アルバESPポリシー・デザイン
Aruba Edge Services Platform(ESP)ポリシーは、ネットワークリソースへのアクセスを管理するゼロトラスト原則を使用して、柔軟で信頼性の高いサービスを提供します。ロールベースのポリシーを使用して、ネットワークが従来のVLANセグメンテーションの方法からIDベースのアクセスに進化するのを支援し、セキュリティで保護されていないIoTデバイスやそれらを侵害しようとする不正なアクターの脅威の増加をより正確に分類し、効果的に軽減します。
Aruba ESPポリシーを設計する際は、ネットワークにアクセスするさまざまなタイプのユーザーとデバイスを識別する手段と、必要なアクセスレベルを検討してください。この識別情報は、各クライアントセッションがアクセスできるリソースと適用される制限を定義する、きめ細かなロールベースのアクセスポリシーを作成する上で重要です。
Aruba ClearPass Policy ManagerとAruba Centralのクラウド認証サービスは、効果的な役割ベースのポリシーを適用するための重要なコンポーネントです。
ClearPassは、クライアントデバイスを認証し、適切なレベルのネットワークアクセスを割り当てるために、物理または仮想アプライアンスとしてオンプレミスに展開できます。LDAP、Device Insight、パートナーのファイアウォール・データベースなどの内部または外部リポジトリとインタフェースして、デバイスまたはユーザーのアイデンティティをすばやく確立し、IP接続を確立する前に、アクセスのレベルに関する情報に基づいた決定を下すことができます。
Cloud Authは、クラウドネイティブのセキュリティサービスであり、Aruba CentralのNetConductorの不可欠な部分です。ClearPassと同様に、Google WorkspaceやMicrosoft Entra IDなどの企業の既存のクラウドアイデンティティストアと統合して、適切なレベルのネットワークアクセスを認証して割り当てます。
Aruba ESPポリシーの設計には、次の要素が1つ以上含まれる場合があります。
– Aruba Central
- Aruba ClearPass Policy Manager
- Aruba CXスイッチ
- ArubaOS 10ゲートウェイとアクセスポイント – Aruba Central NetConductor
次の図は、集中型および分散型のポリシー適用モデルの高レベルの例です。
最初の図である集中型モデルは、ユーザーベーストンネリング(UBT)を使用して、有線クライアントトラフィックをカプセル化し、GREトンネル経由でArubaOS 10ゲートウェイクラスターに転送します。ゲートウェイは、トラフィックのカプセル化を解除して分析し、ユーザーロールやその他の関連属性を適用してから、トラフィックを対応する宛先に転送します。
2番目の図では、分散型モデルであるAruba CXスイッチがEVPN-VXLANオーバーレイ・ファブリックを構成しています。データトラフィックはVXLANトンネルにカプセル化されて転送され、対応する役割とポリシーで構成されたVXLAN-GBP対応デバイス上でポリシーを強制できます。
クライアントロール
Aruba ESPは、ネットワーク内の接続された任意のクライアントに役割を割り当て、ネットワーク内の任意の時点（スイッチ、AP、ゲートウェイ）でその役割にポリシーを適用する機能を提供します。
アクセスを試みるすべてのタイプのユーザーまたはデバイスに対する役割を定義します。役割のすべての受信者は、ネットワーク全体で同じポリシーの影響を受け、それに応じてグループ化する必要があります。
ポリシールールは役割を参照し、それによって、そのルールが転送を通じて特定のネットワークデバイスにどのように適用されるかに基づいて、ポリシー強制アクションを実行します。
802.1X認証とともに、組織はArubaデバイスがサポートする組み込み属性やカスタマイズ可能な属性の長いリストを組み込むことができます。これらの属性は、管理者がネットワークへのクライアントデバイスのアクセスを分類したり、許可または禁止したりするための追加のコンテキストを提供します。
使用可能な属性は次のとおりです。
*ホスト名 *IPアドレス *ゲートウェイの場所 *MDMメンバーシップの状態 *ファイアウォールトラフィック分類 *クライアントOSバージョン *時刻 *プロファイルするデバイスタイプ。
クライアントの役割を正確に割り当てることは、組織でゼロトラストポリシーを実施するための重要な基盤です。
ポリシー
ポリシーとそのクライアントの役割の割り当ては慎重に定義する必要があります。これは、脅威からネットワークを保護しながら、すべての信頼できるネットワークデバイスに適切で中断のないアクセスを提供する包括的なソリューションとして機能します。
ポリシーは、ネットワーク上でのクライアントの動作を制御する一連の規則です。ポリシー・ルール内では、各ユーザーは1つのロールで表されます。動的に使用される場合、ロールは認証中に割り当てられ、そのユーザーまたはデバイスからのすべてのトラフィックは、そのアクセスインスタンスのロールIDでマークされます。
トラフィックが一意のロールIDでマークされた後、ポリシーを任意のArubaデバイスに適用して、そのトラフィックがネットワーク内のどこで、いつ、どのように流れるかを決定できます。
ClearPass
ClearPassは、複数の仮想環境に物理アプライアンスまたは仮想アプライアンスとして実装できる、柔軟で強力なソリューションです。スタンドアロンのAAAサーバとして導入できますが、ベストプラクティスは、高可用性(HA)と負荷分散の両方のために、クラスタ内に複数のサーバを導入することです。詳細はインストールガイドを参照してください。
ClearPassのすべての実装と操作は、パブリッシャーノードのWeb UI内で直接管理されます。この導入ガイドには、ソリューションを正しくインストールするための詳細な手順が記載されています。機能とコマンドの詳細については、User Guideを参照してください。
ClearPassを使用する場合は、ネットワークに参加するときに期待されるクライアントエクスペリエンスを計画する時間がかかります。フローチャートを作成して技術チームおよびビジネスチームの両方と共有するための認証および承認プロセスの概要を示し、適切な期待値を設定して新しいソリューションの利点を示すセキュリティ手順が必要な理由の下で組織のメンバーを確認します。
ユーザーエクスペリエンスとビジネス要件を定義した後、ClearPassが期待を満たす方法を決定します。ClearPassは、豊富な機能を備えた強力なツールです。このガイドでは、最も一般的でシンプルでありながら非常に効果的な実装で使用されるサービスと機能について説明します。
パブリッシャおよびサブスクライバ - ClearPassクラスタを構築する際は、地理的な場所とHAの要件を考慮して、データベース同期、L2冗長性、Guest Captive Portal、およびその他のサービスが適切に動作していることを確認します。
認証方法 – ネットワーク上のクライアントを許可または禁止するために使用する認証方法を定義します。利用可能な方法のリストには、PEAP、EAP-TLS、およびEAP-TTLSが含まれますが、これらに限定されません。
認証ソース – 前の手順で定義した認証方法をサポートするために必要なすべての認証ソースを特定します。Active Directory、MDMソリューション、内部ユーザーまたはゲスト・デバイス・リポジトリなどのソースを、このセクションで前述の定義に従って含めることができます。
Identity – コンテキストを構築するために使用可能なエンドポイントプロファイリング方法を識別し、必要に応じてClearPassロールおよびロールマッピングポリシーを構築して、ポリシーの実施をさらに支援します。
Enforcement – 最後に、認証への応答に使用される適切な実施プロファイルを決定するための規則のトップダウンリストを構築するように実施ポリシーを構成します。これは、ClearPassサービスを処理する最後の手順です。VLAN名とID、QoSマーキング、Arubaユーザーロール、その他の標準またはカスタム属性を含めることができます。
Network Devices and Device Groups:ClearPassが認証要求を受け入れる必要があるネットワーク・デバイス（RADIUSクライアントやTACACSクライアントなど）のリストを構成します。オプションとして、ClearPassサービスが要求の分類、受け入れ、処理に使用できるデバイスグループを作成します。このデバイスグループは、特定のベンダー製のスイッチのグループなど、応答で異なる属性が必要になる可能性のある要求の分類、受け入れ、処理に使用できます。
上記のコンポーネントは、まとめてClearPassサービスを形成します。完全なサービスとしての全体的なインタラクションと組み合わせ機能は、ClearPassパブリッシャーの完成したService Templates & Wizardsページで確認できます。上記のコンポーネントを組み合わせて、有線NACからワイヤレスまたは有線ゲスト専用ポータルまで、あらゆる種類の環境を保護します。
最良の結果を得るには、キャンパス全体でVLANの命名規則を標準化し、ClearPassで必要なときに簡単に参照できるようにします。たとえば、エンタープライズユーザのVLAN IDと名前がIDF、建物、フロアによって異なる場合、IDF名やサブネットなどに基づいてどのVLAN IDを返すかを識別するための、複雑な強制ポリシーが必要になります。繰り返しプロファイルを使用すると、構成と後続のメンテナンスおよびトラブルシューティングに時間がかかる場合があります。 IDが異なる場合でもVLAN名を標準化することで、サービス構成の複雑さを簡素化します。ClearPassは1つの標準レスポンスを送信するだけで、このプラットフォームのサポートが非常に簡単になります。
一元化されたポリシー
一元化されたポリシーでは、ワイヤレスおよび/または有線のデータトラフィックは、セキュリティ強化とトラフィックシェーピングのためにゲートウェイクラスタにトンネリングされます。
次の例では、財務部門のユーザがキャンパスネットワークに対して認証を行います。別のユーザーが、UBT対応スイッチに直接接続されたゲストキオスクコンピュータにログインしています。APとスイッチの両方が、GREトンネル経由でゲートウェイにトラフィックを転送します。ゲートウェイは、トラフィックのカプセル化を解除して分析し、事前定義されたITセキュリティ・ポリシーに基づいてユーザーの役割やその他の関連属性を適用してから、トラフィックを許可された送信先に転送します。この場合、すべての強制はゲートウェイで実行されます。
Aruba Central
Aruba Centralクラウドプラットフォームは、ESPアーキテクチャ全体でポリシーを管理するためのアプリケーションをホストします。Aruba Centralは、Aruba ESPネットワーク内のすべてのデバイスでポリシーの作成と一貫した実装を容易にするユーザーインターフェイスを提供します。
Aruba Centralは、オンプレミスのゲートウェイ、AP、およびスイッチを管理し、一貫したポリシーの実装を保証します。
ゲートウェイ
ArubaOS 10は、クラウド対応のAI統合ワイヤレスネットワークオペレーティングシステムです。AOS 10を実行するゲートウェイは、セントラルを介して構成されます。DPIおよびIDP/IPS関数を使用して、より深いレベルの検査を実行し、ネットワークをより安全に保護することで、大きなACLの処理に優れています。利用可能なゲートウェイ機能により、企業ごとに異なるさまざまなセキュリティ要件にアルバESPポリシーを簡単に適応させることができます。
高可用性を目的としてゲートウェイクラスタを設計する場合は、クラスタの容量を50 %未満にして、ヒットレスフェイルオーバと、クラスタメンバーに障害が発生した場合の接続を中断しないようにしてください。
また、ゲートウェイ・クラスタリングを使用すると、既存のゲートウェイを置き換えることなく規模を拡大できます。新しいゲートウェイは、既存のゲートウェイと一緒にクラスタ化できます。パフォーマンスの問題を回避するには、容量の80%を最大のターゲットとして推奨します。ただし、APは単一のコントローラに戻る単一のGREトンネルを構築します。クラスタの使用率が50 %以下になると、APは2つのクラスタメンバに対して冗長GREトンネルを確立します。
7000および9000シリーズのゲートウェイの最大クラスタサイズは、4つのデバイスです。7200シリーズゲートウェイの最大クラスタサイズは12デバイスです。可能な場合は、より多くのゲートウェイではなく、より大容量のゲートウェイを使用して、要件を満たし、拡張に対する柔軟性を高めます。
同種クラスターが必要です。同じクラスタ内で異なるゲートウェイモデルを混在させることはサポートされていません。
認証サーバ、AAAプロファイル、ロール、およびポリシーはすべて、ゲートウェイの中央設定ページを使用して設定されます。
Devices > Gatewaysタブ> Securityページで、ユーザロールを作成し、同じセクションのサブカテゴリを使用してAAAプロファイルに関連付けます。Role AssignmentタブのAAAプロファイルにより、ゲートウェイ（この例では）はクライアント認証イベント中にRADIUSサーバから返されたロールを認識し、それを適切なエンドポイントにマップできます。
セキュリティ>ポリシーセクションでは、アプリケーションセッションのプロパティに基づいてファイアウォール規則セットを作成できます。ArubaOSには、一般的なベンダーのルーターソフトウェアとの互換性を確保するための標準および拡張ACLを含む6種類のポリシータイプがあります。ただし、ファイアウォールセッションポリシーは、標準および拡張ACLと同等で優れた機能を提供するため、代わりに使用する必要があります。
ポリシーは、上記のページの[ロール構成]タブのロールに関連付けられています。ロールを作成してポリシーに関連付けると、ユーザ認証とロール割り当てを有効にするようにAAAプロファイルを設定できます。セキュリティで保護されたユーザー単位のセッションをCentralから管理し、ゲートウェイクラスタを介してネットワークアクセスレイヤをセキュリティで保護できます。
スイッチング
Arubaスイッチは、User-Based Tunneling(UBT)と呼ばれる一連の機能をサポートしています。スイッチは、APがクライアントトラフィックをトンネリングする方法と同様に、GREトンネル内のゲートウェイクラスタにクライアントトラフィックをトンネリングして戻します。ゲートウェイは、有線、無線、およびWANまたはインターネットトラフィックの一元化されたポリシー適用ポイントとして機能します。
UBTは、Aruba Colorless Portsをサポートする一元化されたポリシーを提供します。スイッチは、ポリシー適用のためにゲートウェイクラスタにトラフィックを動的にトンネリングできるため、任意のクライアントデバイスが適切に構成されたスイッチポートに接続し、適切なレベルのネットワークアクセスを動的に受信できます。このレベルの動的なポート割り当てによって、異なるデバイスに対して複数のスイッチポート範囲を手動で設定および維持する必要がなくなります。
UBTはネットワークエンジニアに対して、前の週に変更リクエストを送信するのを忘れていたため、イライラする月曜日の朝のエスカレーションを排除し、ポートを最終分の従業員の移動に再構成します。また、IAPのトランク・ポートとして構成されたスイッチ・ポート1～8、セキュリティ・カメラのアクセス・ポートとして9～16、プリンタのアクセス・ポートとして17～20、およびビジネスでサポートされるその他のデバイスを必要とする、大規模なポート・マッピング・プランを管理する必要もなくなります。
分散ポリシー
分散ポリシーの適用では、VXLANトンネルを使用してスイッチ間に仮想ネットワークを作成します。Aruba CXスイッチは、ゲートウェイに搭載されているのと同じ機能を使用して、ポリシーをローカルで適用できます。これは、キャンパス内の東西のトラフィックを保護する場合に特に強力です。これらの機能は、Aruba ESP NetConductorソリューションと呼ばれます。
NetConductorは、VXLANとEVPNコントロールプレーンを組み合わせて、地理的に多様なサブネットとブロードキャストドメイン間でエンドポイントの到達可能性を確保します。
次の例では、財務部門の有線ユーザがキャンパスネットワークに対して認証を行います。別のユーザーがゲストキオスクコンピュータにログインしています。スイッチはトラフィックをローカルで分析し、事前定義されたITセキュリティ・ポリシーに基づいてユーザーの役割およびその他の関連属性を適用してから、トラフィックを承認された宛先に直接転送します。スイッチのネイティブファイアウォール機能を使用すると、エッジでポリシーを強制できるため、トラフィックは宛先へのより直接的なパスを使用できます。
NetConductorによって構成されるすべてのスイッチは、同じ中央グループに属している必要があります。ワイヤレスゲートウェイは、既存のワイヤレスグループに残るか、スイッチンググループに含めることができます。
中央
Aruba Centralクラウドプラットフォームは、ESPアーキテクチャ全体でポリシーを管理するアプリケーションをホストします。Centralは、EVPN-VXLANオーバーレイの展開を簡素化するAruba Central NetConductorと呼ばれるワークフローベースのユーザーインターフェイスを提供します。NetConductorは、組織全体で一貫した構成を確保するために、すべてのESPデバイス・タイプとインタフェースを持つ高度なAPIドリブン自動化を実装しています。
NetConductorファブリック内のスイッチとゲートウェイは、オーバーレイ内のすべてのパケットのVXLANヘッダーにマークされているポリシーIDにアクセスし、ネットワーク内のどこでもポリシーを適用できるようにします。ポリシーは、CentralのゲートウェイSecurity設定セクションのClient Rolesインターフェイスを使用して設定します。
ゲートウェイ
ゲートウェイは、Aruba CentralとNetConductorワークフローを使用して設定します。既存のAruba無線LANは、NetConductorファブリックに容易に統合できます。推奨されるアプローチは、ゲートウェイクラスタをVSXペアとして構成された2台のAruba CX 8360スイッチに接続することです。このペアは、ファブリック構成中にスタブペルソナを引き継ぎます。
ワイヤレスLANとオーバーレイファブリックは、コントローラクラスタと接続先のスタブスイッチとの間に設定されたスタティックVXLANトンネルを介して接続されます。このトンネルは、VXLANヘッダーを保持することで、WLANとEVPNファブリック間でロールIDが確実に通信されるようにします。
NetConductorでは、ファブリック内のスイッチにペルソナを追加する必要があります。ゲートウェイはVSX集約スイッチのペアに接続し、スイッチにはNetConductorからスタブペルソナを割り当てる必要があります。これにより、NetConductorはゲートウェイとスイッチの間にスタティックなVXLANトンネルを設定し、EVPNファブリックとWLANオーバーレイの間でGPIDを含むVXLANヘッダーの通信を有効にします。
スイッチング
スイッチは、Aruba Central NetConductorを使用して構成されます。Aruba Central NetConductorは、EVPN-VXLANオーバーレイファブリックを展開する直感的なユーザーエクスペリエンスを提供します。
Aruba CXスイッチのオペレーティング・システムは、提案されているグループ・ベースのポリシー・フィールドを使用して、ポリシーに対してネットワーク内の任意の場所のパケットを評価できるグループ・ポリシーID値を伝送することにより、EVPN-VXLANに基づく高度なリカバリ性を備えたオーバーレイ・ネットワークを構築するために必要なL3機能の高度なスイートを提供します。ファブリックを介して伝送される各ユーザーまたはデバイス・セッションには、ネットワーク内の各スイッチが役割ベースのポリシーを適用できるようにする役割IDが割り当てられます。
