← 概念辨析に戻る

Concept Contrast Fable

ロールによる権限付与と属性による権限付与

先に結論:RBACはロールで権限を管理し、明確で監査しやすい。ABACはユーザー、リソース、環境、タスクの属性に基づいて動的に判断し、柔軟だがガバナンスコストが高い。Agentが企業システムに接続されると、この違いは越権リスクに直接影響する。

RBACはロールで権限を管理し、明確で監査しやすい。ABACはユーザー、リソース、環境、タスクの属性に基づいて動的に判断し、柔軟だがガバナンスコストが高い。Agentが企業システムに接続されると、この違いは越権リスクに直接影響する。

寓話

倉庫の鍵と門番の条件冊

城西の倉庫には帳簿、薬材、貴重な器具が保管されていた。昔の決まりは単純だった。番頭は総鍵、会計は帳簿の鍵、薬師は薬棚の鍵を持ち、荷運び人は外倉にしか入れなかった。各自が役職に応じて鍵束を受け取り、門番は腰札を見て通した。

この方法は気楽だ。新しい経理係が入れば経理係の鍵を渡し、経理係が去れば鍵を回収する。帳簿検査のときも、誰がどの役割ゆえにどの部屋へ入れるかを説明しやすい。倉庫が拡張するまでは、誰も規律に問題があるとは思わなかった。

後に商売は複雑になった。薬師は時に帳簿のロットを見る必要があり、経理係は時に薬材コストを調べる必要があり、外城から来た臨時監査は昼間だけある種の記録を見るべきだった。職位ごとの鍵配りは粗くなり始め、門番は各例外のために臨時に鍵を追加し、鍵束はますます乱れた。

新任の門番は条件冊に切り替えました。彼は役職だけでなく、来訪者の氏名、任務、時間、貨物の種類、承認の有無も見ます。条件に合えば門を開き、合わなければ拒否します。臨時監査はついに永久鍵の束を受け取る必要がなくなり、指定された時刻に指定された帳簿を見るだけになりました。

しかし条件台帳はすぐに厚くなりすぎてめくれなくなった。二つの条件が互いに衝突し、夜勤の薬剤師は急用の記録を取れなくなった。貨物ラベルの記載が不正確なものもあり、システムは普通の生薬を貴重な器具とみなして止めてしまった。門番は毎日、なぜ門が開いたのか、開かなかったのかを説明していた。

城主はどの制度も廃止しなかった。安定した職位は依然として職位の鍵に置き、高リスク、臨時、部門横断、環境の影響を受けるアクセスは条件帳に任せた。各条件には記録が必要で、誰が規則を変え、なぜ変え、どの門に影響するかがすべて追跡できねばならない。

倉庫は秩序を取り戻した。職位の鍵は大多数の者が手順を減らせるようにし、条件冊は職位では説明できない境界を扱う。本当に厄介なところは門の多さではなく、企業が一串の鍵ですべての例外を管理できると思い込むことにある。 毎月の棚卸しでは、城主は二種類の門を抜き打ち検査する。一つは人の多い常用門で、役割がどんどん膨らむのを防ぐ。もう一つは条件が最も多い細門で、規則を誰も理解できなくなるのを防ぐ。新しいタスクが一日しか続かないなら、永久役割を新設せず、条件と有効期限を明記する。こうして倉庫は運営でき、毎回門を開ける理由も説明でき、監査が来ても確認できる帳がある。

ロールベースのアクセス制御

RBAC はユーザーの役割に基づいて権限を割り当て、職位が安定し、職責が明確で、監査要件が直接的な組織の権限管理に適している。

属性ベースのアクセス制御

ABAC はユーザー、リソース、アクション、環境、タスクなどの属性に基づいて動的に決定し、一時的な認可、細粒度のデータアクセス、複雑なコンプライアンスシナリオに適している。

物語の対応

  • 役職ごとに鍵を配る:RBACはロールで権限をマッピング
  • 一時的な監査と部門横断の閲覧:ロールモデルでは表現しにくい例外
  • 氏名、時刻、タスク、貨物カテゴリ:ABAC は複数種類の属性で認可判断を行う
  • 条件冊は厚すぎてめくれない:ABACルールのガバナンスと説明可能性のコスト
  • 安定した職位には鍵、高リスクアクセスには条件冊:企業権限体系によくある混合設計

企業Agentの権限に落とし込む

内部従業員向けツールは、まずRBACで大分類の権限を制御してよい。Agentが顧客、データ等級、タスク目的、時間と場所に応じてツールを呼び出す必要がある場合、ABACでなければ細粒度の境界を表現できない。例外承認を役割に積み上げ続けてはならず、いきなり誰も審査できない属性ルールのセットを構築してもならない。

京ICP备2026014272号