O RDP muda o cliente: por que o banco de dados vê outro host
Uma área de trabalho publicada inicia as próprias conexões, então o recurso vê o host, não o seu portátil. Revise essa segunda identidade junto com o acesso que aprovou.
A sua regra de VPN nega o banco de dados e o ticket é encerrado como falha da firewall, enquanto o mesmo utilizador abre uma área de trabalho publicada e consulta esse banco sem problemas. Ambas as afirmações são verdadeiras. A área de trabalho é outro cliente, com o seu próprio endereço num segmento em que as regras já confiam, e com a sua própria identidade quando se liga mais adiante. O que parece uma regra contraditória é normalmente um segundo pedido que ninguém colocou na revisão.
O segundo pedido tem o seu próprio endereço de cliente
Quando uma aplicação dentro da sessão abre uma ligação ao banco de dados, o aperto de mão TCP começa no host da sessão. O endereço de origem pertence à rede desse host, por isso cada router e firewall de base de dados no caminho avalia o segmento da área de trabalho e não o conjunto de túneis de onde veio o seu portátil. O endereço VPN nunca aparece nesse fluxo. É por isso que uma regra de negação baseada na origem pode ser correta e irrelevante ao mesmo tempo.
Leia a origem de dentro da sessão e não do portátil, e depois teste o caminho seguinte a partir do mesmo local. As duas respostas devem concordar sobre qual host está a fazer o pedido.
whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432Compare o que a sessão reporta com o endereço que o banco de dados registou para o mesmo instante. Quando o registo do servidor mostra a sub-rede da área de trabalho em vez do conjunto de túneis, a pergunta deixa de ser se a regra disparou e passa a ser qual host fez o pedido. Essa é outra investigação com outro responsável.
A identidade também muda, não apenas o endereçamento
A ligação seguinte autentica-se normalmente como o token da sessão, uma credencial armazenada ou uma conta de serviço da aplicação, e o recurso registra o que lhe foi dado. Por isso um rasto de auditoria que mostre uma conta de serviço no banco de dados não prova que uma pessoa executou a consulta. Também não identifica essa pessoa. Apenas o registo de sessão da própria área de trabalho liga esses dois registos.
A autorização acontece duas vezes, e a segunda decisão é tomada com entradas diferentes. A primeira concede um início de sessão de área de trabalho a um utilizador nomeado, enquanto a segunda concede o que o token desse utilizador ou a conta da aplicação podem fazer ao recurso. Um grupo de apoio que pode abrir uma área de trabalho não é automaticamente um grupo que pode ler uma tabela de clientes.
Veja o token e o caminho de delegação antes de escrever a nota de acesso. Ambos são visíveis de dentro da sessão, e é o único local onde a resposta não é um palpite.
whoami /groups
klist
query sessionSe a aplicação usa uma conta de serviço, são os direitos dela que contam a jusante. A rotação dessa credencial pertence à revisão de acesso, não a uma reflexão operacional posterior.
Por que o caminho direto continua bloqueado, e com razão
A regra de negação não está errada só porque o destino é alcançável por outra via. A segmentação é avaliada por origem, e a área de trabalho está num segmento que foi permitido muito antes de alguém o pensar como rota para o banco de dados. Nada contornou a política. A política apenas descreve duas origens diferentes com dois resultados diferentes.
O que a revisão tem de responder é o que cada sessão autorizada nesse host pode iniciar. Navegadores com sessões guardadas, unidades mapeadas, agentes que guardam credenciais e serviços à escuta local alargam todos o alcance da área de trabalho, e nenhum deles aparece no ticket que concedeu o início de sessão. Esse inventário é a superfície real de permissões.
Enumere-o de dentro de uma sessão de teste, não de uma folha de cálculo. Alguns comandos cobrem a maior parte da superfície.
Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'Escolha a fronteira deliberadamente
Três formas servem tarefas diferentes, e a escolha deve seguir a tarefa e não a ferramenta que existe por acaso. Uma aplicação publicada expõe um programa com as suas próprias permissões, uma área de trabalho completa expõe tudo o que o perfil do utilizador pode fazer, e uma conta de base de dados restrita com uma limitação de origem expõe um recurso sem qualquer área de trabalho. A forma mais estreita que ainda conclui o trabalho é a que deve ser documentada. Tudo o que seja mais amplo precisa de uma razão escrita ao lado.
Para um único relatório, uma aplicação publicada ou uma conta restrita é uma concessão menor do que uma área de trabalho geral. Para manutenção que realmente precisa de várias ferramentas, a área de trabalho pode ser correta, mas então a aprovação descreve o host inteiro e não uma aplicação. Pergunte ao proprietário do recurso a qual dessas opções está a dizer sim.
O movimento de dados é um interruptor separado. A área de transferência, o redirecionamento de unidades e as transferências podem levar dados da empresa ao cliente, e executar uma aplicação remotamente não mantém os dados remotos por si só.
Verifique as duas aprovações e o caminho de remoção
Duas aprovações pertencem ao registo: o direito de chegar e abrir a área de trabalho, e o direito de usar recursos a partir de dentro. Nomeie um proprietário para cada uma e mantenha a segunda visível para quem reveja o recurso. É essa segunda entrada que um auditor vai perguntar, porque descreve alcance e não entrada. Escreva ambas antes de a alteração ser aprovada, não depois do primeiro incidente.
Depois teste a remoção, porque uma sessão desligada pode sobreviver à razão que a justificava. A tabela de sessões é o local mais rápido para ver o que ainda está em execução.
query session
query user
qwinsta /server:rdsh01.corp.internalDesligar o cliente deixa a sessão remota em execução, e as suas ligações de rede e credenciais em cache podem continuar utilizáveis até essa sessão terminar. Termine a sessão, ou encerre-a explicitamente, e confirme que o contador a jusante deixa de avançar depois. Um teste de remoção que apenas fecha a tampa do portátil não prova nada. Faça o mesmo teste uma vez com a conta desativada e outra com a permissão de área de trabalho removida, e registe o que o recurso gravou em cada caso.