AWS IAM ABAC設計入門｜タグ駆動のアクセス制御でマルチチームの権限管理を効率化する実践ガイド

AWS IAMを運用していると、チームが増えるにつれてポリシーの数が際限なく増え続ける「ポリシー爆発」に直面するエンジニアは多い。プロジェクトA用ポリシー、チームB用ポリシー、環境（本番/開発）ごとのポリシー……と組み合わせが増えるたびに管理コストが跳ね上がる。

この問題を根本から解消するのが、ABAC（Attribute-Based Access Control：属性ベースアクセス制御）だ。リソースやIAMプリンシパルに付けたタグを「属性」として参照し、「同じタグを持つプリンシパルだけが同じタグを持つリソースを操作できる」というロジックをポリシー1本で表現できる。

この記事では、AWSにおけるABAC設計の仕組みをゼロから解説する。Condition Keysを使ったポリシー実装の手順、マルチチーム・マルチアカウント環境への適用ガイドライン、よくあるつまずきまでを現場視点でまとめた。

RBACとABACの違い：ポリシー爆発が起きる理由

まず、従来のIAM運用であるRBAC（Role-Based Access Control：役割ベースアクセス制御）との違いを整理しておく。

RBACは「誰が（どのロール・グループが）何をできるか」をあらかじめ定義する方式だ。たとえば開発チームが3つあり、それぞれ本番・検証・開発の3環境を持つ想定例を考えると、最低でもチーム数×環境数＝9種類のロール/ポリシーが必要になる。チームが増えるほど組み合わせは線形増加し、「このポリシーはどのチームのどの環境用だったか」という状態に陥る。これがポリシー爆発の典型だ。

一方ABACは「プリンシパルとリソースが同じ属性（タグ）を持つときだけアクセスを許可する」方式で、ポリシーの本数を大幅に削減できる。チームが増えてもポリシーは変更不要で、新チームにタグを付与するだけで既存ポリシーがそのまま機能する。

AWS IAMにおけるABACの仕組み

AWSのABACは「タグ」と「Condition Keys」の組み合わせで実現する。ここでは3種類の主要な属性参照方法を押さえておこう。

1. リソースタグとプリンシパルタグ

ABACで参照する「属性」はAWSタグとして表現される。

・リソースタグ（aws:ResourceTag）: S3バケット、EC2インスタンス、RDSクラスターなどに付けるタグ。例: Project=ecommerce、Env=prod
・プリンシパルタグ（aws:PrincipalTag）: IAMユーザーまたはIAMロールに付けるタグ。リクエストを発行している主体の属性を示す。例: Project=ecommerce、Team=backend
・リクエストタグ（aws:RequestTag）: CreateBucket・RunInstancesなど、リソース作成リクエスト時に付与するタグ値。「作成時に正しいタグを付けなければ拒否する」制御に使う。

2. アクセス制御の要：Condition Keys

IAMポリシーのConditionブロックにCondition Keysを記述することで、属性の比較ロジックを定義する。最もよく使われるのが、aws:PrincipalTagとaws:ResourceTagを突き合わせる「タグ一致条件」だ。

# タグ一致を確認するABAC条件付きポリシーの例（想定例）
# プリンシパルのProjectタグとリソースのProjectタグが一致する場合のみ許可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccessToTagMatchedResources",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:DescribeInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
          "aws:ResourceTag/Env": "${aws:PrincipalTag/Env}"
        }
      }
    }
  ]
}

ポイントは${aws:PrincipalTag/Project}という記法だ。これは「リクエストを発行しているプリンシパルのProjectタグの値」を動的に参照するポリシー変数であり、単一のポリシー文で全プロジェクトのアクセス制御を実現している。

3. 必須タグ強制：aws:TagKeysとaws:RequestTag

リソース作成時に必須タグの付与を強制するには、DenyルールとNull条件を組み合わせる。

# EC2インスタンス作成時に Project タグを必須とする（想定例）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRunInstancesWithoutProjectTag",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Project": "true"
        }
      }
    }
  ]
}

このDenyルールによって、Projectタグなしでのインスタンス起動リクエストが拒否される。ABACは「タグが付いていないリソース」への到達手段がなくなる問題（タグ未付与リソースの孤立問題）を招きやすいため、作成時の強制タグ付けとセットで設計することが必須だ。

ABAC実装の基本ステップ

1. タグ設計：どの軸を属性として使うか決める

ABACの出来はタグ設計で8割が決まる。複雑にしすぎると管理しきれなくなるため、まず以下の3軸から始めることを推奨する。

・Project（例: ecommerce/hrportal）: 業務システム・プロジェクト単位
・Env（例: prod/stg/dev）: 環境（本番・検証・開発）
・Team（例: backend/frontend/infra）: 担当チーム

タグの値は大文字小文字を区別するため（StringEqualsは大小文字区別あり）、命名規則を事前に決めておく。全小文字・ハイフン区切りが運用しやすい。また、タグ設計はAWSコスト配分タグやFinOpsのタグ運用とも連動させると、コスト可視化と権限管理を同一タグ体系で運用できる。

2. IAMプリンシパルへのタグ付け

IAMユーザーやIAMロールへのタグ付けは、マネジメントコンソールまたはAWS CLIで行う。

# AWS CLI: IAMロールへのタグ付け（想定例）
aws iam tag-role \
  --role-name EcommerceBackendRole \
  --tags \
    Key=Project,Value=ecommerce \
    Key=Env,Value=prod \
    Key=Team,Value=backend

AWS IAM Identity Centerを利用している場合は、権限セットにタグを付与したうえでIdPの属性からプリンシパルタグへの自動マッピング（Attribute Mapping）も設定できる。詳しくはAWS IAM Identity Center入門を参照してほしい。

3. ABACポリシーの作成とアタッチ

タグ設計が固まったら、Condition Keysを使ってポリシーを作成する。以下は、S3バケットへのABACアクセスをまとめた想定例だ。

# 想定例: 共通ABACポリシー（全プロジェクト共用）
# Project・Envタグが一致するS3バケットへのR/Wを許可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3ABACReadWrite",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::*",
        "arn:aws:s3:::*/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
          "aws:ResourceTag/Env": "${aws:PrincipalTag/Env}"
        }
      }
    }
  ]
}

このポリシー1本で、Project=ecommerceかつEnv=prodのロールは「同じタグを持つS3バケット」だけを操作できる。hrportalプロジェクト用に別ポリシーを作成する必要はない。新プロジェクトが追加されても、リソースとプリンシパルに正しいタグを付けるだけでよい。

マルチアカウント環境への展開

ABACはマルチアカウント構成（AWS Organizations + AWS IAM Identity Center）との組み合わせで真価を発揮する。IAM Identity Centerの権限セットにABACポリシーを付与し、IdP（例: Microsoft Entra ID）のグループ属性からプリンシパルタグへ自動マッピングすることで、新メンバーをIdPのグループに追加するだけでAWS側のアクセス権限が自動的に設定される運用を実現できる。

また、SCPとの組み合わせでセキュリティを強化できる。たとえばSCPで「特定のタグキーの削除を組織全体で禁止する」ルールを追加すると、プリンシパルが自分のタグを書き換えて権限昇格を試みる攻撃を防げる。SCPの設計についてはAWS SCP実践設計入門も参照してほしい。

IAM Permission Boundariesと組み合わせると、「部門管理者が作れるロールの最大権限」を制限しつつABACポリシーの委任管理も実現できる。詳細はAWS IAM Permission Boundaries入門を参照のこと。

ABACの料金

ABACそのもの（タグの付与・Condition Keysの利用）に追加料金はかからない。IAMは無料のサービスだ。

ただし間接的なコストとして以下の点に注意する。

・AWS Config Rules: 必須タグの付与状況を継続的にチェックする場合はConfig Rulesの料金が発生する（2026年10月時点でアクティブなConfig Ruleあたり月額$2.00）
・タグ付け作業工数: 既存リソースへの一括タグ付けはResource Groups Tagging APIやAWS Tag Editorで自動化できる
・IAM Identity Center連携: 属性マッピングはAWS Organizations環境での利用が前提。既存の構成コストに変化はない

よくあるつまずきと対処法

【つまずき1】タグ未付与リソースへのアクセスが完全に止まる

ABACポリシーを導入すると、タグが付いていないリソースはどのプリンシパルからもアクセス不能になる。移行期に既存リソースへのアクセスが突然失われるのは、一般的によく起きるつまずきだ。

対処法: ABACを全面適用する前に、AWS Resource Groups Tagging APIやAWS Tag Editorで既存リソースのタグ付与率を100%にしてから切り替える。移行期間中はABACポリシーとRBACポリシーを並行で動かし、段階的に移行する進め方が安全だ。

【つまずき2】タグ値の大文字小文字ミスで拒否される

StringEqualsは大文字小文字を区別する。Project=EcommerceとProject=ecommerceは別の値として扱われ、アクセスが拒否される。

対処法: 命名規則を「すべて小文字」に統一し、タグ付け時のバリデーションをConfig Rulesまたはカスタムスクリプトで自動チェックする。大文字小文字を区別したくない場合はStringEqualsIgnoreCase演算子を使う。

【つまずき3】プリンシパルがタグを書き換えて権限昇格する

IAMユーザーがiam:TagUser権限を持っていると、自分のProjectタグを別プロジェクトの値に書き換えてアクセス権を拡張できてしまう。

対処法: iam:TagUser・iam:TagRoleの権限は管理者専用とし、一般ユーザーには付与しない。SCPで組織レベルから禁止することも有効だ。ABACポリシーの整合性を定期検査するにはAWS IAM Access Analyzerが役立つ。

【つまずき4】Conditionの変数展開が想定通り動かない

${aws:PrincipalTag/Project}という変数参照は、プリンシパルにProjectタグが付いていない場合は空文字列に展開される。その結果、タグ未付与のロールは条件を満たせず、すべてのアクセスが拒否される。

対処法: 新ロール作成時のタグ付けをIaCテンプレート（TerraformやCloudFormation）で強制し、タグなしロールが作られないように仕組み化する。

本記事のまとめ

ABACは、増え続けるポリシー管理の負担を根本から解決するアーキテクチャ的なアプローチだ。タグを「属性」として活用することで、チームや環境が増えてもポリシーの本数を抑えられる。

ABACを導入したからといってすべての権限管理がタグだけで完結するわけではない。管理系の操作（iam:CreateRoleなど）やクロスアカウントアクセスにはRBACの要素を組み合わせるハイブリッド設計が現実的だ。まずは特定のプロジェクトやサービスに絞ってパイロット導入し、タグ設計を磨いてから全体展開する進め方が失敗しにくい。

セキュリティ観点からIAMの脅威モデルや権限昇格のリスクをさらに深く学びたい場合は、姉妹サイトSecurityMasters.TOKYOもあわせて参照してほしい。