Client VPN のセキュリティグループをいかに設定すべきか

AWS Client VPN のセキュリティグループについて考えてみました。
2020.05.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Client VPN エンドポイントにはセキュリティグループを関連付けられます。 このセキュリティグループはどのように設定するべきでしょうか?最初に私の考える結論を述べます。

結論

設定ミスによる予期せぬ通信を防ぐため、Client VPN エンドポイント専用のセキュリティグループを作成して適用しましょう。 (VPC に初期設定状態で存在する default セキュリティグループを使用しないようにしましょう。)

当該セキュリティグループにインバウンドルールは不要です。削除しましょう。

また、アウトバウンドルールはすべてのトラフィックを許可する設定にしておくのがオススメです。

セキュリティグループの役割について(おさらい)

セキュリティグループは AWS の各種リソースに適用できる仮想ファイアウォールです。

インバウンドルールおよびアウトバウンドルールにプロトコル・送信元(送信先)などを設定することでトラフィックを制御できます。この送信元(送信先)にはネットワーク CIDR や特定の IP アドレスのほか、セキュリティグループそのものを指定することもできます。

Client VPN におけるセキュリティグループ

Client VPN エンドポイントに適用される

Client VPN エンドポイントを作成する際、当該エンドポイントに適用するセキュリティグループを指定できます。

特にセキュリティグループを指定しない場合 VPC のdefault セキュリティグループが適用されるのですが、この default セキュリティグループには少々厄介な性質があります。

default セキュリティグループについて

上図は初期設定状態の default セキュリティグループです。この default セキュリティグループには当該セキュリティグループが適用されたリソース間のすべてのインバウンドを許可する ルールが設定されています。(以下、default セキュリティグループと書いた際にはこの初期設定状態を指すこととします。)

たとえば、EC2-A・EC2-Bという2つの EC2 インスタンスが存在するとします。両インスタンスに default セキュリティグループを適用した場合、両インスタンス間ではすべてのインバウンドトラフィックが許可されます。

また、EC2 などのいくつかのサービスにてリソース作成時にセキュリティグループを指定しない場合、この default セキュリティグループが自動的に適用されます。 (先に見た Client VPN エンドポイントのケースもこれに該当します。)

したがって、設定ミスなどの原因により新たなリソースに default セキュリティグループが適用されてしまった場合に予期せぬ通信を招く可能性があります。

本稿の本筋とは外れますが、AWS上のセキュリティ基準を評価する CIS AWS Foundation Benchmark の項目4.3においても default セキュリティグループのルール変更が推奨されております。 詳細については下記のブログなどをご参照ください。

insightwatchのセキュリティチェックでオールグリーンを目指す(その4: CISベンチマーク最終回 ネットワーク編)

どう設定すべきか?

では、Client VPN エンドポイント用のセキュリティグループをどのように設定すべきでしょうか。

セキュリティグループ本体

前述のとおり default セキュリティグループには固有の性質があります。設定ミスなどによる意図せぬ通信を防ぐため、Client VPN エンドポイント専用のセキュリティグループを作成しましょう。

インバウンドルール

インバウンドルールは不要ですので、設定しないようにしましょう。

「セキュリティグループにソースとなるIPやネットワークのアドレスを指定しないとClient VPN エンドポイントに接続できないのでは?」

と思われるかもしれませんが、そんなことはございません。ソースをどのように設定した場合でもClient VPN エンドポイントは通信を受け付けます。 *1

マネジメントコンソールから新規のセキュリティグループを作成した場合、初期状態でインバウンドルールなしとなっています。

アウトバウンドルール

ネットワーク運用ポリシーにも依存するところですが、Client VPN エンドポイントに適用するセキュリティグループでは原則としてすべてのアウトバウンド通信を許可します。 その上で、受信側のファイアウォールやClient VPNの承認ルールで制御する構成がスッキリすると思います。 (受信側で制御するケースについて次節で述べます。)

マネジメントコンソールから新規のセキュリティグループを作成した場合、初期状態ですべてのトラフィックを許可するアウトバウンドルールが存在しています。

インバウンドルールのソースとしての利用例

Client VPN エンドポイントにサブネットを関連付けると、当該サブネットには専用の ENI が作成されます。Client VPN エンドポイント作成時に設定したセキュリティグループは、実態として、この ENI に適用されます。また、このENIは定期的に作り直されるため、固定の IP アドレスをもたせることができません。

したがって、Client VPN エンドポイント経由で VPC 内のリソースにアクセスしたい場合、このセキュリティグループをソースとするセキュリティグループ(インバウンドルール)を作成し、アクセス先のリソースに割り当てると良いでしょう。

たとえば、Client VPN 経由の場合のみ上図 Public subnet にある EC2 インスタンスへ SSH 接続を許可したい場合、EC2 用セキュリティグループ (sg-bbb) に下記のインバウンドルールを設定します。

プロトコル ソース
SSH sg-aaa (Client VPN用セキュリティグループ)

終わりに

このブログがほんの少しでも世界を良くできれば嬉しいです。 コンサルティング部の西野 (@xiyegen) がお送りしました。

脚注

  1. したがって、AWS Client VPN には接続元 IP 制限をかけられません。その他の仕組み(証明書・ AD 認証・ SAML 認証など)でセキュリティを担保しましょう。