RDP ändert den Client: Warum die Datenbank einen anderen Host sieht

Ihre VPN-Regel verweigert die Datenbank, und das Ticket wird als Firewallfehler geschlossen, während derselbe Benutzer einen veröffentlichten Desktop öffnet und diese Datenbank ohne Probleme abfragt. Beide Aussagen sind wahr. Der Desktop ist ein anderer Client, mit eigener Adresse in einem Segment, dem die Regeln bereits vertrauen, und mit eigener Identität, wenn er weiterverbindet. Was wie eine widersprüchliche Regel aussieht, ist meist eine zweite Anfrage, die niemand in die Prüfung aufgenommen hat.

Die zweite Anfrage hat eine eigene Clientadresse

Wenn eine Anwendung innerhalb der Sitzung eine Verbindung zur Datenbank öffnet, beginnt der TCP-Handshake am Sitzungshost. Seine Quelladresse gehört zum Netz dieses Hosts, daher bewertet jeder Router und jede Datenbankfirewall auf dem Weg das Segment des Desktops und nicht den Tunnelpool, aus dem Ihr Notebook kam. Die VPN-Adresse erscheint in diesem Fluss nie. Deshalb kann eine quellenbasierte Sperrregel zugleich richtig und irrelevant sein.

Lesen Sie den Ursprung innerhalb der Sitzung statt am Notebook und prüfen Sie dann den weiteren Weg von derselben Stelle aus. Beide Antworten sollten darin übereinstimmen, welcher Host die Anfrage stellt.

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

Vergleichen Sie, was die Sitzung meldet, mit der Adresse, die die Datenbank für denselben Zeitpunkt aufgezeichnet hat. Wenn das Serverprotokoll das Desktop-Subnetz statt des Tunnelpools zeigt, ist die Frage nicht mehr, ob die Regel griff, sondern welcher Host die Anfrage gestellt hat. Das ist eine andere Untersuchung mit einem anderen Verantwortlichen.

Die Identität ändert sich ebenso wie die Adressierung

Die Weiterverbindung authentifiziert sich meist als Token der Sitzung, als gespeicherte Anmeldeinformation oder als Dienstkonto einer Anwendung, und die Ressource zeichnet auf, was ihr davon gegeben wurde. Ein Audit-Trail, der ein Dienstkonto auf der Datenbank zeigt, beweist daher nicht, dass ein Mensch die Abfrage ausgeführt hat. Er identifiziert den Menschen auch nicht. Nur das eigene Sitzungsprotokoll des Desktops verbindet beide Datensätze.

Die Autorisierung erfolgt zweimal, und die zweite Entscheidung wird mit anderen Eingaben getroffen. Die erste gewährt einem benannten Benutzer die Anmeldung an einem Desktop, die zweite gewährt, was das Token dieses Benutzers oder das Konto der Anwendung an der Ressource tun darf. Eine Helpdesk-Gruppe, die einen Desktop öffnen darf, ist nicht automatisch eine Gruppe, die eine Kundentabelle lesen darf.

Sehen Sie sich das Token und den Delegierungspfad an, bevor Sie die Zugriffsnotiz schreiben. Beides ist innerhalb der Sitzung sichtbar, und nur dort ist die Antwort keine Vermutung.

whoami /groups
klist
query session

Verwendet die Anwendung ein Dienstkonto, zählen dessen Rechte weiter. Die Rotation dieser Anmeldeinformation gehört in die Zugriffsprüfung, nicht in einen betrieblichen Nachgedanken.

Warum der direkte Weg weiterhin zu Recht blockiert ist

Die Sperrregel ist nicht falsch, nur weil das Ziel auf einem anderen Weg erreichbar ist. Segmentierung wird pro Quelle bewertet, und der Desktop liegt in einem Segment, das erlaubt wurde, lange bevor jemand es als Route zur Datenbank betrachtete. Nichts hat die Richtlinie umgangen. Die Richtlinie beschreibt schlicht zwei verschiedene Quellen mit zwei verschiedenen Ergebnissen.

Die Prüfung muss beantworten, was jede autorisierte Sitzung auf diesem Host starten kann. Browser mit gespeicherten Sitzungen, zugeordnete Laufwerke, Agenten mit Anmeldeinformationen und lokal lauschende Dienste erweitern alle die Reichweite des Desktops, und keines davon erscheint im Ticket, das die Anmeldung gewährte. Diese Bestandsaufnahme ist die eigentliche Berechtigungsfläche.

Zählen Sie sie innerhalb einer Testsitzung auf, nicht in einer Tabelle. Eine Handvoll Befehle deckt den größten Teil der Fläche ab.

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

Wählen Sie die Grenze bewusst

Drei Formen passen zu unterschiedlichen Aufgaben, und die Wahl sollte der Aufgabe folgen, nicht dem Werkzeug, das zufällig existiert. Eine veröffentlichte Anwendung stellt ein Programm mit eigenen Berechtigungen bereit, ein vollständiger Desktop stellt alles bereit, was das Profil des Benutzers kann, und ein eng begrenztes Datenbankkonto mit Quellenbeschränkung stellt eine Ressource ganz ohne Desktop bereit. Die engste Form, die die Arbeit noch erledigt, ist die zu dokumentierende. Alles Weitere braucht einen daneben geschriebenen Grund.

Für einen einzelnen Bericht ist eine veröffentlichte Anwendung oder ein eingeschränktes Konto eine kleinere Gewährung als ein allgemeiner Desktop. Für Wartung, die wirklich mehrere Werkzeuge braucht, kann der Desktop richtig sein, aber dann beschreibt die Genehmigung den ganzen Host statt einer Anwendung. Fragen Sie den Ressourceninhaber, welchem davon er zustimmt.

Datenbewegung ist ein eigener Schalter. Zwischenablage, Laufwerksumleitung und Downloads können Firmendaten zum Client tragen, und eine Anwendung fern auszuführen hält Daten nicht von selbst fern.

Prüfen Sie beide Genehmigungen und den Rücknahmeweg

Zwei Genehmigungen gehören in den Eintrag: das Recht, den Desktop zu erreichen und zu öffnen, und das Recht, Ressourcen von innen zu nutzen. Benennen Sie für jede einen Inhaber und halten Sie die zweite für jeden sichtbar, der die Ressource prüft. Nach dem zweiten Eintrag wird ein Prüfer fragen, weil er Reichweite statt Zugang beschreibt. Schreiben Sie beide, bevor die Änderung genehmigt wird, nicht nach dem ersten Vorfall.

Testen Sie dann die Rücknahme, denn eine getrennte Sitzung kann den Grund für sie überleben. Die Sitzungstabelle ist der schnellste Ort, um zu sehen, was noch läuft.

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

Das Trennen des Clients lässt die Remotesitzung weiterlaufen, und ihre Netzwerkverbindungen und zwischengespeicherten Anmeldeinformationen können nutzbar bleiben, bis diese Sitzung endet. Melden Sie sich ab oder beenden Sie die Sitzung ausdrücklich, und bestätigen Sie, dass der nachgelagerte Zähler danach nicht weiterläuft. Ein Rücknahmetest, der nur den Notebookdeckel schließt, beweist nichts. Führen Sie denselben Test einmal mit deaktiviertem Konto und einmal mit entzogener Desktop-Berechtigung durch, und halten Sie fest, was die Ressource jeweils protokollierte.