要点
- ロール（誰か）と権限（操作に何が必要か）を分ける。
- 拠点、部署、所有者などのスコープを第2の軸として加える。
- アクセスはすべてのリクエストでサーバー側で確認する。画面は許可されないものを隠すだけ。
- ロールの変更と機密データへのアクセスをすべて記録する。
アクセス制御は「管理者」フラグから始まり、やがて特別扱いだらけになりがちです。事業が成長しても理解しやすいままの、ロール、権限、スコープの構造を紹介します。
アクセス制御が崩れていく典型
多くのシステムは、管理者とそれ以外という2種類のユーザーから始まります。事業が成長すると例外が現れます。承認はできるが削除はできないマネージャー、自拠点の記録だけを見るべき支店、すべてを閲覧できるが何も変更できない監査担当者。例外のたびにif文が増え、やがて誰が何をできるのか自信を持って言える人がいなくなります。
ロールと権限は別物
権限は、システムが提供する操作として定義します。請求書の作成、休暇の承認、レポートの出力などです。ロールは、実際の職務に合わせた権限の名前付きの束として定義します。コードが確認するのは権限であり、ロール名ではありません。
このルールひとつで変更が安くなります。新しい職務が生まれたら、何十か所ものコードを直すのではなく、既存の権限から新しいロールを作るだけです。
第2の軸としてスコープを加える
権限は「この人は休暇を承認できるか？」に答えます。スコープは「誰の休暇を？」に答えます。病院のシステムなら部長は自部署の休暇だけを承認でき、複数キャンパスの学校なら校長は自キャンパスだけを見られます。
- 組織のスコープ：会社、地域、支店、部署。
- 所有のスコープ：ユーザーが作成した、または担当している記録。
- 関係のスコープ：保護者は自分の子どもの記録だけを見られる。
毎回サーバーで強制する
ボタンを隠すのは使いやすさのための工夫であり、セキュリティ対策ではありません。すべてのAPIリクエストで、権限とスコープをサーバー側で確認する必要があります。理想的には共通の層で行い、個々のエンドポイントが確認を忘れないようにします。データベースが対応していれば、行レベルのポリシーがさらなる安全網になります。
アクセスを監査可能にする
ロールと割り当てのすべての変更、機密記録へのすべてのアクセスを記録します。顧客、監査人、規制当局から「誰がいつ何を見られたか」と聞かれたとき、答えは記憶ではなくクエリから出てくるべきです。
参考になりましたか？次の記事をメールで受け取れます。