# 最小権限設計 ## 定義 最小権限設計とは、人間・自動化タスク・個々のマシンのいずれであっても、与えられたタスクの遂行に必要な最小限のアクセスだけを許可し、その制約をあらゆる認証・認可層に貫かせるという、システム設計の実践的な運用体系である。前提となるのは「人間は完璧ではない」という現実であり、悪意の有無にかかわらず、誤字・コピペミス・フィッシング被害・内部不正のいずれもがいつか起こりうる以上、権限そのものを絞ることで被害の範囲を限定するという発想を取る。この体系は単一の技法ではなく、(1) リスクに基づくアクセス分類、(2) 小さな機能別APIへの管理操作の分解、(3) breakglassメカニズムによる例外対応、(4) 構造化された正当化に基づく監査、(5) 多者承認(MPA)・三要素認可(3FA)・業務上の正当化・一時的アクセス・プロキシといった高度な制御、という5つの柱の組み合わせとして実装される。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]] §Concepts and Terminology > Least Privilege, §Classifying Access Based on Risk, §Best Practices, §Advanced Controls) 最小権限設計は、ゼロトラストネットワーキング(ネットワーク上の所在地に特権を与えない)と Zero Touch(自動化によって人間の本番への直接アクセス自体を取り除く)という2つの隣接する設計思想の上に成り立つ。ゼロトラストネットワーキングがネットワーク層での信頼の否定であるのに対し、Zero Touchは人間そのものをアクセス経路から間接化する、より踏み込んだ発展形として位置づけられる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]] §Concepts and Terminology > Zero Trust Networking, Zero Touch) ## 横断的知見 - **抽象的な原則(1975年)と運用体系(2020年)という2つの層が、45年の時間差を挟んで同じ結論に収束している**: [[セキュリティ設計原則]] が扱う Saltzer & Schroeder の Least privilege principle(1975年、「宝石を入れた金庫に弁当を入れるな」)は、特権プログラムが必要な操作の間だけ特権を持つべきだという抽象的な規範を1文で述べるにとどまる。本概念が扱う本書第5章は、この同じ原則を「リスクに基づくアクセス分類」「小さな機能別API」「breakglass」「MPA・3FA・一時的アクセス」という5つの具体的な運用パターンにまで分解し、Googleが実際にどう組織的に実装したかを詳述する。両者を合わせると、45年前に定式化された抽象原則が、現代の大規模分散システムにおいてどのような技法群として翻訳されたかという系譜が具体的に追跡できる。興味深いことに、本章がUnix文化の引用として掲げる McIlroy, Pinson, and Tague (1978)の「1つのプログラムに1つのことをうまくやらせよ」という格言は、Saltzer & Schroeder (1975)の Economy of mechanism(機構が少ないほど正しく作れる)と、時期・出自(いずれもBell研究所系)を近くしながら独立に同じ帰結(機構を小さく保つことが安全性を生む)に到達しており、モジュール性とセキュリティの結びつきが単一の学派の主張ではないことを示唆する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]] §Best Practices > Small Functional APIs, [[セキュリティ設計原則]] の既存記述) - **同一書籍の別章(第3章)がすでに示していた具体例が、第5章によって一般原則として体系化される**: [[セーフプロキシ]] が扱う本書第3章のGoogle Tool Proxyは、borg killのような危険なコマンドをプロキシ経由に強制し、ポリシー確認・MPA承認・監査ログという3段階の制御を課す具体的な実装事例である。第5章はこの同じ発想を、"Small Functional APIs"(大きなPOSIX APIを分解する)・"Multi-Party Authorization"(狭いスコープのAPIに対する承認ほど承認者が正確に把握できる)という一般原則として抽象化し直しており、第3章の事例が第5章のどの一般原則の実例に当たるかを対応づけられる。加えて、第3章が「Zero Touch Prodがあれば防止・緩和できた障害が約13%」という定量的な裏付けを持つのに対し、第5章はこの定量的評価を繰り返さず、もっぱら設計技法の解説に紙幅を割く。両者を合わせて初めて「一般原則(第5章)」と「効果の実測値を伴う具体的な導入事例(第3章)」の両輪が揃う。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]] §Best Practices > Small Functional APIs, §Advanced Controls > Multi-Party Authorization (MPA), [[セーフプロキシ]] の既存記述) - **「大きなAPIは最小権限を表現しにくい」という第5章の診断は、認可モデルの理論的な機構の限界という、独立した角度からの診断と同じ結論に至る**: 第5章はPOSIX APIのような大きな管理APIについて、対話セッション中のユーザーの行動を制約・監査しづらいという運用上の欠点を指摘し、小さな機能別APIへの分解を処方箋とする。一方 [[認可モデル]] が扱う Security Engineering 第6章は、UnixのACLが(プリンシパル, プログラム, オブジェクト)という3次元のアクセス制御を表現できないためSETUIDという間接手段に頼らざるを得ず、これが実際の脆弱性の温床になったと報告する。前者は「APIの粒度」という運用者視点の診断、後者は「認可行列の次元数」という理論的な機構の限界からの診断であり、出発点は異なるが、いずれも「表現力の低い大きな管理インターフェースが過剰な暗黙の権限を生む」という同一の病理に行き着いている。第5章の処方箋(APIを分解する)は、認可モデル側の脆弱性(SUID root)を生む構造的原因そのものを取り除く方向の対策になっていると解釈できる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]] §Best Practices > Small Functional APIs, [[認可モデル]] の既存記述) ## 未解決の問い - 第5章のリスクに基づくアクセス分類(公開・機密・高度機密の3分類)は、本wikiが扱う多層セキュリティ(MLS)の形式的な機密性レベル(Bell-LaPadulaのno read up/no write down)とどこまで対応するか、あるいは緩やかなラベリングにとどまり形式的な保証を持たない点で本質的に異なるかは、[[多層セキュリティ（MLS）]] 側の記述と突き合わせて検討する必要がある。 - 3FAが防ぐ「均質なワークステーション群への広範な侵害」という脅威モデルは、[[生体認証]] や [[パスキー認証]] のようなハードウェア結合型認証の脅威モデルとどこまで重なり、どこで補完関係にあるかは未検討。 - 本章はMPA・3FA・業務上の正当化・一時的アクセス・プロキシを「組み合わせて使える」と述べるにとどまり、複数の高度な制御を同時に課したときの累積的な生産性コスト(承認待ち時間の合算など)を定量的に扱っていない。他ソースに運用データがあれば横断的知見に昇格させる。 - 本章の「構造化された正当化」(チケット番号への紐づけ)は監査の自動検証を可能にすると述べるが、正当化そのものが偽装される可能性(存在するが無関係なチケット番号を流用する等)への対策は本章の範囲外であり、他ソースでの補強が必要。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 5 Design for Least Privilege]](全節) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 3 Case Study - Safe Proxies]](§Safe Proxies in Production Environments、§Google Tool Proxy) - 概念: [[セキュリティ設計原則]](Saltzer & Schroeder の抽象的な最小権限の原則) / [[認可モデル]](認可行列の次元数という理論的な機構の限界) / [[ゼロトラスト]](ゼロトラストネットワーキングとの関係) / [[セーフプロキシ]](プロキシによる高度な制御の具体的実装) - 実体: [[Zero Touch Prod]] ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 5. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 3.