ISCアクセス管理の攻略法｜IDライフサイクル・MFA・特権IDを一枚で整理

1｜Identity proofing・Authentication・Authorizationを分ける

Identity proofingは申請者が主張する本人であることを確認し、デジタルIDと結び付ける手続です。Authenticationはアクセス時に認証手段を用いてそのIDを確認し、Authorizationは確認済みIDへ許可する操作・データ範囲を決めます。

強いMFAがあっても過剰権限が付与されていれば、認可の問題は残ります。逆に適切な役割設計があっても、共有IDや弱い認証では誰が操作したかを信頼できません。

• Proofing：あなたは誰か
• Authentication：今アクセスしているのはそのIDか
• Authorization：そのIDは何をしてよいか

2｜Joiner・Mover・Leaverで権限を更新する

入社時は、人事記録と承認済み職務に基づいてIDを作成します。異動時は新しい権限を加えるだけでなく、旧職務の権限を削除します。退職時は、通知とID無効化を適時に連携します。

定期アクセスレビューは、日々の変更処理で残った過剰権限を発見する統制です。ただし、年次レビューを待って退職者アクセスを削除する運用では遅すぎます。予防的な変更処理と発見的な再認証を組み合わせます。

3｜Least privilegeとSegregation of dutiesを同時に見る

Least privilegeは、担当業務に必要な最小限の権限だけを付与する原則です。Segregation of dutiesは、承認・記録・資産管理など相反する権限を一人へ集中させない考え方です。

RBACでは職務役割へ権限を割り当て、ABACでは利用者、端末、資源、時刻などの属性でポリシーを評価します。どのモデルでも、役割や属性ルール自体が過剰なら適切な統制にはなりません。

4｜特権IDは申請から操作証跡まで別管理する

管理者IDは設定変更、ログ閲覧、ID作成など広い影響を持つため、通常IDより厳しい統制が必要です。個人別ID、MFA、承認、有効期限、セッション記録、利用後レビューを組み合わせます。

緊急IDは恒久的な抜け道にしません。利用理由、開始・終了時刻、実行操作を記録し、利用後に独立した担当者が速やかにレビューします。共有の管理者パスワードだけでは個人の説明責任が弱くなります。

• Just-in-timeで必要時だけ有効化
• Just-enough-accessで必要操作だけ許可
• 資格情報を保管・ローテーション
• コマンド・セッション・設定変更を監視

5｜MFA・SSO・Federationの利点と集中リスクを比較する

MFAは知識・所持・生体など異なる要素を組み合わせます。同じ種類の知識要素を二つ使っても、独立した要素によるMFAとは限りません。リスクが高い操作では再認証やstep-up authenticationも検討します。

SSOとidentity federationは利用者体験と集中管理を改善しますが、IDプロバイダーや認証情報の侵害が複数サービスへ波及する集中リスクを持ちます。強い認証、署名されたassertionの検証、短いセッション、迅速な失効、可用性設計が必要です。

6｜Zero Trustは「毎回すべて拒否」ではなく継続評価

NISTのZero Trust Architectureは、社内ネットワークにいる、会社端末である、といった場所や所有関係だけを理由に暗黙の信頼を与えません。利用者、端末状態、資源、行動、状況を用いてアクセスを評価します。

試験では、認証済み利用者へ広範な権限を永続付与する選択肢より、対象資源ごとの明示的な認可、最小権限、監視、再評価を選びます。ネットワーク分割も侵害後の横移動を抑える補完統制になります。

7｜アクセス管理問題の確認順序

設問で問題となっているのが本人確認、認証、認可、変更、監視のどこかを特定します。便利そうなセキュリティ製品ではなく、示されたリスクへ最も直接対応する統制を選びます。

• 誰が権限を承認するか
• 権限は業務上必要な最小範囲か
• 異動・退職が適時に反映されるか
• 特権操作を個人へ追跡できるか
• 例外・緊急アクセスを独立レビューするか