ゼロトラストのインラインセグメンテーション:ネットワーク設計におけるマイクロセグメンテーションの新しい方法
エンタープライズネットワークは、クラウド対応で拡張性に優れた効率的なネットワークに対する需要の高まりに対応するために、大規模な移行を遂げています。大量のモノのインターネット(IoT)やモバイルデバイスに対する需要もあります。デバイスの数が増えるにつれて、マイクロセグメンテーションとセキュリティに対するニーズもかつてないほど高まり、ネットワークも複雑化します。このような課題に対応するには、自動化と運用簡素化のための人工知能(AI)を備えたネットワークが必要です。グループベースポリシー(GBP)によるマイクロセグメンテーションをサポートするジュニパーネットワークスキャンパスファブリックIP Closは、拡張性の高いスタンダードベースの EVPNアーキテクチャです。このアーキテクチャは、ジュニパー Mist™ポータルを通じて管理される一貫した最適化されたエンタープライズセキュリティ要件を提供します。
GBPを使用すると、キャンパスファブリックIP Clos内のアクセスレイヤーでマイクロセグメンテーションを有効にし、EVPN-VXLANを活用してブロードキャストドメイン内およびドメイン間でのトラフィック分離を提供し、キャンパスファブリック全体のセキュリティポリシーを簡素化できます。
GBPを使用したマイクロセグメンテーションには、いくつかの利点があります。
スタンダードベース — https://datatracker.ietf.org/doc/html/draft-smith-vxlan-group-policy-05
- ワークフローの簡略化—グループベースのポリシーは、ジュニパー Mistポータルを通じて管理され、ネットワーク全体のポリシーの制御と適用のためのシンプルでわかりやすいワークフローを提供します。また、GBPは、すべてのデバイスに大量のファイアウォールフィルターを設置する必要がなくなり、横方向の脅威保護を確実にすることで、ネットワーク設定を簡素化します。
- 一貫性—GBPは、ジュニパーMistポータルを通じて、企業全体で一貫した顧客管理セキュリティポリシーを提供します。
- ロケーションに依存しない接続性—GBPは基盤となるVXLANテクノロジーを活用して、ロケーションに依存しないエンドポイントアクセス制御を提供します。
- よりきめ細かい制御—GBPはレイヤー2方式として適用できるため、従来のACLベースの方式よりも厳密な制御が可能です。GBPと共にVXLANを使用すると、同じVLAN内のクライアントとの間のトラフィックをブロックできます。
- ネットワークアクセス制御—GBPを使用すると、有線クライアントの動的または静的なタグ付けが可能になります。
- ダイナミックGBPタグ付けは、業界標準ベースのRADIUSおよびクラウドベースのジュニパー Mist Access Assuranceを含むネットワークアクセス制御プラットフォームと連携します。
- 静的GBPタグでは、ファブリック内のすべてのアクセスポートで、IPプレフィックス、MACアドレス、VLAN、ポートごとにGBPタグを割り当てることができます。
におけるグループベースのポリシーとSGT
ゼロトラストインラインセグメンテーションを使用しないマイクロセグメンテーション
VXLANアーキテクチャでは、マクロセグメンテーションとマイクロセグメンテーションを使用して、グループベースポリシー(GBP)を通じてデータと重要なアセットを保護できます。VXLAN上に構築されたグループベースのポリシーは、エンドポイントに対してロケーションに依存しないアクセス制御を提供します。これにより、デバイスの物理的接続場所に関係なく、エンタープライズネットワークのさまざまな部分に一貫したセキュリティポリシーを適用できます。
GBPを使用することで、設定の複雑さを軽減し、すべてのスイッチに大量のファイアウォールフィルターを導入する必要がなくなります。グループベースのポリシーは、エンドポイントやユーザーの場所に関係なく、ネットワーク全体に一貫したセキュリティルールを適用することで、脅威の横方向への移動を防ぐのに役立ちます。VXLAN-GBPは、VXLANヘッダーの予約済みフィールドを使用して、スケーラブルグループタグ(SGT)を伝送します。これらのタグはファイアウォールフィルタールールで参照できるため、ポート番号やMACアドレスに依存するよりも信頼性の高いポリシー適用方法となります。
スケーラブルなグループタグは、ポートごとまたはMACアドレスごとと、スイッチ上で静的に割り当てるか、RADIUSサーバーを介して動的に割り当てることができます。802.1X 認証を使用する場合、ユーザーの認証に成功した後、RADIUS サーバーは適切な SGT をスイッチにプッシュできます。
キャンパスVXLANの導入では、VXLAN-GBPセグメンテーションが特に有用です。物理ネットワーク設計とは独立したアクセスポリシーを定義できるためです。これにより、アプリケーションとエンドポイントデバイス向けのセキュリティポリシーの計画と実装の両方が簡素化されます。
VXLAN-GBP規格の詳細については 、IEEE RFC(I-D.draft-smith-vxlan-group-policy)を参照してください。このアーキテクチャ例では、VXLAN-GBP は VXLAN ヘッダーの予約済みフィールドを SGT として活用します。
へのGBPタグ
Junos OSリリース22.4R1以降、ジュニパーネットワークススイッチは、以下に説明するようにエグレスおよびイングレス強制モードでVXLAN-GBPをサポートします。
- GBPエグレスの適用:
- これがIETF標準ベースのアプローチです。
- GBPタグはVXLANデータプレーンの一部であり、VXLANヘッダーでグループポリシーIDとして設定する必要があります。
- リモートスイッチからの宛先GBPタグを検証するには、パケットを毎回リモートスイッチに送信する必要があります。その後、リモートスイッチは、ファブリックから次の有線クライアントへと送信されるトラフィックの適用ポイントとして機能し、SGTポリシーに基づいてトラフィックをブロックし、パケットを破棄できます。
- GBP ingressの適用:
- これは、Junos GBPおよびSGT実装に対するジュニパーネットワークス独自の拡張機能です。
- この拡張機能は、Junos OSリリース22.4R1以降で利用できます。
- ここでGBPタグはコントロールプレーン(MP-BGP拡張)の拡張です。
- GBPタグ情報は、ベンダー固有の属性を介して、ファブリックがノード間で共有するEVPNタイプ2のMACおよびIPアドレス情報に追加されます。この場合、VXLANヘッダーのグループポリシーIDの値は適用に使用されないため、デフォルトでは常にゼロになります。
- このアプローチの大きな利点は、リモートスイッチ上に存在する有線クライアントの宛先GBPタグがコントロールプレーンを通じて学習されるため、既知であることです。この機能拡張により、送信元有線クライアントが接続されているローカルスイッチのSGTは、リモートスイッチ上の宛先クライアントへの送信が許可されていないトラフィックを先制的にブロックできます。SGTの適用は、常にingress有線クライアントスイッチで行われます。標準ベースのアプローチのように、SGTによって破棄される可能性がある場合でも、すべてのトラフィックをファブリック経由で送信する必要は、このソリューションでは発生しません。
- この拡張機能により、管理者はGBPベースのトラフィック転送の決定を簡単にデバッグできます。ローカルスイッチを確認して、トラフィックがリモートスイッチによって許可されるかブロックされるかを確認できます。
show ethernet-switching tableなどのJunos OSコマンドは、ローカルおよびリモートの有線クライアントのGBPタグ情報を表示します。
GBPタグを有線クライアントに適用して、SGTがトラフィックを許可またはブロックするために使用する方法はさまざまです。
GBPタグは、次のように割り当てることができます。
- 静的GBPタグ割り当ての場合:
- 有線クライアントを識別し、GBPタグを割り当てるには、タグ割り当てを静的に設定する必要があります。
- 一致基準(Junos OSリリースバージョンによって異なります)は次のとおりです。
- レイヤー3送信元IPv4プレフィックスとホスト
- レイヤー3送信元IPv6プレフィックスとホスト
- レイヤー2 MACアドレス
- スイッチのインターフェイス/ポートおよびVLAN ID(ジュニパーネットワークス® EX4100スイッチではサポートされていません)
- レイヤー2 VLAN ID(EX4100スイッチではサポートされていません)
- スイッチ インターフェイス/ポート
- 動的GBPタグ割り当ての場合:
- 有線クライアントは、ファブリックに入る際にスイッチポートで認証される必要があります。
- これは、RADIUS access-acceptメッセージの一部であるRADIUSサーバー認証情報に基づいています。
- 有線クライアント認証には、以下があります。
- IEEE 802.1X EAPベース
- MAC認証バイパス(MAB)
ジュニパーのMistポータルは、このプロセスを簡素化し、以下に示すように必要なスイッチ構成を抽象化します。
GBPタグの割り当てを定義した後、SGTをスイッチポリシーとして指定する必要があります。ここでも、ジュニパー Mist クラウドでは、ポータル内でこのプロセスを簡素化および抽象化することで、直感的なコミュニケーションマトリックスを構築できます。
スイッチテンプレートを使用して、静的または動的なGBPタグの割り当てとSGTポリシーを設定することを強くお勧めします。テンプレートを使用すると、IP Closファブリックのすべてのアクセススイッチにこの情報を配布する作業が容易になります。
詳細については、以下の「IP Closファブリック向け JVD拡張」 と導入例を参照してください。
ゼロトラストのインラインセグメンテーションによるマイクロセグメンテーション
SGT適用機能は、有線クライアントがファブリックに侵入する場所で実行する必要があるため、これまで採用されているアプローチはIP Closファブリックでのみ利用可能です。これは、同じアクセススイッチの異なるポートに接続された有線クライアントを、同じVLAN内での通信からブロックする必要があるためです。
ファブリックへのノースバウンドの適用を試み、WAN ルーター側で適用を試みるとします。これは、インターネットに向けたトラフィックからの保護には適しているかもしれませんが、L3ベースのマクロセグメンテーション(設計によって異なります)や、同じVLAN内のL2マイクロセグメンテーションには間違いなく手遅れかもしれません。
ZTISにより、ジュニパーは以下を実現しました。
- 他のすべてのキャンパスファブリック設計(EVPN、MH、CRB、ERB)間のギャップを埋め、それらの設計におけるマイクロセグメンテーションも可能にします。
- EVPNファブリックがまったくない場合でもマイクロセグメンテーションを有効にします。これは、スイッチとAPの数が少ないシンプルな支社設計で一般的なことです。
- APから接続されたスイッチへのGBPタグ伝播を有効にします(ジュニパー Mist Edgeを使用したリモートトンネルも経由します)。
これらの新機能とトポロジーを連携させ、無線クライアントと有線クライアントの両方でGBPタグ情報を共有し、これらのポリシーを一貫して実施するために、ベンダー固有の拡張機能が導入され、ネットワーク全体へのクライアント情報の伝搬がサポートされました。
前述のIP Closファブリックのシナリオでは、以下を使用する可能性があることに留意してください。
- VXLANデータヘッダーに埋め込まれたGBPタグにより、egressの適用が可能になります。
- ジュニパー独自のBGP-MP拡張機能は、EVPNコントロールプレーンの一部としてGBPタグを追加し、イングレスの適用を可能にします。
これら2つのアプローチをAPと支社/拠点スイッチに再利用すると、通常、多額の統合コストが発生し、追加の容量が必要となり、すべての有線および無線デバイスにEVPNファブリックを拡張する必要があります。したがって、ZTISに対するより合理化されたアプローチが必要であり、開発されました。
ZTISソリューションでは、同じレイヤー2ドメインまたはEVPNファブリック内のすべてのデバイス間で交換される新しいメッセージタイプが導入されています。2つのメッセージタイプが必要です。
- ZTIS アップデート メッセージは、スイッチまたはAPが新しいクライアントMACアドレスを認証するときに生成されます。その後、デバイスは、関連するMAC-to-GBPタグマッピングをネットワーク内の他のデバイスに配信します。
- ZTIS ルックアップ メッセージは、デバイスがローカルテーブルで新しいMACアドレスを検出したが、対応するGBPタグをまだ知らない場合に送信されます。MAC-to-GBPマッピングを持つデバイスは、ZTISアップデートメッセージを返します。ルックアップメッセージは、スイッチの再起動後に以前に学習したMAC-to-GBP情報が失われ、再構築が必要な場合によく使用されます。
したがって、MAC-to-GBPタグ情報を交換するために、フラッドアンドラーン(またはユニキャストメッセージが使用できる場合はホップバイホップ学習)アプローチを使用するコントロールプレーン機能の第3の方法が多かれ少なかれ存在します。GBP適用機能は、上記の要件として説明したように、ネットワークのアクセススイッチ(ここではジュニパー Mist Edgeとは見なされません)で引き続き発生することに注意してください。
では、これら2つの新しいメッセージはネットワークとどのように交換されるのでしょうか?ネットワーク内のZTISデバイス間で交換されるメッセージは、イーサネット論理リンク制御(LLC)メッセージSNAPを使用したジュニパー拡張に基づきます。これらのメッセージは以下の通りです。
- 2台のZTIS対応スイッチ間のレイヤー2ユニキャストが可能です。スイッチは、リモートスイッチから学習した追加のジュニパーLLDP拡張を使用してこれを検出します。
- それ以外の場合はレイヤー2マルチキャストメッセージで、特にZTIS対応スイッチに接続されたZTIS対応APから送信されます(これにはジュニパー Mist Edgeトンネルが含まれます)。
以下は、このようなメッセージのWiresharkパケットキャプチャであり、レビューするべき最も重要なフィールドを強調しています。
- 宛先MACアドレス
0x5d5b35ffff01は、すべてのL2マルチキャストメッセージに使用され、GBPネットワーク知識を接続されているすべてのデバイスにフラッディングします。それ以外の場合は、ZTISスイッチ間のユニキャストパケットになります。 - LLC SNAPセクションには、以下のようなプロトコルIDが表示されます。
- プロトコルID=
0x000bは、GBPアップデートメッセージを識別します - プロトコルID=
0x000cは、GBPルックアップメッセージを識別します
- プロトコルID=
- データフィールドの最初の2バイトの後に、有線クライアントと無線クライアントのエンコードされたMACアドレスが表示されます。
ZTISはまた、宛先IPプレフィックスに基づいてポリシーを適用する機能を追加することで、マイクロセグメンテーションを強化します。以前は、送信元IPプレフィックスに基づいて静的GBPタグを割り当てることしかできませんでした。宛先IPプレフィックスのサポートにより、クライアントVLANから外部ネットワークに到達するトラフィックに対して適用ポリシーを作成できるようになりました。
適用する宛先IPプレフィックスを複数定義する場合は、最も具体的なものから最も一般的なものへと並べることをお勧めします。最も具体的なプレフィックスがリストの一番上に表示され、その下には幅の広いプレフィックスが表示されます。これは従来のファイアウォールと同じロジックに従い、最初に一致するルールが適用され、後続のルールは評価されません。以下の例では、送信元GBPの割り当ては、EAPやMABなどのRADIUSを介した動的認証と、ローカルクライアントVLAN外のトラフィックフローを定義するいくつかの重複する宛先IPルールに基づいています。
ポリシーを作成するときは、以下の例に示すように、正しく順序付けする必要があります。
- 宛先GBPタグに一致するすべてのルールは、設定の最上位に配置する必要があります。これらのルールは、同じVLAN内のトラフィックにのみ適用されます。これはZTISの既知の制限です。
- 宛先IPプレフィックスルールは、重複しないことを前提として、長いプレフィックスから短いプレフィックスの順に並べる必要があります。これにより、より具体的な一致が最初に評価されます。/0プレフィックスを使用してインターネットトラフィックを許可するルールは、常に特定の送信元GBPタグの最終ルールにする必要があります。宛先IPプレフィックスは、同じVLAN内のトラフィックにも使用できますが、異なるVLAN間のトラフィックのポリシーを定義する際には必要です。
例
上記のポリシーに基づいて、有線クライアントがEAP/MAC認証に基づいてソースGBPタグ=100 を取得するRADIUSします。クライアントは、次のいずれかのVLANに配置できます。
- network=
10.99.99.0/24が割り当てられたVLAN1 - network=
10.88.88.0/24が割り当てられたVLAN2
以下の表は、クライアントがどのトラフィックをどの宛先に送信できるかを示しています。
| 送信元IP:GBPタグ100 | 宛先IP 8.8.8.8 | 宛先IP 10.11.11.11 | 宛先IP 10.33.33.33 | 宛先IP 10.99.99.23 | 宛先IP 10.88.88.88 |
|---|---|---|---|---|---|
| VLAN1 10.99.99.23/24 | 許可(インターネット) | 許可(ファブリック) | 許可済み(サーバー) | 許可(有線クライアント) | 拒否(vlan1088) |
| VLAN2 10.88.88.23/24 | 許可(インターネット) | 許可(ファブリック) | 許可済み(サーバー) | 許可されるが、ユニキャスト(ファブリック) | 許可(有線クライアント) |
ポリシーの適用は、ACLと同様に一方向に適用されます。そのため、双方向を意図したトラフィックが他のルールによって意図せずブロックされないようにする必要があります。この例では、これは、送信元 IP が VLAN2 の 10.88.88.23 で、宛先 IP が VLAN1 の 10.99.99.23 である場合に発生します。ICMPエコー要求は転送され、10.99.99.23に到達しますが、ICMPエコー応答は、そのリターントラフィックを許可しないため、vlan1088ルールによって破棄されます。
有効なZTISトポロジーとその仕組みを確認しましょう。