← 概念辨析に戻る

Concept Contrast Fable

アクセス制御と最小権限の原則。一つは扉を管理する錠、もう一つは錠に何本の鍵が要るかを教えるもの

先に結論:アクセス制御は、アカウント、役割、権限、認証によって誰がどのリソースにアクセスできるかを決める仕組みです。最小権限の原則は安全設計の理念であり、各主体がその業務を遂行するのに必要な最小限の権限だけを持つことを求めます。アクセス制御は最小権限の原則がなくても動作します。扉は鍵をかけられます。しかし鍵をかけてみると、全員が鍵を持ち、どの鍵でもすべての扉を開けられることが分かります。

アクセス制御は、アカウント、役割、権限、認証によって誰がどのリソースにアクセスできるかを決める仕組みです。最小権限の原則は安全設計の理念であり、各主体がその業務を遂行するのに必要な最小限の権限だけを持つことを求めます。アクセス制御は最小権限の原則がなくても動作します。扉は鍵をかけられます。しかし鍵をかけてみると、全員が鍵を持ち、どの鍵でもすべての扉を開けられることが分かります。

寓話

銭荘の鉄庫には二十四の錠があり、掌门人は六つの鍵しか配らなかった

淮州通宝銭荘には地下鉄庫があり、外門が三道、内門が一道、各門に異なる錠が一基ずつ付いている。銭荘は二十四名の店員を雇い、各人が鍵束を持っていた——初建時に管事的が言ったからだ:便宜のために、三道の外門と一道の内門に入れる万能鍵を統一で配ろう。半年で、この二十四本の万能鍵と二十四名の人間の組み合わせは、鉄庫に錠がないのとほぼ同じだった。

新たに就任した大番頭の顧叔が最初に行ったのは鍵の回収だった。彼はすべての古い錠前を外し、四組の異なる仕様の錠前に交換した。そして一ヶ月をかけて「権限登記簿」を描いた。経理係の小陳は第一の外門だけを開けて帳簿を取れる。鋳銀師の老趙は第一と第二の外門に入れるが、内門には絶対に入れない。運搬工が第一の門に入るには管事の同行が必要。最後に内門に入れるのは顧叔自身と副番頭一人だけであった。

店員たちが集団で抗議した。以前は一つの鍵でどこへでも行けたのに、今は歩くのにも誰かに開けてもらわなければならず、仕事が遅くなった。顧叔は桐油の桶と書類の束を持ち出し、二十四本の古い鍵をすべて回収して油に浸し、廃鉄として封印した。そして登記簿を開いて言った。お前たちの以前の権利は「便利」ではなく「漏洞」だった。我々のこの銭荘が賊の一団に誰か一人を綁され、鍵を奪われたら、全庫が空になる。なぜなら、各人の手にある鍵は庫管のものと全く同じだからだ。

顧叔は「鍵をかけるな」と言っているのではない。鍵をかけることを前提に、誰が鍵を持ち、どんな鍵を持ち、なぜ持てるのかを再定義しているのだ。彼のやり方では扉の鍵の価値を否定しておらず、四つの扉の鍵は依然として完全だ。しかし鍵の配布を「全員が一本の万能鍵」から「各人にちょうど必要な分だけ」へ変えた。

顧叔が特にこだわった細部が一つある:登録簿の権限には「倉庫に入れる」と書いてはならず、「第一の外門:毎週月曜から金曜の辰時から酉時まで、帳簿を持ち出す」と書かなければならない。時間、空間、目的の三要素が欠かせない。経理係が帳簿を取るなら、ついでに銀箱に触れてはならない。荷役が木箱を運ぶなら、内門の鍵がどこにあるかを知ってはならない。

半年後、銭荘は一度盗難に遭った。賊は裏庭から塀を越えたが、最初の外門しか入れなかった。二番目の門の鍵を持っていなかったため、巡回隊にその場で捕まった。もし旧制の万能鍵のままであれば、四つの門はこの賊にとって数歩余分に歩くだけだった。この話が広まると、周辺の三家の銭荘が顧叔の権限登録簿を学びに人を派遣した。しかしそれは結局、錠前の作り方を学んでいるのではない——錠前の技術は常に進歩している——、鍵を発行する原則を学んでいるのが要点だった。

顧叔は後に登録簿を調べるとき、決して「錠前は頑丈か」とは尋ねず、「なぜこの鍵がこの人に渡されたのか」と尋ねました。錠は入れるかどうかを管理し、鍵を渡す原則は入るべきかどうかを管理します。錠前がどんなに良くても、誰もが万能鍵を持っていれば、鉄庫には境界がありません。

アクセス制御

認証、認可判断、アクセス実行の仕組みを組み合わせたもので、ユーザー管理、ロール定義、権限割り当て、ポリシー実行を含む。「扉がどこにあり、錠がどんな形か」を定義する実行レイヤーである。

最小権限の原則

各主体がタスク完了に必要な最小限の権限集合のみを得ることを求める安全設計原則。権限を与えること自体を禁じるのではなく、「なぜこの権限が必要か」という回答が毎回成り立つことを求める点が鍵である。これは設計原則であり、具体的なツールではない。

物語の対応

  • 二十四本の万能鍵:アクセス制御機構はあるが権限が完全に制御不能——錠前はまだあるが、鍵が氾濫
  • 顧叔は鍵を回収して錠を替える:最小権限の原則を実施する——錠の価値を否定するのではなく、鍵を再配分する
  • 権限登録簿の三要素(時間、空間、目的):現代の細粒度権限の設計原型
  • 作業員が遅いと抗議:安全と利便性の永遠の緊張、最小権限は通常摩擦を増やす
  • 賊は最初の門で捕まった:最小権限の実際の攻撃における多層防御効果
  • 周辺の両替商が鍵の発行原則を学びに来た。最小権限は設計手法であり、錠前の製品セットではない。
  • IAM ロール設定災難:アクセス制御はあるが最小権限に違反する古典的ミス

クラウドプラットフォームの権限監査とロール設計に落とし込む

IAM 権限監査を行う時は、ロールにどのポリシーがバインドされているかだけを見てはいけない——各ユーザーのポリシー和集合を調べ、「この権限は実際に使われているか?」と問う。あるデザイナーが SQL コンソール権限を持っているのに一度もログインしないなら、ポリシー自体がどれほど規範的に書かれていても、この認可はすでに最小権限に違反している。新しいロールを作る時はゼロ権限から始め、リソースアクセスを一つ加えるごとに理由を一段書く。広範なデフォルトテンプレートから削っていくのはやめる——削り忘れた一条まで。従業員が異動または退職するたびに、権限収束監査を一度行い、歴史的に蓄積された余分な認可を一度に回収する。

京ICP备2026014272号