アクセス制御とは

このレッスンで学ぶこと

アクセス制御は、「誰であるか」を確かめる認証の次に、「何をしてよいか」を決める認可の仕組みです。この回は章の地図として、認可が何を突き合わせ、どこで崩れるのかを整理します。

読み終えると、1回のリクエストのどこに主体・資源・操作が現れているかを、自分の環境で指せるようになります。

認可は3つを突き合わせる

1回の判定に要るのは、次の3つです。

• 主体。誰が要求しているか。練習用のショップならtanakaやadmin
• 資源。何に対してか。注文1043、利用者57のプロフィールなど
• 操作。その資源に何をするか。読む、書き換える、消す

tanakaが/api/orders/1043を開くとき、サーバーは「tanakaという主体が、注文1043という資源を、読むという操作をしてよいか」を判定します。3つのどれが欠けても判定は下せません。

GET /api/orders/1043   ログイン中の主体 = tanaka
  主体   tanaka
  資源   注文 1043
  操作   読む
  → tanaka は 1043 を読んでよいか？

判定はどこに置くか

この判定は、資源に触れる場所、つまりサーバー側の各エンドポイントに置きます。画面のボタンやリンクを出し分けるのは表示の都合であって、認可ではありません。メニューから管理者用のリンクを消しても、その先のエンドポイントが判定をしなければ、URLを直接叩けば通ります。ここは章の最後に「サーバー側の認可」として詳しく戻ってきます。

崩れ方は縦と横に分かれる

認可の欠陥は、方向で2つに分けると見通しがよくなります。

• 垂直。役割をまたぐ方向。一般利用者のtanakaが、管理者adminにしか許されない機能に手を伸ばす形です
• 水平。同じ役割の中で、持ち主をまたぐ方向。tanakaが、別の一般利用者の注文を読む形です

手を動かす

練習用の環境でtanakaとしてログインし、/api/orders/1043を開いたときのURLと応答を「HTTP通信」タブで確かめてください。主体・資源・操作の3つが、そのリクエストのどこに現れているかを言えるようにしておくと、次の回からの崩れ方が読みやすくなります。

まとめ