この記事では、Azure DevOps による Microsoft Sentinel の統合とデプロイの操作を自動化する方法について説明します。 デプロイをセキュリティで保護するために、Microsoft Sentinel の機能を使用して Azure DevOps を実装します。 次に、DevSecOps フレームワークを使用して、Microsoft Sentinel の成果物を大規模に管理およびデプロイします。
アーキテクチャ
次の図は、Azure DevOps と Microsoft Sentinel の IaC 設定を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
- スクラム マスターおよび製品管理の担当者は Azure DevOps を使用して、エピック、ユーザー ストーリー、およびプロジェクトバックログの一部として製品バックログ項目を定義します。
- スクラム マスターおよび製品管理の担当者は Azure Boards を使用して、バックログの作成、スプリントでの作業のスケジュール作成、プロジェクト ボードのレビュー、リポジトリ構造の作成、承認ワークフローやブランチなどのセキュリティ規則の設定を行います。
- Azure Git リポジトリには、コードとしてのインフラストラクチャで Microsoft Sentinel の成果物を管理するためのスクリプトと許可が格納されます。
- 成果物とソース管理では、ソリューションで使用される DevSecOps ワークフローの拡張機能と更新パッケージまたはコンポーネント (Azure Resource Manager テンプレート ツールキットや PowerShell Pester など) が維持されます。
- Microsoft Sentinel の成果物:
- ポリシー SIEM エンジニアは、参照アーキテクチャで Azure ポリシーを使用して、Azure サービスの診断設定を構成およびスケーリングします。 ポリシーは、Azure Key Vault などの Microsoft Sentinel データ コネクタのデプロイを自動化するのに役立ちます。 ポリシーは OMSIntegration API に依存します。
- コネクタ。 Microsoft Sentinel は論理コネクタ (Azure Data Connectors) を使って、Microsoft Entra ID、Azure リソース、Microsoft Defender、サードパーティのソリューションなどのサポートされるデータ ソースから、監査やメトリックなどのセキュリティ データを取り込みます。 データ コネクタのメイン リストは SecurityInsights API によって管理されます。 他のものは OMSIntegration API に依存しており、Azure Policy の診断設定で管理されます。
- マネージド ID。 Microsoft Sentinel はマネージド ID を使用して、マネージド サービス ID (MSI) の代理として機能する一方、プレイブック、ロジック アプリ、Automation Runbook、キー コンテナーと対話します。
- オートメーション。 SOC チームは調査中にオートメーションを使用します。 SOC チームは、Azure 仮想マシン (VM) の証拠保全や Microsoft Defender の eDiscovery (Premium) など、Azure Automation を使用してデジタル フォレンジック データ取得手順を実行します。
- 分析 SOC アナリストまたは脅威ハンターは、組み込みまたはカスタムの分析ルールを使用して、Microsoft Sentinel 内のデータを分析および関連付けしたり、脅威とインシデントが特定された場合にプレイブックをトリガーしたりします。
- プレイブック。 ロジック アプリでは、インシデントの割り当て、インシデントの更新、修復操作の実行 (VM の分離または包含、トークンの取り消し、ユーザー パスワードのリセットなど) など、SecOps の反復可能なアクションが実行されます。
- 脅威のハンティング。 脅威ハンターでは、データ処理、データ操作、データの視覚化、機械学習、ディープ ラーニングなどの高度なユースケースに対して Jupyter ノートブックと組み合わせて使用できる、事前対応型の脅威ハンティング機能を使用します。
- ブック。 SIEM のエンジニアは Workbooks ダッシュボードを使用して、傾向と統計を視覚化し、Microsoft Sentinel インスタンスとそのサブコンポーネントの状態を表示します。
- 脅威インテリジェンス。 脅威インテリジェンス プラットフォーム フィードを Microsoft Sentinel に融合する特定のデータ コネクタ。 TAXII と Graph API という 2 つの接続方法がサポートされています。 セキュリティ API では、どちらの方法も tiIndicators、つまり脅威インテリジェンス インジケーターとして機能します。
- Microsoft Entra ID。 ID およびアクセス管理機能は、参照アーキテクチャで使用されるコンポーネント (マネージド ID、サービス プリンシパル、Microsoft Sentinel 用の Azure ロールベースのアクセス制御 (RBAC)、ロジック アプリ、Automation Runbook など) に提供されます。
- Azure Pipelines DevOps のエンジニアはパイプラインを使用して、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを備えたサンドボックス環境や運用環境などのさまざまな Azure サブスクリプションを管理するためのサービス接続を作成します。 Azure 環境ごとに複数のサブスクリプションを対象とする場合は、承認ワークフローを使用して、予期しないデプロイを防止しサービス プリンシパルを分離することをお勧めします。
- Azure Key Vault。 SOC エンジニアはキー コンテナーを使用して、サービス プリンシパルのシークレットと証明書を安全に格納します。 アーキテクチャのこのコンポーネントは、Azure パイプライン サービス接続で使用されている場合に、"コードにシークレットを含めない" という DevSecOps の原則を適用するのに役立ちます。
- Azure のサブスクリプション。 SOC チームは、この参照アーキテクチャで Microsoft Sentinel の 2 つのインスタンスを使用します。これらは運用とサンドボックスの環境をシミュレートするために 2 つの論理的な Azure サブスクリプション内に分離されています。 テスト、開発、運用前など、その他の環境でニーズに合わせて拡張できます。
データフローの例
- 管理者は Microsoft 365 構成ファイルのフォーク内のエントリを追加、更新、または削除します。
- 管理者はフォークされたリポジトリへの変更をコミットして同期します。
- 次に管理者は pull request (PR) を作成して、変更をメイン リポジトリにマージします。
- ビルド パイプラインが PR に対して実行されます。
コンポーネント
- Microsoft Entra ID は、ID およびアクセスの制御を管理するためのマルチテナントに対応したクラウドベース サービスです。
- Azure DevOps は、コードでの共同作業、アプリのビルドとデプロイ、作業の計画と追跡を行うクラウド サービスです。
- Azure Key Vault は、シークレットを安全に保管し、それにアクセスするためのクラウド サービスです。 シークレットは、API キー、パスワード、証明書、暗号化キーなど、アクセスを厳密に制御する必要がある任意のものです。
- Azure Policy は、Azure 環境でポリシー定義の作成、割り当て、管理を行うサービスです。
- Microsoft Sentinel は、スケーラブルでクラウドネイティブの SIEM およびセキュリティ オーケストレーション自動応答 (SOAR) ソリューションです。
- Azure Automation は、プロセスの自動化によってクラウド管理を簡略化するためのサービスです。 Azure Automation を使用して、時間がかかり、手動で、エラーを招きやすく、頻繁に繰り返されるタスクを自動化します。 Automation を使用すると、会社の信頼性、効率、価値を生み出すまでの時間を改善できます。
シナリオの詳細
セキュリティ オペレーション センター (SOC) のチームは、Azure DevOps を使用して Microsoft Sentinel を統合するときに問題に直面することがあります。 プロセスには多くの手順が必要で、セットアップには数日かかり、繰り返しが必要になる場合があります。 開発のこの部分を自動化できます。
クラウドを最新化するために、エンジニアは、重要なビジネス資産を保護して防護するための新しいスキルとテクニックを常に学習する必要があります。 エンジニアは、変化するセキュリティ環境とビジネス ニーズに対応できる堅牢でスケーラブルなソリューションを構築する必要があります。 セキュリティ ソリューションは、柔軟性と俊敏性を備え、開発の初期段階から慎重に計画されたものである必要があります。 この初期計画手法は "シフトレフト" と呼ばれます。
この記事では、Azure DevOps による Microsoft Sentinel の統合とデプロイの操作を自動化する方法について説明します。 ソリューションを拡張して、複数のエンティティ、サブスクリプション、さまざまな運用モデルを持つ複雑な組織に対応することができます。 このソリューションでサポートされている一部の運用モデルとして、ローカル SOC、グローバル SOC、クラウド サービス プロバイダー (CSP)、マネージド セキュリティ サービス プロバイダー (MSSP) があります。
この記事の対象読者は次のとおりです。
- SOC スペシャリスト (アナリストや脅威ハンターなど)
- セキュリティ情報イベント管理 (SIEM) エンジニア
- サイバーセキュリティ アーキテクト
- 開発者
考えられるユース ケース
このアーキテクチャの一般的なユース ケースは次のとおりです。
- 迅速なプロトタイプ作成と概念実証。 このソリューションは、コードとしてのインフラストラクチャ (IaC) と Microsoft Sentinel を使用して、クラウドの脅威からの保護を改善したり SIEM インフラストラクチャを最新化したりする必要があるセキュリティ組織および SOC チームに最適です。
- サービスとしての Microsoft Sentinel。 この開発フレームワークでは、サービス ライフサイクル管理の原則が統合されます。 これらの原則は、Azure DevOps と Azure Lighthouse の能力を組み合わせる一方で、複数の顧客テナントに対して反復可能な標準化されたアクションを実行する、MSSP のようなシンプルまたは複雑なチームに適しています。 たとえば、新しい脅威アクターまたは進行中のキャンペーンに対して Microsoft Sentinel のユースケースを公開する必要があるチームは、このソリューションを使用できます。
- 脅威検出のための SOC ユース ケースの構築。 多くのグループと脅威インテリジェンス プラットフォームは、高度なスパイ技術や手法、方針の手順に対するセキュリティ体制を分析するために、MITRE ATT&CK のコンテンツと分類に依存しています。 このソリューションでは、Microsoft Sentinel の成果物開発に MITRE ATT&CK の用語集を組み込むことによって、脅威検出のエンジニアリング手法を開発するための構造化されたアプローチを定義します。
次の図は、MITRE ATT&CK のクラウド シナリオを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
MITRE に基づく脅威定義の攻撃シナリオ
次の表は、攻撃シナリオの重要な側面の用語、定義、および詳細を示しています。
| データ アイテム | 説明 | Microsoft Sentinel の成果物: |
|---|---|---|
| タイトル | 攻撃ベクトルの特性または手法の説明に基づく、攻撃シナリオのわかりやすい名前。 | MITRE マニフェスト |
| MITRE ATT&CK の方針 | 攻撃シナリオに関連する MITRE ATT&CK の方針 | MITRE マニフェスト |
| MITRE ATT&CK 技法 | 攻撃シナリオに関連する手法またはサブ手法 ID を含む MITRE ATT&CK の手法。 | MITRE マニフェスト |
| データ コネクタのソース | 実行されるアクションの識別に関連する情報、一連のアクション、または敵対者によるそれらのアクションの結果を収集するために使用されることのある、センサーまたはログ記録システムによって収集される情報のソース。 | Microsoft Sentinel データ コネクタまたはカスタム ログ ソース |
| 説明 | 手法とその内容、一般的な用途、敵対者による利用方法、その使用方法のバリエーションに関する情報。 手法に関する技術情報のほか、使用に関する幅広いリファレンスが記述されている、信頼できる記事への参照が含まれています。 | |
| 検出 | 高レベルの分析プロセス、センサー、データ、および検出の戦略は、敵対者が使用している手法を特定するのに役立ちます。 このセクションでは、敵対者の行動を検出するネットワーク防御者などの責任者に通知することにより、責任者は分析の記述やセンサーのデプロイなどのアクションを実行できます。 有益な防御方法を示すための十分な情報と参照が必要です。 特定の手法では検出が常に可能であるとは限らず、そのように記述する必要があります。 | 分析脅威ハンティング |
| 対応策 | 手法が動作することを妨げたり、敵対者にとって望ましい結果がもたらされることを妨げる構成、ツール、またはプロセス。 このセクションでは、ネットワーク防御者やポリシーメーカーなどの、敵対者に対応する担当者に通知し、ポリシーの変更やツールのデプロイなどのアクションを実行できるようにします。 特定の手法では軽減策が常に可能であるとは限らず、そのように記述する必要があります。 | |
| 対応策 | 手法が動作することを妨げたり、敵対者にとって望ましい結果がもたらされることを妨げる構成、ツール、またはプロセス。 このセクションでは、ネットワーク防御者またはポリシーメーカーのために、敵対者の影響を軽減する方法について説明します。 ポリシーを変更したり、ツールをデプロイしたりする手順について説明します。 特定の手法では軽減策が常に可能であるとは限らず、そのように記述する必要があります。 | プレイブック、Automation Runbook |
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
セキュリティを使用すると、一般的に、自動化によって運用効率が向上し、脅威検出エンジニアリング、脅威インテリジェンス、SOC、SOAR ユースケースなどのより複雑なユースケースについての時間が節約されます。 DevOps チームは、Microsoft Sentinel CI/CD のコンテキストで IaC を安全に使用できる場合を把握する必要があります。 このプロセスでは、サービス プリンシパルとマネージド ID という、Microsoft Entra ID 内で人間以外のアカウントに使われる特定の ID の使用が導入されます。
次の表は、サービス プリンシパルのセキュリティに関する考慮事項と、Microsoft Sentinel および Azure DevOps リリース パイプラインによってカバーされる主なユース ケースをまとめたものです。
| 使用事例 | 要件 (最小の特権) | ロール割り当て期間 | アクセス許可のスコープ | トラスティ | セキュリティに関する考慮事項 |
|---|---|---|---|---|---|
| Microsoft Sentinel コネクタを有効にする | セキュリティ管理者** 所有者* Microsoft Sentinel 共同作成者 閲覧者 |
JIT (ワンタイム アクティベーション) 意図的 (新しいサブスクリプションとコネクタがデプロイされるたび) |
Tenant | SPN | キー コンテナーを使用して、サービス プリンシパル名 (SPN) のシークレットと証明書を格納します。 SPN 監査を有効にします。 定期的に、アクセス許可の割り当て (SPN 用の Azure Privileged Identity Management) または SPN の不審なアクティビティを確認します。 特権アカウントには、Microsoft Entra 証明機関と多要素認証 (サポートされている場合) を使います。 細分性を高めるには、Microsoft Entra カスタム ロールを使います。 |
| Microsoft Sentinel 成果物をデプロイする (ブック、分析、ルール、脅威ハンティング クエリ、ノー トブック、プレイブックなど) | Microsoft Sentinel 共同作成者 Logic Apps の共同作成者 |
永続的 | Microsoft Sentinel のワークスペースまたはリソース グループ | SPN | Azure DevOps (ADO) ワークフロー承認を使用して、この SPN を使用したパイプラインのデプロイをセキュリティで保護することを確認します。 |
| Microsoft Sentinel にログ ストリーミング機能を構成するためのポリシーを割り当てる | リソース ポリシーの共同作成者 ** | 意図的 (新しいサブスクリプションとコネクタがデプロイされるたび) | 監視するすべてのサブスクリプション | SPN | 特権アカウントには、Microsoft Entra ID、CA、MFA (サポートされている場合) を使います。 |
* Microsoft Entra の診断設定にのみ関係します。
* * 特定のコネクタでは、"セキュリティ管理者" や "リソース ポリシーの共同作成者" などの追加のアクセス許可が必要です。これにより、Microsoft Sentinel ワークスペース、Microsoft Entra ID、Microsoft 365 または Microsoft Defender、および Azure Key Vault のようなサービスとしてのプラットフォーム (PaaS) リソースへのデータのストリーミングが可能になります。
特権アクセス モデル
マイクロソフトでは、特権アクセス モデル戦略を採用して、特権アクセスへの影響が大きく危険性の高い攻撃から会社のリスクを迅速に軽減することをお勧めします。 DevOps モデルの自動プロセスの場合、ID はサービス プリンシパル ID に基づくようにします。
特権アクセスを、すべての会社の最上位のセキュリティ優先順位にする必要があります。 これらの ID が侵害されると、非常に悪い影響が生じます。 特権 ID により、ビジネスに不可欠な資産にアクセスできますが、ほとんどの場合、攻撃者がこれらのアカウントを侵害したときに大きな影響が生じます。
特権アクセスのセキュリティは、他のすべてのセキュリティ保証の基礎となるため、非常に重要です。 特権アカウントを制御する攻撃者は、他のすべてのセキュリティ保証を脅かす可能性があります。
そのため、最小限の特権の原則に従うことで、サービス プリンシパルを異なるレベルまたは階層に論理的に分散させることをお勧めします。 次の図は、アクセスの種類とアクセスが必要な場合に応じて、サービス プリンシパルを分類する方法を示しています。
レベル 0 のサービス プリンシパル
レベル 0 のサービス プリンシパルには、最高レベルのアクセス許可が与えられます。 これらのサービス プリンシパルによって、テナント全体またはルート管理グループの管理タスクをグローバル管理者として実行する資格がユーザーに付与されます。
セキュリティ上の理由と管理のしやすさを考慮して、このレベルのサービス プリンシパルは 1 つだけにすることをお勧めします。 このサービス プリンシパルのアクセス許可は保持されるため、必要な最小限のアクセス許可のみを付与し、アカウントの監視とセキュリティ保護を維持することをお勧めします。
このアカウントのシークレットまたは証明書を Azure Key Vault に安全に保存します。 可能であれば、キー コンテナーを専用の管理サブスクリプションに配置することを強くお勧めします。
レベル 1 のサービス プリンシパル
レベル 1 のサービス プリンシパルは、ビジネス組織レベルの管理グループに範囲が限定された、昇格されたアクセス許可です。 これらのサービス プリンシパルによって、範囲内にある管理グループの下にサブスクリプションを作成する権限がユーザーに付与されます。
セキュリティ上の理由と管理のしやすさを考慮して、このレベルのサービス プリンシパルは 1 つだけにすることをお勧めします。 このサービス プリンシパルのアクセス許可は保持されるため、必要な最小限のアクセス許可のみを付与し、アカウントの監視とセキュリティ保護を維持することを強くお勧めします。
このアカウントのシークレットまたは証明書を Azure Key Vault に安全に保存します。 可能であれば、キー コンテナーを専用の管理サブスクリプションに配置することを強くお勧めします。
レベル 2 のサービス プリンシパル
レベル 2 のサービス プリンシパルは、サブスクリプション レベルに制限されています。 これらのサービス プリンシパルによって、サブスクリプション所有者としての役割を務める、サブスクリプションで管理タスクを実行する権限がユーザーに付与されます。
セキュリティ上の理由と管理のしやすさを考慮して、このレベルのサービス プリンシパルは 1 つだけにすることをお勧めします。 このサービス プリンシパルのアクセス許可は保持されるため、必要な最小限のアクセス許可のみを付与し、アカウントの監視とセキュリティ保護を維持することを強くお勧めします。
このアカウントのシークレットまたは証明書を Azure Key Vault に安全に保存します。 可能であれば、キー コンテナーを専用の管理リソース グループに配置することを強くお勧めします。
レベル 3 のサービス プリンシパル
レベル 3 のサービス プリンシパルは、ワークロード管理者に限定されます。 一般的なシナリオでは、すべてのワークロードが同じリソース グループ内に含まれます。 この構造により、サービス プリンシパルのアクセス許可が、このリソース グループのみに制限されます。
セキュリティ上の理由と管理のしやすさを考慮して、ワークロードあたりのサービス プリンシパルは 1 つだけにすることをお勧めします。 このサービス プリンシパルのアクセス許可は保持されるため、必要な最小限のアクセス許可のみを付与し、アカウントの監視とセキュリティ保護を維持することを強くお勧めします。
このアカウントのシークレットまたは証明書を Azure Key Vault に安全に保存します。 可能であれば、キー コンテナーを専用の管理リソース グループに配置することを強くお勧めします。
レベル 4 のサービス プリンシパル
レベル 4 のサービス プリンシパルには、最も限定されたアクセス許可が与えられます。 これらのサービス プリンシパルによって、1 つのリソースに限定された管理タスクを実行する資格がユーザーに付与されます。
可能であれば、マネージド ID を使用することをお勧めします。 非マネージド ID の場合は、レベル 3 のシークレットが格納されている Azure Key Vault にシークレットまたは証明書を格納します。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
Microsoft Sentinel ソリューションは 3 つのブロックで構成されており、これによって完全で正常な動作が保証されます。
1 番目のブロックは環境定義で、これによって必須のアーキテクチャ要素が構成されます。 このブロックの主な関心事は、デプロイされる運用環境と非運用環境の数を考慮し、すべての場合で設定が同種であるようにすることです。
2 番目のブロックは Microsoft Sentinel コネクタのデプロイで、ここではチームに必要なコネクタの種類と、それらを有効にするために必要なセキュリティ要件を検討します。
3 番目のブロックは Microsoft Sentinel 成果物ライフサイクル管理で、ここではコンポーネントのコーディング、デプロイ、使用または破棄が行われます。 たとえば、このブロックには分析ルール、プレイブック、ブック、脅威ハンティングなどが含まれます。
成果物の間の次の依存関係を検討してください。
- 分析ルールで定義されているオートメーション ルール
- 新しいデータ ソースまたはコネクタを必要とするブックまたは分析
- 既存のコンポーネントの更新の管理
- 成果物をバージョン管理する方法
- 更新されたか完全に新しい分析ルールを識別、テスト、デプロイする方法
インフラストラクチャを構築、テスト、デプロイする
Microsoft Sentinel ソリューションと DevOps を管理する際は、エンタープライズ アーキテクチャの接続とセキュリティの側面を考慮することが重要です。
Azure DevOps では、構築、テスト、デプロイのアクティビティに Microsoft ホステッド エージェントまたはセルフホステッド エージェントを使用できます。 会社の要件に応じて、Microsoft ホステッド、セルフホステッド、または両方のモデルの組み合わせを使用できます。
- Microsoft ホステッド エージェント。 このオプションは、組織全体の共有インフラストラクチャであるため、Azure DevOps エージェントと最も速く連携できる方法です。 Microsoft ホステッド エージェントをパイプラインで使用することの詳細については、「Microsoft ホステッド エージェント」を参照してください。 Microsoft ホステッド エージェントは、ハイブリッド ネットワーク環境で動作し、IP 範囲へのアクセスを許可できます。 これらのエージェントでアクセス権が付与される IP 範囲をダウンロードするには、「Azure IP 範囲とサービス タグ - パブリック クラウド」を参照してください。
- セルフホステッド エージェント。 このオプションを使用すると、専用のリソースが付与され、ビルドとデプロイの依存ソフトウェアをインストールした場合に詳細に制御できます。 セルフホステッド エージェントは、Azure 上の VM、スケール セット、コンテナーで動作できます。 セルフホステッド エージェントの詳細については、Azure Pipelines エージェントに関する記事を参照してください。
GitHub ランナー
GitHub では、構築、テスト、デプロイに関係するアクティビティについて、GitHub でホストされているランナーまたはセルフホステッド ランナーを使用できます。 会社のニーズに応じて、GitHub ホステッド、セルフホステッド、または両方のモデルの組み合わせを使用できます。
GitHub ホステッド ランナー
このオプションは、組織全体の共有インフラストラクチャであるため、GitHub ワークフローを操作するための最も速い方法です。 詳細については、「GitHub ホステッド ランナーについて」をご覧ください。 GitHub ホステッド エージェントは、特定のネットワーク要件に従って、ハイブリッド ネットワーク環境で動作します。 ネットワーク要件の詳細については、サポートされるランナーとハードウェア リソースに関する記事を参照してください。
セルフホステッド ランナー
このオプションにより、専用のリソース インフラストラクチャが会社に提供されます。 セルフホステッド ランナーは、Azure の VM とコンテナーで動作し、自動スケーリングに対応します。
ランナーの選択に関する考慮事項
Microsoft Sentinel ソリューションでエージェントとランナーのオプションを選択する場合は、次のニーズを考慮してください。
- 会社では、Microsoft Sentinel 環境でプロセスを実行するための専用のリソースが必要ですか?
- 運用環境の DevOps アクティビティ用のリソースを、その他の環境から分離する必要がありますか?
- 重要なリソースまたは内部ネットワークでのみ使用できるリソースへのアクセスを必要とする特定のケースをテストする必要がありますか?
リリース プロセスのオーケストレーションと自動化
デプロイ プロセスは Azure DevOps または GitHub を使用して設定できます。 Azure DevOps では YAML パイプラインまたはリリース パイプラインの使用がサポートされています。 Azure DevOps での YAML パイプラインの使用の詳細については、「Azure Pipelines を使用する」を参照してください。 Azure DevOps でのリリース パイプラインの使用の詳細については、「リリース パイプライン」を参照してください。 GitHub での GitHub Actions の使用の詳細については、「GitHub Actions の概要」を参照してください。
Azure DevOps
Azure DevOps デプロイで、次のデプロイ アクティビティを実行できます。
- YAML パイプラインを使用して、PR 承認を自動的にトリガーしたり、オンデマンドで実行したりします。
- Azure DevOps グループを使用して、さまざまな環境のサービス接続を管理します。
- 重要な環境で、サービス接続機能と Azure DevOps グループを使用して、チーム内で特定のユーザー アクセス許可を割り当てることで、デプロイの承認を設定します。
GitHub
GitHub デプロイで、次のデプロイ アクティビティを実行できます。
- GitHub を使用して、PR またはデプロイ アクティビティを作成する。
- GitHub シークレットを使用して、サービス プリンシパルの資格情報を管理する。
- GitHub に関連付けられているワークフローを使用して、デプロイの承認を統合する。
Microsoft Sentinel インフラストラクチャを使用した自動デプロイ
エンタープライズ アーキテクチャに応じて、1 つ以上の Microsoft Sentinel 環境をデプロイできます。
- 運用環境に複数のインスタンスを必要とする組織は、地理的な場所ごとに同じテナントに別々のサブスクリプションを設定できます。
- 運用環境の一元化されたインスタンスでは、同じテナントの 1 つまたは複数の組織へのアクセスが提供されます。
- 運用環境、運用前環境、統合環境などの複数の環境を必要とするグループは、必要に応じてそれらを作成および破棄できます。
物理と論理の環境定義の比較
環境定義の設定には、物理または論理の 2 つの選択肢があります。 どちらにも異なるオプションと利点があります。
- 物理定義 - Microsoft Sentinel アーキテクチャの要素は、コードとしてのインフラストラクチャ (IaC) の次のオプションを使用して定義されます。
- Bicep テンプレート
- Azure Resource Manager テンプレート (ARM テンプレート)
- Terraform
- 論理定義 - これはグループ内の異なるチームを設定し、それらの環境を定義するための抽象化レイヤーとして機能します。 定義は物理インフラストラクチャ レイヤーを使用して、ビルド環境の入力としてデプロイ パイプラインとワークフロー内で設定されます。
論理環境を定義する場合は、次の点を考慮してください。
- 名前付け規則
- 環境の特定
- コネクタと構成
コード リポジトリ
前のセクションで示した複数の環境アプローチを考慮して、次の GitHub コード リポジトリ編成について検討します。
物理定義 - IaC オプションに基づいて、メインのデプロイ定義でリンクされている個々のモジュール定義を使用するアプローチについて考えてみます。
次の例は、コードの編成方法を示しています。
このリポジトリへのアクセスを、物理レベルでアーキテクチャを定義するチームに制限し、エンタープライズ アーキテクチャで同種の定義となるようにします。
各組織のデプロイ戦略に合わせて、ブランチとマージの戦略を調整できます。 チームが定義から始める必要がある場合は、「Git ブランチ戦略を採用する」を参照してください。
ARM テンプレートの詳細については、「Azure リソース デプロイ時のリンクされたテンプレートおよび入れ子になったテンプレートの使用」を参照してください。
Bicep 環境の設定の詳細については、「Bicep ツールのインストール」を参照してください。 GitHub の詳細については、「GitHubフロー」を参照してください。
論理定義では、会社の環境を定義します。 Git リポジトリでは、会社のさまざまな定義を収集します。
次の例は、コードの編成方法を示しています。
リポジトリには、異なるチームによって行われた PR アクションが反映されます。 複数の環境が異なるチームによって定義され、会社の所有者または承認者によって承認されます。
環境デプロイを実行する特権レベルはレベル 2 です。 このレベルでは、リソース グループとリソースが、必要なセキュリティとプライバシーを持つ環境用に作成されます。 このレベルでは、運用環境 (運用環境と運用前環境) で許可されるアクションに対するユーザー アクセス許可も設定されます。
テストと開発のためにオンデマンドで環境を必要とし、テストが終了した後で環境を破棄する機能を必要としている組織は、Azure DevOps パイプラインまたは GitHub アクションを実装できます。 スケジュールされたトリガーを設定して、Azure DevOps イベントまたは GitHub アクションを使用して、必要に応じて環境を破棄できます。
Microsoft Sentinel コネクタの自動構成
Microsoft Sentinel コネクタは、Microsoft Entra ID、Microsoft 365、Microsoft Defender、脅威インテリジェンス プラットフォーム ソリューションなど、エンタープライズ アーキテクチャ環境内のさまざまな要素との接続をサポートするソリューションの重要な部分です。
環境を定義するときに、コネクタ構成を使用して同種の構成で環境を設定できます。
DevOpsモデルの一部としてコネクタを有効にすることが、サービス プリンシパル レベル モデルでサポートされている必要があります。 この点に注目することにより、次の表に示すような適切なレベルのアクセス許可が確保されます。
| コネクタのシナリオ | 特権アクセス モデルのレベル | Azure の最小限の特権 | ワークフローの承認が必要かどうか |
|---|---|---|---|
| Microsoft Entra ID | レベル 0 | グローバル管理者またはセキュリティ管理者 | 推奨 |
| Microsoft Entra ID Protection | レベル 0 | グローバル管理者またはセキュリティ管理者 | 推奨 |
| Microsoft Defender for Identity | レベル 0 | グローバル管理者またはセキュリティ管理者 | 推奨 |
| Microsoft Office 365 | レベル 0 | グローバル管理者またはセキュリティ管理者 | 推奨 |
| Microsoft Cloud App Security | レベル 0 | グローバル管理者またはセキュリティ管理者 | 推奨 |
| Microsoft Defender XDR | レベル 0 | グローバル管理者またはセキュリティ管理者 | 推奨 |
| Microsoft Defender for IOT | [レベル 2] | 共同作成者 | 推奨 |
| Microsoft Defender for Cloud | [レベル 2] | セキュリティ閲覧者 | 省略可能 |
| Azure アクティビティ | [レベル 2] | サブスクリプション閲覧者 | 省略可能 |
| 脅威インテリジェンス プラットフォーム | レベル 0 | グローバル管理者またはセキュリティ管理者 | 推奨 |
| セキュリティ イベント | [レベル 4] | なし | 省略可能 |
| syslog | [レベル 4] | なし | 省略可能 |
| DNS (プレビュー) | [レベル 4] | なし | 省略可能 |
| Windows ファイアウォール | [レベル 4] | なし | 省略可能 |
| AMA を使用した Windows セキュリティ イベント | [レベル 4] | なし | 省略可能 |
Microsoft Sentinel の成果物のデプロイ
Microsoft Sentinel の成果物の実装では、各企業が攻撃を防止して修復するために複数の成果物を作成するため、DevOps の関連性が高まります。
成果物の実装に責任を負うのが、1 つのチームだったり複数のチームだったりすることがあります。 自動的なビルドと成果物のデプロイは、多くの場合、最も一般的なプロセス要件であり、エージェントとランナーのアプローチと条件を決定づけます。
Microsoft Sentinel の成果物をデプロイして管理するには、Microsoft Sentinel REST API の使用が必要になります。 詳細については、「Microsoft Sentinel REST API」を参照してください。 次の図は、Azure REST API スタック上の Azure DevOps パイプラインを示しています。
PowerShell を使用してリポジトリを実装することもできます。
チームで MITRE を使用する場合は、さまざまな成果物を分類し、それぞれに方針と手法を指定します。 成果物の種類ごとに対応するメタデータ ファイルを含めるようにしてください。
たとえば、Azure ARM テンプレートを使用して新しいプレイブックを作成し、ファイル名が Playbook.arm.json の場合は、Playbook.arm.mitre.json という名前の JSON ファイルを追加します。 したがって、このファイルのメタデータには、使用している MITRE の方針または手法に対応する CSV、JSON、または YAML 形式が含まれます。
この手法に従うことで、チームは使用するさまざまな成果物の種類のセットアップ中に行われたジョブに基づいて MITRE カバレッジを評価できます。
ビルド成果物
ビルド プロセスの目的は、最高の品質の成果物を確実に生成することです。 次の図は、実行できるビルド プロセスのアクションの一部を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
- 成果物の定義を JSON または YAML 形式の記述スキーマに基づくようにし、その後スキーマを検証して、構文エラーを回避できます。
- ARM テンプレート テスト ツールキットを使用して、ARM テンプレートを検証します。
- PowerShell を使用して、カスタム モデルの YAML と JSON ファイルを検証します。
- ウォッチリスト設定を検証し、定義したクラスレス ドメイン間ルーティング (CIDR) レコードが正しいスキーマ (10.1.0.0/16 など) に従っていることを確認します。
- 構文のレベルで検証できるキーワード クエリ言語 (KQL) クエリを使用して、分析ルール、ハンティング ルール、ライブ ストリーム ルールを検証します。これは構文のレベルで検証できます。
- KQL ローカル検証も、1 つのオプションにします。
- KQL インライン検証ツールを DevOps パイプラインに統合します。
- Azure Automation 用の PowerShell に基づくロジックを実装する場合は、次の要素を使用して、構文の検証と単体テストを含めることができます。
- 成果物に含まれるメタデータ ファイルに基づいて、MITRE マニフェスト メタデータ レポートを生成します。
成果物をエクスポートする
通常、複数のチームが複数の Microsoft Sentinel インスタンスで作業し、必要な成果物を生成して検証します。 既存の成果物を再利用する目的で、会社では既存の環境から成果物定義を取得する自動プロセスを設定できます。 また、Automation ではセットアップ中に異なる開発チームによって作成された成果物に関する情報を提供できます。
次の図は、成果物抽出プロセスの例を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
成果物をデプロイする
デプロイ プロセスの目的は次のとおりです。
- 市場投入までの時間を短縮する。
- ソリューションの設定と管理に関与する複数のチーム間でパフォーマンスを向上させる。
- 環境の正常性を評価する統合テストを設定する。
開発チームはこのプロセスを使用して、開発中の成果物のユース ケースをデプロイ、テスト、検証できます。 アーキテクチャと SOC のチームは QA 環境でパイプラインの品質を検証し、攻撃シナリオの統合テストを行います。 テスト ケースでは、チームは通常、分析ルール、修復プレイブック、ウォッチリストなどのさまざまな成果物を結合します。 各ユース ケースの一部には攻撃のシミュレーションが含まれ、ここで、インジェスト、検出、修復の側面からチェーン全体が評価されます。
次の図は、成果物が適切な順序でデプロイされるデプロイ プロセス シーケンスを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
Sentinel 成果物をコードとして管理することで、運用を維持し、CI/CD DevOps パイプラインでデプロイを自動化するための柔軟な方法が提供されます。
Microsoft ソリューションでは、次の成果物についての自動化ワークフローが提供されます。
| アーティファクト | Automation ワークフロー |
|---|---|
| ウォッチリスト | コード レビュー スキーマの検証 デプロイ ウォッチリストとアイテムの作成、更新、削除 |
| 分析ルールの fusion Microsoft Security ML 行動分析 異常 スケジュール済み |
コード レビュー KQL 構文検証 スキーマの検証 Pester デプロイ 作成、有効化、更新、削除、エクスポート 警告テンプレートのサポート |
| オートメーション ルール | コード レビュー スキーマの検証 デプロイ 作成、有効化、更新、削除、エクスポート |
| Connectors | コード レビュー スキーマの検証 デプロイ アクション: 有効化、削除 (無効化)、更新 |
| ハンティング ルール | コード レビュー KQL 構文検証 スキーマの検証 Pester デプロイ アクション: 作成、有効化、更新、削除、エクスポート |
| プレイブック | コード レビュー TTK デプロイ アクション: 作成、有効化、更新、削除、エクスポート |
| Workbooks | デプロイ アクション: 作成、更新、削除 |
| Runbooks | コード レビュー PowerShell 構文検証 Pester デプロイ アクション: 作成、有効化、更新、削除、エクスポート |
選択したオートメーション言語によっては、一部の自動化機能がサポートされていない場合があります。 次の図は、言語ごとにサポートされている自動化機能を示しています。
* まだ文書化されていない開発中の機能
** Microsoft Operational Insights または Microsoft Insights リソース プロバイダー API でサポートされている自動化メソッド
Azure Automation
次の図は、マネージド サービス ID を使用して Microsoft Sentinel アクセスを簡略化するコンポーネントを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
他のリソースへのアクセスを許可する必要がある場合は、マネージド ID を使用します。これにより、すべての重要な操作に対して一意の ID が保証されます。
プレイブックを設定するには、Azure Automation を使用します。 次の複雑なタスクと自動化機能には、PowerShell スクリプトを使用します。
- さまざまなレベルの資格情報が必要で、Microsoft Entra ID またはカスタムの資格情報に基づく必要がある、サードパーティ ソリューションとの統合:
- Microsoft Entra ユーザー資格情報
- Microsoft Entra サービス プリンシパルの資格情報
- 証明書の認証
- カスタム資格情報
- マネージド ID
- 組織のスクリプトを再利用するソリューション、またはプレイブックへの複雑な変換を回避するために PowerShell コマンドを使用する必要があるソリューションの実装
- PowerShell ベースのソリューション
- Python ベースのソリューション
- 修復アクションがクラウドとオンプレミスのリソースに影響を与える可能性があるハイブリッド シナリオでのソリューションの実装。
Microsoft Sentinel リポジトリ
経験豊富な DevOps チームであれば、Azure DevOps に組み込まれている CI/CD パイプラインを使用して、コードとしてのインフラストラクチャ (IaC) で Microsoft Sentinel を管理することを検討する場合もあります。 製品グループは、顧客とパートナーが Azure DevOps セキュリティ アーキテクチャを構築する上で直面する課題を理解しているため、次の 2 つの取り組みが役立つ可能性があります。
- 参照用アーキテクチャの文書化
- Ignite 2021 で発表された、"Microsoft Sentinel リポジトリ" と呼ばれる新しいソリューションの開発
チームのニーズに合ったソリューションの選択をサポートするために、次の表では機能と技術の基準を比較します。
| ユース ケースと機能 | Azure DevOps と GitHub のカスタム アプローチ | Microsoft Sentinel リポジトリ |
|---|---|---|
| Azure DevOps アーキテクチャ コンポーネント (エージェント、パイプライン、Git、ダッシュボード、Wiki、サービス プリンシパル、RBAC、監査など) の定義に時間を費やさずに、Microsoft Sentinel 成果物のデプロイをすぐに開始する必要がある。 | 推奨されません | 推奨 |
| CI/CD パイプラインを管理するためのチームが小規模でスキル セットが低い。 | 推奨されません | 推奨 |
| CI/CD パイプラインのセキュリティのすべての側面を制御して管理する必要がある。 | サポートされています | サポートされていません |
| 開発者がデプロイ パイプラインをトリガーする前に、監視の統合のためにゲートとブランチを統合する必要がある (ソース管理、コーディング レビュー、ロールバック、ワークフロー承認など)。 | サポートされています | 部分的にサポートされています。 |
| カスタマイズされた Git またはリポジトリ構造がある。 | サポートされています | サポートされています |
| 成果物をビルドするために Resource Manager や Bicep IaC 言語を使用しない。 | サポートされています | サポートなし |
| 複数の Microsoft Sentinel ワークスペースへの成果物のデプロイを 1 つの Microsoft Entra テナント内で一元管理する必要がある。 | サポートされています | サポートされています |
| 複数の Microsoft Entra テナント間で CI/CD パイプラインを統合または拡張する必要がある。 | サポートされています | サポートされています |
| サブスクリプション、場所、環境などによってパラメーター化が異なるプレイブックがある。 | サポートされています | 未定 (ガイドラインを文書化する予定) |
| 同じリポジトリで異なる成果物を統合して、ユース ケースを作成する必要がある。 | サポートされています | サポートされています |
| 成果物を一括削除する機能が必要。 | サポートされています | サポートされていません |
可用性、パフォーマンス、スケーラビリティ
Microsoft Sentinel シナリオ用に社内で Azure DevOps エージェントのアーキテクチャを選択する場合は、次のニーズを考慮してください。
- 運用環境では、Microsoft Sentinel 環境での操作に専用のエージェント プールが必要になる場合があります。
- 非運用環境では、特に CI/CD 業務のチームからのさまざまな要求を処理するための多数のインスタンスでエージェント プールを共有する場合があります。
- 攻撃シミュレーション シナリオは、専用のエージェントが必要になる特殊なケースです。 テストのニーズに対して専用プールが必要かどうかを検討してください。
- ハイブリッド ネットワーク シナリオに取り組む組織は、ネットワーク内のエージェントの統合を検討する場合があります。
組織は、コンテナーに基づいてエージェント用に独自のイメージを作成できます。 詳細については、「Docker でセルフホステッド エージェントを実行する」を参照してください。
Azure DevOps による Microsoft Sentinel のテナント間の管理
グローバル SOC または MSSP として、複数のテナントを管理する必要がある場合があります。 Azure Lighthouse では、複数の Microsoft Entra テナント間でのスケーリング動作が同時にサポートされ、管理タスクが効率化されます。 詳細については、Azure Lighthouse の概要に関するページを参照してください。
テナント間の管理は、次のシナリオで特に有効です。
- 顧客テナントで Microsoft Sentinel リソースを管理する。
- 複数のテナントにわたる攻撃を追跡し、セキュリティ アラートを表示する。
- テナント間に分散している複数の Microsoft Sentinel ワークスペースにわたるインシデントを表示する。
顧客をオンボードする方法
顧客をオンボードするには、マネージド サービス オファーと ARM テンプレートの 2 つのオプションがあります。
ARM テンプレートを使用した手動オンボード
オファーを Azure Marketplace にサービス プロバイダーとして発行しない場合や、すべての要件を満たしていない場合は、ARM テンプレートを使用して、顧客を手動でオンボードできます。 これは、同じ企業に複数のテナントがあるエンタープライズ シナリオで最も可能性の高いオプションです。
次の表は、オンボード シナリオを比較したものです。
| 考慮事項 | マネージド サービス プラン | ARM テンプレート |
|---|---|---|
| パートナー センター アカウントが必要 | はい | いいえ |
| Silver または Gold Cloud Platform コンピテンシー レベルまたは Azure Expert マネージド サービス プロバイダー (MSP) のステータスが必要 | はい | いいえ |
| 新規顧客は Azure Marketplace を通して利用可能 | はい | いいえ |
| 特定の顧客に対してオファーを制限できる | はい (プライベート オファーを使用する場合のみ。これは、CSP プログラムのリセラーを通して確立されたサブスクリプションでは使用できません) | はい |
| 顧客が Azure portal で同意する必要がある | はい | いいえ |
| オートメーションを使用して複数のサブスクリプション、リソースグループ、または顧客をオンボードできる | いいえ | はい |
| 新しい組み込みロールと Azure Lighthouse 機能への即座のアクセスを提供する | 常にではない (しばらく延期の後に一般公開) | はい |
マネージド サービス オファーの発行の詳細については、「Azure Marketplace にマネージド サービス オファーを発行する」を参照してください。
ARM テンプレートの作成方法の詳細については、ARM テンプレートの作成とデプロイに関する記事を参照してください。
次の図は、Azure Lighthouse と Microsoft Sentinel を使用した、MSSP テナントと顧客のリソース プロバイダー テナントのアーキテクチャの統合の概要を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
- MSP オファリングは、ARM テンプレートまたは Azure Marketplace サービス オファリングを通じて統合されます。
- Azure の委任されたリソース管理では、要求がパートナー テナントからのものであることが確認され、マネージド サービス リソース プロバイダーが呼び出されます。
- マネージド サービス リソース プロバイダーでは、MSP のアクセスを制御するために RBAC が使用されます。
- MSP によって、顧客リソースに対する SecOps アクションが実行されます。
- 課金プロセスでは、経費が顧客の料金として扱われます。 顧客エンティティが同じ Microsoft Entra テナント内に別々のワークスペースを持つ場合、課金の分割が可能です。
- データのセキュリティと主権は、顧客のテナントの境界に依存します。
複数のテナントにわたる ID
Microsoft Sentinel を Azure DevOps で管理するには、次に示すコンポーネントに対する設計上の決定を評価します。
| 使用事例 | 長所 |
|---|---|
| DevOps アクションを管理するためのグローバル ID、単一のサービス プリンシパル | このケースは、すべてのテナントを含むグローバル デプロイ プロセスに適用されます。 統合 ID を使用すると、さまざまなテナントへのアクセスが容易になりますが、特定のテナントの承認アクションを管理するプロセスが複雑になる可能性があります。 この種の ID の保護メカニズムと承認モデルも、関連するグローバルな影響による承認されていない使用を回避するために非常に重要です。 |
| DevOps アクションを管理するための専用 ID、複数のサービス プリンシパル | このケースは、デプロイ プロセスがテナントごとに専用のものである場合、またはテナント アクションに承認が必要な場合に適用されます。 この場合、この ID の使用を保護して承認するための推奨事項は、影響が軽減された場合でも、グローバルな場合と同じです。 |
コード リポジトリの編成
| 使用事例 | 長所 |
|---|---|
| すべてのテナントについて単一バージョンのコードを含む統合リポジトリ | このケースでは、リポジトリ内でコードの統合バージョンを持つことが容易になります。 このケースでは、テナントの特定のバージョンを管理するコードの統合バージョンには、各ケースのブランチに対するサポートが必要な場合があります。 |
| テナント別の特定のコード フォルダーを持つ統合リポジトリ | このケースは単一リポジトリのケースを補完します。 ここでは、フォルダー構造で専用の成果物をテナント別に分割できます。 |
| テナント別の専用リポジトリ | この方法では、コード成果物を管理するときの分離が提供されます。 これにより、チームや要件が異なるテナント間での進化が容易になります。 変更を統合するには、リポジトリ間でプロセスを確立する必要があり、これには保守作業が必要になる場合があります。 |
ビルドとデプロイのプロセス
| 使用事例 | 長所 |
|---|---|
| すべてのテナントについての単一のビルド プロセス | すべてのテナントで同じバージョンの成果物が使用される場合、これは生成とパッケージを実装するための最も簡単なオプションです。 |
| テナント別のビルド プロセス | 異なるバージョンのコードが各テナントにデプロイされます。 |
| すべてのテナント用のグローバル デプロイ プロセス | 新しいデプロイとデプロイの更新が、すべてのテナントに適用されます。 すべてのテナントに対してデプロイと更新のプロセスの手順が使用されます。 |
| テナント別のグローバル デプロイ プロセス | 新しいデプロイとデプロイの更新が、1 つまたは複数のテナントに適用されます。 |
| テナント別の専用のデプロイ プロセス | デプロイ プロセスは、各テナントに適用されます。 |
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させることです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
ソリューションのコストは、次の要因によって決まります。
- 会社が Microsoft Sentinel Log Analytics ワークスペースに入れるデータの量 (月単位)
- 従量課金制 (PAYG) など、選択したコミットメント レベルまたは課金方法
- テーブルまたはグローバルのレベルでのデータ ポリシーのリテンション率
詳細については、Azure のデータの種類別のリテンションに関する記事を参照してください。
価格を計算するには、Microsoft Sentinel の料金計算ツールを参照してください。 価格に関する高度な考慮事項と例については、「Microsoft Sentinel のコストを計画する」を参照してください。
次のコンポーネントを使用してソリューションを拡張すると、追加のコストが発生する可能性があります。
- プレイブック - Azure Logic Apps および Azure Functions のランタイム。 詳細については、価格の詳細に関するページをご覧ください。
- Azure Data Explorer、Event Hubs、Azure Storage アカウントなどの外部ストレージへのエクスポート。
- Jupyter Notebook コンポーネントで使用する機械学習ワークスペースとコンピューティング。
このシナリオのデプロイ
次のセクションでは、さまざまな DevOps プロセスをカバーするサンプル ユースケースの形式でこのシナリオをデプロイする手順について説明します。
Microsoft Sentinel フレームワークをビルドしてリリースする
まず、生成したリリースをさまざまなプロセスで使用できる専用リポジトリに、必要な NuGet コンポーネントを設定します。
Azure DevOps を使用している場合、PowerShell 用の Microsoft Sentinel フレームワークからのさまざまな NuGet パッケージをホストするコンポーネント フィードを作成できます。 詳細については、「NuGet パッケージの概要」を参照してください。
チームで GitHub レジストリを選択した場合、フィード プロトコルと互換性があるため、これを NuGet リポジトリとして接続できます。 詳細については、「GitHub パッケージ入門」を参照してください。
使用可能な NuGet リポジトリがある場合、パイプラインには NuGet のサービス接続が含まれます。 これらのスクリーンショットは、Microsoft Sentinel NuGet Framework Connection という名前の新しいサービス接続の構成を示しています。
フィードを構成した後、PowerShell フレームワークを構築するためのパイプラインを特定のフォークで GitHub から直接インポートできます。 詳細については、「GitHub リポジトリの構築」を参照してください。 このケースでは、新しいパイプラインを作成し、コード ソースとして GitHub を選択します。
別の方法として、Git に基づく Azure DevOps リポジトリとして Git リポジトリをインポートすることもできます。 どちらの場合も、パイプラインをインポートするには、次のパスを指定します。
src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml
これで、初めてパイプラインを実行できるようになりました。 次に、フレームワークによって NuGet フィードへのビルドとリリースが行われます。
Microsoft Sentinel 環境を定義する
Microsoft Sentinel の使用を開始してこれらのサンプルを使用する場合、会社内の環境を定義します (Environment as Code (Eac) など)。 各ケースで環境を構成するさまざまな要素を指定します。
Microsoft Sentinel の成果物には、Azure 上の次の要素が含まれています。
- Log Analytics ワークスペース - このワークスペースは、ソリューションの基礎を形成します。 セキュリティ関連の情報はここに格納され、ワークスペースは Kusto 照会言語 (KQL) のエンジンです。
- Log Analytics ワークスペースでの Microsoft Sentinel ソリューション - このソリューションは、Log Analytics ワークスペースの機能を拡張して、SIEM と SOAR の機能が含まれています。
- Key Vault - キー コンテナーでは、修復プロセス中に使用されるシークレットとキーが保持されます。
- Automation アカウント - このアカウントはオプションであり、修復プロセスに使用されます。 使用する修復プロセスは、PowerShell と Python の Runbook に基づいています。 このプロセスには、ベスト プラクティスに従ってさまざまなリソースで動作するシステム マネージド ID が含まれています。
- ユーザー マネージド ID - この機能は、Microsoft Sentinel プレイブックと Runbook の間の対話を管理する Microsoft Sentinel 統一 ID レイヤーとして機能します。
- ロジック アプリ接続 - これらは、Microsoft Sentinel、キー コンテナー、およびユーザー マネージド ID を使用するオートメーションの接続です。
- 外部ロジック アプリ接続 - これらは、修復プロセスに関連し、プレイブックに基づく外部リソースへの接続です。
- Azure Event Hubs - この機能はオプションで、Microsoft Sentinel とその他のソリューション (Splunk、Azure Databricks と Machine Learning、Resilient など) との統合を処理します。
- ストレージ アカウント - この機能はオプションで、Microsoft Sentinel とその他のソリューション (Splunk、Azure Databricks と Machine Learning、Resilient など) との統合を処理します。
リポジトリの例を使用すると、JSON ファイルを使用して環境を定義し、さまざまな論理概念を指定することができます。 環境の定義に使用できるオプションは、リテラルまたは自動です。
リテラル定義では、次の例に示すように、環境内の各リソースの名前と要素を指定します。
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Literal",
"ResourceGroupName": "<resource-group-name>"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Literal",
"LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
"ManagedIdentityName": "<user-managed-identity-name>",
"SentinelConnectionName": "<Sentinel-API-connection-name>",
"KeyVaultName": "<Key-Vault-name>",
"KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
},
"Automation":
{
"Type": "Literal",
"AutomationAccountName": "<automation-account-name>",
"AutomationAccountConnectionName": "<automation-account-API-connection-name>"
},
"Integration":
{
"Type": "Literal",
"EventHubNamespaces": [
"<Event-Hubs-namespace-1-name>",
"<Event-Hubs-namespace-2-name>",
"<Event-Hubs-namespace-3-name>",
"<Event-Hubs-namespace-4-name>",
"<Event-Hubs-namespace-5-name>",
"<Event-Hubs-namespace-6-name>",
"<Event-Hubs-namespace-7-name>",
"<Event-Hubs-namespace-8-name>",
"<Event-Hubs-namespace-9-name>",
"<Event-Hubs-namespace-10-name>",
],
"StorageAccountName": "<storage-account-name>"
}
}
}
自動定義では、次の例に示すように、要素名は名前付け規則に基づいて自動的に生成されます。
{
{
"SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
"Name": "<environment-name>",
"NamingConvention": "<naming-convention-template-for-automatic-cases>",
"Location": "<environment-location>",
"ResourceGroup": {
"Type": "Automatic"
}
},
"Resources":
{
"Sentinel":
{
"Type": "Automatic"
},
"Automation":
{
"Type": "Automatic"
},
"Integration":
{
"Type": "Automatic",
"MaxEventHubNamespaces": 5
}
}
}
GitHub リポジトリで Microsoft Sentinel 環境パスの下にあるサンプルを見つけ、ユース ケースの準備のリファレンスとしてサンプルを使用できます。
Microsoft Sentinel 環境をデプロイする
少なくとも 1 つの環境が定義されたら、Azure DevOps と統合するための Azure サービス接続を作成できます。 サービス接続を作成したら、ターゲット サブスクリプション上の所有者ロールまたは同様の権限レベルにリンクされたサービス プリンシパルを設定します。
このファイルで定義されている新しい環境を作成するためのパイプラインをインポートします。
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml次に、環境を表すサービス接続の名前を入力します。
リポジトリ内の環境定義のブランチを選択します。
[Azure Environment Connection] (Azure 環境接続) ボックスに、サブスクリプションの Azure DevOps サービス接続の名前を入力します。
同じサブスクリプション内の複数の環境を解決するためにサービス接続で使用できる環境の名前を入力します。
コネクタに適用するアクションを選択します。
プレリリース版の PowerShell フレームワーク コンポーネントを使用する場合は、[Use PowerShell Pre-Release Artifacts] (PowerShell プレリリース成果物の使用) を選択します。
パイプラインには、デプロイ フローの一部として次の手順が含まれています。
- NuGet コンポーネントをデプロイする。
- NuGet ツールを使用して成果物リポジトリと接続する。
- フィードを解決する。
- 必須のモジュールをインストールする。
- 環境定義を取得する。
- ターゲットに存在するリソースを検証する。
- Log Analytics と Microsoft Sentinel を追加する (これらがワークスペースにない場合)。
- Log Analytics が既にある場合は、Log Analytics のインスタンスに Microsoft Sentinel を追加する。
- Microsoft Sentinel と Logic Apps の間の相互作用を表すマネージド ID を作成する。
- Azure Key Vault を作成し、マネージド ID に対してシークレットとキーを管理するためのロールの割り当てを設定する。
- 該当する場合は、Azure Automation アカウントを作成し、システム割り当てマネージド ID をオンにする。
- システム割り当てマネージド ID についてキー コンテナーに対するロール割り当てを設定する。
- Event Hubs 定義が存在しない場合は作成し、その定義に統合要素が含まれているかどうかを設定する。
- システム割り当てマネージド ID についてキー コンテナーに対するロール割り当てを設定する。
- ストレージ アカウント定義が存在しない場合は作成し、その定義に統合要素が含まれているかどうかを設定する。
- システム割り当てマネージド ID についてキー コンテナーに対するロール割り当てを設定する。
- コネクタ アクションをデプロイする。
- Automation アカウントに統合 Runbook をデプロイする。
- 環境の一部として定義されている場合は、Logic Apps 接続をデプロイする。
Microsoft Sentinel 環境を破棄する
開発やテストの環境の場合のように、環境が不要になった場合は、このファイルで定義されているように破棄できます。
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml
環境パイプラインを配置するときと同様に、環境を表すサービス接続の名前を指定します。
Microsoft Sentinel 環境を操作する
環境の準備ができたら、さまざまなユースケースを設定するための成果物の作成を開始できます。
このファイルで定義されているように、作業中の環境から成果物をエクスポートします。
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.ymlリポジトリ内の環境定義のブランチを選択します。
[Azure Environment Connection] (Azure 環境接続) ボックスに、エクスポート中の環境の Azure DevOps サービス接続の名前を入力します。
プレリリース版の PowerShell フレームワーク コンポーネントを使用する場合は、[Use PowerShell Pre-Release Artifacts] (PowerShell プレリリース成果物の使用) を選択します。
分析とハンティングのルールの形式を選択します。
結果の成果物出力ファイルが生成されます。 成果物を入手した後は、Git リポジトリに出力ファイルを含めることができます。
Microsoft Sentinel 環境で成果物をビルドする
成果物を Microsoft Sentinel MITRE のユース ケース パスの下に配置します。 さまざまな種類の成果物に応じてフォルダー構造を設定します。
このファイルで定義されているビルド プロセスを開始します。
src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yamlリポジトリ内の環境定義のブランチを選択します。
成果物をビルドするブランチを選択する方法の図。(./media/build-artifacts-pipeline.png)
プレリリース版の PowerShell フレームワーク コンポーネントを使用する場合は、[Use PowerShell Pre-Release Artifacts] (PowerShell プレリリース成果物の使用) を選択します。
パイプラインは、次の手順で構成されます。
- NuGet コンポーネントをデプロイする。
- NuGet ツールを成果物リポジトリに追加する。
- フィードを解決する。
- 必須のモジュールをインストールする。
- ARM テンプレートを検証するためのテスト ツールキット フレームワークを取得する。
- ARM テンプレートを検証する。
- PowerShell Runbook コードを検証し、構文の検証を行う。
- 該当する場合は、Pester 単体テストを実行する。
- ハンティングと分析のルールで KQL 構文を検証する。
Microsoft Sentinel 環境に成果物をデプロイする
成果物をデプロイする場合は、Microsoft Sentinel リポジトリまたはこのリポジトリのデプロイ パイプライン サンプルを使用できます。 詳細については、リポジトリからのカスタム コンテンツのデプロイに関する記事を参照してください。
Microsoft Sentinel リポジトリ
Microsoft Sentinel リポジトリを使用する場合は、各 Microsoft Sentinel インスタンスに接続されているリポジトリに成果物を含めるリリース プロセスを設定できます。 成果物がリポジトリにコミットされた後、一部の手順は、パイプラインの作成と Microsoft Sentinel リポジトリの有効化の一環として自動的に実行されます。
また、このドキュメントで説明されている方法に基づいて、Microsoft Sentinel リポジトリが実行するデプロイ プロセスをカスタマイズできます。 考慮すべき重要な側面の 1 つは、次の方法で設定できるリリース承認です。
- 成果物をコミットする際の PR 承認。 詳しくは、「pull request の作成」を参照してください。
- デプロイの実行中にパイプラインの承認をリリースします。 詳細については、「承認とチェックを定義する」を参照してください。
Microsoft Sentinel デプロイ パイプラインのサンプル
Microsoft Sentinel デプロイ パイプラインのサンプルを使用すると、リリース プロセスを設定できます。
このファイルで定義されているリリース プロセスを設定します。
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.ymlリポジトリ内の環境定義のブランチを選択します。
[Azure Environment Connection] (Azure 環境接続) ボックスに、エクスポート中の環境の Azure DevOps サービス接続の名前を入力します。
プレリリース版の PowerShell フレームワーク コンポーネントを使用する場合は、[Use PowerShell Pre-Release Artifacts] (PowerShell プレリリース成果物の使用) を選択します。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Kevin Kisoka |アソシエイト アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- シングルテナント アーキテクチャ用の DevOps を使用した Microsoft Sentinel の詳細については、「コードとしての Microsoft Sentinel のデプロイと管理」を参照してください。
- MSSP マルチテナント アーキテクチャの詳細については、「Azure Lighthouse と Microsoft Sentinel の DevOps 機能を結合する」を参照してください。
- Microsoft Sentinel を使用したマネージド ID の詳細については、「新機能 : Microsoft Sentinel Logic Apps コネクタのマネージド ID」を参照してください。
- Microsoft Sentinel リポジトリからコンテンツをデプロイする方法については、「リポジトリからカスタム コンテンツをデプロイする」を参照してください。
- Azure DevOps セキュリティの考慮事項については、既定のアクセス許可のクイック リファレンスに関する記事を参照してください。
- Azure DevOps リポジトリを保護する方法については、リポジトリ リソースへの保護の追加に関するページを参照してください。
- Azure DevOps サービス接続セキュリティを管理する方法については、Azure Pipelines でのサービス接続に関する記事を参照してください。