RDP canvia el client: per què la base de dades veu un altre amfitrió

La teva regla de VPN denega la base de dades i el tiquet es tanca com una fallada del tallafoc, mentre el mateix usuari obre un escriptori publicat i consulta aquesta base sense problemes. Totes dues afirmacions són certes. L’escriptori és un client diferent, amb la seva pròpia adreça en un segment que les regles ja es confien, i la seva pròpia identitat quan es connecta més enllà. El que sembla una regla contradictòria sol ser una segona sol·licitud que ningú va posar a la revisió.

La segona sol·licitud té la seva pròpia adreça de client

Quan una aplicació dins de la sessió obre una connexió a la base de dades, l’encaixada TCP comença a l’amfitrió de la sessió. La seva adreça d’origen pertany a la xarxa d’aquest amfitrió, així que cada encaminador i tallafoc de la base de dades del camí avalua el segment de l’escriptori i no el pool de túnels d’on venia el teu portàtil. L’adreça VPN no apareix mai en aquest flux. Per això una regla de denegació per origen pot ser alhora correcta i irrellevant.

Llegeix l’origen des de dins de la sessió i no des del portàtil, i després prova el camí següent des del mateix lloc. Les dues respostes haurien de coincidir sobre quin amfitrió fa la sol·licitud.

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

Compara el que informa la sessió amb l’adreça que la base de dades va registrar per al mateix moment. Quan el registre del servidor mostra la subxarxa de l’escriptori en lloc del pool de túnels, la pregunta deixa de ser si la regla s’ha activat i passa a ser quin amfitrió ha fet la sol·licitud. Això és una investigació diferent amb un propietari diferent.

La identitat també canvia, no només l’adreçament

La connexió següent normalment s’autentica amb el testimoni de la sessió, una credencial emmagatzemada o un compte de servei de l’aplicació, i el recurs registra el que li han donat. Per tant, un registre d’auditoria que mostri un compte de servei a la base de dades no demostra que una persona hagi executat la consulta. Tampoc identifica la persona. Només el registre de sessió de l’escriptori uneix aquests dos registres.

L’autorització passa dues vegades, i la segona decisió es pren amb entrades diferents. La primera concedeix un inici de sessió d’escriptori a un usuari concret, mentre que la segona concedeix el que el testimoni d’aquest usuari o el compte de l’aplicació poden fer al recurs. Un grup d’ajuda que pot obrir un escriptori no és automàticament un grup que pot llegir una taula de clients.

Mira el testimoni i el camí de delegació abans d’escriure la nota d’accés. Tots dos són visibles des de dins de la sessió, que és l’únic lloc on la resposta no és una suposició.

whoami /groups
klist
query session

Si l’aplicació fa servir un compte de servei, els seus drets són els que importen més endavant. Rotar aquesta credencial pertany a la revisió d’accés, no a una reflexió operativa posterior.

Per què el camí directe encara està bloquejat, i correctament

La regla de denegació no és incorrecta només perquè la destinació sigui abastable per una altra via. La segmentació s’avalua per origen, i l’escriptori està situat en un segment que es va permetre molt abans que algú el pensés com una ruta a la base de dades. Res no ha eludit la política. La política simplement descriu dues fonts diferents amb dos resultats diferents.

El que la revisió ha de respondre és què pot iniciar cada sessió autoritzada en aquell amfitrió. Els navegadors amb sessions desades, les unitats mapejades, els agents que guarden credencials i els serveis que escolten localment amplien l’abast de l’escriptori, i cap d’ells no apareix al tiquet que va concedir l’inici de sessió. Aquest inventari és la superfície real de permisos.

Enumera’l des de dins d’una sessió de prova, no des d’un full de càlcul. Un grapat d’ordres cobreix la major part de la superfície.

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

Tria el límit deliberadament

Tres formes encaixen en tasques diferents, i l’elecció ha de seguir la tasca i no l’eina que casualment existeix. Una aplicació publicada exposa un programa amb els seus propis permisos, un escriptori complet exposa tot el que pot fer el perfil de l’usuari, i un compte de base de dades d’abast reduït amb una restricció d’origen exposa un recurs sense cap escriptori. La forma més estreta que encara completa la feina és la que cal documentar. Qualsevol cosa més àmplia necessita una raó escrita al costat.

Per a un sol informe, una aplicació publicada o un compte restringit és una concessió més petita que un escriptori general. Per al manteniment que realment necessita diverses eines, l’escriptori pot ser correcte, però llavors l’aprovació descriu tot l’amfitrió i no una aplicació. Pregunta al propietari del recurs a quina d’aquestes opcions està dient que sí.

El moviment de dades és un interruptor a part. El porta-retalls, la redirecció d’unitats i les baixades poden portar dades de l’empresa al client, i executar una aplicació remotament no manté les dades remotes per si sol.

Comprova les dues aprovacions i el camí de retirada

Dues aprovacions pertanyen al registre: el dret a arribar i obrir l’escriptori, i el dret a utilitzar recursos des de dins. Nomena un propietari per a cadascuna i mantén la segona visible per a qui revisi el recurs. És aquesta segona entrada la que preguntarà un auditor, perquè descriu abast i no entrada. Escriu totes dues abans que s’aprovi el canvi, no després del primer incident.

Després prova la retirada, perquè una sessió desconnectada pot sobreviure la raó que la justificava. La taula de sessions és el lloc més ràpid per veure què continua en marxa.

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

Desconnectar el client deixa la sessió remota en marxa, i les seves connexions de xarxa i credencials en memòria cau poden continuar sent utilitzables fins que aquesta sessió acabi. Tanca la sessió, o acaba-la explícitament, i confirma que el comptador posterior deixa d’avançar després. Una prova de retirada que només tanca la tapa del portàtil no demostra res. Fes la mateixa prova una vegada amb el compte desactivat i una altra amb el permís d’escriptori retirat, i després anota què va registrar el recurs en cada cas.