VPNポートがベンチマークで検出された？まずコントロールの範囲を確認せよ

スキャナがVPNポートを検出し、チケットがそれを公開リスナーと言い換え、その後の議論は露出が実際に存在するかどうかになる。検出結果は、読み手が想定することをほとんど語らない。固定された範囲を持つベンチマークのコントロールを引用しており、ポート番号はその範囲への入力の一つにすぎない。

ポートを擁護する前にコントロールを読む。判決のように読める検出結果は、通常、一つのリソースに適用された述語である。

検出結果の行が実際に引用しているもの

ベンチマークの検出結果には、由来する文書とリビジョン、評価されたリソース、結果を引き起こした述語、監査が実際に達成したカバレッジという、分けて考える価値のある四つの要素がある。チームは通常、リソースだけを引用し、セキュリティグループやネットワークACLやホストを対象にして、そのうえでポートについて議論する。あなたのリスナーがそもそも範囲内にあったかを決めるのは述語である。それがなければ、規則ではなく数値を論じていることになる。

AmazonのSecurity Hubのドキュメントでは、課金されたPDFなしでもその切り分けが確認できる：EC2コントロールのページは、ポート22と3389の無制限アクセスに対するセキュリティグループの検査を列挙し、ネットワークACLを独自の条件を持つ別のリソースとして扱う。同じ管理ポートでも、対象が異なれば検査も異なる。検出結果が受け継ぐのはこの粒度である。

aws ec2 describe-security-groups --group-ids sg-0d1f8a2c4b6e9f3a1 --output json
aws ec2 describe-network-acls --filters Name=entry.port-range.from,Values=22 --output table

公開リスナーと管理アクセスを分ける

インターネットからUDP 1194を受け付けるVPNリスナーと、承認後にのみ到達できるSSHサービスは、異なる露出経路である。前者を覆う検査は後者について何も語らないことがあり、後者を覆う検査は前者を無視することがある。一方の合格は他方についての表明ではなく、二者が状況共有でどれほど似て聞こえても変わらない。

レビューでは各経路をそれぞれ独立した行として扱う。

次に、ゲートウェイ自体が何を許可しているかを確認する。トンネルを受け入れることは、ゲートウェイ上で管理権限を与えることと同じではなく、どちらもその背後のサーバーに到達することと等しくない。問いを、誰が接続でき、誰が管理でき、トンネルが何に到達できるかに分ける。これら三つの答えは異なるシステムから来ており、誰も行動できない一文に日常的にまとめられる。

ポートがそもそも範囲内かどうかを決めるのはリソースである

セキュリティグループの規則、サブネットACLのエントリ、ホストのファイアウォール規則は、いずれも通信を許可しうるが、コントロールが評価する対象になりうるのはそのうち一つだけである。実効的な許可とは、並行するグループ、両方のアドレスファミリー、そしてそれらの手前にある拒否規則を組み合わせることだ。グループ単位の検査に失敗するポートでも到達不能なままのことがあり、合格するポートでもさらに内側で遮断されていることがある。

別の環境の規則を持ち込むと失敗するのはここだ。ネットワークACLはステートレスで順序に従って評価され、セキュリティグループはステートフルで許可のみを行う。一方から借りた規則モデルは他方を記述せず、それを翻訳すると誤った対象について自信満々の答えを生む。

判断を記録し、次の監査で再利用できるようにする

範囲が本当に曖昧なときは、コントロールのリビジョン、リソース識別子、引用された述語、そしてそれを解決した証拠を書き留める。何を除外したか、なぜ除外したかも含める。その記録こそが、二番目のレビュー担当者がベンチマーク全体を読み直さずに同じ結論に達することを可能にし、人員の入れ替えを生き残る唯一のものである。

「VPNポートを確認済み」とだけ書いたメモは、来四半期に議論が戻ることを保証する。代わりに評価者、リビジョン、証拠を名指しせよ。