Cloud Service
Microsoft Sentinel
クラウドネイティブな SIEM 兼 SOAR。多様なログを集約・相関して脅威を検知し、プレイブックで対応を自動化する。AWS の Security Lake と GuardDuty を組み合わせた相当。
- 1.ログを一元集約し相関分析して脅威を検知するクラウド SIEM。
- 2.プレイブックで調査と封じ込めを自動化する SOAR も内蔵。
- 3.サーバー管理不要でスケールし、取り込み量に応じた従量課金。
解決する課題
- 各クラウド・オンプレ・SaaS に散在するログを一元的に集約し、横断で脅威を見たい
- 単独では無害に見えるイベントを相関分析して、本当の攻撃の連鎖を浮かび上がらせたい
- 大量のアラートに埋もれず、ノイズを抑えて重大インシデントに集中したい
- 検知から調査・封じ込めまでの初動対応を自動化し、対応時間(MTTR)を短縮したい
- SIEM 基盤のサーバー構築・スケール・パッチ管理から解放されたい
主要概念と用語
Microsoft Sentinel は Log Analytics ワークスペースの上に構築される SIEM/SOAR ソリューションです。
- SIEM(Security Information and Event Management): ログを集約・相関し、脅威を検知・可視化する仕組み
- SOAR(Security Orchestration, Automation and Response): 検知後の対応を自動化・オーケストレーションする仕組み。Sentinel ではプレイブックが担う
- ワークスペース(Log Analytics): ログの保管・クエリ基盤。Sentinel はこの上で動作し、課金や保持もここに紐づく
- データコネクタ: Microsoft 365 / Entra ID / Defender / 各種クラウド・ファイアウォール・SaaS などからログを取り込む接続定義
- 分析ルール(Analytics Rules): 取り込んだログから脅威を検知するルール。スケジュール型のクエリ検知や、近実時間(NRT)検知、異常検知などがある
- KQL(Kusto Query Language): 検索・分析・検知ルールを記述する問い合わせ言語
- インシデント: 関連するアラートをまとめた調査の単位。重大度や状態(新規・進行中・解決済み)を持つ
- エンティティ: ユーザー・ホスト・IP・ファイルなど、アラート内の実体。エンティティ単位で挙動を追跡する
- UEBA(User and Entity Behavior Analytics): 利用者や資産の通常の振る舞いを学習し、逸脱を異常として検出する
- ハンティング(Hunting): 既知のルールに頼らず、KQL で能動的に脅威を探索する作業
- ウォッチリスト: 既知の悪性 IP や VIP ユーザーなど、相関に使う参照データの一覧
- プレイブック(Playbook): Azure Logic Apps で実装する自動対応ワークフロー。隔離・通知・チケット起票などを行う
- オートメーションルール: インシデントに対してプレイブック実行やタグ付け、担当割当を自動でトリガーする統制層
仕様・制限・クォータ
- 基盤は Log Analytics ワークスペースであり、保持期間・取り込み制御・アーカイブはワークスペース側の設定に従う
- 取り込みデータのインタラクティブ保持には上限日数があり、それを超える長期保管は**アーカイブ(低コスト層)**に分ける構成が一般的
- 多数のデータコネクタを標準提供し、未対応のソースはカスタムログ取り込みや Syslog / Common Event Format(CEF)、エージェント経由で取り込める
- 分析ルールの実行頻度や検索範囲、クエリ結果の上限などにサービス側の制限があり、ルール設計時に考慮する
- プレイブックは Logic Apps の制約(実行時間・スロットリング・コネクタ可用性)を継承する
- 大規模環境では複数ワークスペースやリージョンにまたがるため、横断クエリやワークスペース管理の設計が必要になる
Sentinel のコストも分析品質も何をどれだけ取り込むかで決まります。価値の高いログ(認証・管理操作・セキュリティ製品のアラート)を優先し、ノイズの多い冗長ログはフィルタや変換で間引く前提で設計してください。
内部の仕組み
Microsoft Sentinel は、データ取り込み → 検知 → インシデント化 → 自動対応という流れで動作します。
- 取り込み: データコネクタが各ソースのログを Log Analytics ワークスペースへ集約する。取り込み時に**変換(DCR ベースの正規化・フィルタ)**を適用できる
- 検知: 分析ルールが KQL クエリを定期実行(または近実時間で評価)し、条件に合致したイベントをアラートとして生成する。UEBA や機械学習ベースの異常検知も併用される
- 相関・インシデント化: 関連するアラートを1つのインシデントに束ね、エンティティ(ユーザー・ホスト・IP)をマッピングして調査しやすくする
- 自動対応: オートメーションルールがインシデントを評価し、条件に合えば**プレイブック(Logic Apps)**を起動して、アカウント無効化・ホスト隔離・通知・チケット起票などを実行する
検知ロジックの中核は KQL であり、調査・ハンティング・ダッシュボード(ブック)も同じ言語で記述できる点が、学習コストと運用効率の両面で効いてきます。
Sentinel は単独でも使えますが、Microsoft Defender XDR と統合するとエンドポイント・ID・メールなどの検知を取り込み、相関の質が上がります。両者を統合ポータルで一体運用する構成が近年の推奨です。
設計パターン / ベストプラクティス
- ワークスペース設計を最初に固める: 単一ワークスペース集約か、テナント・リージョン・部門ごとの分割かを、データ主権とアクセス制御の観点で決める
- 取り込みを取捨選択する: 価値の高いログを優先し、変換ルールでノイズを削減してコストとシグナル品質を両立する
- 検知は段階的に育てる: 標準のルールテンプレートから始め、誤検知を見ながら閾値やフィルタを調整して自組織向けに最適化する
- 対応を自動化する: 反復的な初動(通知・エンリッチ・隔離)をプレイブック化し、人手は判断が要る部分に集中させる
- コンテンツはコードで管理: 分析ルールやプレイブックを**リポジトリ管理(Infrastructure as Code)**し、環境間で再現可能にする
- MITRE ATT&CK でカバレッジを可視化し、検知の穴を体系的に埋める
運用・監視
- インシデントキューを SOC の起点にし、重大度・状態・担当でトリアージする
- ヘルス監視: コネクタの取り込み停止やルールの実行失敗を、ヘルス機能やアラートで検知する
- 取り込み量とコストを定期レビューし、想定外に増えたログ源を早期に特定する
- ハンティングを定例化し、ルール化されていない脅威を能動的に探索する
- チューニングのループを回す: 誤検知率の高いルールを継続的に調整し、アラート疲れを防ぐ
コスト
課金は主に取り込んだデータ量と保持に連動します。取り込みは従量課金に加え、一定量を予約する**コミットメントティア(割引)**を選べます。
| 課金要素 | 考え方 | コスト最適化のヒント |
|---|---|---|
| データ取り込み | 取り込んだログ量に応じた従量課金 | 価値の低いログを変換で間引く |
| コミットメントティア | 一定量を予約して単価を下げる定額 | 安定して大量取り込みする環境で有効 |
| 保持(インタラクティブ) | 一定期間まで含み、超過分は日数課金 | 長期保管はアーカイブ層へ分離 |
| アーカイブ / 検索 | 低コストの長期保管と再検索の都度課金 | 監査用途の古いログを安価に保持 |
| プレイブック実行 | Logic Apps の実行・コネクタ課金 | 高頻度の自動化はトリガー条件を絞る |
無秩序に全ログを取り込むと、取り込み課金が急増します。必要なログを選び、フィルタ・変換でノイズを落とすことが、Sentinel の費用対効果を決める最大の要因です。
セキュリティ
- アクセスは RBAC で最小化し、閲覧専用・対応担当・管理者などロールを分離する
- マネージド ID をプレイブックに付与し、自動対応に使う資格情報のハードコードを排除する
- 取り込んだログ自体を保護: ワークスペースのアクセス制御・暗号化・ネットワーク制限を適用する
- 監査ログを有効化し、Sentinel の設定変更やルール変更の追跡可能性を確保する
- データ主権: ログの保管リージョンとテナント分離を、規制要件に合わせて設計する
Well-Architected の観点
- セキュリティ(Security): 横断的な脅威検知・相関・自動対応により、検知から封じ込めまでの初動を体系化する。これが本サービスの主目的
- オペレーショナルエクセレンス(Operational Excellence): マネージド基盤でサーバー運用を不要にし、ルールやプレイブックを IaC 化することで、SOC の運用を反復可能で測定可能なプロセスにする
- 一方で取り込み設計を誤るとコスト最適化(Cost Optimization)を損なうため、取得対象の取捨選択がトレードオフの要となる
試験で問われるポイント
- 「クラウドネイティブな SIEM/SOAR が欲しい」→ Microsoft Sentinel
- ログの集約・相関・検知は SIEM、検知後の**自動対応(プレイブック)**は SOAR、と役割を区別する
- Sentinel は Log Analytics ワークスペースの上で動き、検知ルールは KQL で書く、という土台を押さえる
- 自動対応のプレイブックは Azure Logic Apps で実装される
- エンドポイントやアラートの単体検知は Microsoft Defender 系、それらを横断集約・相関するのが Sentinel、という棲み分け
- コストの主因は取り込みデータ量で、最適化は取り込み対象の選別と変換がカギ
関連サービス・比較
Microsoft Sentinel は、AWS では複数サービスにまたがる役割を1つに束ねています。脅威検知の AWS GuardDuty とログ集約レイクの Security Lake、可視化の OpenSearch などを組み合わせた領域に相当します。
| 観点 | Azure | AWS |
|---|---|---|
| クラウド SIEM / 相関 | Microsoft Sentinel | Security Lake と OpenSearch の組み合わせ |
| 脅威検知(マネージド) | Microsoft Defender 系の検知を集約 | GuardDuty |
| ログ集約レイク | Log Analytics ワークスペース | Security Lake(OCSF 正規化) |
| 自動対応(SOAR) | プレイブック(Logic Apps) | EventBridge と Lambda などの自前構成 |
| セキュリティ態勢管理 | Microsoft Defender for Cloud | Security Hub |
| クエリ言語 | KQL | OpenSearch のクエリ / SQL 等 |
AWS では GuardDuty(検知)/ Security Lake(集約)/ Security Hub(態勢)/ OpenSearch(分析) に分かれる機能を、Azure では Sentinel と Defender for Cloud を中心に統合的に提供します。Sentinel は特に集約・相関・自動対応を一手に担う点が特徴です。
ハンズオン / CLI例
# 1. Log Analytics ワークスペースを作成(Sentinel の土台)
az group create --name sec-rg --location japaneast
az monitor log-analytics workspace create \
--resource-group sec-rg \
--workspace-name soc-law \
--location japaneast
# 2. そのワークスペース上に Microsoft Sentinel を有効化
# (sentinel 拡張機能を利用。未導入なら az extension add --name sentinel)
az sentinel onboarding-state create \
--resource-group sec-rg \
--workspace-name soc-law \
--name default
# 3. データコネクタや分析ルールの一覧を確認
az sentinel data-connector list \
--resource-group sec-rg \
--workspace-name soc-law -o table
az sentinel alert-rule list \
--resource-group sec-rg \
--workspace-name soc-law -o table
Azure Service
Microsoft Sentinelを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
セキュリティ・ID
比較で見る軸
クラウド: Azure / カテゴリ: セキュリティ・ID / 難易度: intermediate
導入後に効く点
プレイブックで調査と封じ込めを自動化する SOAR も内蔵。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Azure
- カテゴリ
- セキュリティ・ID
- 難易度
- intermediate
- 関連資格
- —
- 設計柱
- security / operational
判断チェックリスト
- 自社の用途が「セキュリティ・ID / security」に近いか確認する。
- 強みである「ログを一元集約し相関分析して脅威を検知するクラウド SIEM。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。