Windows Server 2025 / O que o AD CS faz e como planejar uma PKI interna
O Active Directory Certificate Services (AD CS) é a função do Windows Server usada para emitir e gerenciar certificados da organização. Antes de implantá-lo, defina a hierarquia de confiança, as permissões de solicitação, a revogação, a renovação, a recuperação e os responsáveis pela operação conforme os usuários, dispositivos e serviços previstos.
Decida se uma CA interna é necessária
O AD CS pode operar uma autoridade certificadora (CA) dentro de uma infraestrutura de chaves públicas (Public Key Infrastructure, PKI). Uma CA assina certificados conectando uma identidade a uma chave pública. Os clientes devem confiar nessa autoridade e validar o certificado para o propósito pretendido.
A renovação repetida de certificados web internos ou a autenticação de dispositivos gerenciados pode justificar uma PKI organizacional. Uma CA interna não é automaticamente confiável por todos os navegadores. Certificados emitidos por autoridades publicamente confiáveis podem se adequar melhor a serviços públicos usados por clientes não gerenciados.
Comece com a visão geral do AD CS e faça um inventário da PKI organizacional existente ou dos serviços gerenciados de emissão de certificados. Um site HTTPS não exige automaticamente a implantação de uma nova CA.
Defina a hierarquia e os limites de confiança
| Decisão | Pergunta |
|---|---|
| CA raiz e CAs emissoras | Onde a chave de nível superior é mantida e por quem? |
| Empresarial ou independente | São necessárias a integração com o Active Directory, os modelos de certificado e a inscrição automática? |
| Online ou offline | Qual nível emite continuamente e qual permanece separado? |
| Clientes não gerenciados | Como informações de confiança e revogação chegarão a eles? |
Uma CA raiz offline e uma CA emissora online formam uma estrutura a avaliar conforme a escala, as ameaças e a capacidade de recuperação. Mais níveis não melhoram automaticamente a segurança.
Use considerações de planejamento de PKI para decidir nomes de CA e de servidores, proteção de chaves, prazos de validade e URLs de publicação antes da instalação. Não trate a renomeação de um servidor CA instalado como um ajuste rotineiro. Considere a separação de gerenciamento e proteção de chaves antes de combinar uma CA com um controlador de domínio.
Limite as permissões dos modelos e da inscrição
Os modelos de certificado definem a finalidade, as regras de uso da chave, a validade e as condições de inscrição. A extensão Extended Key Usage (EKU) identifica usos como autenticação de servidor ou cliente. A emissão irrestrita de certificados capazes de comprovar uma identidade pode facilitar a falsificação dessa identidade.
- Separe os solicitantes dos responsáveis pela aprovação e emissão.
- Decida se os solicitantes podem definir os nomes incluídos nos certificados e como esses nomes serão validados.
- Restrinja o acesso às chaves privadas e permita exportá-las apenas se houver necessidade.
- Limite a inscrição automática a finalidades e grupos aprovados; monitore falhas e certificados emitidos.
Revise o potencial de abuso antes de conceder permissões amplas de modelo a grupos como Usuários Autenticados. Separe a administração de CA, certificados e servidores comuns conforme apropriado. Consulte orientações de segurança, delegação e auditoria de CA.
Planeje a publicação da revogação e a renovação
Planeje a revogação de certificados para chaves comprometidas, usuários que saem e servidores desativados. Uma lista de certificados revogados (Certificate Revocation List, CRL) publica as revogações; a extensão Authority Information Access (AIA) indica onde obter informações sobre a autoridade emissora. Os caminhos de validação necessários devem ser acessíveis pelos clientes reais.
A publicação apenas em DNS ou LDAP internos pode ser inadequada para clientes externos. Uma CA indisponível não invalida imediatamente todos os certificados emitidos, mas interrupções na emissão, renovação e publicação de revogação têm efeitos distintos. As políticas da aplicação e do cliente também afetam o comportamento de validação.
Coordene a renovação dos certificados da CA raiz, da CA emissora e dos serviços. Solicitar um longo prazo para um certificado de serviço não elimina os limites impostos pela validade restante e pela política da CA emissora. Verifique o certificado que um serviço apresenta, e não apenas a presença de um novo certificado no repositório.
Documente a proteção das chaves e a recuperação antes da implantação
Uma chave privada de CA comprometida pode afetar todo o escopo de confiança. Considere um módulo de segurança de hardware (HSM), acessos administrativos restritos e responsabilidades separadas quando apropriado. Planeje backups pelos métodos suportados de chaves, banco de dados, configuração, políticas e informações de publicação com acesso restrito e um processo de recuperação testado.
- Identifique os sistemas que usam certificados, suas finalidades e a demanda prevista.
- Defina um responsável e explique a reutilização da PKI existente ou a necessidade de uma nova.
- Projete a estrutura das CAs, proteção de chaves, modelos, permissões e distribuição de confiança.
- Defina publicação de revogação, alertas de renovação, backups e recuperação isolada.
- Valide emissão, nomes, renovação, revogação e recuperação em um ambiente de teste separado.
Este exercício produz uma lista de verificação para planejamento e revisão. Não instale uma CA no servidor do curso DC1 nem distribua uma raiz de teste para dispositivos reais como parte deste exercício de planejamento. Antes da implantação, defina procedimentos de operação sustentáveis e um plano para retirar a confiança ou migrar os serviços.
