What's

AWS Client VPNの検証を実施した。
検証で判明したメリット・デメリットなど、本格導入に向けて情報をまとめる。
なお以下ではAWS Client VPNをClient VPNと省略する。

導入前の環境

検証の話に入る前に2020/04時点での環境を記しておく。
AWS上にOpenVPN EC2インスタンスを構築してOpenVPN + 同VPC内に構築された踏み台経由でAWSのリソースにアクセス可能になっている。つまり、AWS上に構築していてインターネットに公開していない管理画面やデータベースに社外からアクセスするためには、VPNを張って踏み台経由するSSH Port Forwardingする必要がある。

構築内容

構築手順については公式ドキュメントを参照されたい。

クライアントCIDR
- 192.168.128.0/22
アクセス可にしたVPCサブネットは2つ
セキュリティグループ
- インバウンド
  - プライベートアドレス帯からのアクセスのみ許可
- アウトバウンド
  - 全て許可
認証
- 相互認証 (証明書ベースでサーバ・クライアント認証)
DNS
- デフォルトのAmazon DNS
プロトコル
- UDP
スプリットトンネル有効化 (インターネットとAWS Resouceへのトラフィックを分離)
ログ
- Cloudwatch Logs
- ロググループ /aws/client-vpn
- ログストリーム test

クライアントソフトウェア
- AWS Client VPN for Desktop (MacOS)

検証事項

検証したことは以下の4つである。

1. 踏み台なしでピアリング先のEC2へSSH
2. SSH Port ForwardingなしでHTTP接続
3. SSH Port ForwardingなしでAurora MySQLへ接続
4. Route53で管理しているドメインへアクセス
5. 許可していないAWS Resourceへのアクセス

検証結果

2020/04時点の環境であるOpenVPNとClient VPNのケースを比較しながら検証結果を述べていく。

1. 踏み台なしでピアリング先のEC2へSSH

OpenVPN → ❌

OpenVPNは各VPCへのルートテーブルを保持していないので、ピアリング先のVPCへアクセスするために踏み台を経由しなくてはならない。
踏み台なしではもちろん他のVPCにあるEC2へのアクセスはできなかった。

Client VPN → ⭕️

Client VPN経由で許可しているVPCにあるEC2へのSSH接続ができた。よってClient VPNを使用している時には踏み台なしでアクセス可能なことが分かった。

2. SSH Port ForwardingなしでHTTP接続

OpenVPN → ❌

OpenVPNの場合、SSH Port Forwardingなしでは本来のURLを直叩きでアクセスすることはできなかった。

Client VPN → ⭕️

本来のURLを直叩きでアクセス可能になった。ちなみにセキュリティグループで送信元IPがプライベートアドレス帯で宛先ポートが80・443を許可していることが前提となる。

3. SSH Port ForwardingなしでAurora MySQLへ接続

OpenVPN → ❌

Client VPN → ⭕️

踏み台なしでアクセスできるので接続の安定性は増した

4. Route53で管理しているドメインへアクセス

構築したClient VPNのDNSサーバはデフォルトのAmazon DNSである。
そのDNSサーバを使用してRoute53で管理しているドメインへアクセスできるか検証した。
前提としてそのRoute53を所有しているアカウントでRoute53 Resolverの設定はしていない。

OpenVPN → ❌

Client VPN → ❌

別アカウントのRoute53で管理しているドメインを名前解決できないことが分かった。
解決方法は2つ考えられる。
まず1つ目は、ドメインを所有しているアカウントでインバウンドのRoute53 Resolverを作成して、Client VPNエンドポイントにそのResolverがあるVPCサブネットへアクセス許可することだ。
もう1つはOpenVPNで設定しているDNSサーバをClient VPNエンドポイントでも利用する方法である。それはカスタムDNSサーバとして設定すればできる。

5. 許可していないAWS Resourceへのアクセス

アクセス許可していない任意のVPCサブネット上のリソースへ本当にアクセスできないか検証した。こちらはClient VPNだけの検証なのでClient VPNの結果のみ記載する。

Client VPN → ❌

Client VPNで許可していないVPCサブネット上のリソースへはアクセスできなかった。これは期待通りである。

メリット

踏み台をなくせる

OpenVPN AMIを使ってEC2で運用しているが、その仕組み上他のアカウントのリソースへアクセスするためには踏み台が必要になる。
Client VPNを使用すれば許可されているVPCサブネットにあるリソースに直接アクセス可能になる。社内と同様の方法でリソースにアクセスでき、踏み台やSSH Port Forwardingなどリモートワーク専用の設定をする必要がなくなる。社外で開発する際のストレスは減少するだろう。

サーバの管理不要

踏み台の管理不要になるが、何よりOpenVPNの自前管理から解放されるメリットは大きいだろう。OpenVPNが社外からアクセスする時の入り口で、脆弱性や不正アクセスなどのサーバ自体のセキュリティを常に気にしなくてはいけない。しかし、Client VPNはAWSがマネジメントしてくれるのでサーバ自体の管理をしなくていい。もちろんログなどを監視することは必要だ。

認証・認可

Client VPNを導入するにあたり最も気になる部分であろう認証・認可に関して説明する。
現在のOpenVPNの認証・認可について詳細を把握していないので比較ができないので、Client VPNだけメリットを挙げる。
まず認証についてだが、サポートしているのはADを使った認証と証明書ベースの相互認証である。AD認証は今回検証できなかったが、既にAWS Directory Serviceを利用していればわざわざ構築する手間を省ける。認証を集中管理でき、ADの運用ノウハウもあれば相互認証より適しているだろう。またADがMFAをサポートしているので(相互認証ではサポートされていない)、セキュリティもある程度高められる。Simple ADはMFAをサポートできないので注意してほしい。
次に認可についてである。Client VPN エンドポイントにセキュリティグループとネットワークベースの認可を紐付けられる。セキュリティグループに関しては説明は省く。ネットワークベースの認可ではエンドポイント経由でアクセスできるVPCサブネットを制限できる。これらはエンドポイント毎に設定できるので、目的に応じて柔軟に設定可能だ。例えば、ステージングと本番用でエンドポイントを分けることもできる。
またADを使えばグループごとに認可を設けることができる。所属グループごとによってあるVPCへは接続できたりするので、Least Privilegeのセオリーを実現するのに役立つだろう。

デメリット(課題)

ルート数の制限

Client VPNではルートテーブルに設定できるルート数の上限が10である。言い換えれば、アクセスできるピアリング先のネットワーク上限数は9である。それ以上ある場合にはエンドポイントを作成するしかない。

証明書ベースの相互認証

今回AD認証を使用できなかったので相互認証で検証を行った。まず、相互認証を行うためには以下の準備が必要である。

CA局
サーバ証明書
サーバ秘密鍵
クライアント証明書
クライアント秘密鍵

CA局やサーバ証明書は1つ構築・作成すればいいが、問題はクライアント証明書と秘密鍵の扱いである。セキュリティの観点からクライアント証明書と秘密鍵は各人に発行すべきであるが、運用負荷が高い。またセキュリティを担保して渡す仕組みも作らなければならない。
このように十分なノウハウがなければ証明書ベースの相互認証は運用が大変である。

本格導入に向けて

全社的にClient VPNを導入する際のメリットや問題点を挙げる。

メリット・解決できること

踏み台不要
OpenVPNサーバ管理不要
オリジナルのホスト名でアクセス可能
柔軟な認可設定 (Least Privilege)
ローカルマシンにリモートワーク用の設定不要 (Client VPNの設定・アプリは必要)

問題・課題点

認証・認可

全面的に導入するならADベースの認証・認可が現時点のベストだろう。そうなるとセキュリティの観点からMFAは必須である。既にAWS Directory Serviceを導入しており、かつSimple ADでないなら簡単だが、導入していないまたはSimple ADの場合はハードルが高くなってしまう。

ルート数の上限

先にルート数の上限による問題点を示したが、以下では全社導入の観点から述べる。
アクセスできるVPCピア先のネットワーク数が限られるので、全社で1つのClient VPNエンドポイントを運用していくのは現実的ではないだろう。VPCのCIDR毎にルート追加せず、プライベートアドレスのクラス単位で一括設定をするのもありだが、Least privilegeや柔軟性の観点からベストプラクティスとは言えない。
現実的な解としてチーム単位やある程度設定・運用可能な単位でエンドポイントを作成するのがいいだろう。インフラ専用部隊があれば話は別だが、誰がどのチームが運用していくのかなど別の問題が生じる可能性がある。

まとめ

Client VPNの検証結果と考察をしてみた。Client VPNは管理対象のサーバを減らしてくれて、柔軟な認証・認可を提供してくれる。この点からでもClient VPNの導入価値は高いと思う。
既にADを運用していて、現在のリモートネットワーク環境にストレスを抱えている場合は導入検討してみてはいかがでしょうか？

Reference