AWS Client VPN のルールはサブネットではなくリソースに置く

スタッフは VPC 内の一つのアプリケーションに到達する必要があり、同じインスタンス上のデータベースリスナーには到達してはなりません。そこで誰かが VPN エンドポイント用に二つ目のパブリックサブネットを追加し、要件を満たしたと言います。サブネットの配置はルーティングと可用性を変えます。一つのポートを与えたり取り上げたりはしません。要件を表す許可は宛先に、つまりリソースのセキュリティグループにあり、VPN の境界はそのルールが参照するハンドルを提供します。

サブネットの配置はルーティングであり、認可ではない

エンドポイントのネットワーク関連付けがどこにあるかで、どのルートテーブルがクライアントのトラフィックを運び、どの可用性ゾーンが障害を生き延びるかが決まります。どのインスタンスのどのポートにそのトラフィックが届くかは何も語りません。同じサブネットに関連付けた二つのクライアントも同じ送信元 ID で到着し、リソースはサブネット名で両者を区別できません。

代わりに要件から始めます。誰が呼び、どのリソースに、どのサービスポートへ、どの方向か。次に、その四つを宛先で表現できるルールモデルを選びます。この枠組みなら、余分なサブネットは設計から完全に消えます。

Client VPN の関連付けグループがそのハンドルです

サブネットに関連付けた AWS Client VPN エンドポイントでは、文書化された手順は具体的です。意図したセキュリティグループをエンドポイントのターゲットネットワーク関連付けに適用し、その Client VPN グループを送信元として、リソースのセキュリティグループで必要なトラフィックを許可します。

具体的には、アプリケーションインスタンスのグループは関連付けグループからのアプリケーションポートだけを許可し、それ以外は許可しません。AWS のリソースアクセスの手順がこの関係を説明しており、エンドポイントが関連付けるすべてのサブネットで同じグループポリシーを保つ価値があります。別のグループとの古い関連付けは、境界を静かに広げるからです。

そのルールは誰も認証しません。ログインは別の制御であり、リソースへの経路は三つ目です。要求が届く前に三つすべてが成り立つ必要があります。どれが失敗したかで正しい修正が決まり、ルールの変更が正解になるのは最初の一つだけです。

一つの関連付けグループが区別できないもの

同じ関連付けグループの背後のすべてのクライアントは、同じセキュリティグループの送信元としてリソースに到達します。役割の異なる二人の利用者はその層では区別できず、グループの名前やタグは関係ありません。Client VPN の外部グループ認可はディレクトリや SAML グループに対して宛先プレフィックスでアクセスを絞るもので、リソースの役割より粗く、ID システムではなくネットワーク境界として扱うべきです。

より細かい区別はアプリケーションに属します。ほとんどのスタッフに閉じておくべきデータベースリスナーは、グループの所属が整っていることを願うより、許可されたプレフィックス上でまったく到達できないようにする方がよく守られます。

グループの名前を変えても ID は生まれず、チームごとに複製すれば監査すべき関連付けが増えるだけです。

そのルールをすべての VPN 設計にコピーしてはいけません

自己管理の EC2 VPN ゲートウェイ、ルーティングされた検査アプライアンス、マネージド Client VPN は三つの異なるパケット経路です。どの送信元アドレスが実際にリソースへ届くのか、途中で変換が起きるのか、その経路上でサービスがどの参照方式を支えるのかを確かめます。

中間装置を経由させる転送は、インスタンス間の直接トラフィックのように送信元セキュリティグループの参照を保ちません。AWS は、そのような設計ではグループ参照の代わりに適切なプライベート送信元アドレスや CIDR が必要になりうると文書化しています。マネージド Client VPN の手順は、各ゲートウェイに付けたグループが転送パケットの万能な ID トークンとして機能する証拠ではありません。

経路上の NAT ホップが一つあれば仮定は崩れ、障害は存在するのに決して一致しないルールに見えます。

実効的な境界を確認します

リソースに付いたすべてのセキュリティグループを読みます。許可ルールは合算され、狭いルールが別グループの広いルールを打ち消すことはないからです。次にネットワーク ACL、ホストのファイアウォール、アプリケーション自身の認可を確認します。これらは別々の誤りを持つ別々の層です。

同じリソースに対して、許可される要求と意図的に除外される要求を一つずつ試して終えます。この組が境界を証明するのに対し、成功した接続一つは何かが開いていることしか証明しません。エンドポイントを含むサブネットではなく、経路、実効的な送信元、意図したサービスポートを確認します。

作業順序は、四部構成の要件を書き、グループを関連付けに結び、リソースのルールをポートに絞り、許可一つと拒否一つを検証し、その後になって初めてルーティング上の理由でサブネットを分けることを検討します。