Azure エンクレーブには、ミッション クリティカルな環境のセキュリティで保護され、スケーラブルで一元的な監視をサポートする、組み込みの監視機能が用意されています。 これらの機能は、コミュニティ マネージャーとエンクレーブ所有者がコンプライアンスを強制し、異常を調査し、分離されたワークロード全体で運用の正常性を確保するのに役立ちます。
Azure エンクレーブ リソースでは、以下が既定で有効になっています。
- Log Analytics ワークスペースは、既定でコミュニティ マネージド リソース グループにデプロイされます
- (省略可能)Log Analytics ワークスペースがエンクレーブ マネージド リソース グループにデプロイされる
- ストレージ アカウントがエンクレーブ マネージド リソース グループにデプロイされる
- 各エンクレーブの仮想ネットワーク フロー ログが有効化され、エンクレーブのストレージ アカウントが指定され、コミュニティおよび/またはエンクレーブの Log Analytics ワークスペースに転送されます
- 診断設定は、コミュニティとエンクレーブの両方のマネージド リソース グループにデプロイされたリソースで有効になります
一元化された分離された可観測性
Azure エンクレーブの可観測性は、Azure Monitor、Log Analytics、ストレージ アカウントを使用した一元的な診断ログ記録とエンクレーブ分離診断ログの両方をサポートするデュアル層ログ モデルに基づいて構築されています。
コミュニティ レベルの可観測性
Azureエンクレーブで作成されたすべてのコミュニティには、一元化されたLog Analyticsワークスペースが含まれています。 このワークスペースは、次の目的で設計されています。
- コミュニティ内のすべてのエンクレーブから診断とメトリックを集計します。
- 診断ログとフローログの監視とクエリの実行を単一の画面で行えるようにします。
- クロスエンクレーブ分析、アラート、コンプライアンス追跡をサポートします。
コミュニティが作成されると、ワークスペースが自動的に作成されます。 ワークスペースは、デプロイまたは更新操作中にエンクレーブまたはワークロード所有者が診断先として選択できます。 コミュニティ Log-A ワークスペースのパブリック アクセスは無効になっていますが、既定ではネットワーク分離されません。 パブリック アクセスまたはネットワークの分離を構成するには、 プライベート リンクのセキュリティを追加することを検討してください。
Note
エンクレーブ リソース (ワークロード、パブリック IP、Application Gateway など) からの診断設定は、統合された監視をサポートするために一元化されたワークスペースにログを送信するように構成できます。
エンクレーブ単位の可観測性
コミュニティ ワークスペースに加えて、各エンクレーブは、そのエンクレーブ専用の分離されたLog Analytics ワークスペースでプロビジョニングされます。 このワークスペースは、エンクレーブ レベルのログ記録のユース ケース用に最適化されており、次の特性が含まれています。
- Virtual Network フロー ログの既定のストレージ。各エンクレーブに対して自動的に有効になります。
- 内部ワークロードやネットワーク コンポーネントなど、エンクレーブ スコープ リソースのオプションの診断設定。
- クロスエンクレーブ ログの集計を防ぐ分離または規制の要件を満たすように設計されています。
管理者は、この分離されたワークスペースにのみログを送信することで、エンクレーブ診断を非公開にすることを選択できます。
設定可能なログ出力先
Azure エンクレーブでは、リソース所有者が次のいずれかを選択できる柔軟なログ構成がサポートされています。
| ログ出力先 | Purpose | 既定の使用 |
|---|---|---|
| コミュニティ Log Analytics ワークスペース | 一元的な監視とクロスエンクレーブ分析を有効にする | Optional |
| Enclave Log Analytics ワークスペース | エンクレーブ レベルの分離とデータ主権を維持する | 仮想ネットワーク フロー ログの既定値 |
診断設定は、デプロイ中またはデプロイ後に、Azure ポータル、CLI、または Bicep/ARM テンプレートを使用して構成できます。
Important
仮想ネットワーク フロー ログは、分離された環境でもネットワーク レベルでの可視性を維持できるよう、既定では常にエンクレーブ固有のワークスペースに送信されます。
一般的な可観測性のシナリオ
| シナリオ | ログ記録戦略 |
|---|---|
| クロスエンクレーブ正常性ダッシュボード | すべてのエンクレーブから一元化されたコミュニティ Log Analytics ワークスペースに診断を送信する |
| 厳密なデータ制御による規制されたエンクレーブ | エンクレーブ固有のLog Analytics ワークスペース内に診断を保持する |
| 監査目的での長期保有 | ポリシーによって制御される保持設定を使用してストレージ アカウントにログを送信する |
| ネットワーク調査または脅威ハンティング | エンクレーブ ワークスペースを使用して既定の仮想ネットワーク フロー ログを分析する |
Network Watcher のリソース グループを構成する
仮想ネットワーク フロー ログの作成に関する潜在的な問題を回避するには、NetworkWatcherRG リソース グループを事前に手動で設定し、Mission Enclave アプリにそのリソース グループのOwner ロールを割り当てるか、サブスクリプションに最初のエンクレーブを作成する前に、セットアップとロールの割り当てが自動的に発生したことを確認します。
この潜在的な問題を軽減するには、サブスクリプションごとに、新しいサブスクリプションで NetworkWatcherRG という名前の NetworkWatcher リソース グループを手動で作成し、NetworkWatcherRG で Mission Enclave Azure エンクレーブ アプリ Ownerを付与します。
NetworkWatcherRGリソース グループを選択し、Access control (IAM)を選択してから、Addを選択してAdd role assignmentします。
Privileged administrator roles選択し、ownerを選択してから、Nextを選択します。
Select members選択し、検索に「Mission Enclave」と入力し、Mission Enclaveアプリを選択し、Selectを選択してから、Nextします。
サブスクリプションに条件が必要な場合は、[
Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended)] を選択し、[Review + assign] を選択します。
更新が完了したら、エンクレーブ リソースAzureデプロイを開始できます。
コミュニティまたはエンクレーブが作成されると、Azureエンクレーブは次の手順を試みます。
-
NetworkWatcherRGが存在するかどうかを確認します。 そうでない場合は、そのリソース グループの作成を試みます。 -
NetworkWatcherRGにMission Enclaveアプリの永続的なOwner割り当てがあるかどうかを確認します。 そうでない場合は、NetworkWatcherRGの永続的なOwner割り当てとしてMission Enclaveアプリを割り当てるようにします。 継承されたOwnerアクセス許可が存在する場合でも、永続的なOwner割り当ての作成が試行されます。 - いずれかの手順が失敗した場合、仮想ネットワーク フロー ログを作成しようとしたときにエンクレーブデプロイが失敗する可能性があります。