Microsoft AZ-801: Criptografia, Certificados e PKI — Guia de estudos

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Faz parte do Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A criptografia e a infraestrutura de chave pública formam a base de confiança de um ambiente híbrido centrado no Windows Server. Os administradores devem ser capazes de proteger dados em repouso com BitLocker e EFS, estabelecer e operar uma PKI corporativa com AD CS e um Online Responder, automatizar o ciclo de vida dos certificados por meio de modelos e registro automático (autoenrollment), e integrar o gerenciamento de certificados nativo da nuvem via Azure Key Vault. As seções a seguir detalham a arquitetura, os pré-requisitos, os padrões de implantação e os controles operacionais que aparecem consistentemente em ambientes híbridos do Windows Server no mundo real.

BitLocker e EFS no Windows Server

O BitLocker Drive Encryption protege volumes usando uma combinação do TPM e de protetores de chave. O TPM 2.0 é a recomendação de base atual; o TPM 1.2 continua sendo suportado, mas o TPM 2.0 com UEFI e Secure Boot fornece uma vinculação mais forte da cadeia de inicialização aos Registradores de Configuração da Plataforma (PCRs) do TPM. Para servidores, exija TPM+PIN em volumes do sistema operacional para adicionar um fator online, mitigando ataques de cold-boot e offline. Configure isso via Group Policy em BitLocker Drive Encryption (Exigir autenticação adicional na inicialização; Permitir PINs aprimorados para inicialização). Onde não houver TPM, uma chave de inicialização USB é possível, mas é inferior operacionalmente e menos segura.

A governança da chave de recuperação é obrigatória. Em ambientes AD DS, deposite as informações de recuperação em objetos de computador (msFVE-RecoveryInformation) via Group Policy (Escolher como as unidades do sistema operacional protegidas pelo BitLocker podem ser recuperadas; Fazer backup de senhas de recuperação e pacotes de chaves no AD DS). Em cenários com ingresso no Azure AD, as chaves de recuperação são depositadas no objeto de dispositivo do Azure AD e podem ser descobertas por administradores autorizados na blade Devices; as políticas do Intune podem exigir o depósito no Azure AD. Valide o depósito antes de habilitar a criptografia em escala.

O Network Unlock elimina a inserção manual do PIN para servidores ingressados em domínio em sub-redes seguras de datacenter durante reinicializações autônomas. Os pré-requisitos incluem volumes de SO protegidos por TPM, firmware UEFI, conectividade com fio sem bloqueio 802.1X no pré-boot, alcançabilidade de broadcast DHCP e um servidor Windows Deployment Services com o recurso Network Unlock e um certificado de autenticação de servidor emitido por uma CA corporativa usando o modelo Network Unlock. Configure as GPOs do BitLocker para habilitar o Network Unlock e garanta que o OCSP/CRL da CA esteja acessível pelo servidor WDS. O Network Unlock não se aplica a hosts móveis ou sem fio.

O pré-provisionamento acelera implantações em larga escala, criptografando o espaço usado já no Windows PE durante a criação da imagem. Em sequências de tarefas do MDT/Configuration Manager, use a etapa Pre-provision BitLocker (manage-bde -on C: -used -skiphardwaretest) para iniciar a criptografia antes que o SO completo seja implantado; mude para a proteção total após o ingresso no domínio e a aplicação da política.

Gerencie o BitLocker centralmente com o Microsoft Endpoint Manager. O Intune (MDM) impõe a criptografia silenciosa com protetores somente de TPM para dispositivos ingressados no Azure AD e deposita as chaves no Azure AD; exigir um PIN de inicialização impede a criptografia silenciosa e requer interação do usuário. Para servidores ingressados em domínio e ambientes mistos, use o Configuration Manager BitLocker Management (o sucessor do MBAM) para relatórios de conformidade, depósito, portais e rotação de chaves. Sempre projete para um depósito auditável e mapeamento de proprietário.

O EFS é uma criptografia por arquivo vinculada aos certificados EFS do usuário. Uma chave de criptografia de arquivo (FEK) é gerada por arquivo e criptografada com a chave pública EFS do usuário. Na ausência de uma CA corporativa, o Windows emite um certificado EFS autoassinado, o que impede a recuperação e o controle centralizado. Em implantações corporativas, emita certificados EFS a partir do AD CS usando o modelo Basic EFS e designe Agentes de Recuperação de Dados (DRAs) via GPO (Políticas de Chave Pública, Encrypting File System) para garantir a recuperabilidade de arquivos criptografados pelo usuário. A ferramenta de linha de comando cipher continua essencial: cipher /e e /d criptografam ou descriptografam; cipher /r gera pares de chaves DRA; cipher /u atualiza arquivos criptografados para usar o certificado EFS atual. Use o BitLocker para proteção em nível de volume e o EFS apenas quando for necessária a separação por usuário ou por arquivo, reconhecendo que o EFS requer o logon do usuário e a disponibilidade do certificado.

Hierarquia do AD CS e Online Responder

Uma PKI corporativa resiliente usa uma hierarquia de CAs em camadas. A CA raiz offline é a âncora de confiança e deve ser isolada física e logicamente, sendo ligada apenas para assinar solicitações de CAs subordinadas e publicar CRLs. Use uma validade longa (por exemplo, 10–20 anos), tamanhos de chave RSA grandes (pelo menos 4096, quando viável) e publique CDP/AIA em URLs de alta disponibilidade e com caminhos consistentes. Nunca emita certificados de entidade final a partir da raiz.

As CAs subordinadas (emissoras) são ingressadas no domínio, online e de curta duração (por exemplo, 3–5 anos) com uso de chave e EKUs restritos. Elas emitem certificados de computador, usuário e serviço e publicam CRLs frequentes com sobreposição para evitar interrupções durante atrasos na publicação. Prefira chaves privadas respaldadas por HSM nas CAs emissoras para reduzir o risco de exfiltração de chaves. Configure restrições baseadas em registro ou política nos modelos e na emissão para impor o princípio do menor privilégio.

A verificação de revogação deve ser rápida e confiável. Um Online Responder (OCSP) reduz a latência do cliente ao responder a consultas de status por certificado, em vez de baixar CRLs completas. Instale o serviço de função Online Responder, inscreva os respondentes para um certificado de Assinatura de Resposta OCSP por meio de um modelo v3 dedicado e configure uma Configuração de Revogação que aponte para a CA emissora e suas CRLs usando o Microsoft CRL-based Revocation Provider. Garanta que a CA inclua uma URL de OCSP na extensão Authority Information Access para que os clientes saibam onde consultar.

Para escala e resiliência, implante um array de OCSP. Designe um controlador de array para replicar as configurações de revogação para os respondentes membros. Faça o balanceamento de carga do array usando o Windows NLB ou um balanceador de carga externo com uma sonda de saúde que confirme a responsividade do OCSP e a atualização dos certificados de assinatura. Fixe tempos de vida curtos para os certificados de assinatura OCSP e use a inscrição automática para renovação a fim de minimizar a exposição a riscos. Monitore a atualização da CRL e o tempo de vida do cache do OCSP para evitar respostas obsoletas.

Modelos, Inscrição Automática, Arquivamento de Chaves e Credential Roaming

Os modelos de certificado governam as restrições de solicitação, o nome do requerente (subject name), os usos da chave e os requisitos de emissão. Os modelos da Versão 2 (introduzidos com o Windows Server 2003 Enterprise) permitem personalização e suportam inscrição automática com chaves baseadas em CSP. Os modelos da Versão 3 (Windows Server 2008 e posterior) adicionam suporte a CNG, ECC e algoritmos Suite B. Escolha v3 quando precisar de CNG/ECC; escolha v2 para máxima compatibilidade com sistemas legados. Vincule os modelos a um único conjunto de CAs emissoras para conter o raio de impacto.

A inscrição automática transforma o ciclo de vida do certificado em um processo automatizado orientado por políticas. Configure a Política de Grupo em Computer Configuration ou User Configuration, Windows Settings, Security Settings, Public Key Policies, Certificate Services Client – Auto-Enrollment. Habilite-a com as opções Renew expired certificates, Update certificates that use certificate templates e Remove revoked/expired certificates. A inscrição automática requer permissões no modelo: as entidades de segurança (principals) devem ter Read e Autoenroll; a permissão Enroll é suficiente apenas para inscrição manual. Delimite o escopo por grupos de segurança para evitar a emissão inesperada de certificados e controlar o volume.

O arquivamento de chaves protege os dados caso uma chave privada seja perdida. Habilite a opção Archive the subject’s encryption private key no modelo para certificados somente de criptografia (por exemplo, EFS, S/MIME). Designe Agentes de Recuperação de Chave (KRAs) emitindo para eles certificados de KRA a partir do modelo Key Recovery Agent e configure a CA para arquivar chaves. A recuperação é limitada a tipos de chave arquiváveis; tradicionalmente, o RSA Key Exchange (CSP legado) é suportado, enquanto o arquivamento de chaves privadas CNG/ECC não é suportado pelo arquivamento de chaves do AD CS. Não habilite o arquivamento para modelos somente de assinatura.

O Credential Roaming sincroniza certificados de usuário, chaves privadas e chaves mestras da DPAPI entre dispositivos ingressados no domínio, armazenando-os no AD. Habilite-o via Política de Grupo em User Configuration, Administrative Templates, System, Credential Roaming e delimite o escopo para usuários confiáveis. Isso melhora a experiência do usuário para certificados de EFS, S/MIME e de autenticação de cliente em várias máquinas, sem a necessidade de perfis móveis (roaming profiles). Valide o suporte do esquema de diretório e planeje a interação com o Windows Hello for Business e gerenciadores de credenciais de terceiros para evitar conflitos ou duplicação.

Ciclo de Vida de TLS/SSL e Integração com o Azure Key Vault

O TLS moderno depende da semântica correta dos certificados. Sempre inclua o EKU de Autenticação de Servidor e prefira assinaturas SHA-256 ou mais fortes com RSA de pelo menos 2048 bits ou curvas ECC apropriadas. O Subject Alternative Name (SAN) deve listar todos os hostnames que os clientes usam; o antigo Subject CN sozinho é insuficiente para clientes modernos. Certificados curinga (*.contoso.com) simplificam implantações de múltiplos hosts em uma única zona DNS, mas não correspondem a nomes de múltiplos níveis (app.dev.contoso.com) ou zonas diferentes; avalie cuidadosamente a concentração de risco quando chaves privadas curinga são implantadas amplamente. Para necessidades de múltiplas zonas, prefira certificados SAN ou múltiplos certificados direcionados.

Padronize os CSRs com certreq ou IIS, mantenha políticas de custódia de chaves e automatize a renovação bem antes da data de expiração (NotAfter) para permitir implantações em fases e a propagação de OCSP/CRL. Em servidores web ingressados no domínio, o registro automático (autoenrollment) com um template de Web Server v3 pode automatizar a emissão e a renovação; use o fornecimento do nome do sujeito na solicitação com as aprovações apropriadas. Aplique configurações de servidor que aceitem apenas TLS 1.2/1.3, habilite os pacotes de cifras ECDHE para forward secrecy e remova cifras SHA-1 obsoletas e de nível de exportação.

O Azure Key Vault estende o ciclo de vida dos certificados para a nuvem. Você pode importar certificados PFX/PEM existentes, gerar novos com uma autoridade de certificação (CA) integrada ao Key Vault (por exemplo, DigiCert) usando uma política de certificado e definir a rotação automática para que o Key Vault solicite a renovação e mantenha a versão mais recente. O objeto de certificado encapsula uma chave e um segredo do Key Vault, permitindo fluxos de trabalho com PFX exportáveis ou chaves não exportáveis respaldadas por HSM, dependendo da política. Aplicações e serviços recuperam as versões atuais via RBAC ou políticas de acesso e identidades gerenciadas (managed identities). As referências do Key Vault permitem que serviços como o Azure App Service e o Azure Functions obtenham certificados e segredos por referência, sem incorporá-los na configuração. Para cargas de trabalho do Windows Server no Azure ou em ambiente híbrido, use a extensão de VM do Azure Key Vault ou automação personalizada com identidades gerenciadas para buscar e instalar certificados atualizados no repositório de certificados do Windows e acionar reinicializações de serviço, garantindo renovações sem intervenção manual (zero-touch) em servidores web, proxies reversos e gateways de aplicação.

Cenário de Problema Prático

A Adobe Inc. precisa padronizar a criptografia e a PKI em dois datacenters on-premises e em cargas de trabalho do Windows Server hospedadas no Azure. Eles exigem reinicializações de servidor não supervisionadas nos datacenters, renovações automatizadas de certificados web, recuperação de criptografia por arquivo e atrito mínimo para o usuário.

1. Construir uma PKI de duas camadas com uma CA raiz offline e duas CAs emissoras online

• Por quê: Uma CA raiz offline cria uma âncora de confiança de alta garantia, enquanto CAs emissoras de curta duração limitam a exposição e suportam alta disponibilidade. A hierarquia permite a separação de funções, o escopo escalável de templates e a publicação segura de CRL/AIA.

2. Implantar um array de OCSP Online Responder atrás de um balanceador de carga

• Por quê: O OCSP fornece respostas de revogação de baixa latência para servidores web e de aplicação em escala. Um array com balanceamento de carga e verificação de integridade (health-check) evita pontos únicos de falha e garante que os clientes obtenham o status atualizado sem baixar CRLs grandes.

3. Criar templates de certificado v3 para Web Server, Assinatura de Resposta OCSP e Autenticação de Computador; templates v2 para EFS e S/MIME com arquivamento de chave

• Por quê: A v3 habilita CNG/ECC para TLS moderno e assinatura de respondentes; a v2 maximiza a compatibilidade de clientes para EFS/S/MIME e suporta o arquivamento de chaves de criptografia. O escopo de templates impõe a emissão com o menor privilégio.

4. Habilitar o registro automático (autoenrollment) via Group Policy e atribuir permissões de Leitura/Registro Automático nos templates para grupos de segurança com escopo definido

• Por quê: O registro automático remove etapas manuais, lida com renovações antes da expiração e limpa certificados revogados/expirados. O escopo por grupo de segurança evita a emissão excessiva e adere ao princípio do menor privilégio.

5. Implementar o BitLocker em todos os servidores com TPM+PIN para volumes do SO; depositar (escrow) as chaves de recuperação no AD DS

• Por quê: O TPM+PIN aumenta a resistência a ataques offline; o depósito no AD DS garante a recuperabilidade. Os servidores atingem as metas de tempo de atividade (uptime) enquanto garantem a auditabilidade da custódia de chaves em nível de conformidade.

6. Configurar o Network Unlock usando o WDS com o recurso Network Unlock nas sub-redes do datacenter

• Por quê: Reinicializações não supervisionadas após a aplicação de patches, sem acesso ao console local, são habilitadas, mantendo os controles de segurança do TPM+PIN fora do datacenter. UEFI+TPM e DHCP com fio atendem aos pré-requisitos técnicos.

7. Gerenciar a postura do BitLocker com o Configuration Manager BitLocker Management e seus relatórios

• Por quê: O Configuration Manager oferece cobertura madura para servidores, painéis de conformidade e fluxos de trabalho de autoatendimento/recuperação, reduzindo a sobrecarga operacional em um ambiente misto on-premises e Azure.

8. Emitir certificados EFS a partir do AD CS e configurar DRAs via GPO; exigir que os usuários façam backup dos seus certificados EFS

• Por quê: A emissão centralizada mais os DRAs garantem a continuidade dos negócios para a criptografia em nível de arquivo. As chaves DRA são rigorosamente controladas para evitar abusos, mantendo as opções de recuperação.

9. Centralizar os certificados TLS para cargas de trabalho voltadas para a Internet no Azure Key Vault com integração de CA gerenciada e rotação automática; distribuir para o Windows Server via automação com identidades gerenciadas

• Por quê: O Key Vault delega a renovação, centraliza segredos, suporta versionamento e permite a implantação segura e automatizada em servidores. A rotação automática elimina expirações e se alinha com operações sem intervenção manual (zero-touch).

10. Habilitar o Credential Roaming para um conjunto de usuários com escopo definido que necessitam de EFS e S/MIME em múltiplos dispositivos

• Por quê: O Credential Roaming sincroniza certificados e chaves DPAPI, garantindo que os usuários possam descriptografar e assinar em diferentes estações de trabalho sem exportação/importação manual, melhorando a produtividade e reduzindo os tickets de suporte.

← Azure Arc e Gerenciamento de Servidores Híbridos · Todos os domínios · Atualização e Gerenciamento de Patches do Windows Server →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →