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.

Contrôlez l'accès à AWS STS avec des politiques de point de terminaison VPC

Lorsque vous créez un point de terminaison VPC d'interface pour AWS Security Token Service (AWS STS), vous pouvez y associer une politique de point de terminaison. La politique contrôle les principaux autorisés à utiliser le point de terminaison et les AWS STS actions qu'ils peuvent effectuer. Si vous n'attachez pas de politique, le point de terminaison utilise la politique par défaut qui autorise un accès illimité à toutes les AWS STS actions pour tous les principaux.

Les politiques relatives aux points de terminaison VPC n'accordent pas d'autorisations à elles seules. Ils constituent une limite supplémentaire qui fonctionne parallèlement aux autres politiques. La politique du point de terminaison et les politiques applicables de l'appelant doivent autoriser une demande pour qu'elle aboutisse.

Pour plus d'informations sur les politiques relatives aux points de terminaison VPC, consultez la section Contrôler l'accès aux points de terminaison VPC à l'aide des politiques relatives aux points de terminaison dans le guide de l'utilisateur Amazon VPC.

Politique de point de terminaison d'un VPC par défaut

Si vous n'attachez pas de politique personnalisée lorsque vous créez le point de terminaison, AWS associez la stratégie par défaut suivante. Cette politique permet un accès illimité au point de terminaison.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Pour limiter l'accès au point de terminaison, associez une politique de point de terminaison personnalisée.

Considérations importantes pour AWS STS Politiques de point de terminaison d’un VPC

AWS STS gère les demandes provenant de deux types d'appelants fondamentalement différents. Votre politique de point de terminaison VPC doit prendre en compte les deux types afin d'éviter de bloquer involontairement les demandes légitimes.

Comment ? AWS STS évalue les politiques relatives aux points de terminaison VPC pour les appelants fédérés

Lorsqu'un appelant fédéré invoque AssumeRoleWithSAML ou via AssumeRoleWithWebIdentity un point de terminaison VPC, les règles suivantes s'appliquent :

Nous vous recommandons d'utiliser aws:ResourceOrgID ou aws:ResourceAccount de rédiger des déclarations de politique relatives aux points de terminaison VPC qui doivent s'appliquer aux appelants fédérés, car ces appelants ne disposent pas de clés de condition basées sur le principal.

Clés de condition disponibles pour AWS STS Politiques de point de terminaison d’un VPC

Le tableau suivant présente les clés de condition couramment utilisées et leur disponibilité dans le contexte des demandes pour chaque type d'appelant lors de l'envoi de demandes via un point de terminaison AWS STS VPC. Des clés de condition supplémentaires sont disponibles en plus de celles répertoriées ici.

Exemple : Tout autoriser AWS STS actions pour votre organisation

La politique de point de terminaison suivante limite votre point de terminaison AWS STS VPC à votre organisation tout en prenant en charge l'accès fédéré. Il autorise toutes les AWS STS actions pour les principaux authentifiés de votre organisation et permet séparément aux appelants fédérés d'assumer des rôles au sein de votre organisation. Les appelants fédérés (AssumeRoleWithSAMLetAssumeRoleWithWebIdentity) ont besoin d'une déclaration distincte car ils n'en ont pas aws:PrincipalOrgID dans le contexte de la demande.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowOrganizationPrincipals",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-exampleorgid"
                }
            }
        },
        {
            "Sid": "AllowFederatedAssumeRole",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:AssumeRoleWithWebIdentity"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceOrgID": "o-exampleorgid"
                }
            }
        }
    ]
}

La première instruction utilise "Principal": {"AWS": "*"} with aws:PrincipalOrgID pour autoriser l'authentification AWS des principaux de votre organisation. La deuxième instruction est utilisée "Principal": "*" pour faire correspondre les appelants fédérés et limite le rôle cible à l'utilisation de votre organisation. aws:ResourceOrgID La politique de confiance du rôle reste le principal critère permettant de déterminer quelles identités fédérées peuvent assumer quels rôles.

Pour plus d'informations sur la mise en œuvre de contrôles de périmètre réseau, consultez la section Création d'un périmètre de données sur AWS et les exemples de politique de périmètre de données sur le GitHub site Web.

Exemple : Tout autoriser AWS STS actions pour des comptes spécifiques

La politique de point de terminaison suivante autorise toutes les AWS STS actions pour les principaux sur des comptes spécifiques. Utilisez cette politique lorsque vos comptes ne font pas partie d'une organisation. Les appelants fédérés sont autorisés dans une déclaration séparée car ils n'en ont pas aws:PrincipalAccount dans le contexte de la demande.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificAccountPrincipals",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalAccount": [
                        "111122223333",
                        "444455556666"
                    ]
                }
            }
        },
        {
            "Sid": "AllowFederatedAssumeRole",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:AssumeRoleWithWebIdentity"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceAccount": [
                        "111122223333",
                        "444455556666"
                    ]
                }
            }
        }
    ]
}

La première instruction utilise "Principal": {"AWS": "*"} with aws:PrincipalAccount pour autoriser les AWS principaux authentifiés à partir des comptes spécifiés. La deuxième instruction est utilisée "Principal": "*" pour faire correspondre les appelants fédérés et limite le rôle cible aux mêmes comptes utilisant. aws:ResourceAccount La politique de confiance du rôle reste le principal critère permettant de déterminer quelles identités fédérées peuvent assumer quels rôles.

Exemple : Restreindre à un élément spécifique AWS STS actions

La politique de point de terminaison suivante n'autorise que AssumeRole les principaux authentifiés et AssumeRoleWithSAML les appelants fédérés, tous deux limités à des rôles au sein de votre organisation.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAssumeRoleByOrgPrincipals",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:AssumeRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-exampleorgid"
                }
            }
        },
        {
            "Sid": "AllowSAMLFederation",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "sts:AssumeRoleWithSAML",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceOrgID": "o-exampleorgid"
                }
            }
        }
    ]
}

Cette politique bloque d'autres AWS STS actions telles que GetCallerIdentityGetSessionToken, et AssumeRoleWithWebIdentity via ce point de terminaison. Ajustez les Action éléments en fonction de vos besoins.

Exemple : refuser l'accès à une organisation non organisationnelle tout en autorisant la fédération

La politique de point de terminaison suivante utilise un refus explicite pour bloquer les principaux authentifiés extérieurs à votre organisation, tout en préservant l'accès pour les appelants fédérés. Cette approche commence par une autorisation générale et ajoute une déclaration de refus ciblée.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAll",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Sid": "DenyNonOrgPrincipals",
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:PrincipalOrgID": "o-exampleorgid"
                }
            }
        }
    ]
}

L'instruction deny utilise"Principal": {"AWS": "*"}, ce qui l'étend aux AWS principaux authentifiés uniquement. Les appelants fédérés (SAML et OIDC) ne sont pas AWS des principaux et ne sont pas concernés par cet Principal élément. Le refus ne s'applique donc pas à eux. Cette approche évite d'avoir à recourir à des conditions complexes Null ou à Bool des conditions pour définir des exceptions pour les appelants fédérés.