APIの権限管理が適切に設計されているか？¶
Type: Structure
Category: API・権限・セキュリティ
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
APIにはユーザー・ロールごとの権限管理が求められる
権限管理はセキュリティの要であり、設計ミスはインシデントに直結するが、特にBtoBシステムではユーザーごとに細かな操作制御が必要となるため、責務の分離と明示的な設計が必須
これを怠り設計段階で権限と振る舞いの分離がされていないと、漏洩や不正アクセスが発生しやすい
セキュリティインシデントはBtoBにとっては致命的なため意識した開発が必須
例¶
- ドメイン層: Document.canView(user) のようなprivate関数で、業務ルールとしての操作許可をドメインオブジェクト内部で表現する
- ユースケース層: requirePermission(user, Action.VIEW_DOCUMENT) をユースケースの冒頭で呼び出し、権限制御を明示的に行う
- エンドポイントごとに必要権限を明示的に設計しておく
- APIレスポンスで非表示にするのではなく、リクエスト段階で権限制御して早期returnする
よくある失敗例¶
- UI側で非表示にしているだけで、APIには誰でもアクセスできてしまう
- 権限ロジックが複数箇所に分散していて、変更時に考慮漏れして整合性が崩壊
- 誰がどこまで操作できるのか仕様に書かれておらず、ドメインでの操作可否とユースケースでの権限制御が混同され、責務が不明瞭
FAQ¶
Q. 権限の定義はどこで持つべき？
A. サーバーサイドでRole/PermissionをEnumなどで明示的に定義し、誰が何をできるか一目で把握できるのが望ましい。例えばval rolePermissions = mapOf(Role.ADMIN to setOf(VIEW_DOCUMENT, APPROVE_TASK, EXPORT_CSV),Role.USER to setOf(VIEW_DOCUMENT))のようにマッピングするなど
Q. 権限の種類が増えてきたら？
A. ポリシーベースの動的な権限設計に移行する。例えばclass ViewDocumentPolicy : Policy