AzureにはActive Directory構造があります。最上位レベルの構造は組織であり、その下にディレクトリ（Azureテナントとも呼ばれます）があります。ディレクトリ内には、1つ以上のAzureサブスクリプションを設定できます。

特定のAzureコンポーネント間の関係は次のとおりです。

テナントサブスクリプションリソースグループリソース > > >

それぞれの説明は次のとおりです。

• 1つのテナントは複数のサブスクリプションを持つことができますが、各サブスクリプションは1つのテナントにのみ属することができます。

• 1 つのサブスクリプションに複数のリソースグループを含めることができますが、各リソースグループは 1 つのサブスクリプションにのみ属することができます。

• 1 つのリソースグループは複数のリソースを持つことができますが、各リソースは 1 つのサブスクリプションにのみ属することができます。

次のセクションでは、これらのコンポーネントについて詳しく説明します。

• Azure とコンポーネントのマッピングCloud APIC

• Azureサブスクリプションについて

• テナントとアイデンティティについて

テナントとアイデンティティについて

Azureおよびで使用できるさまざまなタイプのテナントとIDを次に示します。Cloud APIC

（注）	リリース5.2（1）より前のリリースでは、管理対象アイデンティティのみがインフラテナントのアクセスタイプとしてサポートされ、管理対象アイデンティティとサービスプリンシパルの両方がユーザテナントのアクセスタイプとしてサポートされていました。 リリース5.2（1）以降、マネージドアイデンティティとサービスプリンシパルの両方が、インフラテナントとユーザテナントのアクセスタイプとしてサポートされるようになりました。

マネージドアイデンティティ

マネージドアイデンティティは、Azure AD認証をサポートするリソースに接続するときに使用するアプリケーションのアイデンティティを提供します。アプリケーションは管理対象IDを使用してAzure ADトークンを取得できます。たとえば、開発者が安全な方法でクレデンシャルを保存したり、ストレージアカウントにアクセスしたりするために、アプリケーションでマネージドアイデンティティを使用してAzure KeyVaultなどのリソースにアクセスできます。https://docs.microsoft.com/en-us/azure/key-vault/general/overview

管理対象IDを使用する利点は次のとおりです。

• クレデンシャルにはアクセスできないため、クレデンシャルを管理する必要はありません。

• マネージドIDを使用して、独自のアプリケーションを含むAzure AD認証をサポートする任意のリソースを認証できます。

• マネージドIDは追加コストなしで使用できます。

Azureの管理対象アイデンティティの詳細については、以下を参照してください。

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

管理対象アイデンティティを使用してでテナントを設定する場合は、Azureポータルとで次の設定を行います。Cloud APICCloud APIC

1. Azureポータルで、仮想マシンのロール割り当てを追加します。このオプションは、Azureサブスクリプションが（同じ組織の）同じAzureディレクトリにある場合に使用します。

   （注）	Azureサブスクリプションが異なるディレクトリにあり、マネージドIDを使用してテナントを設定する場合は、Azureコンソールに移動し、各サブスクリプションをクリックして同じAzureディレクトリの下にサブスクリプションを移動できます。これは、（異なるサブスクリプションを含む）ディレクトリが同じ親組織の子である場合にのみ実行できます。

2. Cloud APIC では、Cloud APIC でテナントを構成するときに [管理対象アイデンティティ（Managed Identity）] オプションを選択します。

これらの構成の詳細については、Cisco Cloud APIC GUIを使用したテナントの作成 を参照してください。

サービス プリンシパル（Service Principal）

Azureサービスプリンシパルは、Azureリソースにアクセスするためのアプリケーション、ホステッドサービス、および自動化ツールで使用するために作成されたIDです。異なるサブスクリプションでテナントを設定する場合は、サービスプリンシパルIDを使用します。サブスクリプションが同じ組織内の異なる Azure ディレクトリ（Azure テナント）にあるか、サブスクリプションが異なる組織にある可能性があります。

サービスプリンシパルを使用してでテナントを設定する場合は、Azureポータルとで次の設定を行います。Cloud APICCloud APIC

1. Azureポータルで、アプリケーションのロール割り当てを追加します。この場合、クラウドリソースは特定のアプリケーションを介して管理されます。

2. では、テナントを設定するときに [サービスプリンシパル（Service Principal）] オプションを選択します。Cloud APICCloud APICこのページに入力するサブスクリプションは、同じ組織内の異なるAzureディレクトリ（Azureテナント）に配置することも、異なる組織に配置することもできます。

これらの構成の詳細については、Cisco Cloud APIC GUIを使用したテナントの作成 を参照してください。

共有テナント

Azureサブスクリプションを上記の2つの方法のいずれかにすでに関連付けており、そのサブスクリプションにさらにテナントを作成する場合は、このオプションを選択します。

でテナントを共有テナントとして設定する場合は、Azureポータルとで次の設定を行います。Cloud APICCloud APIC

1. 上記の2つの方法のいずれかでAzureサブスクリプションをすでに関連付けているため、Azureで共有テナント専用の設定を行う必要はありません。共有テナントでは、既存のサブスクリプションにさらにテナントを作成します。

2. では、テナントを設定するときに[共有（Shared）]オプションを選択します。Cloud APICCloud APIC

これらの構成の詳細については、Cisco Cloud APIC GUIを使用したテナントの作成 を参照してください。

CCR は、仮想およびクラウド環境で包括的な WAN ゲートウェイとネットワークサービスを提供します。CCR により、企業はWANをプロバイダーがホストするクラウドに拡張できます。Cisco Cloud APIC ソリューションには 2 つの CCR が必要です。

Cisco Cloud APIC で使用する CCR のタイプは、リリースによって異なります。

• リリース 25.2(3) よりも前のリリースでは、Cisco Cloud Services Router 1000v が Cisco Cloud APIC で使用されるCSRです。この CCR のタイプに関する詳細は、『Cisco Cloud Services Router 1000v マニュアル』を参照してください。

• リリース 25.0(3) 以降、Cisco Cloud APIC では Cisco Catalyst 8000V が使用されます。この CCR のタイプに関する詳細は、『Cisco Catalyst 8000V Edge ソフトウェア マニュアル』を参照してください。

リリース 5.1(2) で導入されたクラウド サービス EPG は、クラウド ネイティブまたはサードパーティのサービス インスタンスまたはエンドポイントのコレクションを含む名前付き論理構成体である管理対象オブジェクトです。この場合、エンドポイントは特定のサービス インスタンスを指します。たとえば、SQL サーバーはエンドポイントと見なされ、SQL サーバーのコレクションはサービスエンドポイント グループを形成します。サービス EPG の他の例としては、ストレージ アカウントのコレクション、Key Vault のコレクションなどがあります。

サービス EPG には、いくつかの固有の属性があります。

• サービス タイプ：この属性は、グループ化されているクラウド サービスのタイプを示します。利用可能なサービスの種類の例には、Azure SQL、Azure Containter Registery、Azure ApiManagement Services などがあります。サービス タイプ Customは、サードパーティ サービス EPG を構成するときに使用されます。

• 展開タイプ：この属性は、サービスを展開する方法と場所を示します。 以下は使用可能な展開タイプです。

  • クラウド ネイティブ：このタイプの展開では、サービスはクラウドプロバイダーのネットワークでインスタンス化され、サービスを使用するユーザまたはアプリケーションはサービスを管理します。たとえば、Azure ストレージ アカウントが Azure 独自の VNet 内に存在する場合があり、ストレージ コンテンツにアクセスするための URL があります。

  • クラウド ネイティブ管理対象：このタイプの展開では、サービスは VNet またはサブネットでインスタンス化されます（Cisco Cloud APIC を介して作成されます）。たとえば、Azure Kubernetes cluster（AKS）は、Cisco Cloud APIC によって管理されるサブネットに展開できます。

  • サードパーティ：これは、サードパーティ（Azure 以外）が市場を通じてサービスを提供している展開です。このサービスへのアクセスは、プライベートリンク機能を通じて提供されます。

• アクセス タイプ：サービスへのアクセス方法を示します。使用可能なアクセス タイプは次のとおりです。

  • パブリック：サービスには、割り当てられたパブリック IP アドレスを使用してアクセスできます。特定のサービスのパブリック IP アドレス範囲へのアクセスは、NSG ルールの Azure「サービスタグ」を使用して行います。

  • プライベート：割り当てられているプライベート IP アドレスを使用して、サービスにアクセスできます。この割り当ては、展開が Cloud Native および Third Party の場合、プライベート エンドポイントの作成を通して行われます。Cloud Native Managed 展開の場合、プライベート IP はサービスによってサブネット IP スペースから割り当てられます。

  前の箇条書きで説明したように、特定の展開タイプ、および各展開タイプ内の特定のアクセス タイプのみが各サービスの種類でサポートされます。次の表は、各サービスの種類でサポートされている展開の種類とアクセスの種類の詳細を示しています。

  サービスタイプ	プロバイダー	展開タイプ/アクセス タイプ
  		クラウドネイティブ	クラウド ネイティブ管理対象	サードパーティ製の
  Azure Storage Blob	Microsoft.Storage	プライベート	N/A	N/A
  Azure SQL	Microsoft.Sql	パブリック（Public） プライベート（Private）	N/A	N/A
  Azure Cosmos DB	Microsoft.DocumentDB	パブリック（Public） プライベート（Private）	N/A	N/A
  Azure Databricks	Microsoft.Databricks	パブリック（Public）	プライベート（Private） パブリックとプライベート	N/A
  Azure Storage	Microsoft.Storage	パブリック（Public） プライベート（Private）	N/A	N/A
  Azure Storage ファイル	Microsoft.Storage	プライベート	N/A	N/A
  Azure Storage キュー	Microsoft.Storage	プライベート	N/A	N/A
  Azure Storage テーブル	Microsoft.Storage	プライベート	N/A	N/A
  Azure Kubernetes Services（AKS）	Microsoft.ContainerService	プライベート	プライベート パブリックとプライベート	N/A
  Azure Active Directory ドメイン サービス	Microsoft.AAD	パブリック（Public）	プライベート（Private） パブリックとプライベート	N/A
  Azure Container レジストリ	Microsoft.ContainerRegistry	パブリック（Public） プライベート（Private）	N/A	N/A
  Azure ApiManagement サービス	Microsoft.ApiManagement	パブリック（Public）	プライベート（Private） パブリックとプライベート	N/A
  Azure Key Vault	Microsoft.KeyVault	パブリック（Public） プライベート（Private）	N/A	N/A
  Redis キャッシュ	Microsoft.Cache	N/A	プライベート パブリックとプライベート	N/A
  カスタムサービス		パブリック（Public） プライベート（Private）	N/A	プライベート

• サービスエンドポイント セレクタ： サービスエンドポイントは、既存のセレクタ（クラウド EPG 選択で使用される）と、以下にリストされている新しいタイプのセレクタを使用して選択できます。

  • リソース名：サービス リソースの名前

  • リソース ID：リソースのクラウドプロバイダーの ID

  • URL：サービスを識別するエイリアスまたは FQDN（プライベート リンク エイリアスは Azure で使用されます）

  次の表に、各展開の種類でサポートされているエンドポイント セレクタの詳細を示します。

  （注）	クラウド ネイティブ（パブリック）展開タイプに関する情報は、次の表に記載されていません。展開タイプがエンドポイント セレクタをサポートしていないためです。

  展開タイプ	タグ	地域	IP	リソース名	Resource ID	URL
  クラウド ネイティブ（プライベート）	Y	Y	N	Y	Y	N
  クラウド ネイティブ管理対象	N	N	Y	N	N	N
  サードパーティ製の	N	N	N	N	N	Y（プライベート リンク接続にのみ適用）

コントラクトが作成されると、コントラクトで定義されたルールの一部が統合され、特定の基準に基づいて Azure に表示されます。複数のポートと複数の IP アドレスと範囲を 1 つのわかりやすいルールに組み合わせることができます。ルールの統合の基準は次のとおりです。

• ルールは、コントラクト内でのみ統合されます。2 つの異なるコントラクトに起因する 2 つのルールは、Azure に統合されません。

• 送信元/宛先アドレス プレフィックスと宛て先ポートが統合されます。

• 複数のルールを NSG に統合するための条件は次のとおりです。

  • 同一コントラクト

  • 同じプロトコル（UDP、TCP、ICMP）

  • 同じ方向（インバウンド、アウトバウンド）

  • 同型（SG、IP）

• 同一コントラクト内の同一プロトコル（TCP/UDP）の重複するポート範囲は 1 つに集約します。

  たとえば、TCP ポート 100 ～ 200、150 ～ 250 は 100 ～ 250 に統合されます。

• 1.2.3.4/32（任意のアドレスプレフィックス）が許可され、0.0.0.0/0 の拡張 EPG が追加された場合、許可される送信元/宛先 IP は [1.2.3.4/32, 0.0.0.0/0] ではなく任意になります。

以下の例は、コントラクト C1 および C2 に基づく、EPG1 アウトバウンド ルールと統合された EPG1 アウトバウンド ルールを示しています。

Contract C1:
Consumer: EPG1 , Provider: EPG2
Filter: TCP  (ports 53)
Filter: UDP (port 53, 5000)

Contract C2:
Consumer: EPG1 , Provider: EPG2
Filter: TCP (ports 80, 8080)

EPG1 outbound rules:
EPG1 -> EPG2 		TCP 	80
EPG1 -> EPG2 		TCP 	8080
EPG1 -> EPG2 	      TCP        53
EPG1 -> EPG2 		UDP 	53
EPG1 -> EPG2 		UDP 	5000
EPG1 -> 1.1.1.1/32 	TCP 	80
EPG1 -> 1.1.1.1/32 	TCP 	8080
EPG1 -> 1.1.1.1/32 	TCP 	53
EPG1 -> 1.1.1.1/32 	UDP 	53
EPG1 -> 1.1.1.1/32 	UDP	5000
EPG1 -> 2.2.2.2/32 	TCP 	80
EPG1 -> 2.2.2.2/32 	TCP 	8080
EPG1 -> 2.2.2.2/32 	TCP       53
EPG1 -> 2.2.2.2/32 	UDP 	53
EPG1 -> 2.2.2.2/32 	UDP 	5000

Rules are consolidated by comma-separated filters (consolidated based on C1 and C2): 
EPG1 -> EPG2 				TCP	 80,8080  
EPG1 -> EPG2 				UDP 	53,5000  
EPG1 -> EPG2 				TCP	 53	
EPG1 -> 1.1.1.1/32, 2.2.2.2/32 	 TCP 	80,8080	
EPG1 -> 1.1.1.1/32, 2.2.2.2/32 	 UDP 	53,5000	
EPG1 -> 1.1.1.1/32, 2.2.2.2/32 	 TCP 	53		

サブジェクトおよびフィルタの管理対象オブジェクトにより、さまざまなアプリケーションまたはサービスの提供要件を満たすためのクラウド EPG とコントラクト間の混合と照合が可能になります。次の図は、管理情報ツリー（MIT）内のアプリケーション サブジェクトおよびフィルタの場所と、テナント内の他のオブジェクトとの関係を示します。

コントラクトには、複数の通信ルールを含めることができ、複数のクラウド EPG は複数のコントラクトを消費および提供できます。ポリシーの設計者は、複雑な通信ポリシーを簡潔に表し、アプリケーションの複数のインスタンス間でこれらのポリシーを再利用できます。

（注）	サブジェクトは Cisco Cloud APIC で非表示になり、設定できません。Azure にインストールされているルールの場合、フィルタ エントリで指定された送信元ポートは考慮されません。

サブジェクトおよびフィルタは次のオプションに従ってクラウド EPG 通信を定義します。

• フィルタは、レイヤ 3 ～ レイヤ 4 フィールド、レイヤ 3 プロトコル タイプなどの TCP/IP ヘッダー フィールド、レイヤ 4 ポートなどです。関連するコントラクトに従って、クラウド EPG プロバイダーは、IN および OUT 両方の方向でプロトコルおよびポートを決定します。コントラクトのサブジェクトは、コントラクトを提供する側と消費する側の クラウド EPG の間に適用されるフィルタ（およびその方向）への関連付けが含まれています。

• サブジェクトはコントラクトに含まれています。コントラクト内のサブジェクトがフィルタを使用して、通信できるトラフィックのタイプと発生の仕方を指定します。たとえば、HTTPS メッセージの場合、サブジェクトはその方向と許可される IP アドレス タイプ（たとえば IPv4）、HTTP プロトコル、およびポートを指定するフィルタを指定します。サブジェクトは、フィルタを単方向にするか双方向にするかを決定します。単方向フィルタは 1 方向で使用されます。単方向フィルタは、IN または OUT の通信を定義しますが、両方に対して同じではありません。双方向フィルタは両方に対して同じで、IN および OUT の通信を定義します。

• Azure 構造体でレンダリングされる ACI コントラクトは常にステートフルであり、リターン トラフィックを許可します。