RDP cambia el cliente: por qué la base de datos ve otro host

Tu regla de VPN deniega la base de datos y el tique se cierra como una avería del cortafuegos, mientras el mismo usuario abre un escritorio publicado y consulta esa base sin problemas. Ambas afirmaciones son ciertas. El escritorio es otro cliente, con su propia dirección en un segmento en el que las reglas ya confían, y con su propia identidad cuando conecta hacia delante. Lo que parece una regla contradictoria suele ser una segunda solicitud que nadie incluyó en la revisión.

La segunda solicitud tiene su propia dirección de cliente

Cuando una aplicación dentro de la sesión abre una conexión a la base de datos, el saludo TCP comienza en el host de la sesión. Su dirección de origen pertenece a la red de ese host, así que cada enrutador y cortafuegos de base de datos del camino evalúa el segmento del escritorio y no el grupo de túneles del que vino tu portátil. La dirección VPN nunca aparece en ese flujo. Por eso una regla de denegación por origen puede ser correcta e irrelevante al mismo tiempo.

Lee el origen desde dentro de la sesión y no desde el portátil, y luego prueba el camino posterior desde el mismo lugar. Las dos respuestas deberían coincidir sobre qué host hace la solicitud.

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

Compara lo que informa la sesión con la dirección que la base de datos registró para el mismo instante. Cuando el registro del servidor muestra la subred del escritorio en lugar del grupo de túneles, la pregunta deja de ser si la regla se activó y pasa a ser qué host hizo la solicitud. Eso es otra investigación con otro responsable.

La identidad también cambia, no solo el direccionamiento

La conexión posterior suele autenticarse como el token de la sesión, una credencial almacenada o una cuenta de servicio de la aplicación, y el recurso registra lo que se le dio. Por eso un rastro de auditoría que muestre una cuenta de servicio en la base de datos no demuestra que una persona ejecutara la consulta. Tampoco identifica a la persona. Solo el registro de sesión del propio escritorio une esos dos registros.

La autorización ocurre dos veces, y la segunda decisión se toma con datos distintos. La primera concede un inicio de sesión de escritorio a un usuario concreto, mientras que la segunda concede lo que el token de ese usuario o la cuenta de la aplicación pueden hacer con el recurso. Un grupo de soporte que puede abrir un escritorio no es automáticamente un grupo que puede leer una tabla de clientes.

Mira el token y la ruta de delegación antes de escribir la nota de acceso. Ambos son visibles desde dentro de la sesión, y es el único lugar donde la respuesta no es una suposición.

whoami /groups
klist
query session

Si la aplicación usa una cuenta de servicio, sus derechos son los que importan después. Rotar esa credencial pertenece a la revisión de acceso, no a una reflexión operativa posterior.

Por qué el camino directo sigue bloqueado, y con razón

La regla de denegación no es errónea solo porque el destino sea alcanzable por otra vía. La segmentación se evalúa por origen, y el escritorio está en un segmento que se permitió mucho antes de que nadie lo pensara como ruta a la base de datos. Nada eludió la política. La política solo describe dos fuentes distintas con dos resultados distintos.

Lo que la revisión debe responder es qué puede iniciar cada sesión autorizada en ese host. Los navegadores con sesiones guardadas, las unidades asignadas, los agentes que guardan credenciales y los servicios que escuchan localmente amplían todos el alcance del escritorio, y ninguno aparece en el tique que concedió el inicio de sesión. Ese inventario es la superficie real de permisos.

Enuméralo desde dentro de una sesión de prueba, no desde una hoja de cálculo. Un puñado de comandos cubre la mayor parte de la superficie.

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

Elige el límite a propósito

Tres formas encajan en tareas distintas, y la elección debe seguir a la tarea y no a la herramienta que casualmente existe. Una aplicación publicada expone un programa con sus propios permisos, un escritorio completo expone todo lo que puede hacer el perfil del usuario, y una cuenta de base de datos de alcance reducido con una restricción de origen expone un recurso sin escritorio alguno. La forma más estrecha que aún completa el trabajo es la que hay que documentar. Cualquier cosa más amplia necesita una razón escrita al lado.

Para un único informe, una aplicación publicada o una cuenta restringida es una concesión menor que un escritorio general. Para el mantenimiento que realmente necesita varias herramientas, el escritorio puede ser correcto, pero entonces la aprobación describe todo el host y no una aplicación. Pregunta al propietario del recurso a cuál de esas está diciendo que sí.

El movimiento de datos es un interruptor aparte. El portapapeles, la redirección de unidades y las descargas pueden llevar datos de la empresa al cliente, y ejecutar una aplicación en remoto no mantiene los datos en remoto por sí solo.

Comprueba las dos aprobaciones y la ruta de retirada

Dos aprobaciones pertenecen al registro: el derecho a llegar y abrir el escritorio, y el derecho a usar recursos desde dentro. Nombra un propietario para cada una y mantén la segunda visible para quien revise el recurso. Es esa segunda entrada la que preguntará un auditor, porque describe alcance y no entrada. Escribe ambas antes de que se apruebe el cambio, no después del primer incidente.

Después prueba la retirada, porque una sesión desconectada puede sobrevivir a la razón que la justificaba. La tabla de sesiones es el lugar más rápido para ver qué sigue en marcha.

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

Desconectar el cliente deja la sesión remota en marcha, y sus conexiones de red y credenciales en caché pueden seguir siendo utilizables hasta que esa sesión termine. Cierra la sesión, o termínala de forma explícita, y confirma que el contador posterior deja de avanzar después. Una prueba de retirada que solo cierra la tapa del portátil no demuestra nada. Haz la misma prueba una vez con la cuenta desactivada y otra con el permiso de escritorio retirado, y luego anota qué registró el recurso en cada caso.