RDP change le client : pourquoi la base de données voit un autre hôte

Votre règle VPN refuse la base de données et le ticket est clos comme une panne de pare-feu, alors que le même utilisateur ouvre un bureau publié et interroge cette base sans difficulté. Les deux affirmations sont vraies. Le bureau est un autre client, avec sa propre adresse sur un segment auquel les règles font déjà confiance, et sa propre identité lorsqu’il se connecte plus loin. Ce qui ressemble à une règle contradictoire est généralement une seconde requête que personne n’a mise dans la revue.

La seconde requête a sa propre adresse de client

Quand une application à l’intérieur de la session ouvre une connexion à la base de données, la poignée de main TCP démarre sur l’hôte de session. Son adresse source appartient au réseau de cet hôte, donc chaque routeur et pare-feu de base de données sur le chemin évalue le segment du bureau et non le pool de tunnels d’où venait votre portable. L’adresse VPN n’apparaît jamais dans ce flux. C’est pourquoi une règle de refus fondée sur la source peut être à la fois correcte et sans objet.

Lisez l’origine depuis l’intérieur de la session plutôt que depuis le portable, puis testez le chemin suivant au même endroit. Les deux réponses devraient s’accorder sur l’hôte qui émet la requête.

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

Comparez ce que la session rapporte avec l’adresse que la base de données a enregistrée pour le même instant. Quand le journal du serveur montre le sous-réseau du bureau au lieu du pool de tunnels, la question cesse d’être de savoir si la règle s’est déclenchée et devient de savoir quel hôte a fait la requête. C’est une autre enquête avec un autre responsable.

L’identité change aussi, pas seulement l’adressage

La connexion suivante s’authentifie généralement avec le jeton de la session, un identifiant stocké ou un compte de service de l’application, et la ressource enregistre ce qui lui a été fourni. Une piste d’audit montrant un compte de service sur la base de données ne prouve donc pas qu’un humain a exécuté la requête. Elle n’identifie pas non plus cet humain. Seul le journal de session du bureau relie ces deux enregistrements.

L’autorisation se produit deux fois, et la seconde décision est prise avec d’autres entrées. La première accorde une ouverture de session de bureau à un utilisateur nommé, tandis que la seconde accorde ce que le jeton de cet utilisateur ou le compte de l’application peut faire sur la ressource. Un groupe d’assistance autorisé à ouvrir un bureau n’est pas automatiquement un groupe autorisé à lire une table clients.

Regardez le jeton et le chemin de délégation avant d’écrire la note d’accès. Les deux sont visibles depuis l’intérieur de la session, et c’est le seul endroit où la réponse n’est pas une supposition.

whoami /groups
klist
query session

Si l’application utilise un compte de service, ce sont ses droits qui comptent en aval. La rotation de cet identifiant relève de la revue d’accès, pas d’une réflexion opérationnelle après coup.

Pourquoi le chemin direct est toujours bloqué, et à juste titre

La règle de refus n’est pas fausse simplement parce que la destination est joignable autrement. La segmentation est évaluée par source, et le bureau se trouve sur un segment autorisé bien avant que quiconque l’ait pensé comme une route vers la base de données. Rien n’a contourné la politique. La politique décrit simplement deux sources différentes avec deux résultats différents.

Ce que la revue doit trancher, c’est ce que chaque session autorisée sur cet hôte peut lancer. Les navigateurs avec sessions enregistrées, les lecteurs mappés, les agents détenant des identifiants et les services à l’écoute en local étendent tous la portée du bureau, et aucun d’eux n’apparaît dans le ticket qui a accordé l’ouverture de session. Cet inventaire est la véritable surface d’autorisation.

Énumérez-le depuis l’intérieur d’une session de test, pas depuis un tableur. Une poignée de commandes couvre l’essentiel de la surface.

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

Choisissez la frontière délibérément

Trois formes conviennent à des tâches différentes, et le choix doit suivre la tâche plutôt que l’outil qui existe par hasard. Une application publiée expose un programme avec ses propres permissions, un bureau complet expose tout ce que le profil de l’utilisateur peut faire, et un compte de base de données restreint par une limitation de source expose une ressource sans aucun bureau. La forme la plus étroite qui accomplit encore le travail est celle à documenter. Tout ce qui est plus large exige une raison écrite à côté.

Pour un rapport unique, une application publiée ou un compte restreint est une autorisation plus petite qu’un bureau général. Pour une maintenance qui a réellement besoin de plusieurs outils, le bureau peut être correct, mais alors l’approbation décrit l’hôte entier plutôt qu’une application. Demandez au propriétaire de la ressource à laquelle de ces options il consent.

Le déplacement des données est un commutateur distinct. Le presse-papiers, la redirection de lecteurs et les téléchargements peuvent transporter des données de l’entreprise vers le client, et exécuter une application à distance ne garde pas les données à distance en soi.

Vérifiez les deux approbations et le chemin de retrait

Deux approbations appartiennent au dossier : le droit d’atteindre et d’ouvrir le bureau, et le droit d’utiliser les ressources depuis l’intérieur. Nommez un propriétaire pour chacune et gardez la seconde visible pour quiconque examine la ressource. C’est cette seconde entrée qu’un auditeur demandera, car elle décrit la portée et non l’entrée. Écrivez les deux avant que le changement soit approuvé, pas après le premier incident.

Testez ensuite le retrait, car une session déconnectée peut survivre à la raison qui l’a justifiée. La table des sessions est l’endroit le plus rapide pour voir ce qui tourne encore.

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

Déconnecter le client laisse la session distante active, et ses connexions réseau et identifiants en cache peuvent rester utilisables jusqu’à la fin de cette session. Déconnectez-vous, ou terminez la session explicitement, et confirmez que le compteur en aval cesse ensuite d’avancer. Un test de retrait qui se contente de fermer le capot du portable ne prouve rien. Faites le même test une fois avec le compte désactivé et une fois avec l’autorisation de bureau retirée, puis notez ce que la ressource a journalisé dans chaque cas.