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.
Option 2 : les applications ne peuvent assumer que le rôle autorisé par la politique de confiance
Dans ce scénario, deux certificats ont été fournis AWS Certificate Manager (ACM) AWS Autorité de certification privée et partagés avec les applications nécessitant un accès aux AWS ressources. L'application 1 ne peut assumer que le rôle 1, et l'application 2 ne peut assumer que le rôle 2. Dans la politique de confiance des rôles, vous configurez les champs d'objet du certificat en tant que conditions. Ces conditions permettent à l'application de n'assumer qu'un rôle spécifique. En raison des autorisations de rôle, seule l'application 1 peut accéder au compartiment 1, et seule l'application 2 peut accéder au compartiment 2. L'image suivante montre l'accès dont dispose chaque application.
Dans cette option, vous configurez les politiques de confiance pour les autoriser AssumeRole uniquement lorsque des attributs de certificat spécifiques sont respectés. L'exemple de politique de confiance des rôles montre comment configurer la Condition section pour exiger un nom commun de certificat spécifique (CN), qui est différent pour le rôle 1 et le rôle 2. Chaque application peut assumer un rôle spécifique car elle IAM Roles Anywhere entretient une relation d'ancrage de confiance avec AWS CA privée. Cette approche permet d'empêcher tout accès non autorisé aux rôles et aux données, car l'application ne peut assumer aucun rôle lié au profil cible. Par exemple, vous pouvez séparer les données commerciales dans différents compartiments, configurer des rôles pour autoriser l'accès à un seul de ces compartiments, puis utiliser des contrôles d'accès basés sur des certificats dans la politique de confiance pour définir le rôle que l'application peut assumer.
L'exemple de politique de confiance suivant pour le rôle 1 comporte une condition qui autorise l'attribution d'un rôle uniquement si le nom du certificat est application-1.com et si l'ancre de confiance Amazon Resource Name (ARN) correspond :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "application-1.com" }, "ArnEquals": { "aws:SourceArn": [ "arn:aws:rolesanywhere:<region>:<account-ID>:trust-anchor/<TA_ID>" ] } } } ] }
L'exemple de politique de confiance suivant pour le rôle 2 comporte une condition qui autorise l'attribution d'un rôle uniquement si le nom du certificat est le même application-2.com et si l'ARN de l'ancre de confiance correspond :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "application-2.com" }, "ArnEquals": { "aws:SourceArn": [ "arn:aws:rolesanywhere:<region>:<account-ID>:trust-anchor/<TA_ID>" ] } } } ] }
Pour plus d'informations sur les politiques de confiance des rôles et sur la manière dont vous pouvez modifier ces exemples, consultez la section Politique de confiance dans la IAM Roles Anywhere documentation.
Des exemples de règles relatives aux rôles et aux profils pour les applications 1 et 2 sont inclus dans la section Annexe : Exemples de politiques relatives aux rôles et aux profils de ce guide.