RDP cambia il client: perché il database vede un altro host

La tua regola VPN nega il database e il ticket viene chiuso come guasto del firewall, mentre lo stesso utente apre un desktop pubblicato e interroga quel database senza problemi. Entrambe le affermazioni sono vere. Il desktop è un altro client, con il proprio indirizzo su un segmento di cui le regole già si fidano, e con la propria identità quando si connette più avanti. Quello che sembra una regola contraddittoria è di solito una seconda richiesta che nessuno ha messo nella revisione.

La seconda richiesta ha un proprio indirizzo client

Quando un’applicazione dentro la sessione apre una connessione al database, la stretta di mano TCP parte sull’host della sessione. Il suo indirizzo di origine appartiene alla rete di quell’host, quindi ogni router e firewall del database lungo il percorso valuta il segmento del desktop e non il pool di tunnel da cui è arrivato il tuo portatile. L’indirizzo VPN non compare mai in quel flusso. Per questo una regola di rifiuto basata sull’origine può essere insieme corretta e irrilevante.

Leggi l’origine dall’interno della sessione e non dal portatile, poi verifica il percorso successivo dallo stesso punto. Le due risposte dovrebbero concordare su quale host sta facendo la richiesta.

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

Confronta ciò che la sessione riporta con l’indirizzo che il database ha registrato per lo stesso istante. Quando il registro del server mostra la sottorete del desktop invece del pool di tunnel, la domanda smette di essere se la regola è scattata e diventa quale host ha fatto la richiesta. È un’altra indagine con un altro responsabile.

L’identità cambia insieme all’indirizzamento

La connessione successiva di solito si autentica come token della sessione, credenziale memorizzata o account di servizio dell’applicazione, e la risorsa registra ciò che le è stato fornito. Un tracciato di audit che mostra un account di servizio sul database non prova quindi che una persona abbia eseguito la query. Non identifica nemmeno la persona. Solo il registro di sessione del desktop collega quei due record.

L’autorizzazione avviene due volte, e la seconda decisione viene presa con input diversi. La prima concede un accesso desktop a un utente nominato, mentre la seconda concede ciò che il token di quell’utente o l’account dell’applicazione possono fare sulla risorsa. Un gruppo di assistenza che può aprire un desktop non è automaticamente un gruppo che può leggere una tabella clienti.

Guarda il token e il percorso di delega prima di scrivere la nota di accesso. Entrambi sono visibili dall’interno della sessione, ed è l’unico posto in cui la risposta non è un’ipotesi.

whoami /groups
klist
query session

Se l’applicazione usa un account di servizio, sono i suoi diritti a contare a valle. La rotazione di quella credenziale appartiene alla revisione degli accessi, non a una riflessione operativa successiva.

Perché il percorso diretto è ancora bloccato, e giustamente

La regola di rifiuto non è sbagliata solo perché la destinazione è raggiungibile in un altro modo. La segmentazione viene valutata per origine, e il desktop si trova su un segmento consentito molto prima che qualcuno lo pensasse come rotta verso il database. Nulla ha aggirato la politica. La politica descrive semplicemente due origini diverse con due esiti diversi.

La revisione deve rispondere a che cosa può avviare ogni sessione autorizzata su quell’host. Browser con sessioni salvate, unità mappate, agenti che detengono credenziali e servizi in ascolto locale estendono tutti la portata del desktop, e nessuno di essi compare nel ticket che ha concesso l’accesso. Quell’inventario è la vera superficie dei permessi.

Elencalo dall’interno di una sessione di test, non da un foglio di calcolo. Poche istruzioni coprono la maggior parte della superficie.

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

Scegli il confine deliberatamente

Tre forme si adattano a compiti diversi, e la scelta dovrebbe seguire il compito e non lo strumento che esiste per caso. Un’applicazione pubblicata espone un programma con i propri permessi, un desktop completo espone tutto ciò che il profilo dell’utente può fare, e un account database ristretto con un vincolo di origine espone una risorsa senza alcun desktop. La forma più stretta che completa ancora il lavoro è quella da documentare. Qualcosa di più ampio richiede una ragione scritta accanto.

Per un singolo report, un’applicazione pubblicata o un account limitato è una concessione più piccola di un desktop generico. Per la manutenzione che richiede davvero più strumenti, il desktop può essere corretto, ma allora l’approvazione descrive l’intero host e non un’applicazione. Chiedi al proprietario della risorsa a quale di queste sta dicendo di sì.

Il movimento dei dati è un interruttore separato. Gli appunti, il reindirizzamento delle unità e i download possono portare dati aziendali al client, e eseguire un’applicazione da remoto non mantiene i dati da remoto di per sé.

Controlla entrambe le approvazioni e il percorso di rimozione

Due approvazioni appartengono al registro: il diritto di raggiungere e aprire il desktop, e il diritto di usare risorse dall’interno. Nomina un proprietario per ciascuna e mantieni la seconda visibile a chiunque esamini la risorsa. È quella seconda voce che un revisore chiederà, perché descrive la portata e non l’ingresso. Scrivi entrambe prima che la modifica sia approvata, non dopo il primo incidente.

Poi verifica la rimozione, perché una sessione disconnessa può sopravvivere alla ragione che l’ha giustificata. La tabella delle sessioni è il posto più rapido per vedere cosa è ancora in esecuzione.

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

Disconnettere il client lascia attiva la sessione remota, e le sue connessioni di rete e le credenziali in cache possono restare utilizzabili finché quella sessione non termina. Esci, oppure termina la sessione esplicitamente, e conferma che il contatore a valle smette di avanzare dopo. Un test di rimozione che chiude solo il coperchio del portatile non prova nulla. Esegui lo stesso test una volta con l’account disabilitato e una volta con l’autorizzazione desktop rimossa, poi annota cosa ha registrato la risorsa in ciascun caso.