# 認可モデル ## 定義 認可モデルとは、認可(authorization、あるプリンシパルにあるオブジェクトへの操作許可を与える)・仲介(mediation、権限を持つか検査する)・剥奪(revocation、以前に与えた権限を取り消す)という3つの操作を、どのようにデータ構造として実装するかを規定する枠組みである。*Principles of Computer System Design* 第11章は3モデルを提示する: (1) **単純ガードモデル**、(2) **ケアテイカーモデル**、(3) **フロー制御モデル**(→ [[情報フロー制御]])。単純ガードモデルは、プリンシパルを行・オブジェクトを列とする認可行列(authorization matrix)に基づき、read/writeなどの権限をセルに保持する。このモデルには**チケット方式**(行指向、プリンシパル側が保持)と**リスト方式**(列指向、ガード側が保持)の2実装がある。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.1, §11.6.2) **チケット方式**では、ガードがオブジェクトごとにチケットを保持し、プリンシパルはアクセス可能な各オブジェクトのチケットを個別に保持する(鍵束の比喩)。チケット指向システムにおけるチケットは通常**ケーパビリティ**(capability)と呼ばれる(→ [[Capability-based Security]])。プリンシパルはチケットを他者へ自由に渡せるため共有が容易だが、剥奪には権限者がチケットを回収するか、ガード側のチケットを変更して残る全プリンシパルへ再発行するかしかなく、いずれも困難または破壊的である。**リスト方式**では、ガードが権限を持つプリンシパルのトークン一覧、すなわち**アクセス制御リスト(ACL)**を保持する。仲介はリスト検索を要するが、剥奪はリストからトークンを削除するだけで済み、監査(誰がアクセス権を持つか)も容易である。両者を組み合わせた**エージェンシー**(招待制会議での名簿確認+食券配布のような、リストからチケットへの一度限りの変換)という折衷案もある。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.2.1-§11.6.2.3) 大量のプリンシパルに同一権限を与える必要がある場合、複数ユーザーが共有できる**保護グループ(protection group)**が導入される。UNIXはこのモデルの具体例であり、UID/GID・`/etc/passwd`・`/etc/group`によるプリンシパル管理、inodeに格納されたowner/group/other 3エントリのみのACL、SETUIDによる一時的な権限昇格(最小権限の原則の実践例)を持つ。UNIX ACLが3エントリに限定されているため、任意のプリンシパルへ個別権限を与えられず、メール配送プログラムのような場面でSETUIDに頼らざるを得ない構造的弱点がある。**ケアテイカーモデル**は単純ガードモデルのオブジェクト指向版で、read/write/executeのような単純なメソッドではなく任意のメソッドに対して任意の制約(「午後5時30分だけ開けられる金庫」など)を強制できるが、その分プログラムが複雑化し欠陥の温床になりやすい。データベースの行・列アクセス制御が典型例である。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.2.4, §11.6.3, §11.6.4) さらに、オブジェクト作成者が自動的に権限者(authority)になる**裁量アクセス制御(discretionary access control)**に対し、作成者以外の主体が権限者となり作成者自身も変更できない**非裁量アクセス制御(non-discretionary access control)**が区別される。組織の部門長が「need to know」原則で区画を強制する場合などに用いられ、[[情報フロー制御]] の前提となる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.5) **『Building Secure and Reliable Systems』第5章は、認可の判断を運用の観点から「認証(authentication)」と切り分け、認可判断が考慮しうる属性の分類を与える**: 同章は認証を「接続してきた主体の身元を検証すること」、認可を「認証済みの主体が要求した操作を許可すべきかを判断すること」と定義したうえで、認可判断が考慮しうる属性として、要求された操作そのもの(URL、コマンド、gRPCメソッド)・引数(URLパラメータ、argv、gRPCリクエスト)・要求元(IPアドレス、クライアント証明書)・認証済みロールに関するメタデータ(地理的位置、法的管轄、機械学習による評価)・サーバー側の文脈(類似要求の頻度、利用可能な容量)の5種類を挙げる。最も単純な認可判断は、認証済みロールが特定のリソースのアクセス制御リスト(ACL)のメンバーかどうかを文字列一致で確認するものであり、これは本ページの**リスト方式**の定義とほぼ一致する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]] §A Policy Framework for Authentication and Authorization Decisions, §Advanced Controls > Using Advanced Authorization Controls) ## 横断的知見 - 本章の「チケットオリエンテッドシステムにおけるチケットは通常ケーパビリティと呼ばれる」という一次資料の記述は、既存の [[Capability-based Security]] ページの「capability = 改ざん不可能な権限トークン」という定義と正確に一致する。ただし [[Capability-based Security]] は現代のOS・コンテナサンドボックスの文脈(Capsicum、コンテナ移植など)でケーパビリティを単独の防御機構として論じるのに対し、本章はケーパビリティ(チケット方式)をACL(リスト方式)と対にした**トレードオフの一方**として位置づけ、失効の困難さという構造的弱点を明示する点で視点が異なる。両ソースを合わせると、ケーパビリティの利点(共有の容易さ、権限の局所性)と欠点(失効困難、監査困難)の両面が補完的に見える。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.2, [[Capability-based Security]] の既存記述) - **単純ガードモデルの「チケット方式/リスト方式」という抽象的な二分法が、Security Engineering第6章で実在の商用OS群の系譜として裏付けられる**: *Principles of Computer System Design* はチケット方式・リスト方式を理論モデルとして提示するにとどまるが、第6章はACL系譜(Unix由来、Linux・macOS・Android・iOS・Windowsに継承)とケーパビリティ系譜(1970年代の実験機、Plessey System 250、IBM AS/400、公開鍵証明書、近年のFreeBSD・iOS・Windows)を具体的な製品名と年代付きで並べる。特に「Unixのファイルディスクリプタは事実上ケーパビリティであり、ACLの権限やファイル所有者が変更された後もアクセスが継続する」という第6章の指摘は、単純ガードモデルの理論(チケットは失効が困難)が、ACLを基本機構とするはずのUnixの内部実装にも滲み出していることを示す実例であり、両ソースを合わせると「ACL系OSも内部的にケーパビリティ的な性質を完全には排除できない」という、理論だけでは見えない実装上の知見が得られる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.2, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.2, §6.2.4) - **UnixのSUID機構は、単純ガードモデルの限界(2次元機構による3次元問題の表現)が実際の脆弱性を生んだ一次事例である**: *Principles of Computer System Design* は認可行列を2次元(プリンシパル×オブジェクト)と3次元(プリンシパル×プログラム×オブジェクト)の両方で定式化するが、実装がどちらの次元を採用するかの帰結までは論じない。第6章は、Unix ACLが3次元を直接表現できないためSUID属性という間接手段に頼らざるを得ず、これが「プログラマが安易にSUID rootを選んでしまう」という具体的な脆弱性の温床になったと報告する。抽象モデルの限界が、実装の詳細(SUID)を経由して現実の脆弱性(過剰権限)に転化する経路を、2つのソースを重ねて初めて追跡できる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.1, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.3) - **裁量アクセス制御(DAC)/非裁量アクセス制御という二分法と、DAC/MAC(強制アクセス制御)という二分法は、同じ「作成者が権限者になるか」という軸を異なる語彙で切り取ったものだが、完全には対応しない**: *Principles of Computer System Design* の非裁量アクセス制御は「作成者以外の主体が権限者になり、部門長がneed-to-knowで区画を強制する」という組織内の権限移譲を指すのに対し、第6章のMACは「ベンダーやリモートの政府当局が強制する」という、より広い(必ずしも組織内に閉じない)強制の主体を扱う。第6章はMACの起源を軍のマルチレベルセキュリティ研究に置き、それがTPMによるtrusted bootという形でDRM目的の商用OSに合流した経緯を描く点で、非裁量アクセス制御の理論的定義よりも歴史的・産業的な文脈情報が豊富である。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.5, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.5) - **「作成者以外の主体が権限者になる非裁量アクセス制御」という抽象的な定義は、第9章によって、Anderson report(1972)とBell-LaPadulaモデル(1973)という具体的な起源と形式的性質を与えられる**: 本ページはこれまで、第6章§6.2.5が「MACの起源を軍のマルチレベルセキュリティ研究に置く」と一行で要約するにとどまり、その内実には立ち入れていなかった。第9章はこの起源を具体的に描く——1972年のAnderson reportがreference monitor/TCBという実装戦略を導入し、1973年のBell-LaPadulaモデルがsimple security property(no read up)と\*-property(no write down)という2つの形式的性質として非裁量性を定式化した。*Principles of Computer System Design* の「作成者以外の主体(部門長)がneed-to-knowで区画を強制する」という非裁量アクセス制御の定義は、BLPでは「利用者の直接行動だけでなく、利用者が実行するプログラムの間接行動までも独立に強制する」という、より厳密な要件に具体化される——これはWWMCCSがTrojan Horse攻撃に脆弱だった事件に由来する。3つのソースを合わせると、「非裁量アクセス制御」という単一の用語が、抽象的な組織論(誰が権限者か)・具体的な脅威モデル(Trojan Horseへの対処)・形式的な数理モデル(2つの読み書き制約)という3つの異なる精度で語られていることが分かる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.6.5, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.5, [[@2020__Wiley__Security Engineering 3e - Chapter 9 Multilevel Security]] ch.9 §9.3.1, §9.3.2, [[多層セキュリティ（MLS）]]) - 本章はチケット方式とリスト方式のどちらが「優れている」かの一般的な結論を出さず、Table 11.1で用途に応じたトレードオフとして提示するにとどまる。現代のクラウドIAM(AWS IAM、Kubernetes RBACなど)がこの2軸のどちらに近いか、あるいは両者を動的に折衷しているかは本章の範囲外で、別ソースの突き合わせが必要。Security Engineering第6章もAmazon AWS IAMを「サービスプロバイダが提供するさらに別のアクセス制御機構の層」として言及するのみで、AWS IAMがACL/ケーパビリティのどちらに近いかの分析は与えていない。『Building Secure and Reliable Systems』第5章は、AWS/GCPのIAMを「認証済みロールがACLのメンバーかどうかを確認する」という最も単純なリスト方式(ACL)の上に、MFA・MPAのような複雑な認可要件をレイヤーとして積み増すフレームワークだと位置づけており、少なくとも出発点はリスト方式に近いという手がかりを与える。ただし同章もIAMの内部実装の詳細(チケット的な要素を含むか)までは踏み込んでおらず、問い自体は完全には解決していない。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]] §A Policy Framework for Authentication and Authorization Decisions > Using Advanced Authorization Controls) - UNIX ACLの3エントリ制約という設計上の弱点は本章で明示されるが、より柔軟なACL(Andrew File Systemなど、本章が言及するのみ)がどのように失効・監査の困難さを解決しているかの詳細は本章に記載がない。Security Engineering第6章はPosixの拡張ACL(任意個の named user/group entity)がこの制約を緩和したと補足するが、失効・監査の困難さそのものへの解決策は同様に示されていない。 - ケアテイカーモデルの複雑性が生む脆弱性のリスクについて、本章は一般論を述べるにとどまり、具体的な緩和策(形式手法によるケアテイカー実装の検証など)は示されていない。 - Security Engineering第6章は「Multicsのようなリング機構」「ケーパビリティを持つ実験機(CAPなど)」を1960〜70年代の到達点として位置づけ、「以後の研究はこれらの基本テーマを新しい文脈(携帯電話など)で焼き直したものにすぎない」と評する。この評価が単純ガードモデル・ケアテイカーモデル・フロー制御モデルという*Principles of Computer System Design*の3モデル分類にも同様に当てはまるか(つまり2009年の教科書自体が1970年代の到達点の再整理にとどまるのか)は、両ソースの突き合わせだけでは判定できない。 - ポリシー言語の設計は、単純すぎれば認可判断がフレームワークと本体コードに分散し、汎用的すぎれば推論が困難になるという二律背反を持つと『Building Secure and Reliable Systems』第5章は指摘する。この二律背反が、本ページのチケット方式/リスト方式やケアテイカーモデルのような理論的モデルの選択とどう関係するか(特定のモデルがこの二律背反を緩和しやすいか)は、両ソースの突き合わせだけでは確定できない。 ## 関連 - ソース: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]](§11.6.1-§11.6.5) / [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]](§6.2) / [[@2020__Wiley__Security Engineering 3e - Chapter 9 Multilevel Security]](§9.3.1, §9.3.2) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]](§A Policy Framework for Authentication and Authorization Decisions) - 概念: [[Capability-based Security]](チケット方式=ケーパビリティの現代的展開) / [[情報フロー制御]](非裁量アクセス制御の発展形) / [[セキュリティ設計原則]] / [[信頼計算基盤（TCB）]] / [[多層セキュリティ（MLS）]](非裁量アクセス制御の形式的定式化としてのBell-LaPadula) / [[最小権限設計]](認可判断を集約するポリシーフレームワークへの投資) - 実体: [[Multics]](リング機構の起源、単純ガードモデルの実装史) ## 出典 - Jerome H. Saltzer and M. Frans Kaashoek, *Principles of Computer System Design: An Introduction*, Version 5.0, 2009, Chapter 11 §11.6. MIT OpenCourseWare, CC BY-NC-SA 3.0 US. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 6, §6.2. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 9, §9.3.1, §9.3.2. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 5.