関係ベースアクセス制御(ReBAC)とGoogle Zanzibar
1. 概要
定義: 関係ベースアクセス制御(ReBAC, Relationship-Based Access Control)とは、主体(ユーザー)と客体(リソース)の間に存在する「関係(relation)」を認可判断の第一の根拠とする認可モデルであり、Google Zanzibarはこのモデルをグローバル規模で一貫して実装した認可システムの代表的な設計である。
初期のアクセス制御は、リソースに権限リストを直接付与するACL(Access Control List)から出発し、組織が大きくなるにつれて役割に権限を束ねるRBAC(Role-Based Access Control)へと発展した。RBACは「同じ仕事をする人は同じ権限を持つ」という前提ではよく機能するが、現代の協業サービスは「この文書を作成した人」「このフォルダを共有された人」「この組織の構成員でありかつ特定プロジェクトに招待された人」のように、リソースとユーザーの間の具体的な関係によって権限が定まる場合が支配的である。こうした要求をRBACの役割数を増やして表現すると、役割がリソース数に比例して爆発する「役割爆発(role explosion)」問題が発生する。
ReBACは権限を「ユーザーUはリソースRに対して関係Relを持つか」というグラフクエリに還元する。たとえば「Aliceは文書doc:readmeを閲覧できるか」は、「Aliceはdoc:readmeのviewerか、あるいはeditor・ownerか、またはdoc:readmeが属するフォルダのviewerか」という関係探索に変わる。この観点は、Google Drive・GitHub・Slackのように数億のユーザーと数十億の客体を扱うサービスで、きめ細かな権限(fine-grained authorization)を自然にモデル化する。
ReBACが注目されるもう一つの理由は、認可ロジックの外部化・集中化の流れと接しているためである。かつては各アプリケーションが権限判断を内部に散りばめて実装していたが、マイクロサービスが増えると同じ権限の問いをサービスごとに重複実装し、互いに異なって解釈する不整合が大きくなった。権限モデルとデータを一つの専用サービスに集め、各サービスがCheck APIのみを呼び出すようにすれば、ポリシーの一貫性・監査・変更管理が一箇所に収束する。ReBACは、この中央認可サービスが扱うのに適した統一的なデータモデル(関係タプル)を提供する点で構造的な利点がある。
Googleは2019年のUSENIX ATC論文でZanzibarを公開した。ZanzibarはGoogle Drive、Calendar、Cloud、YouTube、Photosなど多数のサービスの認可を担い、論文によれば数兆(trillions)個の関係タプルと毎秒数百万件の権限検査を扱いながら、95パーセンタイルのレイテンシ10ms未満、可用性99.999%以上を達成したと報告している。この主題の核心は単に「関係で権限を見る」という概念ではなく、グローバル分散環境で正確性(とりわけ権限取り消しの一貫性)と低レイテンシを同時に満たす設計技法にある。技術士の答案では、モデル・データ構造・一貫性メカニズム・運用上のトレードオフをあわせて扱う必要がある。
2. アクセス制御モデルの進化とReBACの位置
2.1 ACL → RBAC → ABAC → ReBAC
アクセス制御モデルは「権限を何に結合するか」によって区分される。ACLはリソースごとに(主体, 許可動作)の対を列挙する。表現は直観的だが、ユーザーが増えると管理が難しく、「このユーザーがアクセス可能なすべてのリソース」を問う逆方向クエリが高価である。RBACはユーザー・役割・権限の3階層で管理負担を減らしたが、リソースごとに異なるきめ細かな共有を表現しにくい。
ABAC(Attribute-Based Access Control)はユーザー・リソース・環境の属性とポリシー規則(例: 「部署=財務 AND 時間=業務時間」)で柔軟性を確保するが、ポリシーが複雑になると「なぜこの権限が許可/拒否されたか」を追跡しにくく、大規模クエリ性能を保証しにくい。ReBACは権限を関係グラフの到達可能性(reachability)問題に還元し、きめ細かさと説明可能性を同時に得る。実務ではReBACを基本骨格とし、ABAC式の条件(contextual tuple, caveat)で補強するハイブリッドが増えている。
| モデル | 権限結合対象 | 強み | 限界 |
|---|---|---|---|
| ACL | リソースごとの主体リスト | 直観的、きめ細かい | 逆方向クエリ・大規模管理の難度 |
| RBAC | 役割 | 管理が単純、組織マッピング容易 | 役割爆発、リソースごとの共有表現が困難 |
| ABAC | 属性・ポリシー式 | 柔軟、動的条件 | デバッグ・性能・一貫性保証の難度 |
| ReBAC | 客体間の関係グラフ | きめ細かさ+説明可能、階層継承 | グラフ探索コスト、実装の複雑さ |
この比較で重要なのはモデルの優劣ではなく適用文脈である。組織構造中心の全社権限はRBACが、規制ベースの動的判断はABACが、共有・協業中心の製品権限はReBACが有利である。ZanzibarはReBACを中心に据えつつ、グループメンバーシップでRBACを、条件付きタプルでABAC要素を吸収した設計とみなせる。
2.2 関係タプルというデータモデル
Zanzibarのすべての権限は関係タプル(relation tuple)一つの形で保存される。表記は⟨object⟩#⟨relation⟩@⟨user⟩であり、たとえばdoc:readme#viewer@user:aliceは「readme文書のviewerはalice」を意味する。ユーザーの位置には個別ユーザーだけでなく、他の集合を指すusersetが来ることができる。doc:readme#viewer@group:eng#memberは「engグループのmember全員がreadmeのviewer」という関係を一つのタプルで表現する。
この「userset rewrite」能力がReBACの表現力を生む。グループメンバーシップ、フォルダ継承、役割階層がすべて「関係が別の関係を参照する」形に統一されるからである。権限検査は結局、これらのタプルが成す有向グラフで「ユーザーノードが(客体, 関係)ノードに到達可能か」を探索する問題になる。タプルは単純な行(row)なので水平拡張が容易であり、関係の追加・削除がすなわち権限の付与・取り消しになる点で監査(audit)にも有利である。
2.3 役割爆発の具体的な例
役割爆発がなぜ致命的かは数値で見ると明らかである。1万個のプロジェクトがあり、各プロジェクトごとにviewer・editor・adminの3水準のアクセスが必要な協業ツールを仮定しよう。RBACでこれを表現するにはproject-1-viewer、project-1-editor…のようにプロジェクト数 × 権限数 = 3万個の役割が必要であり、プロジェクトが10万個に増えれば役割は30万個になる。役割自体がリソース数に比例して増加するため、役割ディレクトリの管理・検索・監査がすべて崩壊する。
ReBACは同じ要求をproject:123#editor@user:aliceのようなタプル一つで表現する。役割という中間概念をリソースごとに複製せず、リソースとユーザーの関係を直接記述するからである。継承が必要ならproject:123#viewer: editor or adminのようにネームスペース規則で一度だけ宣言すればすべてのプロジェクトに適用される。このように「宣言は一度、データは関係で」という分離が、大規模なきめ細かい認可でReBACが選択される最も実質的な理由である。
3. Zanzibarのアーキテクチャと動作原理
flowchart LR
App["クライアントサービス(Driveなど)"] -->|"Check/Read/Write/Expand"| ACL["aclserver(権限検査)"]
ACL -->|"関係タプル照会"| SP["Spanner(グローバル分散DB)"]
ACL -->|"キャッシュ照会"| LH["Leopard(集合インデックス)"]
SP -->|"変更ログストリーム"| LH
App -->|"書き込み時のcontent version"| ACL
ACL -->|"zookie(一貫性トークン)を返す"| App
SP -->|"TrueTimeタイムスタンプ"| ACL
上記の構造で、クライアントサービスは自らの権限ポリシーをZanzibarにネームスペース構成(namespace config)として登録し、実際の権限変更はWriteでタプルを入れたり外したりし、権限判断はCheck APIで照会する。中核APIは四つである。Check(「UはRに対して関係を持つか」)は許可/拒否を返し、Readは保存されたタプルをそのまま照会し、Expandは特定の(客体, 関係)の全ユーザー集合をツリーに展開してデバッグ・権限閲覧に使われ、Writeはタプルを変更する。
ストレージ層はGoogle Spannerである。Spannerの外部一貫性(external consistency)とTrueTimeグローバル時計のおかげで、すべてのタプル変更にグローバルに比較可能なタイムスタンプを付けられる。このタイムスタンプが、後述する一貫性トークン(zookie)の土台になる。権限検査は読み取り負荷が圧倒的なので、頻繁に問われる(客体, 関係)集合はLeopardという別の集合インデックスシステムが非同期に具体化(materialize)し、深いグループ入れ子の探索コストを下げる。
3.1 権限検査の評価過程
sequenceDiagram
participant C as クライアント
participant A as aclserver
participant S as Spanner
C->>A: "Check(doc:readme#viewer@alice, zookie)"
A->>A: "ネームスペース規則の解釈(viewer = viewer ∪ editor ∪ parent.viewer)"
A->>S: "doc:readme#viewerタプル照会"
S-->>A: "editor@aliceなし、parent=folder:eng"
A->>S: "folder:eng#viewer照会(再帰)"
S-->>A: "group:eng#member@aliceにマッチ"
A-->>C: "許可(allowed)、評価結果をキャッシュ"
権限検査はネームスペース構成に定義された規則に従って関係を展開する。たとえば「viewerはeditorを含み、上位フォルダのviewerを継承する」という規則があれば、doc:readme#viewer検査は直接タプル → editorタプル → 上位フォルダviewerへとつながる有向グラフ探索で実行される。この過程は深さが深くなり得るので、Zanzibarは下位クエリを並列化し、頻繁に使う中間結果をキャッシュし、人気のある客体に集中する「ホットスポット」を緩和するためにリクエスト重複排除とキャッシュキーのシャーディングを適用する。
評価結果の正確性を損なわずに深い入れ子を速く処理するため、Zanzibarは各下位問題を独立にキャッシュ可能な単位に分割する。たとえばgroup:eng#memberの構成員集合は複数の文書検査で繰り返し参照されるので、一度計算して再利用する。また、同一の(客体, 関係, ユーザー)クエリが短時間に殺到すると(例: 人気の公開文書)、重複リクエストを一度だけ評価するように束ねる「request hedging・deduplication」でバックエンド負荷を減らす。
3.2 一貫性とzookie — 「新規権限の適用」と「取り消しの即時性」の均衡
認可システムで最も危険な誤りは権限取り消しの反映が遅れることである。キャッシュのためにすでに共有を解除した文書を依然として見られるなら、深刻な情報漏洩である。逆に、すべての検査を常に最新データで強い一貫性で実行すれば、レイテンシとコストが爆発する。Zanzibarはこの緊張をzookieという一貫性トークンで解決する。
クライアントがコンテンツを保存するとき、Zanzibarが発行したzookie(内部的にはSpannerタイムスタンプ)をあわせて保管する。以後、そのコンテンツに対するCheckは、zookieが指す時点以上のスナップショットで評価するよう保証する。これにより「コンテンツ変更より古いACLで判断する」逆転を防ぎ、new-enemy問題(権限取り消し後に新しく追加されたコンテンツが古い権限で露出したり、共有が変わったのに古い順序で判断される誤り)を防止する。平常時のCheckはやや過去の一貫したスナップショットを使ってキャッシュ命中率を高めレイテンシを下げつつ、正確性が必要な地点はzookieで下限をかける。これは「常に最新」ではなく「必要なだけの最新」を設計で保証する典型例である。
new-enemy問題を具体的に見ると二つのシナリオがある。第一に、AliceがBobを文書から削除した直後に秘密の内容を追加したが、権限検査が削除以前のスナップショットで評価されると、Bobが新しい内容を見てしまう。第二に、AliceがBobの権限を上げてすぐに機微な文書をそのフォルダに移したが、二つの変更の順序が入れ替わって評価されると、意図と異なる露出が生じる。zookieは「コンテンツの現在の状態を作ったACLの時点以上」を強制することで、こうした順序逆転を源から遮断する。すなわち、性能のためのキャッシュ・スナップショット最適化が権限取り消しの安全性を決して犠牲にしないようにするのが核心である。
4. 実装エコシステムと比較
Zanzibarは論文のみで公開されたので、オープンソース・商用実装がエコシステムを成す。代表的にはCNCFサンドボックスのOpenFGA(Auth0/Okta主導)、SpiceDB(AuthZed)、Ory Keto、そしてAuth0 FGA・AuthZed Cloudのようなマネージドサービスがある。各実装はZanzibarのタプル・ネームスペース・Check/Expandの概念を共有しつつ、一貫性モデルと運用利便性で差がある。
| 実装 | 主導 | 特徴 | 備考 |
|---|---|---|---|
| OpenFGA | Okta(Auth0) | DSLベースのモデル、CNCFサンドボックス | コミュニティ活発、多言語SDK |
| SpiceDB | AuthZed | zookie類似のZedToken、caveat(条件付き)対応 | Zanzibarに最も忠実、Postgres/Spannerバックエンド |
| Ory Keto | Ory | Goベース、Oryエコシステム統合 | 軽量、セルフホスト |
| Google Zanzibar | Google内部 | 原本、Spanner+Leopard | 非公開(論文のみ公開) |
実装間の最も重要な実務上の違いは一貫性制御の方式である。SpiceDBのZedToken、OpenFGAのconsistencyオプションのように、zookieに相当するメカニズムをどう露出するかがアプリケーションの正確性を左右する。たとえば金融サービスの決裁ラインの変更のように取り消しの即時性が重要な場合は「完全一貫(fully consistent)」クエリを、公開投稿の露出のように多少の遅延が許される場合は「最小遅延(minimize latency)」クエリを選ぶというように、リソースごとに一貫性の等級を設計する。
4.1 レガシー権限のReBAC移行の例
仮想の文書協業サービスが従来、関係表(doc_permissions(doc_id, user_id, role))で権限を管理していたとしよう。移行の第一段階は、これらの行をそのまま関係タプルに写像(mapping)することである。doc_permissions(42, alice, editor)一行はdoc:42#editor@user:aliceタプル一つになる。数千万行ならバッチで一括Writeするが、移行中にも新規の権限変更が続けて発生するので、変更キャプチャ(CDC)で移行以降のデルタを同期する。
第二段階は、アプリケーションコードの分散した権限判断ロジック(複数サービスに散らばったif user.role in (...))を単一のCheck呼び出しに置き換える作業である。このとき直ちに切り替えず、既存ロジックとReBAC判断を同時に実行して結果を比較(shadow mode)する。たとえば一日1億件の権限判断で不整合が0.001%未満に収束すれば、はじめてReBACを権威ある決定点に昇格する。この段階的移行が省略されると、モデリング誤りが運用事故に直結するので、実際の大規模移行では最も多くの時間がこの検証段階に投入される。
もう一つの実務上の考慮はスキーマ(モデル)設計である。OpenFGA DSLでdefine viewer: [user] or editor or viewer from parentのように関係と継承を宣言するが、このモデリングが誤るとグラフが過度に深くなってレイテンシが大きくなったり、意図しない権限漏れが生じる。実際の導入事例で最も多い失敗はモデリング誤りとタプル同期漏れであり、既存システムの権限データをタプルに移行する設計がプロジェクトの成否を分ける。
5. 深化 — 導入パターンと最新動向
現場の導入はおおむね三段階で進む。第一は中央権限モデルの定義で、散らばったif文ベースの権限ロジックをOpenFGA/SpiceDBモデルに収束させる。第二は二重運用(shadow)検証で、既存の権限判断とReBAC判断を同時に実行し、不整合をログで比較して安全に移行する。第三は完全移行で、アプリケーションはCheck APIのみを呼び出し、権限変更はWriteで一元化する。この過程でデータ変更(共有/取り消し)とタプル書き込みを同じトランザクション境界で束ねて不整合を防ぐことが重要である。
最新動向としては、第一に条件付き権限(caveat/contextual tuple)の拡散である。「業務時間にのみ」「特定IP帯域からのみ」のようなABAC式の条件をタプルに結合し、ReBACとABACを融合する。第二にAIエージェント・非定型ワークロードの認可である。エージェントがユーザーに代わってリソースにアクセスするとき、「ユーザー・エージェント・リソース」の委任関係をタプルで表現しようとする試みが増えている。第三に標準化の議論で、きめ細かな認可(Fine-Grained Authorization)を外部化・集中化する流れが、ゼロトラストのポリシー決定点(PDP)概念と噛み合って拡散している。第四に、OpenFGAのCNCF昇格と各クラウドのマネージドFGAの投入により、「認可をサービスとして消費する」モデルが定着しつつある。
とりわけ国内では、公共・金融分野のきめ細かなアクセス制御要求と個人情報保護法上のアクセス権限管理・アクセス記録保存の義務が噛み合い、権限付与・取り消しの追跡性と証憑が重要になっている。関係タプルベースのモデルは「誰がいつどの関係を通じてアクセス権限を得たか」をデータとして残すので、監査ログ・アクセス制御の証跡と自然に結合する。逆に、ABAC式の複雑なポリシー式のみでは事後の説明が難しい点が対比される。
予想される出題方向としては、① ReBACとRBAC/ABACの比較および適用基準、② Zanzibarのzookieと一貫性保証メカニズムの説明、③ 関係タプル・userset rewriteの概念と権限グラフ探索、④ きめ細かな認可の外部化がゼロトラスト・マイクロサービスアーキテクチャに与える含意などが有力である。答案では必ず「なぜ大規模でReBACが必要か(役割爆発)」と「正確性・レイテンシのトレードオフをどう設計で解決したか(zookie)」を核心の軸として叙述するのがよい。
6. 考慮事項および示唆点
第一に、正確性とレイテンシのトレードオフをリソース等級別に設計すべきである。 すべてのCheckを完全一貫にすればレイテンシ・コストが過度であり、すべてをキャッシュ優先にすれば取り消し漏れのリスクがある。リソースの機微度に応じて一貫性等級(完全一貫 vs 最小遅延)を分離し、取り消しが致命的なリソースはzookie下限を明示的にかけるべきである。
第二に、権限データとビジネスデータの同期をトランザクションで保証すべきである。 共有解除は成功したのにタプル削除が失敗すれば、幽霊権限が残る。変更イベントベース(outboxパターン)や2段階書き込み戦略で「データ・タプル不整合」を構造的に除去し、周期的な整合性監査とExpandベースの検証を運用に含めるべきである。
第三に、モデル設計とガバナンスが性能とセキュリティを同時に決定する。 関係グラフが過度に深いか循環するとレイテンシが大きくなり、継承規則が曖昧だと過大権限が生じる。モデル変更に対するレビュー・バージョン管理・影響度分析(この変更がどのユーザーの権限を変えるか)を、ポリシーのコード化(Policy as Code)と結合して運用すべきである。
第四に、認可の外部化は組織・アーキテクチャ戦略とともに進めるべきである。 きめ細かな認可を中央サービスに分離すれば一貫性と監査が容易になるが、すべてのサービスがCheckに依存するので、可用性・レイテンシの単一の要衝になる。地域複製、キャッシュ層、障害時のfail-safe(既定拒否)ポリシー、そして権限サービス自体のSLO管理が前提とされ、ゼロトラストのPDP/PEP分離原則と整合するように設計すべきである。
第五に、ベンダー・実装依存性と移植性を考慮すべきである。 Zanzibarモデルは共通だが、一貫性トークン・条件付きタプル・スキーマDSLは実装ごとに異なる。モデルを抽象化層の背後に置き、中核の権限ロジックが特定製品のAPIに過度に結合しないように設計すれば、将来の移行コストを減らせる。
第六に、性能・コストの観測性を運用指標として管理すべきである。 きめ細かな認可はリクエスト経路ごとにCheckを呼び出すので、呼び出し数・p95/p99レイテンシ・キャッシュ命中率・グラフ探索の深さがサービス品質を左右する。これらをダッシュボードで常時観測し、深さが過度なモデルはリファクタリングし、集合クエリが多いリソースは具体化インデックスで先手を打つべきである。認可がすべてのリクエストの臨界経路に入る以上、認可サービスの容量計画とコスト(FinOps)管理を別課題とするのが望ましい。
参考資料
- Google, "Zanzibar: Google's Consistent, Global Authorization System", USENIX ATC 2019: https://research.google/pubs/pub48190/
- USENIX ATC '19 発表資料(Zanzibar): https://www.usenix.org/conference/atc19/presentation/pang
- OpenFGA(公式ドキュメント): https://openfga.dev/docs
- AuthZed SpiceDB(公式ドキュメント): https://authzed.com/docs
- Ory Keto: https://www.ory.sh/keto/
一言まとめ: ReBACはユーザーとリソースの「関係」を権限判断の軸とし、大規模なきめ細かい認可の役割爆発を解決するモデルであり、Google Zanzibarは関係タプル・userset rewrite・zookie一貫性トークンによってグローバル規模で低レイテンシと取り消しの正確性を同時に達成した代表的な設計である。