概要
AWS Secrets Managerで管理するシークレットへのアクセスを、限られたIAMプリンシパルに制限したいケースがあります。たとえば、データベースの接続情報をチームごとに管理し、各チームのメンバーだけが自チームのシークレットにアクセスできるようにする場面です。
このとき、アクセス対象のプリンシパル（ユーザーやロール）が頻繁に変更される環境では、IAMポリシーのARNをその都度書き換える運用は管理負荷が高く、スケーラビリティに欠けます。メンバーの異動や追加のたびにポリシーを修正し、レビューし、適用するという作業が発生するためです。
この課題を解決するのが ABAC（Attribute-Based Access Control: 属性ベースアクセス制御） です。ABACでは、IAMプリンシパルとリソースの双方にタグ（属性）を付与し、「タグの値が一致する場合にのみアクセスを許可する」というポリシーを記述します。プリンシパルの追加・変更時はタグを設定するだけでよく、ポリシー自体の変更は不要です。
本記事では、Secrets Managerのリソースポリシーとタグベースの条件キー（aws:PrincipalTag、aws:ResourceTag）を組み合わせたABACの仕組みを解説し、実際にAWSコンソールで設定・動作確認を行います。
クラウドおさるチームのメンバーが入れ替わっても、ポリシーを書き換えずにシークレットへのアクセスを保てるか。タグの一致でアクセスを決める ABAC を、Secrets Manager で確かめる記事でござる。
この記事のメリット
- RBAC（ロールベース）とABAC（属性ベース）のアクセス制御の違いを理解し、ABACが適するユースケースを判断できるようになる
aws:PrincipalTagとaws:ResourceTagの条件キーの使い方を正確に把握できる- Secrets Managerのリソースポリシーを使ったタグベースアクセス制御を実装できるようになる
- プリンシパルが頻繁に変更される環境でも、ポリシー変更なしでアクセス制御を維持する設計を習得できる
- SCS試験でABACやタグベースのアクセス制御に関する問いに正確に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
RBACとABACの違い
AWSにおけるアクセス制御のアプローチは、大きく RBAC（Role-Based Access Control） と ABAC（Attribute-Based Access Control） の2つに分けられます。
| 項目 | RBAC（ロールベース） | ABAC（属性ベース） |
|---|---|---|
| アクセス制御の基準 | プリンシパルが引き受けるロールやグループ | プリンシパルとリソースに付与されたタグ（属性） |
| ポリシーの記述 | ロールやグループごとに個別のポリシーを作成 | タグの一致条件を記述した汎用的なポリシーを作成 |
| プリンシパル追加時の対応 | ロール・グループへの割り当てとポリシーの追加・修正 | タグの付与のみ（ポリシーの変更は不要） |
| スケーラビリティ | プロジェクト・チーム数の増加に伴いポリシー数が増加 | ポリシー数は一定のまま、タグで制御範囲を拡張可能 |
| 管理の柔軟性 | 静的な割り当てが中心 | 動的な変更に柔軟に対応できる |
RBACは「誰であるか（どのロールに属するか）」に基づいてアクセスを制御します。一方、ABACは「どのような属性を持っているか」に基づいて制御します。プリンシパルが頻繁に変更される環境や、プロジェクト・チームの数が多い環境では、ABACの方がポリシー管理のコストを抑えられます。
aws:PrincipalTag と aws:ResourceTag
ABACを実現するために使用する主な条件キーは以下の2つです。
aws:PrincipalTag
aws:PrincipalTag/<タグキー> は、APIリクエストを行うプリンシパル（IAMユーザーやIAMロール）に付与されたタグの値を参照する条件キーです。
"Condition": {
"StringEquals": {
"aws:PrincipalTag/Team": "database-admin"
}
}この条件は、リクエストを行うプリンシパルに Team=database-admin というタグが付与されている場合に一致します。
aws:ResourceTag
aws:ResourceTag/<タグキー> は、アクセス対象のリソースに付与されたタグの値を参照する条件キーです。
"Condition": {
"StringEquals": {
"aws:ResourceTag/Team": "database-admin"
}
}この条件は、アクセス対象のリソースに Team=database-admin というタグが付与されている場合に一致します。
タグの一致条件を組み合わせる
ABACの真価は、この2つを組み合わせて「プリンシパルのタグとリソースのタグが一致する場合にのみ許可する」という条件を記述できる点にあります。
"Condition": {
"StringEquals": {
"aws:PrincipalTag/Team": "${aws:ResourceTag/Team}"
}
}この条件は、プリンシパルの Team タグとリソースの Team タグの値が一致する場合に一致します。たとえば、プリンシパルに Team=database-admin が付与されており、シークレットにも Team=database-admin が付与されていればアクセスが許可されます。
クラウドおさるaws:PrincipalTag は呼び出す側、aws:ResourceTag はアクセスされる側のタグでござるな。猿山のバナナ倉庫も、猿の首札と倉庫の札の色がそろえば入れる決まりにしておけば、新入りには札を渡すだけで、決まりそのものは書き換えずに済むのでござる。
Secrets Managerのリソースポリシー
Secrets Managerのシークレットには、IAMポリシー（アイデンティティベースポリシー）に加えて リソースポリシー を設定できます。リソースポリシーはシークレット側に直接アタッチするポリシーで、「このシークレットに誰がアクセスできるか」を定義します。
リソースポリシーを使うメリットは以下の通りです。
- IAMポリシーを変更せずに、シークレット側でアクセス制御を追加できる
- クロスアカウントアクセスの許可が可能
- タグベースの条件と組み合わせることで、動的なアクセス制御を実現できる
アクセス制御方式の比較
Secrets Managerのシークレットへのアクセスを制限する方式として、以下の4つが考えられます。
| 方式 | 概要 | プリンシパル変更時の対応 | スケーラビリティ |
|---|---|---|---|
| タグベースACL（ABAC） | リソースポリシー + aws:PrincipalTag / aws:ResourceTag | タグの付与のみ | 高い。ポリシー変更不要 |
| IAMロール + 信頼ポリシー | ロールを作成し、信頼ポリシーで許可するプリンシパルを指定 | 信頼ポリシーの修正が必要 | 中程度。ロール数やポリシー修正が増加 |
| デフォルト拒否 + IAMグループ | IAMグループにポリシーをアタッチし、メンバーをグループに追加 | グループメンバーの追加・削除が必要 | 中程度。グループ管理が必要 |
| VPCエンドポイントポリシー | VPCエンドポイント経由のアクセスをポリシーで制御 | ネットワーク経路ベースの制御のため、プリンシパル単位の制御には不向き | 低い。プリンシパル単位の柔軟な制御が困難 |
プリンシパルが頻繁に変更される環境で、柔軟性とスケーラビリティを最大化するには、タグベースACL（ABAC） が最も適しています。ポリシー自体の変更が不要で、タグの付与だけでアクセス制御を管理できるためです。
タグベースアクセス制御の利点
タグベースのABACには、スケーラビリティ以外にも以下の利点があります。
- SCPsとの統合: AWS Organizations のサービスコントロールポリシー（SCPs）でもタグベースの条件を使用でき、組織全体で一貫したタグベースの制御を実現できる
- CloudTrailによる監査: CloudTrailのイベントログにはプリンシパルのタグ情報が含まれるため、「どのチームのメンバーがどのシークレットにアクセスしたか」を追跡できる
- タグポリシーによるガバナンス: AWS Organizationsのタグポリシーを使えば、タグキーの命名規則や値の標準化を強制でき、ABACの前提となるタグの一貫性を維持できる
実践
ここでは、Secrets Managerのシークレットに対してタグベースのアクセス制御を設定し、タグが一致するユーザーのみがシークレットにアクセスできることを確認します。
前提条件
- リージョン:
ap-northeast-1（東京） - 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| IAMユーザー | abac-user-db | データベースチームのユーザー（シークレットにアクセスできる側） |
| IAMユーザー | abac-user-app | アプリケーションチームのユーザー（シークレットにアクセスできない側） |
各IAMユーザーにはAWSマネジメントコンソールへのログイン権限を設定してください。
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| Secrets Managerシークレット | prod/database/credentials | タグベースアクセス制御の対象シークレット |
| IAMポリシー | SecretsManagerAbacPolicy | タグ一致時にSecrets Managerへのアクセスを許可するポリシー |
手順1: Secrets Managerにシークレットを作成しタグを付与する
まず、アクセス制御の対象となるシークレットを作成し、チームを識別するタグを付与します。
- AWSマネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
Secrets Managerと入力し、表示された「Secrets Manager」を選択します - 「新しいシークレットを保存する」をクリックします
- 「シークレットのタイプ」で「その他のシークレットのタイプ」を選択します
- 「キー/値のペア」に以下を入力します
- キー:
username、値:db-admin - 「+ 行を追加」をクリックし、キー:
password、値:SamplePassword123! - 暗号化キーはデフォルト（
aws/secretsmanager）のままにします
- 「次」をクリックします
- 「シークレットの名前」に
prod/database/credentialsと入力します - 「タグ – オプション」セクションで「追加する」をクリックし、以下を入力します
- キー:
Team、値:database-admin
- 「次」をクリックします
- 「自動ローテーション」はデフォルト（無効）のままにします
- 「次」をクリックします
- 確認画面で設定内容を確認し、「保存」をクリックします
手順2: IAMユーザーにタグを付与する
次に、2名のIAMユーザーにチームを識別するタグを付与します。
abac-user-db にタグを付与する
- 上部の検索バーに
IAMと入力し、表示された「IAM」を選択します - 左側ナビゲーションの「ユーザー」を選択します
abac-user-dbをクリックします- 「タグ」タブを選択します
- 「新しいタグを追加する」をクリックします
- タグ編集画面が開いたら、もう一度「新しいタグを追加する」をクリックして行を追加し、以下を入力します
- キー:
Team、値:database-admin - 「変更を保存」をクリックします
abac-user-app にタグを付与する
- ユーザー一覧に戻り、
abac-user-appをクリックします - 同じ手順で以下のタグを付与し、「変更を保存」をクリックします
- キー:
Team、値:app-team
手順3: タグベースのIAMポリシーを作成する
プリンシパルのタグとリソースのタグが一致する場合にSecrets Managerへのアクセスを許可するIAMポリシーを作成します。
- 左側ナビゲーションの「ポリシー」を選択します
- 「ポリシーの作成」をクリックします
- 「JSON」タブを選択し、以下のポリシーを入力します
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSecretsManagerAccessMatchingTag",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:ap-northeast-1:*:secret:prod/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Team": "${aws:PrincipalTag/Team}"
}
}
},
{
"Sid": "AllowSecretsManagerList",
"Effect": "Allow",
"Action": [
"secretsmanager:ListSecrets"
],
"Resource": "*"
}
]
}このポリシーのポイントは以下の通りです。
AllowSecretsManagerAccessMatchingTag:prod/配下のシークレットに対して、プリンシパルのTeamタグとリソースのTeamタグが一致する場合にのみGetSecretValueとDescribeSecretを許可しますAllowSecretsManagerList: シークレットの一覧表示を許可します。一覧表示はリソースレベルの権限をサポートしていないため、Resourceは*を指定します
- 「次へ」をクリックします
- ポリシー名に
SecretsManagerAbacPolicyと入力します - 説明に
Tag based access control for Secrets Managerと入力します（IAM ポリシーの説明は英数字と+=,.@-_しか使えないため、日本語は入力できません） - 「ポリシーの作成」をクリックします
手順4: IAMユーザーにポリシーをアタッチする
作成したポリシーを両方のIAMユーザーにアタッチします。
abac-user-db にポリシーをアタッチする
- 左側ナビゲーションの「ユーザー」を選択します
abac-user-dbをクリックします- 「許可」タブを選択します
- 「許可を追加」→「ポリシーを直接アタッチする」を選択します
- 検索バーに
SecretsManagerAbacPolicyと入力し、表示されたポリシーにチェックを入れます - 「次へ」をクリックし、「許可を追加」をクリックします
abac-user-app にポリシーをアタッチする
- ユーザー一覧に戻り、
abac-user-appをクリックします - 「許可」タブを選択します
- 「許可を追加」→「ポリシーを直接アタッチする」を選択します
- 検索バーに
SecretsManagerAbacPolicyと入力し、表示されたポリシーにチェックを入れます - 「次へ」をクリックし、「許可を追加」をクリックします
手順5: Secrets Managerのリソースポリシーを設定する
シークレットのリソースポリシーにもタグベースの条件を設定します。IAMポリシーとリソースポリシーの両方でタグベースの制御を行うことで、多層的なアクセス制御を実現します。
- 上部の検索バーに
Secrets Managerと入力し、表示された「Secrets Manager」を選択します - シークレット一覧から
prod/database/credentialsをクリックします - 「リソースのアクセス許可 – オプション」セクションで「許可を編集」をクリックします
- JSON エディタの内容をすべて選択して削除し、以下のリソースポリシーを入力します（
<アカウントID>は自分のアカウントIDに置き換えます）
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessByMatchingTag",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<アカウントID>:root"
},
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/Team": "database-admin"
}
}
},
{
"Sid": "DenyAccessByNonMatchingTag",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::<アカウントID>:root"
},
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/Team": "database-admin"
},
"Null": {
"aws:PrincipalTag/Team": "false"
}
}
}
]
}このリソースポリシーのポイントは以下の通りです。
AllowAccessByMatchingTag: プリンシパルのTeamタグがdatabase-adminの場合にアクセスを許可しますDenyAccessByNonMatchingTag: プリンシパルのTeamタグがdatabase-admin以外の場合に明示的に拒否します。明示的な拒否は他のポリシーの許可より優先されるため、IAMポリシー側で許可されていてもアクセスはブロックされますPrincipalにはアカウントのルート（arn:aws:iam::<アカウントID>:root）を指定します。"Principal": "*"を指定すると「このリソースポリシーは、シークレットへの広範なアクセスを許可します」というエラーになり、コンソールからは保存できませんNull条件でaws:PrincipalTag/Teamが存在する場合だけ拒否を適用しています。この条件がないと、Teamタグを持たない管理者ユーザーまでDescribeSecretを拒否され、コンソールでシークレットの詳細が見られなくなります
- 「保存」をクリックします
「リソースポリシーを正常にシークレット prod/database/credentials にアタッチしました。」と表示されます。
クラウドおさるリソースポリシーの明示的な拒否は、IAM ポリシー側の許可より優先されるのでござる。Null 条件を外すと、Team タグを持たない管理者まで DescribeSecret を拒否されてしまうので気をつけるでござるぞ。
手順6: タグが一致するユーザーでアクセスできることを確認する
abac-user-db（Team=database-admin）でサインインし、シークレットにアクセスできることを確認します。
管理者のセッションを維持したまま別のIAMユーザーで確認したい場合は、コンソール右上のアカウントメニューから「マルチセッションサポートをオンにする」を選び、「セッションを追加」から別ユーザーでサインインします。別のブラウザやシークレットウィンドウを使っても構いません。
abac-user-dbでAWSマネジメントコンソールにサインインします- リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
Secrets Managerと入力し、表示された「Secrets Manager」を選択します - シークレット一覧から
prod/database/credentialsをクリックします - 「シークレットの値」セクションで「シークレットの値を取得する」をクリックします
username: db-adminとpassword: SamplePassword123!の値が表示されることを確認します
手順7: タグが一致しないユーザーでアクセス拒否されることを確認する
abac-user-app（Team=app-team）でサインインし、シークレットへのアクセスが拒否されることを確認します。
abac-user-appでAWSマネジメントコンソールにサインインします- リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
Secrets Managerと入力し、表示された「Secrets Manager」を選択します - シークレット一覧から
prod/database/credentialsをクリックします - シークレットの詳細画面を開いた時点で「Secrets Manager でシークレットを記述するための許可がありません。」というエラーが表示され、詳細もシークレットの値も表示されないことを確認します
この結果から、同じIAMポリシー（SecretsManagerAbacPolicy）がアタッチされた2名のユーザーでも、タグの値の違いによってアクセスの可否が制御されていることが確認できます。abac-user-app は IAMポリシーの条件（aws:ResourceTag/Team と aws:PrincipalTag/Team の一致）を満たさないうえに、リソースポリシーの明示的な拒否にも該当するため、DescribeSecret の時点でブロックされます。
クラウドおさるプリンシパルが頻繁に入れ替わる環境で、ポリシーを変えずにアクセスを絞るにはどの方式が向くか、という観点が問われるのでござる。IAM ロールの信頼ポリシーや IAM グループ、VPC エンドポイントポリシーと比べて、タグの付与だけで済む ABAC を選べるかが鍵でござるな。
まとめ
- ABAC（属性ベースアクセス制御） は、プリンシパルとリソースのタグ（属性）に基づいてアクセスを制御する方式で、プリンシパルが頻繁に変更される環境に適している
aws:PrincipalTagはリクエスト元のプリンシパルのタグを、aws:ResourceTagはアクセス対象のリソースのタグを参照する条件キーで、これらを組み合わせることでタグの一致条件に基づくアクセス制御を実現できる- Secrets Managerの リソースポリシー にタグベースの条件を設定することで、シークレット側でアクセスを制御でき、IAMポリシーとの多層的な防御が可能になる
- タグベースのアクセス制御では、新しいプリンシパルの追加時にタグを付与するだけでよく、ポリシー自体の変更が不要なため、柔軟性とスケーラビリティ に優れている
- RBACと比較して、チーム数やプロジェクト数が増加してもポリシー数が増えないため、大規模な環境でも管理コストを抑えられる
参照先
- AWS Secrets Manager でのシークレットへのアクセス許可の管理
- AWS Secrets Manager のリソースベースのポリシー
- IAM の ABAC とは
- IAM でのポリシーと権限
- AWS グローバル条件コンテキストキー
- IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する
