このページのトピック
Azure VNetにデプロイする
このページでは、Azure Virtual Network (VNet) を使用してAzure Stackをプライベートネットワークにデプロイする方法について詳しく説明します。このガイドで説明されている手順に従うことで、すべてのAzure Stackリソースをプライベートネットワーク環境に安全にデプロイできます。
はじめに
リソースの最高レベルのセキュリティを確保するために、システムのさまざまなコンポーネントに合わせたいくつかの対策を実装しました。
- Function App: すべての受信トラフィックをクローズし、アウトバウンドトラフィックのVNet統合を有効にしました。つまり、Function Appは仮想ネットワークの一部であるリソースとのみ通信できるため、外部ソースからの不正アクセスを防止できます。
- Service Bus and Storage Account: セキュリティをさらに強化するために、ほとんどのパブリックエンドポイントを閉鎖し、Service BusおよびStorage Account用のプライベートエンドポイントを作成します。プライベートエンドポイントは、プライベートネットワークからのアクセスのみを許可し、リソースへの外部アクセスを防ぎます。
- Application Insights and Log Analytics workspace: デプロイには、Application Insights and Log Analytics workspaceへのパブリックネットワークアクセスを制御できるパラメータが含まれています。パブリックネットワークアクセスを無効にする場合は、それらのリソースをAzure Monitor Private Link Scope (AMPLS) に追加することを強くお勧めします。これにより、許可されたソースからのみログが取り込まれ、クエリが実行されるようになり、不正アクセスからデータが保護されます。
- Key Vaultは、FSSライセンスと検索設定を保存するために必要であり、トレンドマイクロのバックエンドからアクセスできる必要があります。これには、パブリックネットワークからのアクセスが必要です。
- Storage StackのService Busは、保護されたストレージアカウントからイベントBlobCreatedおよびBlobRenamedをフェッチするためにEvent Gridによって使用されます。 Event GridではVNetへのメッセージ送信がサポートされていないため、Service Busはパブリックネットワークに接続したままにする必要があります。
VNetを使用するStackをVNetを使用しないStackにアップデートすることはできません。また、その逆も同様です。つまり、VNetを使用してStackをデプロイした場合、以降のアップデートでVNetの構成を削除することはできません。同様に、VNetなしでStackをデプロイした場合、以降のアップデートでVNetの構成を追加することはできません。StackでVNetを使用するかどうかを変更するには、Stackを削除して再度デプロイする必要があります。
前提条件
Azure Virtual Network (VNet) を使用してプライベートネットワークにAzure Stacksシステムをデプロイする前に、前提条件となるいくつかの手順を完了する必要があります。これらの手順は、Azure Stacksリソースをプライベートネットワーク環境に安全にデプロイするために不可欠です。
サポートされているAzureリージョン
リージョン別の利用可能な製品 のドキュメントに示されているように、VNet、Private Link、プライベートDNSゾーンなどのリソースがサポートされているリージョンを含め、サービスは 複数のAzureリージョン でサポートされています。
VNetとサブネット
Azure Stackをデプロイする前に、次の4つのサブネットを含むVNetを作成する必要があります。
- Scanner機能アプリサブネット
- BLOBリスナー機能 アプリサブネット
- 検索後処理 タグ機能 アプリサブネット
- プライベートエンドポイントサブネット
最初の3つのサブネットは、Azure Function Appの機能であるVNet統合を使用します。これにより、Azure Stacksの機能をVNetと統合できます。予想されるスケールアウトワーカーの数に対応するには、各サブネットに十分な数の使用可能なIPアドレスが必要です。たとえば、各Function Appワーカーには2つのIPアドレスが必要なため、使用可能なIP数は最大スケールアウト数の2倍に設定する必要があります。さらに、「Integrating your app with a Azure virtual network」によると、少なくとも16個の使用可能なIPアドレスを提供する/28サブネットを予約することをお勧めします。
プライベートエンドポイントサブネットには、基本的なAll-in-one Stackで使用可能なIPアドレスを9つ以上用意することをお勧めします。複数のStorage Stackがある場合は、Storage Stackごとに5つの追加のIPアドレスが必要です。したがって、使用可能なIPの数は、9よりも大きく、追加のStorage Stackに必要な追加のIPアドレスの数を足した数である必要があります。
さらに、Azureでは、すべてのサブネットの最初と最後の4つのIPアドレスが自動的に予約され、合計5つのIPアドレスが予約されます。したがって、サブネットごとに追加で5つのIPアドレスを割り当てる必要があります。詳細については、「Azure Virtual Networkに関するよくある質問 (FAQ)」を参照してください。
次の表に従って、サブネットを設定してください。
| サブネット | Scanner Stackで使用可能なIP | Storage Stackで使用可能なIP | 予約済みIP番号 | IPアドレスの総数 | 最小推奨値 |
|---|---|---|---|---|---|
| Scanner機能アプリサブネット | 2 x Scannerのスケールアウト数 (初期設定=1) | 該当なし | 5 | 2 x 1 + 5 = 7 | /28 |
| BLOBリスナー機能 アプリサブネット | 該当なし | 2 x BLOBリスナーのスケールアウト数 (初期設定=1) | 5 | 2 x 1 + 5 = 7 | /28 |
| 検索後処理 タグ機能 アプリサブネット | 該当なし | 2 x 検索後処理タグのスケールアウト数 (初期設定=1) | 5 | 2 x 1 + 5 = 7 | /28 |
| プライベートエンドポイントサブネット | ストレージアカウント用に3つ、Service Bus用に1つ | ストレージアカウント用に4つ、Service Bus用に1つ | 5 | (3+1) + (4+1) + 5 = 14 | /27 |
Azure Stack内のリソースは、保護されたストレージアカウントと相互に通信する必要があるため、作成するサブネットが相互にアクセスできることを確認してください。
Azureでは、Function Appの統合を同じリージョンにデプロイされたVNetにのみ制限します。したがって、Azure StackがVNetと同じリージョン内にデプロイされていることを確認してください。
Azure CLIを使用して関数アプリのサブネットを作成するには、次のコマンドを使用します。
az network vnet subnet create \
--name <function-app-subnet-name> \
--resource-group <application-resource-group-name> \
--vnet-name <vnet-name> \
--address-prefixes <address-prefixes> \
--delegations Microsoft.Web/serverFarms
Azure CLIを使用してプライベートエンドポイントのサブネットを作成するには、次のコマンドを使用します。
az network vnet subnet create \
--name <private-endpoint-subnet-name> \
--resource-group <application-resource-group-name> \
--vnet-name <vnet-name> \
--address-prefixes <address-prefixes>
保護されたストレージアカウント
プライベートネットワークアクセスのみを許可するストレージアカウントにAzure Stackがアクセスできるようにするには、プライベートエンドポイントまたはサービスエンドポイントを介したStackのネットワークからのアクセスを許可する必要があります。
プライベートエンドポイント は、ネットワークインタフェースを使用して仮想ネットワークをプライベートリンクサービスに接続する、より安全なオプションです。これにより、仮想ネットワーク内のIPアドレスを介してストレージアカウントにアクセスできるようになります。一方、サービスエンドポイント では、特定のサブネットからのトラフィックが公共のインターネットを経由せずにストレージアカウントにアクセスできます。
セキュリティを強化するために、プライベートエンドポイントを使用することをお勧めします。特に、ストレージアカウントがプライベート接続のみを受け入れる場合や、パブリックIPをブロックするファイアウォールがある場合は、この機能を使用することをお勧めします。Stackは、前のセクションで説明した Scanner Function App Subnet Blob Listener Function App Subnetおよび Post Scan Action Tag Function App Subnet から保護されたストレージアカウントにアクセスします。これらのサブネットが保護されたストレージアカウントにアクセスできることを確認してください。アクセスできない場合、検索は失敗します。
Event GridシステムトピックはVNetをサポートしていません。 BLOBイベントをサブスクライブするには、次のAzure CLIコマンドを使用して、信頼できるAzureサービスのトラフィックをバイパスする必要があります。
az storage account update \
--resource-group <resource_group_name> \
--name <protected_storage_account_name> \
--bypass AzureServices
プライベートDNSゾーン
プライベートエンドポイントが正しいリソースに接続できるようにするには、プライベートDNSゾーンのDNS設定を正しく構成する必要があります。
プライベートDNSゾーンを準備するには、特定の名前でゾーンを作成し、対象のVNetにリンクする必要があります。リソースエンドポイントを対応するプライベートエンドポイントのプライベートIPアドレスにマップするレコードは、Azure Stackのデプロイプロセス中に自動的に作成されます。プライベートDNSゾーンの設定方法の詳細については、「AzureプライベートエンドポイントのDNS設定」を参照してください。
保護対象リソースには、次のプライベートDNSゾーンが必要です。
- ストレージアカウントBLOB: privatelink.blob.core.windows.net
- ストレージアカウントファイル: privatelink.file.core.windows.net
- ストレージアカウントテーブル: privatelink.table.core.windows.net
- サービスバス: privatelink.servicebus.windows.net
Azure CLIを使用してプライベートDNSゾーンを作成するには、次のコマンドを使用します。
az network private-dns zone create \
--resource-group <platform-resource-group-name> \
--name privatelink.blob.core.windows.net
az network private-dns zone create \
--resource-group <platform-resource-group-name> \
--name privatelink.file.core.windows.net
az network private-dns zone create \
--resource-group <platform-resource-group-name> \
--name privatelink.table.core.windows.net
az network private-dns zone create \
--resource-group <platform-resource-group-name> \
--name privatelink.servicebus.windows.net
Azure CLIを介してプライベートDNSゾーンをVNetにリンクするには、次のコマンドを使用します。
az network private-dns link vnet create \
--registration-enabled false \
--name <link-name> \
--resource-group <platform-resource-group-name> \
--virtual-network <target-vnet-resource-id> \
--zone-name privatelink.blob.core.windows.net
az network private-dns link vnet create \
--registration-enabled false \
--name <link-name> \
--resource-group <platform-resource-group-name> \
--virtual-network <target-vnet-resource-id> \
--zone-name privatelink.file.core.windows.net
az network private-dns link vnet create \
--registration-enabled false \
--name <link-name> \
--resource-group <platform-resource-group-name> \
--virtual-network <target-vnet-resource-id> \
--zone-name privatelink.table.core.windows.net
az network private-dns link vnet create \
--registration-enabled false \
--name <link-name> \
--resource-group <platform-resource-group-name> \
--virtual-network <target-vnet-resource-id> \
--zone-name privatelink.servicebus.windows.net
Azure Monitor Private Linkのスコープ (オプション)
Azure Monitor Private Link Scopes (AMPLS) は、プライベートエンドポイントを使用してプライベートネットワーク内からAzure Monitorのログとメトリックに安全にアクセスできるようにするサービスです。つまり、データは保護され、公共のインターネットを経由することはありません。
プライベートネットワークからAzure StacksのApplication Insightsログデータにアクセスするには、 Azure Monitor Private Linkのスコープと、対象のVNetに接続するための対応するプライベートエンドポイントを作成する必要があります。 AMPLSの設定手順の詳細については、「プライベートリンクの設定」を参照してください。 Azure Stackのデプロイが完了したら、Application InsightsリソースをAMPLSに追加できます。これにより、ログデータにはプライベートネットワーク内からのみアクセスできるようになります。
VNetがAzure Monitor Private Linkのスコープにリンクされている場合は、ログが失われないように、対応するApplication Insightsリソースをスコープに追加することが重要です。必要なリソースをスコープに追加しないと、Azureのネットワーク状況によってログが失われる可能性があります。
Azure Stackをデプロイする
Azure StackをVNetにデプロイするには、前のセクションで作成したリソースを使用してテンプレートパラメータを満たす必要があります。必要な9つのパラメータは次のとおりです。
| パラメータ | タイプ | 説明 | 例 |
|---|---|---|---|
| リソースID | string |
Azure StackがデプロイされるVNetのリソースID。 | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/virtualNetworks/{vnetName} |
| Scannerのサブネット名 | string |
Scanner Function Appをデプロイするサブネットの名前。 | c1fss-scanner |
| BLOBリスナーのサブネット名 | string |
BlobListener Function Appがデプロイされるサブネットの名前。 | c1fss-blob-listener |
| 検索後処理タグ サブネット名 | string |
PostScanActionTag Function Appを配置するサブネットの名前。 | c1fss-post-scan-action-tag |
| プライベートエンドポイントのサブネット名 | string |
プライベートエンドポイントがデプロイされるサブネットの名前。 | c1fss-private-endpoints |
| ファイルプライベートDNSZoneリソースID | string |
ストレージアカウントファイルサービスを解決するプライベートDNSゾーンのリソースID。 | /subscriptions/{subscriptionId}/resourceGroups/platform-rg/providers/Microsoft.Network/privateDnsZones/privatelink.file.core.windows.net |
| BLOBプライベートDNSZoneリソースID | string |
ストレージアカウントBLOBサービスを解決するプライベートDNSゾーンのリソースID。 | /subscriptions/{subscriptionId}/resourceGroups/platform-rg/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net |
| テーブルプライベートDNSZoneリソースID | string |
ストレージアカウントテーブルサービスを解決するプライベートDNSゾーンのリソースID。 | /subscriptions/{subscriptionId}/resourceGroups/platform-rg/providers/Microsoft.Network/privateDnsZones/privatelink.table.core.windows.net |
| Service BusのプライベートDNSZoneリソースID | string |
Service Busを解決するプライベートDNSゾーンのリソースID。 | /subscriptions/{subscriptionId}/resourceGroups/platform-rg/providers/Microsoft.Network/privateDnsZones/privatelink.servicebus.windows.net |
| Application Insightの制限付きアクセス | boolean |
Application Insightsへのパブリックアクセスを無効にするかどうかを指定します。 trueに設定した場合、アプリケーションインサイトログには、 Azure Monitor Private Linkのスコープを介してのみアクセスできます。 | true |
デプロイを続行する前に、各パラメータの値を確認してください。
Azure Stackの設定
Azure Stackをデプロイしたら、データの保護を開始する前に構成する必要があります。必要な2つの主要なタスクがあります。
Azure StacksのApplication InsightをAzure Monitor Private Linkのスコープに追加する
ログにパブリックネットワークが含まれていて、デプロイパラメータ Restricted Access For Application Insight が falseであることを示している場合は、このセクションを無視してください。
Application Insightsへのアクセスをセキュリティで保護するために、Application InsightsをAzure Monitor Private Linkのスコープに追加できます。これにより、Application Insightsログへのアクセスが、Private Link Scopeにアクセスできるユーザのみに制限されます。プライベートリンクのスコープにApplication Insightsを追加するには、次の手順を実行します。
- Azure portalで、[Azure Monitor Private Link Scopes] に移動します。
- [Configure] セクションで、[Azure Monitorリソース] をクリックします。
- [Add] をクリックします。
- [Stacks Application Insights] を選択します。
- [Apply] をクリックします。
または、次のコマンドを使用することもできます。
az monitor private-link-scope scoped-resource create \
--linked-resource <TARGET_APPLICATION_INSIGHT_RESOURCE_ID> \
--name <SCOPED_RESOURCE_NAME> \
--resource-group <AMPLS_RESOURCE_GROUP> \
--scope-name <AMPLS_NAME>
Stackのログにプライベートネットワークからアクセスできるようにするには、少なくとも3つのApplication InsightsリソースをAzure Monitor Private Linkの範囲に追加する必要があります。Scanner Stackの場合、Application InsightsのリソースIDはデプロイ出力に ScannerApplicationInsightResourceIDとして表示されます。Storage Stackの場合、Application InsightsのリソースIDは、デプロイ出力から BlobListenerApplicationInsightsResourceID および ActionTagApplicationInsightsResourceIDとして確認できます。接続方法の詳細については、「Azure Monitorリソースの接続」を参照してください。
Azure Stackを削除する前に、まずAzure Monitor Private Link Scope (AMPLS) とApplication Insightsの間の関連付けを削除する必要があります。そうしないと、削除プロセスでエラーが発生する可能性があります。関連付けを削除するには、Azure portalまたはAzure CLIを使用して、スコープからApplication Insightsリソースを削除します。
ファイアウォール(オプション)
通常、VNetトラフィックはAzure FirewallまたはNetwork SecurityGroup (NSG) によって保護されます。 NSGではFQDNフィルタがサポートされていないため、 Azure Firewallを使用してトラフィックを制御することをお勧めします。 Azure Stackがスムーズに実行されるように、適切なファイアウォール設定を行うことが重要です。
完全修飾ドメイン名 (FQDN) によるトラフィックの制御は、ネットワークルールとアプリケーションルールの2種類のファイアウォールルールでサポートされています。ネットワークルールを使用してこれを実現する場合は、最初にDNSプロキシを有効にする 必要があります。ただし、AzureではHTTP/Sトラフィックにアプリケーションルールを使用することをお勧めします。HTTP/Sトラフィックにはアプリケーションルールの方が適しているためです。 FQDNフィルタのアプリケーションルールとネットワークルールの違いの詳細については、AzureのWebサイトで「ネットワークルールでFQDNフィルタリング」を参照してください。
サードパーティのサービスとの通信
サードパーティのサービスとの通信を許可するには、次のアプリケーションルールをファイアウォールの許可リストに追加する必要があります。
| 名前 | ソースの種類 | ソース | プロトコル:ポート | 対象の完全修飾ドメイン名 | 説明 |
|---|---|---|---|---|---|
| C1FSSトレンド | IPアドレス | <Scanner-subnet> | https:443 | filestorage.us-1.cloudone.trendmicro.com | FQDNはC1リージョンによって異なります |
| Trend C1FSS ICRC | IPアドレス | <Scanner-subnet> | https:443 | c1fss1.icrc.trendmicro.com | |
| Trend Micro C1FSS IAU | IPアドレス | <Scanner-subnet> | https:443 | ipv6-iaus.trendmicro.com | |
| Trend C1fss IAU Active | IPアドレス | <Scanner-subnet> | https:443 | ipv6-iaus.activeupdate.trendmicro.com | |
| AWS S3 | IPアドレス | <scanner-subnet><blob-listener-subnet><post-scan-action-tag-subnet> | https:443 | file-storage-security.s3.amazonaws.com | |
| Scanner Azure Management | IPアドレス | <Scanner-subnet> | https:443 | management.azure.com |
Scanner StackのKeyVaultの設定
Scanner Stackには、パブリックネットワークに残っている2つのKeyVaultがあります。 Scanner Function AppがこれらのScannerにアクセスできない場合、検索は失敗します。したがって、KeyVaultをホワイトリストに追加する必要があります。
アプリケーションルールからホワイトリストの対象FQDNを設定できます。このルールは、スキャナのデプロイ出力ScannerLicenseKeyVaultURI および ScannerConfigKeyVaultURIに表示されます。
| 名前 | ソースの種類 | ソース | プロトコル:ポート | 対象の完全修飾ドメイン名 |
|---|---|---|---|---|
| ScannerのKey Vault | IPアドレス | <Scanner-subnet> | https:443 | <scanner-license-keyvault>.vault.azure.net、<scanner-config-keyvault>.vault.azure.net |
または、ネットワークルールからのサービスタグのホワイトリストを設定できます。これは、より簡単な方法ですが、対象のすべてのKeyVaultへのトラフィックを許可します。
| 名前 | プロトコル | ソースの種類 | ソース | サービスタグ | 送信先ポート |
|---|---|---|---|---|---|
| Key Vaults | TCP | IPアドレス | <Scanner-subnet> | AzureKeyVault または AzureKeyVault.<region> | 443 |
Application Insightの設定
Azure Monitor Private Link Services (AMPLS) を使用していない場合は、Application Insightsに次のファイアウォールルールを追加する必要があります。送信先のFQDNの値については、「AzureプライベートエンドポイントのDNS設定に関するドキュメント」および「Azure Monitorで使用するIPアドレス」を参照してください。
| 名前 | ソースの種類 | ソース | プロトコル:ポート | 対象の完全修飾ドメイン名 |
|---|---|---|---|---|
| Application Insights | IPアドレス | <scanner-subnet><blob-listener-subnet><post-scan-action-tag-subnet> | https:443 | <region>.in.applicationinsights.azure.com, <region>.livediagnostics.monitor.azure.com |
ネットワークの問題が発生した場合のトラブルシューティングに役立てるため、ファイアウォールログを有効にすることを強くお勧めします。ファイアウォールの設定については、「Azure Firewallのログとメトリックを監視する」のドキュメントを参照してください。
Azure Stackのすべてのサブネットが相互に通信できることを確認することが重要です。
まとめ
リソースの保護を強化するために、いくつかのセキュリティ対策を実施しています。サービスアカウントとService Busのパブリックエンドポイントを閉鎖し、プライベートネットワークからのアクセスのみを許可するプライベートエンドポイントを作成しました。 Function Appについては、すべての受信トラフィックが閉じられ、送信トラフィックに対するアウトバウンド統合が有効になりました。さらに、Application Insightsについては、 Azure Monitor Private Link Scopes (AMPLS) と統合して、許可されたソースからのみログを取り込み、クエリを実行できるようにしました。