Overview
Azure エンクレーブは、最も機密性の高いミッション ワークロードに対して、セキュリティで保護され、分離され、準拠しているクラウド環境のデプロイと管理を高速化し、合理化するAzure サービスです。
コミュニティは、ガバナンス、管理、接続、監視のためにエンクレーブを安全かつ論理的にグループ化する分離されたハブ ネットワーク基盤を提供します。 コミュニティ所有者は、コミュニティ エンドポイントとトランジット ハブを介して、他のコミュニティまたはオンプレミス ネットワークへの接続を有効にすることができます。
このチュートリアルでは、8 つのパート 1 で、Azure ポータルで Azure エンクレーブ コミュニティを作成します。 このシリーズの後のチュートリアルでは、 エンクレーブ、 エンクレーブ エンドポイント、 エンクレーブ接続を作成します。
このチュートリアルでは、次の操作を行います。
- コミュニティ アーキテクチャとアドレス空間を計画します。
- エンクレーブ向けのコミュニティをデプロイする。
- ハブアンドスポーク トポロジの利点について説明します。
- コミュニティのデプロイ、接続リソース、監視、アクセスを検証します。
- 不要になったコミュニティをクリーンアップします。
前提条件
- 必要なネットワーク、ファイアウォール ポリシー、および監視リソースのクォータを持つAzure サブスクリプション。
- ターゲット サブスクリプションまたはリソース グループ内のリソースを作成および管理するためのアクセス許可:
- 投稿者
- ユーザー アクセス管理者 (ロールの割り当てを作成または更新する必要がある場合)
- Azure ネットワーク、Azure リソース グループ、プライベート IP アドレスの計画に関する基本的な知識。
- オプションの検証コマンドを実行する場合は、Azure CLI または Azure PowerShell がインストールされている必要があります。
始める前の準備
コミュニティの計画
コミュニティを作成する前に、次の重要な計画の側面を検討してください。
アドレス空間の計画
計画されているすべてのエンクレーブに必要な IP 領域の合計を計算します。
- エンクレーブ数の見積もり: 現在のニーズに加えて、20 から 30% の増加を計画する
- 必要な領域を計算する: 各エンクレーブには通常、/16 ~ /24 CIDR が必要です
- 重複を回避する: オンプレミス ネットワークやその他のAzure環境との重複を防ぐ
- 慎重に計画する: コミュニティとエンクレーブに必要な IP アドレス空間を決定する
計算例:
- /16 CIDR を持つ 5 つのエンクレーブを計画する (それぞれ 65,536 IP、合計 327,680 IP)
- 最小コミュニティ CIDR: /12 (合計 1,048,576 IP)
- 推奨: 拡張バッファーの場合は /11 または /10
アドレス空間のサイズに関する推奨事項:
| 展開サイズ | エンクレーブ数 | 推奨される CIDR | 使用可能な IP 数 |
|---|---|---|---|
| 小さい | 1-3 エンクレーブ | /14 | 262,144 |
| Medium | 4-10 エンクレーブ | /12 | 1,048,576 |
| Large | 11-25 エンクレーブ | /11 | 2,097,152 |
| エンタープライズ | 26+ エンクレーブ | /10 | 4,194,304 |
Tip
Azure IP アドレス計算ツールを使用して、アドレス空間を計画します。
名前付け規則
デプロイ前に名前付け標準を確立します。
推奨される名前付けパターン:
- 形式:
<organization>-<environment>-<purpose> - 例:
-
contoso-prod-main- 本番コミュニティ -
fabrikam-dev-sandbox- 開発コミュニティ -
northwind-test-validation- テスト コミュニティ
-
名前付けに関するその他の考慮事項:
- 名前を簡潔にする (3 ~ 24 文字)
- 小文字とハイフンを使用する
- 特殊文字を使用しないようにする
- チーム リファレンスのドキュメントの名前付け規則
リージョンの選択
次に基づいてAzureリージョンを選択します。
データ所在地の要件:
- 規制に対するコンプライアンス
- データ主権の要件
- 業界固有の規制
サービスの可用性:
- リージョンAzureエンクレーブの可用性を確認する
- 必要なAzureサービスが利用可能であることを確認する
- プレビュー機能と GA 機能を検討する
パフォーマンスとコスト:
- ユーザーとの近接性による待機時間の短縮
- ネットワーク エグレス コスト
- リージョン別のAzure価格のバリエーション
ディザスター リカバリー:
- 必要に応じてセカンダリ リージョンの計画を立てる
- Azure DR のペアリージョンを検討する
アーキテクチャの考慮事項
ハブアンドスポーク トポロジ
コミュニティはハブとエンクレーブを作成し、ハブアンドスポーク ネットワーク トポロジのスポークを作成します。このトポロジには、いくつかのアーキテクチャ上の利点があります。
ハブ (コミュニティ) コンポーネント:
- マネージド リソース グループ: コミュニティをサポートする Azure マネージド リソース
- 接続リソース: コミュニティ ハブのVirtual WANおよび関連する接続リソース
- ファイアウォール ポリシー: トラフィック ガバナンスのための一元化されたルール ポリシーとルール コレクション
- 一元的なログ記録: 構成可能なログ記録と監視リソース
- ポリシーの適用: 一元的なガバナンスとコンプライアンスの制御
スポーク (エンクレーブ) コンポーネント:
- 分離された仮想ネットワーク: エンクレーブごとにネットワーク境界を分離する
- ワークロード リソース: アプリケーション固有のAzure リソース
- ネットワーク セキュリティ グループ: サブネット レベルのセキュリティ制御
- プライベート エンドポイント: Azure PaaS サービスへのセキュリティで保護された接続
ハブアンドスポーク トポロジの利点:
| 給付金 | Description |
|---|---|
| ネットワークの分離 | 各エンクレーブは独立したアドレス空間で分離されます |
| 一元化されたセキュリティ | トラフィック検査とポリシー適用のための単一ポイント |
| コストの最適化 | 共有インフラストラクチャ (ファイアウォール、VPN ゲートウェイ) によってコストが削減される |
| 簡素化された管理 | 一元的な監視とガバナンス |
| スケーラビリティ | 既存のエンクレーブに影響を与えずに新しいエンクレーブを簡単に追加 |
| 制御された接続 | エンクレーブ間トラフィックには明示的なエンクレーブ接続が必要 |
既定のセキュリティ
コミュニティには、複数のセキュリティ レイヤーが用意されています。
ネットワーク セキュリティ:
- Azure Firewallを使用した分離されたネットワーク境界
- 既定でネットワーク トラフィックを拒否する
- コミュニティ エンドポイントとエンクレーブ エンドポイントを介した明示的な許可ルール
- 監査とコンプライアンスのためのネットワーク トラフィック ログ
ガバナンスとコンプライアンス:
- 一元化されたAzure Policyの適用
- 組み込みのコンプライアンス フレームワーク
- 承認を含むポリシー除外ワークフロー
- すべての管理操作の監査ログ
アクセス制御:
- 管理操作のためのジャストインタイム (JIT) アクセス
- 一時的な特権アクセス向けのメンテナンス モード
- ロールベースのアクセス制御 (RBAC) の統合
- マネージド ID のサポート
監視と可観測性:
- Log Analytics ワークスペースの統合
- メトリックとアラートのAzure Monitor
- Azure Firewall 脅威インテリジェンス
- ネットワーク フロー ログと診断
アーキテクチャ ダイアグラム
次の図は、コミュニティから始まり、後のチュートリアルでエンクレーブとワークロードを追加するエンクレーブ環境Azure例を示しています。
Azure エンクレーブでコミュニティを作成する
リソース グループを準備する
コミュニティを作成する前に、リソース グループが必要です。 Azure リソース グループは、Azure リソースのデプロイと管理に使用する論理コンテナーです。
Important
このチュートリアルでは、リソース グループ名のプレースホルダーとして myResourceGroup を使用します。 必要に応じて、名前付け規則に従って、 myResourceGroup を独自のリソース グループ名に置き換えることができます。
リソース グループのベスト プラクティス:
- 目的と環境を示すわかりやすい名前を使用する
- 組織とコストの追跡にタグを適用する
- 適切な RBAC アクセス許可が割り当てられていることを確認する
- リソース グループの場所を検討する (コミュニティ リージョンと一致する必要がある)
コミュニティをデプロイする
コミュニティのデプロイが完了するまでに約 30 ~ 45 分 かかります。 Azureエンクレーブは、コミュニティ リソースを作成し、接続、ファイアウォール ポリシー、監視のためのマネージド リソースをサポートします。
手順 1: Azure エンクレーブに移動する
Azure Enclave ページで、左側のメニューのCommunitiesを選択します。
手順 2: コミュニティの作成を開始する
[ Communities ] ページで、[ Create] を選択します。
手順 3: コミュニティ設定を構成する
コミュニティの基本的な詳細を入力します。
基本的な構成:
-
Subscription: Azure サブスクリプションを選択します -
Resource Group:myResourceGroup(または新規作成) -
Community name:cmt-fabrikam(または名前付け規則を使用) -
Region:East US(要件に基づいて選択) -
Community address space:10.0.0.0/16
構成パラメーターについて:
| パラメーター | Description | Guidance |
|---|---|---|
| サブスクリプション | リソースの課金先となる Azure サブスクリプション | 適切なクォータでサブスクリプションを使用する |
| リソース グループ | コミュニティ リソースの論理コンテナー | 新規作成または既存の使用 |
| コミュニティ名 | コミュニティの一意の識別子 | 名前付け規則 (3 ~ 24 文字) に従う |
| リージョン | Azureのデプロイメント用リージョン | 作成後に変更できない |
| アドレス空間 | コミュニティのプライベート IP 範囲 | RFC 1918 に準拠している必要があります。将来の拡張を見据えて計画してください。 |
アドレス空間のガイダンス:
プライベート IP アドレス範囲 (RFC 1918):
-
10.0.0.0/8- クラス A (16,777,216 アドレス) -
172.16.0.0/12- クラス B (1,048,576 アドレス) -
192.168.0.0/16- クラス C (65,536 アドレス)
このチュートリアルの場合:
-
10.0.0.0/16を使用すると、65,536 個の IP アドレスが提供されます - 中程度のサイズのサブネットを持つ 3 ~ 5 個のエンクレーブに十分
- 将来的な拡張に備えて、本番環境ではより大きな CIDR(たとえば /14 や /12)を検討してください
他のタブを確認できますが、このチュートリアルでは既定値をそのまま使用します。
- 既定のファイアウォールを選択したままにする
- エンクレーブ用の専用ハブを作成しない
- 既定のポリシー管理を維持する
- 既定の監視とログ記録の設定を保持する
- コミュニティ管理に他のユーザーを追加しない
- メンテナンス モードを維持する
Off
次に[ Approvals ]タブを選択します。
手順 4: 承認
このチュートリアルでは、エンクレーブ接続の作成と更新の承認のみが必要です。 コミュニティの基本的な詳細を入力します。
承認の構成:
-
Connection creation:Requiredを選択し、1にMinimum number of approversを入力します。 -
Connection updates:Requiredを選択し、1にMinimum number of approversを入力します。
Note
これらの承認の選択は、最後に作成したリソースで承認がどのように機能するかを示すためだけに用意されています。 この構成は、運用環境の構成を表していません。
手順 5: 確認して作成する
Review + create選択し、コミュニティの詳細が正しいことを検証します。
検証チェック:
- サブスクリプションとリソース グループが正しいことを確認する
- 名前付け規則に従ってコミュニティ名を確認する
- リージョンが要件を満たしていることを確認する
- アドレス空間が適切なサイズであり、重複していないことを確認する
- 検証の警告またはエラーを確認する
手順 6: 作成
Createを選択してデプロイを開始します。
デプロイ中の動作:
デプロイ プロセスでは、次のものが作成されます。
- Virtual Network: コミュニティ アドレス空間を備えたハブ仮想ネットワーク
- Azure Firewall: トラフィック フィルター処理用の Premium レベルまたは Standard レベル
- ファイアウォール ポリシー: 既定の規則とポリシー
- Log Analytics ワークスペース: 監視と診断用
- マネージド リソース グループ: Azureマネージド インフラストラクチャが含まれています
- 診断設定: ログとメトリックの構成
- ネットワーク セキュリティ グループ: 既定のセキュリティ規則
デプロイの進行状況の監視:
- Azureポータルの通知でデプロイメントステータスを追跡
- 問題が発生した場合にデプロイ ログを確認する
- 推定時間: 30 ~ 45 分
- 状態に "実行中" が表示され、[成功] が表示されます
デプロイを検証する
コミュニティのデプロイが完了したら、これらの検証手順を実行して、すべてが正しく構成されていることを確認します。
手順 1: コミュニティの状態を確認する
確認する主な情報:
- プロビジョニング状態: "Succeeded" である必要があります
- リソース グループ: 表示されている正しいリソース グループ
- 場所: 選択したリージョンと一致します
- アドレス空間: 正しい CIDR が表示される
- マネージド リソース グループ: 自動的に作成
手順 2: ネットワーク構成を確認する
- コミュニティの概要で、
Managed Resource Groupを選択します。 - 作成されたリソースを確認します。
マネージド リソース グループに必要なリソース:
- マネージド ID
- Log Analytics ワークスペース
- Virtual WANおよび関連する接続リソース
- ファイアウォール ポリシーと規則の収集リソース
- 診断設定 (該当する場合)
マネージド接続リソースを確認します。
- マネージド リソース グループに移動します。
- 予想される接続とファイアウォール ポリシー リソースが作成されたことを確認します。
- 構成されたアドレス空間がコミュニティ計画と一致していることを確認します。
手順 3: RBAC とアクセスを確認する
- コミュニティの
Access control (IAM)に移動する - ロールの割り当てを確認する
想定されるロール:
- ユーザー アカウントには適切なアクセス許可が必要です
- サブスクリプション/リソース グループから継承されたアクセス許可を確認する
- コミュニティ管理のアクセス許可に対して行った割り当てを確認する
検証チェックリスト
デプロイ後、次の内容を確認します。
- コミュニティの状態が [成功] と表示される
- 想定されるリソースで作成されたコミュニティ マネージド リソース グループ
- 適切なアドレス空間で構成されたマネージド接続リソース
- 作成されたファイアウォール ポリシーとルール コレクション
- 接続された Log Analytics ワークスペース
- 診断設定が有効になっている
- RBAC アクセス許可が構成されている
- アクティビティ ログにデプロイ エラーがない
リソースをクリーンアップする
このチュートリアルを完了した後にコミュニティを削除する必要がある場合:
Warning
コミュニティの削除は 永続的 であり、 元に戻すことはできません。 関連付けられているエンクレーブ、ワークロード、およびマネージド リソースは、コミュニティ削除プロセスの一環として削除できます。 コミュニティを削除する前に、依存リソースを確認します。
削除する前に:
- 重要な構成またはデータをエクスポートする
- 参照用にネットワーク設定を記録する
- チーム メンバーに計画的な削除を通知する
- 依存関係 (仮想ネットワーク ピアリング、接続) を削除する
コミュニティを削除するには:
Azure ポータルで Azure エンクレーブに移動する
左側のメニューから、
Communitiesを選びます。削除するコミュニティを選択します(例:
cmt-fabrikam)。上部のメニューから
Deleteを選択するコミュニティ名を入力して削除を確認する
Deleteを選択
Azure CLIによる代替削除:
# Delete community (replace with your values)
az resource delete \
--resource-group myResourceGroup \
--resource-type Microsoft.Mission/communities \
--name fabrikam \
--api-version 2025-05-01-preview
削除される内容:
- コミュニティ リソース
- コミュニティ内の関連付けられたエンクレーブ
- 関連付けられているワークロードと空のワークロード リソース グループ
- マネージド リソース グループとサービスマネージド リソース
- ファイアウォール ポリシーと関連する規則コレクション リソース
- ログ分析ワークスペース (共有されていない場合)
保持される内容:
- リソース グループ (他のリソースが含まれている場合)
- Azure エンクレーブによって管理されていないリソース
- ログ分析データ (保持設定に基づく)
Troubleshooting
問題: アドレス空間の重複エラーが発生してデプロイが失敗する
症状: アドレス空間の競合に関するエラー メッセージが表示され、デプロイが失敗する
考えられる原因:
- アドレス空間がサブスクリプション内の既存の仮想ネットワークと重複している
- アドレス空間がオンプレミス ネットワークと競合する
- アドレス空間が仮想ネットワーク ピアリング接続と重複している
解決手順:
- サブスクリプション内の既存の VNet を確認します。
az network vnet list --output table - 重複しない別の CIDR ブロックを選択する
- ハイブリッド接続を使用しているかどうかをネットワーク チームで確認する
- 新しいアドレス空間を使用してデプロイを再開する
防止: 割り当てられたすべての範囲を文書化した IP アドレス管理 (IPAM) スプレッドシートを維持する
問題: デプロイに予想以上に時間がかかる
症状: 60 分以上実行されているデプロイ
考えられる原因:
- 負荷が高い Azure リージョン
- 複雑なファイアウォール ポリシーの構成
- リソース プロバイダーの登録の遅延
解決手順:
- サービス正常性の問題について Azure の状態ページを確認する
- アクティビティ ログでデプロイ ログを確認する
- デプロイが 90 分を超える場合は、Azure サポートにお問い合わせください
- 明示的に通知されない限り、デプロイを取り消さないでください
防止: 可能な場合はピーク外の時間帯にデプロイする
問題: デプロイ後にコミュニティにアクセスできない
症状: ポータルでコミュニティがデプロイされたがアクセスできない
考えられる原因:
- RBAC アクセス許可の不足
- アクセスをブロックする条件付きアクセス ポリシー
- マネージド リソース グループのアクセス許可の問題
解決手順:
- コミュニティに閲覧者または共同作成者の役割があることを確認する
- Microsoft Entra IDで条件付きアクセス ポリシーを確認する
- サブスクリプション管理者にアクセス権を要求する
- ブラウザーのキャッシュをクリアして再試行する
防止: デプロイを開始する前に、適切な RBAC 割り当てを確認する
ヘルプを受ける
問題が引き続き発生する場合:
- Azure エンクレーブのトラブルシューティング ガイド: トラブルシューティング ガイドを確認する
- ログの確認: アクティビティ ログでエラー メッセージを確認する
- Azureドキュメント: Azure エンクレーブのドキュメントとAzureエンクレーブに関する FAQ を確認する
-
サポートに問い合わせる: 次の方法でサポート チケットを作成します。
- サブスクリプション ID
- コミュニティ リソース ID
- デプロイ イベントのタイムライン
- エラー メッセージとスクリーンショット
- デプロイ相関 ID
コミュニティ コストについて
コミュニティのAzure計算ツールの見積もりを作成します。
コスト最適化のヒント:
- 開発/テストに Standard レベルのファイアウォールを使用する
- ログ保持ポリシーを適切に構成する
- リソースの監視と適切なサイズ設定
- 追跡にMicrosoft Cost Managementを使用する
次のステップ
おめでとうございます! Azure エンクレーブ コミュニティが正常にデプロイされました。
次のチュートリアルでは、ワークロードをホストするためにコミュニティ内に分離されたエンクレーブを作成する方法について説明します。