IAMtutoriel : Utiliser les balises de SAML session pour ABAC

Le contrôle d'accès basé sur les attributs (ABAC) est une stratégie d'autorisation qui définit les autorisations en fonction des attributs. Dans AWS, ces attributs sont appelés balises. Vous pouvez associer des balises aux IAM ressources, y compris aux IAM entités (utilisateurs ou rôles), et aux AWS ressources. Lorsque les entités sont utilisées pour envoyer des demandes AWS, elles deviennent des entités principales et ces entités incluent des balises.

Vous pouvez également transmettre des balises de session lorsque vous endossez un rôle ou fédérez un utilisateur. Vous pouvez ensuite définir des politiques qui utilisent des clés de condition de balise pour accorder des autorisations à vos principaux en fonction de leurs balises. Lorsque vous utilisez des balises pour contrôler l'accès à vos ressources AWS , vous autorisez vos équipes et vos ressources à se développer en modifiant moins les politiques AWS . ABACles politiques sont plus flexibles que AWS les politiques traditionnelles, qui vous obligent à répertorier chaque ressource individuelle. Pour plus d'informations sur les politiques traditionnelles ABAC et leurs avantages par rapport aux politiques traditionnelles, consultezDéfinissez les autorisations en fonction des attributs avec ABAC autorisation.

Si votre entreprise utilise un fournisseur d'identité (IdP) SAML basé sur un fournisseur d'identité pour gérer les identités des utilisateurs d'entreprise, vous pouvez utiliser des SAML attributs pour un contrôle d'accès précis dans. AWS Les attributs peuvent inclure des identifiants de centre de coûts, des adresses e-mail d'utilisateurs, des classifications de services et des affectations de projet. Lorsque vous transmettez ces attributs en tant qu’étiquettes de session, vous pouvez ensuite contrôler l'accès à l’interface AWS en fonction de ces étiquettes de session.

Pour terminer le ABACdidacticiel en transmettant des SAML attributs au directeur de votre session, effectuez les tâches dansIAMtutoriel : Définir les autorisations d'accès aux AWS ressources en fonction des balises, avec les modifications incluses dans cette rubrique.

Prérequis

Pour effectuer les étapes d'utilisation des balises de SAML session pourABAC, vous devez déjà disposer des éléments suivants :

• Accès à un IdP SAML basé sur lequel vous pouvez créer des utilisateurs de test dotés d'attributs spécifiques.

• La possibilité de se connecter en tant qu'utilisateur disposant d'autorisations d'administrateur.

• Expérience en matière de création et de modification d'IAMutilisateurs, de rôles et de politiques dans le AWS Management Console. Toutefois, si vous avez besoin d'aide pour vous souvenir d'un processus de IAM gestion, le ABAC didacticiel fournit des liens permettant de consulter step-by-step les instructions.

• Découvrez la configuration d'un IdP SAML basé dans. IAM Pour plus de détails et des liens vers une IAM documentation détaillée, voirTransmission de balises de session en utilisant AssumeRoleWith SAML.

Étape 1 : Créer des utilisateurs test

Ignorez les instructions de la section Étape 1 : Créer des utilisateurs test. Vos identités étant définies dans votre fournisseur, il n'est pas nécessaire d'ajouter des IAM utilisateurs à vos employés.

Étape 2 : Création de la ABAC politique

Suivez les instructions Étape 2 : Création de la ABAC politique pour créer la politique gérée spécifiée dansIAM.

Étape 3 : créer et configurer le SAML rôle

Lorsque vous utilisez le ABAC didacticiel pourSAML, vous devez effectuer des étapes supplémentaires pour créer le rôle, configurer l'SAMLIdP et activer AWS Management Console l'accès. Pour de plus amples informations, veuillez consulter Étape 3 : Créer les rôles.

Étape 3A : Création du SAML rôle

Créez un rôle unique qui fait confiance à votre fournisseur SAML d'identité et à l'test-session-tagsutilisateur que vous avez créé à l'étape 1. Le ABAC didacticiel utilise des rôles distincts dotés de différentes balises de rôle. Comme vous transmettez des balises de session depuis votre SAML IdP, vous n'avez besoin que d'un seul rôle. Pour savoir comment créer un rôle SAML basé, consultezCréation d'un rôle pour la fédération SAML 2.0 (console).

Nommez le rôle access-session-tags. Attachez la politique d'autorisation access-same-project-team au rôle. Modifiez la politique d'approbation de rôle pour utiliser la politique suivante. Pour obtenir des instructions détaillées sur la modification de la relation d'approbation d'un rôle, veuillez consulter Mettre à jour une politique de confiance dans les rôles .

La politique de confiance des rôles suivante permet à votre fournisseur SAML d'identité et à l'test-session-tagsutilisateur d'assumer le rôle. Lorsqu'ils endossent le rôle, ils doivent transmettre les trois balises de session spécifiées. L'action sts:TagSession est requise pour autoriser la transmission des balises de session.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSamlIdentityAssumeRole",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"},
            "Condition": {
                "StringLike": {
                    "aws:RequestTag/cost-center": "*",
                    "aws:RequestTag/access-project": "*",
                    "aws:RequestTag/access-team": [
                        "eng",
                        "qas"
                    ]
                },
                "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
            }
        }
    ]
}

La AllowSamlIdentityAssumeRole déclaration permet aux membres des équipes d'ingénierie et d'assurance qualité d'assumer ce rôle lorsqu'ils se fédérent avec l'IdP AWS d'Example Corporation. Le ExampleCorpProvider SAML fournisseur est défini dansIAM. L'administrateur a déjà configuré l'SAMLassertion pour transmettre les trois balises de session requises. L'assertion peut transmettre des balises supplémentaires, mais ces trois balises doivent être présentes. Les attributs de l'identité peuvent avoir n'importe quelle valeur pour les balises cost-center et access-project. Toutefois, la valeur de l'attribut access-team doit correspondre à eng ou qas pour indiquer que l'identité se trouve dans l'équipe d'ingénierie ou d'assurance qualité.

Étape 3B : Configuration de l'SAMLIdP

Configurez votre SAML IdP pour transmettre les access-team attributs cost-centeraccess-project, et sous forme de balises de session. Pour de plus amples informations, veuillez consulter Transmission de balises de session en utilisant AssumeRoleWith SAML.

Pour transmettre ces attributs sous forme de balises de session, incluez les éléments suivants dans votre SAML assertion.

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:cost-center">
  <AttributeValue>987654</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-project">
  <AttributeValue>peg</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-team">
  <AttributeValue>eng</AttributeValue>
</Attribute>

Étape 3C : Activer l'accès à la console

Activez l'accès à la console pour vos SAML utilisateurs fédérés. Pour de plus amples informations, veuillez consulter Permettre aux utilisateurs fédérés SAML 2.0 d'accéder au AWS Management Console.

Étape 4 : Tester la création de secrets

Fédérez-vous pour AWS Management Console utiliser le access-session-tags rôle. Pour de plus amples informations, veuillez consulter Permettre aux utilisateurs fédérés SAML 2.0 d'accéder au AWS Management Console. Puis, suivez les instructions de la section Étape 4 : Tester la création de secrets pour créer des secrets. Utilisez différentes SAML identités avec des attributs correspondant aux balises indiquées dans le ABAC didacticiel. Pour de plus amples informations, veuillez consulter Étape 4 : Tester la création de secrets.

Étape 5 : Tester l'affichage des secrets

Suivez les instructions de la section Étape 5 : Tester l'affichage des secrets pour afficher les secrets que vous avez créés à l'étape précédente. Utilisez différentes SAML identités avec des attributs correspondant aux balises indiquées dans le ABAC didacticiel.

Étape 6 : Tester l'adaptabilité

Suivez les instructions de la section Étape 6 : Tester l'adaptabilité pour tester l'évolutivité. Pour ce faire, ajoutez une nouvelle identité dans votre IdP SAML basé avec les attributs suivants :

• cost-center = 101010

• access-project = cen

• access-team = eng

Étape 7 : Tester la mise à jour et la suppression des secrets

Suivez les instructions de l'étape Étape 7 : Tester la mise à jour et la suppression des secrets pour mettre à jour et supprimer des secrets. Utilisez différentes SAML identités avec des attributs correspondant aux balises indiquées dans le ABAC didacticiel.

Important

Supprimez tous les secrets que vous avez créés pour éviter les frais de facturation. Pour de plus amples informations sur la tarification de Secrets Manager, veuillez consulter Tarification AWS Secrets Manager.

Récapitulatif

Vous avez maintenant effectué avec succès toutes les étapes nécessaires à l'utilisation des balises de SAML session et des balises de ressources pour la gestion des autorisations.

Note

Vous avez ajouté des politiques qui autorisent les actions uniquement dans des conditions spécifiques. Si vous appliquez une politique différente à vos utilisateurs ou rôles disposant d'autorisations plus larges, il se peut que les actions ne soient pas limitées pour demander le balisage. Par exemple, si vous accordez à un utilisateur des autorisations administratives complètes à l'aide de la politique AdministratorAccess AWS gérée, ces politiques ne limitent pas cet accès. Pour plus d'informations sur la façon dont les autorisations sont déterminées lorsque plusieurs politiques sont impliquées, veuillez consulter Identification d'une demande autorisée ou refusée dans un compte.