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

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

• 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

• Prise en charge des limites des autorisations pour le rôle AWS CodeBuild pour CodeSeeder

• Architecture à comptes multiples AWS

• 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 (IAM) AWS Identity and Access Management générées pour un module ADDF disposent des autorisations minimales requises pour le cas d'utilisation. 

• Les AWS services 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 cadre 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 ressources AWS de manière impérative. AWS CDK applique déjà les bonnes pratiques de sécurité par défaut pour divers services et scénarios. Avec AWS CDK, le risque lié aux mauvaises configurations de sécurité est réduit.

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

L'utilitaire cdk-nag open source (GitHub) est intégré dans ADDF. Cet utilitaire vérifie automatiquement que les modules ADDF basés sur AWS CDK respectent les bonnes pratiques générales et de sécurité. 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, voir Règles cdk-nag (GitHub).

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

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

Par défaut, AWS CDK assigne la stratégie gérée par AWS AdministratorAccess permissive au rôle de déploiement AWS CDK créé dans des comptes amorcés. Le nom complet de ce rôle est cdk-[CDK_QUALIFIER]-cfn-exec-role-[AWS_ACCOUNT_ID]-[REGION]. AWS CDK utilise ce rôle pour déployer des ressources dans le Compte AWS amorcé dans le cadre du processus de déploiement d'AWS CDK.

En fonction des exigences de sécurité de votre organisation, la stratégie AdministratorAccess peut être trop permissive. Dans le cadre du processus d'amorçage d'AWS CDK, vous pouvez personnaliser la stratégie et les autorisations en fonction de vos besoins. Vous pouvez modifier la stratégie en réamorçant le compte avec une nouvelle stratégie définie à l'aide du paramètre --cloudformation-execution-policies. Pour plus d'informations, veuillez consulter Personnalisation du bootstrapping (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 de destination à l'aide d'AWS CodeBuild. CodeSeeder attribue une fonction du service par défaut à CodeBuild pour 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. Elle inclut toutes les autorisations requises pour le déploiement d'applications AWS CDK, car tous les modules fournis par ADDF sont créés en tant qu'applications AWS CDK.

Toutefois, si vous devez exécuter des commandes d'étape en dehors d'AWS CDK, vous devez créer une politique IAM personnalisée au lieu d'utiliser la fonction du service par défaut pour CodeBuild. Par exemple, si vous utilisez un autre cadre de déploiement IaC qu'AWS CDK, comme Terraform, vous devez créer une politique IAM qui accorde des autorisations suffisantes pour que ce cadre spécifique fonctionne. Un autre scénario qui nécessite une politique IAM dédiée est celui où vous incluez les appels directs AWS Command Line Interface (AWS CLI) vers d'autres AWS services dans les commandes d'étape install, pre_build, build ou post_build. Par exemple, vous avez besoin d'une stratégie 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 offre un contrôle précis pour toute commande AWS en dehors du déploiement d'AWS CDK. Pour un exemple de politique IAM personnalisée, voir ModuleStack (documentation SeedFarmer). 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 renforcer la protection de ces données, les modules fournis par SeedFarmer, CodeSeeder et ADDF chiffrent les données au repos et en transit pour tous les AWS services utilisés (sauf indication contraire explicite pour les modules du dossier demo-only).

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

ADDF gère divers secrets pour différents services, tels que Docker Hub, JupyterHub et Amazon 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

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

Prise en charge des limites des autorisations pour le rôle AWS CodeBuild pour CodeSeeder

Les limites des autorisations IAM sont 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 CodeSeeder prennent en charge une limite des autorisations IAM pour chaque compte de destination. La limite des autorisations limite les autorisations maximales de toute fonction du service utilisée par CodeBuild lorsque CodeSeeder déploie des 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 stratégie 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, veuillez consulter Permissions boundary support (documentation SeedFarmer).

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 stratégies de limite des autorisations.

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

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

4. Une fois le déploiement réussi, la limite des autorisations est jointe à toutes les fonctions du service utilisées par CodeBuild pour déployer des modules.

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

Architecture à comptes multiples AWS

Tel que défini dans le pilier de sécurité du cadre AWS Well-Architected, il est considéré comme une bonne pratique de séparer les ressources et les charges de travail en plusieurs Comptes AWS, en fonction des exigences de votre organisation. Cela s'explique par le fait qu'un Compte AWS sert de limite d'isolement. 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 de manière native les architectures à comptes multiples AWS. Vous pouvez répartir vos modules ADDF sur autant d'Comptes AWS que nécessaire pour répondre aux exigences de votre organisation en matière de sécurité et de séparation des tâches. 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.

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 à comptes multiples, SeedFarmer doit accéder aux comptes de destination 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. Lancer des tâches AWS CodeBuild dans les comptes de destination, 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'endosser les rôles AWS Identity and Access Management (IAM) propres à ADDF.

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 chaîne d'outils. SeedFarmer endosse 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 AWS Systems Manager Parameter Store locales.

• 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 AWS Systems Manager Parameter Store locales et des actions AWS CodeBuild qui initient et décrivent des tâches CodeBuild via CodeSeeder.

Ces rôles IAM propres à ADDF sont créés dans le cadre du processus d'amorçage d'ADDF. Pour plus d'informations, veuillez consulter Bootstrap Compte AWS(s) dans le Guide de déploiement d'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.