ACI ファブリック ネットワーク アクセス セキュリティ ポリシー モデル（コントラクト）
ACI のファブリック セキュリティ ポリシー モデルはコントラクトに基づいています。このアプローチにより、従来のアクセス コントロール リスト（ACL）の制限に対応できます。コントラクトには、エンドポイント グループ間のトラフィックで適用されるセキュリティ ポリシーの仕様が含まれます。
次の図は、 コントラクトのコンポーネントを示しています。
EPG 通信にはコントラクトが必要です。EPG/EPG 通信はコントラクトなしでは許可されません。値は、 [APIC] は、コントラクトや関連する EPG などのポリシー モデル全体を各スイッチの具象モデルにレンダリングします。入力時に、ファブリックに入るパケットはすべて、必要なポリシーの詳細でマークされます。EPG の間を通過できるトラフィックの種類を選択するためにコントラクトが必要とされるので、コントラクトはセキュリティ ポリシーを適用します。コントラクトは、従来のネットワーク設定でのアクセス コントロール リスト（ACL）によって扱われるセキュリティ要件を満たす一方で、柔軟性が高く、管理が容易な、包括的なセキュリティ ポリシー ソリューションです。
アクセス コントロール リストの制限
従来のアクセス コントロール リスト（ACL）には、ACI ファブリック セキュリティ モデルが対応する多数の制限があります。従来の ACL は、ネットワーク トポロジと非常に強固に結合されています。それらは通常、ルータまたはスイッチの入力および出力インターフェイスごとに設定され、そのインターフェイス、およびそれらのインターフェイスを流れることが予期されるトラフィックに合わせてカスタマイズされます。このカスタマイズにより、それらは多くの場合インターフェイス間で再利用できません。もちろんこれはルータまたはスイッチ間にも当てはまります。
従来の ACL は、非常に複雑で曖昧です。なぜなら、そのリストには、許可された特定の IP アドレス、サブネット、およびプロトコルのリストと、明確に許可されていない多くのものが含まれているためです。この複雑さは、問題が生じるのを管理者が懸念して ACL ルールを削除するのを躊躇するため、維持が困難で、多くの場合は増大するだけということを意味します。複雑さは、それらが通常 WAN と企業間または WAN とデータセンター間の境界などのネットワーク内の特定の境界ポイントでのみ配置されていることを意味します。この場合、ACL のセキュリティのメリットは、エンタープライズ内またはデータセンターに含まれるトラフィック向けには生かされません。
別の問題として、1 つの ACL 内のエントリ数の大幅増加が考えられます。ユーザは多くの場合、一連の送信元が一連のプロトコルを使用して一連の宛先と通信するのを許可する ACL を作成します。最悪のケースでは、 N の送信元が M の接続先と K 種のプロトコルを使用して通信している場合、 N*M*K 行の設定が ACL に必要となる可能性があります。ACL は、プロトコルごとに各宛先と通信する各送信元を一覧表示する必要があります。また、それほど多くのデバイスやプロトコルがなくても、ACL は非常に大きくなります。
ACI ファブリック セキュリティ モデルは、これらの ACL の問題に対応します。ACI ファブリック セキュリティ モデルは、管理者の意図を直接表します。管理者は、連絡先、フィルタ、およびラベルの管理対象オブジェクトを使用してエンドポイントのグループがどのように通信するかを指定します。これらの管理対象オブジェクトは、ネットワークのトポロジに関連していません。なぜなら、それらは特定のインターフェイスに適用されないためです。それらは、エンドポイントのこれらのグループの接続場所に関係なく、ネットワークが強要しなければならない簡易なルールです。このトポロジの独立性は、これらの管理対象オブジェクトが特定の境界ポイントとしてだけではなくデータセンター全体にわたって容易に配置して再利用できることを意味します。
ACI ファブリック セキュリティ モデルは、エンドポイントのグループ化コンストラクトを直接使用するため、サーバーのグループが相互に通信できるようにするための概念はシンプルです。1 つのルールにより、任意の数の送信元が同様に任意の数の宛先と通信することを可能にできます。このような簡略化により、そのスケールと保守性が大幅に向上します。データセンター全体でより簡単に使用できることにもなります。
セキュリティ ポリシー仕様を含むコントラクト
ACI セキュリティ モデルでは、コントラクトに EPG 間の通信を管理するポリシーが含まれます。コントラクトは通信内容を指定し、EPG は通信の送信元と宛先を指定します。コントラクトは次のように EPG をリンクします。
EPG 1 --------------- コントラクト --------------- EPG 2
コントラクトで許可されていれば、EPG 1 のエンドポイントは EPG 2 のエンドポイントと通信でき、またその逆も可能です。このポリシーの構造には非常に柔軟性があります。たとえば、EPG 1 と EPG 2 間に多くのコントラクトが存在すること、1 つのコントラクトを使用する EPG が 3 つ以上存在すること、コントラクトを複数の EPG のセットで再利用することが可能です。
また EPG とコントラクトの関係には方向性があります。EPG はコントラクトを提供または消費できます。コントラクトを提供する EPG は通常、一連のクライアント デバイスにサービスを提供する一連のエンドポイントです。そのサービスによって使用されるプロトコルはコントラクトで定義されます。コントラクトを消費する EPG は通常、そのサービスのクライアントである一連のエンドポイントです。クライアント エンドポイント（コンシューマ） がサーバー エンドポイント（プロバイダー） に接続しようとすると、コントラクトはその接続が許可されるかどうかを確認します。特に指定のない限り、そのコントラクトは、サーバーがクライアントへの接続を開始することを許可しません。ただし、EPG 間の別のコントラクトが、その方向の接続を簡単に許可する場合があります。
この提供/消費の関係は通常、EPG とコントラクト間を矢印を使って図で表されます。次に示す矢印の方向に注目してください。
EPG 1 <------- 消費 -------- コントラクト <------- 提供 -------- EPG 2
これらの同じ構造は、仮想マシンのハイパーバイザを管理するポリシーにも適用されます。EPG が Virtual Machine Manager（VMM）のドメイン内に配置されると、APIC は EPG に関連付けられたすべてのポリシーを VMM ドメインに接続するインターフェイスを持つリーフ スイッチにダウンロードします。VMM ドメインの詳細については、 Virtual Machine Managerドメイン の章（ アプリケーション セントリック インフラストラクチャの基本）を参照してください。このポリシーが作成されると、APIC は EPG のエンドポイントへの接続を可能にするスイッチを指定する VMM ドメインにそれをプッシュ（事前入力）します。VMM ドメインは、EPG 内のエンドポイントが接続できるスイッチとポートのセットを定義します。エンドポイントがオンラインになると、適切な EPG に関連付けられます。パケットが送信されると、送信元 EPG および宛先 EPG がパケットから取得され、対応するコントラクトで定義されたポリシーでパケットが許可されたかどうかが確認されます。許可された場合は、パケットが転送されます。許可されない場合は、パケットはドロップされます。
コントラクトは 1 つ以上のサブジェクトで構成されます。各サブジェクトには 1 つ以上のフィルタが含まれます。各フィルタには 1 つ以上のエントリが含まれます。各エントリは、アクセス コントロール リスト（ACL） の 1 行に相当し、エンドポイント グループ内のエンドポイントが接続されているリーフ スイッチで適用されます。
詳細には、コントラクトは次の項目で構成されます。
-
名前：テナントによって消費されるすべてのコントラクト（共通テナントまたはテナント自体で作成されたコントラクトを含む）にそれぞれ異なる名前が必要です。
-
サブジェクト：特定のアプリケーションまたはサービス用のフィルタのグループ。
-
フィルタ：レイヤ 2 ～ レイヤ 4 の属性（イーサネット タイプ、プロトコル タイプ、TCP フラグ、ポートなど） に基づいてトラフィックを分類するために使用します。
-
アクション：フィルタリングされたトラフィックで実行されるアクション。次のアクションがサポートされます。
-
トラフィックの許可（通常のコントラクトのみ）
-
トラフィックのマーク（DSCP/CoS）（通常のコントラクトのみ）
-
トラフィックのリダイレクト（サービス グラフによる通常のコントラクトのみ）
-
トラフィックのコピー（サービス グラフまたは SPAN による通常のコントラクトのみ）
-
トラフィックのブロック（禁止コントラクトのみ）
Cisco APIC リリース 3.2(x) および名前が EX または FX で終わるスイッチでは、標準コントラクトで代わりにサブジェクトの拒否アクションまたはコントラクトまたはサブジェクトの除外を使用して、指定のパターンを持つトラフィックをブロックできます。
-
トラフィックのログ（禁止コントラクトと通常のコントラクト）
-
-
エイリアス：（オプション）変更可能なオブジェクト名。オブジェクト名は作成後に変更できませんが、エイリアスは変更できるプロパティです。
このように、コントラクトによって許可や拒否よりも複雑なアクションが可能になります。コントラクトは、所定のサブジェクトに一致するトラフィックをサービスにリダイレクトしたり、コピーしたり、その QoS レベルを変更したりできることを指定可能です。具象モデルでアクセス ポリシーをあらかじめ入力すると、APIC がオフラインまたはアクセスできない場合でも、エンドポイントは移動でき、新しいエンドポイントをオンラインにでき、通信を行うことができます。APIC は、ネットワークの単一の障害発生時点から除外されます。ACI ファブリックにパケットが入力されると同時に、セキュリティ ポリシーがスイッチで実行している具象モデルによって適用されます。
フィルタ エントリの設定
このセクションでは、次のフィルタエントリ構成オプションについて説明します。
-
フラグメントのみとマッチ
-
DSCP とマッチ
-
TCP フラグ
-
ステートフル
-
ポート ゼロ エントリ
各フィルタには、1 つ以上のフィルタエントリを含めることができます。これは [テナント（Tenant）] > [コントラクト（Contract）] > [フィルタ（Filters）] > [Filter_name]にあります。各フィルタエントリの構成場所は [テナント（Tenant）] > [コントラクト（Contract）] > [フィルタ（Filters）] > [Filter_name] > [Filter_entry_name]です。
部分的にのみ一致
[フラグメントにのみマッチング（Match Only Fragments）] オプションは、オフセットが 0 より大きいフラグメント（最初のフラグメントを除くすべてのフラグメント）を照合します。
[フラグメントにのみマッチング（Match Only Fragments）] オプションは、デフォルトでは無効になっています。これは、デフォルトではフィルタ構成がすべてのパケット（すべてのフラグメントを含む）に適用されることを意味します。したがって、デフォルトでは、フィルタにマッチするすべてのパケットを、コントラクトアクションに基づいて許可、ドロップ、コピー、リダイレクトすることができます。[フラグメントにのみマッチング（Match Only Fragments）] オプションが有効になっている場合、フィルタ構成は最初のフラグメントを除くすべてのフラグメントに適用されます。
 （注） |
TCP/UDP ポート情報は、最初のフラグメントでのみチェックできます。 |
次にいくつか例を示します。
-
許可コントラクトの IP フィルタで [フラグメントにのみマッチング（Match Only Fragments）] が無効になっている場合（デフォルト）、すべてのフラグメントを含むすべての IP パケットが許可されます。
-
許可コントラクトに [フラグメントにのみマッチング（Match Only Fragments）] が有効になっている IP フィルタがある場合、オフセットが 0 より大きい IP フラグメント（最初のフラグメントを除くすべての IP フラグメント）のみが許可されます。そのようなわけで、別の許可コントラクトがない限り、最初のフラグメントは暗黙の拒否ルールによってドロップされます。
-
許可コントラクトに特定の TCP ポートフィルタ（接続先 TCP ポート 80 など）があり、その許可コントラクトで [フラグメントにのみマッチング（Match Only Fragments）] が無効になっている場合（デフォルト ）、特定の TCP ポートにマッチするすべての TCP トラフィックが許可されます。TCPポート情報が最初のフラグメントのみにあるため、別の許可コントラクトがない限り、最初のフラグメント以外のフラグメントは暗黙の拒否ルールによってドロップされます。
-
特定の TCP/UDP ポートフィルタで [フラグメントにのみマッチング（Match Only Fragments）] を有効にするのは、有効な構成の組み合わせではありません。TCP/UDP ポート情報は最初のフラグメントでしかチェックできないのに対し、[フラグメントにのみマッチング（Match Only Fragments）] は、最初のものを除いた、すべてのフラグメントとマッチングを行うようにとの指定だからです。
一致の DSCP
このオプションは、EtherType、IP プロトコル、送信元ポート、宛先ポートに加えて、トラフィックで照合する DSCP（差別化サービスコードポイント、Differentiated Services Code Point）値を指定します。このオプションを使用すると、送信元 EPG、接続先 EPG、フィルタマッチングなどの他のパラメータが同じであっても、パケット内の DSCP 値に応じて異なるアクションを実行できます。このオプションは、デフォルトでは未指定です（Cisco ACI における従来の IOS または NX-OS 用語では、[任意（Any）] に相当します）。これには、「EX」または「FX」以降のリーフノードが必要です。
TCP フラグ
このオプションは、EtherType、IP プロトコル、送信元ポート、宛先ポートに加えて、トラフィックで照合する TCP フラグ値を指定します。使用可能な TCP フラグは次のとおりです。
-
Synchronize：SYN
-
Established: ACK または RST
-
Acknowledgement: ACK
-
Reset: RST
-
Finish: FIN
ステートフル
[ステートフル（Stateful）] オプションは、ACK フラグが設定されている場合にのみ、プロバイダーからコンシューマへの TCP パケットを許可します。このオプションは、デフォルトで無効です。セキュリティを強化するために、TCP フィルタエントリではステートフル オプションを有効にすることを推奨します。ただし、有効にした場合、ポリシー圧縮は適用できないため、 [ポリシー圧縮の有効化（Enable Policy Compression）] が必要な場合は除きます。
コンシューマが特定のプロバイダーの TCP ポートにアクセスできるようにするには、管理者はコンシューマ側の TCP ポート（コントラクト フィルタの送信元ポート構成）をワイド範囲として構成する必要があります。ウェルノウン ポートではない送信元ポートも対応可能にするためです。次の例には、2 つのゾーニング ルールがあります。1 つは任意の送信元 TCP ポートを使用するコンシューマから接続先 TCP ポート 80 を使用するプロバイダーへのトラフィックを許可するルール、もう 1 つは逆方向のルールです。プロバイダーのエンドポイントが送信元 TCP ポート80を使用してコンシューマのエンドポイントに SYN 攻撃を実行した場合でも、トラフィックが ACI ファブリックによって自動的にドロップされることはありません。送信元 TCP ポート 80 を使用するプロバイダーから、任意の宛先 TCP ポートを使用するコンシューマへのトラフィックは、コントラクトによって許可されているからです。
プロバイダーからコンシューマへの通常の TCP パケットが許可される場合、次のようになります。
-
データパケット（3 ウェイハンドシェイク後）：これらのパケットには ACK ビットが設定されているため、リーフ ノードはパケットを許可します。
-
RST パケット：RST パケットにも ACK ビットが設定されているため、リーフノードは RST パケットを許可します。
-
FIN パケット：ACK ビットが設定された FIN パケットは許可されます。ACK のない FIN パケットはドロップされます。ACK のない FIN パケットの処理は、オペレーティング システムのタイプによって異なるため、オペレーティング システムを特定する目的での FIN スキャン攻撃が行われることがあります。このようなパケットをドロップすれば、攻撃を防ぐことができます。
「show zoning-rule」コマンドの CLI 出力は、ステートフルオプションが有効になっているリーフでプログラムされたポリシーの例です。
Pod1-Leaf1# show zoning-rule scope 2850817
+---------+--------+--------+----------+---------+---------+---------+-------------------+----------+----------------------+
| Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority |
+---------+--------+--------+----------+---------+---------+---------+-------------------+----------+----------------------+
| 4250 | 0 | 0 | implicit | uni-dir | enabled | 2850817 | | deny,log | any_any_any(21) |
| 4246 | 0 | 0 | implarp | uni-dir | enabled | 2850817 | | permit | any_any_filter(17) |
| 4208 | 0 | 15 | implicit | uni-dir | enabled | 2850817 | | deny,log | any_vrf_any_deny(22) |
| 4247 | 0 | 32777 | implicit | uni-dir | enabled | 2850817 | | permit | any_dest_any(16) |
| 4222 | 32774 | 32775 | 71 | uni-dir | enabled | 2850817 | tenant1:Contract1 | permit | fully_qual(7) |
| 4244 | 32775 | 32774 | 69 | uni-dir | enabled | 2850817 | tenant1:Contract1 | permit | fully_qual(7) |
+---------+--------+--------+----------+---------+---------+---------+-------------------+----------+----------------------+
これらの行は、EPG Web と EPG アプリ間のコントラクト 1 によって作成されたものです。フィルタ エントリ情報の詳細は、「show zoning-filter filter FilterID」コマンドを使用して確認できます。プロバイダーからコンシューマへの方向で使用されるフィルタ ID 71 には、TcpRules の「ack」があります。
Pod1-Leaf1# show zoning-filter filter 69
+----------+------+--------+-------------+------+-------------+----------+-------------+-------------+-----------+---------+-------+-------------+-------------+----------+
| FilterId | Name | EtherT | ArpOpc | Prot | ApplyToFrag | Stateful | SFromPort | SToPort | DFromPort | DToPort | Prio | Icmpv4T | Icmpv6T | TcpRules |
+----------+------+--------+-------------+------+-------------+----------+-------------+-------------+-----------+---------+-------+-------------+-------------+----------+
| 69 | 69_0 | ip | unspecified | tcp | no | yes | unspecified | unspecified | 22 | 22 | dport | unspecified | unspecified | |
+----------+------+--------+-------------+------+-------------+----------+-------------+-------------+-----------+---------+-------+-------------+-------------+----------+
Pod1-Leaf1# show zoning-filter filter 71
+----------+------+--------+-------------+------+-------------+----------+-----------+---------+-------------+-------------+-------+-------------+-------------+----------+
| FilterId | Name | EtherT | ArpOpc | Prot | ApplyToFrag | Stateful | SFromPort | SToPort | DFromPort | DToPort | Prio | Icmpv4T | Icmpv6T | TcpRules |
+----------+------+--------+-------------+------+-------------+----------+-----------+---------+-------------+-------------+-------+-------------+-------------+----------+
| 71 | 71_0 | ip | unspecified | tcp | no | yes | 22 | 22 | unspecified | unspecified | flags | unspecified | unspecified | ack |
+----------+------+--------+-------------+------+-------------+----------+-----------+---------+-------------+-------------+-------+-------------+-------------+----------+
次のリストは、ステートフル オプションの使用に関連する設計上の重要な考慮事項の一部をまとめたものです。
-
ステートフル オプションは、TCP トラフィックにのみ適用されます。
-
ステートフル オプションは ACK フラグしかチェックしないので、ステートフル ファイアウォールとは異なり、プロバイダーからの SYN + ACK 攻撃は防止できません。
-
[双方向のルール圧縮（Bidirectional rule compression）] は、ステートフルが有効になっている場合、適用できません。
ポート ゼロ エントリ
各フィルタには、1 つ以上のフィルタ エントリを含めることができます。これは [テナント（Tenant）] > [コントラクト（Contract）] > [フィルタ（Filters）] > [Filter_name]にあります。
APIC リリース6.0(4) 以降、ポート ゼロ エントリが導入されました。一般的なフィルタ エントリとポート ゼロ エントリの違いは次のとおりです。
-
一般のフィルタ エントリでポートが「未指定」または「0」に設定されている場合、ポート範囲は「0 ～ 65535」です。
-
ポート ゼロ エントリは、ポート「0」のフィルタ エントリ用です。これは、ポート「0」がインターネット番号割当機関（Internet Assigned Numbers Authority、IANA）によって予約済みポートとして定義されており、使用が想定されていないため、主にこのようなトラフィックを拒否するためのものです。
ポート ゼロ エントリには、次の [方向（Direction）] オプションがあります。
-
[両方向（Direction Both、デフォルト）]：送信元ポート「0」も宛先ポートも「0」。
-
[宛先方向（Direction Destination）]：送信元ポートは「0」、宛先ポートは「すべて」（0 ～ 65535）。
-
[送信元方向（Direction Source）]：送信元ポートは「すべて」（0 ～ 65535）、宛先ポートは「0」。
（注） |
送信元ポート「0」と宛先ポート「80」のフィルタなど、送信元または宛先ポートのいずれかが「0」で、他方を特定のポートに指定しているフィルタ エントリは、汎用フィルタ エントリまたはポート ゼロ エントリではサポートされません。 |
セキュリティ ポリシーの適用
トラフィックは前面パネルのインターフェイスからリーフ スイッチに入り、パケットは送信元 EPG の EPG でマーキングされます。リーフ スイッチはその後、テナント エリア内のパケットの宛先 IP アドレスでフォワーディング ルックアップを実行します。ヒットすると、次のシナリオのいずれかが発生する可能性があります。
-
ユニキャスト（/32）ヒットでは、宛先エンドポイントの EPG と宛先エンドポイントが存在するローカル インターフェイスまたはリモート リーフ スイッチの VTEP IP アドレスが提供されます。
-
サブネット プレフィクス（/32 以外）のユニキャスト ヒットでは、宛先サブネット プレフィクスの EPG と宛先サブネット プレフィクスが存在するローカル インターフェイスまたはリモート リーフ スイッチの VTEP IP アドレスが提供されます。
-
マルチキャスト ヒットでは、ファブリック全体の VXLAN カプセル化とマルチキャスト グループの EPG で使用するローカル レシーバのローカル インターフェイスと外側の宛先 IP アドレスが提供されます。
（注） |
マルチキャストと外部ルータのサブネットは、入力リーフ スイッチでのヒットを常にもたらします。セキュリティ ポリシーの適用は、宛先 EPG が入力リーフ スイッチによって認識されるとすぐに発生します。 |
転送テーブルの誤りにより、パケットがスパイン スイッチの転送プロキシに送信されます。転送プロキシはその後、転送テーブル検索を実行します。これが誤りである場合、パケットはドロップされます。これがヒットの場合、パケットは宛先エンドポイントを含む出力リーフ スイッチに送信されます。出力リーフ スイッチが宛先の EPG を認識するため、セキュリティ ポリシーの適用が実行されます。出力リーフ スイッチは、パケット送信元の EPG を認識する必要があります。ファブリック ヘッダーは、入力リーフ スイッチから出力リーフ スイッチに EPG を伝送するため、このプロセスをイネーブルにします。スパイン スイッチは、転送プロキシ機能を実行するときに、パケット内の元の EPG を保存します。
出力リーフ スイッチでは、送信元 IP アドレス、送信元 VTEP、および送信元 EPG 情報は、学習によってローカルの転送テーブルに保存されます。ほとんどのフローが双方向であるため、応答パケットがフローの両側で転送テーブルに入力し、トラフィックが両方向で入力フィルタリングされます。
マルチキャストおよび EPG セキュリティ
マルチキャスト トラフィックでは、興味深い問題が起こります。ユニキャスト トラフィックでは、宛先 EPG はパケットの宛先の検査からはっきりわかります。一方、マルチキャスト トラフィックでは、宛先は抽象的なエンティティ、マルチキャスト グループです。パケットの送信元はマルチキャスト アドレスではないため、送信元 EPG は以前のユニキャストの例と同様に決定されます。宛先グループの由来は、マルチキャストが異なる場所です。
マルチキャスト グループが、ネットワーク トポロジからいくらか独立しているので、グループ バインディングへの (S, G) および (*, G) の静的設定は受け入れ可能です。マルチキャスト グループが転送テーブルにある場合、マルチキャスト グループに対応する EPG は、転送テーブルにも配置されます。
（注） |
このマニュアルでは、マルチキャスト グループとしてマルチキャスト ストリームを参照します。 |
リーフ スイッチは、マルチキャスト ストリームに対応するグループを常に宛先 EPG と見なし、送信元 EPG と見なすことはありません。前述のアクセス コントロール マトリクスでは、マルチキャスト EPG が送信元の場合は行の内容は無効です。トラフィックは、マルチキャスト ストリームの送信元またはマルチキャスト ストリームに加わりたい宛先からマルチキャスト ストリームに送信されます。マルチキャスト ストリームが転送テーブルにある必要があり、ストリーム内に階層型アドレッシングがないため、マルチキャスト トラフィックは、入力ファブリックの端でアクセスが制御されます。その結果、IPv4 マルチキャストは入力フィルタリングとして常に適用されます。
マルチキャスト ストリームの受信側は、トラフィックを受信する前にマルチキャスト ストリームに最初に加わる必要があります。IGMP Join 要求を送信すると、マルチキャスト レシーバは実際に IGMP パケットの送信元になります。宛先はマルチキャスト グループとして定義され、宛先 EPG は転送テーブルから取得されます。ルータが IGMP Join 要求を受信する入力点で、アクセス制御が適用されます。Join 要求が拒否された場合、レシーバはその特定のマルチキャスト ストリームからトラフィックを受信しません。
マルチキャスト EPG へのポリシーの適用は、前述のようにコントラクトのルールに従ってリーフ スイッチにより入力時に発生します。また、EPG バインディングへのマルチキャスト グループは、 [APIC] により、特定のテナント（VRF）を含むすべてのリーフ スイッチにプッシュされます。
タブー
セキュリティを確保する通常のプロセスも適用されますが、ACI ポリシー モデルは、どのようなセキュリティ プラクティスが採用されても完全性を確保するのに役立ちます。ACI ポリシー モデルのアプローチでは、すべての通信がこれらの条件に準拠する必要があります。
-
通信は、モデルの管理対象オブジェクトであるコントラクトに基づいてのみ許可されます。コントラクトがなければ、EPG 間通信はデフォルトでディセーブルになります。
-
ハードウェアへのダイレクト アクセスはなく、すべてのインタラクションはポリシー モデルを通じて管理されます。
禁止コントラクトは特定のトラフィックを拒否するために使用できます。そうしないと、コントラクトによって許可されます。ドロップされるトラフィックは、パターンと一致しています（すべての EPG、特定の EPG、フィルタに一致するトラフィックなど）。禁止ルールは単方向で、コントラクトを提供する EPG に対して一致するトラフィックを拒否します。
Cisco APIC リリース 3.2(x) および名前が EX または FX で終わるスイッチでは、標準コントラクトで代わりに件名 [拒否] アクションまたは [コントラクトまたは件名の除外] を使用して、指定のパターンを持つトラフィックをブロックできます。
フィードバック