ポート間のファイアウォールはホスト境界ではない

ウェブサイトは443で応答し、VPNは1194で応答し、ファイアウォールはちょうどその二つだけを許可し、レビューは通る。その手順のどこにも、ウェブワーカーが何を読めるのか、どのファイルを書き換えられるのかを問うものはなかった。侵害されたワーカーは、制御用ソケットや書き込み可能な設定ディレクトリに到達できるなら、開いたポートを必要としない。境界とは権限であり、リスナーは目に見えやすい部分にすぎない。

別のサービス名はラベルにすぎず、別のアイデンティティこそがセキュリティ特性である。

ポートではなくワーカーの権限を数える

実行ユーザー、そのグループ、ケイパビリティ、ファイルシステムの見え方から始める。たまたまVPNグループに属するサービスアカウントは、ポートが一つも開いていなくても鍵素材を読める。書き込み可能なマウントがもう半分であり、アップロードとキャッシュはポリシーファイルや秘密から遠ざけるべきで、不要に共有された書き込み可能ディレクトリは整った命名を台無しにする。特権を持つ親と特権を持たないワーカーは同じ権限を共有しないため、その操作を実行するプロセスを確認する。

デーモンの起動時にVPN鍵が読めるからといって、ウェブワーカーがそれを必要とするわけではない。デーモンが行う読み取りと、アプリケーションに与えられるアクセスを分けて考える。

見た目より多くを与えるソケット

一部のエンドポイントは、メトリクスフィードの衣装をまとった管理用APIだ。VPNの管理インターフェースはセッションを変更し、クライアントを切断し、状態を読める。コンテナランタイムのソケットはさらに広く、そこへのアクセスは事実上ホストの制御であり、ウェブアプリケーションが必要とする範囲をはるかに超える。どちらも通常のアプリケーションのマウント集合に属さず、待ち受けポートを数えても現れない。

管理用リスナーをローカルアドレスにバインドすることは始まりであり、完全な制限ではない。そのアドレスへのあらゆる入口経路がいまも重要なのだから、意図した送信元とインターフェースだけを許可すべきである。

コンテナは一つのカーネルを共有する

コンテナはプロセス、ファイルシステム、ネットワークの境界を追加するが、ホストと一つのカーネルを共有するため、ケイパビリティの選択、ホストマウント、デーモンへのアクセスが決定的になる。ホストの秘密をマウントしたり特権的なランタイム制御を与えたりすれば、コンテナというラベルが示唆する境界は消える。別々のVMは確かに別々のゲストカーネルを与えるが、ハイパーバイザー、管理用アイデンティティ、ストレージ、バックアップは共有されたままだ。設定と更新に名前のある所有者がいる境界を選ぶこと。

誰も保守しない凝った構成は、実際にレビューされる単純な構成より悪い。

まず拒否を、次にサービスを試験する

ワーカーの実際のコンテキストで承認済みのチェックを使い、VPNポリシーを変更できないこと、不要な秘密を読めないこと、管理インターフェースに触れられないことを確認する。管理者としての読み取り成功は、その拒否について何も試験していない。次にウェブサイト、許可された通常のVPN操作、そして再起動時にそれぞれがどうなるかを検証する。VPNの修復に依存しない復旧経路を残し、誤りが復旧可能なままであるようにする。

両方の役割は依然としてCPU、メモリ、上り回線容量、保守イベントを共有する。権限の境界がきれいでも、これらの共有リソースは計画に含めるべきだ。

各プロセスが何をできるか、停止したときに何が失敗するか、どの境界が共有されたままかを記録する。ポート数はその記録ではない。