Azure Sentinel KQLによるセキュリティログ分析：アーキテクチャから運用まで

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Sentinel KQLによるセキュリティログ分析：アーキテクチャから運用まで

Azure Sentinel（現在はMicrosoft Sentinelに改称）は、Microsoft Azure上で提供されるクラウドネイティブなSIEM（Security Information and Event Management）およびSOAR（Security Orchestration, Automation, and Response）ソリューションです。Kusto Query Language（KQL）を駆使することで、多種多様なセキュリティログを一元的に収集、分析し、脅威の検出と対応を自動化できます。本記事では、Microsoft SentinelとKQLを用いたセキュリティログ分析のアーキテクチャ、設定手順、運用監視、セキュリティ、コスト最適化、そして一般的な落とし穴について解説します。

アーキテクチャ概要

Microsoft Sentinelの核となるアーキテクチャは、データソースからのログ取り込み、Log Analyticsワークスペースでのデータ保存とKQLによる分析、そして検出・対応メカニズムで構成されます。

  1. データソース: Azureリソース、オンプレミスサーバー、SaaSアプリケーション（Microsoft 365など）、他社クラウド環境など、様々な場所からセキュリティログを収集します。

  2. データコネクタ: Sentinelは、これら多様なデータソースからログを収集するための組み込みコネクタを提供します。例えば、Azure Activity Log、Azure AD、Microsoft 365、Microsoft Defenderシリーズ、Syslog、Common Event Format (CEF) などです。

  3. Log Analytics ワークスペース: 収集されたすべてのログは、Azure Monitor Log Analyticsワークスペースに保存されます。このワークスペースがSentinelのバックエンドデータストアとなり、KQLによってクエリ可能な形式で構造化されます。

  4. Microsoft Sentinel ワークスペース: Log Analyticsワークスペース上にSentinel機能が有効化されます。ここで分析ルール、プレイブック、ハンティングクエリ、ワークブックなどが管理されます。

  5. 分析ルール: 定義されたKQLクエリに基づいて、潜在的な脅威や異常な振る舞いを自動的に検出します。検出された場合はインシデントを生成します。

  6. インシデント: 分析ルールによって生成されたアラートを関連付け、調査が必要なセキュリティ事象として可視化します。

  7. プレイブック: Azure Logic Appsを基盤とする自動応答メカニズムです。インシデント発生時に、特定のタスク（例えば、ユーザーの無効化、IPアドレスのブロック、通知送信など）を自動実行します。

  8. ハンティング: 事前定義されたKQLクエリやカスタムクエリを用いて、既知または未知の脅威を能動的に探索します。

  9. ワークブック: カスタマイズ可能なダッシュボードで、KQLクエリの結果を視覚的に表示し、セキュリティ状況の監視や傾向分析に利用されます。

以下に、主要なコンポーネント間のデータフローを示すアーキテクチャ図を示します。

flowchart TD
    A["データソース"]|セキュリティログ生成| --> B("データコネクタ")
    B --> C["Log Analytics ワークスペース"]|データ取り込み・保存|
    C --> D{"Microsoft Sentinel ワークスペース"}|分析・監視・管理|
    D --> E["分析ルール"]|脅威の自動検出|
    D --> F["KQLハンティング"]|能動的な脅威探索|
    D --> G["ワークブック"]|セキュリティ状況の可視化|
    E --> H["インシデント"]|アラートと関連付け|
    H --> I["プレイブック"]|自動的な対応アクション|

    subgraph セキュリティオペレーションセンター (SOC)
        D --- E
        D --- F
        D --- G
        E --- H
        H --- I
    end

    subgraph Azure 基盤
        A
        B
        C
    end

設定手順

Microsoft Sentinelのデプロイと初期設定には、主にAzure PowerShellまたはAzure CLIが利用できます。ここでは、Azure PowerShellを使った基本的なワークスペース作成とデータコネクタ有効化の例を示します。

1. Microsoft Sentinelワークスペースの作成

既存のLog Analyticsワークスペースを選択するか、新規に作成し、その上でSentinelを有効化します。 （2024年5月10日 JST現在）

# Azureへのログイン (初回のみ)


# Connect-AzAccount

# サブスクリプションの設定 (必要に応じて)


# Select-AzSubscription -SubscriptionName "YourSubscriptionName"

# リソースグループの指定

$ResourceGroupName = "rg-sentinel-dev"
$Location = "japaneast" # または任意のリージョン
$WorkspaceName = "loganalytics-sentinel-prod"
$SentinelWorkspaceName = "sentinel-prod"

# リソースグループの作成 (存在しない場合)

New-AzResourceGroup -Name $ResourceGroupName -Location $Location

# Log Analytics ワークスペースの作成


# SKUは「PerGB2018」が推奨されますが、環境に応じて変更してください。

$laworkspace = New-AzOperationalInsightsWorkspace `
    -ResourceGroupName $ResourceGroupName `
    -Name $WorkspaceName `
    -Location $Location `
    -Sku PerGB2018

# Microsoft Sentinel ソリューションの有効化

New-AzResource `
    -ResourceGroupName $ResourceGroupName `
    -Location $Location `
    -ResourceName $SentinelWorkspaceName `
    -ResourceType "Microsoft.SecurityInsights/Sentinels" `
    -ApiVersion "2023-04-01-preview" `
    -Property @{
        workspaceResourceId = $laworkspace.Id
    }
Write-Host "Microsoft Sentinelワークスペース '$SentinelWorkspaceName' が有効化されました。"

2. データコネクタの有効化（例：Azure Activity Log）

Azure Activity Logは、Azureサブスクリプション内の管理操作に関するログを提供します。これをSentinelに取り込むことで、Azureリソースに対する変更や管理アクティビティを監視できます。

# 既存のLog AnalyticsワークスペースのIDを取得

$WorkspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName $ResourceGroupName -Name $WorkspaceName).ResourceId

# Azure Activity Log コネクタの有効化


# これはData Connectors APIを使用する例です。実際のコネクタ有効化はAzureポータルが簡単です。


# PowerShellで直接コネクタを有効化する一般的な方法は、Diagnostic Settingsを利用します。


# 例: Activity LogをLog Analyticsワークスペースに送信する診断設定の作成

Set-AzDiagnosticSetting `
    -Name "SendActivityLogsToSentinel" `
    -ResourceId "/subscriptions/$(Get-AzContext).Subscription.Id" `
    -ServiceBusRuleId $null `
    -EventHubAuthorizationRuleId $null `
    -MarketplacePartnerId $null `
    -Categories @("Administrative", "Security", "ServiceHealth", "Alert", "Recommendation", "Autoscale", "ResourceHealth") `
    -Enabled $true `
    -WorkspaceId $WorkspaceId `
    -StorageAccountId $null
Write-Host "Azure Activity LogがLog Analyticsワークスペース '$WorkspaceName' に送信されるように設定されました。"

多くのデータコネクタは、Sentinelポータル上でのシンプルなUI操作、またはAzure Monitorの診断設定を通じて設定されます。

運用監視

Microsoft Sentinelの運用監視は、KQLを核とした多角的なアプローチで実現されます。

KQLによるログ分析の基礎

KQLは、Sentinelに収集されたログを効率的にクエリするための強力な言語です。基本的なクエリは、テーブル名にパイプ | を繋げて演算子を適用する形式を取ります。 （2024年5月10日 JST確認）

# 過去1時間のアクティビティログから特定の操作を検索

AzureActivity
| where TimeGenerated > ago(1h)
| where OperationNameValue startswith "MICROSOFT.COMPUTE/VIRTUALMACHINES/DELETE"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, ActivityStatus
| order by TimeGenerated desc

上記のKQLは、過去1時間以内に実行された仮想マシンの削除操作を抽出し、呼び出し元、操作名、リソースグループ、ステータスなどの情報を表示します。

分析ルール、プレイブック、ワークブックの活用

  • 分析ルール: 定期的にKQLクエリを実行し、定義されたしきい値や条件に合致した場合にアラートを発行し、インシデントを生成します。例えば、短時間での複数回の認証失敗や、異常な地域からのログイン試行などを検出できます。

  • プレイブック: インシデント発生時の初動対応を自動化します。例えば、特定のIPアドレスからの攻撃が検出された場合に、そのIPをファイアウォールでブロックしたり、Microsoft Teamsに通知を送信したりするワークフローを設定できます。

  • ワークブック: セキュリティメトリック、インシデントの傾向、データソースの状態などを視覚的に表示するカスタムダッシュボードです。KQLクエリの結果をグラフやテーブルで表示し、状況把握とレポート作成に役立ちます。

セキュリティ

Microsoft Sentinelは、Azureの堅牢なセキュリティ基盤上に構築されており、アイデンティティと権限管理、脅威保護機能が強化されています。

アイデンティティと権限境界

  • Microsoft Entra ID: SentinelへのアクセスはMicrosoft Entra ID（旧Azure AD）によって認証されます。多要素認証（MFA）や条件付きアクセスポリシーを適用することで、強固なアクセス制御を実現できます。

  • Azure ロールベースのアクセス制御 (Azure RBAC): Sentinelでは、Log AnalyticsワークスペースのRBACに加え、Sentinel固有のロールが提供されます。

    • Microsoft Sentinel 閲覧者: インシデント、データ、ワークブックなどを閲覧できます。

    • Microsoft Sentinel 応答者: インシデントの管理（割り当て、状態変更など）に加え、閲覧権限を持ちます。

    • Microsoft Sentinel 共同作成者: 分析ルール、プレイブック、ハンティングクエリなどの作成・編集権限に加え、応答者の権限を持ちます。

    • Microsoft Sentinel 管理者: Sentinelワークスペースに対する完全な管理権限を持ちます。 これらのロールを最小特権の原則に基づいて割り当てることで、セキュリティ運用の職務分離を徹底できます。

  • 条件付きアクセス: Microsoft Entra IDと連携し、ユーザーの場所、デバイスの状態、アプリケーションの種類などに基づいてアクセスを制限できます。例えば、特定のIPアドレス範囲からのアクセスのみを許可したり、準拠デバイスからのアクセスを必須にしたりできます。

Microsoft Defender for Cloud との連携

Microsoft Defender for Cloudは、Azure環境のセキュリティ体制管理と脅威保護を提供するサービスです。Sentinelと連携することで、Defender for Cloudが生成するセキュリティアラートや推奨事項をSentinelに取り込み、より広範なセキュリティ監視と対応が可能になります。例えば、Defender for Cloudによって検出されたSQLインジェクション攻撃のアラートをSentinelのインシデントとして管理し、プレイブックによる自動対応をトリガーできます。

コスト最適化

Microsoft Sentinelのコストは、主にデータ取り込み量とデータ保持期間によって決定されます。効果的なコスト最適化のためには、以下の戦略を組み合わせることが重要です。

  1. データ取り込み量の最適化:

    • 必要なログのみを取り込む: すべてのログを取り込むのではなく、セキュリティ分析に不可欠なログソースとイベントのみを選択します。例えば、詳細すぎるデバッグログは除外するなどの検討が必要です。

    • データフィルタリング: データコネクタによっては、取り込み前にイベントをフィルタリングできる場合があります。これにより、Log Analyticsワークスペースに送られるデータ量を削減できます。

    • Microsoft 365 E5ライセンス: 特定のMicrosoft 365 E5ライセンスを所有している場合、一部のMicrosoft 365データコネクタ（例: Azure AD Audit Logs, Microsoft Purview DLP）からのデータ取り込みが無料枠の対象となる場合があります（2024年5月10日 JST現在、詳細はMicrosoftの料金ページを参照[2]）。

  2. データ保持期間の管理:

    • 階層型ストレージの活用: Sentinelは、インタラクティブクエリ用のホットデータと、長期保存用のアーカイブデータを管理できます。頻繁にアクセスしない古いデータは、コストの低いアーカイブ層に移動させることで、データ保持コストを大幅に削減できます。アーカイブ期間は最大7年まで設定可能です。

    • Log Analyticsワークスペースの基本ログ: 高頻度で大量に発生するが、分析の重要性が低いログには「基本ログ」ティアを適用することで、取り込みコストを削減できます。ただし、基本ログのクエリはインタラクティブログよりも高額になる場合があります。

  3. リザーブドキャパシティ (Reserved Capacity):

    • 毎日のデータ取り込み量が予測可能な場合、リザーブドキャパシティを事前にコミットすることで、従量課金よりも大幅な割引が適用されます。100GB/日以上のデータ取り込みが見込まれる場合に特に有効です。

これらの組み合わせにより、Sentinelの運用コストを最適化しつつ、必要なセキュリティレベルを維持することが可能です。

落とし穴と対策

Microsoft Sentinelの導入と運用には、いくつかの注意すべき落とし穴が存在します。

  1. KQLのパフォーマンス: 大量のデータに対する複雑なKQLクエリは、実行に時間がかかり、コストも増加する可能性があります。

    • 対策: where句で早めにデータを絞り込む、project句で必要な列のみを選択する、summarize句で集計を行う前にフィルタリングする、などKQLのベストプラクティスに従う。頻繁に使うクエリは保存済みクエリとして最適化する。

  2. コストスパイク: 想定外のデータ取り込み量増加により、Sentinelの費用が急騰することがあります。

    • 対策: 定期的にLog Analyticsのデータ取り込み量を監視し、異常なスパイクを検出するアラートを設定する。不要なデータソースの取り込みを停止またはフィルタリングする。リザーブドキャパシティ導入時は、慎重に日々の取り込み量を予測する。

  3. False Positive/Negativeのチューニング: 分析ルールが多すぎるとFalse Positive（誤検知）が増加し、アラート疲れを引き起こします。逆に、ルールが不十分だとFalse Negative（見逃し）のリスクが高まります。

    • 対策: 導入初期は、既存のインフラや脅威プロファイルに合わせた分析ルールから導入し、徐々にチューニングを行う。定期的なルールレビューとKQLクエリの改善を実施する。脅威インテリジェンスフィードを活用し、既知の脅威に対するルールを強化する。

  4. 不適切なRBAC設計: 最小特権の原則に反する広範な権限付与は、セキュリティリスクを高めます。

    • 対策: Sentinel固有のロールとAzure RBACを組み合わせ、各ユーザー/グループに必要最小限の権限のみを付与する。定期的に権限レビューを実施し、不要な権限がないか確認する。

まとめ

Microsoft Sentinelは、KQLを核とした強力なクラウドネイティブSIEM/SOARソリューションであり、現代の複雑なセキュリティ脅威に対抗するための効果的なツールです。アーキテクチャの理解、適切な設定と運用、Azure RBACとMicrosoft Entra IDによる厳格なセキュリティ管理、そして賢明なコスト最適化戦略を組み合わせることで、組織のセキュリティ体制を大幅に強化できます。KQLの習熟は、Sentinelを最大限に活用し、セキュリティ運用を効率化するための鍵となります。導入時には、初期のチューニングや継続的な運用改善計画を立てることが成功の鍵となるでしょう。

参考文献 [1] Microsoft Learn: Microsoft Sentinel の概要 (Microsoft, 確認日: 2024年5月10日 JST) https://learn.microsoft.com/ja-jp/azure/sentinel/overview [2] Microsoft Azure: Microsoft Sentinel の料金 (Microsoft, 確認日: 2024年5月10日 JST) https://azure.microsoft.com/ja-jp/pricing/details/microsoft-sentinel/ [3] Microsoft Learn: Microsoft Sentinel のデータ コネクタ (Microsoft, 確認日: 2024年5月10日 JST) https://learn.microsoft.com/ja-jp/azure/sentinel/connect-data-sources [4] Microsoft Learn: Azure のロールベースのアクセス制御 (Azure RBAC) と Microsoft Sentinel (Microsoft, 確認日: 2024年5月10日 JST) https://learn.microsoft.com/ja-jp/azure/sentinel/roles [5] Microsoft Learn: Azure Monitor の診断設定を作成または編集する (Microsoft, 確認日: 2024年5月10日 JST) https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/create-diagnostic-settings?tabs=azure-portal [6] Microsoft Learn: KQL クエリ言語の概要 (Microsoft, 確認日: 2024年5月10日 JST) https://learn.microsoft.com/ja-jp/azure/data-explorer/kusto/query/tutorials/learn-kql

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました