RDP はクライアントを変える：データベースが別のホストを見る理由

VPN のルールはデータベースを拒否し、チケットはファイアウォールの障害として閉じられます。一方で同じユーザーが公開デスクトップを開き、そのデータベースへ問題なく問い合わせています。どちらの記述も正しいのです。デスクトップは別のクライアントであり、ルールがすでに信頼しているセグメント上に独自のアドレスを持ち、先へ接続するときには独自の ID も持ちます。矛盾したルールに見えるものは、たいてい誰もレビューに入れていない二つ目の要求です。

二つ目の要求には独自のクライアントアドレスがある

セッション内のアプリケーションがデータベースへの接続を開くと、TCP のハンドシェイクはセッションホストで始まります。その送信元アドレスはそのホストのネットワークに属するため、経路上のすべてのルーターとデータベースのファイアウォールは、ノート PC が来たトンネルプールではなくデスクトップのセグメントを評価します。VPN のアドレスはそのフローに決して現れません。だからこそ送信元ベースの拒否ルールは、正しいまま無関係であり得るのです。

送信元はノート PC からではなくセッションの内側で読み、その同じ場所から先の経路を検証してください。二つの答えは、どのホストが要求しているかについて一致するはずです。

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

セッションが報告する内容を、データベースが同じ時刻に記録したアドレスと比較します。サーバーログがトンネルプールではなくデスクトップのサブネットを示すなら、問いはルールが発動したかどうかではなく、どのホストが要求したかになります。それは別の担当者による別の調査です。

ID はアドレッシングとともに変わる

先への接続は通常、セッションのトークン、保存された資格情報、またはアプリケーションのサービスアカウントとして認証され、リソースは与えられたものを記録します。したがって、データベース上のサービスアカウントを示す監査証跡は、人間がクエリを実行したことを証明しません。その人間を特定するものでもありません。デスクトップ自身のセッションログだけが、その二つの記録を結びつけます。

承認は二度行われ、二度目の判断は異なる入力で下されます。一つ目は指名されたユーザーにデスクトップのサインインを与え、二つ目はそのユーザーのトークンまたはアプリケーションのアカウントがリソースに対してできることを与えます。デスクトップを開けるヘルプデスクのグループが、自動的に顧客テーブルを読めるグループになるわけではありません。

アクセス記録を書く前に、トークンと委任の経路を確認してください。どちらもセッションの内側から見え、答えが推測でない唯一の場所です。

whoami /groups
klist
query session

アプリケーションがサービスアカウントを使うなら、下流で重要なのはその権限です。その資格情報のローテーションはアクセスレビューの一部であり、後回しの運用上の思いつきではありません。

直接の経路が今も正しく遮断されている理由

宛先に別の道で到達できるというだけでは、拒否ルールは誤りではありません。セグメンテーションは送信元ごとに評価され、デスクトップは誰かがデータベースへの経路と考えるよりずっと前に許可されていたセグメントに置かれています。ポリシーを回避したものは何もありません。ポリシーは、二つの異なる結果を持つ二つの異なる送信元を記述しているだけです。

レビューが答えるべきは、そのホスト上の認可されたセッションが何を起動できるかです。保存されたセッションを持つブラウザー、マップされたドライブ、資格情報を保持するエージェント、ローカルで待ち受けるサービスはすべてデスクトップの到達範囲を広げ、そのどれもサインインを与えたチケットには現れません。その一覧こそが実際の権限の表面です。

それを表計算ではなく、テストセッションの内側で列挙してください。いくつかのコマンドで表面の大半を覆えます。

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

境界は意図して選ぶ

三つの形はそれぞれ別の作業に合い、選択はたまたま存在する道具ではなく作業に従うべきです。公開アプリケーションは独自の権限を持つ一つのプログラムを公開し、完全なデスクトップはユーザーのプロファイルができることすべてを公開し、送信元制限付きの狭いデータベースアカウントはデスクトップなしで一つのリソースだけを公開します。作業をなお完了できる最も狭い形が、記録すべき形です。より広いものには、その横に理由を書く必要があります。

一つのレポートには、公開アプリケーションや制限付きアカウントのほうが一般的なデスクトップより小さな付与です。複数の道具を本当に必要とする保守なら、デスクトップが正しいこともありますが、そのとき承認は一つのアプリケーションではなくホスト全体を記述します。リソースの所有者に、どれに同意しているのかを尋ねてください。

データの移動は別のスイッチです。クリップボード、ドライブのリダイレクト、ダウンロードは会社のデータをクライアントへ運び、アプリケーションを遠隔で動かすこと自体はデータを遠隔に保ちません。

二つの承認と削除の経路を確認する

記録には二つの承認が属します。デスクトップに到達して開く権利と、その内側からリソースを使う権利です。それぞれに所有者を定め、二つ目をリソースをレビューする誰にでも見える状態にしてください。監査人が尋ねるのはその二つ目の記載です。入口ではなく到達範囲を記述しているからです。変更が承認される前に両方を書き、最初のインシデントの後に書くのではありません。

次に削除を検証します。切断されたセッションは、その理由より長く生き残ることがあるからです。セッションテーブルは、まだ動いているものを確認する最も速い場所です。

query session
query user
qwinsta /server:rdsh01.corp.internal

クライアントを切断してもリモートセッションは動き続け、そのネットワーク接続とキャッシュされた資格情報はセッションが終わるまで使えるままになり得ます。サインアウトするか、セッションを明示的に終了し、その後に下流のカウンターが進まなくなることを確認してください。ノート PC のふたを閉じるだけの削除テストは何も証明しません。同じテストを、アカウントを無効にした状態とデスクトップ権限を外した状態でそれぞれ一度行い、それぞれの場合にリソースが何を記録したかを書き留めてください。