IAMは誰の責任か？ ~ABAC・SCP・委譲の設計~

2026年3月7日、AWSユーザーコミュニティ「JAWS-UG」主催の国内最大規模イベント JAWS DAYS 2026 に参加しました。 本記事では、

JAWS DAYS 2026「AWS IAMは誰の責任か？」（登壇: 辻 水月氏 / KINTOテクノロジーズ）

に参加して得られたIAMの権限管理に関するセッションの知見と、自分のAWSアカウントで試した検証事例を紹介します。

---

セッション内容

課題：インフラチームがボトルネックに

KINTOテクノロジーズでは、AWSリソースの作成・管理をすべてインフラチームが担っていました。Lambdaを1つ追加するにもインフラチームへの依頼が必要で、サービス増加とともに作業量が膨れ上がっていました。その結果、インフラチームの対応がサービスの増加に対応できなくなり、ボトルネックが生じました。

解決策は「責任と操作を分けて任せる」ことでした。具体的には次の3点です。

• (1) インフラチームがIAM Roleやリソースをいちいち作ることをやめた

• (2) 最終責任（全体の統制と品質の管理）は手放さなかった

• (3)「標準ルール（ABAC）」と「禁止ルール（SCP）」を整備した

ABACで「枠の中の自由」をつくる

まず、ABAC（Attribute-Based Access Control）とは、AWSリソースに付けたタグでアクセスを制御する仕組み（AWS公式ドキュメント）です。３ステップで説明すると

1. 定義: インフラチームが標準ポリシーを用意（「system=netcomかつenv=devのタグがついたリソースなら操作OK」等）
2. 識別: AWSリソースにタグを付ける（system=netcom、env=dev等）
3. 自律: 開発者が自分のプロジェクトタグがついたリソースを自由に操作する

ただし落とし穴もあります。タグなしリソースの放置やタグの付与漏れが起きやすい点です。対策として、リソース作成時のタグ必須化、Conditionでのチェック、命名ルールのポリシー化で対応していたそうです。たとえば、SCPで aws:RequestTag 条件を使い、必須タグが付いていないリソースの作成自体をDenyするルールを設けることで、タグ付与漏れを仕組みとして防止できます。

任せるための最低限の仕組み

辻氏が整理した枠組みは「禁止・標準・委譲」の3つです。

分類	内容	具体例
禁止（SCP）	やっていいことの上限を決める	管理者権限の付与、何でもあり権限
標準（ABAC）	守るべきルール	標準ポリシー、命名・タグルール
委譲（開発）	開発チームが自由にやっていいこと	Role作成、日々のリソース変更

SCPは権限の上限を決めるガードレールで、管理アカウントのユーザーやロールには効かない点に注意が必要です。なお、IAMベストプラクティスではPermissions Boundaryで権限の上限を決める方法もすすめられています。

最後に辻氏が示した、IAMの責任を設計する際の3つの問いが印象に残りました。

1. 今の権限管理で、開発チームは自律的に動けているか？
2. インフラチームは「作業者」ではなく「設計者」になれているか？
3. 禁止・標準・委譲のどの層が欠けているか？

---

自分のAWSアカウントで検証してみる

ここからは、セッションの内容を自分のアカウントで実際に試した事例です。すべてマネジメントコンソール上で操作しました。

前提条件

• IAMの管理権限を持つユーザーでコンソールにサインインしていること

検証1: ABACポリシーの作成

タグが一致するリソースだけ操作を許可するポリシーを作成します。

参考: IAM チュートリアル: タグに基づいてAWSリソースにアクセスする

1. IAM を開く
2. 左メニュー 「ポリシー」 → 「ポリシーの作成」
3. 「JSON」 タブに切り替え、以下を貼り付ける

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListSecrets",
      "Effect": "Allow",
      "Action": "secretsmanager:ListSecrets",
      "Resource": "*"
    },
    {
      "Sid": "AllowTagMatchingResources",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret",
        "secretsmanager:UpdateSecret",
        "secretsmanager:DeleteSecret",
        "secretsmanager:PutSecretValue"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/project": "${aws:PrincipalTag/project}",
          "aws:ResourceTag/env": "${aws:PrincipalTag/env}"
        }
      }
    },
    {
      "Sid": "AllowCreateWithMatchingTags",
      "Effect": "Allow",
      "Action": "secretsmanager:CreateSecret",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/project": "${aws:PrincipalTag/project}",
          "aws:RequestTag/env": "${aws:PrincipalTag/env}"
        },
        "ForAllValues:StringEquals": {
          "aws:TagKeys": ["project", "env"]
        },
        "StringLike": {
          "aws:RequestTag/project": "?*",
          "aws:RequestTag/env": "?*"
        }
      }
    }
  ]
}

1. 「次へ」 をクリック
2. ポリシー名に abac-test-policy と入力 → 「ポリシーの作成」

検証2: テスト用IAMロールの作成とタグ付与

1. IAM → 左メニュー 「ロール」 → 「ロールを作成」
2. 信頼されたエンティティタイプ: 「AWS アカウント」 を選択
3. 「このアカウント」 を選択 → 「次へ」
4. 許可ポリシーで abac-test-policy を検索してチェック → 「次へ」
5. ロール名に abac-test-role と入力
6. 「タグを追加」 セクションで以下の2つのタグを追加:
   • キー: project / 値: myapp
   • キー: env / 値: dev
7. 「ロールを作成」

検証3: スイッチロールでABACをテスト

1. コンソール右上のアカウント名をクリック → 「ロールの切り替え」
2. 以下を入力:
   • アカウント: 自分のアカウントID
   • ロール: abac-test-role
3. 「ロールの切り替え」 をクリック

テスト A: タグが一致するシークレットの作成（成功するはず）

1. Secrets Manager を開く
2. 「新しいシークレットを保存する」
3. シークレットのタイプ: 「その他のシークレットのタイプ」
4. キー/値に key / value を入力 → 「次へ」
5. シークレット名: abac-test-match
6. 「タグ」 セクションで以下を追加:
   • キー: project / 値: myapp
   • キー: env / 値: dev
7. 「次へ」 → ローテーション設定はそのまま → 「次へ」 → 「保存」
8. 結果: 正常に作成されました

下図のように、ロールのタグ（project=myapp, env=dev）と同じタグを付けたシークレットキーは、エラーなく一覧に登録されました。これにより、ABACポリシーのAllow条件が正しくマッチしていることが確認できました。

テスト B: タグが一致しないシークレットの作成（失敗するはず）

1. 同じ手順でシークレットを作成
2. シークレット名: abac-test-mismatch
3. タグを以下に変更:
   • キー: project / 値: otherapp
   • キー: env / 値: prod
4. 結果: エラーが表示され、作成できない → ABACが正しく機能している証拠

下図のように、以下のように保存ボタンを押した直後に赤いエラーバナーが表示され、シークレットキーは作成されませんでした。ポリシー側でタグの条件が検知され、不一致のリソース作成が拒否されていることが確認できました。

検証のまとめ

検証項目	結果	ポイント
ABACポリシーの作成	タグベースの条件付きポリシーを作成できた	aws:ResourceTag と aws:PrincipalTag の変数でロールとリソースのタグを動的に照合できた
タグ一致シークレットの作成	成功（期待どおり）	ロールのタグ（project=myapp, env=dev）と一致するタグを付ければ操作が許可された
タグ不一致シークレットの作成	失敗（期待どおり）	タグが一致しないリソースは操作が拒否され、ABACのガードレールが機能していることを確認できた

今回の検証を通じて、ABACがタグという属性だけで「許可」と「拒否」を明確に切り分けられることを実際に確かめることができました。ポリシー側のConditionを一度整えれば、あとはロールとリソースに適切なタグを付与するだけで制御が効くため、ルールを増やさずに範囲だけを広げていける点は運用面でも大きな利点であると感じました。セッションで語られていた「枠の中の自由」を、小規模ながら自分のアカウントでも再現することができました。

執筆者：山田翔也 システムエンジニア プロテインに呪われてる