IAM チュートリアル: ABAC で SAML セッションタグを使用する - AWS Identity and Access Management
前提条件ステップ 1: テストユーザーを作成するステップ 2: ABAC ポリシーを作成するステップ 3: SAML ロールを作成して設定するステップ 4: シークレットの作成をテストするステップ 5: シークレットの表示をテストするステップ 6: スケーラビリティをテストするステップ 7: シークレットの更新と削除をテストする概要

IAM チュートリアル: ABAC で SAML セッションタグを使用する

属性ベースのアクセスコントロール (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。AWS では、これらの属性はタグと呼ばれます。タグは、IAM エンティティ (ユーザーまたはロール) を含む IAM リソースと、AWS リソースにアタッチできます。エンティティが AWS へのリクエストを行うために使用されると、エンティティはプリンシパルになり、プリンシパルにはタグが含まれます。

ロールを引き受けるとき、またはユーザーをフェデレートするときに セッションタグ を渡すこともできます。その後、タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。タグを使用して AWS リソースへのアクセスを制御すると、AWS ポリシーの変更を減らしてチームとリソースを拡張できます。ABAC ポリシーは、個々のリソースをリストする従来の AWS ポリシーよりも柔軟性があります。ABAC の詳細と、従来のポリシーに対する利点については、「AWS の ABAC とは」を参照してください。

会社で SAML ベースの ID プロバイダー (IdP) を使用して企業ユーザー ID を管理する場合は、SAML 属性を使用して、AWS のきめ細かなアクセス制御を行うことができます。属性には、コストセンター ID、ユーザーの E メールアドレス、部門分類、およびプロジェクト割り当てを含めることができます。これらの属性をセッションタグとして渡すと、これらのセッションタグに基づいて AWS へのアクセスを制御できます。

SAML 属性をセッションプリンシパルに渡して ABAC チュートリアル を完了するには、このトピックに含まれる変更を使用して「IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する」のタスクを実行します。

前提条件

ABAC で SAML セッションタグを使用するステップを実行するには、次のものが必要です。

  • 特定の属性を持つテストユーザーを作成できる SAML ベースの IdP へのアクセス。

  • 管理者アクセス許可を持つユーザーとしてサインインできること。

  • AWS Management Console での IAM ユーザー、ロール、ポリシーの作成と編集の経験。ただし、IAM 管理プロセスの記憶にサポートが必要な場合は、ABAC チュートリアルでは、ステップバイステップの手順を参照できるリンクを提供します。

  • IAM で SAML ベースの IdP を設定した経験があります。詳細および詳細 IAM ドキュメントへのリンクを表示するには、「AssumeRoleWithSAML を使用したセッションタグの受け渡し」を参照してください。

ステップ 1: テストユーザーを作成する

ステップ 1: テストユーザーを作成する の手順に従います。ID はプロバイダーで定義されるため、従業員の IAM ユーザーを追加する必要はありません。

ステップ 2: ABAC ポリシーを作成する

ステップ 2: ABAC ポリシーを作成する の手順に従って、IAM で指定した管理ポリシーを作成します。

ステップ 3: SAML ロールを作成して設定する

SAML の ABAC チュートリアルを使用する場合は、追加のステップを実行し、ロールを作成します。SAML IdP を設定し、AWS Management Console アクセスを有効にする必要があります。詳細については、「ステップ 3: ロールを作成する」を参照してください。

ステップ 3A: SAML ロールを作成する

SAML ID プロバイダーと、ステップ 1 で作成した test-session-tags ユーザーを信頼する 1 つのロールを作成します。ABAC チュートリアルでは、異なるロールタグを持つ個別のロールを使用します。SAML IdP からセッションタグを渡すため、必要なロールは 1 つだけです。SAML ベースのロールを作成する方法については、「SAML 2.0 フェデレーション用のロールを作成する (コンソール)」を参照してください。

ロールに access-session-tags という名前を付けます。access-same-project-team アクセス許可ポリシーをロールにアタッチします。ロールの信頼ポリシーを編集して、次のポリシーを使用します。ロールの信頼関係を編集する方法の詳細については、「ロールの修正 (コンソール)」を参照してください。

次のロール信頼ポリシーでは、SAML ID プロバイダーと test-session-tags ユーザーがロールを引き受けることができます。ロールを引き受けるときは、指定した 3 つのセッションタグを渡す必要があります。sts:TagSession アクションは、セッションタグを渡すことを許可するために必要です。

{
    "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"}
            }
        }
    ]
}

この AllowSamlIdentityAssumeRoleステートメントにより、エンジニアリングチームおよび品質保証チームのメンバーは、Example Corporation IdP から AWS にフェデレーションするときに、このロールを引き受けることができます。ExampleCorpProvider SAML プロバイダーは IAM で定義されています。管理者は、必要な 3 つのセッションタグを渡すように SAML アサーションをすでに設定しています。アサーションは追加のタグを渡すことができますが、これら 3 つは存在する必要があります。ID の属性は、cost-center タグと access-project タグに対して任意の値を持つことができます。ただし、access-team 属性値は、ID がエンジニアリングチームまたは品質保証チームにあることを示す eng か qas に一致する必要があります。

ステップ 3B: SAML IdP を設定する

cost-center、access-project、access-team の各属性をセッションタグとして渡すように SAML IdP を設定します。詳細については、「AssumeRoleWithSAML を使用したセッションタグの受け渡し」を参照してください。

これらの属性をセッションタグとして渡すには、SAML アサーションに以下の要素を含めます。

<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>

ステップ 3C: コンソールアクセスを有効にする

フェデレーティッド SAML ユーザーのコンソールアクセスを有効にします。詳細については、「SAML 2.0 フェデレーティッドユーザーが AWS Management Consoleにアクセス可能にする」を参照してください。

ステップ 4: シークレットの作成をテストする

access-session-tags ロールを使用して AWS Management Console にフェデレートします。詳細については、「SAML 2.0 フェデレーティッドユーザーが AWS Management Consoleにアクセス可能にする」を参照してください。次に、ステップ 4: シークレットの作成をテストする の手順に従ってシークレットを作成します。属性を持つ異なる SAML ID を使用して、ABAC チュートリアルで示されているタグと一致させます。詳細については、「ステップ 4: シークレットの作成をテストする」を参照してください。

ステップ 5: シークレットの表示をテストする

ステップ 5: シークレットの表示をテストする の手順に従って、前のステップで作成したシークレットを表示します。属性を持つ異なる SAML ID を使用して、ABAC チュートリアルで示されているタグと一致させます。

ステップ 6: スケーラビリティをテストする

ステップ 6: スケーラビリティをテストする の指示に従って、スケーラビリティをテストします。これを行うには、SAML ベースの IdP に次の属性を持つ新しい ID を追加します。

  • cost-center = 101010

  • access-project = cen

  • access-team = eng

ステップ 7: シークレットの更新と削除をテストする

「ステップ 7: シークレットの更新と削除をテストする」の手順に従って、シークレットを更新および削除します。属性を持つ異なる SAML ID を使用して、ABAC チュートリアルで示されているタグと一致させます。

重要

課金されないように、作成したシークレットをすべて削除します。Secrets Manager の料金設定の詳細については、「AWS Secrets Manager 料金設定」を参照してください。

概要

これで、アクセス許可の管理に SAML セッションタグとリソースタグを使用するために必要なすべてのステップが正しく完了しました。

注記

特定の条件下でのみアクションを許可するポリシーを追加しました。より広範なアクセス許可を持つユーザーまたはロールに別のポリシーを適用する場合、アクションはタグ付けを必要とするだけではないことがあります。例えば、AdministratorAccess AWS 管理ポリシーを使用してユーザーに完全な管理アクセス許可を付与しても、これらのポリシーではそのアクセスが制限されません。複数のポリシーが関係する場合のアクセス許可の決定方法の詳細については、「アカウント内でのリクエストの許可または拒否の決定」を参照してください。