権限管理のベストプラクティス

クラウド／社内システムのアクセス権限（IAM）と、アプリケーション内の認可設計の両方を対象に、押さえておくべき原則と実践をまとめたものです。

目次

基本原則
認証と認可を分けて考える
認可モデルの選び方
ライフサイクル管理（JML）
特権アクセス管理（PAM）
非人間アカウント（サービスアカウント・API キー）
クラウド IAM の実践ポイント
アプリケーション内の認可実装
棚卸し（アクセスレビュー）
監査ログとモニタリング
申請・承認フロー
よくあるアンチパターン
導入チェックリスト

1. 基本原則

原則	内容
最小権限 (Least Privilege)	業務に必要な最小限の権限だけを、必要な期間だけ付与する
デフォルト拒否 (Default Deny)	明示的に許可されていない操作はすべて拒否する
職務分掌 (Separation of Duties)	申請・承認・実行を同一人物が完結できないようにする
多層防御 (Defense in Depth)	ネットワーク・IAM・アプリ・データの各層で制御する
ゼロトラスト	社内ネットワークであっても毎回「誰が・何に・何をするか」を検証する
説明責任 (Accountability)	すべての権限とその利用が、特定の個人・システムに紐づいて追跡できる

2. 認証と認可を分けて考える

認証 (Authentication)：「あなたは誰か」を確認する（SSO、MFA、パスキーなど）
認可 (Authorization)：「あなたは何をしてよいか」を判断する（ロール、ポリシー）
認証は IdP（Entra ID、Okta、Google Workspace など）に集約し、各システムで独自のID・パスワードを持たない
認可ロジックはアプリ内に散らばらせず、ポリシーとして一元管理する

3. 認可モデルの選び方

モデル	概要	向いているケース
RBAC（ロールベース）	「管理者」「編集者」「閲覧者」などのロールに権限を束ねる	組織構造が安定している業務システム全般
ABAC（属性ベース）	部署・地域・時間帯・データ分類などの属性で判定	条件が複雑、規制対応が必要なケース
ReBAC（関係ベース）	「このドキュメントのオーナー」「このチームのメンバー」など関係で判定	Google Drive型の共有、マルチテナントSaaS
ACL	リソースごとに許可ユーザーを列挙	小規模・単純な共有

実践のコツ

まずは RBAC で始め、例外が増えてきたら ABAC / ReBAC を組み合わせる
ロールは「役職」ではなく「職務（ジョブファンクション）」単位で設計する
ロール爆発（ほぼ同じロールが大量にある状態）を防ぐため、定期的に統廃合する
個人への直接付与は避け、グループ → ロール → 権限 の流れで付与する

4. ライフサイクル管理（JML）

Joiner（入社・参加）

人事システムと IdP を連携し、アカウント作成を自動化（SCIM など）
職務に応じたベースラインロールを自動付与

Mover（異動）

異動時に旧権限を必ず剥奪する（権限の累積＝「権限クリープ」が最も起きやすいタイミング）
新部署のロールは改めて申請・承認を経て付与

Leaver（退職・離任）

退職日当日（理想は即時）に IdP アカウントを無効化
SaaS・クラウド・VPN・共有アカウントのパスワード、APIキーも棚卸しして無効化
所有していたリソースの引き継ぎ先を決めてから削除

5. 特権アクセス管理（PAM）

管理者権限は 常時付与しない。必要なときだけ申請して一時的に昇格（JIT: Just-In-Time）
昇格には承認フローと有効期限（例：最大4時間）を設定
root / 特権アカウントは日常業務で使わない。MFA 必須、利用は緊急時のみ
ブレークグラス（緊急用）アカウントを用意し、利用時は即アラート＆事後レビュー
特権操作はセッション記録を残す

6. 非人間アカウント（サービスアカウント・API キー）

人間のアカウントより管理が甘くなりがちで、侵害の起点になりやすい領域です。

サービスごとに専用アカウントを作り、使い回さない
長期的な静的キーより、短命なトークンや Workload Identity（OIDC連携など）を優先
シークレットはコードやリポジトリに置かず、Secrets Manager / Vault で管理
キーの自動ローテーションを設定する
各サービスアカウントにオーナー（責任者）を必ず設定する
CI/CD パイプラインの権限は、デプロイ先環境ごとに分離する
AI エージェントや自動化ツールに付与する権限も同じ原則で絞り込む（読み取り専用から始める、破壊的操作は人間の承認を挟む）

7. クラウド IAM の実践ポイント

環境（本番・ステージング・開発）をアカウント／プロジェクト単位で分離する
マネージドポリシーの *:* やワイルドカードを安易に使わない
組織レベルのガードレール（AWS SCP、GCP Organization Policy、Azure Policy）で「絶対にやってはいけないこと」を禁止
権限境界（Permission Boundary）で委任できる権限の上限を決める
IAM Access Analyzer などで「付与されているが使われていない権限」を検出して削除
本番データへの直接アクセスは原則禁止し、必要時は監査付きの踏み台経由に

8. アプリケーション内の認可実装

認可チェックは必ずサーバー側で行う（UIでボタンを隠すだけでは不十分）
すべてのAPIエンドポイントで認可を確認する（「このIDのリソースは本当にこのユーザーのものか」＝IDOR対策）
認可ロジックをミドルウェアやポリシーエンジン（OPA、Cedar、OpenFGA、Casbin など）に集約する
マルチテナントでは、クエリに必ずテナントIDの条件を付与する（行レベルセキュリティの活用も検討）
権限変更はキャッシュ・トークンにすぐ反映されるよう、トークンの有効期限を短めにするか失効の仕組みを持つ
認可のテストケース（「権限がない場合に拒否されるか」）を自動テストに含める

9. 棚卸し（アクセスレビュー）

対象	推奨頻度
特権アカウント・管理者権限	月次〜四半期
本番環境・機密データへのアクセス	四半期
一般業務システムの権限	半期〜年次
サービスアカウント・APIキー	四半期

レビューはリソースのオーナー（上長・システム責任者） が実施する
「承認」を押すだけの形骸化を防ぐため、最終利用日や利用頻度を併せて提示する
一定期間（例：90日）使われていない権限は自動で剥奪候補にする

10. 監査ログとモニタリング

「誰が・いつ・どこから・何に・何をしたか」を記録する
特に記録すべきイベント：
- ログイン成功／失敗、MFA の変更
- 権限の付与・変更・剥奪
- 特権昇格、ブレークグラスアカウントの利用
- 大量データのエクスポート
ログは改ざんできない場所に集約し、保持期間を規程で定める
異常検知（深夜の特権操作、普段と違う国からのアクセス等）でアラートを出す

11. 申請・承認フロー

権限申請はチケットやセルフサービスポータル経由にし、口頭・チャットでの付与をやめる
申請には「理由」「期間」を必須にする
承認者は申請者本人以外（職務分掌）
期限付き権限は期限到来で自動剥奪
すべての申請・承認履歴を保存し、監査時に提示できるようにする

12. よくあるアンチパターン

❌ 「とりあえず管理者権限を付けておく」
❌ 共有アカウント（admin / test を複数人で使う）
❌ 異動・退職者の権限が残ったまま
❌ APIキーを Git リポジトリや Slack に貼る
❌ フロントエンドだけで権限制御している
❌ 誰がオーナーか分からないサービスアカウント
❌ 棚卸しが「全件承認」で終わっている
❌ 本番と開発で同じ認証情報を使っている

13. 導入チェックリスト

参考になるフレームワーク・標準

NIST SP 800-53（AC: Access Control ファミリー）
NIST SP 800-207（ゼロトラスト・アーキテクチャ）
ISO/IEC 27001 / 27002（アクセス制御の管理策）
CIS Controls（Control 5: アカウント管理、Control 6: アクセス制御管理）
OWASP Top 10（A01: アクセス制御の不備）

0件のページ