Utilisation d'AWS Organizations à des fins de sécurité

AWS Organizations vous aide à gérer et à gouverner de manière centralisée votre environnement à mesure que vous développez et adaptez vos ressources AWS. En utilisant AWS Organizations, vous pouvez créer par programmation de nouveaux comptes AWS, allouer des ressources, regrouper des comptes pour organiser vos charges de travail et appliquer des politiques à des comptes ou à des groupes de comptes à des fins de gouvernance. Une organisation AWS consolide vos comptes AWS afin que vous puissiez les administrer en tant qu'unité unique. Il possède un compte de gestion et zéro ou plusieurs comptes membres. La plupart de vos charges de travail résident dans des comptes membres, à l'exception de certains processus gérés de manière centralisée qui doivent résider soit dans le compte de gestion, soit dans des comptes désignés en tant qu'administrateurs délégués pour des services AWS spécifiques. Vous pouvez fournir des outils et un accès à partir d'un emplacement central à votre équipe de sécurité afin de gérer les besoins de sécurité pour le compte d'une organisation AWS. Vous pouvez réduire la duplication des ressources en partageant les ressources critiques au sein de votre organisation AWS. Vous pouvez regrouper les comptes dans des unités organisationnelles AWS (OUs), qui peuvent représenter différents environnements en fonction des exigences et de l'objectif de la charge de travail. AWS Organizations fournit également plusieurs politiques qui vous permettent d'appliquer de manière centralisée des contrôles de sécurité supplémentaires à tous les comptes membres de vos organisations. Cette section se concentre sur les politiques de contrôle des services (SCPs), les politiques de contrôle des ressources (RCPs) et les politiques déclaratives.

Avec AWS Organizations, vous pouvez utiliser SCPset RCPsappliquer des barrières d'autorisation au niveau de l'organisation, de l'unité d'organisation ou du compte AWS. SCPs sont des garde-fous qui s'appliquent aux principaux du compte d'une organisation, à l'exception du compte de gestion (c'est l'une des raisons de ne pas gérer les charges de travail sur ce compte). Lorsque vous attachez un SCP à une unité d'organisation, le SCP est hérité par l'enfant OUs et les comptes associés à cette unité d'organisation. SCPs n'accordez aucune autorisation. Ils spécifient plutôt les autorisations maximales pour une organisation, une unité d'organisation ou un compte AWS. Vous devez toujours associer des politiques basées sur l'identité ou les ressources aux principaux ou aux ressources de vos comptes AWS pour leur accorder des autorisations. Par exemple, si un SCP refuse l'accès à l'ensemble d'Amazon S3, le principal concerné par le SCP n'aura pas accès à Amazon S3 même s'il y est explicitement autorisé par le biais d'une politique IAM. Pour plus d'informations sur la manière dont les politiques IAM sont évaluées, le rôle de SCPs celles-ci et la manière dont l'accès est finalement accordé ou refusé, consultez la section sur la logique d'évaluation des politiques dans la documentation IAM.

RCPs sont des garde-fous qui s'appliquent aux ressources figurant dans les comptes d'une organisation, qu'elles appartiennent ou non à la même organisation. Par exemple SCPs, RCPs n'affectez pas les ressources du compte de gestion et n'accordez aucune autorisation. Lorsque vous attachez un RCP à une UO, le RCP est hérité par l'enfant OUs et les comptes associés à l'UO. RCPs fournissent un contrôle centralisé sur les autorisations maximales disponibles pour les ressources de votre organisation et prennent actuellement en charge un sous-ensemble de services AWS. Lorsque vous concevez SCPs pour votre OUs, nous vous recommandons d'évaluer les modifications à l'aide du simulateur de politique IAM. Vous devez également consulter les dernières données auxquelles le service a été accédé dans IAM et utiliser AWS CloudTrail pour enregistrer l'utilisation du service au niveau de l'API afin de comprendre l'impact potentiel des modifications du SCP.

SCPs et RCPs sont des commandes indépendantes. Vous pouvez choisir d'activer uniquement SCPs ou RCPs d'utiliser les deux types de politiques ensemble en fonction des contrôles d'accès que vous souhaitez appliquer. Par exemple, si vous souhaitez empêcher les responsables de votre organisation d'accéder à des ressources extérieures à votre organisation, vous devez appliquer ce contrôle en utilisant SCPs. Si vous souhaitez restreindre ou empêcher les identités externes d'accéder à vos ressources, vous devez appliquer ce contrôle en utilisant RCPs. Pour plus d'informations et des cas d'utilisation pour RCPs et SCPs, consultez Using SCPs and RCPs dans la documentation AWS Organizations.

Vous pouvez utiliser les politiques déclaratives d'AWS Organizations pour déclarer et appliquer de manière centralisée la configuration souhaitée pour un service AWS donné à grande échelle au sein d'une organisation. Par exemple, vous pouvez bloquer l'accès public à Internet aux ressources Amazon VPC au sein de votre organisation. Contrairement aux politiques d'autorisation telles que SCPs et RCPs, les politiques déclaratives sont appliquées dans le plan de contrôle d'un service AWS. Les politiques d'autorisation régulent l'accès à APIs, tandis que les politiques déclaratives sont appliquées directement au niveau du service pour faire respecter une intention durable. Ces politiques permettent de garantir que la configuration de base d'un service AWS est toujours maintenue, même lorsque le service introduit de nouvelles fonctionnalités ou APIs. La configuration de base est également maintenue lorsque de nouveaux comptes sont ajoutés à une organisation ou lorsque de nouveaux directeurs et ressources sont créés. Les politiques déclaratives peuvent être appliquées à l'ensemble d'une organisation ou à des comptes spécifiques OUs .

Chaque compte AWS possède un seul utilisateur root qui dispose des autorisations complètes sur toutes les ressources AWS par défaut.  Pour des raisons de sécurité, nous vous recommandons de ne pas utiliser l'utilisateur root, sauf pour quelques tâches qui nécessitent explicitement un utilisateur root. Si vous gérez plusieurs comptes AWS via AWS Organizations, vous pouvez désactiver la connexion root de manière centralisée, puis effectuer des actions privilégiées root pour le compte de tous les comptes membres. Après avoir géré de manière centralisée l'accès root pour les comptes membres, vous pouvez supprimer le mot de passe de l'utilisateur root, les clés d'accès et les certificats de signature, et désactiver l'authentification multifactorielle (MFA) pour les comptes membres. Les nouveaux comptes créés dans le cadre d'un accès root géré de manière centralisée ne disposent par défaut d'aucun identifiant d'utilisateur root. Les comptes membres ne peuvent pas se connecter avec leur utilisateur root ni récupérer le mot de passe de leur utilisateur root.

AWS Control Tower propose un moyen simplifié de configurer et de gérer plusieurs comptes. Il automatise la configuration des comptes dans votre organisation AWS, automatise le provisionnement, applique des garde-fous (notamment des contrôles préventifs et de détection) et vous fournit un tableau de bord pour plus de visibilité. Une politique de gestion IAM supplémentaire, une limite d'autorisations, est attachée à des entités IAM spécifiques (utilisateurs ou rôles) et définit les autorisations maximales qu'une politique basée sur l'identité peut accorder à une entité IAM.

AWS Organizations vous aide à configurer les services AWS qui s'appliquent à tous vos comptes. Par exemple, vous pouvez configurer la journalisation centralisée de toutes les actions effectuées au sein de votre organisation AWS à l'aide d'AWS CloudTrail, et empêcher les comptes membres de désactiver la journalisation. Vous pouvez également agréger de manière centralisée les données relatives aux règles que vous avez définies à l'aide d'AWS Config, afin de vérifier la conformité de vos charges de travail et de réagir rapidement aux modifications. Vous pouvez utiliser AWS CloudFormation StackSets pour gérer de manière centralisée les CloudFormation stacks AWS entre les comptes et OUs au sein de votre organisation AWS, afin de pouvoir configurer automatiquement un nouveau compte répondant à vos exigences de sécurité.

La configuration par défaut d'AWS Organizations prend en charge l'utilisation SCPs comme liste de refus. En utilisant une stratégie de liste de refus, les administrateurs des comptes membres peuvent déléguer tous les services et actions jusqu'à ce que vous créiez et associiez un SCP refusant un service ou un ensemble d'actions spécifique. Les instructions de refus nécessitent moins de maintenance qu'une liste d'autorisation, car vous n'avez pas à les mettre à jour lorsqu'AWS ajoute de nouveaux services. Les instructions de refus sont généralement plus courtes en caractères, il est donc plus facile de respecter la taille maximale pour SCPs. Dans une instruction dont la valeur de l'Effect élément est égale àDeny, vous pouvez également restreindre l'accès à des ressources spécifiques ou définir les conditions d'entrée en vigueur. SCPs En revanche, une instruction Allow dans un SCP s'applique à toutes les ressources ("*") et ne peut pas être limitée par des conditions. Pour plus d'informations et des exemples, consultez la section Stratégie d'utilisation SCPs dans la documentation AWS Organizations.