権限管理（Access Control）とは、システム内のリソースに対して「誰が」「何を」「どのように」操作できるかを制御する仕組みです。適切な権限管理がなければ、誤ったユーザーが機密データにアクセスし、情報漏洩や不正操作が発生します。
アクセス制御モデルの種類
Section titled “アクセス制御モデルの種類”エンタープライズシステムで使われる主要なアクセス制御モデルは4種類あります。
1. DAC（任意アクセス制御）
Section titled “1. DAC（任意アクセス制御）”DAC（Discretionary Access Control）は、リソースの所有者が自由にアクセス権を設定できるモデルです。Linuxのファイルパーミッション（chmod）が代表例です。柔軟ですが、所有者の判断ミスがセキュリティリスクに直結します。
2. MAC（強制アクセス制御）
Section titled “2. MAC（強制アクセス制御）”MAC（Mandatory Access Control）は、システムが一元的にアクセスポリシーを強制するモデルです。「秘密」「極秘」などの機密レベルをラベルとして付与し、対応するクリアランスを持つユーザーのみがアクセスできます。政府・軍事システムで採用されます。
3. RBAC（ロールベースアクセス制御）
Section titled “3. RBAC（ロールベースアクセス制御）”RBAC（Role-Based Access Control）は、ユーザーにロール（役割）を割り当て、ロールに権限を付与するモデルです。エンタープライズ環境で最も広く採用されています。
4. ABAC（属性ベースアクセス制御）
Section titled “4. ABAC（属性ベースアクセス制御）”ABAC（Attribute-Based Access Control）は、ユーザー・リソース・環境の属性に基づいてポリシーを評価するモデルです。「部門=営業 AND 地域=東京 AND 時間帯=業務時間内」のような細かい制御が可能ですが、実装の複雑さが増します。
RBACの構造
Section titled “RBACの構造”RBACは「ユーザー → ロール → 権限 → リソース」の4層構造で表現されます。
graph LR
U[ユーザー: Alice] --> R[ロール: admin]
R --> P1[権限: read]
R --> P2[権限: write]
R --> P3[権限: delete]
P1 --> Res[リソース: customer-data]
P2 --> Res
P3 --> Res各レイヤーの役割:
| レイヤー | 説明 | 例 |
|---|---|---|
| ユーザー | 実際の人間またはサービスアカウント | alice@example.com |
| ロール | 職責や機能を表す名前 | admin・editor・viewer |
| 権限 | 具体的な操作の許可 | read・write・delete・execute |
| リソース | 操作対象のデータやサービス | customer-data・invoices |
最小権限の原則
Section titled “最小権限の原則”最小権限の原則（Principle of Least Privilege）とは、ユーザーやサービスに対して、業務遂行に必要な最小限の権限のみを付与するという設計原則です。
具体例:
- 閲覧のみ必要な経理担当には
read権限のみ付与（writeは不要） - バックアップ用スクリプトには対象バケットへの読み取り権限のみ付与
- CIパイプラインには本番DBへの書き込み権限を与えない
アクセス制御モデル比較
Section titled “アクセス制御モデル比較”| 比較項目 | DAC | MAC | RBAC | ABAC |
|---|---|---|---|---|
| 複雑さ | 低 | 中 | 中 | 高 |
| 柔軟性 | 高 | 低 | 中 | 高 |
| 監査のしやすさ | 低 | 高 | 高 | 中 |
| エンタープライズ適合 | 低 | 中（特殊用途） | 高 | 中〜高 |
| 主な採用場面 | 個人PC・ファイルシステム | 政府・軍事 | 一般企業システム | 金融・医療・クラウド |
AIシステムへの権限管理適用
Section titled “AIシステムへの権限管理適用”RAGのアクセス制御
Section titled “RAGのアクセス制御”RAG（Retrieval-Augmented Generation）システムでは、ユーザーが検索できるドキュメントをRBACで制御します。
- 「一般社員」ロール: 社内規定・FAQのみ検索可
- 「営業担当」ロール: 顧客情報・契約書も検索可
- 「経営層」ロール: 財務データも検索可
ドキュメントにメタデータとして access_level を付与し、検索クエリにユーザーのロール情報を含めてフィルタリングします。
APIキーのスコープ管理
Section titled “APIキーのスコープ管理”LLM APIへのアクセスにはスコープを設定します。
| スコープ | 対象ユーザー | 許可操作 |
|---|---|---|
inference:read | 一般ユーザー | 推論リクエストのみ |
inference:admin | 開発チーム | モデル設定変更・ログ閲覧 |
billing:read | 経営層 | 使用量・コスト確認 |
モデルアクセスティア
Section titled “モデルアクセスティア”高コストモデル（例: claude-opus）へのアクセスを特定ロールに制限し、コスト管理とセキュリティを両立できます。
ロール設計パターン
Section titled “ロール設計パターン”フラットロール構成（小規模向け）
Section titled “フラットロール構成（小規模向け）”admin → 全権限
editor → 読み書き
viewer → 読み取りのみ機能別ロール構成（中規模向け）
Section titled “機能別ロール構成（中規模向け）”sales-manager → 顧客データ書き込み
sales-rep → 顧客データ読み取り
engineering → コードリポジトリ・インフラ
hr-admin → 人事データ階層ロール構成（大規模向け）
Section titled “階層ロール構成（大規模向け）”上位ロールが下位ロールの権限を継承します。例: senior-engineer は engineer の全権限に加え、本番環境デプロイ権限を持つ。
よくある設計ミス
Section titled “よくある設計ミス”- ロールの爆発（Role Explosion）: ロールが細分化されすぎて管理不能になる。汎用ロールから始め、必要に応じて細分化する
- adminロールの乱用: 「とりあえずadminで」という運用は最小権限の原則に違反する
- サービスアカウントの見落とし: CI/CDパイプラインやバックグラウンドジョブのアカウントにも最小権限を適用する
- 権限の定期レビュー不足: 異動・退職後も不要な権限が残り続ける
権限の定期監査
Section titled “権限の定期監査”権限は付与したままにせず、定期的なレビューが必要です。
- 四半期ごとに未使用権限をレビュー
- 退職者アカウントの即時無効化フローを整備
- 最後のアクセス日時を記録し、90日以上未使用のアカウントをレビュー
よくある質問
Section titled “よくある質問”Q: ロールはいくつ作ればよいですか？
最初は3〜5個（admin・editor・viewer など）から始め、実際の業務フローに合わせて追加するのが推奨です。50を超えるとロール爆発のリスクが高まります。AWS IAMのベストプラクティスでも「必要最小限のロール数」を推奨しています。
Q: 一時的な権限昇格（管理者作業など）はどう扱いますか？
JIT（Just-In-Time）アクセスと呼ばれるパターンを使います。必要な時間だけ権限を付与し、作業完了後に自動で失効させます。AWS IAM Identity CenterやOktaでこの仕組みを実装できます。監査ログに昇格理由と時刻を必ず記録します。
Q: RBACとABACはどう使い分けますか？
基本的なアクセス制御にはRBACが適しています。「特定の時間帯のみ」「特定の地域からのアクセスのみ」のような動的なポリシーが必要な場合はABACを検討します。多くの場合、RBACをベースにABACの要素を部分的に組み合わせるハイブリッド構成が実用的です。
このページの外部仕様・背景情報は、参考文献を参照してください。[1][2]
- GitHub, GitHub Docs
- NIST, AI Risk Management Framework