CredSSP vs KCD na prática: qual usar em ambientes Windows e Azure?
- Rodrigo Motta
- há 12 minutos
- 3 min de leitura
Introdução
Este artigo é complementar a dois conteúdos já publicados no InfraShare:
Um artigo focado exclusivamente em CredSSP, abordando funcionamento, riscos e quando usar
Um artigo específico sobre Kerberos Constrained Delegation (KCD), publicado em 05/12/2026, com foco em conceito e configuração.
A proposta aqui não é repetir conteúdo, mas conectar os pontos.
Enquanto os artigos anteriores explicam cada tecnologia de forma isolada, este texto faz a ponte entre elas, respondendo à pergunta que surge na prática:
“Dado que ambos resolvem o problema do double hop, qual devo usar em cada cenário?”
Se você ainda não leu os conteúdos anteriores, recomendo começar por eles:
🔗 CredSSP na prática: como funciona, riscos e quando usar https://Kerberos Constrained Delegation (KCD) em Ambientes Híbridos: Guia Completo e Didático para Administradores de Windows Server
🔗 Kerberos Constrained Delegation (KCD): conceito, funcionamento e cenários de uso Kerberos Constrained Delegation (KCD) em Ambientes Híbridos: Guia Completo e Didático para Administradores de Windows Server
Neste conteúdo, vamos tratar CredSSP x KCD como soluções distintas para o mesmo problema técnico, muito comum em ambientes Windows modernos: o double hop**, com foco em ambientes reais de produção, Azure, AVD e Windows Admin Center.
O problema clássico: o double hop
O double hop ocorre quando:
O usuário acessa um servidor intermediário (ex: jump server, WAC, AVD)
A partir dele, tenta acessar um segundo recurso (SQL Server, File Server, AD, etc.)
Por padrão, as credenciais não são repassadas automaticamente para o segundo salto. É aí que entram CredSSP e KCD.
O que é CredSSP?
O CredSSP permite que o cliente delegue suas credenciais completas ao servidor remoto, que passa a agir como se fosse o usuário.
Como funciona na prática
O cliente envia usuário e senha (ou hash) ao servidor remoto
O servidor pode reutilizar essas credenciais para acessar outros serviços
Exemplo comum
Windows Admin Center acessando servidores
PowerShell Remoting com necessidade de acessar SQL ou File Server
Ambientes de laboratório ou troubleshooting rápido
Vantagens
Implementação simples
Funciona mesmo fora de domínio
Resolve rapidamente problemas de double hop
Riscos e desvantagens
🔴 Credenciais ficam disponíveis no servidor remoto
Vulnerável a ataques como Pass-the-Hash
Não atende princípios de Zero Trust
Frequentemente bloqueado por times de segurança
Quando usar CredSSP
✔ Ambientes controlados ✔ Laboratórios ✔ Acesso administrativo temporário ✔ Troubleshooting pontual
❌ Não recomendado para produção sensível
O que é KCD (Kerberos Constrained Delegation)?
O Kerberos Constrained Delegation permite que um serviço delegue autenticação de forma controlada, sem nunca receber a senha do usuário.
Como funciona na prática
O usuário autentica via Kerberos
O serviço intermediário recebe um ticket Kerberos
Esse ticket só pode ser usado para serviços explicitamente autorizados
Ou seja: não há exposição de credenciais.
Exemplo comum
Aplicação web acessando SQL Server
AVD acessando File Server
Serviços rodando como conta gerenciada (gMSA)
Vantagens
🟢 Muito mais seguro
Atende auditorias e compliance
Compatível com Zero Trust
Sem exposição de senha
Desvantagens
Configuração mais complexa
Exige domínio AD funcional
Requer cuidado com SPNs
Comparativo direto: CredSSP x KCD
Critério | CredSSP | KCD |
Tipo | Delegação de credenciais | Delegação de tickets |
Exposição de senha | Sim | Não |
Segurança | Baixa | Alta |
Complexidade | Baixa | Média/Alta |
Compliance | ❌ | ✔ |
Zero Trust | ❌ | ✔ |
Uso em produção | Não recomendado | Recomendado |
Cenários reais (sem teoria)
Windows Admin Center (WAC)
CredSSP: funciona rápido, mas gera alertas de segurança
KCD: solução ideal para produção, exige SPNs corretos
Recomendação: KCD sempre que possível
Azure Virtual Desktop (AVD)
Usuário acessa AVD
Precisa acessar File Server ou SQL
CredSSP: alto risco
KCD: padrão recomendado pela Microsoft
Recomendação: KCD + Kerberos
Laboratório / Homologação
Testes rápidos
Pouca criticidade
CredSSP aceitável, desde que documentado
Minha recomendação como especialista de infraestrutura
Use CredSSP apenas quando não houver alternativa viável e de forma temporária.
Se o ambiente é:
Produção
Auditável
Exposto à internet
Integrado com Azure
KCD não é opcional, é obrigatório.
Checklist rápido de decisão
Precisa resolver rápido? → CredSSP (temporário)
Ambiente produtivo? → KCD
Auditoria ou compliance? → KCD
WAC, AVD, aplicações corporativas? → KCD
Se você administra ambientes Windows e quer estudar Kerberos, autenticação e segurança com mais profundidade, uma leitura altamente recomendada é:
📘 Windows Server Security – Best Practices (livro técnico)
👉 Ideal para quem trabalha com AD, Kerberos, delegação e hardening.
Conclusão
Este artigo foi pensado como um complemento direto ao conteúdo anterior sobre CredSSP.
Enquanto o primeiro artigo responde “o que é CredSSP e por que ele é arriscado”, este fecha o raciocínio técnico ao responder:
“Dado o risco, qual é a alternativa correta em ambientes profissionais?”
A resposta, na maioria dos cenários modernos, é clara:
CredSSP: exceção, uso temporário, bem documentado
KCD: padrão recomendado, seguro e alinhado a Zero Trust
Se você administra ambientes Windows Server, Active Directory, Azure, AVD ou WAC, recomendo fortemente a leitura completa dos dois artigos para ter visão técnica e decisória completa sobre delegação de credenciais.
Comentários