リポジトリのデプロイをカスタマイズする (パブリックプレビュー)

2025-05-01
適用対象: Microsoft Sentinel in the Microsoft Defender portal, Microsoft Sentinel in the Azure portal

Microsoft Sentinel ワークスペースへのリポジトリのコンテンツのデプロイをカスタマイズするには、主に 2 つの方法があります。各方法では異なるファイルと構文が使われるため、これらの例を使って作業を始めることを検討してください。

カスタマイズ方法	対象となる配置オプション
GitHub ワークフロー DevOps パイプライン	接続の配置トリガーをカスタマイズする配置パスをカスタマイズするスマート配置の有効化
構成ファイル	コンテンツ配置の優先順位を制御する特定のコンテンツファイルを配置から "除外" することを選択するパラメーターファイルを特定のコンテンツファイルにマップすることで、さまざまなワークスペースに配置をスケーリングする

重要

Microsoft Sentinel リポジトリ 機能は現在 プレビュー段階です。ベータ版、プレビュー版、または一般公開されていない Azure 機能に適用されるその他の法的条件については、 Microsoft Azure プレビューの追加使用条件を参照してください。

前提条件

リポジトリの配置をカスタマイズするには、リポジトリ接続が存在する必要があります。接続の作成の詳細については、「リポジトリからカスタムコンテンツをデプロイする」を参照してください。接続が確立された後は、次の前提条件が適用されます。

GitHub リポジトリへのコラボレーターアクセスまたは Azure DevOps リポジトリへのプロジェクト管理者アクセス
GitHub に対して有効なアクションと、Azure DevOps に対して有効なパイプライン
ワークスペースに配置するカスタムコンテンツファイルがサポートされている形式であることを確認します。サポートされている形式については、「リポジトリのコンテンツを計画する」を参照してください。

展開可能なコンテンツタイプの詳細については、「コンテンツの検証」を参照してください。

ワークフローまたはパイプラインをカスタマイズする

既定のワークフローでは、リポジトリへのコミットに基づいて、前回のデプロイ以降に変更されたコンテンツのみがデプロイされます。異なる配置トリガーを構成したり、特定のルートフォルダーからのみコンテンツを配置したりするには、カスタマイズしてください。

接続の種類に応じて、次のいずれかのタブを選択します。

GitHubの
Azure DevOps

GitHub デプロイワークフローをカスタマイズするには:

GitHub でリポジトリに移動し、 .github/workflows ディレクトリでワークフローを見つけます。

ワークフローファイルは、 sentinel-deploy-xxxxx.ymlで始まる YML ファイルです。そのファイルを開くと、ワークフロー名が最初の行に表示され、既定の名前付け規則は Deploy Content to <workspace-name> [<deployment-id>] になります。

例: name: Deploy Content to repositories-demo [xxxxx-dk5d-3s94-4829-9xvnc7391v83a]
ページの右上にある鉛筆ボタンを選択して編集のためにファイルを開き、次のようにデプロイを変更します。
- デプロイトリガーを変更するには、コード内の on セクションを更新します。このセクションには、ワークフローの実行をトリガーするイベントが記述されています。
  
  既定で、この構成は on: push に設定されています。つまり、既存のコンテンツへの変更とリポジトリへの新しいコンテンツの追加の両方を含め、接続されたブランチへのすべてのプッシュ時にワークフローがトリガーされます。次に例を示します。
```
on:
    push:
        branches: [ main ]
        paths:
        - `**`
        - `!.github/workflows/**` # this filter prevents other workflow changes from triggering this workflow
        - `.github/workflows/sentinel-deploy-<deployment-id>.yml`
```
  たとえば、ワークフローを定期的に実行するようにスケジュールしたり、さまざまなワークフローイベントを結合したりするには、これらの設定を変更します。
  
  詳細については、ワークフローイベントの構成に関する GitHub ドキュメントを参照してください。
- スマートデプロイを無効にするには:スマートデプロイの動作は、説明されているデプロイトリガーとは別です。ワークフローの jobs セクションに移動します。 smartDeployment の既定値を true から false に切り替えます。この変更がコミットされると、スマートデプロイ機能がオフになり、この接続のすべての将来のデプロイでは、この変更がコミットされると、リポジトリの関連するすべてのコンテンツファイルが接続されたワークスペースに再デプロイされます。
- デプロイパスを変更するには:
  
  on セクションに関する既定の構成では、** セクションの最初の行にあるワイルドカード (paths) は、ブランチ全体がデプロイトリガーのパスに含まれていることを示しています。
  
  この既定の構成は、コンテンツがブランチのどこかにプッシュされるといつでもデプロイワークフローがトリガーされることを意味します。
  
  ファイルの後半の jobs セクションには、既定の構成 directory: '${{ github.workspace }}' が含まれています。この行は、フォルダーパスをフィルターせずに、 GitHub ブランチ全体がコンテンツデプロイのパスに含まれることを示しています。
  
  特定のフォルダーパスのコンテンツのみをデプロイするには、それを paths と directory の両方の構成に追加します。たとえば、SentinelContent という名前のルートフォルダーからのコンテンツのみをデプロイするには、次のようにコードを更新します。
```
paths:
- `SentinelContent/**`
- `!.github/workflows/**` # this filter prevents other workflow changes from triggering this workflow
- `.github/workflows/sentinel-deploy-<deployment-id>.yml`

...
    directory: '${{ github.workspace }}/SentinelContent'
```

詳細については、 GitHub Actions と GitHub ワークフローの編集に関する GitHub ドキュメントを参照してください。

Azure DevOps デプロイパイプラインをカスタマイズするには:

Azure DevOps で、リポジトリに移動し、 .sentinel ディレクトリでパイプライン定義ファイルを見つけます。

パイプライン名はパイプラインファイルの最初の行に表示され、既定の名前付け規則 Deploy Content to <workspace-name> [<deployment-id>] があります。

例: name: Deploy Content to repositories-demo [xxxxx-dk5d-3s94-4829-9xvnc7391v83a]
ページの右上にある鉛筆ボタンを選択して編集のためにファイルを開き、次のようにデプロイを変更します。
- デプロイトリガーを変更するには、コード内の trigger セクションを更新します。このセクションには、ワークフローの実行をトリガーするイベントが記述されています。
  
  既定で、この構成は、既存のコンテンツへの変更とリポジトリへの新しいコンテンツの追加の両方を含め、接続されたブランチへのすべてのプッシュを検出するように設定されています。
  
  このトリガーを、スケジュール設定トリガーや pull request トリガーなど、使用可能な任意の Azure DevOps トリガーに変更します。詳細については、 Azure DevOps トリガーのドキュメントを参照してください。
- スマートデプロイを無効にするには:スマートデプロイの動作は、説明されているデプロイトリガーとは別です。パイプラインの ScriptArguments セクションに移動します。 smartDeployment の既定値を true から false に切り替えます。この変更がコミットされると、スマートデプロイ機能がオフになり、この接続のすべての将来のデプロイでは、この変更がコミットされると、リポジトリの関連するすべてのコンテンツファイルが接続されたワークスペースに再デプロイされます。
- デプロイパスを変更するには:
  
  trigger セクションの既定の構成には次のコードが含まれます。これは、main ブランチがデプロイトリガーのパスに含まれることを示しています。
```
trigger:
    branches:
        include:
        - main
```
  この既定の構成は、コンテンツが main ブランチのどこかにプッシュされるといつでもデプロイパイプラインがトリガーされることを意味します。
  
  特定のフォルダーパスからのみコンテンツを配置するには、トリガーの include セクションにフォルダー名を追加し、steps セクションに配置パスを追加します。
  
  たとえば、SentinelContent ブランチの main という名前のルートフォルダーからのコンテンツのみをデプロイするには、次のように include と workingDirectory の設定をコードに追加します。
```
paths:
    exclude:
    - .sentinel/*
    include:
    - .sentinel/sentinel-deploy-39d8ekc8-397-5963-49g8-5k63k5953829.yml
    - SentinelContent
....
steps:
- task: AzurePowerShell@5
  inputs:
    azureSubscription: `Sentinel_Deploy_ServiceConnection_0000000000000000`
    workingDirectory: `SentinelContent`
```

詳細については、 Azure DevOps YAML スキーマに関する Azure DevOps のドキュメントを参照してください。

重要

GitHub と Azure DevOps の両方で、トリガーパスとデプロイパスのディレクトリの一貫性を維持してください。

パラメーターファイルを使用してデプロイをスケーリングする

コンテンツファイルでパラメーターをインライン値として渡すのではなく、 Bicep パラメーターファイルまたはパラメーター値を含む JSON ファイルの使用を検討してください。次に、これらのパラメーターファイルを関連付けられた Microsoft Sentinel コンテンツファイルにマップして、異なるワークスペースにまたがる配置をより適切にスケーリングします。

パラメーターファイルをコンテンツファイルにマップするには、いくつかの方法があります。 Bicep パラメーターファイルは Bicep ファイルテンプレートのみをサポートしますが、JSON パラメーターファイルは両方をサポートしていることに注意してください。リポジトリの展開パイプラインでは、パラメーターファイルが次の順序で考慮されます。

パラメーターファイルマッピングの優先順位を示す図。

にマッピングはありますか?詳細については、「
。
ワークスペースにマップされたパラメーターファイルはありますか? はい。コンテンツファイルは、ワークスペースにマップされたパラメーターファイルと同じディレクトリ内に、
.< のいずれかのパターンに一致します。WorkspaceID>.bicepparam
.parameters-<WorkspaceID>.json
既定のパラメーターファイルはあるか? はい。コンテンツファイルは、
.bicepparam
次のいずれかのパターンに一致するパラメーターファイルを持つ同じディレクトリにあります.parameters.json

構成ファイルを使用してパラメーターファイルをマップするか、ファイル名にワークスペース ID を指定することで、複数のワークスペース配置との競合を回避します。

重要

マッピングの優先順位に基づいてパラメーターファイルの一致が決定されると、残りのマッピングはパイプラインで無視されます。

sentinel-deployment.config に一覧表示されているマップされたパラメーターファイルを変更すると、ペアになったコンテンツファイルのデプロイがトリガーされます。ワークスペースマップパラメーターファイルまたは既定のパラメーターファイルの追加または変更を行うと、さらに優先順位の高いパラメーターマッピングが設定されていない限り、ペアになっているコンテンツファイルと、新しく変更されたパラメーターの配置がトリガーされます。ワークフロー/パイプライン定義ファイルでスマートデプロイ機能が有効になっている限り、他のコンテンツファイルはデプロイされません。

接続構成をカスタマイズする

2022 年 7 月の時点で、リポジトリのデプロイスクリプトでは、各リポジトリブランチのデプロイ構成ファイルの使用がサポートされています。構成 JSON ファイルは、パラメーターファイルを関連するコンテンツファイルにマップし、デプロイの特定のコンテンツを優先し、デプロイから特定のコンテンツを除外するのに役立ちます。

リポジトリのルートに sentinel-deployment.config ファイルを作成します。この構成ファイルを追加、削除、または変更すると、更新された構成に従ってリポジトリ内のすべてのコンテンツの完全な配置がトリガーされます。
構造化コンテンツを 3 つの省略可能なセクションである "prioritizedcontentfiles":、"excludecontentfiles":、"parameterfilemappings": に追加します。セクションが含まれない場合や、.config ファイルが省略されている場合でも、デプロイプロセスは実行されます。無効なセクションまたは認識されないセクションは無視されます。

以下は有効なsentinel-deployment.configファイルの内容全体の例です。このサンプルは、 Microsoft Sentinel CICD リポジトリのサンプルでも確認できます。

{
  "prioritizedcontentfiles": [
    "parsers/Sample/ASimAuthenticationAWSCloudTrail.json",
    "workbooks/sample/TrendMicroDeepSecurityAttackActivity_ARM.json",
    "Playbooks/PaloAlto-PAN-OS/PaloAltoCustomConnector/azuredeploy.bicep"
  ], 
  "excludecontentfiles": [
     "Detections/Sample/PaloAlto-PortScanning.json",
     "parameters"
  ],
  "parameterfilemappings": {
    "879001c8-2181-4374-be7d-72e5dc69bd2b": {
      "Playbooks/PaloAlto-PAN-OS/Playbooks/PaloAlto-PAN-OS-BlockIP/azuredeploy.bicep": "parameters/samples/auzredeploy.bicepparam"
    },
    "9af71571-7181-4cef-992e-ef3f61506b4e": {
      "Playbooks/Enrich-SentinelIncident-GreyNoiseCommunity-IP/azuredeploy.json": "path/to/any-parameter-file.json"
    }
  },
  "DummySection": "This shouldn't impact deployment"
}

注

どのコンテンツパスでも円記号 "\" 文字を使わないでください。代わりにスラッシュ "/" を使ってください。

コンテンツファイルに優先順位を付ける方法:

リポジトリ内のコンテンツの量が増えると、デプロイの時間が長くなる可能性があります。時間の影響を受けやすいコンテンツをこのセクションに追加し、トリガーが発生したときにそのデプロイを優先させます。

"prioritizedcontentfiles": セクションに完全なパス名を追加します。現時点では、ワイルドカードマッチングはサポートされていません。
コンテンツファイルを除外するには、個々の .json コンテンツファイルの完全なパス名を使用して "excludecontentfiles": セクションを変更します。
パラメーターをマップするには:

デプロイスクリプトは、「パラメーターファイルを使用したデプロイのスケーリング」の説明に従って、パラメーターをマッピングする 3 つの方法を受け入れます。 sentinel-deployment.config を使用したパラメーターのマッピングは最も優先順位が高く、特定のパラメーターファイルが関連付けられているコンテンツファイルにマップされることを保証します。 "parameterfilemappings": セクションを、ターゲット接続のワークスペース ID と個々の .json ファイルの絶対パス名に変更してください。

サンプルリポジトリを使って、デプロイ構成ファイルと 3 つのパラメーターマッピング方法をすべて行ってみることができます。詳細については、 Microsoft Sentinel CICD リポジトリのサンプルを参照してください。

次の方法で共有

リポジトリのデプロイをカスタマイズする (パブリック プレビュー)

前提条件

ワークフローまたはパイプラインをカスタマイズする

パラメーター ファイルを使用してデプロイをスケーリングする

接続構成をカスタマイズする

関連するコンテンツ

フィードバック

その他のリソース

リポジトリのデプロイをカスタマイズする (パブリックプレビュー)

パラメーターファイルを使用してデプロイをスケーリングする