データベースには、規制当局、攻撃者、監査人が最も関心を持つ顧客、支払い、健康記録が保存されています。SQL Server、Oracle、MySQL、PostgreSQLのネイティブ監査機能はオブジェクトや権限の変更を記録しますが、誰が機密行を読んだかについての可視性はほとんど提供しません。
Netwrix 2026年 データおよびIdentityセキュリティレポートによると、機密データの露出の75％は、侵害されたIDまたは誤設定された権限から始まります。ネイティブ監査は、これらのIDが最も強い権限を持つ場所、つまり監査証跡を自ら編集できるprivileged accountsに対して最も視認性が低いです。
データベースのアクティビティ監視は、アクセス、変更、および管理操作の独立した記録を作成し、セキュリティチームがインシデントを調査し、コンプライアンスを証明し、侵害されたアカウントや静かな構成変更が報告対象の違反になる前に不正使用を検出できるようにします。
データベースアクティビティモニタリングとは何ですか？
データベースアクティビティモニタリング（DAM）は、データベースエンジン自体とは独立して、データベース内のユーザーおよび管理者の活動をキャプチャ、保存、分析するセキュリティの分野です。要求に応じて、誰が接続したか、何を読み取ったかまたは変更したか、監査設定が変更されたかどうかを回答します。
DAMはパフォーマンス監視と並行して使用されますが、目的は異なります。パフォーマンスツールはCPU、I/O、クエリの遅延を追跡してエンジンの健全性を保ちます。一方、DAMはSQL文、ユーザーID、クライアントIPアドレス、タイムスタンプを記録し、活動を特定の人物やサービスに紐づけられるようにします。
DAMツールは、network tap、ホストエージェント、またはデータベース自身の監査機能を通じて情報を収集し、その記録が侵害された管理者アカウントから保護されるように、データベース外のリポジトリに転送します。
なぜデータベース活動の監視が重要なのか
データベース管理者（DBA）やセキュリティアナリストにとって、インシデントや監査で難しいのは誰が何に触れたかを証明することです。独立したデータベースの記録がなければ、チームは部分的なログから手作業でその証拠を再構築し、通常は期限内に行います。
機密データはデータベース層に集中しています
顧客記録、カード保有者データ、およびprotected health information (PHI)はデータベースのテーブルに存在します。規制対象のデータは必ずどこかでデータベースを通過します。データベースアクセスが監視されていないと、環境内で最も機密性の高い資産は最も近い責任の層を失い、その後のすべての管理は記録されていないトレイルに依存します。
ネイティブデータベースログは調査をサポートできません
SQL Serverのデフォルトトレースはオブジェクトと権限の変更を記録しますが、SELECTアクティビティは記録せず、100MBの履歴のみを保持します。さらに悪いことに、Microsoftは警告しています。sysadminsは監査証跡自体を改ざんする可能性があるため、NIST SP 800-53 AU-9(2)では、監査記録を監査対象とは別のシステムに保存することを要求しています。
コンプライアンスフレームワークはデータベースの監査証跡を必要とします
すべての主要なフレームワークは、データベースの活動を証拠として扱います。 PCI DSS v4.0.1 要件10は、カード保有者データアクセスと監査ログの整合性について12か月の記録を義務付けています。HIPAAの45 CFR 164.312(b) はePHIシステムの活動を記録・検査する仕組みを要求しています。
Ernst & Young Incorporatedに関する2023年の検査報告書で（PCAOBリリース番号104-2024-113）、PCAOBはSOXに基づく財務報告の内部統制監査において、クライアントの管理責任者が会計システムの背後にあるデータベースへの直接変更をどのように確認したかを評価しなかったとして同社を指摘しました。
GDPR 第5条2項は、管理者が規則の原則に準拠していることを示すことを要求しており、個人データに誰がアクセスしたかを示すことを含みます。
侵害されたアカウントと内部者の悪用は、最初にデータベースで表面化します
有効なログインは、実行内容を記録するシステムを除き、すべてのシステムに正当なものとして見えます。そのため、資格情報の盗難や内部者の悪用は、ほとんど境界コントロールをトリップしません。Verizonの2026 Data Breach Investigations Reportによると、資格情報の悪用は攻撃チェーンのいずれかの時点で39％の侵害に関与しており、継続的なデータベース監視は、その後に続く横移動を検出する最も早い場所であることが多いです。
Netwrix AuditorはハイブリッドMicrosoft環境でのアクセスおよび変更イベントの前後の値を記録します。デモをリクエストしてください。
監視が必要なデータベースのアクティビティ
以下のカテゴリは、それぞれ独自の検出ルールを正当化するに足るセキュリティまたはコンプライアンスの重要性を持っています。これらは、誰がアクセスしたか、何を読んだり変更したか、記録が改ざんされたかをカバーしており、すべての調査の出発点となる質問です。
認証および接続イベント
ログオン記録は、盗まれた資格情報が最初に明らかになる場所です。ログイン失敗はパスワード推測やcredential stuffingを示し、異常なソースからの成功したログインは、資格情報が使用すべきでない場所で使われていることを示します。
特権およびサービスアカウントのログオンは特に注意が必要です。サービスアカウントが通常のアプリケーション層ではなく新しいワークステーションから突然接続する場合は、ほぼ常に調査する価値があります。Oracleは新しいデータベースでデフォルトでpredefined failed-logon policyを有効にしますが、アップグレードされたものは手動でオンにする必要があることが多いです。
機密データの読み取りと一括エクスポート
規制対象のテーブルを誰が照会したかを直接把握することは、情報漏えいが発生したことを知ることと、何が持ち出されたかを証明することを区別します。ユーザーがこれまで触れたことのないテーブルへの初回アクセスや、bcpやexpdpなどのツールによる大量抽出は、最も注視すべき読み取りパターンであり、同じ行動はエンドポイントでdata loss preventionコントロールが監視しています。
スキーマおよび構成の変更
スキーマおよび構成の変更は、データを破壊したり、その他すべてを検出するための監視を無効にする可能性があります。 CREATE、ALTER、および DROP ステートメントはテーブルやストアドプロシージャに対して独自のアラートが必要であり、監査構成の変更には最速の対応が求められます。 Microsoftは xp_cmdshell をSQL Serverでデフォルトで無効にしています。これを有効にすると攻撃者にコマンドシェルを与えてしまいます。
新規または昇格された権限
単一の権限付与により、制限されたアカウントがすべてを読み取るか、監査ログを完全に無効にするアカウントに変わることがあります。SQL Serverのsysadminロールへの変更、新しいログイン、およびOracleの同等のDBAロールへの追加は交渉不可能なアラートであり、同じくprivilege escalationパターンがアイデンティティ層で監視されています。最小権限が基本的な制御です。OracleのORA_ACCOUNT_MGMTポリシーがこれをカバーしていますが、デフォルトで無効になっています。
機密テーブルへのデータ変更
給与や口座残高が無断で変更された場合、最初の疑問は変更前の値が何であったかです。ネイティブの監査記録はステートメントのテキストのみを記録し、行の値は記録しないため、SQL ServerのChange Data Capture、MySQLの行イメージバイナリログ、またはPostgreSQL triggersのような別の仕組みで変更前後の内容を保存する必要があります。規制対象テーブルへの大量または営業時間外の変更に関するアラートはMITREのT1565, Data Manipulationにマッピングされます。
通常のパターンを破るアクティビティ
ベースラインルールは、単独では普通に見えるが、そのアカウントにとっては異常な活動を検出します。例えば、ユーザーが5分間に突然10のテーブルをクエリしたり、既知のアプリケーションアカウントが新しいIPアドレスから接続したりする場合です。
これはネイティブな監査設定ではなくSIEM分析に依存する唯一のカテゴリであり、アカウント層でidentity threat detectionが使用するのと同じ行動ベースのアプローチです。
データベースアクティビティ監視の実装方法
各ステップは前のステップに依存するため、5つのステップを順番に進めてください。ステップ1で範囲を決めると、ステップ2で適切な収集方法が決まります。
彼らはまた、すべてのイベントを手動で確認できない小規模なチームを想定しているため、以下のいくつかのステップは手動のトリアージではなく、段階的な展開と自動化されたベースラインに依存しています。
1. 監視する範囲を定義します
給与、カード保有者、健康、知的財産などの規制対象またはビジネスに敏感なデータを保持するデータベースをインベントリ化し、規制の要因でランク付けすることから始めます。そのインベントリは、どのテーブルに敏感なフィールドがあるかを知って初めて意味があるため、まず data classification を実行してください。これをスキップすると、給与監査仕様に指摘できるものがありません。
リスクは現実的です：Netwrix 2026 Data and Identity Security Reportの調査によると、57％の組織が機密データのインベントリを継続的に管理しておらず、多くのチームがこのステップを手探りで始めています。
機密データベースをマッピングしたら、それにアクセスするprivileged、共有、およびサービスアカウントにも同じインベントリを拡張し、通常ユーザーログが選択的であっても、すべてのprivilegedセッションを完全に監視することを約束してください。
CIS Safeguard 8.5 はそのコミットメントの最低基準を定めています。最低でも、機密データを保持するすべての資産について、ユーザー名、タイムスタンプ、送信元および送信先のアドレスを記録してください。
2. 環境に合った収集方法を選択してください
サーバーに負荷をかけたくない場合は、SPANポートを介したパッシブネットワークキャプチャから始めるのが適切です。ただし、その負荷ゼロのトレードオフにより、forward-secret Transport Layer Security (TLS)、ローカル接続、およびクラウド管理データベースの可視性が失われます。
ステートメントの表示よりもブロックが重要な場合は、TLSを自ら終了するインラインプロキシの方が適していますが、その制御により遅延が発生し、プロキシが可用性の依存対象となります。
その後もローカル接続のカバレッジが必要で、チームがCPUコストとカーネルやデータベースのアップグレードごとに発生する再検証作業を許容できる場合、ホストエージェントがそのギャップを埋めます。データベースをサービスとして運用するチーム（DBaaS）や、ストアドプロシージャや暗号化の可視化が必要なチームは、ネイティブ監査とエージェントレス収集を組み合わせて対応します。
Oracleは ネイティブ監査における中程度の一桁台のCPU負荷を報告しています 最大360,000件の監査記録/時。エージェントレス収集はさらに負荷を加えるため、導入前に組み合わせをテストしてください。
実際には、多くのチームが方法を組み合わせています。OracleのAVDFドキュメントは、ネットワーク監視とデータベース監査を組み合わせて、それぞれの盲点を補うことを推奨しているためです。
3. 小規模チームが対応できるポリシーとアラート閾値を設定する
ルールは一度にすべてではなく段階的に有効にしてください。初日からすべてを有効にすると、小規模チームが誤検知に埋もれてしまいます。上記の6つのアクティビティカテゴリからマッピングされた監査改ざんとsysadmin権限付与から段階的な展開を開始してください。これら2つは見逃しアラートに対する許容度が最も低いためです。
NIST SP 800-94 は、新たに導入されたシステムは環境に完全に適合する前に過剰な誤検知を発生させることが多いと警告しており、これが段階的アプローチが重要な理由です。
ボリュームおよびアクセスパターンのルールは異なる処理が必要です。少なくとも1週間のベースラインデータに基づいて調整された異常として実行してください。これは、Microsoft Sentinelが独自の影響を受けた行の異常ルールに使用する14日間のトレーニング期間と同じ規模です。
これらの閾値は普遍的な数値に従うのではなく、環境に限定されると予想してください。あるチームの異常は100行、別のチームは500,000行であり、自分自身の基準値だけがどちらがどちらかを明らかにします。
4. データベースイベントを集中管理し、identityコンテキストと関連付けます
まずログ収集を集中化し、CIS Safeguard 8.9が要求するように、大量のイベントデータセットを人間が確認できる範囲に絞り込むツールを使用します。パイプラインが構築されたら、各イベントをその背後にあるアカウントと関連付けます。アイデンティティのコンテキストがない集中ログでは、名前ではなく生のSQL文を読むことになってしまいます。
Microsoft Sentinelでは、その相関は特定のテーブルを通じて行われます。Azure SQLの監査イベントをSQLSecurityAuditEventsテーブル（または旧設定ではAzureDiagnostics）にルーティングし、SQL ServerのWindowsイベントをSecurityEventへ、DefenderのアラートをSecurityAlert; その後、IdentityInfoテーブルを使用して、各アカウントの背後にいる人物を特定します。
Splunk と IBM QRadar のユーザーは、自身のアイデンティティ検索で同じパターンを適用できます。これにより、「誰かが大きなSELECTを実行した」という事実を「2時間前にsysadminに追加された契約者アカウントが大きなSELECTを実行した」に変えることができます。
5. 監視パイプラインをテスト、調整、維持します
本番環境で信頼する前に、代表的なアクティビティでパイプライン全体をテストしてください。サーバーロールにテストログインを追加し、監査仕様を変更し、600行のエクスポートを実行してから、各アラートが正しいIDとともに届くことを確認します。イベントを記録してもIDコンテキストを失うパイプラインは半分しか完成していません。
アプリケーションが変更されるたびにベースラインを再構築し、定期的に監査ポリシー自体を再確認してください。なぜなら、Oracle's AVDF documentationではDBAがそれらを変更または削除できると警告しているからです。設定をスケジュールに従って取得し、レビューしてください。CIS Safeguard 8.1では少なくとも年に一度のレビューを求めています。
保持には同じ規律が必要です。PCI DSSの12か月の最低期間を基準として、適用される最も厳しい規定に設定し、Azure SQLパイプラインにデータを供給する診断設定も監視リストに残してください。削除すると収集が静かに停止する可能性があります。
Netwrixがデータベースの活動を監視する方法
上記の作業の大部分は、範囲の定義からアイデンティティコンテキストの相関付けまで、使用するツールに関係なく適用されます。Netwrix Auditor は SQL Server と Oracle の収集、アラート、前後の詳細をカバーし、Netwrix Access Analyzer は権限と機密データのレイヤーを追加します。
ログオンと特権アクセスの追跡
Netwrix AuditorのSQL Server monitoringは成功および失敗したログオンを記録し、特権操作やサーバーロールの変更を含むDBAの活動を追跡します。そのOracle Database monitoringソフトウェアは成功および失敗したログオンを追跡し、SQL文と権限を監視します。どちらのソースでも、アナリストにメールを送信したり、ユーザーが定義したスクリプトを応答アクションとして実行するようにアラートを設定できます。
Auditorのレポートはコンプライアンスの証拠としても役立ちます。 First National Bank and Trust of BeloitはOCCコンプライアンスの主要ソリューションとしてNetwrix Auditorを使用しており、監査準備に1週間ではなく1時間を費やしています。 Bank of the Southはビジネスに重要なデータを保護し、PCI DSSおよびGLBAに準拠するために使用しており、監査準備に年間少なくとも40時間を節約しています。
データ変更の前後の値をキャプチャする
Netwrix Auditor for SQL Serverはデフォルトでトリガーレスモードで動作し、追加の負荷なしに5分ごとにトレースログを読み取り、誰がいつ何を変更したかを報告します。トリガーベースのモードは、INSERT、UPDATE、DELETEの前後の値を追加しますが、これはネイティブ監査では提供できず、高トランザクションサーバーでは追加の負荷がかかります。
アクティビティを機密データに接続する
Netwrix Auditor はトリガーレスモードで設定したテーブルとポリシーを使用してテーブルレベルで機微データのコンテキストを適用し、レポートが規制対象テーブルのアクティビティを検出できるようにします。SQL ServerおよびOracle全体でのより深い検出と権限分析には、Netwrix Access Analyzer が効果的な権限をマッピングし、Auditor単独ではカバーできない過剰に公開されたデータを明らかにします。
本番環境への影響を最小限にした展開
Netwrix Auditorはリモートで収集するため、トリガーベースのモードのみが監視対象のテーブルにアクセスします。Oracleの収集はAuditorサーバー上のOracle Instant Clientを通じて10分ごとに実行され、SQL Serverのトレース読み取りは5分ごとに実行されます。アドオンは、すでにSIEMに集中しているチーム向けに活動記録をSplunk、IBM QRadar、ArcSightに転送します。
データベースアクティビティの監視を実践する
最も規制の厳しいデータを保持するインスタンスから開始し、ベースラインを確立して、最初のアラートセットが実行可能な結果をもたらした後にのみ拡張してください。
クラウド管理されたワークロードの場合、カバレッジはデータソースと展開モデルによって異なります。Netwrix Access Analyzerは機密データを検出し、SQL Server、Azure SQL、Amazon RDS for SQL Server、およびOracleの権限を分析します。
デモをリクエストして、Netwrixがデータベースの活動を監視し、監査証跡を集中管理し、不正使用を侵害前に検出する方法をご覧ください。
データベースアクティビティ監視に関するよくある質問
共有する
もっと詳しく
著者について
