Fonctionnalités de sécurité intégrées ADDF

Autonomous Driving Data Framework (ADDF) dispose de diverses fonctionnalités de sécurité intégrées. Par défaut, ces fonctionnalités sont conçues pour vous aider à configurer un cadre sécurisé et à aider votre organisation à répondre aux exigences de sécurité d'entreprise les plus courantes.

Les fonctionnalités de sécurité intégrées sont les suivantes :

• Moindre privilège pour le code de module ADDF

• Infrastructure en tant que code

• Contrôles de sécurité automatisés pour IaC

• Politique de moindre privilège personnalisée pour le AWS CDK rôle de déploiement

• Politique de moindre privilège pour le fichier deployspec du module

• Chiffrement des données

• Stockage des informations d'identification à l'aide de Secrets Manager

• Examens de sécurité de SeedFarmer et CodeSeeder

• Support des limites d'autorisations pour le AWS CodeBuild rôle pour CodeSeeder

• AWS architecture multi-comptes

• Autorisations de moindre privilège pour les déploiements de comptes multiples

Moindre privilège pour le code de module ADDF

Le moindre privilège est la bonne pratique de sécurité qui consiste à accorder les autorisations minimales nécessaires à l'exécution d'une tâche. Pour en savoir plus, veuillez consulter Appliquer les autorisations de moindre privilège. Les modules fournis par ADDF suivent rigoureusement le principe du moindre privilège dans leur code et dans les ressources déployées, comme suit :

• Toutes les politiques AWS Identity and Access Management (IAM) générées pour un module ADDF disposent des autorisations minimales requises pour le cas d'utilisation. 

• Services AWS sont configurés et déployés selon le principe du moindre privilège. Les modules fournis par ADDF utilisent uniquement les services et fonctionnalités de service requis pour un cas d'utilisation spécifique.

Infrastructure en tant que code

ADDF, en tant que cadre, est conçu pour déployer des modules ADDF sous forme d'infrastructure en tant que code (IaC). L'IaC élimine les processus de déploiement manuel et aide à prévenir les erreurs et les mauvaises configurations qui peuvent résulter des processus manuels. 

ADDF est conçu pour orchestrer et déployer des modules à l'aide de n'importe quel cadre IaC courant. Cela inclut, mais sans s'y limiter : 

• AWS Cloud Development Kit (AWS CDK)

• AWS CloudFormation

• Hashicorp Terraform

Vous pouvez utiliser différents cadres IaC pour écrire différents modules, puis utiliser ADDF pour les déployer.

Le framework IaC par défaut utilisé par les modules ADDF est AWS CDK. AWS CDK est une abstraction orientée objet de haut niveau que vous pouvez utiliser pour définir des AWS ressources de manière impérative. AWS CDK applique déjà les meilleures pratiques de sécurité par défaut pour divers services et scénarios. Grâce à son utilisation AWS CDK, le risque de mauvaises configurations de sécurité est réduit.

Contrôles de sécurité automatisés pour IaC

L'utilitaire open-source cdk-nag (GitHub) est intégré à ADDF. Cet utilitaire vérifie automatiquement le respect des meilleures pratiques générales et de sécurité par AWS CDK les modules ADDF basés sur ces modules. L'utilitaire cdk-nag utilise des règles et des packs de règles pour détecter et signaler le code qui enfreint les bonnes pratiques. Pour plus d'informations sur les règles et une liste complète, consultez cdk-nag rules (). GitHub

Politique de moindre privilège personnalisée pour le AWS CDK rôle de déploiement

ADDF utilise largement la AWS CDK v2. Il est nécessaire de démarrer tous les ADDF Comptes AWS sur. AWS CDK Pour plus d'informations, veuillez consulter Bootstrapping (documentation AWS CDK ).

Par défaut, AWS CDK attribue la politique AdministratorAccess AWS gérée permissive au rôle de AWS CDK déploiement créé dans les comptes bootstrap. Le nom complet de ce rôle estcdk-[CDK_QUALIFIER]-cfn-exec-role-[AWS_ACCOUNT_ID]-[REGION]. AWS CDK utilise ce rôle pour déployer des ressources dans le bootstrap dans le Compte AWS cadre du processus de AWS CDK déploiement.

En fonction des exigences de sécurité de votre organisation, la politique AdministratorAccess peut être trop permissive. Dans le cadre du processus d'amorçage d' AWS CDK , vous pouvez personnaliser la politique et les autorisations en fonction de vos besoins. Vous pouvez modifier la politique en réamorçant le compte avec une nouvelle politique définie à l'aide du paramètre --cloudformation-execution-policies. Pour plus d'informations, consultez la section Personnalisation du bootstrap (documentation)AWS CDK .

Note

Bien que cette fonctionnalité de sécurité ne soit pas propre à ADDF, elle est répertoriée dans cette section, car elle peut améliorer la sécurité globale de votre déploiement ADDF.

Politique de moindre privilège pour le fichier deployspec du module

Chaque module contient un fichier de spécifications de déploiement appelé deployspec.yaml. Ce fichier définit les instructions de déploiement du module. CodeSeeder l'utilise pour déployer le module défini dans le compte cible en utilisant AWS CodeBuild. CodeSeeder attribue un rôle de service par défaut pour CodeBuild déployer les ressources, comme indiqué dans le fichier de spécifications de déploiement. Cette fonction du service est conçue selon le principe du moindre privilège. Il inclut toutes les autorisations requises pour déployer des AWS CDK applications, car tous les modules fournis par l'ADDF sont créés en tant qu' AWS CDK applications.

Toutefois, si vous devez exécuter des commandes d'étape en dehors de AWS CDK, vous devez créer une politique IAM personnalisée au lieu d'utiliser le rôle de service par défaut pour CodeBuild. Par exemple, si vous utilisez un framework de déploiement IaC autre que AWS CDK Terraform, vous devez créer une politique IAM qui accorde des autorisations suffisantes pour que ce framework spécifique fonctionne. Un autre scénario qui nécessite une politique IAM dédiée est celui où vous incluez des appels directs AWS Command Line Interface (AWS CLI) à d'autres Services AWS personnes dans les commandes install pre_buildbuild,, ou post_build stage. Par exemple, vous avez besoin d'une politique personnalisée si votre module inclut une commande Amazon Simple Storage Service (Amazon S3) pour charger des fichiers dans un compartiment S3. La politique IAM personnalisée fournit un contrôle précis pour toute AWS commande en dehors du déploiement. AWS CDK Pour un exemple de politique IAM personnalisée, voir ModuleStack(SeedFarmer documentation). Lorsque vous créez une politique IAM personnalisée pour votre module ADDF, assurez-vous d'appliquer les autorisations de moindre privilège.

Chiffrement des données

ADDF stocke et traite des données potentiellement sensibles. Pour protéger ces données,, SeedFarmer CodeSeeder, et les modules fournis par ADDF chiffrent les données au repos et en transit pour toutes les données utilisées Services AWS (sauf indication contraire explicite pour les modules du demo-only dossier).

Stockage des informations d'identification à l'aide de Secrets Manager

ADDF gère divers secrets pour différents services, tels que Docker Hub et Amazon JupyterHub Redshift. ADDF utilise AWS Secrets Manager pour stocker tous les secrets liés à ADDF. Cela vous permet de supprimer les données sensibles du code source.

Les secrets de Secrets Manager sont uniquement stockés dans les comptes de destination, dans la mesure où ils sont nécessaires au bon fonctionnement de ces comptes. Par défaut, le compte de chaîne d'outils ne contient aucun secret.

Examens de sécurité de SeedFarmer et CodeSeeder

SeedFarmeret CodeSeeder(GitHubréférentiels) sont utilisés pour déployer ADDF et ses modules ADDF. Ces projets open source sont soumis au même processus régulier de révision AWS interne de la sécurité que l'ADDF, comme décrit dans. Processus de révision de la sécurité ADDF

Support des limites d'autorisations pour le AWS CodeBuild rôle pour CodeSeeder

Les limites d'autorisations IAM constituent un mécanisme de sécurité courant qui définit les autorisations maximales qu'une politique basée sur l'identité peut accorder à une entité IAM. SeedFarmer et prenez CodeSeeder en charge la fixation d'une limite d'autorisations IAM pour chaque compte cible. La limite d'autorisations limite les autorisations maximales de tout rôle de service utilisé CodeBuild lors du CodeSeeder déploiement de modules. Les limites des autorisations IAM doivent être créées en dehors d'ADDF par une équipe de sécurité. Les pièces jointes à la politique de limite des autorisations IAM sont acceptées en tant qu'attributs dans le fichier manifeste de déploiement ADDF, deployment.yaml. Pour plus d'informations, consultez la section Support des limites d'autorisations (SeedFarmer documentation).

Le flux de travail est le suivant :

1. Votre équipe de sécurité définit et crée une limite des autorisations IAM en fonction de vos exigences de sécurité. La limite des autorisations IAM doit être créée individuellement dans chaque Compte AWS ADDF. Le résultat est une liste Amazon Resource Name (ARN) des politiques de limite des autorisations.

2. L'équipe de sécurité partage la liste ARN des politiques avec votre équipe de développement ADDF.

3. L'équipe de développement ADDF intègre la liste ARN des politiques dans le fichier manifeste. Pour un exemple de cette intégration, consultez sample-permissionboundary.yaml () et manifeste de déploiement (documentation). GitHub SeedFarmer

4. Une fois le déploiement réussi, la limite d'autorisations est attachée à tous les rôles de service CodeBuild utilisés pour déployer des modules.

5. L'équipe de sécurité veille à ce que les limites des autorisations soient appliquées selon les besoins.

AWS architecture multi-comptes

Comme défini dans le pilier de sécurité du AWS Well-Architected Framework, il est considéré comme une bonne pratique de séparer les ressources et les charges de travail en Comptes AWS plusieurs, en fonction des exigences de votre organisation. Cela est dû au fait que an Compte AWS agit comme une limite d'isolation. Pour plus d'informations, veuillez consulter Gestion et séparation de Compte AWS. La mise en œuvre de ce concept est appelée architecture à comptes multiples. Une architecture à comptes multiples AWS bien conçue permet de catégoriser les charges de travail et de réduire l'impact en cas de faille de sécurité, par rapport à une architecture à compte unique.

ADDF prend en charge nativement les architectures AWS multi-comptes. Vous pouvez distribuer vos modules ADDF sur Comptes AWS autant de modules que nécessaire pour répondre aux exigences de sécurité et separation-of-duties aux exigences de votre organisation. Vous pouvez déployer ADDF dans un seul Compte AWS, en combinant les fonctions de la chaîne d'outils et du compte de destination. Vous pouvez également créer des comptes de destination individuels pour les modules ou les groupes de modules ADDF.

La seule restriction que vous devez prendre en compte est qu'un module ADDF représente la plus petite unité de déploiement pour chaque Compte AWS module.

Pour les environnements de production, il est recommandé d'utiliser une architecture à comptes multiples composée d'un compte de chaîne d'outils et d'au moins un compte de destination. Pour de plus amples informations, veuillez consulter Architecture ADDF.

Autorisations de moindre privilège pour les déploiements de comptes multiples

Si vous utilisez une architecture multi-comptes, SeedFarmer vous devez accéder aux comptes cibles pour effectuer les trois actions suivantes :

1. Écrire les métadonnées du module ADDF dans le compte de chaîne d'outils et les comptes de destination.

2. Lire les métadonnées du module ADDF en cours à partir du compte chaîne d'outils et des comptes de destination.

3. Lancez AWS CodeBuild des tâches dans les comptes cibles, dans le but de déployer ou de mettre à jour des modules.

La figure suivante montre les relations entre comptes, y compris les opérations permettant d'assumer des rôles spécifiques à l'ADDF AWS Identity and Access Management (IAM).

Ces actions entre comptes sont réalisées à l'aide d'opérations assume-role bien définies.

• Le rôle IAM de la chaîne d'outils ADDF est déployé dans le compte de la chaîne d'outils. SeedFarmer assume ce rôle. Ce rôle est autorisé à exécuter une action iam:AssumeRole et peut endosser le rôle IAM de déploiement ADDF dans chaque compte de destination. En outre, le rôle IAM de la chaîne d'outils ADDF peut exécuter des opérations locales de magasin de AWS Systems Manager paramètres.

• Le rôle IAM de déploiement ADDF est déployé dans chaque compte de destination. Ce rôle ne peut être endossé qu'à partir du compte de chaîne d'outils en utilisant le rôle IAM de la chaîne d'outils ADDF. Ce rôle est autorisé à exécuter des opérations locales du magasin de AWS Systems Manager paramètres et à exécuter des AWS CodeBuild actions qui initient et décrivent des CodeBuild tâches par le biais desquelles CodeSeeder.

Ces rôles IAM propres à ADDF sont créés dans le cadre du processus d'amorçage d'ADDF. Pour plus d'informations, consultez Bootstrap Compte AWS(s) dans le guide de déploiement ADDF ()GitHub.

Toutes les autorisations de comptes multiples sont définies selon le principe du moindre privilège. Si un compte de destination est compromis, l'impact sur les autres Comptes AWS ADDF est minime ou nul.

Dans le cas d'une architecture à compte unique pour ADDF, les relations entre les rôles restent les mêmes. Elles se fondent simplement dans un Compte AWS unique.