メインコンテンツまでスキップ

API permission 設計

セキュリティはアプリケーション特有の関心事であり、ビジネスオブジェクトはこのことについて意識しない」と言っています

usecase 内で権限によってロジックを分けることはしない。
小・中規模であれば考慮はしていいが、それ以上の規模であれば行わない。

人によって情報を出し分けたい

どの記事を読んでも最後に出し分けるのが慣例っぽい。

権限チェックの箇所は

routerでやるとエンドポイントをみただけで一発でわかる。

パーミッションでの属性とは

同じapiを叩けるが、クライアントによって出力を変えるなどの属性。

設計をする時に考えること

Image from Gyazo

Image from Gyazo

RBAC: Role-Based Access Control

RBACは「ユーザーの役割によって権限のチェックを行う」やり方です。 役割とは、たとえば一般ユーザーや管理者などがあります。 権限を変更するだけで処理の可否を変更できるという利点がありますが、権限がふえると管理や実装が大変になってきます。

「管理者」のような役割以外にも、WritableやReadableのような複数のパーミッションを持たせるようなやり方もあります。

ABAC: Attribute-Based Access Control

ABACは「ユーザーの属性によって権限のチェックを行う」やり方です。たとえばツイートの投稿者かどうか、あるいは同じグループに所属しているかどうか、です。

ABACは柔軟な権限管理ができる一方で実装が大変だったり、ものによってはデータベースへのアクセスがふえてパフォーマンスが悪くなったりします。RBACとABACは、システムの種類によって使い分けるとよいです。ひとつのシステム内で両方を使うことももちろんあります。

Resource

アプリケーションにおける権限設計の課題
権限管理の苦い思い出を新規サービスで昇華した話
システムの権限管理を設計するときの考え方とは