RDP cambia o cliente: por que a base de datos ve outro host

A túa regra de VPN denega a base de datos e o ticket péchase como unha avaría do cortafuegos, mentres o mesmo usuario abre un escritorio publicado e consulta esa base sen problemas. Ambas as afirmacións son certas. O escritorio é outro cliente, coa súa propia dirección nun segmento no que as regras xa confían, e coa súa propia identidade cando conecta cara adiante. O que parece unha regra contraditoria adoita ser unha segunda solicitude que ninguén puxo na revisión.

A segunda solicitude ten a súa propia dirección de cliente

Cando unha aplicación dentro da sesión abre unha conexión á base de datos, o saúdo TCP comeza no host da sesión. A súa dirección de orixe pertence á rede dese host, así que cada enrutador e cortafuegos de base de datos do camiño avalía o segmento do escritorio e non o conxunto de túneles do que veu o teu portátil. A dirección VPN nunca aparece nese fluxo. Por iso unha regra de denegación por orixe pode ser correcta e irrelevante ao mesmo tempo.

Le a orixe desde dentro da sesión e non desde o portátil, e despois proba o camiño seguinte desde o mesmo lugar. As dúas respostas deberían coincidir sobre que host fai a solicitude.

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

Compara o que informa a sesión coa dirección que a base de datos rexistrou para o mesmo instante. Cando o rexistro do servidor mostra a subrede do escritorio en lugar do conxunto de túneles, a pregunta deixa de ser se a regra se activou e pasa a ser que host fixo a solicitude. Iso é outra investigación con outro responsable.

A identidade tamén cambia, non só o direccionamento

A conexión posterior adoita autenticarse como o token da sesión, unha credencial almacenada ou unha conta de servizo da aplicación, e o recurso rexistra o que se lle deu. Por iso un rastro de auditoría que mostre unha conta de servizo na base de datos non demostra que unha persoa executase a consulta. Tampouco identifica a persoa. Só o rexistro de sesión do propio escritorio une eses dous rexistros.

A autorización ocorre dúas veces, e a segunda decisión tómase con datos distintos. A primeira concede un inicio de sesión de escritorio a un usuario concreto, mentres que a segunda concede o que o token dese usuario ou a conta da aplicación poden facer co recurso. Un grupo de asistencia que pode abrir un escritorio non é automaticamente un grupo que pode ler unha táboa de clientes.

Mira o token e a ruta de delegación antes de escribir a nota de acceso. Ambos son visibles desde dentro da sesión, e é o único lugar onde a resposta non é unha suposición.

whoami /groups
klist
query session

Se a aplicación usa unha conta de servizo, os seus dereitos son os que importan despois. Rotar esa credencial pertence á revisión de acceso, non a unha reflexión operativa posterior.

Por que o camiño directo segue bloqueado, e con razón

A regra de denegación non é errónea só porque o destino sexa alcanzable por outra vía. A segmentación avalíase por orixe, e o escritorio está nun segmento que se permitiu moito antes de que ninguén o pensase como ruta á base de datos. Nada eludiu a política. A política só describe dúas fontes distintas con dous resultados distintos.

O que a revisión debe responder é que pode iniciar cada sesión autorizada nese host. Os navegadores con sesións gardadas, as unidades asignadas, os axentes que gardan credenciais e os servizos que escoitan localmente amplían todos o alcance do escritorio, e ningún deles aparece no ticket que concedeu o inicio de sesión. Ese inventario é a superficie real de permisos.

Enumérao desde dentro dunha sesión de proba, non desde unha folla de cálculo. Un puñado de ordes cobre a maior parte da superficie.

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

Escolle o límite a propósito

Tres formas encaixan en tarefas distintas, e a elección debe seguir a tarefa e non a ferramenta que casualmente existe. Unha aplicación publicada expón un programa cos seus propios permisos, un escritorio completo expón todo o que pode facer o perfil do usuario, e unha conta de base de datos de alcance reducido cunha restrición de orixe expón un recurso sen ningún escritorio. A forma máis estreita que aínda completa o traballo é a que hai que documentar. Calquera cousa máis ampla necesita unha razón escrita ao lado.

Para un único informe, unha aplicación publicada ou unha conta restrinxida é unha concesión menor que un escritorio xeral. Para o mantemento que realmente necesita varias ferramentas, o escritorio pode ser correcto, pero entón a aprobación describe todo o host e non unha aplicación. Pregunta ao propietario do recurso a cal desas opcións está dicindo que si.

O movemento de datos é un interruptor aparte. O portapapeis, a redirección de unidades e as descargas poden levar datos da empresa ao cliente, e executar unha aplicación en remoto non mantén os datos en remoto por si só.

Comproba as dúas aprobacións e a ruta de retirada

Dúas aprobacións pertencen ao rexistro: o dereito a chegar e abrir o escritorio, e o dereito a usar recursos desde dentro. Nomea un propietario para cada unha e mantén a segunda visible para quen revise o recurso. É esa segunda entrada a que preguntará un auditor, porque describe alcance e non entrada. Escribe ambas antes de que se aprobe o cambio, non despois do primeiro incidente.

Despois proba a retirada, porque unha sesión desconectada pode sobrevivir á razón que a xustificaba. A táboa de sesións é o lugar máis rápido para ver que segue en marcha.

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

Desconectar o cliente deixa a sesión remota en marcha, e as súas conexións de rede e credenciais na caché poden seguir sendo utilizables ata que esa sesión remate. Pecha a sesión, ou termínaa explicitamente, e confirma que o contador posterior deixa de avanzar despois. Unha proba de retirada que só pecha a tapa do portátil non demostra nada. Fai a mesma proba unha vez coa conta desactivada e outra co permiso de escritorio retirado, e despois anota que rexistrou o recurso en cada caso.