RBAC の記事の最後に、「ロールが増えすぎる」「データ1件ごとの判断が苦手」という RBAC の弱いところを書きました。そこを補う考え方が ABAC（属性ベースのアクセス制御）です。ただ、「属性」「ポリシー」と言葉だけ並べてもイメージしにくいので、この記事では会社の部屋の入り方のような身近な例から始めて、NIST・Microsoft・AWS のドキュメントで確かめながら、少しずつ図にしました。
- ABAC は、人や資料に付けた「ラベル（属性）」を見比べて判断するしくみであること
- RBAC と比べて何がうれしいか（部署が増えても決まりが増えない）
- しくみの中身：門番（PEP）と審査係（PDP）
- Azure・AWS・Entra の条件付きアクセスでの実際の形
- 使うときに気をつけること
まずは身近な例で：会社の部屋の入り方
会社に「営業部の部屋」「人事部の部屋」があり、それぞれの部署の人だけが入れるようにしたいとします。やり方は2つ考えられます。
- 鍵を配るやり方（RBAC に近い）：「営業部の鍵」「人事部の鍵」を作り、部署の人に配ります。部署が増えるたびに、鍵の種類も増えます。
- カードリーダーが判断するやり方（ABAC）：社員証に「部署：営業部」と書いておき、部屋の入口にも「営業部」の札を付けます。カードリーダーは「社員証の部署と部屋の札の部署が同じなら開ける」という決まり1つで判断します。部署が増えても、社員証と札を用意するだけで、決まりは変わりません。
この「社員証の部署」や「部屋の札」のような、人やモノに付いている情報のことを属性といいます。ABAC は、属性を見比べてアクセスを決めるしくみです。
ABAC を3つのステップで見る
NIST SP 800-162 は ABAC を、「主体（人）、対象（資料などのリソース）、求められた操作、場合によっては環境（状況）の属性を、決まり（ポリシー）に照らして評価し、操作を許すかを決める方法」と定義しています。これを3つのステップに分けてみます。
人や資料にラベル（属性）を付ける
まず、人と資料にラベルを付けます。ラベルは「部署：営業部」のような、名前と値の組です。
| 属性の種類 | 例 |
|---|---|
| 人（誰が） | 部署、役職、所属する会社 |
| 資料（何に） | どの部署の資料か、社外秘かどうか、作った人 |
| 操作（何を） | 読む、書く、消す |
| 状況（いつ・どこから） | 時刻、社内ネットワークからか、会社の端末か |
決まり（ポリシー）を書く
次に、ラベルを使って決まりを書きます。たとえば「人の部署と資料の部署が同じなら、読んでよい」です。状況のラベルを使えば、「ただし社外からは読めない」のような決まりも書けます。
リクエストのたびに見比べる
アクセスのたびに、人・資料・操作・状況のラベルを決まりに当てはめて、許可か拒否かを決めます。どの決まりにも当てはまらなければ、拒否します。
RBAC と何が違う？
RBAC は「その人が、あるロール（役割）を持っているか」で判断します。部署ごとに資料を分けたいとき、RBAC だけで作ると「営業部・読む」「人事部・読む」……のように、部署の数だけロールが増えていきます。ABAC なら「人の部署 ＝ 資料の部署」の決まり1つで済み、新しい部署ができても、人と資料にラベルを付けるだけです。
AWS のドキュメントも ABAC の利点として、新しいリソースのために既存の決まりを書き換えなくてよいこと、職務ごとに決まりを作らずに済むので数が少なくなることを挙げています。NIST も、ABAC では一人ひとりに直接権限を割り当てる必要がなくなると説明しています。
| 項目 | RBAC | ABAC |
|---|---|---|
| 見るもの | ロールを持っているか | 人・資料・操作・状況のラベル |
| 細かさ | ロールの単位まで | 資料1件ごと、状況ごとまで |
| 部署や資料が増えたとき | ロールや割り当てが増える | ラベルを付けるだけで、決まりは増えない |
| わかりやすさ | 「誰が何をできるか」を一覧にしやすい | 結果がラベルの値で変わるので、一覧にしにくい |
どちらか一方を選ぶというより、組み合わせて使うのがふつうです。「社員なら読む・書くのロールを持つ」は RBAC で決め、「ただし自分の部署の資料だけ」は ABAC で絞る、という形です。Microsoft のドキュメントでも、RBAC は業務の形に沿っていて導入しやすく、ABAC はいくつかの場面で柔軟さをもたらすので、両方を組み合わせるとよいと説明しています。
しくみの中身：門番と審査係
部屋の例でいえば、ドアを開け閉めするカードリーダーと、「開けてよいか」を決める決まりは、別の役割です。NIST SP 800-162 も、ABAC のしくみを役割の違う部品に分けて説明しています。
| 部品 | 役割（NIST SP 800-162 より） | API でいえば |
|---|---|---|
| 門番 PEP（Policy Enforcement Point） | アクセスを求められたときに、判断の結果を実行する（止める・通す） | API のコード、API ゲートウェイ |
| 審査係 PDP（Policy Decision Point） | 当てはまるポリシーを評価して、判断を出す | 認可の判定をする部分 |
| ラベルの保管場所 PIP（Policy Information Point） | 評価に必要な属性（ラベル）やデータを取り出す元 | Entra ID、データベース、タグ |
| 管理画面 PAP（Policy Administration Point） | ポリシーを作り、管理し、テストする | 管理画面、ポリシーの定義ファイル |
こう分けておくと、「どこで止めるか」と「どう判断するか」を別々に考えられます。たとえば、API ゲートウェイ（門番）で止めつつ、判断の決まり（審査係）は1か所にまとめておく、という設計ができます。
実際の製品での形
Azure：ロールの割り当てに「条件」を足す
Azure の ABAC は、RBAC のロールの割り当てに「条件」を足すしくみです。今のところ、Azure Storage の BLOB（Azure のファイル置き場に置くファイル）などで使えます。BLOB には「タグ」というラベルを付けられ、条件でそのタグを見比べます。
Microsoft のドキュメントの例では、Chandra さんに Storage Blob Data Reader（ファイルを読むロール）を割り当て、「ファイルのタグ Project が Cascade（プロジェクト名）のものだけ読める」という条件を付けています。同じロールを持っていても、タグが Cascade でないファイルは読めません。
参考：その条件をコードで書いたもの（Microsoft のドキュメントの例。読めなくても大丈夫です）
(
(
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
AND NOT
SubOperationMatches{'Blob.List'})
)
OR
(
@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'
)
)
前半は「ファイルを読む操作でなければ、この条件は関係しない」、後半は「ファイルのタグ Project が Cascade なら許す」という意味です。
| 項目 | Azure ABAC の決まり（Microsoft のドキュメントより） |
|---|---|
| 使える場所 | 今のところ、BLOB ストレージやキューストレージのデータ操作を含むロールの割り当て |
| 使える属性の例 | ファイルのタグ（インデックスタグ）、置き場所のパスやコンテナ名、Private Link 経由か、今の日時、人のラベル（カスタムセキュリティ属性） |
| できないこと | 条件で特定のリソースへのアクセスを明示的に拒否することはできない（条件は、与えた権限を絞り込むもの） |
| うれしいこと | より細かく制御できる。何千にもなりうるロールの割り当ての数を減らせる。プロジェクト名や機密区分のような業務の言葉で決まりを書ける |
人の側のラベル（カスタムセキュリティ属性）とファイルのタグを見比べる、「ユーザーの Project 属性と、ファイルのタグ Project が同じなら読める」という条件も作れます。図3の「人の部署 ＝ 資料の部署」と同じ考え方です。
AWS：タグを見比べる
AWS は属性を「タグ」と呼びます。AWS のチュートリアルでは、リソースのタグと、操作する人（IAM ロールなど）のタグが同じかを、決まり（IAM ポリシー）の条件で比べます。次の1行は「リソースの access-project タグが、操作する人の access-project タグと同じなら」という意味です。
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}"
同じチュートリアルでは、アクセス制御に使う access- で始まるタグを、リソースから外す操作を拒否するポリシーも一緒に作っています。タグを外されると権限が変わってしまうからです。
Entra の条件付きアクセス：サインインのときに状況を見る
Microsoft 365 などにサインインするときの Microsoft Entra の条件付きアクセスも、ラベル（Microsoft の言い方ではシグナル）を集めて判断するしくみです。「もし〜なら、〜させる」という決まりで、たとえば「社外から管理者がサインインするなら、多要素認証を求める」のような判断をします。
| シグナル | 例 |
|---|---|
| ユーザー・グループ | 特定のユーザーやグループ（管理者のロールを持つ人など） |
| 場所 | IP アドレスの範囲、国や地域 |
| デバイス | プラットフォーム、準拠済み（compliant）かどうか |
| アプリ | どのアプリにアクセスしようとしているか |
| リスク | Entra ID Protection が判定したユーザーやサインインのリスク |
よく使われる決まりとして、Microsoft のドキュメントは「管理者のロールを持つ人には多要素認証を求める」「特定のアプリには組織で管理しているデバイスを求める」「レガシー認証を使うサインインをブロックする」などを挙げています。なお、条件付きアクセスが効くのは、1つ目の認証（パスワードなど）が終わったあとです。
自分の API に取り入れるには
ここからは、自社で API を作って公開するときの話です。例として、伝票を返す API で「自分の部署の伝票だけ読める」「作った人だけが直せる」という決まりを ABAC で作る場面を考えます。
まず決めるのは、ラベルをどこに持たせるかと、どこで判断するかの2つです。
| 置き場所 | 持つもの | この例では |
|---|---|---|
| Microsoft Entra ID | 人のラベル | ユーザーの部署（department）やロール。サインインのときにトークンへ入れて、API に届ける |
| 業務データベース | データのラベル | 伝票ごとの部署、作成者、機密区分などの列 |
| API のコードや設定 | 決まり | 読む：人の部署 ＝ 伝票の部署。直す：作成者 ＝ 本人。どれにも当たらなければ拒否 |
| API ゲートウェイ | 門番 | トークンが正しいか（署名や期限）を確かめ、だめなら止める |
| API のコード | 審査係 | 人のラベルとデータのラベルを決まりに当てはめ、許可か拒否を決める |
ポイントは、ラベルが2か所に分かれていることです。人のラベルはトークンに入って、リクエストと一緒に届きます。一方、データのラベルは伝票そのものと一緒にデータベースにあります。そのため、「この人がこの伝票を読めるか」は、伝票をデータベースから取り出したあとでないと決められません。ゲートウェイはトークンしか見えないので、最後の判断は API のコードで行います。
実際にリクエストが来たときの流れを、順番に並べると次のようになります。
- ①② 利用者のアプリが Entra ID にサインインし、トークンを受け取る。トークンには「部署＝営業部」のような人のラベルが入っている。
- ③④ アプリはトークンを付けて「伝票123をください」と頼む。門番（ゲートウェイ）は、トークンが本物で期限内かを確かめる。
- ⑤〜⑦ 門番が通したリクエストを API のコードが受け取り、データベースから伝票123とそのラベル（部署＝営業部）を取り出す。
- ⑧ 審査係（API のコード）が「人の部署 ＝ 伝票の部署」の決まりに当てはめる。一致したので許可。
- ⑨ 伝票を返す。部署が違うときや、ラベルが空のときは 403（権限がない）で断る。
直す（更新する）ときも流れは同じで、⑧の決まりが「作成者 ＝ 本人」に変わるだけです。部署が増えても、伝票の列に部署名が入るだけで、決まりは書き換えなくて済みます。
人のラベルをトークンに入れるには：Microsoft Entra ID のユーザーには部署（department）などの項目があります。Microsoft Graph のクレームマッピングポリシーを使うと、その部署をアクセストークンのクレームとして足せます。Microsoft のドキュメントも、ユーザーの属性をトークンに足すことで「アプリがより良い認可の判断をできる」と説明しています。トークンに入れずに、API のコードが Microsoft Graph からユーザーの部署を読みに行く作り方もあります。
OWASP の認可のチートシートも、アプリの開発では RBAC より ABAC や関係ベースの方式を勧めています。そのうえで、次の3つを求めています。図8はこの3つに沿っています。
- 既定で拒否する：決まりに当たらないとき、ラベルが空のときは断る（図8の下の 403）。
- すべてのリクエストで確かめる：一覧を見せたときに確かめたから、詳細を開くときは確かめない、ということはしない。
- サーバ側で確かめる：アプリの画面でボタンを隠すだけでは足りない。判断は API のコード（図8の⑧）で行う。
注意点
| 注意点 | 理由と対策 |
|---|---|
| 属性を変えられる人を絞る | 属性が権限そのものになるので、タグや属性を書き換えられる人は権限を変えられる。AWS のチュートリアルでも、アクセス制御用のタグを外す操作を拒否している。Azure でも、条件を足すにはロールの割り当てを書く権限が要る |
| 属性の値をそろえる | 「Cascade」と「cascade」、部署名の書き方の違いで結果が変わる。値の一覧を決めておく |
| 決まりをテストできる形に | 結果が属性の組み合わせで変わるので、「誰が何をできるか」を一覧にしにくい。代表的なパターンで、許可・拒否を確かめる手順を用意する |
| 既定は拒否 | 属性がない、決まりに当てはまらないときは拒否にする |
企業での例
| 場面 | しくみ | 決まりの例 |
|---|---|---|
| 部署ごとのファイルを Azure Storage に置き、その部署の人だけが読めるようにする | Azure の ABAC | Storage Blob Data Reader の割り当てに、「ファイルのタグと、ユーザーの属性が同じ」の条件を付ける |
| AWS 上で、プロジェクトとチームごとにシークレットを分ける | AWS のタグ | リソースのタグと IAM ロールのタグが一致するときだけ許可し、アクセス制御用のタグは外せないようにする |
| 管理者のサインインを守る | 条件付きアクセス | 管理者のロールを持つ人には、多要素認証を求める |
| 業務アプリは会社の端末からだけ使わせる | 条件付きアクセス | 特定のアプリには、準拠済みのデバイスを求める |
| 自社の業務 API で、自分の部署の伝票だけを見せる | API のコード | トークンの部署と、伝票の部署が同じなら返す。違えば拒否する |
まとめ
| 項目 | ポイント |
|---|---|
| ABAC | 人・資料・操作・状況のラベル（属性）を、決まり（ポリシー）に当てはめて判断する |
| RBAC との違い | ロールの有無ではなくラベルの見比べ。部署が増えても決まりは増えない |
| 部品 | 門番（PEP）、審査係（PDP）、ラベルの保管場所（PIP）、管理画面（PAP） |
| Azure | RBAC の割り当てに条件を足して絞り込む。今はストレージのデータ操作が対象 |
| AWS | リソースのタグと、操作する人のタグを比べる |
| 条件付きアクセス | サインインのときに、ユーザー・場所・デバイス・アプリ・リスクで判断する |
| 注意 | 属性を変えられる人を絞る。値をそろえる。テストできる形にする。既定は拒否 |
参考にした資料
この記事は、次の標準と公式ドキュメントで内容を確かめて書きました。仕様や対応状況は変わることがあるので、最新の情報はリンク先で確かめてください。
- NIST Special Publication (SP) 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations（NIST）：ABAC の定義、個々の主体に直接権限を割り当てなくてよいこと、PEP・PDP・PIP・PAP
- Authorization Cheat Sheet（OWASP）：ABAC・ReBAC を勧めること、既定で拒否、毎回の確認、サーバ側での確認
- What is Azure attribute-based access control (Azure ABAC)?（Microsoft Learn）：ロールの割り当ての条件、Chandra と Project=Cascade の例と条件のコード、使える場所と属性、条件で明示的に拒否できないこと
- What is Conditional Access?（Microsoft Learn）：シグナルと判断、if-then の決まり、よく使われる決まり、1つ目の認証のあとに効くこと
- Customize claims with the claims mapping policy in Microsoft Graph（Microsoft Learn）：ユーザーの department をアクセストークンのクレームに足す例、認可の判断のために属性を足すこと
- Define permissions based on attributes with ABAC authorization・IAM tutorial: Define permissions to access AWS resources based on tags（AWS）：属性をタグと呼ぶこと、RBAC と比べた利点、タグを比べる条件、アクセス制御用のタグを外す操作の拒否
あとがき
RBAC と ABAC は対立するものだと思っていましたが、Azure の ABAC が「RBAC の割り当てに条件を足す」形になっているのを見て、ロールで大まかに分けて属性で絞る、という組み合わせ方がしっくりきました。属性がそのまま権限になる分、タグを誰が書き換えられるかという地味な設定が大事になるところも、運用で忘れずにいたい点です。
コメント