VPC のリモートアクセス受け入れには拒否テストが必要だ

リモートアクセスの受け入れとは、期待される結果の表であり、動作するページのスクリーンショットではない。 グループごとに、何が成功し何が失敗すべきかを書き出し、管理された時間枠の中で専用のテスト ID を使って両方を実行する。 境界を証明するのは拒否の側であり、ログインの成功はトンネルが存在することしか証明しない。 これらはすべて、すでに選定済みの VPN 製品で機能する。

テストには専用のアカウントを使い、テスト用 ID が実際の例外と取り違えられないようにラベルを付ける。

境界を期待される結果として書き出す

コンポーネントではなくロールから始める、つまり誰がどのサービスを、どこから、どの ID で必要とするのか。 例としての VPC では、あるグループは HTTPS 経由でステージングを必要とし、別のグループは本番データベースを必要とし、さらに小さな第三のグループがゲートウェイ自体を管理する。 各行には、期待される許可と期待される拒否を書き、機能すべきでない隣接サービスや隣接アカウントも含める。 その表が受け入れ基準であり、テストを実行しない人でもレビューできる。

データベースへのログインは、ネットワーク経路とは別にテストする。 到達可能な TCP ポートがあっても、承認されていないデータベースアカウントが成功してはならず、VPN のメンバーシップがクラウドの IAM ロールを作成したり、管理用 API へのアクセスを付与したりしてはならない。 これらは三つの独立した制御であり、それぞれ独立に失敗する。

ルートは認可ではない

ルートは経路を可能にするが、許可を与えるものではない。 ルートを伏せるのは、クライアントがいつでも自分でルートを追加できるため、宛先で強制される制限の弱い代用にすぎない。 判断するのは、セキュリティグループ、データベースの付与、そしてアプリケーション自身の認可である。 テストが予想外に成功したときは、クライアントに持たせたかったルーティングテーブルではなく、まず宛先のポリシーを見る。

拒否のテストがサーバー側を狙うのも同じ理由で、その結果はクライアントを編集しても変えられない。

制御は実際にどの送信元を見ているのか。

制御が評価する送信元アドレスは、ゲートウェイのアーキテクチャによって決まる。 EC2 上にホストされたゲートウェイは、ルーティングされたプールを転送したり、自分のアドレスに変換したり、NAT の後に別のアドレスを提示したりし、マネージド Client VPN はサブネットに関連付けられて独自のモデルに従う。 セキュリティグループとネットワーク ACL は、その処理の後に到着するものを見る。 誤った送信元の前提でルールを検査するのは、正しく見えて誤ったトラフィックを通す境界を作るよくある方法である。

各結果は、ID とセッション、リソース、操作、時刻、そして判断という最小の有用なイベントと関連付ける。 CloudTrail の API 呼び出し、VPC フローログ、VPN セッションログはそれぞれ別の問いに答えるものであり、どれか一つだけではアプリケーションの監査にならない。

ID を失効させて、もう一度テストする

失効も同じ表に含める。 テスト用 ID を削除して新しいセッションが拒否されることを確認したうえで、所有者が異なり振る舞いも異なるため、既存のセッションの扱いを別に確認する。 ゲートウェイの再起動や交換の後に何が起きるかを確認し、手で追加した例外が黙って消えたり、より広く戻ったりしないようにする。 次のデプロイまでしかもたない境界は、境界ではない。

ここまでのどれも、パッチ適用、復旧、資格情報のライフサイクル管理の仕事を置き換えるものではない。 より狭い約束を測定可能にするもので、適切な人が適切なサービスに到達し、近隣のルート、アカウント、管理面は付与の外にとどまる。

表はデプロイと一緒に保管し、ゲートウェイが変わったら再実行する。 テストは安いが、その背後にある前提は安くない。