Microsoft DefenderポータルでMicrosoft Sentinelを使ってSAPを監視する場合、最初に確認すべきポイントは「SAPデータコネクタエージェントの廃止」と「エージェントレス接続への移行準備」です。公式ドキュメントでは、SAP環境をMicrosoft Sentinelに接続する前に、SAPロール、監査ログ、SAP BTP、SAP Cloud Connector、RFC宛先、前提条件チェッカーなどを整える必要があるとされています。(Microsoft Learn)
特に既存環境でコンテナ化されたSAP data connector agentを使っている場合は、2026年9月14日に恒久的に無効化される予定のため、エージェントレスデータコネクタへの移行計画を早めに立てるべきです。(GitHub)
なお、対象の「Configure your SAP system for the Microsoft Sentinel solution」ページは確認時点で2026年4月29日更新と表示されています。一方、SAP向けMicrosoft Sentinelソリューションのデプロイ概要、前提条件、移行ガイドなどの関連公式ページは2026年5月14日更新として掲載されています。本稿では、これらの関連公式情報を含め、管理者・開発者が実務で確認すべき変更点と対応手順を整理します。(Microsoft Learn)
Microsoft DefenderでのSAP監視は「Sentinelの接続方式」が焦点になる
今回の公式情報は、Microsoft Defenderそのものの単体機能追加というより、Microsoft Defenderポータル上で利用できるMicrosoft SentinelとSAPシステムをどう接続するかに関する更新です。
Microsoft Sentinel solution for SAP applicationsは、SAPシステムからログを収集し、Microsoft Sentinelのワークスペースへ送信します。あわせて、分析ルール、ワークブック、Watchlist、Playbookなどのセキュリティコンテンツを使い、SAP環境の不審操作や権限変更、監査ログ無効化、ブルートフォース、データ持ち出しの兆候などを検出します。(Microsoft Learn)
ここで重要なのは、SAPデータの取り込み方法が主に次の2系統に分かれることです。
| 接続方式 | 概要 | 今後の判断 |
|---|---|---|
| エージェントレスデータコネクタ | SAP Cloud ConnectorとSAP Integration Suiteを使ってSAPログを取得する方式 | 新規導入・移行先として優先して検討 |
| コンテナ化SAP data connector agent | Dockerコンテナとして動作する従来型のエージェント方式 | 2026年9月14日の無効化予定を前提に移行が必要 |
すでにMicrosoft SentinelでSAP監視を行っている企業ほど、「動いているから問題ない」と判断しがちです。しかし、旧エージェント方式の廃止予定が明示されているため、単なる設定確認ではなく、移行計画、権限設計、ログ取り込み設計を含めた見直しが必要です。(Microsoft Learn)
今回の変更点・確認ポイント
公式情報から読み取れる実務上のポイントは、次の4つです。
| 確認ポイント | 影響を受ける担当者 | 実務上の対応 |
|---|---|---|
| SAP data connector agentの廃止予定 | SOC、Azure管理者、SAP BASIS、インフラ担当 | エージェントレス方式への移行計画を作成 |
| エージェントレス接続の前提条件 | SAP BASIS、SAP BTP管理者、Entra ID管理者 | SAP BTP、Integration Suite、Cloud Connector、アプリ登録権限を確認 |
| SAP側の監査ログ・ロール設定 | SAP BASIS、セキュリティ管理者 | Sentinel用のSAPロール、システムユーザー、監査ログ設定を確認 |
| 前提条件チェッカーの利用 | SAP BASIS、SOC | 接続前にiflowを実行し、警告やエラーを解消 |
特に注意したいのは、エージェントレス接続ではSAP側だけで完結しない点です。Microsoft Sentinel、Microsoft Entra ID、SAP BTP、SAP Integration Suite、SAP Cloud Connectorの担当者が連携しなければ、接続設定は途中で止まりやすくなります。
対象者はSOCだけではない
この対応は、Microsoft DefenderやMicrosoft Sentinelを管理するセキュリティチームだけの作業ではありません。SAP側の認可、RFC、監査ログ、BTP設定が絡むため、複数チームで役割を分担する必要があります。
SOC・セキュリティ管理者が確認すること
SOCやセキュリティ管理者は、Microsoft Sentinel側の設定と運用影響を確認します。
具体的には、Microsoft SentinelのContent hubからSAP applications solutionをインストールし、Log Analyticsワークスペース、データコネクタ、分析ルール、ワークブックが正しく展開されているかを確認します。公式情報では、SAP向けソリューションのインストールにより、agent-basedとagentlessの両方のデータコネクタがMicrosoft SentinelのData connectorsページに表示されるとされています。(Microsoft Learn)
確認すべき項目は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| Sentinelワークスペース | SAPログを取り込むLog Analyticsワークスペースが有効か |
| 権限 | ソリューション展開、DCR/DCE作成、ロール割り当てに必要な権限があるか |
| データコネクタ | agentless data connectorを利用する前提で設計しているか |
| 分析ルール | 既存のSAP関連ルールやワークブックが移行後も使えるか |
| 取り込み量 | SAPログ増加によるコスト影響を見積もっているか |
ログの取り込み量は、SAPシステムの利用状況、ユーザー数、モジュール、ログ種別、ネットワークトラフィックなどに左右されます。公式ドキュメントでも、各SAPシステムがMicrosoft Sentinelへ送るログ量をテストすることが推奨されています。(Microsoft Learn)
SAP BASISチームが確認すること
SAP BASISチームは、SAP側のロール、ユーザー、監査ログ、RFC関連設定を中心に確認します。
Microsoft SentinelのSAPデータコネクタがSAPシステムに接続するには、専用のSAPロールとシステムユーザーが必要です。エージェント方式では/MSFTSEN/SENTINEL_RESPONDER、エージェントレス方式ではMSFTSEN_SENTINEL_READERのように、接続方式によって参照するロールが異なります。(GitHub)
ここで失敗しやすいのは、旧エージェント用の権限をそのままエージェントレス接続に流用することです。Microsoftの移行ガイドでは、エージェントレスデータコネクタは従来のコンテナ化エージェントと比べて「少ないが異なる権限」を必要とするため、SAPシステム上のSentinelユーザーとロールの認可を確認するよう明記されています。(Microsoft Learn)
Microsoft Entra ID管理者が確認すること
エージェントレスデータコネクタでは、Azureリソースの自動展開やアプリ登録に関わる権限が必要です。公式ドキュメントでは、agentless data connectorで関連Azureリソースを展開するには、Microsoft Entra IDのApplication Developerロール以上が必要とされています。(Microsoft Learn)
権限が不足している場合、DCRやDCEが作成されても、アプリ登録やサービスプリンシパルの認可が不完全になり、SAP側からログを送れない状態になりやすいです。
確認すべき項目は次のとおりです。
| 項目 | 具体例 |
|---|---|
| Entra ID権限 | Application Developer以上の権限があるか |
| Azure RBAC | DCRにMonitoring Metrics Publisherが割り当てられているか |
| クライアント情報 | client ID、client secret、token URLを安全に管理しているか |
| シークレット運用 | BTP client secretの定期ローテーション手順があるか |
エージェントレス接続で必要になるSAP側の準備
エージェントレス接続では、SAP Cloud ConnectorとSAP Integration Suiteを使ってSAPシステムからログを取得します。従来のコンテナ管理を減らせる一方で、SAP BTPやIntegration Suiteの設定が必要になります。(Microsoft Learn)
SAP BTPで必要なサービスを有効化する
SAP BTPサブアカウントでは、次のサービスを準備します。
| サービス | 用途 |
|---|---|
| SAP Integration Suite | Microsoft Sentinel向けのIntegration Packageやiflowを扱う |
| SAP Process Integration Runtime | Integration flowの実行基盤として利用 |
| Cloud Foundry Runtime | Cloud Foundry環境での実行に必要 |
公式手順では、SAP Integration SuiteのCloud Integration capabilityを有効化したうえで、PI_Administrator、PI_Integration_Developer、PI_Business_Expertなどのロールをユーザーに割り当てる流れが示されています。また、SAP Process Integration Runtimeはintegration-flowサービスプランでインスタンスを作成し、サービスキーのJSONを安全な場所に保存する必要があります。(GitHub)
実務では、このJSONに含まれるclientid、clientsecret、tokenurl、urlがSentinel側の接続情報として使われます。平文でチケットやチャットに貼るのではなく、Key Vaultや社内の承認済みシークレット管理基盤で扱うべきです。
SAP Integration SuiteにMicrosoft Sentinel Solutionを取り込む
エージェントレス接続では、SAP Integration Suite側でMicrosoft Sentinel Solutionのパッケージを取り込み、Data Collectorの設定を行います。
公式手順では、SAP Integration SuiteポータルのDiscoverからMicrosoft Sentinel Solutionを検索し、パッケージをコピーして、ArtifactsタブからData Collectorを設定します。その後、Microsoft Sentinel側で得られるLogIngestionURLとDCRImmutableIDをiflowに設定してデプロイします。(Microsoft Learn)
ここでの典型的な失敗は、DCRやDCEの展開後に値が反映されないまま作業を進めることです。公式手順では、値が自動入力されない場合、手順を閉じて再展開し、値を更新する流れが示されています。(Microsoft Learn)
SAP Cloud ConnectorでRFC接続を公開する
SAP Cloud Connectorでは、バックエンドABAPシステムをRFCプロトコルでマッピングします。さらに、Microsoft Sentinelが必要なデータを取得できるよう、以下のような関数名をリソースとして追加します。
| 関数名 | 主な用途 |
|---|---|
RSAU_API_GET_LOG_DATA | SAP Security Audit Logの取得 |
BAPI_USER_GET_DETAIL | SAPユーザー詳細の取得 |
RFC_READ_TABLE | 必要なテーブルの読み取り |
SIAG_ROLE_GET_AUTH | セキュリティロール認可情報の取得 |
/OSP/SYSTEM_TIMEZONE | SAPシステムのタイムゾーン情報取得 |
公式情報では、提供されるロールは最小権限アクセスとして構成されているものの、RFC_READ_TABLEなどの機能モジュールはSAP Cloud ConnectorやSAPロールだけでなく、SAPのRFCアクセスのベストプラクティスやUCON設定も考慮するよう案内されています。(Microsoft Learn)
つまり、「Sentinelに必要だからRFC_READ_TABLEを広く許可する」のではなく、Cloud Connector、SAPロール、UCONの複数層で制御するのが安全です。
SAP監査ログ設定は「必要なものだけ」ではなく広めに考える
Microsoft Sentinel for SAPの検出精度は、SAPから取り込む監査ログの質に大きく左右されます。公式ドキュメントでは、SAPシステムで監査ログが既定で有効になっていない場合があるため、監査を有効化し、監査パラメータを構成することが推奨されています。さらに、特定ログだけでなく、監査ログのすべてのメッセージを構成することも推奨されています。(Microsoft Learn)
理由は明確です。攻撃や内部不正の調査では、後から「このログも必要だった」と気づくことが多いためです。たとえば、権限昇格のアラートだけでは原因を追いきれず、ログオン履歴、クライアントIP、ロール変更、テーブル参照などの周辺情報が必要になるケースがあります。
SAP HANA DBログも対象ならHANA側の監査を確認する
SAP HANA DBログをMicrosoft Sentinelに取り込む場合は、SAP HANA DB側でも監査を有効化する必要があります。SAPアプリケーション層の監査ログだけを有効にしても、HANA DB側の監査イベントは十分に取得できない可能性があります。(Microsoft Learn)
RISE/ECSやS/4HANA Cloudでは責任分界を確認する
SAP RISE/ECSで管理されるSAPシステムでは、Security Audit Logの有効化が共有責任に含まれるため、監査が既定で有効か、追加作業が必要かをSAP側の窓口に確認する必要があります。また、SAP S/4HANA Cloud public editionでは監査が既定で有効とされています。(Microsoft Learn)
クラウドSAP環境では、オンプレミスと同じ感覚でBasisチームがすべて変更できるとは限りません。契約形態と責任分界を確認せずに作業計画を立てると、接続直前に「その設定はSAP側依頼が必要」と判明し、展開が遅れます。
コンテナ化SAP data connector agentを使っている場合の移行手順
既存環境でコンテナ化されたSAP data connector agentを使っている場合は、停止日を待たずにエージェントレス接続へ移行する計画を立てます。
公式移行ガイドでは、移行の流れとして、既存環境の評価、機能差分の確認、エージェントレス接続の展開、ログ収集の検証、並行稼働、旧エージェントの廃止が示されています。(Microsoft Learn)
| フェーズ | 実施内容 | 注意点 |
|---|---|---|
| 評価 | 監視対象のSAP SID、ログ種別、カスタム設定を棚卸し | 旧エージェントの設定ファイルだけでなくSentinel側のルールも確認 |
| 設計 | エージェントレス方式の前提条件と権限を確認 | 旧ロールの流用ではなく、必要権限を見直す |
| 展開 | SAP BTP、Integration Suite、Cloud Connector、Sentinelを設定 | SAP BASISとSOCの作業順序を合わせる |
| 検証 | KQLでログ取り込みを確認 | 主要ログが同じ粒度で取れているか確認 |
| 並行稼働 | 旧エージェントとエージェントレスを一定期間併用 | 重複取り込みやコスト増に注意 |
| 廃止 | 旧エージェント停止、不要ロール・CRの削除 | 削除前に監査証跡とロールバック手順を残す |
移行ガイドでは、既存の分析ルール、ワークブック、Playbookへの投資はエージェントレスデータコネクタでも機能し、KQL関数側で両方の取り込み方式をサポートするためにfuzzy union operatorが使われると説明されています。(Microsoft Learn)
ただし、これは「何も検証しなくてよい」という意味ではありません。自社でカスタムKQL、独自Watchlist、独自Playbook、SOCの運用ルールを作っている場合は、テーブル名、列、ログ頻度、遅延、重複を実データで確認する必要があります。
接続前に前提条件チェッカーを実行する
エージェントレス接続では、Prerequisite checker iflowを使ってSAPシステムがMicrosoft Sentinel連携の前提条件を満たしているか確認できます。
公式手順では、Integration PackageのArtifactsタブからPrerequisite checker iflowを構成し、対象SAPシステムのRFC destination名を設定してデプロイします。推奨として、1分間隔で24時間実行し、夜間バッチや一時的な利用スパイクなどの異常も把握する流れが示されています。(GitHub)
結果の見方は次のとおりです。
| ステータス | 意味 | 次の対応 |
|---|---|---|
| Completed、警告なし | 前提条件を満たしている | SAPシステムの接続作業へ進む |
| Completed、警告あり | 一部の前提条件に懸念がある | 警告内容を修正してから接続する |
| Failedまたは非200ステータス | SAPシステム到達性または設定に問題がある | RFC宛先、認証情報、iflow設定を確認して再実行 |
実務では、警告が出たまま本番接続へ進まないことが重要です。接続自体は成功しても、特定ログが欠落したり、検出ルールが期待通りに動かなかったりする可能性があります。
前提条件チェックが完了したら、スケジュールされたPrerequisite checker iflowはアンデプロイします。新しいSAPシステムをオンボードする場合は、システムごとに同じ確認を繰り返します。(GitHub)
展開時に失敗しやすいポイント
Microsoft SentinelとSAPの連携は、単一サービスの有効化ではなく、複数基盤をまたぐ設定です。以下のポイントでつまずきやすいため、事前にチェックリスト化しておくと安全です。
ロール名を接続方式ごとに分けて確認していない
エージェント方式とエージェントレス方式では、SAP側で参照するロールが異なります。
旧エージェント方式では/MSFTSEN/SENTINEL_RESPONDERが例として示されています。一方、エージェントレス方式ではMSFTSEN_SENTINEL_READERテンプレートを使ってロールを作成する流れが示されています。(GitHub)
「Sentinel用ロールは作成済み」とだけ確認すると、方式違いの権限不足を見落とします。チケットや設計書には、接続方式、ロール名、対象クライアント、割り当てユーザーを明記してください。
SAP監査ログを一部だけ有効にしている
コストを抑える目的で監査ログを絞りすぎると、検出や事後調査に必要な文脈が不足します。公式ドキュメントでは、監査ログのすべてのメッセージを構成することが推奨されています。(Microsoft Learn)
まずは検証環境または限定した本番範囲で取り込み量を測定し、そのうえで保持期間、検出対象、例外設定を調整するのが現実的です。
SAP Cloud Connectorの公開範囲が広すぎる
RFC_READ_TABLEのような強力な関数を扱う場合、Cloud Connectorで公開しただけで安心してはいけません。SAPロール、UCON、監査ログ、運用レビューを組み合わせ、最小権限で運用する必要があります。(Microsoft Learn)
Entra IDとSAP BTPのシークレット管理が属人化している
エージェントレス接続では、BTP側のサービスキーやEntra IDアプリ登録の情報が接続に関わります。担当者個人のメモ、チャット、ローカルファイルに保存すると、ローテーションや退職時の引き継ぎで問題が起きます。
BTP client secretは定期的にローテーションすることが推奨されています。自動化スクリプトやKey Vaultとの連携も検討し、手動更新だけに依存しない運用を作るべきです。(Microsoft Learn)
初回接続後すぐに「正常」と判断してしまう
公式手順では、初回接続後に待ち時間が発生する可能性があると説明されています。また、ログ取り込みは時間帯やバッチ処理によって偏るため、接続直後の数分だけでは十分な検証になりません。(Microsoft Learn)
最低限、以下を確認します。
| 確認項目 | 見るべきポイント |
|---|---|
| Audit Log | 直近イベントが継続的に入っているか |
| Change Documents | 変更ログが期待どおり取得されているか |
| User Master Data | ユーザー・ロール・権限情報が取得されているか |
| 時刻 | SAPシステム、OS、Sentinel側で時刻ずれがないか |
| 重複 | 並行稼働中に同一イベントが二重に入っていないか |
開発者・運用担当者が見るべきカスタマイズ領域
開発者や運用自動化担当者は、SAP Integration Suiteでのiflow設定や、データコネクタの挙動カスタマイズを確認します。
たとえば、SAP agentless data connectorでは、SAP Integration SuiteのValue Mapping artifactを使って、ログ収集の挙動をカスタマイズできます。公式ドキュメントでは、Sybaseを利用している場合、Change Docs logsの取り込みはサポートされないため、collect-changedocs-logsパラメータをfalseにする例が示されています。(Microsoft Learn)
主なカスタマイズ例は次のとおりです。
| パラメータ | 目的 | 判断基準 |
|---|---|---|
collect-audit-logs | Audit Logの取り込み制御 | 原則は有効。監査対象外にする場合は理由を記録 |
collect-changedocs-logs | Change Docs logsの取り込み制御 | Sybase利用時は無効化を検討 |
collect-user-master-data-users | ユーザー詳細情報の取り込み制御 | 権限分析・ユーザー調査に必要なら有効 |
collect-user-master-data-roles | ロール認可情報の取り込み制御 | 権限昇格検出や棚卸しに必要なら有効 |
ingestion-cycle-days | User Master data全体の取り込み期間 | 初期同期負荷と鮮度のバランスで調整 |
カスタマイズは便利ですが、検出ロジックに影響します。変更する場合は、SOC、SAP BASIS、監査担当の合意を取り、変更前後のログ量とアラート件数を比較してください。
管理者向けチェックリスト
本番展開前に、以下を確認してください。
| 分類 | チェック項目 |
|---|---|
| 接続方式 | 旧エージェント方式を継続していないか、エージェントレス移行計画があるか |
| Sentinel | SAP applications solutionがContent hubから展開済みか |
| 権限 | Sentinel、Azureリソースグループ、Entra ID、SAP BTPの必要権限がそろっているか |
| SAPロール | 接続方式に合ったSAPロールを作成し、システムユーザーに割り当てたか |
| 監査ログ | SAP Security Audit Logを有効化し、必要な監査パラメータを設定したか |
| BTP | Integration Suite、Process Integration Runtime、Cloud Foundry Runtimeを準備したか |
| Cloud Connector | RFC宛先、仮想ホスト、必要な関数リソースを設定したか |
| iflow | Data CollectorとPrerequisite checkerを設定・デプロイしたか |
| 検証 | 24時間程度のチェックとKQLでのログ確認を実施したか |
| 運用 | シークレットローテーション、障害時の切り戻し、旧エージェント停止手順を文書化したか |
次に取るべき行動
まず、現在のSAP監視方式を棚卸ししてください。コンテナ化されたSAP data connector agentを使っている場合は、2026年9月14日の無効化予定を前提に、エージェントレスデータコネクタへの移行スケジュールを作成します。(GitHub)
新規導入の場合は、最初からエージェントレス方式を前提に、Microsoft Sentinel、SAP BASIS、SAP BTP、Entra IDの担当者を集めて設計します。接続作業に入る前に、SAPロール、監査ログ、BTPサービス、Cloud Connector、RFC宛先、Prerequisite checkerの結果をそろえておくことが、展開遅延を避ける近道です。
Microsoft DefenderポータルでMicrosoft Sentinelを運用する環境では、SAPログが入ることだけでなく、検出ルールが意味のあるアラートを出せる状態まで確認して初めて完了です。移行後はKQLで取り込み状況を確認し、ワークブック、Watchlist、Playbook、インシデント対応手順まで一通り検証してください。
コメント