ABAC

ABAC とは

ABAC (Attribute-Based Access Control) は、ユーザーの属性 (部署、役職、所在地)、リソースの属性 (機密レベル、所有者)、環境の属性 (時刻、IP アドレス、デバイス) を組み合わせてアクセス可否を動的に判断する認可モデルである。NIST SP 800-162 で標準化されている。

RBAC がロール (管理者、編集者) という静的な分類でアクセスを制御するのに対し、ABAC は属性の組み合わせによるポリシーで制御する。「営業部の社員が、自部署の顧客データに、営業時間内にのみアクセスできる」といった細粒度のルールを、ロールの爆発的増加なしに表現できる。

RBAC のロール爆発問題

RBAC で細粒度の制御を実現しようとすると、ロールが指数的に増殖する。

営業部 × マネージャー × 東京 = 営業部マネージャー東京
営業部 × マネージャー × 大阪 = 営業部マネージャー大阪
営業部 × 一般社員 × 東京   = 営業部一般社員東京
開発部 × マネージャー × 東京 = 開発部マネージャー東京
...

3 つの属性 (部署 5 × 役職 3 × 拠点 4) だけで 60 ロールが必要になる。属性が増えるたびにロール数が掛け算で増加し、管理が破綻する。ABAC はこの問題を属性ベースのポリシーで解決する。

RBAC との比較

RBAC との主な違いを以下に比較する。

観点	RBAC	ABAC
制御の粒度	ロール単位 (粗い)	属性の組み合わせ (細かい)
ポリシーの柔軟性	ロールの追加が必要	属性の組み合わせで動的に対応
管理の複雑さ	シンプル、直感的	ポリシーの設計・テストが複雑
ロール爆発問題	発生しやすい	発生しない
新規属性の追加	新ロールの作成が必要	タグの付与だけで対応
監査のしやすさ	「誰がどのロールか」で明確	属性の組み合わせで判定が複雑
適するケース	組織構造が安定、権限パターンが少ない	細粒度の制御、動的な条件が必要

実務では RBAC と ABAC を組み合わせるハイブリッドアプローチが多い。基本的な権限は RBAC で管理し、細粒度の制御が必要な部分だけ ABAC を適用する。

AWS IAM での ABAC 実装

AWS IAM は ABAC をネイティブにサポートしている。リソースとプリンシパルにタグを付与し、IAM ポリシーの Condition でタグの一致を検証する。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::project-data/*",
      "Condition": {
        "StringEquals": {
          "s3:ExistingObjectTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    }
  ]
}

このポリシーは「ユーザーの Project タグと S3 オブジェクトの Project タグが一致する場合のみアクセスを許可する」という ABAC ルールだ。新しいプロジェクトが追加されても、ポリシーの変更は不要でタグの付与だけで対応できる。

ABAC で使える AWS の条件キー

条件キー	用途
aws:PrincipalTag/キー名	IAM ユーザー/ロールのタグ
aws:ResourceTag/キー名	リソースのタグ
aws:RequestTag/キー名	リクエスト時に指定されたタグ
aws:CurrentTime	現在時刻 (時間帯制限)
aws:SourceIp	リクエスト元 IP (ネットワーク制限)

ABAC の設計パターン

パターン 1: プロジェクト分離

チームメンバーが自分のプロジェクトのリソースのみにアクセスできるようにする。IAM ユーザーに Project=alpha タグを付与し、S3 オブジェクトにも同じタグを付与する。

パターン 2: 環境分離

Environment=prod タグを持つリソースへのアクセスを、Environment=prod タグを持つロールのみに制限する。開発者が本番リソースに誤ってアクセスするのを防ぐ。

パターン 3: 時間帯制限

aws:CurrentTime 条件で、営業時間外のアクセスを拒否する。

よくある落とし穴

• タグの不整合: リソースにタグを付け忘れると、ABAC ポリシーが意図どおりに動作しない。タグの付与を自動化 (CloudFormation のデフォルトタグ、AWS Config ルール) する
• ポリシーのテスト不足: 属性の組み合わせが膨大になるため、すべてのケースを手動テストするのは不可能。IAM Policy Simulator やアクセスアナライザーで自動検証する
• 属性の信頼性: ユーザーが自分のタグを変更できる場合、ABAC の前提が崩れる。タグの変更権限を管理者に限定する
• デバッグの困難さ: アクセス拒否時に「どの属性の不一致が原因か」が分かりにくい。CloudTrail のログで Condition の評価結果を確認する

NIST SP 800-162 が ABAC の標準仕様を定義している。AWS の「ABAC for AWS」ドキュメントで実装パターンが詳しく解説されている。

現場での応用を知るには関連書籍も役立つ。