Microsoft Azure Storage Accountインテグレーションガイド🔗
以下の手順は、Secureworks® Taegis™ XDR への取り込みを容易にするために Azure Storage Account のインテグレーションを設定するためのものです。
設定の前提条件🔗
注意
XDR は、Azure commercial cloud、Azure Government、Azure Government 内の Department of Defense (DoD)、US Government (GCC)、および US Government High (GCC-High) の Azure Storage Account のインテグレーションをサポートしています。
注意
Storage Account のインテグレーションプロセスを開始する前に、以下の前提条件が必要です。
- 少なくとも 1 つの Storage Account を含むアクティブな Azure サブスクリプション。Quickstart: Create a Storage Account using Azure portal を参照してください
- データソースログの送信先となる Storage Account 内の Blob Container
- Storage Account Blob Container にログデータを送信するように設定された 1 つ以上のデータソース
必要な情報の収集🔗
Storage Account を XDR と連携するには、以下の情報が必要です。
- Storage Account — XDR とのインテグレーションに使用する Storage Account 名。
-
Blob Container — Storage Account 内に存在する Blob Container 名。これはデータソースログの送信先です。

Storage Account Blob Container -
Azure Function Service Plan Type — 詳細については、ベンダーのドキュメントを参照してください。
重要
"Isolated" Service Plan Type はサポートされていません。
注意
後でこのインテグレーションをプライベートネットワークに制限する予定がある場合は(以下のStorage Account をプライベートネットワークに制限するを参照)、ここでは Basic または Premium を選択してください。Dynamic (Consumption) プランはリージョン VNet インテグレーションをサポートしておらず、Function App の展開後にプランタイプを変更することはできません。これはこのステップで行う一度限りの決定であり、後から見直すことはできません。
- Azure Function Service Plan Code — 詳細については、ベンダーのドキュメントを参照してください。
| Service Plan Type | Valid Service Plan Code(s) |
|---|---|
| Basic | B1, B2, B3 |
| Dynamic | Y1 |
| Premium | P0V3,P1MV3,P1V2,P1V3,P2MV3,P2V2,P2V3,P3MV3,P3V2,P3V3,P4MV3,P5MV3 |
XDR に必要な情報を入力する🔗
XDR で、次の手順に従います。
- Taegis Menu から、Integrations → Cloud APIs を選択します。
-
ページ上部から Add an Integration を選択します。

インテグレーションの追加 -
Custom タブを選択し、Azure Storage Account カードから Set Up を選択します。
-
必要な情報の収集で説明されているとおりに必須フィールドを入力します。
- Taegis Integration Name — 任意の一意の文字列。
- Storage Account Name — ログデータの送信先となる既存の Storage Account の名前。
- Function App Name — Azure Function が何を行うことを意図しているかを示す説明的な文字列。
- 例: NSG Flow ログを Storage Account に送信する場合は
NSGFlowLogsForwarder。
- 例: NSG Flow ログを Storage Account に送信する場合は
- Data Source Key — これはログが作成されるコンテナフォルダーです。
- 例: データソースが
MicrosoftInsights/2024-02-03/02hr/part=01/00004.jsonのようなパターンで書き込まれる場合、MicrosoftInsightsが Data Source Key の適切な値になります。
- 例: データソースが
- Azure Function Service Plan Type — (任意)Basic、Dynamic、Premium。デフォルトは Dynamic です。
- Azure Function Service Plan Code — (任意)必要な情報の収集の表を参照してください。
- Azure Function Service Plan Num Workers — (任意)デフォルトは 1 です。

Azure Storage Accountインテグレーションの追加
- Done を選択します。ARM テンプレート(AzureFunction.json)が自動的にダウンロードされます。ファイルの場所をメモしておいてください。
-
ベンダーのドキュメントの手順に従って ARM テンプレートを展開します。
- Build your own template in editor: オプションを選択します。
-
エディターで AzureFunction.json ファイルを読み込みます。
- Save を選択します。
- 既存の Resource group を選択するか、新しいものを作成します。
注意
XDR は、Azure Function を展開する Subscription ID および Resource Group とは異なる Subscription ID や Resource Group 配下の Storage Account をサポートしています。
- Storage Account Subscription ID — 現在の Subscription ID と異なる場合にのみ変更します。
- Storage Account Resource Group — 現在の Resource Group と異なる場合にのみ変更します。

- Review + Create を選択します。
- Create を選択します。Azure Function の展開が開始されます。
- 展開が完了したら、XDR に戻ります。Azure Storage Account インテグレーションが Cloud API Integrations テーブルに表示されます。
Storage Account をプライベートネットワークに制限する(任意)🔗
注意
このセクションは任意であり、上記のXDR に必要な情報を入力するセクションの手順を完了した後に実施する必要があります。ARM テンプレートは常にパブリックネットワークアクセスを有効にした状態で Function App を展開します。つまり、最初からプライベートな VNet 専用状態に直接展開する方法はありません。Storage Account のトラフィックをパブリックインターネット経由にしない必要がない場合は、上記のステップ 12 で終了できます。このセクションは必須ではありません。
Function App は Storage Account を 2 つの目的で使用します。1 つは監視対象のデータソースとして、もう 1 つは Function App 自身に必要なバックエンドストレージ(host keys、trigger tracking、content)としてです。現在はいずれの用途も Storage Account のパブリックエンドポイントに依存しているため、プライベートネットワークの変更を行う前に、まずパブリックネットワーク経由でインテグレーションを展開し、正常に動作することを確認する必要があります。
以下の変更をサポートするのは、Basic または Premium の Azure Function Service Plan Type のみです。Dynamic プランで展開した場合、このセクションは適用されません。
前提条件🔗
- 既存の Azure 仮想ネットワーク(VNet)とサブネット。これは、パブリックインターネットではなく内部ネットワーク経由で Function App を Storage Account に接続するために使用します。既存の VNet/サブネットを使用するか、新しく作成してください。詳細は、ベンダーの Azure Functions networking options ドキュメント、またはガイダンスとしてこの walkthrough on using a Blob trigger with a private endpoint を参照してください。
- 上記のXDR に必要な情報を入力するセクションで展開され、パブリックネットワーク経由で正常に動作することが確認済みの Function App。
手順🔗
-
既存の仮想ネットワークが利用できない場合は、仮想ネットワークを作成します。必要に応じてサブネットを作成するか、デフォルトのサブネットを使用します。

仮想ネットワークの作成 -
Function App で Networking に移動し、インバウンド接続とアウトバウンド接続の両方で仮想ネットワークを使用するようにします。Storage account へのアクセスは引き続き storage account key を使用します。

Storage Account のネットワーク設定 -
環境変数として
WEBSITE_CONTENTOVERVNETを1に設定し、Function App の content-share トラフィックを仮想ネットワーク経由にします。変数を保存すると、Function App は自動的に再起動します。これは次のステップの前に実施する必要があります。そうしないと、パブリックアクセスを無効にした時点で Function App が自身に必要なストレージへアクセスできなくなります。
Storage Account の環境変数 -
Storage Account のパブリックネットワークアクセスを無効にし、仮想ネットワーク経由でのみ到達可能にします。この特定の構成変更専用のベンダーの手順書はありません。最も近い参考資料は、Microsoft の Configure anonymous read access for containers and blobs 記事です。

プライベートネットワーク経由のアクセス -
プライベートネットワーク経由でもすべてが想定どおりに動作していることをテストします。Test/Run を使用してコンテナ内に存在するファイルを呼び出し、Function App をトリガーします。ログを確認し、ファイルアップロードが想定どおりに機能することを確認してください。

Function のテスト
既知の問題🔗
- "Basic" Azure Function Service Plan Type と B2 または B3 Azure Function Service Plan code では、Azure Function Service Plan Num Workers の最大数は 3 です。