RBACの仕組み ― ロールベースのアクセス制御を理解する

Role-Based Access Control、日本語だと「ロールベースアクセス制御」だよ。ユーザーに直接権限を付けるんじゃなくて、「ロール（役割）」を間に挟んで権限を管理する仕組みなんだ。会社で言うと、個人ごとに鍵を配るんじゃなくて「部長には3階まで入れる鍵」「一般社員には1階だけの鍵」みたいに役職で決める感じだね。

ユーザーが10人なら直接でもいいけど、1000人になったら大変だよ。新入社員が入るたびに「データベース読み取りOK」「ログ閲覧OK」「デプロイNG」って1つずつ設定するの？ ロールなら「開発者」ロールを付けるだけで必要な権限がまとめて付くんだ。異動や退職の時もロールを外すだけで済むよ。

「ユーザー」「ロール」「パーミッション」の3つで構成されるよ。たとえば「閲覧者」ロールには「記事の読み取り」権限、「編集者」ロールには「読み取り＋書き込み」権限、「管理者」ロールには「読み取り＋書き込み＋削除＋ユーザー管理」権限、みたいに定義するんだ。

ロール階層（Role Hierarchy）っていう仕組みがあるよ。「管理者」ロールは「編集者」ロールの権限をすべて含む、「編集者」は「閲覧者」の権限をすべて含む…みたいに継承関係を作れるんだ。最小権限の原則（Principle of Least Privilege）に従って、必要最低限のロールだけ付与するのが基本だよ。

AWS IAMのロールが有名だね。EC2インスタンスに「S3読み取り専用ロール」を付けると、そのインスタンスからだけS3にアクセスできる。KubernetesのRBACでは「namespace: devの中でPodの作成・削除OK」みたいにリソース単位で細かく設定できるよ。データベースのGRANT文もRBACの一種だね。

ACL（Access Control List）は古くからある方式で、リソースごとに「誰がアクセスできるか」をリストで管理するよ。ABAC（Attribute-Based Access Control）はユーザーの属性（部署、勤務地、時間帯など）を組み合わせて動的に判定する方式。RBACはこの2つの中間で、シンプルさと柔軟性のバランスがいいから一番広く使われてるんだ。

「ロール爆発（Role Explosion）」っていう問題があるよ。組織が複雑になると「東京オフィスの開発チームリーダー用ロール」「大阪オフィスの…」みたいにロールが際限なく増えて管理が破綻するんだ。これを防ぐにはABACと組み合わせたり、定期的にロールを棚卸しして未使用のものを削除する「ロールマイニング」が重要だよ。

「ブレイクグラス（Break Glass）」手順っていうのがあるよ。ガラスを割って非常ボタンを押すイメージだね。一時的に高権限のロールを付与して、操作ログを全部記録し、終わったらすぐ剥奪する。ゼロトラストアーキテクチャでは「常に検証」が原則だから、RBACだけじゃなくデバイスの状態やアクセス元のリスク評価も組み合わせて判断するのが今のベストプラクティスだよ。