権限管理設計における「Default Deny」と「Default Allow」の選択¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
B2B SaaSの権限管理で、新機能や新項目の初期権限をDefault DenyにするかDefault Allowにするかを整理した記事。 最小権限の原則ではDefault Denyが基本だが、運用負荷やユーザー体験を考えるとハイブリッド運用になりやすい。 RBAC、ABAC、ReBAC、権限粒度、Feature Flagとの役割分担まで含めて、認可設計の判断軸として使える。
本文¶
問題設定¶
Dress Codeの権限管理機能では、プロダクトごとのアクセス制御、管理者側と従業員側の権限分離、項目単位の権限設定などを扱う。 機能拡張時に問題になるのは、新しく追加した項目や機能を初期状態で許可するか拒否するか。
- Default Deny: 初期状態は何もできない。必要な権限を付与していく。
- Default Allow: 初期状態はすべてできる。不要な権限を剥奪していく。
セキュリティ原則としてはDefault Denyが推奨されるが、現実にはリスク許容度、テナント規模、開発フェーズによって判断する。
権限モデルと粒度¶
記事では、Default Deny / Default Allowの前提としてアクセス制御モデルも整理している。
- RBAC: ロールに権限を紐づける
- ABAC: サブジェクト、リソース、環境などの属性で判断する
- ReBAC: エンティティ間の関係で判断する
権限の粒度には、CRUDベース、機能別、スコープ別がある。 粒度が細かいほどDefault Denyの管理コストは上がるが、制御の精度は高くなる。
Default Deny¶
ユーザー招待時点ではログインできるだけで、何も操作できない。 管理者が必要な権限を明示的に付与していく。
利点:
- 最小権限の原則に沿う
- 新機能や新項目が意図せず公開されにくい
- テナントごとの統制に向く
課題:
- 権限設定がないとユーザーが何もできない
- 新機能追加時に管理者の設定負担が増える
- 機能が見えず、ユーザーがアップデートに気づきにくい
Default Allow¶
初期状態では使えるようにしておき、必要に応じて制限する。 初期導入の体験はよいが、意図しない権限付与のリスクがある。
小規模・初期フェーズでは実用的な場面もあるが、テナント規模やデータ感度が上がると危険になりやすい。
主要プラットフォームの実装¶
記事では、AWS IAM、GCP IAM、Kubernetes RBAC、OPA、Cedarなどを比較している。 実装方法は違っても、「明示的に許可しなければアクセスできない」という原則は共通する。
- AWS IAM: 明示Allowがない限り拒否。Denyが優先。
- Kubernetes RBAC: Role / ClusterRoleで許可のみを定義する。
- OPA:
default allow := falseで拒否をベースにする。 - Cedar: デフォルトはForbid。
Feature Flagとの分担¶
Default Denyでは、新機能を出しても権限付与されるまでユーザーに見えない。 そのため、権限管理だけではなくFeature Flagと分けて考える。
- Permission: テナント管理者が誰に使わせるかを制御する
- Feature Flag: プロダクト側がいつ・誰に公開するかを制御する
新機能リリースでは、Feature Flagで段階公開し、Permissionでテナント内の利用者を制御する。
要点¶
- 認可設計では、Default Denyを基本にしつつ、運用負荷とユーザー体験を考えてハイブリッドにする。
- 権限粒度を細かくすると制御精度は上がるが、管理コストも上がる。
- 新機能公開はPermissionだけではなくFeature Flagと分担すると設計しやすい。
- AWS IAM、Kubernetes RBAC、OPA、Cedarなどの設計はDefault Denyの実例として参考になる。