Restrinja quem pode alcançar o RDP, mantenha a Autenticação ao Nível da Rede ativada onde for suportada, utilize credenciais fortes individuais e minimize o privilégio administrativo. Teste uma segunda sessão e o acesso de recuperação antes de fechar a ligação atual.
Trate o ambiente de trabalho como uma fronteira de administração
Uma sessão RDP proporciona acesso interativo a um sistema remoto, pelo que a conta utilizada para ela pode tornar-se um alvo valioso. Comece por decidir quem necessita de acesso e que trabalho deve realizar. Um início de sessão de administrador partilhado é conveniente até precisar de remover o acesso de uma pessoa ou de compreender uma alteração de configuração. Contas individuais tornam essas tarefas operacionais mais claras.
Separe a atividade de rotina das alterações privilegiadas onde o software o permitir. Um utilizador que necessita de uma aplicação empresarial não necessita necessariamente de administração de sistema sem restrições. Mantenha também o endpoint do administrador em bom estado: proteger a máquina remota não protege credenciais introduzidas a partir de um dispositivo local infetado ou partilhado. Considere ambas as extremidades da sessão no design de acesso.
Limite a acessibilidade antes de confiar na proteção do início de sessão
Decida que redes ou dispositivos autorizados devem conseguir alcançar o anfitrião da sessão. Onde a sua arquitetura o suportar, utilize um VPN controlado ou um Gateway de Ambiente de Trabalho Remoto em vez de expor amplamente a administração. A Microsoft documenta o RD Gateway como uma rota para recursos internos com políticas de autorização de ligação e de recursos. A sua adequação depende do ambiente; não é uma funcionalidade incluída apenas porque um plano suporta RDP.
Restrinja as regras de firewall ao caminho pretendido e confirme como serão tratados os endereços dinâmicos dos clientes. Não crie uma regra restritiva que desligue imediatamente o único administrador sem uma opção de recuperação. Mantenha a sessão existente aberta, teste o novo caminho a partir de outra sessão e documente o mecanismo de recuperação autorizado antes de remover a rota de acesso mais antiga.
Mantenha a autenticação e a confiança explícitas
A Microsoft recomenda a Autenticação ao Nível da Rede para a maioria dos ambientes suportados. A NLA exige autenticação antes de estabelecer uma sessão remota completa, acrescentando proteção nessa fase. Não substitui uma firewall, uma política de contas ou atualizações do sistema. Verifique a compatibilidade do cliente e resolva os problemas de autenticação em vez de enfraquecer permanentemente a configuração como primeira resposta.
Utilize credenciais únicas e um segundo fator através de uma arquitetura de acesso suportada, sempre que possível. Verifique a identidade remota esperada e o comportamento do certificado, especialmente após uma reconstrução ou alteração do nome do anfitrião. Um aviso de certificado merece investigação; aceitar repetidamente identidades inesperadas transforma uma verificação de confiança útil num diálogo ignorado. Mantenha as credenciais de recuperação num armazenamento privado aprovado.
| Camada | Decisão | Verificação |
|---|---|---|
| Rede | Que clientes podem alcançar o anfitrião? | Fontes inesperadas não conseguem ligar-se |
| Autenticação | Que conta e fatores são necessários? | Uma segunda sessão permitida é bem-sucedida |
| Privilégio | Que tarefas exigem administração? | Os utilizadores de rotina não conseguem alterar definições do sistema |
| Recuperação | Como é restaurado o acesso após um erro? | O caminho de recuperação documentado está disponível |
Reduza o que a sessão pode transportar
Reveja as funcionalidades de redirecionamento da área de transferência, unidade, impressora e outras em função do fluxo de trabalho real. Um administrador pode não precisar de todos os recursos locais expostos ao anfitrião remoto. Por outro lado, desativar um caminho de transferência necessário sem alternativa pode incentivar soluções alternativas inseguras. Documente o método permitido para mover ficheiros e mantenha os segredos fora das notas comuns do ambiente de trabalho ou dos diretórios de transferência partilhados.
Para ambientes adequados baseados em domínio, a Microsoft fornece o Remote Credential Guard para reduzir a exposição de credenciais durante ligações RDP. Requer clientes compatíveis e autenticação Kerberos e suporta ligações diretas à máquina de destino; as ligações através do Remote Desktop Gateway ou do Connection Broker não são suportadas. Verifique os requisitos para o seu caminho de acesso real em vez de o tratar como uma proteção universal para máquinas Windows alojadas autónomas.
Mantenha a máquina e a evidência de que necessita
Agende atualizações do sistema operativo e das aplicações, incluindo um processo de reinício deliberado. Verifique se uma atualização requer reinício e valide o serviço depois. Defina políticas de sessão sensatas para trabalho não assistido ou desligado, mas considere as aplicações que têm de continuar em execução. Uma política de tempo limite deve responder a uma necessidade de segurança ou operacional em vez de simplesmente copiar um número arbitrário de outro ambiente.
Retenha informações úteis de acesso e incidentes segundo uma política documentada. Monitorize falhas de autenticação repetidas e atividade administrativa inesperada sem recolher conteúdo desnecessário. Restrinja quem pode ler os registos de diagnóstico e decida durante quanto tempo são necessários. Uma política de registo precisa é mais significativa do que manter tudo indefinidamente ou prometer que nunca poderá existir qualquer registo operacional.
Uma sequência segura para a primeira sessão
Na entrega, verifique o sistema esperado, altere as credenciais temporárias através do processo aprovado e estabeleça acesso individual. Confirme a firewall e a rota de recuperação e, em seguida, teste uma segunda ligação. Aplique atualizações, reveja o redirecionamento e instale a aplicação necessária. Crie uma cópia de segurança e pratique a recuperação das definições que importam antes de depender do ambiente de trabalho para o trabalho diário.
O DeskLink RDP e configurações dedicadas selecionadas oferecem opções relacionadas com Windows no catálogo SwissOctet. Confirme o sistema operativo, o licenciamento, os privilégios da conta e as responsabilidades de gestão da sua encomenda. Uma ligação de ambiente de trabalho suportada é o início de um plano de administração; os controlos que configura e verifica determinam como esse acesso é utilizado.
A sua lista de verificação prática.
- Utilize contas individuais e privilégios adequados.
- Restrinja o caminho de acesso RDP pretendido.
- Mantenha o NLA ativado em sistemas compatíveis.
- Teste uma segunda sessão antes de fechar o acesso atual.
- Reveja o redirecionamento, as atualizações e a política de sessão.
- Confirme o licenciamento e o procedimento de recuperação.
Os detalhes que importam.
O NLA torna um anfitrião RDP exposto completamente seguro?+
Não. O NLA é um controlo de autenticação. A acessibilidade, as credenciais, as atualizações e os privilégios continuam a exigir atenção.
Posso utilizar o Remote Credential Guard em todos os servidores Windows?+
Não. O cliente, o anfitrião e o ambiente de autenticação têm de cumprir os requisitos da Microsoft, incluindo a configuração Kerberos aplicável.
O que devo fazer antes de restringir a firewall?+
Verifique uma rota de recuperação, preserve a sessão em funcionamento e teste o novo caminho permitido através de uma segunda ligação.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- Microsoft: Ativar o Ambiente de Trabalho Remoto e a Autenticação ao Nível da Rede learn.microsoft.com
- Microsoft: Acesso através do Remote Desktop Gateway learn.microsoft.com
- Microsoft: Remote Credential Guard learn.microsoft.com
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.