Déployez des contrôles d'accès préventifs basés sur les attributs pour les sous-réseaux publics - Recommandations AWS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Déployez des contrôles d'accès préventifs basés sur les attributs pour les sous-réseaux publics

Créée par Joel Alfredo Nunez Gonzalez (AWS) et Samuel Ortega Sancho (AWS)

Récapitulatif

Dans les architectures réseau centralisées, les clouds privés virtuels d'inspection et de périphérie (VPCs) concentrent tout le trafic entrant et sortant, tel que le trafic à destination et en provenance d'Internet. Cela peut toutefois créer des goulots d'étranglement ou entraîner l'atteinte des limites des quotas de service AWS. Le déploiement de la sécurité périphérique du réseau en même temps que les charges de travail qu'il implique VPCs offre une évolutivité sans précédent par rapport à l'approche centralisée plus courante. C'est ce qu'on appelle une architecture de périphérie distribuée.

Bien que le déploiement de sous-réseaux publics dans les comptes de charge de travail puisse présenter des avantages, il présente également de nouveaux risques de sécurité car il augmente la surface d'attaque. Nous vous recommandons de déployer uniquement des ressources Elastic Load Balancing (ELB), telles que des équilibreurs de charge d'application ou des passerelles NAT dans leurs sous-réseaux publics. VPCs L'utilisation d'équilibreurs de charge et de passerelles NAT dans des sous-réseaux publics dédiés vous permet de mettre en œuvre un contrôle précis du trafic entrant et sortant.

Le contrôle d'accès basé sur les attributs (ABAC) consiste à créer des autorisations détaillées basées sur les attributs de l'utilisateur, tels que le département, le rôle du poste et le nom de l'équipe. Pour plus d'informations, consultez ABAC pour AWS. ABAC peut fournir des garde-fous pour les sous-réseaux publics des comptes de charge de travail. Cela permet aux équipes d'application d'être agiles, sans compromettre la sécurité de l'infrastructure.

Ce modèle décrit comment sécuriser les sous-réseaux publics en implémentant l'ABAC par le biais d'une politique de contrôle des services (SCP) dans AWS Organizations et de politiques dans AWS Identity and Access Management (IAM). Vous appliquez le SCP à un compte membre d'une organisation ou à une unité organisationnelle (UO). Ces politiques ABAC permettent aux utilisateurs de déployer des passerelles NAT dans les sous-réseaux cibles et les empêchent de déployer d'autres ressources Amazon Elastic Compute Cloud (Amazon EC2), telles que des EC2 instances et des interfaces réseau élastiques.  

Conditions préalables et limitations

Prérequis

  • Une organisation dans AWS Organizations

  • Accès administratif au compte racine d'AWS Organizations

  • Dans l'organisation, un compte de membre actif ou une unité d'organisation pour tester le SCP

Limites

  • Le SCP de cette solution n'empêche pas les services AWS qui utilisent un rôle lié à un service de déployer des ressources dans les sous-réseaux cibles. Elastic Load Balancing (ELB), Amazon Elastic Container Service (Amazon ECS) et Amazon Relational Database Service (Amazon RDS) sont des exemples de ces services. Pour plus d'informations, consultez les effets du SCP sur les autorisations dans la documentation d'AWS Organizations. Mettez en œuvre des contrôles de sécurité pour détecter ces exceptions.

Architecture

Pile technologique cible

  • SCP appliqué à un compte AWS ou à une unité d'organisation dans AWS Organizations

  • Les rôles IAM suivants :

    • AutomationAdminRole— Utilisé pour modifier les balises de sous-réseau et créer des ressources VPC après avoir implémenté le SCP

    • TestAdminRole— Utilisé pour vérifier si le SCP empêche les autres principaux IAM, y compris ceux disposant d'un accès administratif, d'effectuer les actions réservées au AutomationAdminRole

Architecture cible

Les balises empêchent les utilisateurs de déployer des ressources autres que les passerelles NAT dans des sous-réseaux publics
  1. Vous créez le rôle AutomationAdminRole IAM dans le compte cible. Ce rôle est autorisé à gérer les ressources réseau. Notez les autorisations suivantes qui sont exclusives à ce rôle :

    • Ce rôle peut créer VPCs des sous-réseaux publics.

    • Ce rôle peut modifier les attributions de balises pour les sous-réseaux cibles.

    • Ce rôle peut gérer ses propres autorisations.

  2. Dans AWS Organizations, vous appliquez le SCP au compte ou à l'unité d'organisation AWS cible. Pour un exemple de politique, voir Informations supplémentaires sur ce modèle.

  3. Un utilisateur ou un outil du pipeline CI/CD peut assumer le AutomationAdminRole rôle d'appliquer la SubnetType balise aux sous-réseaux cibles.

  4. En assumant d'autres rôles IAM, les responsables IAM autorisés de votre organisation peuvent gérer les passerelles NAT dans les sous-réseaux cibles et les autres ressources réseau autorisées dans le compte AWS, telles que les tables de routage. Utilisez les politiques IAM pour accorder ces autorisations. Pour plus d'informations, consultez Gestion des identités et des accès pour Amazon VPC.

Automatisation et mise à l'échelle

Pour protéger les sous-réseaux publics, les balises AWS correspondantes doivent être appliquées. Une fois le SCP appliqué, les passerelles NAT sont le seul type de EC2 ressource Amazon que les utilisateurs autorisés peuvent créer dans les sous-réseaux dotés de cette balise. SubnetType:IFA (IFAdésigne les actifs connectés à Internet.) Le SCP empêche la création d'autres EC2 ressources Amazon, telles que des instances et des interfaces réseau élastiques. Nous vous recommandons d'utiliser un pipeline CI/CD qui assume le AutomationAdminRole rôle de créer des ressources VPC afin que ces balises soient correctement appliquées aux sous-réseaux publics.

Outils

Services AWS

  • AWS Identity and Access Management (IAM) vous aide à gérer en toute sécurité l'accès à vos ressources AWS en contrôlant qui est authentifié et autorisé à les utiliser.

  • AWS Organizations est un service de gestion de comptes qui vous aide à consolider plusieurs comptes AWS au sein d'une organisation que vous créez et gérez de manière centralisée. Dans AWS Organizations, vous pouvez mettre en œuvre des politiques de contrôle des services (SCPs), qui sont un type de politique que vous pouvez utiliser pour gérer les autorisations au sein de votre organisation.

  • Amazon Virtual Private Cloud (Amazon VPC) vous aide à lancer des ressources AWS dans un réseau virtuel que vous avez défini. Ce réseau virtuel ressemble à un réseau traditionnel que vous exploiteriez dans votre propre centre de données, avec les avantages liés à l'utilisation de l'infrastructure évolutive d'AWS.

Épopées

TâcheDescriptionCompétences requises

Créez un rôle d'administrateur de test.

Créez un rôle IAM nommé TestAdminRole dans le compte AWS cible. Associez la politique IAM gérée par AdministratorAccessAWS au nouveau rôle. Pour obtenir des instructions, consultez la section Création d'un rôle pour déléguer des autorisations à un utilisateur IAM dans la documentation IAM.

Administrateur AWS

Créez le rôle d'administrateur d'automatisation.

  1. Créez un rôle IAM nommé AutomationAdminRole dans le compte AWS cible.

  2. Associez la politique IAM gérée par AdministratorAccessAWS au nouveau rôle.

Voici un exemple de politique de confiance que vous pouvez utiliser pour tester le rôle à partir du 000000000000 compte.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::000000000000:root" ] }, "Action": "sts:AssumeRole", "Condition": {} } ] }
Administrateur AWS

Créez et attachez le SCP.

  1. À l'aide de l'exemple de code fourni dans la section Informations supplémentaires, créez une politique de contrôle de sécurité. Pour obtenir des instructions, consultez la section Création d'un SCP dans la documentation d'AWS Organizations.

  2. Attachez le SCP au compte AWS ou à l'unité d'organisation cible. Pour obtenir des instructions, consultez la section Attacher et détacher des politiques de contrôle des services dans la documentation d'AWS Organizations.

Administrateur AWS
TâcheDescriptionCompétences requises

Créez un VPC ou un sous-réseau.

  1. Assumez le TestAdminRole rôle dans le compte AWS cible.

  2. Essayez de créer un VPC ou un nouveau sous-réseau public dans un VPC existant. Pour obtenir des instructions, consultez la section Créer un VPC, des sous-réseaux et d'autres ressources VPC dans la documentation Amazon VPC. Vous ne devriez pas être en mesure de créer ces ressources.

  3. Assumez le AutomationAdminRole rôle et réessayez de passer à l'étape précédente. Vous devriez maintenant être en mesure de créer les ressources réseau.

Administrateur AWS

Gérez les tags.

  1. Assumez le TestAdminRole rôle dans le compte AWS cible.

  2. Ajoutez une SubnetType:IFA balise à un sous-réseau public disponible. Vous devriez être en mesure d'ajouter cette balise. Pour obtenir des instructions sur la façon d'ajouter des balises via l'interface de ligne de commande AWS (AWS CLI), consultez la section create-tags dans le manuel de référence des commandes de l'AWS CLI.

  3. Sans modifier vos informations d'identification, essayez de modifier la SubnetType:IFA balise attribuée à ce sous-réseau. Vous ne devriez pas être en mesure de modifier cette balise.

  4. Assumez le AutomationAdminRole rôle et réessayez les étapes précédentes. Ce rôle doit être en mesure d'ajouter et de modifier cette balise.

Administrateur AWS

Déployez des ressources dans les sous-réseaux cibles.

  1. Assumez le TestAdminRole rôle.

  2. Pour un sous-réseau public doté de cette SubnetType:IFA balise, essayez de créer une EC2 instance. Pour obtenir des instructions, consultez la section Lancer une instance dans la EC2 documentation Amazon. Dans ce sous-réseau, vous ne devriez pas être en mesure de créer, de modifier ou de supprimer des EC2 ressources Amazon, à l'exception des passerelles NAT.

  3. Dans le même sous-réseau, créez une passerelle NAT. Pour obtenir des instructions, consultez la section Créer une passerelle NAT dans la documentation Amazon VPC. Vous devriez être en mesure de créer, de modifier ou de supprimer des passerelles NAT dans ce sous-réseau.

Administrateur AWS

Gérez le AutomationAdminRole rôle.

  1. Assumez le TestAdminRole rôle.

  2. Essayez de modifier le AutomationAdminRole rôle. Pour obtenir des instructions, consultez la section Modification d'un rôle dans la documentation IAM. Vous ne devriez pas être en mesure de modifier ce rôle.

  3. Assumez le AutomationAdminRole rôle et réessayez de passer à l'étape précédente. Vous devriez maintenant être en mesure de modifier le rôle.

Administrateur AWS
TâcheDescriptionCompétences requises

Nettoyez les ressources déployées.

  1. Détachez le SCP du compte AWS ou de l'unité d'organisation. Pour obtenir des instructions, consultez la section Détacher un SCP dans la documentation d'AWS Organizations.

  2. Supprimez la stratégie de contrôle de service. Pour obtenir des instructions, consultez Supprimer un SCP (documentation AWS Organizations).

  3. Supprimez le AutomationAdminRole rôle et le TestAdminRole rôle. Pour obtenir des instructions, consultez la section Suppression de rôles dans la documentation IAM.

  4. Supprimez toutes les ressources réseau, telles que VPCs les sous-réseaux, que vous avez créées pour cette solution.

Administrateur AWS

Ressources connexes

Documentation AWS

Références AWS supplémentaires

Informations supplémentaires

La politique de contrôle des services suivante est un exemple que vous pouvez utiliser pour tester cette approche dans votre organisation.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyVPCActions", "Effect": "Deny", "Action": [ "ec2:CreateVPC", "ec2:CreateRoute", "ec2:CreateSubnet", "ec2:CreateInternetGateway", "ec2:DeleteVPC", "ec2:DeleteRoute", "ec2:DeleteSubnet", "ec2:DeleteInternetGateway" ], "Resource": [ "arn:aws:ec2:*:*:*" ], "Condition": { "StringNotLike": { "aws:PrincipalARN": ["arn:aws:iam::*:role/AutomationAdminRole"] } } }, { "Sid": "AllowNATGWOnIFASubnet", "Effect": "Deny", "NotAction": [ "ec2:CreateNatGateway", "ec2:DeleteNatGateway" ], "Resource": [ "arn:aws:ec2:*:*:subnet/*" ], "Condition": { "ForAnyValue:StringEqualsIfExists": { "aws:ResourceTag/SubnetType": "IFA" }, "StringNotLike": { "aws:PrincipalARN": ["arn:aws:iam::*:role/AutomationAdminRole"] } } }, { "Sid": "DenyChangesToAdminRole", "Effect": "Deny", "NotAction": [ "iam:GetContextKeysForPrincipalPolicy", "iam:GetRole", "iam:GetRolePolicy", "iam:ListAttachedRolePolicies", "iam:ListInstanceProfilesForRole", "iam:ListRolePolicies", "iam:ListRoleTags" ], "Resource": [ "arn:aws:iam::*:role/AutomationAdminRole" ], "Condition": { "StringNotLike": { "aws:PrincipalARN": ["arn:aws:iam::*:role/AutomationAdminRole"] } } }, { "Sid": "allowbydefault", "Effect": "Allow", "Action": "*", "Resource": "*" } ] }