柳 松　クラウドプラットフォーム技術部 クラウド技術グループ

これまで、ネットワークアーキテクトのセキュリティ戦略は、企業のビジネスにとって重要なデータを外部から分離する、目に見えないネットワーク防衛境界線(network perimeter)に向けていました。境界内のアクセスは信頼できると見なされており、脅威ではなかったため、境界内では、情報へのアクセスはほとんど制限されていませんでした。しかし、最近多発しているサイバー攻撃により、境界内であっても、アクセスの信頼性を確保することが課題になっています。

１．クラウド環境のサイバー攻撃

クラウドサービスの利用が拡大していることで、クラウド環境に対するサイバー攻撃が増加しています。侵入事件などもニュースにも大きく取り上げられています。下記２つの例は典型的な攻撃方式です。

① クリプトマイニング(他人の端末を乗っ取って無断で仮想通貨の採掘（マイニング）を行う)

② Kinsingマルウェア(脆弱なDockerサーバーを標的とするマルウェア)

クラウド環境では、攻撃を仕掛ける入口は様々にあります。例えばDocker、Kubernetes、Linuxアプリ、WAFの脆弱性、また設定ミスなど多様性があります。上記赤い枠に強調している通り、共通点は、入口から侵入した後、内部で“信頼”されたために接続の正当性は確認しないことを利用した攻撃である点です。

２． マイクロセグメンテーション紹介

これまでファイアウォールで行われてきたセキュリティ対策に加えて、ファイアウォールでは検知できない標的型攻撃に対応するセキュリティ対策としてマイクロセグメンテーションを紹介します。

「マイクロセグメンテーション」はネットワークを複数のセグメントまたはサブネットに分割するアーキテクチャ上のアプローチであり、それぞれが独自の小さなネットワークとして機能します。これにより、ネットワーク管理者は細かなポリシーに基づいてサブネット間のトラフィックのフローを制御できます。組織はセグメンテーションを使用して、監視の改善、パフォーマンスの向上、技術問題の特定、そして最も重要なセキュリティの強化を行えます。

以下図のように、従来は内部ネットワークと外部インターネット境界に配置された物理ファイアウォールによって、社内外の境界を守る「境界防衛セキュリティ」でした。標的型攻撃対策ではインターネットだけでなく、企業の内部ネットワーク通信も精査する「ゼロトラスト」(zero trust)環境を実現する必要があります。マイクロセグメンテーションは全てのアクセスを信頼せず、アクセス管理することができます。

楽天クラウドはVMware社NSX-Tのマイクロセグメンテーション技術をOpenStackプラットフォームと組み合わせ、アプリケーション間およびワークロード間で脅威が水平方向へ拡散するのを阻止します。

以下図はマイクロセグメンテーションを実現する方法です。左側の課題は：
• ネットワーク Hair-pinning(異なるサブネット通信は必ずファイアウォール経由)
• VLAN/サブネットの中でアクセス制限なし
• Lateral(水平方向)攻撃展開

解決方法は分散型ファイアウォールです。ネットワークセグメントをVM単位で細分化して、セキュリティセグメントの細分化を行う方法です。
• Software defined network（SDN）により境界にある物理ファイアウォールは不要
• ファイアウォールサービスは各VMのvNIC単位で払い出しが可能、分散型ファイアウォールによりVM最小権限、Lateral侵害防止を実現
• ファイアウォールポリシーを一元管理

３． Demo

楽天クラウドではセキュリティグループ機能を使ってマイクロセグメンテーションを実現することができます。セキュリティグループは、外部からインスタンスへの通信を、あらかじめ定義されたルールに従ってフィルタリングする機能です。ルールはセキュリティーグループ単位で⾏います。通信の制御はプロトコル毎、ポート単位、ソースIP(CIDR で指定)で条件指定が可能です。セキュリティグループ設定が終わったらインスタンスに割当てます。

DemoはWebアプリケーションの3層アーキテクチャを想定しています。ネットワークトポロジーとリソースデータは以下図と表をご参考ください。

作業手順は以下の通りです。
① ネットワークを作成します。
　　　　bas-network：踏み台VM専用ネットワーク
　　　　web：ウェブ層ネットワーク
　　　　app：アプリケーション層ネットワーク
　　　　db：データベース層ネットワーク
② 各ネットワークとルーターを繋ぎます。
③ 以下図の通り、default、grpA-db-policy、Bastionセキュリティグループを作成します。defaultはグループ内のVMのSSH開放設定です。

grpA-db-policyはデータベースVMの5432ポートを192.168.8.24(grpA-app01)にアクセス開放設定するためのものです。インスタンスを作成する前には、DHCPで振り分けられるPアドレスはわかりません。本セキュリティグループはインスタンス作成後に追加し、grpA-db01に割り当てます。

Bastionは外部から踏み台へのアクセス用ポリシーです。ポート22とICMP(pingコマンド用)アクセスを指定されたIP範囲に開放します。

④ 上記情報を使ってすべてのインスタンスを作成します。(DHCPを使ってIPアドレスをランダムに振り分けるのでIPが一致しなくても無視してください)
⑤ Bastionにsshで登録します。セキュリティグループdefaultによりすべてのVMにssh(port 22)が可能ですが、他のアクセスが禁止となります。下記コマンドで、ポート22と80アクセスをテストします。想定通り、ポート22はopenしていますが、80はfiltered(このポートが開いているかどうかを判別できない)です。

[r-user@bastion ~]$ nmap -Pn -p 22,80 192.168.9.4

Starting Nmap 6.40 ( http://nmap.org ) at 2020-08-24 22:43 JST
Nmap scan report for 192.168.9.4
Host is up (0.0063s latency).
PORT   STATE    SERVICE
22/tcp open     ssh
80/tcp filtered http

Nmap done: 1 IP address (1 host up) scanned in 1.26 seconds

nmapコマンドをインストールされない場合は下記コマンドでインストールできます。

sudo yum -y install nmap

セキュリティグループで許可しない限り、同じネットワークのVM間にもアクセス不可です。grpA-web01をssh登録してテストをします。grpa-web02にpingしても通りませんが、同じネットワークのゲートウェイ(192.168.7.1)にpingしたらOKとなります。

[r-user@grpa-web01 ~]$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether fa:16:3e:32:df:7a brd ff:ff:ff:ff:ff:ff
   inet 192.168.7.18/24 brd 192.168.7.255 scope global dynamic eth0

[r-user@grpa-web01 ~]$ ping -c 5 192.168.7.14
PING 192.168.7.14 (192.168.7.14) 56(84) bytes of data.

--- 192.168.7.14 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

[r-user@grpa-web01 ~]$ ping -c 5 192.168.7.1
PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data.
64 bytes from 192.168.7.1: icmp_seq=1 ttl=64 time=4.53 ms
64 bytes from 192.168.7.1: icmp_seq=2 ttl=64 time=2.75 ms
64 bytes from 192.168.7.1: icmp_seq=3 ttl=64 time=2.05 ms
64 bytes from 192.168.7.1: icmp_seq=4 ttl=64 time=2.00 ms
64 bytes from 192.168.7.1: icmp_seq=5 ttl=64 time=2.40 ms

--- 192.168.7.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 2.003/2.747/4.530/0.933 ms

もちろんgrpA-web01からでもポート22は疎通確認できますが、80はNGです。

[r-user@grpa-web01 ~]$ nmap -Pn -p 22,80 192.168.7.14

Starting Nmap 6.40 ( http://nmap.org ) at 2020-08-25 10:26 JST
Nmap scan report for 192.168.7.14
Host is up (0.0070s latency).
PORT   STATE    SERVICE
22/tcp open     ssh
80/tcp filtered http

Nmap done: 1 IP address (1 host up) scanned in 1.25 seconds

⑥ セキュリティグループgrpA-db-policyをテストします。grpA-db-policyはgrpA-db01に割り当てされているので、grpA-app01からgrpA-db01のポート5432にアクセス可能ですが、他のVM(例としてgrpB-web01を検証)からのアクセスはfilteredとなります。

[r-user@grpa-app01 ~]$ nmap -Pn -p 22,80,5432 192.168.9.4

Starting Nmap 6.40 ( http://nmap.org ) at 2020-08-25 10:29 JST
Nmap scan report for 192.168.9.4
Host is up (0.0048s latency).
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   filtered http
5432/tcp closed   postgresql

Nmap done: 1 IP address (1 host up) scanned in 1.26 seconds

grpB-web01に登録してテストします。

[r-user@grpb-web01 ~]$ nmap -Pn -p 22,80,5432 192.168.9.4

Starting Nmap 6.40 ( http://nmap.org ) at 2020-08-25 10:31 JST
Nmap scan report for 192.168.9.4
Host is up (0.0065s latency).
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   filtered http
5432/tcp filtered postgresql

Nmap done: 1 IP address (1 host up) scanned in 1.25 seconds

Nmapに認識されるポート状態のclosedは、アクセス可能(Nmapのプローブパケットを受信したり応答したりする)ではありますが、そこで受信待機しているアプリケーションはないことを意味します。

４．まとめ

クラウド環境ならではのスケーラビリティや可用性などメリットを最大限に享受するためには、下記運用ベストプラクティスを念頭に置いて、潜在的リスクを最小限にしましょう。
• インスタンス設定マニュアルに沿って手順通りインスタンスを作成
• セキュリティグループを使って必要のない権限を禁止
• セグメンテーション設計に細心の注意を払うことで、ネットワーク内に水平方向に拡散しようとする攻撃に対して対抗

現在、楽天クラウドにおいて次世代セキュリティ仮想アプライアンスサービスを準備中です。より一層のセキュリティ強化となるオプションにご期待ください。

楽天クラウド：https://cloud.rakuten.co.jp/

柳 松
外資系ITメーカー入社、ストレージソリューションSEから始め、アーキテクト、プレセールス、ビジネスデベロップメントを経験。インフラ系から現職のクラウド系新規サービス開発にチャレンジ中。最近の趣味は読書。特に歴史と社会に興味を持っている。理科と違って、正解のない世界を面白く感じている。