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.
Évaluation du SCP
Note
Les informations contenues dans cette section ne s'appliquent pas aux types de politiques déclaratives, y compris les politiques de sauvegarde, les politiques de balises, les politiques relatives aux applications de chat ou les politiques de désinscription des services d'intelligence artificielle. Pour de plus amples informations, veuillez consulter Comprendre l'héritage des politiques déclaratives.
Vous pouvez attacher plusieurs politiques de contrôle des services (SCP) à différents niveaux dans AWS Organizations. Comprendre comment les SCP sont évaluées peut ainsi vous aider à définir des SCP de sorte qu'elles produisent les résultats attendus.
Rubriques
Fonctionnement des SCP avec Allow
Pour qu'une autorisation soit accordée pour un compte spécifique, une instruction Allow explicite est nécessaire à chaque niveau, de la racine via chaque UO sur le chemin d'accès direct au compte (y compris le compte cible lui-même). C'est pourquoi, lorsque vous activez les SCP, vous associez AWS Organizations une politique SCP AWS gérée nommée FullawsAccess qui autorise tous les services et actions
Examinons le scénario des figures 1 et 2. Pour qu'une autorisation soit accordée ou qu'un service soit autorisé pour le compte B, une SCP accordant l'autorisation ou autorisant le service doit être attachée à la racine, à l'UO de production et au compte B.
L'évaluation des SCP obéit à un modèle de refus par défaut selon lequel toutes les autorisations non explicitement autorisées dans les SCP sont refusées. Si aucune instruction Allow n'est présente dans les SCP à quelque niveau que ce soit (à la racine ou au niveau de l'UO de production ou du compte B), l'accès est refusé.
Figure 1 : exemple de structure organisationnelle avec une instruction Allow attachée à la racine, à l'UO de production et au compte B
Figure 2 : exemple de structure organisationnelle avec une instruction Allow attachée à l'UO de production et impact sur le compte B
Fonctionnement des SCP avec Deny
N'importe quelle SCP de la racine via chaque UO sur le chemin d'accès direct au compte (y compris le compte cible lui-même) peut refuser une autorisation pour un compte spécifique.
Supposons, par exemple, qu'une SCP attachée à l'UO de production comporte une instruction Deny explicite spécifiée pour un service donné. Une autre SCP attachée à la racine et au compte B autorise explicitement l'accès à ce même service, comme le montre la figure 3. Par conséquent, le compte A et le compte B se verront refuser l'accès au service, car une politique de refus attachée à tous les niveaux de l'organisation est évaluée pour toutes les UO et tous les comptes membres sous-jacents.
Figure 3 : exemple de structure organisationnelle avec une instruction Deny attachée à l'UO de production et impact sur le compte B
Stratégie d'utilisation des SCP
Lorsque vous rédigez des SCP, vous pouvez utiliser une combinaison de Deny déclarations Allow et de déclarations pour autoriser les actions et les services prévus dans votre organisation. Denyles déclarations constituent un moyen efficace de mettre en œuvre des restrictions qui devraient s'appliquer à une plus grande partie de votre organisation ou de vos unités d'organisation, car lorsqu'elles sont appliquées à la racine ou OU-level qu'elles affectent tous les comptes qui en dépendent.
Astuce
Vous pouvez utiliser les données du dernier accès au service dans IAM pour mettre à jour vos SCP afin de limiter l'accès aux seules données Services AWS dont vous avez besoin. Pour de plus amples informations, consultez Affichage des dernière informations consultées pour Organizations dans le Guide de l'utilisateur IAM.
AWS Organizations attache un SCP AWS géré nommé FullawsAccess àAllow pour n'autoriser que certains services. Vous pouvez choisir de remplacer FullawsAccess à la racine ou à tous les niveaux. Si vous associez une liste d'autorisations (SCP) spécifique à un service à la racine, elle s'applique automatiquement à toutes les unités d'organisation et à tous les comptes sous-jacents, ce qui signifie qu'une seule politique au niveau de la racine détermine la liste d'autorisations de service effective dans l'ensemble de l'organisation, comme indiqué dans le scénario 7. Vous pouvez également supprimer et remplacer FullawsAccess au niveau de chaque unité organisationnelle et de chaque compte, ce qui vous permet de mettre en œuvre des listes d'autorisation de services plus détaillées qui diffèrent selon les unités organisationnelles ou les comptes individuels.
Remarque : le fait de se fier uniquement aux instructions d'autorisation et au modèle implicite de refus par défaut peut entraîner un accès involontaire, car des instructions Allow plus larges ou qui se chevauchent peuvent remplacer les instructions plus restrictives.
L'exemple suivant montre une politique combinant les deux instructions, ce qui empêche les comptes membres de quitter l'organisation et autorise l'utilisation des services AWS souhaités. L'administrateur de l'organisation peut détacher la politique FullAWSAccess et attacher celle-ci à la place.
Pour démontrer comment plusieurs politiques de contrôle des services (SCP) peuvent être appliquées dans une AWS organisation, considérez la structure organisationnelle et les scénarios suivants.
Scénario 1 : Impact des politiques de refus
Ce scénario montre comment les politiques de refus appliquées aux niveaux supérieurs de l'organisation ont un impact sur tous les comptes ci-dessous. Lorsque l'unité d'organisation Sandbox possède à la fois des politiques « AWS Accès complet » et « Refuser l'accès S3 », et que le compte B dispose d'une politique « Refuser l'accès EC2 », le compte B ne peut pas accéder à S3 (depuis le OU-level refus) et à EC2 (depuis son refus au niveau du compte). Le compte A ne dispose pas d'un accès S3 (depuis le OU-level refus).
Scénario 2 : les politiques d'autorisation doivent exister à tous les niveaux
Ce scénario montre comment les politiques d'autorisation fonctionnent dans les SCP. Pour qu'un service soit accessible, il doit y avoir une autorisation explicite à tous les niveaux, depuis le root jusqu'au compte. Dans ce cas, étant donné que l'unité d'organisation Sandbox applique une politique « Autoriser l'accès EC2 », qui n'autorise explicitement que l'accès au service EC2, les comptes A et B auront uniquement accès à EC2.
Scénario 3 : impact de l'absence d'une instruction Allow au niveau de la racine
L'absence d'une instruction « Autoriser » au niveau de la racine dans un SCP constitue une erreur de configuration critique qui bloquera efficacement tout accès aux AWS services et aux actions pour tous les comptes membres de votre organisation.
Scénario 4 : déclarations de refus en couches et autorisations qui en résultent
Ce scénario illustre une structure d'UO profonde à deux niveaux. L'unité d'organisation racine et l'unité d'organisation de charges de travail ont toutes deux un « AWS accès complet », l'unité d'organisation de test dispose d'un « AWS accès complet » avec « Refuser l'accès EC2 » et l'unité d'organisation de production dispose d'un « AWS accès complet ». Par conséquent, le compte D dispose de tous les accès aux services, à l'exception de l'EC2, et les comptes E et F ont tous les accès aux services.
Scénario 5 : Autoriser les politiques du OU-level pour restreindre l'accès au service
Ce scénario montre comment les politiques d'autorisation peuvent être utilisées pour restreindre l'accès à des services spécifiques. L'UO de test applique une politique « Autoriser l'accès EC2 », ce qui signifie que seuls les services EC2 sont autorisés pour le compte D. L'UO de production maintient un « AWS accès complet », de sorte que les comptes E et F ont accès à tous les services. Cela montre comment des politiques d'autorisation plus restrictives peuvent être mises en œuvre OU-level tout en maintenant une autorisation plus large au niveau de la racine.
Scénario 6 : le Root-level refus affecte tous les comptes, indépendamment des autorisations de niveau inférieur
Ce scénario montre qu'une politique de refus au niveau racine affecte tous les comptes de l'organisation, quelles que soient les politiques d'autorisation aux niveaux inférieurs. La racine applique à la fois des politiques « AWS Accès complet » et « Refuser l'accès S3 ». Même si l'unité d'organisation de test applique une politique « Autoriser l'accès au S3 », le refus du S3 au niveau racine a la priorité. Le compte D n'a aucun accès au service car l'unité d'organisation de test autorise uniquement l'accès à S3, mais S3 est refusé au niveau racine. Les comptes E et F peuvent accéder à d'autres services à l'exception de S3 en raison du refus explicite au niveau de la racine.
Scénario 7 : politiques d'autorisation personnalisées au niveau de la racine pour restreindre OU-level l'accès
Ce scénario montre comment les SCP dotés de listes d'autorisation de service explicites fonctionnent lorsqu'ils sont appliqués au niveau de la racine dans un AWS Organizations. Au niveau de la racine de l'organisation, deux SCP « Service Allow » personnalisés sont associés pour autoriser explicitement l'accès à un ensemble limité de AWS services : SCP_1 autorise IAM et Amazon EC2, SCP_2 autorise Amazon S3 et Amazon. CloudWatch Au niveau de l'unité organisationnelle (UO), la politique FullaWSAccess par défaut reste attachée. Cependant, en raison du comportement des intersections, les comptes A et B de ces unités d'organisation ne peuvent accéder qu'aux services explicitement autorisés par le SCP de niveau racine. La politique racine la plus restrictive a la priorité, limitant efficacement l'accès aux seuls IAM, EC2, S3 et CloudWatch aux services, indépendamment des autorisations plus larges accordées aux niveaux organisationnels inférieurs.
