🦔

【脱・IAMポリシー沼】S3のアクセス制御は「タグ」に任せろ！属性ベースアクセス制御(ABAC)入門

に公開
AWS
S3
IAM
アップデート
iamポリシー
tech

はじめに

「Amazon S3 が属性ベースのアクセス制御をサポートするようになりました」
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/amazon-s3-attribute-based-access-control/

2025/11/20 にさらっと出たこのアップデートですが、AWSの設計や権限管理をする上で重要なアップデートです！

これまで、S3バケットが増えるたびに「IAMポリシーを修正して、新しいバケットのARNを追加して…」と繰り返していたあの作業。 今回のサポートにより、「タグ」さえ付与すれば、IAMポリシーを一切書き換えずに権限管理ができるようになりました。

今回は、S3運用を劇的に楽にするこの機能を、実務でハマりやすい「落とし穴」の回避策とあわせて、ハンズオン形式で解説します。

これまでの課題 (RBAC) と ABAC の違い

これまでの一般的な管理手法（RBAC: Role-Based Access Control）と、今回のABAC（Attribute-Based Access Control）の違いを比較してみましょう。

特徴 これまで(RBAC) これから (ABAC)
権限の定義 「場所」を指定

例：「User-Aは bucket-X と object-Y を見てOK」		 「属性（タグ）」を指定

例：「『Project=Blue』のタグを持つ人は、同じタグのデータを見てOK」
新規作成時 毎回ポリシー修正が必要

新しいバケットを作ったら、IAMポリシーを追記修正する。		 修正不要！

バケットやファイルにタグを付けるだけで、即座に権限が適用される。
スケーラビリティ ポリシーが肥大化し、管理不能になりがち。 1つの汎用ルールだけで、バケットが100個増えても対応可能。

動作イメージ

仕組みはシンプルです。「ユーザーのタグ」と「データのタグ」が一致した時だけ、アクセスが可能になります。

  • User A (タグ: Blue) ➡ アクセス ➡ File A (タグ: Blue) ✅ OK
  • User A (タグ: Blue) ➡ アクセス ➡ File B (タグ: Red) ❌ Block

【ハンズオン】実際にやってみよう

構成図

シナリオ

  • ユーザー:
    • blue (タグ: Project=Blue)
    • red (タグ: Project=Red)
  • データ (S3オブジェクト):
    • Blue.txt (タグ: Project=Blue)
    • Red.txt (タグ: Project=Red)
  • ルール:
    • ユーザーの Project タグと、オブジェクトの Project タグが一致する場合のみ、読み取り (GetObject) を許可する。

1. 実験場所（S3バケット）を作ろう

まずはデータを入れる箱を作ります。設定はデフォルトでOKです。

  1. AWSコンソールで [S3] を開く。
  2. [バケットを作成] をクリック。
  3. バケット名 を入力（例: my-abac-test-20251201 など世界で一意な名前）。
  4. 他の設定は全て無視して、一番下の [バケットを作成] をクリック。

2. 「タグ付き」の機密ファイルをアップロード

ここがABACのキモです。ファイルにタグを付けてアップロードします。

  1. 作成したバケットをクリックして中に入る。
  2. [アップロード] → [ファイルを追加] で適当なテキストファイル（例: Blue.txt）を選ぶ。
  3. 【重要】 画面を下にスクロールし、[プロパティ] > [タグ] を探す。
  4. 以下のタグを追加して [アップロード] する。
    • キー: Project
    • 値: Blue

同様の手順で、もう一つ別のファイル（例: Red.txt）をアップロードします。こちらには別のタグを付けます。

  • キー: Project
  • 値: Red

これでS3の中には、「青チーム用」　と　「赤チーム用」　の2つのファイルが用意されました。

3. IAMポリシーを作成

次に、権限ルール（IAMポリシー）を作ります。ここで実務的なテクニックを使います。

🚨 よくある落とし穴：PowerUserAccessの罠

検証用ユーザーには PowerUserAccess などの強い権限がついていることが多いですが、IAMポリシーは「どれか1つでも許可があればOK（足し算）」のルールなので、通常の許可ポリシーだとABACが無視されてしまいます。

✅ 解決策： 「Deny（拒否）」ポリシーを使う

「タグが一致しないなら、絶対に拒否(Deny)する」というポリシーを作成します。Denyは最強なので、PowerUserAccessよりも優先されます。

  1. IAMコンソール -> [ポリシー] -> [ポリシーの作成]。
  2. [JSON] タブを選び、以下をコピペします。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAccessIfTagsDoNotMatch",
            "Effect": "Deny",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<Step1で作ったバケット名>/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:ExistingObjectTag/Project": "${aws:PrincipalTag/Project}"
                }
            }
        }
    ]
}
  1. 名前（例: my-abac-test-20251201-policy）を付けて保存します。

4. IAMユーザーを作成（タグ付け）

最後に、アクセスするユーザーを作り、タグを付けます。

  1. IAMコンソール -> [ユーザー] -> [ユーザーの作成]。
  2. ユーザー名を入力（例: blue, red）。
  3. [許可のオプション] で 「ポリシーを直接アタッチする」 を選択。
  4. 検索窓で以下2つのポリシーにチェックを入れます。
    • PowerUserAccess（一般的な開発者権限のシミュレーション）
    • my-abac-test-20251201-policy（Step3で作ったポリシー）
  5. 作成完了後、ユーザー一覧からそのユーザーをクリックして開く。
  6. [タグ] タブ -> [タグの管理] -> [新しいタグを追加]。
    • キー: Project
    • 値: Blue
    • [変更の保存] をクリック。

これで、「PowerUser権限（S3全部OK）を持っているが、タグがBlueなので、Blueのファイルしか触れない」 というユーザーが完成しました！

結果

作成したIAMユーザー（Project: Blue）でログインし、S3バケットにアクセスしてみます。

  • Blue.txt を開く

  • Red.txt を開く

操作 結果 理由
ファイル一覧を見る ✅ 表示される PowerUserAccessで許可されているため。
Blue.txt を開く ✅ 成功 タグが一致しているため、Denyポリシーが発動しない。
Red.txt を開く ❌ 拒否 (Access Denied) タグが不一致のため、Denyポリシーが発動！

見事に、「ファイル一覧までは共有、中身は自分の部署のものだけ」 という制御が実現できました！

まとめ

S3のABACを利用することで、以下のメリットが得られます。

  1. 運用コストの削減: 新しいリソース追加時のポリシー修正が不要。
  2. スケーラビリティ: 組織が大きくなってもポリシー管理が破綻しない。
  3. チームの自律性: 開発チームがタグ付けだけで権限をコントロールできる。

「バケットごとにポリシーを書く」という作業から卒業し、よりスマートな権限管理を実現しましょう。

Discussion