SAP セキュリティ & GRC
SAP GRCとは？概要・主要モジュール・導入後の運用を実務目線で整理
SAP GRCの概要を、SoD、Access Control、Process Control、Risk Management、EAM、監査ログの役割と運用手順に分けて解説します。SAP環境で統制を設計・監視する担当者向けの実務ガイドです。
SAP GRCとは、SAP環境におけるアクセス管理、職務分掌、リスク管理、内部統制、緊急アクセス、監査対応を支援するためのガバナンス・リスク・コンプライアンス領域です。単一のトランザクションや権限表を指す名称ではなく、統制プロセスを継続的に運用するための仕組みとして捉えると、各機能の役割を整理しやすくなります。
この記事では、SAP GRCを検討・運用するときに確認したい機能範囲、SoD（職務分掌）の考え方、アクセス申請と定期レビュー、緊急アクセス、監査ログの扱いを、現場の作業順に沿って説明します。SAP GRC全体の位置づけを先に確認したい場合は、SAPセキュリティとGRCの概要も参照してください。
SAP GRCの役割
SAP GRCの中心的な役割は、業務上必要なアクセスを付与しながら、過剰権限や統制上のリスクを検出し、承認・是正・証跡確認までを一連の流れで管理することです。
一般的には、次のような情報を組み合わせて判断します。
- ユーザー、組織、職務、所属部門
- ロール、トランザクション、アプリケーション権限
- 実行できる業務の組み合わせ
- 承認者、申請理由、利用期間
- リスク、統制、例外、是正状況
- 緊急アクセスで実行された操作の記録
SAP GRCは、権限設計そのものを自動的に完成させる製品ではありません。業務責任者、内部統制担当者、SAP Basis担当者、監査担当者が、同じリスク情報を参照して判断できる状態を作ることが重要です。
SAP GRCの主要モジュール
SAP GRCの機能は、目的ごとに分けて考えると導入範囲を決めやすくなります。製品構成や利用機能の名称は環境の設計に依存しますが、実務では次の領域を中心に整理します。
Access Control
Access Controlは、ユーザーアクセスの申請、承認、分析、プロビジョニング、定期レビューを扱う領域です。申請者が必要なロールを選び、業務責任者やデータ責任者が承認し、承認済みの内容を対象システムへ反映する流れを設計します。
アクセス申請では、ロール名だけで判断せず、対象システム、組織値、利用期間、業務上の理由を記録します。異動や退職の情報を人事プロセスと連携し、不要になったアクセスを速やかに削除できる状態にすることも重要です。
Process Control
Process Controlは、業務プロセスに含まれる統制を定義し、統制の実施状況、担当者、評価結果、証跡を管理する領域です。たとえば、支払承認、マスタ変更、仕入先登録、仕訳レビューなどについて、統制目的と確認方法を明確にします。
統制を登録するときは、対象プロセス、リスク、統制活動、実施頻度、担当者、証跡の保管場所を一つの単位として記録します。統制の説明だけでなく、誰が何を確認したかを再現できる証跡を残すことが運用上のポイントです。
Risk Management
Risk Managementは、業務や組織に存在するリスクを登録し、影響度、発生可能性、対応策、責任者、対応期限を管理する領域です。アクセス権限の問題だけでなく、業務プロセスや内部統制に関するリスクも対象になります。
リスク対応では、リスクを削除する、統制で低減する、責任者が受容する、別の方法で移転する、といった対応方針を明確にします。リスク評価の基準を部門ごとに変えず、評価尺度とエスカレーション条件を統一すると、報告内容を比較しやすくなります。
Emergency Access Management（EAM）
EAMは、通常のロールでは対応できない障害調査や緊急変更に対して、期限付きの特別アクセスを管理する領域です。緊急アクセス用のID、利用者、承認者、利用時間、利用目的、作業後レビューを結び付けます。
緊急アクセスは、恒常的な強権限ロールの代替として運用します。利用前の承認、利用中の記録、利用後のログレビューを分け、レビュー担当者が作業内容と申請理由を照合できるようにします。詳細な運用手順は、SAP EAM（Firefighter）の運用ガイドにまとめています。
SoD（職務分掌）を設計する
SoDは、同一人物が相互に牽制すべき業務を組み合わせて実行できないようにする考え方です。たとえば、仕入先の登録と支払の実行、発注と請求書照合、受注と値引承認など、組み合わせによって不正や誤処理のリスクが高まる業務を対象にします。
SoDルールを作るときは、最初に業務上の危険な組み合わせを定義し、その後でSAPのトランザクション、アプリケーション、権限オブジェクト、組織値へマッピングします。技術的な権限名から始めると、業務リスクとの対応関係が不明確になりやすいため、業務行為を起点にしたルール設計が有効です。
検出結果は、次のように分類して扱います。
- 未対応の重大リスク
- 既存の統制で管理できるリスク
- 業務上の理由があり、期限付きで受容するリスク
- ロール変更やユーザー削除で解消できるリスク
- 誤検出や対象外としてルールを見直す項目
SoDルールは一度作成して終わりではありません。組織変更、新しい業務、ロール変更、システム追加のタイミングで影響を確認します。SoDの基本概念や検出結果の読み方は、SAP SoD（職務分掌）基礎ガイドで詳しく確認できます。
アクセス申請と承認を運用する
アクセス申請のワークフローでは、申請者、直属上長、ロール所有者、業務データ所有者、セキュリティ担当者などの責任範囲を明確にします。全申請を同じ承認経路にすると運用が重くなるため、ロールの種類、権限の強さ、対象システム、利用期間によって経路を分けます。
申請項目には、少なくとも次の内容を含めます。
- 対象ユーザーと対象システム
- 申請するロールまたは業務機能
- 利用目的と業務上の必要性
- 利用開始日と終了日
- SoDリスクの検出結果
- 承認者と例外承認者
- 利用終了後の削除またはレビュー方法
承認者は、申請者の所属だけでなく、実際の担当業務と利用期間を確認します。特権性の高いロールやSoDリスクを含む申請は、業務責任者による例外承認と期限設定を必須にすると、後続のレビューが容易になります。
アクセス管理の全体像を確認するときは、SAP Access Controlの概要を参照してください。
定期アクセスレビューを実施する
定期アクセスレビューでは、現在の所属、担当業務、利用実績、割り当てロール、SoDリスク、例外の有効期限を確認します。レビュー対象を作成する前に、退職者、異動者、休職者、共有ID、緊急アクセスIDを整理すると、確認漏れを減らせます。
実施手順は次の順序にすると管理しやすくなります。
- レビュー対象期間と対象システムを決める
- ユーザーとロールの一覧を抽出する
- 所属・職務・在籍情報と照合する
- 高リスクロールとSoD違反を優先して確認する
- 継続、変更、削除、期限設定の判断を記録する
- 承認結果を保存し、削除・変更を実行する
- 未完了項目と期限超過項目を管理者へ報告する
レビューの証跡には、対象範囲、基準日、レビュー担当者、判断、コメント、実施日時、是正結果を含めます。メールの承認だけに依存せず、申請・判断・反映結果を同じ管理単位で追跡できるようにします。
監査ログを確認する
監査ログは、ログイン、権限変更、重要設定の変更、ユーザー操作、管理者操作などを後から確認するための証跡です。ログを有効化するだけでなく、対象イベント、保存期間、参照権限、保管場所、レビュー頻度を決めます。
運用開始時には、次の観点を確認します。
- 重要な管理操作が記録されているか
- ログの時刻とシステム時刻が整合しているか
- ログを削除・変更できる権限が限定されているか
- 監査担当者が必要な期間のログを検索できるか
- 異常な失敗ログや大量変更を検知できるか
- ログを別の保管先へ転送する場合の責任分界が明確か
ログレビューでは、単発のイベントだけでなく、同一ユーザーによる連続操作、権限変更直後の重要処理、営業時間外の管理操作などを組み合わせて確認します。監査ログの対象と確認手順は、SAPセキュリティ監査ログの基礎も参照してください。
導入後の運用設計
SAP GRCの導入後は、システム管理と業務統制の責任分界を明確にします。SAP BasisやUser and Role Managementの担当者が技術設定を担当し、業務責任者がロールの必要性とリスク受容を判断し、監査・コンプライアンス担当者が証跡と統制評価を確認する形が基本です。
運用カレンダーには、少なくとも次の定期作業を登録します。
- 毎日または毎週の申請・承認状況確認
- 高リスクアクセスと期限切れ例外の確認
- 緊急アクセスログのレビュー
- 月次または四半期のユーザーアクセスレビュー
- 組織変更時のSoDルール影響確認
- 半期または年次のルール・統制・責任者見直し
- 監査依頼に対する証跡の収集と保管
KPIは、申請処理時間だけでなく、期限超過件数、削除遅延、未レビュー件数、未解決SoDリスク、緊急アクセスのレビュー完了率などを含めます。処理件数だけを追うと、統制の品質や例外の滞留を見落とす可能性があります。
トラブルシューティング
SoD違反が大量に検出される場合
まず、対象システムとの接続、ユーザー同期、ロール同期、組織値のマッピングを確認します。次に、業務上すでに廃止されたロールや、実際には利用されていない技術権限が分析対象に残っていないかを確認します。
検出数が多い場合でも、すべてを一括除外せず、重大度、対象ユーザー、利用実績、業務影響で優先順位を付けます。誤検出はルール定義やマッピングを修正し、正当な例外は責任者、理由、期限、代替統制を記録します。
承認後に権限が反映されない場合
申請の承認状態、プロビジョニングジョブ、対象システムへの接続、技術ユーザーの権限、対象ロールの有効期間を順に確認します。対象システム側でロールが存在するか、割り当て後にユーザー同期が完了しているかも確認します。
監査ログを追跡できない場合
対象イベントの記録設定、ログの保存期間、検索条件、時刻設定、参照権限を確認します。重要操作を再現する前に、テスト環境で必要なイベントが期待どおりに記録されることを確認し、ログの保管とレビュー責任者を明文化します。
まとめ
SAP GRCは、アクセス申請だけを処理する仕組みではなく、SoD、アクセスレビュー、緊急アクセス、業務統制、リスク、監査ログを結び付けて管理するための運用基盤です。
実装・運用では、まず業務リスクと責任者を定義し、その後にロール、ワークフロー、統制、ログの設定へ落とし込みます。さらに、例外には期限を設け、判断と是正の証跡を残すことで、日常運用と監査対応を同じプロセスで管理できます。