IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する - AWS Identity and Access Management
チュートリアルの概要前提条件ステップ 1: テストユーザーを作成するステップ 2: ABAC ポリシーを作成するステップ 3: ロールを作成するステップ 4: シークレットの作成をテストするステップ 5: シークレットの表示をテストするステップ 6: スケーラビリティをテストするステップ 7: シークレットの更新と削除をテストする[概要]関連リソース

IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する

属性ベースのアクセス制御 (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。これらの属性は、AWS でタグと呼ばれています。タグは、IAM エンティティ (ユーザーまたはロール) を含む IAM リソースと、AWS リソースにアタッチできます。タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。タグを使用して AWS リソースへのアクセスを制御すると、AWS ポリシーの変更を減らしてチームとリソースを拡張できます。ABAC ポリシーは、個々のリソースをリストする従来の AWS ポリシーよりも柔軟性があります。ABAC の詳細と、従来のポリシーに対する利点については、「ABAC 認可で属性に基づいてアクセス許可を定義する」を参照してください。

注記

セッションタグごとに 1 つの値を渡す必要があります。AWS Security Token Service は、複数値を持つセッションタグをサポートしていません。

トピック

チュートリアルの概要

このチュートリアルでは、プリンシパルタグを持つ IAM ロールが、一致するタグを持つリソースにアクセスすることを許可するポリシーを作成およびテストする方法を示します。プリンシパルが AWS にリクエストを行うと、プリンシパルとリソースタグが一致するかどうかに基づいてアクセス許可が付与されます。この戦略により、個人は自分のジョブに必要な AWS リソースのみを表示または編集できます。

シナリオ

Example Corporation という大企業のリーダー開発者であり、経験豊富な IAM 管理者であるとします。IAM ユーザー、ロール、ポリシーの作成と管理に精通しています。開発エンジニアと品質保証チームのメンバーが、必要なリソースにアクセスできるようにする必要があります。また、企業の成長に合わせてスケールする戦略も必要です。

AWS リソースタグと IAM ロールプリンシパルタグを使用して、AWS Secrets Manager で始まるサービスをサポートする ABAC 戦略を実装することを選択します。タグに基づく認可をサポートするサービスについては、「IAM と連携する AWS のサービス」を参照してください。各サービスのアクションおよびリソースを含むポリシーで使用できるタグ付け条件キーについては、「AWS のサービスのアクション、リソース、および条件キー」を参照してください。セッションタグを AWS に渡すよう SAML ベースまたはウェブ ID プロバイダーを設定できます。従業員が AWS にフェデレートすると、その属性が AWS で結果のプリンシパルに適用されます。その後、ABAC を使用して、これらの属性に基づいてアクセス許可を許可または拒否できます。SAML フェデレーティッド ID でのセッションタグの使用とこのチュートリアルとの違いについては、「IAM チュートリアル: ABAC で SAML セッションタグを使用する」を参照してください。

エンジニアリングおよび品質保証チームのメンバーは、[Pegasus] または [Unicorn] のいずれかのプロジェクトに参加しています。次の 3 文字のプロジェクトおよびチームタグ値を選択します。

  • access-project = [Pegasus] プロジェクトの場合は peg

  • access-project = [Unicorn] プロジェクト場合は uni

  • access-team = エンジニアリングチームの場合は eng

  • access-team = 品質保証チームの場合は qas

また、カスタム AWS 請求レポートを有効にするために、cost-center コスト配分タグを要求することを選択します。詳細については、AWS Billing and Cost Managementユーザーガイド の [コスト配分タグの使用] をご参照ください。

主要な機能の概要

  • 従業員は、 ユーザー認証情報を使用してサインインし、チームとプロジェクトの IAM ロールを引き受けます。会社に独自の ID システムがある場合は、従業員が IAM ユーザーなしでロールを引き受けることができるようにフェデレーションを設定できます。詳細については、「IAM チュートリアル: ABAC で SAML セッションタグを使用する」を参照してください。

  • すべてのロールに同じポリシーがアタッチされます。アクションは、タグに基づいて許可または拒否されます。

  • 従業員は、ロールに適用される同じタグをリソースにアタッチする場合に限り、新しいリソースを作成できます。これにより、従業員は作成後にリソースを表示できます。管理者は、新しいリソースの ARN を使用してポリシーを更新する必要がなくなりました。

  • 従業員は、プロジェクトに関係なく、チームが所有するリソースを読み取ることができます。

  • 従業員は、自分のチームとプロジェクトが所有するリソースを更新および削除できます。

  • IAM 管理者は、新しいプロジェクトに新しいロールを追加できます。新しい IAM ユーザーを作成してタグ付けし、適切なロールへのアクセスを許可できます。管理者は、新しいプロジェクトまたはチームメンバーをサポートするためにポリシーを編集する必要はありません。

このチュートリアルでは、各リソースにタグ付けし、プロジェクトロールにタグ付けして、前述の動作を許可するポリシーをロールに追加します。結果として得られるポリシーではロール Create、Read、Update、およびDelete は、同じプロジェクトタグとチームタグが付けられたリソースへのアクセスを許可します。このポリシーでは、同じチームでタグ付けされたリソースに対するクロスプロジェクト Read アクセスも許可されます。

この図は、ロールがプロジェクト外では読み取り専用アクセスに制限されている一方で、自身のプロジェクト内ではリソースを作成、読み取り、更新、および削除するための許可を持つ 2 つのプロジェクトを示しています。

前提条件

このチュートリアルのステップを実行するには、以下を持っている必要があります:

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

  • ステップ 3 でロールを作成するために使用する 12 桁のアカウント ID。

    AWS Management Consoleで AWS アカウント ID 番号を確認するには、ナビゲーションバーの右上にある [サポート] を選択してから、[サポートセンター] を選択します。左側のナビゲーションペインにアカウント番号 (ID) が表示されます。

    アカウント番号を示す AWS Support Center ページ。

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

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

テストでは、同じタグでロールを引き受けるアクセス許可を持つ 4 人の IAM ユーザーを作成します。これにより、チームにユーザーを追加しやすくなります。ユーザーにタグを付けると、ユーザーは正しいロールを引き受けるためのアクセス権を自動的に取得します。ユーザーが 1 つのプロジェクトとチームのみで作業する場合、ロールの信頼ポリシーにユーザーを追加する必要はありません。

  1. そのために、次のカスタマー管理ポリシーを access-assume-role という名前で作成します。JSON ポリシーの作成の詳細については、「IAM ポリシーの作成」を参照してください。

    ABAC ポリシー: すべての ABAC ロールを引き受けるが、ユーザーとロールタグが一致する場合のみ

    次のポリシーでは、ユーザーは、 access- 名前プレフィックスを持つアカウント内の任意のロールを引き受けることを許可します。ロールには、ユーザーと同じプロジェクト、チーム、およびコストセンタータグでタグ付けする必要があります。

    このポリシーを使用するには、イタリック体のプレースホルダーテキストをお客様のアカウント情報と置き換えます。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::account-ID-without-hyphens:role/access-*",
            "Condition": {
                "StringEquals": {
                    "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                    "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                    "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
                }
            }
        }
    ]
}

    このチュートリアルを多数のユーザーにスケールするには、ポリシーをグループにアタッチし、各ユーザーをグループに追加します。詳細については、IAM ユーザーグループを作成するおよびIAM グループのユーザーを編集するを参照してください。

  2. 以下の IAM ユーザーを作成し、access-assume-role アクセス許可ポリシーをアタッチします。[AWS Management Console へのユーザーアクセスを提供] が選択されていることを確認してから、次のタグを追加してください。

    [ユーザーネーム] ユーザータグキー ユーザータグ値

    access-Arnav-peg-eng

    access-project

    access-team

    cost-center

    peg

    eng

    987654

    access-Mary-peg-qas

    access-project

    access-team

    cost-center

    peg

    qas

    987654

    access-Saanvi-uni-eng

    access-project

    access-team

    cost-center

    uni

    eng

    123456

    access-Carlos-uni-qas

    access-project

    access-team

    cost-center

    uni

    qas

    123456

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

access-same-project-team という名前の次のポリシーを作成します。このポリシーは、後のステップでロールに追加します。JSON ポリシーの作成の詳細については、「IAM ポリシーの作成」を参照してください。

このチュートリアルに適応できるその他のポリシーについては、以下のページを参照してください。

ABAC ポリシー: プリンシパルとリソースタグが一致する場合にのみ Access Secrets Manager リソースにアクセスする

次のポリシーでは、リソースの作成、読み取り、編集、削除をプリンシパルに許可しますが、それらのリソースにプリンシパルと同じキーと値のペアがタグ付けされている場合に限ります。プリンシパルがリソースを作成するときに、プリンシパルのタグに一致する値を持つaccess-project、access-team、および cost-center タグを追加する必要があります。このポリシーでは、オプションの Name または OwnedBy タグの追加も許可されます。

{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Sid": "AllActionsSecretsManagerSameProjectSameTeam",
         "Effect": "Allow",
         "Action": "secretsmanager:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
             },
             "ForAllValues:StringEquals": {
                 "aws:TagKeys": [
                     "access-project",
                     "access-team",
                     "cost-center",
                     "Name",
                     "OwnedBy"
                 ]
             },
             "StringEqualsIfExists": {
                 "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
             }
         }
     },
     {
         "Sid": "AllResourcesSecretsManagerNoTags",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:GetRandomPassword",
             "secretsmanager:ListSecrets"
         ],
         "Resource": "*"
     },
     {
         "Sid": "ReadSecretsManagerSameTeam",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:Describe*",
             "secretsmanager:Get*",
             "secretsmanager:List*"
         ],
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
             }
         }
     },
     {
         "Sid": "DenyUntagSecretsManagerReservedTags",
         "Effect": "Deny",
         "Action": "secretsmanager:UntagResource",
         "Resource": "*",
         "Condition": {
             "ForAnyValue:StringLike": {
                 "aws:TagKeys": "access-*"
             }
         }
     },
     {
         "Sid": "DenyPermissionsManagement",
         "Effect": "Deny",
         "Action": "secretsmanager:*Policy",
         "Resource": "*"
     }
 ]
}

このポリシーで行うこと

  • AllActionsSecretsManagerSameProjectSameTeam ステートメントは、リソースタグがプリンシパルタグと一致する場合のみ、関連するすべてのリソースでこのサービスのすべてのアクションを許可します。"Action": "secretsmanager:*" をポリシーに追加することで、ポリシーは Secrets Manager が大きくなるにつれて大きくなります。Secrets Manager が新しい API オペレーションを追加する場合、そのアクションをステートメントに追加する必要はありません。ステートメントは、3 つの条件ブロックを使用して ABAC を実装します。リクエストは、3 つのブロックすべてが true を返す場合にのみ許可されます。

    • 指定されたタグキーがリソースに存在し、その値がプリンシパルのタグと一致する場合、このステートメントの最初の条件ブロックは true を返します。このブロックは、一致しないタグ、またはリソースタグ付けをサポートしていないアクションに対して false を返します。このブロックで許可されていないアクションについては、「AWS Secrets Manager のアクション、リソース、および条件キー」を参照してください。このページは、[Secret] リソースタイプで実行されるアクションが secretsmanager:ResourceTag/tag-key 条件キーをサポートしていることを示しています。一部の Secrets Manager アクションでは、GetRandomPassword や ListSecrets など、そのリソースタイプをサポートしません。これらのアクションを許可するには、追加のステートメントを作成する必要があります。

    • 2 番目の条件ブロックは、リクエストで渡されたすべてのタグキーが指定されたリストに含まれている場合に true を返します。これは、 StringEquals 条件演算子とともに ForAllValues を使用して行われます。キーまたはキーのセットのサブセットが渡されない場合、条件は true を返します。これにより、リクエストでタグを渡すことを許可しない Get* オペレーションが可能になります。リクエスタにリストにないタグキーが含まれている場合、条件は false を返します。リクエストで渡されるすべてのタグキーは、このリストのメンバーと一致する必要があります。詳細については、「複数値のコンテキストキー」を参照してください。

    • 3 番目の条件ブロックは、リクエストでタグの受け渡しがサポートされている場合、3 つすべてのタグが存在する場合、およびプリンシパルタグの値に一致する場合に true を返します。このブロックは、リクエストがタグの受け渡しをサポートしていない場合も true を返します。これは、条件演算子の ...IfExists のおかげです。ブロックは、それをサポートするアクション中に渡されたタグがない場合、またはタグのキーと値が一致しない場合、false を返します。

  • AllResourcesSecretsManagerNoTags ステートメントでは、最初のステートメントでは許可されていない GetRandomPassword および ListSecrets アクションを許可します。

  • ReadSecretsManagerSameTeam ステートメントは、プリンシパルがリソースと同じアクセスチームタグでタグ付けされている場合、読み取り専用オペレーションを許可します。これは、プロジェクトまたはコストセンタータグに関係なく許可されます。

  • DenyUntagSecretsManagerReservedTags ステートメントは、Secrets Manager から「access-」で始まるキーを持つタグを削除するリクエストを拒否します。これらのタグはリソースへのアクセスを制御するために使用されるため、タグを削除するとアクセス許可が削除される可能性があります。

  • DenyPermissionsManagement ステートメントは、Secrets Manager リソースベースのポリシーを作成、編集、または削除することを拒否します。これらのポリシーは、シークレットのアクセス許可を変更するために使用できます。

重要

このポリシーでは、サービスに対するすべてのアクションを許可する戦略が使用されますが、アクセス許可を変更するアクションは明示的に拒否されます。アクションを拒否すると、プリンシパルがそのアクションの実行を許可する他のポリシーよりも優先されます。これにより、意図しない結果が生じる可能性があります。ベストプラクティスとして、明示的な拒否は、そのアクションを許可する状況がない場合にのみ使用します。それ以外の場合、個々のアクションのリストを許可し、不要なアクションはデフォルトで拒否されます。

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

以下の IAM ロールを作成し、前のステップで作成した access-same-project-team ポリシーをアタッチします。IAM ロールの作成の詳細については、「IAM ユーザーにアクセス許可を委任するロールを作成する」を参照してください。IAM ユーザーとロールの代わりにフェデレーションを使用する場合は、「IAM チュートリアル: ABAC で SAML セッションタグを使用する」を参照してください。

ジョブ関数 ロール名 ロールタグ ロールの説明

プロジェクト Pegasus エンジニアリング

access-peg-engineering

access-project = peg

access-team = eng

cost-center = 987654

エンジニアがすべてのエンジニアリングリソースを読み取り、Pegasus エンジニアリングリソースを作成および管理できるようにします。

プロジェクト Pegasus 品質保証

access-peg-quality-assurance

access-project = peg

access-team = qas

cost-center = 987654

QA チームがすべての QA リソースを読み取り、すべての Pegasus QA リソースを作成および管理できるようにします。

プロジェクト Unicorn エンジニアリング

access-uni-engineering

access-project= uni

access-team = eng

cost-center = 123456

 エンジニアがすべてのエンジニアリングリソースを読み取り、Unicorn のエンジニアリングリソースを作成および管理できるようにします。

プロジェクト Unicorn 品質保証

access-uni-quality-assurance

access-project = uni

access-team = qas

cost-center = 123456

QA チームがすべての QA リソースを読み取り、すべての Unicorn QA リソースを作成および管理できるようにします。

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

ロールにアタッチされたアクセス許可ポリシーにより、従業員はシークレットを作成できます。これは、シークレットがプロジェクト、チーム、およびコストセンターでタグ付けされている場合にのみ許可されます。ユーザーとしてサインインし、正しいロールを引き受け、Secrets Manager でアクティビティをテストすることで、アクセス許可が想定どおりに機能していることを確認します。

必要なタグがある場合とない場合のシークレットの作成をテストするには

  1. IAM のユーザー、ロール、ポリシーを確認できるように、メインブラウザウィンドウで、管理者ユーザーとしてサインインしたままにします。テストには、ブラウザの匿名ウィンドウまたは別のブラウザを使用します。そこに、access-Arnav-peg-eng IAM ユーザーをとしてサインインし、https://console.aws.amazon.com/secretsmanager/ で Secrets Manager コンソールを 開きます。

  2. access-uni-engineering ロールへの切り替えを試みます。

    このオペレーションは、access-Arnav-peg-eng ユーザーおよび access-uni-engineering ロールで access-project および cost-center タグ値が一致しないため失敗します。

    AWS Management Consoleでのロールの切り替えの詳細については、「ユーザーから IAM ロールに切り替える (コンソール)」を参照してください。

  3. access-peg-engineering ロールに切り替えます。

  4. 以下の情報を使用して新しいシークレットを保存します。シークレットを保存する方法については、「AWS Secrets Manager ユーザーガイド」の「基本的なシークレットの作成」を参照してください。

    重要

    Secrets Manager は、Secrets Manager と連携する追加の AWS サービスに対する権限がないというアラートを表示します。例えば、Amazon RDS データベースの認証情報を作成するには、RDS インスタンス、RDS クラスター、Amazon Redshift クラスターを記述するアクセス許可が必要です。このチュートリアルではこれらの特定の AWS サービスを使用していないため、これらのアラートは無視してかまいません。

    1. [Select secret type (シークレットタイプの選択)] セクションで、[Other type of secrets (他の種類のシークレット)] を選択します。2 つのテキストボックスに、「test-access-key」と「test-access-secret」と入力します。

    2. [Secret name (シークレット名)] フィールドに「test-access-peg-eng」と入力します。

    3. 次の表から異なるタグの組み合わせを追加し、想定される動作を確認します。

    4. [Store (保存)] を選択して、シークレットの作成を試みます。ストレージに障害が発生した場合は、前の Secrets Manager コンソールページに戻り、以下のテーブルから次のタグセットを使用します。最後のタグセットは許可され、シークレットを正常に作成します。

    次の表は、test-access-peg-eng ロールの ABAC タグの組み合わせを示しています。

    access-project タグ値 access-team タグ値 cost-center タグ値 追加のタグ 予想される動作
    (none) (none) (none) (none) access-project タグの値が peg のロールの値と一致しないため、拒否されました。
    uni eng 987654 (none) access-project タグの値が peg のロールの値と一致しないため、拒否されました。
    peg qas 987654 (none) access-team タグの値が eng のロールの値と一致しないため、拒否されました。
    peg eng 123456 (none) cost-center タグの値が 987654 のロールの値と一致しないため、拒否されました。
    peg eng 987654 Owner = Jane 3 つの必須タグがすべて存在し、その値がロールの値と一致しても、ポリシーで追加のタグ owner が許可されないため、拒否されます。
    peg eng 987654 Name = Jane 3 つの必須タグがすべて存在し、その値がロールの値と一致しているため許可されます。オプションの Name タグを含めることもできます。

  5. サインアウトし、以下の各ロールとタグ値について、この手順の最初の 3 つのステップを繰り返します。この手順の 4 番目のステップでは、欠落しているタグ、オプションのタグ、許可されていないタグ、無効なタグ値のセットをテストします。次に、必要なタグを使用して、次のタグと名前を持つシークレットを作成します。

    [ユーザーネーム] ロール名 シークレット名 シークレットタグ

    access-Mary-peg-qas

    access-peg-quality-assurance

    test-access-peg-qas

    access-project = peg

    access-team = qas

    cost-center = 987654

    access-Saanvi-uni-eng

    access-uni-engineering

    		 test-access-uni-eng

    access-project = uni

    access-team = eng

    cost-center = 123456

    access-Carlos-uni-qas

    access-uni-quality-assurance

    test-access-uni-qas

    access-project = uni

    access-team = qas

    cost-center = 123456

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

各ロールにアタッチしたポリシーにより、従業員はプロジェクトに関係なく、チーム名でタグ付けされたシークレットを表示できます。Secrets Manager でロールをテストして、アクセス許可が想定どおりに動作していることを確認します。

必要なタグがある場合とない場合のシークレットの表示をテストするには

  1. 次のいずれかの IAM ユーザーとしてサインインします。

    • access-Arnav-peg-eng

    • access-Mary-peg-qas

    • access-Saanvi-uni-eng

    • access-Carlos-uni-qas

  2. 一致するロールに切り替えます。

    • access-peg-engineering

    • access-peg-quality-assurance

    • access-uni-engineering

    • access-uni-quality-assurance

    AWS Management Console でのロールの切り替えの詳細については、「ユーザーから IAM ロールに切り替える (コンソール)」を参照してください。

  3. 左側のナビゲーションペインで、メニューアイコンを選択してメニューを展開し、[Secrets (シークレット)]を選択します。

  4. 現在のロールに関係なく、テーブルに 4 つのシークレットすべてが表示されます。これは、access-same-project-team という名前のポリシーですべてのリソースに対して secretsmanager:ListSecrets アクションが許可されるためです。

  5. いずれかのシークレットの名前を選択します。

  6. シークレットの詳細ページで、ロールのタグによって、ページのコンテンツを表示できるかどうかが決まります。ロールの名前とシークレットの名前を比較します。同じチーム名を共有する場合、access-team タグは一致します。一致しない場合、アクセスは拒否されます。

    次のテーブルは、各ロールの ABAC シークレットの表示動作を示しています。

    ロール名 シークレット名 予想される動作
    access-peg-engineering test-access-peg-eng 許可
    test-access-peg-qas 拒否
    test-access-uni-eng 許可
    test-access-uni-qas 拒否
    access-peg-quality-assurance test-access-peg-eng 拒否
    test-access-peg-qas 許可
    test-access-uni-eng 拒否
    test-access-uni-qas 許可
    access-uni-engineering test-access-peg-eng 許可
    test-access-peg-qas 拒否
    test-access-uni-eng 許可
    test-access-uni-qas 拒否
    access-uni-quality-assurance test-access-peg-eng 拒否
    test-access-peg-qas 許可
    test-access-uni-eng 拒否
    test-access-uni-qas 許可

  7. ページの上部にあるパンくずリストから、[Secrets (シークレット)] を選択してシークレットのリストに戻ります。異なるロールを使用して、この手順のステップを繰り返し、各シークレットを表示できるかどうかをテストします。

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

ロールベースのアクセスコントロール (RBAC) よりも属性ベースのアクセスコントロール (ABAC) を使用する重要な理由は、スケーラビリティです。会社が新しいプロジェクト、チーム、または人員を AWS に追加する場合、ABAC 主導のポリシーを更新する必要はありません。例えば、Example Company が [Centaur] という名前の新しいプロジェクトに資金を提供しているとします。Saanvi Sarkar というエンジニアが [Centaur] のリードエンジニアとなり、[ユニコーン] プロジェクトに取り組んでいます。また、Saanvi は Peg プロジェクトの作業も確認します。また、Nikhil Jayashankar をはじめ、[Centaur] プロジェクトのみに取り組む新しく採用されたエンジニアもいます。

新しいプロジェクトを AWS に追加するには

  1. IAM 管理者ユーザーとしてサインインし、IAM コンソール (https://console.aws.amazon.com/iam/。

  2. 左側のナビゲーションペインで、[ロール] を選択し、access-cen-engineering という名前の IAM ロールを追加します。access-same-project-team アクセス許可ポリシーをロールにアタッチし、次のロールタグを追加します。

    • access-project = cen

    • access-team = eng

    • cost-center = 101010

  3. 左側のナビゲーションペインで、[ユーザー] を選択します。

  4. access-Nikhil-cen-eng という名前の新しいユーザーを追加し、access-assume-role という名前のポリシーをアタッチして、次のユーザータグを追加します。

    • access-project = cen

    • access-team = eng

    • cost-center = 101010

  5. 「ステップ 4: シークレットの作成をテストする」および「ステップ 5: シークレットの表示をテストする」の手順を使用します。別のブラウザウィンドウで、Nikhil が [Centaur] エンジニアリングシークレットのみを作成できること、および Nikhil がすべてのエンジニアリングシークレットを表示できることをテストします。

  6. 管理者としてサインインしたメインブラウザウィンドウで、ユーザー access-Saanvi-uni-eng を選択します。

  7. [Permissions (アクセス許可)] タブで、[access-assume-role] アクセス許可ポリシーを削除します。

  8. access-assume-specific-roles という名前の次のインラインポリシーを追加します。ユーザーへのインラインポリシーの追加の詳細については、「ユーザーまたはロールのインラインポリシーを埋め込むには (コンソール)」を参照してください。

    ABAC ポリシー: 特定のロールのみ継承する

    このポリシーでは、Saanvi が Pegasus および Centaur プロジェクトのエンジニアリングロールを引き受けることを許可します。IAM は複数値タグをサポートしていないため、このカスタムポリシーを作成する必要があります。Saanvi のユーザーに access-project = peg および access-project = cen のタグを付けることはできません。さらに、AWS 認可モデルが両方の値に一致することはできません。詳細については、「IAM および AWS STS でのタグ付けの規則」を参照してください。代わりに、引き受けることができる 2 つのロールを手動で指定する必要があります。

    このポリシーを使用するには、イタリック体のプレースホルダーテキストをお客様のアカウント情報と置き換えます。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeSpecificRoles",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
                "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
            ]
        }
    ]
}

  9. 「ステップ 4: シークレットの作成をテストする」および「ステップ 5: シークレットの表示をテストする」の手順を使用します。別のブラウザウィンドウで、Saanvi が両方のロールを引き受けることができることを確認します。ロールのタグに応じて、プロジェクト、チーム、およびコストセンターのみのシークレットを作成できることを確認します。また、作成したばかりのシークレットを含め、エンジニアリングチームが所有するすべてのシークレットに関する詳細を表示できることを確認します。

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

ロールにアタッチされた access-same-project-team ポリシーにより、従業員はプロジェクト、チーム、コストセンターでタグ付けされたシークレットを更新および削除できます。Secrets Manager でロールをテストして、アクセス許可が想定どおりに動作していることを確認します。

必要なタグの有無にかかわらず、シークレットの更新と削除をテストするには

  1. 次のいずれかの IAM ユーザーとしてサインインします。

    • access-Arnav-peg-eng

    • access-Mary-peg-qas

    • access-Saanvi-uni-eng

    • access-Carlos-uni-qas

    • access-Nikhil-cen-eng

  2. 一致するロールに切り替えます。

    • access-peg-engineering

    • access-peg-quality-assurance

    • access-uni-engineering

    • access-peg-quality-assurance

    • access-cen-engineering

    AWS Management Console でのロールの切り替えの詳細については、「ユーザーから IAM ロールに切り替える (コンソール)」を参照してください。

  3. ロールごとに、シークレットの説明を更新し、次のシークレットを削除してみてください。詳細については、「AWS Secrets Manager ユーザーガイド」の「シークレットの変更」および「シークレットの削除と復元」を参照してください。

    次のテーブルは、各ロールの ABAC シークレットの更新と削除動作を示しています。

    ロール名 シークレット名 予想される動作

    access-peg-engineering

    test-access-peg-eng

    		 許可
    test-access-uni-eng 拒否
    test-access-uni-qas 拒否

    access-peg-quality-assurance

    		 test-access-peg-qas 許可
    test-access-uni-eng 拒否

    access-uni-engineering

    		 test-access-uni-eng 許可
    test-access-uni-qas 拒否

    access-peg-quality-assurance

    		 test-access-uni-qas 許可

[概要]

これで、属性ベースのアクセスコントロール (ABAC) のタグを使用するために必要なすべてのステップが正常に完了しました。タグ付け戦略を定義する方法を学びました。この戦略をプリンシパルとリソースに適用しました。Secrets Manager の戦略を適用するポリシーを作成して適用しました。また、ABAC は、新しいプロジェクトやチームメンバーを追加すると簡単にスケールできることも学びました。その結果、テストロールを使用して IAM コンソールにサインインし、AWS で ABAC のタグを使用する方法を体験できます。

注記

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

関連情報については、以下のリソースを参照してください。

アカウントのタグをモニタリングする方法については、「サーバーレスワークフローおよび Amazon CloudWatch Events を使用して AWS リソースでタグの変更を監視する」を参照してください。