SAP セキュリティ & GRC
SAP ファイアファイター ID 緊急アクセス管理の設計と運用手順
SAP GRC Access Control の EAM（Emergency Access Management）でファイアファイター IDを設計・申請・監視・レビューする実務手順を、監査ログやSoDとの関係、運用トラブルの切り分けまで含めて解説します。
SAPの本番環境で、通常のユーザー権限だけでは解決できない障害や緊急作業が発生することがあります。このとき、恒久的に強い権限を付与するのではなく、作業目的・期間・承認者・実行者・操作記録を一つの統制にまとめる方法がEAM（Emergency Access Management）です。
SAP GRC Access ControlのEAMでは、緊急用のファイアファイター IDを用意し、利用者に一時的な利用権限を割り当てます。利用者本人の通常IDと、実際に高権限操作を行うファイアファイター IDを分けることで、誰が、どの緊急IDを、いつ、何のために使ったかを追跡しやすくします。全体像は、次の順序で捉えると運用設計が安定します。
EAMの役割とファイアファイター ID
ファイアファイター IDは、緊急作業に必要な権限を集約した専用IDです。通常ユーザーのロールへ管理者権限を追加する方式では、権限が残り続ける、利用目的が追跡しにくい、定期レビューで例外が増えるといった問題が起こります。EAMでは、緊急アクセスを通常運用から分離し、利用記録をレビュー対象にできます。
代表的な構成は次の二つです。
- 中央配置型: EAM側のファイアファイター IDを利用し、対象システムへ接続して作業します。
- 分散配置型: 対象のSAPシステム内にファイアファイター IDを配置し、GRC側で利用状況とログを管理します。
対象システムの数、接続方式、監査要件、ログ収集方式によって適切な構成は変わります。設計時は、対象システムごとに必要な権限、ログ取得方法、所有者、承認経路、障害時の代替手段を一覧化します。
通常ユーザーID
│ 申請・承認
▼
EAMのファイアファイター割当
│ 一時利用
▼
対象SAPシステムの緊急ID
│ 操作ログ・セッション記録
▼
管理者レビュー・是正・証跡保管
ファイアファイター IDの設計
最初に決めるのはIDの単位です。全システムに一つの万能IDを置く設計は、操作範囲が広くなり、レビューの粒度も粗くなります。システム、業務領域、作業種類のいずれか、または組み合わせで分割し、必要最小限の権限にします。
たとえば、FIの期間締め対応、MMの在庫修正、Basisの障害対応を同じIDに集約せず、担当領域や対象システムに応じて分けます。ID名から用途を読み取れる命名規則を定め、所有者と副所有者を登録します。所有者は権限内容と利用目的を説明できる担当者にし、異動時には後任へ引き継ぎます。
権限設計では、次の観点を確認します。
- 緊急作業の種類を具体的な業務シナリオに分ける。
- 各シナリオで必要なトランザクション、サービス、権限オブジェクトを洗い出す。
- 読み取りと更新、設定変更とデータ変更を分離する。
- 本番、検証、開発の対象を分ける。
- 作業終了後に不要となる権限を削除または別IDへ移す。
ファイアファイター IDのパスワードや接続情報は、利用者へ恒久的に配布しません。利用開始、利用終了、利用者、承認状態をEAMの運用フローに結び付けます。技術的なID管理だけでなく、業務責任者による所有と承認を明確にすることが重要です。
申請・承認・利用の運用フロー
緊急アクセスの申請には、対象システム、ファイアファイター ID、作業内容、開始予定時刻、終了予定時刻、理由、関連するインシデントまたは変更番号を含めます。緊急性を理由に説明を省略すると、後からログを見ても操作の妥当性を判断できません。
承認者は、申請者の上長だけでなく、対象システムまたは業務の責任者を含めます。Basis作業なら技術責任者、FIやMMの業務データを変更する作業なら業務責任者を設定します。職務分掌を保つため、申請者と承認者を同一人物にしない運用が基本です。
承認後は、EAMの割当期間内だけファイアファイター IDを利用します。作業開始時に申請番号を記録し、作業終了時には実施内容、変更したデータ、未完了事項、追加対応の要否を記入します。利用時間が延長された場合は、元の申請を放置せず、延長理由と承認を残します。
SoD（職務分掌）の基本を同時に確認すると、緊急IDの強い権限が通常の権限設計を迂回していないか評価できます。緊急アクセスはSoDを自動的に解消する仕組みではなく、例外を期限付きで管理し、事後レビューにつなげる統制です。
操作ログと事後レビュー
EAMの価値は、強い権限を一時的に使えることだけではありません。利用者、ファイアファイター ID、対象システム、セッション時間、実行操作、変更対象、申請理由を関連付け、承認内容と操作結果を比較できる点にあります。
レビュー担当者は、次の順番で確認します。
- 申請の理由が実際の障害、変更、業務処理と対応しているか確認する。
- 承認された時間帯と実際のセッション時間を比較する。
- 操作内容が申請範囲に収まっているか確認する。
- 直接更新、権限変更、設定変更などの高リスク操作を重点的に見る。
- 不一致があれば、実行者と所有者へ照会し、理由と対応を記録する。
- 誤操作や過剰操作があれば、是正、再発防止、追加承認の要否を決める。
SAPセキュリティ監査ログの基本も併用すると、EAMのセッション記録と対象システム側の監査イベントを突き合わせやすくなります。EAMのログだけで操作の業務妥当性がすべて判断できるとは限らないため、変更管理、インシデント管理、アプリケーション側の記録も関連付けます。
レビューの期限を運用規程で定めます。重大な本番変更は作業直後、通常の緊急作業は一定期間内というように、リスクに応じた期限を設定します。未レビュー件数、期限超過件数、理由不備、対象外操作、再発した利用者やIDを定期的に集計すると、統制の弱点を発見できます。
SAP GRC Access Controlでの管理項目
SAP GRC Access Controlでは、EAMの構成要素を個別に管理します。実装時は、ファイアファイター ID、コネクタ、割当対象、所有者、レビュアー、ワークフロー、ログ収集、通知を一つの運用モデルとして整理します。
SAP GRC Access Controlの概要では、アクセスリスク分析やアクセス要求など、EAMと関連する機能領域の位置付けを確認できます。EAMだけを独立した申請画面として扱うのではなく、アクセス要求、SoD分析、ユーザーアクセスレビューとの境界を決めておくと、同じ申請を複数の管理表へ転記する作業を減らせます。
設定前には、次の情報を準備します。
- 対象システムと接続先の一覧
- 各対象のファイアファイター IDと所有者
- 利用可能な期間と最大セッション時間
- 申請者、承認者、レビュアーの職務分掌
- ログ収集の頻度と保管期間
- メールやワークフローの通知先
- 失敗時の連絡先と代替レビュー手順
接続テストでは、認証、対象システムへのログオン、セッション開始、操作ログ収集、レビュー画面への表示までを一連で確認します。ログが表示されることだけで完了とせず、利用者名、ファイアファイター ID、対象システム、時刻、操作内容が正しく関連付いているかを確認します。
よくある障害の切り分け
ファイアファイター IDを利用できない場合は、申請状態、承認状態、割当期間、IDのロック状態、対象システムへの接続、IDの権限を順に確認します。承認済みでも利用できない場合、対象システムやコネクタの指定違い、期間の開始前、割当の期限切れが原因になることがあります。
ログが収集されない場合は、セッション自体が記録されているか、対象システムとの接続が成功しているか、収集処理が実行されているか、ログを表示する担当者の権限があるかを確認します。接続は成功していてもログ収集だけが失敗する場合があるため、接続テストと収集結果を分けて確認します。
ログはあるものの操作内容が不足している場合は、対象システム側の監査設定、記録対象のイベント、時刻同期、ログ保持期間を確認します。監査ログは後から有効化して過去の操作を再構成できないため、運用開始前に代表的な緊急作業を実行し、期待する粒度で記録されることを確認します。
利用者やレビュアーが誤っている場合は、個人ID、担当者の組織割当、ワークフローの代理設定、所有者とレビュアーの関係を確認します。人事異動や組織変更の後に不整合が増えやすいため、定期的に所有者、承認者、レビュアーを棚卸しします。
運用開始前のチェックリスト
本番運用に入る前に、次の項目を実際のテストケースで確認します。
- 緊急作業ごとに専用のファイアファイター IDと所有者がある
- ファイアファイター IDの権限が作業目的に限定されている
- 申請、承認、割当、利用終了、レビューの責任者が決まっている
- 申請理由と関連番号を必須項目として扱える
- 承認前の利用を防止できる
- 利用期間の開始前と終了後のアクセスを防止できる
- 操作ログと対象システム側の監査記録を照合できる
- ログの未収集、期限超過、レビュー未完了を通知できる
- IDのロック、パスワード変更、接続障害に対応できる
- 退職、異動、所有者変更時の手順がある
- レビュー結果、是正内容、例外承認を保管できる
運用開始後は、月次または四半期ごとに利用実績を分析します。利用されていないID、利用頻度が過度に高いID、同じ理由が繰り返される作業、レビューの遅延、対象外操作を確認し、ID分割、権限縮小、手順改善、通常変更への移行を検討します。緊急アクセスを便利な恒久権限として扱わず、例外を可視化する仕組みとして維持することが重要です。