エンジニアブログ 【検証】Aruba CX10000で実現する次世代データセンターセキュリティ！マイクロセグメンテーションを試してみた。
世界初DPUを搭載したAruba Networking CX10000スイッチは、ハードウェアオフロードでステートフルファイアウォール、NAT、IPsecをスイッチ上で機能させることができます。
昨今、データセンターに対する攻撃が大規模化してきており、それに対してマイクロセグメンテーションが注目されてきています。
今回はCX10000を使ったマイクロセグメンテーションの実現方法を検証を通して紹介します。
金井 貴浩
入社9年目のネットワークエンジニア
Juniperプロダクトを中心に、Arubaプロダクトも担当しています。
製品や技術に触れるのが好きで、家に検証環境を構築しています。
1. はじめに
ランサムウェアによる被害のニュースが後を絶ちません。一度企業のネットワークに侵入されると、ウイルスはあっという間にサーバーからサーバーへと感染を広げていきます。このようなサーバー間の通信、いわゆる「East-Westトラフィック」をいかに制御するかが、現代のセキュリティ対策の大きな課題となっています。
従来のファイアウォールによる「境界型防御」だけでは、内部に侵入された後の横展開を防ぐのは困難です。そこで注目されているのが、ゼロトラストの考え方に基づいた「マイクロセグメンテーション」です。これは、サーバー一つ一つを最小単位としてネットワークを細かく分離し、本当に必要な通信以外はすべてブロックする手法です。
しかし、これを実現するには複雑な設定や高価なライセンスやアプライアンスが必要で、導入のハードルが高いと感じている方も多いのではないでしょうか？
今回、そんな悩みを解決してくれるかもしれない、HPE Aruba Networking CX10000 スイッチを検証機として購入し、実機で検証を行いました。「スイッチ」がセキュリティポリシーを適用するとはどういうことなのか？その実力を徹底的にレビューします！
2. HPE Aruba Networking CX10000 とは？
まず、今回検証したCX10000がどのような製品か簡単にご紹介します。
CX10000は、データセンター向けの高性能スイッチですが、ただのスイッチではありません。業界初の「分散サービススイッチ」として、内部にAMD Pensando社が開発したDPU (Data Processing Unit) という専用プロセッサを搭載しています。
このDPUが、これまで外部のファイアウォールや仮想アプライアンスが担っていたステートフルファイアウォールやNATといったセキュリティ機能を、スイッチ自身がハードウェアレベルで高速に処理してくれます。
CX10000を導入するメリットは大きく3つあります。
- 構成のシンプル化: トラフィックをわざわざ外部のファイアウォールを経由させる必要がなくなり、物理/仮想アプライアンスの削減とネットワーク構成の簡素化が期待できます。
- パフォーマンス向上: スイッチを通過するパケットを速度を落とさず高速にハードウェアで検査・処理するため、セキュリティを強化しつつ、低遅延な通信を維持できます。
- 運用の一元化: ファイアウォールポリシーはPensando Policy and Services Manager (PSM) という管理ツールから一元的に作成・適用でき、ネットワークとセキュリティの運用を統合できます。
3. 検証してみよう！環境とシナリオ
検証環境
今回は以下のようなシンプルな環境を構築しました。
CX10000配下にProxmox環境を構築し、複数の仮想マシンをすべて同一のVLAN・サブネット（VLAN 100 / 192.168.100.0/24）に配置しています。
- 物理構成:
- スイッチ: HPE Aruba Networking CX10000
- サーバー: Proxmox 8.3.0
- ポリシー管理: Pensando PSM (仮想アプライアンス)
- 仮想マシン:
- Webサーバー (192.168.100.1)
- DBサーバー (192.168.100.2)
- 許可クライアント (192.168.100.3)
- 不許可クライアント (192.168.100.4)
検証シナリオ
この環境で、以下の2つのシナリオを検証しました。
シナリオ1：【基本編】同一セグメント内のICMP通信を止めてみる
- 内容：通常のL2スイッチでは不可能な、同じVLAN内の仮想マシン間のすべての通信を通信ポリシーをもとに通信制限を行う。
- 結果：ポリシー表通りに通信制御することができました。通信が許可された仮想マシン間は通信でき、許可されていない通信は遮断されました。
- 概要：Proxmoxに対して仮想マシン間の通信を制限するIsolate Ports設定と、CX10000に対してPrivate VLANおよびポリシー設定を行うことで同一L2セグメント間の通信を制御することができました。具体的な設定方法はAppendixを参照ください。
疎通確認結果
| server01(192.168.100.1) | server02(192.168.100.2) |
|
root@server01:~# ping 192.168.100.2 -c 2 2 packets transmitted, 2 received, 0% packet loss, time 1027ms
2 packets transmitted, 0 received, 100% packet loss, time 1019ms root@server01:~# ping 192.168.100.4 -c 2 2 packets transmitted, 0 received, 100% packet loss, time 1051ms |
root@server02:~# ping 192.168.100.1 -c 2 root@server02:~# ping 192.168.100.3 -c 2 root@server02:~# ping 192.168.100.4 -c 2 |
|
server02(192.168.100.2)に対してのみ疎通できました。 |
いずれの仮想マシンに対して疎通できませんでした。 |
| client01(192.168.100.3) | client02(192.168.100.4) |
|
root@client01:~# ping 192.168.100.1 -c 2 2 packets transmitted, 2 received, 0% packet loss, time 1060ms
root@client01:~# ping 192.168.100.4 -c 2 2 packets transmitted, 2 received, 0% packet loss, time 1001ms |
root@client02:~# ping 192.168.100.1 -c 2 2 packets transmitted, 2 received, 0% packet loss, time 1002ms
2 packets transmitted, 0 received, 100% packet loss, time 1003ms root@client02:~# ping 192.168.100.3 -c 2 2 packets transmitted, 2 received, 0% packet loss, time 1052ms |
|
server01,client02に対して疎通できました。server02に対しては通信できませんでした。 |
server01,client01に対して疎通できました。server02に対しては通信できませんでした。 |
シナリオ2：【実践編】Webサーバーへのアクセスを制御する
- 内容：「許可クライアント」からのみ「Webサーバー」のWebポート（TCP/80）へのアクセスを許可し、それ以外の通信はすべて拒否します。
- 結果：ポート番号を指定して許可クライアントからWebサーバの特定ポートへのアクセスができ、不許可クライアントからの通信はできずタイムアウトしたことを確認できました。
- 概要：GUI管理ツール上から通信フロー可視化図（ネットワークグラフ）上からフローを選択し、ポリシーを追加することができました。具体的な設定方法はAppendixを参照ください。
疎通確認結果
| client01 -> server01へhttp通信 | client02 -> server01へhttp通信 |
|
nelco@client01:~$ curl GET http://192.168.100.1 <p>For online documentation and support please refer to <p><em>Thank you for using nginx.</em></p> |
nelco@client02:~$ curl GET http://192.168.100.1 curl: (6) Could not resolve host: GET curl: (28) Failed to connect to 192.168.100.1 port 80 after 136007 ms: Couldn't connect to server |
|
curlコマンドによりWebサーバにアクセスできたことを確認できました。 |
Webサーバにアクセスできずタイムアウトしました。 |
4. まとめ
考察
今回の検証を通じて、CX10000の大きな可能性を感じました。
- 操作が非常に簡単: IPアドレスやポート番号をベースにしたポリシー作成は非常に直感的で、セキュリティの専門家でなくても基本的な設定は迷うことなく行えそうです。
- ハードウェア処理の効果: CX10000によるマイクロセグメンテーションを実施してもパケットをDPUで処理するため、遅延が大きく増加するようなことはありませんでした。パフォーマンスを犠牲にしない点は、インフラ担当者にとって非常に嬉しいポイントです。
- East-Westトラフィックの可視化: PSMのダッシュボードでは、どのサーバー間でどのような通信が発生しているかがリアルタイムで可視化されます。これまでブラックボックスになりがちだった内部通信を把握できるだけでも、セキュリティ運用上、大きな価値があります。
最後に
今回の検証で、HPE Aruba Networking CX10000が、セキュリティを強化できるポテンシャルを秘めた製品であることがよく分かりました。
スイッチがネットワークの接続性を提供するだけでなく、サーバー直近の「門番」としてきめ細やかなセキュリティを提供する。これにより、構成はシンプルになり、パフォーマンスは向上し、運用管理は楽になります。
特に、以下のような環境で大きな価値を発揮すると感じました。
- ランサムウェア対策を本気で強化したいデータセンター
- VMwareやProxmoxなどの仮想環境のセキュリティをシンプルに保ちたい企業
- HCI（ハイパーコンバージドインフラ）を導入しており、外部ファイアウォールとの連携に課題を感じている環境
CX10000は、ネットワークとセキュリティの垣根を取り払い、ゼロトラスト時代にふさわしい新しいデータセンターの形を提案してくれます。
最後までお読みいただき、ありがとうございました。
5. Appendix. A
シナリオ1：【基本編】同一セグメント内のICMP通信を止めてみる
マイクロセグメンテーション実施前
マイクロセグメンテーションを実施していないため、どの仮想マシンからも疎通ができています。
| server01から疎通確認 | server02から疎通確認 |
|
nelco@server01:~$ ping 192.168.100.2 -c 2 --- 192.168.100.2 ping statistics ---
--- 192.168.100.3 ping statistics ---
--- 192.168.100.4 ping statistics --- |
nelco@server02:~$ ping 192.168.100.1 -c 2 --- 192.168.100.1 ping statistics --- --- 192.168.100.3 ping statistics --- --- 192.168.100.4 ping statistics --- |
| client01から疎通確認 | client02から疎通確認 |
|
nelco@client01:~$ ping 192.168.100.1 -c 2 --- 192.168.100.1 ping statistics --- --- 192.168.100.2 ping statistics --- --- 192.168.100.4 ping statistics --- |
nelco@client02:~$ ping 192.168.100.1 -c 2 --- 192.168.100.1 ping statistics --- --- 192.168.100.2 ping statistics --- --- 192.168.100.3 ping statistics --- |
CX10000,Proxmoxに対してマイクロセグメンテーションをするための設定を行います。マイクロセグメンテーションCX10000に対してはPrivate VLAN、ポリシーの設定、ProxmoxにはIsolate Portsの設定を行います。
CX10000設定
| CX10000 (Private VLAN設定) |
|
vrf MicroSeg vlan 100 interface 1/1/1 interface vlan 100 |
ポリシー設定：PSM(Pensando Policy and Services Manager)上でポリシー設定表に基づいて設定を行います。（ICMP通信のみ）
| 設定ポリシー（一覧表示） |
 |
| 設定ポリシー設定（プロトコル選択） | 設定ポリシー設定（アドレス選択） |
 |
 |
| icmpを選択します。 | SourceIPおよびDestinationIPをポリシー表に基づいて設定を行います。 |
Proxmox設定
| Linux Bridge作成 |
 |
| CX10000と接続するNIC（ここではeno4）に紐づくLinuxBridgeを作成します。ここではpvlanという名前に設定します。 |
| ゾーン作成（データセンター -> SDN -> ゾーン） | VNets作成（データセンター -> SDN -> ゾーン） |
 |
 |
| 先ほど設定したLinuxBridge(pvlan)に紐づくゾーンを作成します。 |
先ほど作成したゾーンに紐づくVNetsを作成します。Isolated PortsおよびVLAN awareにチェックを入れます。Isolated Portsにチェックを入れることで仮想マシン間を直接通信することができなくなります。 完了後に適用を選択し、反映させます。 |
| 仮想マシンへNICを割り当て |
 |
| server01,server02,client01,client02にNICを追加します。先ほど作成したVNetsをブリッジとして選択できるようになります。 |
動作確認(ポリシー適用後)
| server01(192.168.100.1) | server02(192.168.100.2) |
|
root@server01:~# ping 192.168.100.2 -c 2 --- 192.168.100.2 ping statistics ---
--- 192.168.100.3 ping statistics --- root@server01:~# ping 192.168.100.4 -c 2 --- 192.168.100.4 ping statistics --- |
root@server02:~# ping 192.168.100.1 -c 2 --- 192.168.100.1 ping statistics --- root@server02:~# ping 192.168.100.3 -c 2 --- 192.168.100.3 ping statistics --- root@server02:~# ping 192.168.100.4 -c 2 --- 192.168.100.4 ping statistics --- |
|
server02(192.168.100.2)に対してのみ疎通できます。 |
いずれの仮想マシンに対して疎通できません。 |
| client01(192.168.100.3) | client02(192.168.100.4) |
|
root@client01:~# ping 192.168.100.1 -c 2 --- 192.168.100.1 ping statistics ---
--- 192.168.100.2 ping statistics --- root@client01:~# ping 192.168.100.4 -c 2 --- 192.168.100.4 ping statistics --- |
root@client02:~# ping 192.168.100.1 -c 2 --- 192.168.100.1 ping statistics ---
--- 192.168.100.2 ping statistics --- root@client02:~# ping 192.168.100.3 -c 2 --- 192.168.100.3 ping statistics --- |
|
server01,client02に対して疎通できます。 |
server01,client01に対して疎通できます。 |
6. Appendix. B
シナリオ2：【実践編】Webサーバーへのアクセスを制御する
PSMと呼ばれるGUI管理ツールを使って、より実践的なポリシーを作成しました。PSMでは「許可クライアント」や「Webサーバー」といったオブジェクトをIPアドレスで定義し、可視化された通信フロー図上（ネットワークグラフ）で対象フローを選択し、該当通信の許可/拒否するかを設定できます。
| client01 -> server01へhttp通信 | client02 -> server01へhttp通信 |
| nelco@client01:~$ curl GET http://192.168.100.1 curl: (6) Could not resolve host: GET curl: (28) Failed to connect to 192.168.100.1 port 80 after 134355 ms: Couldn't connect to server |
nelco@server02:~$ curl GET http://192.168.100.1 curl: (6) Could not resolve host: GET curl: (28) Failed to connect to 192.168.100.1 port 80 after 134119 ms: Couldn't connect to server |
| ポリシー設定画面（フロー可視化） |
 |
| 該当フローを選択 | ポリシー設定（プロトコル選択） | ポリシー設定（IP選択） |
 |
 |
 |
| ネットワークグラフ上から該当のフローを右クリックし「Add Flows to Policy」をクリックします。 | 選択対象フローのプロトコル情報が選択済みの状態でウィンドウが表示されます。 |
同様に選択対象のIPが指定済みの状態で表示されます。 |
動作確認
| client01 -> server01へhttp通信 | client02 -> server01へhttp通信 |
|
nelco@client01:~$ curl GET http://192.168.100.1 <p>For online documentation and support please refer to <p><em>Thank you for using nginx.</em></p> |
nelco@client02:~$ curl GET http://192.168.100.1 curl: (6) Could not resolve host: GET curl: (28) Failed to connect to 192.168.100.1 port 80 after 136007 ms: Couldn't connect to server |
このポリシーを適用した結果、狙い通り「許可クライアント」からWebページにアクセスでき、「不許可クライアント」からはアクセスがタイムアウトする結果となりました。
ポリシー適用後に該当フローも通信ができるようになっているとネットワークグラフ上から確認ができます。（許可：緑色の矢印 不許可：橙色の矢印）
エンジニアブログ
Stech I Labに関するお問い合わせは、
こちらのフォームからご連絡ください。
