ABAC

ABAC とは

ABAC (Attribute-Based Access Control) は、ユーザーの属性 (部署、役職、所在地)、リソースの属性 (機密レベル、所有者)、環境の属性 (時刻、IP アドレス、デバイス) を組み合わせてアクセス可否を動的に判断する認可モデルである。NIST SP 800-162 は、ABAC の定義と導入の考慮事項をまとめた手引きである。

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

RBAC のロール爆発問題

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

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

3 つの属性 (部署 5 × 役職 3 × 拠点 4) だけで 60 ロールが必要になる。属性が増えるたびにロール数が掛け算で増える。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 の条件キー

ABAC の設計パターン

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

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

パターン 2: 環境分離

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

パターン 3: 時間帯制限

aws:CurrentTime 条件で、リクエストの日時をポリシーに書いた日時と比べ、指定した範囲の外のアクセスを拒否する。

よくある落とし穴

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

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