世界初DPUを搭載したAruba Networking CX10000スイッチは、ハードウェアオフロードでステートフルファイアウォール、NAT、IPsecをスイッチ上で機能させることができます。
昨今、データセンターに対する攻撃が大規模化してきており、それに対してマイクロセグメンテーションが注目されてきています。
今回はCX10000を使ったマイクロセグメンテーションの実現方法を検証を通して紹介します。
ランサムウェアによる被害のニュースが後を絶ちません。一度企業のネットワークに侵入されると、ウイルスはあっという間にサーバーからサーバーへと感染を広げていきます。このようなサーバー間の通信、いわゆる「East-Westトラフィック」をいかに制御するかが、現代のセキュリティ対策の大きな課題となっています。
従来のファイアウォールによる「境界型防御」だけでは、内部に侵入された後の横展開を防ぐのは困難です。そこで注目されているのが、ゼロトラストの考え方に基づいた「マイクロセグメンテーション」です。これは、サーバー一つ一つを最小単位としてネットワークを細かく分離し、本当に必要な通信以外はすべてブロックする手法です。
しかし、これを実現するには複雑な設定や高価なライセンスやアプライアンスが必要で、導入のハードルが高いと感じている方も多いのではないでしょうか？
今回、そんな悩みを解決してくれるかもしれない、HPE Aruba Networking CX10000 スイッチを検証機として購入し、実機で検証を行いました。「スイッチ」がセキュリティポリシーを適用するとはどういうことなのか？その実力を徹底的にレビューします！
まず、今回検証したCX10000がどのような製品か簡単にご紹介します。
CX10000は、データセンター向けの高性能スイッチですが、ただのスイッチではありません。業界初の「分散サービススイッチ」として、内部にAMD Pensando社が開発したDPU (Data Processing Unit) という専用プロセッサを搭載しています。
このDPUが、これまで外部のファイアウォールや仮想アプライアンスが担っていたステートフルファイアウォールやNATといったセキュリティ機能を、スイッチ自身がハードウェアレベルで高速に処理してくれます。
CX10000を導入するメリットは大きく3つあります。
- 構成のシンプル化: トラフィックをわざわざ外部のファイアウォールを経由させる必要がなくなり、物理/仮想アプライアンスの削減とネットワーク構成の簡素化が期待できます。
- パフォーマンス向上: スイッチを通過するパケットを速度を落とさず高速にハードウェアで検査・処理するため、セキュリティを強化しつつ、低遅延な通信を維持できます。
- 運用の一元化: ファイアウォールポリシーはPensando Policy and Services Manager (PSM) という管理ツールから一元的に作成・適用でき、ネットワークとセキュリティの運用を統合できます。
検証環境
今回は以下のようなシンプルな環境を構築しました。
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コマンドによりWebサーバにアクセスできたことを確認できました。 |
Webサーバにアクセスできずタイムアウトしました。 |
考察
今回の検証を通じて、CX10000の大きな可能性を感じました。
- 操作が非常に簡単: IPアドレスやポート番号をベースにしたポリシー作成は非常に直感的で、セキュリティの専門家でなくても基本的な設定は迷うことなく行えそうです。
- ハードウェア処理の効果: CX10000によるマイクロセグメンテーションを実施してもパケットをDPUで処理するため、遅延が大きく増加するようなことはありませんでした。パフォーマンスを犠牲にしない点は、インフラ担当者にとって非常に嬉しいポイントです。
- East-Westトラフィックの可視化: PSMのダッシュボードでは、どのサーバー間でどのような通信が発生しているかがリアルタイムで可視化されます。これまでブラックボックスになりがちだった内部通信を把握できるだけでも、セキュリティ運用上、大きな価値があります。
最後に
今回の検証で、HPE Aruba Networking CX10000が、セキュリティを強化できるポテンシャルを秘めた製品であることがよく分かりました。
スイッチがネットワークの接続性を提供するだけでなく、サーバー直近の「門番」としてきめ細やかなセキュリティを提供する。これにより、構成はシンプルになり、パフォーマンスは向上し、運用管理は楽になります。
特に、以下のような環境で大きな価値を発揮すると感じました。
- ランサムウェア対策を本気で強化したいデータセンター
- VMwareやProxmoxなどの仮想環境のセキュリティをシンプルに保ちたい企業
- HCI（ハイパーコンバージドインフラ）を導入しており、外部ファイアウォールとの連携に課題を感じている環境
CX10000は、ネットワークとセキュリティの垣根を取り払い、ゼロトラスト時代にふさわしい新しいデータセンターの形を提案してくれます。
最後までお読みいただき、ありがとうございました。
マイクロセグメンテーション実施前
マイクロセグメンテーションを実施していないため、どの仮想マシンからも疎通ができています。
|
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 PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data. 64 bytes from 192.168.100.2: icmp_seq=1 ttl=63 time=0.569 ms 64 bytes from 192.168.100.2: icmp_seq=2 ttl=63 time=0.419 ms --- 192.168.100.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1027ms rtt min/avg/max/mdev = 0.419/0.494/0.569/0.075 ms root@server01:~# ping 192.168.100.3 -c 2 PING 192.168.100.3 (192.168.100.3) 56(84) bytes of data. --- 192.168.100.3 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1019ms root@server01:~# ping 192.168.100.4 -c 2 PING 192.168.100.4 (192.168.100.4) 56(84) bytes of data. --- 192.168.100.4 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1051ms |
root@server02:~# ping 192.168.100.1 -c 2 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. --- 192.168.100.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1037ms root@server02:~# ping 192.168.100.3 -c 2 PING 192.168.100.3 (192.168.100.3) 56(84) bytes of data. --- 192.168.100.3 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1035ms root@server02:~# ping 192.168.100.4 -c 2 PING 192.168.100.4 (192.168.100.4) 56(84) bytes of data. --- 192.168.100.4 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1032ms |
|
server02(192.168.100.2)に対してのみ疎通できます。 |
いずれの仮想マシンに対して疎通できません。 |
|
client01(192.168.100.3) |
client02(192.168.100.4) |
|
root@client01:~# ping 192.168.100.1 -c 2 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. 64 bytes from 192.168.100.1: icmp_seq=1 ttl=63 time=0.550 ms 64 bytes from 192.168.100.1: icmp_seq=2 ttl=63 time=0.364 ms --- 192.168.100.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1060ms rtt min/avg/max/mdev = 0.364/0.457/0.550/0.093 ms root@client01:~# ping 192.168.100.2 -c 2 PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data. --- 192.168.100.2 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1045ms root@client01:~# ping 192.168.100.4 -c 2 PING 192.168.100.4 (192.168.100.4) 56(84) bytes of data. 64 bytes from 192.168.100.4: icmp_seq=1 ttl=63 time=17.9 ms 64 bytes from 192.168.100.4: icmp_seq=2 ttl=63 time=0.351 ms --- 192.168.100.4 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.351/9.113/17.876/8.762 ms |
root@client02:~# ping 192.168.100.1 -c 2 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. 64 bytes from 192.168.100.1: icmp_seq=1 ttl=63 time=7.11 ms 64 bytes from 192.168.100.1: icmp_seq=2 ttl=63 time=0.411 ms --- 192.168.100.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 0.411/3.760/7.110/3.349 ms root@client02:~# ping 192.168.100.2 -c 2 PING 192.168.100.2 (192.168.100.2) 56(84) bytes of data. --- 192.168.100.2 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1003ms root@client02:~# ping 192.168.100.3 -c 2 PING 192.168.100.3 (192.168.100.3) 56(84) bytes of data. 64 bytes from 192.168.100.3: icmp_seq=1 ttl=63 time=0.575 ms 64 bytes from 192.168.100.3: icmp_seq=2 ttl=63 time=0.365 ms --- 192.168.100.3 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1052ms rtt min/avg/max/mdev = 0.365/0.470/0.575/0.105 ms |
|
server01,client02に対して疎通できます。 |
server01,client01に対して疎通できます。 |
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が指定済みの状態で表示されます。 Saveを行い設定を反映させます。 |
動作確認
|
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 |
このポリシーを適用した結果、狙い通り「許可クライアント」からWebページにアクセスでき、「不許可クライアント」からはアクセスがタイムアウトする結果となりました。
ポリシー適用後に該当フローも通信ができるようになっているとネットワークグラフ上から確認ができます。（許可：緑色の矢印 不許可：橙色の矢印）
-
2025年11月4日
HPE Aruba Networking CXスイッチの高可用性 - VSX設定手順
前回の記事では、VMware ESXi環境にArubaCXスイッチを4台デプロイし、OSPFルーティングの設定を行う手順を紹介しました。今回は、ArubaCXスイッチの高可用性機能である「VSX （Virtual Switching Ext
-
2026年3月26日 製造・倉庫DXの通信課題をROIで解く！ ー Wi-Fi vs ローカル5G(Celona)実データと事例で徹底比較セミナー
- 2026/03/26（木） 13:00-14:00
- オンラインセミナー（ZOOM）
- 【03/26(木)13:00-14:00】製造・倉庫DXの通信課題をROIで解く！ ー Wi-Fi vs ローカル5G(Celona)実データと事例で徹底比較セミナー
- 現場条件（ユースケース）をもとにCelonaとWi-FiのROIシミュレーション紹介 Wi-Fiを継続した場合 vs Celonaに切り替えた場合のコスト差・ROI比較を提示 DXを成功させるために通信の最適化は必須です。自社に合う無線は何か具体的に知りたい方、ご参加お待ちしてます。
- ローカル5Gプラットフォーム Celona（セロナ）
-
2025年11月5日 【11/05(水)13:00-14:00】製造・倉庫DXの通信課題をROIで解く！ー Wi-Fi vs ローカル5G(Celona)実データと事例で徹底比較セミナー
- 2025年11月05日（水）13:00-14:00
- Webセミナー
- 製造・倉庫DXの通信課題をROIで解く！ ー Wi-Fi vs ローカル5G(Celona)実データと事例で徹底比較セミナー
-
2025年11月4日 COMNEXT 2025 ローカル5G「Celona」 出展 登壇あり
- 2025年7月30日（水）～ 8月1日（金）10:00～17:00
- 東京ビッグサイト（南展示棟）
- COMNEXT 2025 ローカル5G「Celona」 出展 登壇あり
- ローカル5GプラットフォームCelona（セロナ）
-
2025年9月26日 【9/26(金)オフラインセミナー登壇】倉庫×無線 スマート物流勉強会～倉庫DXの潮流とローカル5G・無線活用アプリケーションの普及性～
- 2025年9月26日 (金) 15:00 - 17:00
- オープンイノベーション施設WAVE（株式会社フジテックス内）
- 倉庫×無線 スマート物流勉強会 ～倉庫DXの潮流とローカル5G・無線活用アプリケーションの普及性～
ProLabsは高品質かつ低価格のサードパーティ製光トランシーバーを提供いたします。業界標準規格品やベンダー互換品など豊富な製品ラインナップを揃えております。