侵害されたウェブゲートウェイはどこまで到達できるのか
ウェブゲートウェイが制限するのは訪問者が開く先であり、侵害されたホストが接続できる先ではない。二つのレビュー、権限の表、到達範囲を確かめるコマンド。
ゲートウェイのホストが、証明書がまだ有効なうちに侵害されたとしよう。訪問者がどのページを要求できるかを定めていたルールはすべて有効なままであり、それらのルールはどれも、攻撃者が今そのホストからデータベースのサブネットへ向けて開く接続を制限しない。この隙間こそが、ウェブ専用の入口がセグメント化されたネットワークと同じ主張ではない理由である。二つの主張には、別々の出発点からの別々のレビューが必要であり、どちらも正直に語れるのはその後のことだ。
二つの主張、そして訪問者から始まるのはそのうち一つだけ
第一の主張は人についてのものだ。ブラウザと有効なセッションを持つ訪問者は、一つのアプリケーションだけを開け、それ以外は開けない。ウェブ専用の入口はこの主張によく答える。訪問者が受け取るのは経路ではなくページだからだ。その答えには価値があり、またほとんどの図が記録する唯一の主張でもある。
第二の主張は構成要素についてのものだ。ゲートウェイ、あるいはその背後のアプリケーション処理が、誰か他の人の管理下にあると仮定する。この仮定から、問いはどの URL が許可されるかから、その処理がまだどの宛先と ID に到達できるかへと変わる。
二つの主張は所有者が異なり、生み出す証拠も異なり、独立に失敗する。 ID チームはセッションテストで第一を示せる。第二にはネットワークポリシー、サービスアカウントのレビュー、ホストの制御が必要だ。訪問者の半分だけを記録する設計は、レビューのスライドでは完全に見え、インシデントの最中には薄く見える。侵害後に重要な制御が最初から対象外だったからだ。どの制御がどちらの主張を支えるのかを名指しせよ。さもなければ、一つのゲートウェイルールが両方の功績にされる。
経費サービスの実例と、それが失う二つの道
経費サービスを例に取ろう。 10.60.4.10 の公開ゲートウェイが職員を認証し、承認済みの要求をポート 8443 のアプリケーションリスナーへ転送し、そのアプリケーションが expenses_app ロールとして 10.60.4.20:5432 の PostgreSQL リスナー一つに到達する。職員は一般的な内部アクセスを与えられるべきではない。通常運用では、この設計はデータベースリスナーをどこにも公開せずにアプリケーション固有の入口を確かに提供する。アドレスが重要である理由は、本記事の以降の検査がすべてそれを名指しするからだ。
ではゲートウェイを信頼集合から外す。プロセスが攻撃者のものになったとき、 10.60.4.10 はどの宛先に到達できるのか。訪問者を制限していた URL フィルタは、ゲートウェイのホストがデータベースのサブネットへ向けて開く接続について何も語らない。
代わりにアプリケーション処理を外すと、権限の形が変わる。 expenses_app ロール、そのサーバーが到達できるサービス、そのアカウントが読めるファイルである。どちらの場合も、バックエンドの境界が欠けたまま入口だけをウェブ専用に保つことができる。したがって入口の表示は、二つの問いのどちらへの答えにもならない。
各当事者が実際に持つ権限を対応づける
意図された許可として書かれた契約は、設計をそのまま繰り返しがちだ。保有する権限、過剰を反証する検査、その検査の所有者として書けば、各行が検証可能になる。この表は上の例に対する提案であり、製品の主張ではない。
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
所有は権限に従う。 ID チームが表明を、ネットワークプラットフォームチームが経路を、アプリケーションチームがデータベースロールを、データベース管理者がリスナーとそのホストベースのルールを、プラットフォーム所有者が管理プレーンを所有する。所有者のない拒否は文書の一文であり、制御ではない。
この分割は二重計上も防ぐ。ポート制限はテーブル権限を表現できず、データベースロールはホストが無関係なサブネットへソケットを開くのを止められない。
主張するのではなく、ゲートウェイが到達できる先を数え上げる
境界の主張は、その背後の数え上げ以上のものではない。ゲートウェイのホストでは、三つのコマンドが経路選択、実地の検査、外向きのポリシーを覆う。
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter output出力はその順に読む。経路は 10.60.4.20 がそのホストからそもそも選ばれるかを語り、検査はリスナーが応答するかを語り、ルール一覧はポリシーがパケットを止めるのか、そもそも経路上に何もなかったのかを示す。
アプリケーションのホストから数え上げを繰り返す。そこから見たデータベース側は、アプリケーションロールで実行する一つの問い合わせだ。
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'別のスキーマを読めないロールでの接続成功は、所有者ロールでの接続成功とは異なる結果だ。発見と言えるのは後者だけである。
拒否を記録し、その後でレビューに日付を付ける
受入れは意図ではなく結果として書く。職員のセッションはリスナーに到達できず、ゲートウェイのホストは無関係なサブネットに到達できず、アプリケーションロールはデータベースを作成できない。それぞれが名前のある所有者と日付を持つ別個の検査だ。
監視、パッチ適用、復旧は、それらのために設計された管理経路から到達可能に保つ。所有者まで遮断する境界は障害になり、その障害への通常の第一反応はルールを再び広げることだ。 CISA の境界ガイダンス は、内部ネットワーク間の通信を含め、正当化されたポートとプロトコルに内向きと外向きのアクセスを限定するよう求めている。これはほとんどの図が省く、バックエンド起点の方向である。
レビューに日付を付け、その所有者を名指しする。ゲートウェイのイメージ、ルーティングテーブル、アプリケーションロールのいずれかを変更した後は、数え上げと権限の問い合わせを再実行する。