RBACの仕組み — 「閲覧者」と「編集者」でできることを分ける

ひよこ

記事を読める人と、直せる人をどう分けるの？

ペンギン先生

「閲覧者」と「編集者」のようなロールを作り、ロールへ許す操作をまとめる方法があるよ。人にロールを割り当て、どの操作ができるか決める。これがRBACの入口だね。

ひよこ

ログインできたら、編集してもいい？

ペンギン先生

本人だと確認する認証と、操作を許す認可は別だよ。ログインできても閲覧者なら編集は許さない設計にできる。画面のボタンを隠すだけでなく、サーバー側でも確認するんだ。

ひよこ

ユーザーに直接権限を付けるのとは違う？

ペンギン先生

RBACのモデルでは権限をロールに結び、人とロールを対応させるよ。必要な操作のまとまりを管理しやすくなる。ただし実際のサービスには、直接付与や別の制御も混ざることがあるね。

ひよこ

編集者は、必ず削除や公開もできる？

ペンギン先生

ロール名だけでは決まらないよ。この例は読み取りと編集だけを許し、削除は別にする。名前ではなく許可する操作、対象、範囲を確かめよう。

ひよこ

ロールには、いつも階層があるの？

ペンギン先生

階層は拡張の仕組みで、どの実装も同じように対応するわけではないよ。役割の分離や、セッションで有効にするロールの考え方もある。使うサービスのモデルを調べよう。

ひよこ

Kubernetesも、こんな役割で分ける？

ペンギン先生

Role等で権限を定義し、RoleBinding等で利用者と結び付けるよ。namespace内かクラスタ全体かも重要。RBACの許可は加算で、ロールにdenyを書いて打ち消す方式ではないんだ。

ひよこ

AWSのIAMロールなら、そのEC2だけが使えるの？

ペンギン先生

そうとは限らないよ。誰がロールを引き受けられるかという信頼ポリシーと、何ができるかの権限等で決まる。引き受けると一時的な認証情報を使う。RBACの役割表と完全に同じ仕組みとしては扱わないよ。

ひよこ

異動したら、ロールを外すだけで終わり？

ペンギン先生

別経路の権限や有効なセッション等も含めて確かめるよ。必要最小限の操作にし、付与・変更・利用の記録を見直す。緊急時の権限も、終了条件と確認の手順を先に用意するんだ。

まずは、記事を読む係と直す係を分ける

同じサイトでも、記事を読む人と直す人では必要な操作が違います。RBAC（Role-Based Access Control）は、役割に許す操作をまとめ、人へその役割を割り当てる考え方です。

この例では、編集者にも削除は許していません。「管理者」「編集者」などの名前だけで操作が決まるわけではありません。

小さく試す：権限を調べる

Python 3が使えるなら、rbac-demo.pyとして保存し、python rbac-demo.pyで試せます。

permissions = {
    "viewer": {"read"},
    "editor": {"read", "edit"},
}
roles = {"aoi": {"viewer"}, "midori": {"editor"}}

def can(user, action):
    return any(
        action in permissions.get(role, set())
        for role in roles.get(user, set())
    )

print(can("aoi", "edit"))
print(can("midori", "edit"))
print(can("midori", "delete"))

False
True
False

この例は、対応表を調べる練習です。本人確認、対象の記事、組織の境界、セッション等を実装した本番用の認可機構ではありません。本番ではボタンの表示だけでなく、操作を実行する側で必要な条件を検証します。

人・ロール・権限を分ける

NISTのRBACでは、人とロール、ロールと権限の対応が基本です。セッションで割り当てられたロールの一部を有効にする考え方もあります。階層や静的・動的な職務分離は追加のモデルなので、すべての製品に同じ機能があるとは考えません。

たとえば承認を申請した本人が承認できないようにする目的には、ロール名を増やすだけでなく、対象や操作の関係も考えます。ABACの属性等と組み合わせる場合も、どこで何を判断するかを明確にします。

もう少し詳しく：サービスごとの条件

Kubernetesでは、Roleはnamespace内、ClusterRoleはクラスタのリソース等の権限を定義できます。RoleBindingは指定namespace内で権限を結び付け、ClusterRoleBindingはクラスタ全体へ付与します。ClusterRoleをRoleBindingでnamespace内へ割り当てることもあります。RBACの権限は加算で、denyルールで別の許可を打ち消すモデルではありません。

AWS IAMのロールは、引き受ける主体と権限ポリシー等の条件で決まるAWSの仕組みです。一時的な認証情報を発行するので、「EC2に付ければその1台以外は絶対使えない」とは言えません。RBACの一般的な役割表とは分けて、信頼ポリシーと実際のアクセス条件を確認します。

異動や退職時は、直接付与・別ロール・有効なセッション・別サービスの権限等も確認します。緊急アクセスにも承認、期限、操作記録、終了後の点検を用意します。棚卸しとロールの発見・分析（role mining）も同じ操作の名前ではありません。

🐧 ペンギン先生のまとめ：「RBAC」って出てきたら「役割ごとに、できる操作をまとめて管理する仕組み」と思えばだいたいOK！

認証の入口はJWTの仕組み、接続の保護はHTTPとHTTPSの違いで見てみましょう。

参考資料

• NIST：RBAC FAQs — 人・ロール・権限・セッション・拡張モデル
• Kubernetes：Using RBAC Authorization — Role/Bindingの範囲・加算の許可モデル
• AWS：IAM roles — ロールを引き受ける主体・一時認証情報