SAP セキュリティ & GRC
SAP GRC Access Controlの概要と運用手順：申請・SoD分析・緊急アクセス管理
SAP GRC Access Controlで扱うアクセス申請、SoDリスク分析、承認ワークフロー、緊急アクセス、定期レビューの関係を整理し、運用時の確認ポイントとトラブルシューティングを解説します。
SAP GRC Access Controlは、ユーザーへの権限付与を申請・承認・分析・記録するための仕組みです。単にロールを登録するだけでなく、業務上の職務分掌（SoD）リスク、緊急時の特別権限、定期的なアクセス確認までを一連の運用として扱います。
実務では、SAP S/4HANAやSAP ERPなどの接続先システム、組織の承認ルール、リスクルール、監査要件を最初に整理します。Access Controlの画面で申請を作成できても、接続先へのプロビジョニングや承認者の決定が正しく動かなければ、運用は完了しません。
SAP GRC Access Controlの役割
SAP GRC Access Controlの中心機能は、アクセス申請、アクセスリスク分析、ビジネスロール管理、緊急アクセス管理、ユーザーアクセスレビューです。これらは独立した機能に見えますが、ユーザーのライフサイクルに沿って連携させます。
たとえば、異動に伴う新しいロールの申請では、申請内容を承認者へ回付する前にSoDリスクを分析し、必要に応じてリスク受容や代替統制を記録します。承認後は接続先システムへ権限を反映し、後日レビューで継続利用の妥当性を確認します。
全体像を先に把握する場合は、SAP セキュリティとGRCの概要も参照してください。GRC製品群の位置付けと、アクセス管理以外の統制領域を整理できます。
アクセス申請ワークフローの設計
アクセス申請では、誰が、どの接続先に、どのロールを、どの期間利用するかを明確にします。申請者、申請対象ユーザー、上司、ロール所有者、セキュリティ担当者などの役割を分けると、承認責任が曖昧になりにくくなります。
申請ワークフローは、次の順序で確認すると運用設計を進めやすくなります。
- 対象ユーザーと接続先システムを特定する
- 要求するロールまたはアクセスを選択する
- 承認者を組織・ロール所有者・リスク担当者に割り当てる
- SoDや重要権限の分析を実行する
- 承認、却下、修正依頼の結果を記録する
- 承認済みの内容を接続先へ反映する
- 反映結果と有効期限を確認する
申請が停滞する場合は、まず承認者決定ルール、ユーザーと組織の紐付け、接続先との同期状態を確認します。申請者の操作だけを再実行しても、承認者が解決しない限り処理は進みません。
SoDリスク分析とリスク処理
SoD分析は、同一ユーザーが相互に牽制すべき業務権限を同時に持つ状態を検出するために使います。典型的には、取引先登録と支払処理、購買発注と請求書処理、仕訳入力と支払承認などを組み合わせてリスクルールにします。
リスクが検出された場合は、次のいずれかの処理方針を組織で決めます。
- 申請内容から不要な権限を除外する
- 代替ロールや職務分担に変更する
- 業務上必要なリスクとして正式に受容する
- 代替統制を割り当て、担当者と確認頻度を記録する
- 緊急アクセスに限定し、利用後にレビューする
リスクルールは、トランザクション、権限オブジェクト、組織値などの実際の権限設計と対応している必要があります。業務プロセスが変わったときは、ルール、リスク所有者、代替統制、レビュー周期をまとめて見直します。
詳細な職務分掌の考え方は、SAP SoD（職務分掌）基礎で確認できます。Access Controlのリスク分析では、検出結果だけでなく、その後の処理責任まで定義することが重要です。
緊急アクセス管理の運用
通常のロールでは実行できない保守作業や障害対応が必要な場合、緊急アクセス管理（EAM）を利用します。緊急アクセス用のIDを常用権限として配布せず、利用理由、利用者、期間、承認、利用後レビューを記録する運用にします。
運用前に、緊急アクセスIDの所有者、割り当て方法、利用可能な接続先、ログの収集先、レビュー担当者を決めます。利用後は、実行した操作と申請理由を照合し、不要な操作や想定外の権限利用がないか確認します。
ログが収集されない場合は、接続先の設定、監査ログの有効化、時刻同期、ログ転送処理、レビュー対象期間を順に調べます。アカウントを作成しただけでは、利用記録の監査性は確保されません。
緊急アクセスの設計とレビュー手順は、SAP緊急アクセス管理（Firefighter）の概要にまとめています。通常アクセスと緊急アクセスを同じ承認基準で扱わず、緊急性と事後確認を明確に分けてください。
定期的なユーザーアクセスレビュー
定期レビューでは、現在のユーザー、割り当てられたロール、利用期限、所属、上司、ロール所有者を確認します。退職者や異動者のアクセス、長期間利用されていない権限、期限切れになっていない一時権限を重点的に調べます。
レビューの依頼先は、ユーザーの上司だけでなく、業務ロールの所有者やシステム責任者を含めます。承認、却下、修正依頼の結果と処理日を保管し、未回答のレビューには期限とエスカレーションルールを設定します。
レビュー作業を安定させるには、対象範囲、判定基準、回答期限、削除・変更の実施者、例外の記録方法を手順書に固定します。レビュー結果を保存するだけでなく、却下されたアクセスが実際に削除されたことまで確認します。
接続先とプロビジョニングの確認
Access Controlから接続先へアクセスを反映する構成では、接続設定、ユーザー識別子、ロール識別子、通信ユーザー、同期ジョブ、プロビジョニング処理を確認します。申請が承認済みでも、接続先のユーザーが無効、ロールが未同期、または通信権限が不足していれば反映されません。
切り分けでは、次の順序で確認します。
- Access Control上の申請ステータスを確認する
- 承認履歴とリスク処理結果を確認する
- 対象ユーザーの識別子と接続先を確認する
- 同期またはプロビジョニングのジョブログを確認する
- 接続先でユーザーとロールの状態を確認する
- 必要に応じて対象処理を限定して再実行する
接続先で権限が反映されないときは、承認済みという事実と、実際に付与されたという事実を分けて扱います。再実行前にジョブの重複実行や部分反映の有無を確認し、監査証跡が途切れないようにします。
よくある障害の切り分け
申請が作成できない場合は、申請対象ユーザー、接続先、利用可能なロール、申請者の権限、必須項目を確認します。申請は作成できるものの承認へ進まない場合は、承認者決定ルールと組織情報を確認します。
リスク分析結果が期待と異なる場合は、対象システムの同期状況、リスクルールの有効性、権限と業務機能の対応関係を確認します。業務上は同じ名称のロールでも、接続先や組織値が異なれば分析結果が変わるため、ロール名だけで判断しません。
監査や調査に使うログは、申請履歴、承認履歴、リスク分析結果、プロビジョニング結果、緊急アクセス利用記録を関連付けて保管します。監査ログの基本的な確認方法は、SAPセキュリティ監査ログの基礎も役立ちます。
運用開始前の確認チェックリスト
本番運用へ移行する前に、次の項目を確認します。
- 接続先システムとユーザー識別子が定義されている
- 申請対象となるロールとロール所有者が登録されている
- 承認者決定ルールが組織構造と一致している
- SoDルールと重要権限ルールが業務要件を反映している
- リスク受容と代替統制の責任者が決まっている
- EAMの利用条件、ログ収集、事後レビューが定義されている
- ユーザーアクセスレビューの周期と期限が決まっている
- 申請、承認、分析、反映、削除の証跡を確認できる
- 障害時の再実行とエスカレーション手順がある
最初からすべての業務を対象にするより、代表的な組織、ロール、承認経路、接続先を選び、申請から反映、レビューまでを通して検証します。検証では正常系だけでなく、却下、期限切れ、承認者不在、リスク検出、接続エラーも含めます。