概要

権限管理の設計について事例を調べてみたのでメモしておく。

調査メモ

調査した情報を整理してみたが、わかっていないこともあるのでちゃんと整理しきれていない。

権限を構成する要素

権限は次の要素で成り立つものと考えられそう。

誰が（Principal）
何に（Resource）
何を（Action）していいか（ALLOW）、いけないか（DENY）

権限設計の手法

設計手法としては次のようなものが一般的に思われる。

ACL(Access Control List)
- ユーザーごとに権限を設定する
- 権限はリストで管理される
RBAC(Role Based Access Control)
- ユーザーにロールを割り当て、ロールに権限を割り当てる
ABAC(Attribute Based Access Control)
- ユーザー、リソース、環境などの属性に基づいて権限を設定する

権限の柔軟性、実装の複雑性は、ACL < RBAC < ABACとなる。

権限設計の観点

権限設計の観点としては、次のようなものがありそう。

権限の適用範囲
- 権限がどこまで適用されるか？
- 機能的範囲
  - 単一の機能を対象することもあれば、特定の機能群を対象にすることもある
  - ex. ユーザー情報取得APIが利用できるかどうか
- データ的範囲（スコープ）
  - 最もプリミティブな権限の適用範囲
  - ex. ユーザー情報の閲覧権限→名前と年齢は見れるが、住所は見れない
- 両方考える必要もあれば、片方だけの考慮で良い場合もあるが、柔軟な設計が求められる
権限の制御対象
- 権限がどのような基準で適用されるか？
  - コンテンツ
    - 特定の機能、データなどを対象に権限を適用する
  - コンテキスト
    - 特定の条件を満たすかどうかで権限を適用する
      - ex. 決済金額が100万円以上のユーザーのみアクセス可能
    - そもそも権限として管理される対象なのか？権限として管理されるのであれば状態はどのように管理されるか？
  - 時間
    - 特定の時間帯にのみ権限を適用する
      - ex. 平日のみアクセス可能
    - アクセス権限も権限の範疇
権限の制約
- 権限の優先度や権限間の依存関係などの制約
- 相反するような権限
  - 特定のデータしか閲覧できない権限を持っているユーザーに、全データを閲覧できる権限を持たせた場合、どちらが優先されるか
  - 相反するような権限の関係性をどう表現するか？
    - 権限の新規追加時に人力で評価するのか、属性やロールに応じた優先度を定義するのか、集合論的なアプローチで評価するかなど実装面の考慮事項がある
    - ユーザー体験やセキュリティ（最小権限の原則）の視点で検討する必要があるかもしれない
権限適用のレイヤー
- 権限適用されるシステムのレイヤーはどこなのか
  - アプリケーション、データベース、ネットワーク、OSなど
- どこから権限適用が必要か？
- 機能的範囲やデータ的範囲の設定によってレイヤーは定まりそう
管理者権限の取り扱い
- 管理者権限をどのように設定するか
- 管理者権限はセキュリティリスクを持つ
  - 最小権限の原則、権限分割、監査ログ、緊急時のオペレーション整備などリスク管理の観点を持つ必要がある
権限管理の運用フロー
- 適切に権限が管理されるための運用フローを考える必要がある
- 最小権限の原則
  - 必要最低限の権限のみを付与する
- 定期的な監査とレビュー
  - 権限設定を定期的に確認し、不要な権限を取り除くなど
- 一元管理
  - 権限の種類や権限の適用状況などが把握しやすいインタフェースの提供
  - 一貫性のある権限適用フロー
    - 権限管理が各々のシステムで独自実装されているような形だと一貫性が乱れやすい（と思う）
  - 権限の分離
    - 柔軟な権限設定が可能であること
    - 一つの権限の制御対象が広すぎないこと

要求されるシステム特性

権限管理を行うシステムにおいて求められるシステム特性について考えてみた。

拡張性
- 任意の柔軟性で権限を追加できる
スケーラビリティ
- 柔軟性の高い権限設計であるとシステムの複雑性やデータ量の増加も想定されやすい
- ユーザーや権限など線形に増加していった場合のキャパシティを想定する
信頼性
- 権限の追加や変更が既存の権限に悪影響を及ぼさないようにする
セキュリティ
- 最小権限の原則を守る、爆風半径を小さくする、障害における緊急オペレーションの整備など