SAP セキュリティ & GRC

SAP セキュリティ監査ログの基礎:SM19 設定と SM20 確認方法

SAP のセキュリティ監査ログについて、SM19 の記録設定、SM20 の確認方法、調査時の切り分け、保存と運用のポイントを実務向けに解説します。

SAP セキュリティ監査ログの運用SM19の設定、SM20の確認、運用対応の関係を示すSAP セキュリティ監査ログの運用SM19の設定、SM20の確認、運用対応の関係を示す対象範囲記録されたイベント証跡監査対象を定イベント、ユーザー、クライ…SM19で設定記録条件を保存し、変更内…SM20で確認時刻、ユーザー、クライアント…調査と対応承認記録や変更記録と照合…CertPas オリジナル図解
監査対象の定義からSM19設定、SM20確認、調査までの流れ
目次
  1. セキュリティ監査ログの役割
  2. SM19で監査ログを設定する
  3. SM20で監査ログを確認する
  4. 監査ログが見つからないときの切り分け
  5. 監査ログ運用を安定させる
  6. SM19とSM20の運用チェックリスト
  7. まとめ

SAP のセキュリティ監査ログは、ユーザーのログオン、トランザクション実行、権限関連の操作などを記録し、インシデント調査や内部統制の証跡として利用する機能です。設定は主に SM19、記録されたログの確認は SM20 で行います。実際の運用では、記録対象を決めてから、対象期間・ユーザー・クライアント・イベント種別を絞り込んで確認します。

このページでは、SAP GUI を使った SM19 の設定SM20 の確認方法 を、運用担当者が実施しやすい順序で整理します。GRC 製品のリスク分析や SoD の考え方とは役割が異なるため、必要に応じて SAP セキュリティと GRC の全体像 と組み合わせて運用してください。

セキュリティ監査ログの役割

監査ログは、発生した操作を後から追跡するための技術的な記録です。たとえば、特定ユーザーのログオン失敗、重要なトランザクションの実行、ユーザーや権限に関する変更などを調査する際に、時刻・ユーザー・クライアント・イベントの情報を確認できます。

ログは「不正操作を自動的に防止する仕組み」ではありません。アクセス制御や職務分掌は別途設計し、監査ログは 検知と事後調査 のために利用します。記録が有効でも、対象イベントの選定、保存期間、レビュー担当者が定まっていなければ、調査時に必要な証跡を取り出せません。

監査ログを設計する際は、次の観点を先に決めます。

  • どのイベントを記録するか
  • どのユーザー、クライアント、システムを対象にするか
  • 日常レビューとインシデント調査で誰が確認するか
  • ログをどの期間保持するか
  • エクスポートした記録をどこに保管するか
SM20にイベントが表示されない場合監査ログが見つからない場合の実務的な切り分け順序を示すSM20にイベントが表示されない場合監査ログが見つからない場合の実務的な切り分け順序を示す最初に確認設定済みなら絞り込み後まだ見つからない場合期待したイベントがないSM19の対象範囲を確認イベント、ユーザー、クライ…時刻と検索条件を確認テスト時刻を使い、SM20…承認済みの再テスト管理された操作を実施し、…記録してエスカレーション条件を保存し、担当管理者へ…CertPas オリジナル図解
SM20に監査イベントが表示されない場合の切り分けフロー

SM19で監査ログを設定する

SM19 は、セキュリティ監査ログの記録条件を登録・管理するためのトランザクションです。設定変更を行う前に、監査対象のイベントを業務要件とセキュリティ要件から一覧化します。すべてのイベントを無制限に記録するのではなく、調査価値とログ量のバランスを確認します。

1. 対象システムとクライアントを確認する

ログ設定はシステム環境ごとに管理します。開発、検証、本番で目的が異なるため、最初にログオン先のシステムとクライアントを確認します。本番環境の設定を変更するときは、変更申請、承認者、実施時刻、変更前後の内容を記録します。

2. 監査対象のイベントを選ぶ

SM19 では、ログオン関連、トランザクション関連、ユーザー・権限管理関連など、監視したいイベントカテゴリを選択します。対象は組織のリスクに合わせて定義します。たとえば、特権ユーザー、緊急アクセス用ユーザー、ユーザー登録・削除、ロール変更、重要トランザクションの実行などを優先します。

重要な業務操作を記録する場合は、業務部門と 監査対象の境界 を合意します。対象を広げるほど調査材料は増えますが、レビュー負荷、保存容量、個人情報の取り扱いも増えます。

3. ユーザーと対象範囲を設定する

監査対象をユーザー単位で絞る場合は、特権ユーザーや運用ユーザーなど、管理上のグループを明確にします。全ユーザーを対象にする設定では、通常業務のログ量が大きくなるため、保存容量とレビュー手順を先に確認します。

クライアント単位で運用している場合は、業務データを扱うクライアントを対象に含めます。システム管理用クライアントを対象とする場合は、管理操作の監視目的を明確にしておくと、後のレビューでノイズを減らせます。

4. 設定を保存し、記録開始を確認する

SM19 で条件を保存した後は、設定内容、実施者、実施時刻、対象システムを変更記録に残します。保存だけで終わらせず、テスト用の操作を実施して、期待するイベントがログに現れることを確認します。

設定確認では、次の項目をチェックします。

  • 対象クライアントが正しいこと
  • 監査対象のイベントが選択されていること
  • 対象ユーザーまたは対象範囲が意図どおりであること
  • 記録開始後の操作が SM20 で検索できること
  • ログオン失敗など、検証しやすいイベントが記録されること
SM19とSM20の役割比較設定に使うトランザクションと確認に使うトランザクションを整理するSM19とSM20の役割比較設定に使うトランザクションと確認に使うトランザクションを整理する記録が確認を支える証跡が支えるSM19:設定記録するイベントと対象範…SM20:確認記録された監査イベントを…運用テスト、レビュー、保存、…CertPas オリジナル図解
SM19の監査ログ設定とSM20の確認、および運用活動の比較

SM20で監査ログを確認する

SM20 は、セキュリティ監査ログを検索・表示するためのトランザクションです。調査では、最初から広い期間や全ユーザーを指定せず、発生時刻、ユーザー、クライアント、イベント種別の順に条件を絞ります。検索条件と取得時刻も記録しておくと、後から同じ調査を再現できます。

期間を先に絞り込む

対象期間は、アラートや問い合わせで示された時刻の前後に設定します。時刻の基準が異なるシステムや監視製品と突き合わせる場合は、タイムゾーンとサーバー時刻を確認します。広い期間を一度に検索すると、処理時間と結果件数が増え、重要なイベントを見落としやすくなります。

ユーザーとイベントを組み合わせる

不審なユーザーが判明している場合は、ユーザーを指定してイベントを確認します。ユーザーが不明な場合は、特権ユーザー、技術ユーザー、緊急アクセス用ユーザーなど、リスクの高い範囲から調査を開始します。

イベント種別を組み合わせると、単独のログよりも操作の流れを把握しやすくなります。たとえば、ログオン、権限変更、対象トランザクションの実行、ログオフを時系列で並べると、アカウント利用の状況を確認できます。

結果を業務上の事実と照合する

SM20 の結果だけで不正と判断せず、変更依頼、チケット、ジョブ実行記録、ユーザーへの確認結果と照合します。予定された保守作業や緊急対応であれば、承認記録と実行時刻が一致するかを確認します。

調査記録には、検索条件、該当イベント、ユーザー、時刻、クライアント、関連する変更番号、判断、次の対応を残します。ログのスクリーンショットだけでなく、検索条件と出力データを保存すると、レビュー時の説明が容易になります。

監査ログが見つからないときの切り分け

SM20 に期待したイベントが表示されない場合は、設定、対象範囲、時刻、検索条件、保存状態の順に確認します。まず、SM19 で該当イベントが記録対象になっていることを確認し、次に操作したユーザーとクライアントが対象に含まれていることを確認します。

その後、次の手順で切り分けます。

  1. テスト操作の実施時刻を確定する
  2. SM19 で対象イベントと対象ユーザーを確認する
  3. SM20 の期間をテスト時刻の前後に限定する
  4. ユーザー、クライアント、イベントの条件を一つずつ確認する
  5. 監査ログの保存状態とシステムの稼働状態を確認する
  6. 設定変更後に新しい操作で再テストする

ログオン失敗を検証する場合は、テスト用アカウントと承認済みの検証時間を使います。実ユーザーのパスワードを繰り返し誤入力する方法は、アカウントロックを発生させるため、運用手順として採用しません。

ログが記録されているのに検索できない場合は、期間の指定、ユーザー名の入力、クライアント条件、イベントカテゴリを個別に見直します。結果をエクスポートして調査担当者へ渡すときは、アクセス権と個人情報の取り扱いを確認します。

監査ログ運用を安定させる

監査ログは、設定して終わりではなく、日常レビューとインシデント対応の両方に組み込みます。日常レビューでは、特権ユーザー、ユーザー・ロール変更、ログオン失敗など、優先度の高いイベントを定期的に確認します。インシデント対応では、アラートの発生時刻を起点に、前後の操作を時系列で追跡します。

定期レビューの手順を固定する

レビュー担当者、頻度、対象イベント、確認結果の記録場所、エスカレーション条件を文書化します。レビュー結果は「異常なし」だけで終わらせず、対象期間、検索条件、確認件数、例外、承認者を残します。

監査ログと SoD のレビューは補完関係にあります。SoD は職務の組み合わせによるリスクを分析し、監査ログは実際の操作を追跡します。職務分掌リスクを整理するときは、SAP SoD(職務分掌)基礎 を参照してください。

特権ユーザーを重点管理する

特権ユーザーは、監査ログの対象、利用申請、承認、利用後レビューを一つの運用にまとめます。緊急アクセスを利用する環境では、SAP Emergency Access Management(Firefighter)の概要 と監査ログの記録を関連付け、利用理由と実行操作を追跡できる状態にします。

保存とアクセスを管理する

ログの保存期間は、社内規程、契約、法令、監査要件を確認して決めます。保存先へのアクセスは必要最小限にし、ログを削除・エクスポート・閲覧できるユーザーを管理します。ログを別媒体へ保管する場合は、取得日時、取得者、対象期間、ハッシュ値など、完全性を確認できる情報を運用規程に含めます。

SM19とSM20の運用チェックリスト

本番環境で運用を開始する前に、次の項目を確認します。

  • 監査対象のイベントと選定理由が文書化されている
  • 対象システム、クライアント、ユーザー範囲が定義されている
  • SM19 の変更申請と承認記録が残っている
  • テスト操作が SM20 で検索できる
  • 日常レビューの担当者と頻度が決まっている
  • 異常検知時のエスカレーション先が決まっている
  • ログの保存期間と保管場所が定義されている
  • ログの閲覧、エクスポート、削除に関する権限が管理されている
  • 設定変更後の再テスト手順がある

このチェックリストを変更管理や内部統制の手順に組み込むと、担当者が交代しても同じ基準で監査ログを確認できます。アクセス権やユーザー管理の設計は、SAP Access Control の概要 と合わせて整理すると、予防・検知・是正の役割分担を明確にできます。

まとめ

SAP のセキュリティ監査ログでは、SM19 で記録対象を設計し、SM20 で期間・ユーザー・クライアント・イベントを絞り込んで確認します。重要なのは、ログを有効化することだけでなく、テストで記録を確認し、定期レビュー、保存、エスカレーションまでを一つの運用として整えることです。

ログが見つからない場合は、設定、対象範囲、時刻、検索条件を順番に確認します。特権ユーザーや緊急アクセスの操作は、承認記録や変更管理の証跡と突き合わせることで、操作の正当性を判断しやすくなります。

ブログ一覧へ戻る