Utilisation AWS Organizations pour la sécurité

AWS Organizationsvous permet de gérer et de gouverner votre environnement de manière centralisée à mesure que vous développez et faites évoluer vos AWS ressources. En utilisant AWS Organizations, vous pouvez créer de nouveaux comptes par programmation 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 AWS organisation consolide les vôtres 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 raisons spécifiques Services AWS. Vous pouvez fournir des outils et un accès à partir d'un emplacement central à votre équipe de sécurité afin qu'elle puisse gérer les besoins de sécurité au nom d'une AWS organisation. Vous pouvez réduire la duplication des ressources en partageant les ressources critiques au sein de votre AWS organisation. Vous pouvez regrouper les comptes en unités AWS organisationnelles (UO), 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 (SCP), les politiques de contrôle des ressources (RCP) et les politiques déclaratives.

Avec AWS Organizations, vous pouvez utiliser les SCP et les RCP pour appliquer des garanties d'autorisation au niveau de l' AWS organisation, de l'unité d'organisation ou du compte. Les SCP sont des garde-fous qui s'appliquent aux principaux du compte d'une organisation, à l'exception du compte de gestion (ce qui est l'une des raisons de ne pas exécuter de charges de travail sur ce compte). Lorsque vous attachez un SCP à une UO, le SCP est hérité par les UO enfants et les comptes associés à cette UO. Les SCP n'accordent aucune autorisation. Ils spécifient plutôt les autorisations maximales disponibles pour vos principaux au sein d'une AWS organisation, d'une unité d'organisation ou d'un compte. Vous devez toujours associer des politiques basées sur l'identité ou les ressources aux principaux ou aux ressources de votre entreprise 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 des SCP et la manière dont l'accès est finalement accordé ou refusé, consultez la section Logique d'évaluation des politiques dans la documentation IAM.

Les RCP sont des garde-fous qui s'appliquent aux ressources des comptes d'une organisation, qu'elles appartiennent ou non à la même organisation. Comme les SCP, les RCP n'affectent pas les ressources du compte de gestion et n'accordent aucune autorisation. Lorsque vous attachez un RCP à une UO, le RCP est hérité par les UO enfants et les comptes associés à l'UO. Les RCP 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 des SCP pour vos unités d'organisation, nous vous recommandons d'évaluer les modifications à l'aide du simulateur de politique IAM. Vous devez également consulter les données du dernier accès au service dans IAM et les utiliser AWS CloudTrail pour enregistrer l'utilisation du service au niveau de l'API afin de comprendre l'impact potentiel des modifications du SCP.

Les SCP et les RCP sont des contrôles indépendants. Vous pouvez choisir d'activer uniquement les SCP ou les RCP, ou 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 dirigeants de votre organisation d'accéder à des ressources extérieures à votre organisation, vous devez appliquer ce contrôle en utilisant des SCP. Si vous souhaitez restreindre ou empêcher les identités externes d'accéder à vos ressources, vous devez appliquer ce contrôle à l'aide de RCP. Pour plus d'informations et les cas d'utilisation des RCP et des SCP, consultez la section Utilisation des SCP et des RCP dans la documentation. AWS Organizations

Vous pouvez utiliser des politiques AWS Organizations déclaratives pour déclarer et appliquer de manière centralisée la configuration souhaitée pour une donnée Service AWS à 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 les SCP et les RCP, les politiques déclaratives sont appliquées dans le plan de contrôle d'un AWS service. Les politiques d'autorisation régulent l'accès aux API, 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 API. 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 unités d'organisation ou à des comptes spécifiques.

Chacun Compte AWS dispose d'un seul utilisateur root qui dispose des autorisations complètes sur toutes les AWS ressources 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 Comptes AWS 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 Towerpropose un moyen simplifié de configurer et de gérer plusieurs comptes. Il automatise la configuration des comptes dans votre AWS organisation, automatise le provisionnement, applique des contrôles (y compris 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 principes IAM spécifiques (utilisateurs ou rôles) et définit le maximum d'autorisations qu'une politique basée sur l'identité peut accorder à un principal IAM.

AWS Organizations vous permet de les configurer pour Services AWSqu'elles s'appliquent à tous vos comptes. Par exemple, vous pouvez configurer la journalisation centralisée de toutes les actions effectuées au sein de votre AWS organisation en utilisant CloudTrail et en empêchant les comptes membres de désactiver la journalisation. Vous pouvez également agréger de manière centralisée les données pour les règles que vous avez définies à l'aide de celles-ci AWS Config, afin de vérifier la conformité de vos charges de travail et de réagir rapidement aux modifications. Vous pouvez l'utiliser AWS CloudFormation StackSetspour gérer de manière centralisée les CloudFormation piles entre les comptes et les unités d' AWS organisation de votre organisation, afin de pouvoir configurer automatiquement un nouveau compte pour répondre à vos exigences de sécurité.

La configuration par défaut des AWS Organizations supports utilise les SCP comme listes 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 lors de l' AWS ajout de nouveaux services. Les déclarations de refus sont généralement plus courtes en caractères, il est donc plus facile de respecter la taille maximale des SCP. Dans une instruction où l'élément Effect a une valeur de Deny, vous pouvez également limiter l'accès à des ressources spécifiques ou définir des conditions pour le moment où les politiques de contrôle des services sont en vigueur. En revanche, une Allow déclaration 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égies d'utilisation des SCP dans la AWS Organizations documentation.