RDP verandert de client: waarom de database een andere host ziet

Uw VPN-regel weigert de database en het ticket wordt gesloten als een firewallfout, terwijl dezelfde gebruiker een gepubliceerde desktop opent en die database zonder problemen bevraagt. Beide uitspraken zijn waar. De desktop is een andere client, met zijn eigen adres op een segment dat de regels al vertrouwen, en met zijn eigen identiteit wanneer hij verder verbindt. Wat op een tegenstrijdige regel lijkt, is meestal een tweede verzoek dat niemand in de beoordeling heeft gezet.

Het tweede verzoek heeft een eigen clientadres

Wanneer een toepassing binnen de sessie een verbinding met de database opent, begint de TCP-handshake op de sessiehost. Het bronadres hoort bij het netwerk van die host, dus elke router en databasefirewall langs het pad beoordeelt het segment van de desktop en niet de tunnelpool waar uw laptop vandaan kwam. Het VPN-adres verschijnt nooit in die stroom. Daarom kan een weigerregel op basis van bron tegelijk juist en irrelevant zijn.

Lees de oorsprong binnen de sessie in plaats van op de laptop en test daarna het vervolgpad vanaf dezelfde plek. De twee antwoorden zouden het eens moeten zijn over welke host het verzoek doet.

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

Vergelijk wat de sessie meldt met het adres dat de database voor hetzelfde moment vastlegde. Wanneer het serverlog het subnet van de desktop toont in plaats van de tunnelpool, houdt de vraag op of de regel is afgegaan en wordt het welke host het verzoek heeft gedaan. Dat is een ander onderzoek met een andere eigenaar.

De identiteit verandert net als de adressering

De vervolgverbinding authenticeert meestal als het token van de sessie, een opgeslagen referentie of een serviceaccount van de toepassing, en de resource legt vast wat hem is gegeven. Een auditspoor dat een serviceaccount op de database toont, bewijst dus niet dat een mens de query heeft uitgevoerd. Het identificeert die mens ook niet. Alleen het sessielog van de desktop zelf verbindt die twee records.

Autorisatie gebeurt twee keer, en de tweede beslissing wordt met andere invoer genomen. De eerste verleent een benoemde gebruiker een desktopaanmelding, terwijl de tweede verleent wat het token van die gebruiker of het account van de toepassing met de resource mag doen. Een helpdeskgroep die een desktop mag openen, is niet automatisch een groep die een klanttabel mag lezen.

Kijk naar het token en het delegatiepad voordat u de toegangsnotitie schrijft. Beide zijn zichtbaar van binnen de sessie, en dat is de enige plek waar het antwoord geen gok is.

whoami /groups
klist
query session

Als de toepassing een serviceaccount gebruikt, zijn de rechten daarvan verder van belang. Het roteren van die referentie hoort bij de toegangsbeoordeling, niet bij een operationele nabeschouwing.

Waarom het directe pad nog steeds terecht is geblokkeerd

De weigerregel is niet onjuist alleen omdat de bestemming via een andere weg bereikbaar is. Segmentering wordt per bron beoordeeld, en de desktop staat op een segment dat werd toegestaan lang voordat iemand het als een route naar de database beschouwde. Niets heeft het beleid omzeild. Het beleid beschrijft eenvoudig twee verschillende bronnen met twee verschillende uitkomsten.

Wat de beoordeling moet beantwoorden, is wat elke geautoriseerde sessie op die host kan starten. Browsers met opgeslagen sessies, toegewezen stations, agents met referenties en lokaal luisterende diensten vergroten allemaal het bereik van de desktop, en geen ervan verschijnt in het ticket dat de aanmelding gaf. Die inventaris is het echte machtigingsoppervlak.

Som ze op van binnen een testsessie, niet uit een spreadsheet. Een handvol opdrachten dekt het grootste deel van het oppervlak.

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

Kies de grens bewust

Drie vormen passen bij verschillende taken, en de keuze moet de taak volgen en niet het gereedschap dat toevallig bestaat. Een gepubliceerde toepassing stelt één programma met eigen machtigingen beschikbaar, een volledige desktop stelt alles beschikbaar wat het profiel van de gebruiker kan, en een beperkt databaseaccount met een bronbeperking stelt één resource beschikbaar zonder enige desktop. De smalste vorm die het werk nog afmaakt, is degene die moet worden gedocumenteerd. Alles breder vereist een reden die ernaast wordt geschreven.

Voor één rapport is een gepubliceerde toepassing of een beperkt account een kleinere toekenning dan een algemene desktop. Voor onderhoud dat echt meerdere gereedschappen nodig heeft, kan de desktop juist zijn, maar dan beschrijft de goedkeuring de hele host in plaats van één toepassing. Vraag de resource-eigenaar met welke van die opties hij instemt.

Gegevensverplaatsing is een aparte schakelaar. Klembord, stationsomleiding en downloads kunnen bedrijfsgegevens naar de client brengen, en een toepassing op afstand uitvoeren houdt gegevens niet vanzelf op afstand.

Controleer beide goedkeuringen en het verwijderpad

Twee goedkeuringen horen in het dossier: het recht om de desktop te bereiken en te openen, en het recht om resources van binnenuit te gebruiken. Noem voor elk een eigenaar en houd de tweede zichtbaar voor iedereen die de resource beoordeelt. Het is die tweede vermelding waar een auditor naar zal vragen, omdat die bereik beschrijft en niet toegang. Schrijf beide voordat de wijziging wordt goedgekeurd, niet na het eerste incident.

Test daarna de verwijdering, want een losgekoppelde sessie kan de reden ervoor overleven. De sessietabel is de snelste plek om te zien wat er nog draait.

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

Het loskoppelen van de client laat de externe sessie doorlopen, en de netwerkverbindingen en in de cache opgeslagen referenties kunnen bruikbaar blijven tot die sessie eindigt. Meld u af, of beëindig de sessie expliciet, en bevestig dat de teller stroomafwaarts daarna stopt met oplopen. Een verwijderingstest die alleen het deksel van de laptop sluit, bewijst niets. Voer dezelfde test één keer uit met een uitgeschakeld account en één keer met de desktoppermissie ingetrokken, en noteer daarna wat de resource in elk geval logde.