Casos de uso de PKI: HTTPS, S/MIME e assinatura de código

A Infraestrutura de Chaves Públicas (PKI) é a base invisível das comunicações digitais seguras. Os certificados e as CAs que você estudou são aplicados diariamente em dezenas de cenários do mundo real. O exame Security+ avalia sua capacidade de reconhecer casos de uso da PKI, entender qual tipo de certificado é apropriado para cada caso e identificar qual proteção a PKI oferece em cada contexto. Os três casos de uso mais importantes no exame são HTTPS/TLS (segurança na web), S/MIME (segurança de e-mail) e assinatura de código (integridade de software).

HTTPS (HTTP sobre TLS) é o caso de uso mais visível da PKI. Quando você se conecta a https://bank.com, seu navegador: (1) recebe o certificado TLS do servidor, (2) verifica se a cadeia de certificados leva a uma CA raiz confiável, (3) compara o nome do host com os campos SAN, (4) verifica se o certificado não foi revogado e (5) usa a chave pública para uma troca de chaves Diffie-Hellman, estabelecendo uma sessão criptografada. O ícone de cadeado no navegador indica que todas essas verificações foram aprovadas. Um certificado ausente ou inválido resulta em um aviso do navegador que impede a maioria dos usuários de prosseguir.

S/MIME (Secure/Multipurpose Internet Mail Extensions) usa certificados PKI para oferecer dois serviços de segurança de e-mail. Criptografia: o remetente criptografa o corpo do e-mail com a chave pública do destinatário, de modo que somente o destinatário possa descriptografá-lo — protegendo a confidencialidade mesmo se o e-mail for interceptado durante o trânsito ou armazenado em um servidor comprometido. Assinaturas digitais: o remetente assina com sua chave privada, comprovando ao destinatário que o e-mail realmente veio do remetente e não foi alterado — protegendo a integridade e fornecendo não repúdio. O S/MIME exige que cada usuário tenha seu próprio certificado emitido por uma CA.

Assinatura de código usa PKI para assinar digitalmente software — executáveis, scripts, drivers e instaladores — para que os usuários possam verificar se o software veio de um editor confiável e não foi adulterado. O fornecedor do software assina o código com uma chave privada de um certificado de assinatura de código emitido por uma CA confiável. Quando um usuário executa o software, o OS verifica a assinatura usando a chave pública do fornecedor na cadeia de certificados. O Windows SmartScreen, o Gatekeeper do macOS e as lojas de aplicativos do iOS/Android dependem da assinatura de código para estabelecer a procedência do software. Softwares sem assinatura podem ser bloqueados ou gerar avisos de segurança.

Autenticação por certificado de cliente (também chamada de TLS mútuo ou mTLS) amplia o modelo TLS padrão ao exigir que o cliente também apresente um certificado. No TLS padrão, somente o servidor é autenticado por certificado; no mTLS, as duas partes são autenticadas mutuamente. Isso é usado para: autenticação de VPN (cartões inteligentes ou certificados de cliente em vez de senhas), autenticação de API (autenticação entre máquinas, na qual o cliente é um serviço, não uma pessoa) e acesso administrativo privilegiado (exigindo que administradores usem tokens de hardware com certificados incorporados).

O SSH usa criptografia de chave pública para duas finalidades: autenticação do servidor e autenticação do cliente. Autenticação do servidor: quando você se conecta pela primeira vez a um servidor SSH, ele apresenta sua chave de host (chave pública). Seu cliente SSH armazena essa chave em ~/.ssh/known_hosts. Em conexões posteriores, se a chave de host mudar — o que pode indicar um ataque MITM ou a reinstalação do servidor —, o SSH avisa você. Autenticação do cliente: em vez de senhas, os administradores usam pares de chaves — a chave pública é adicionada a authorized_keys no servidor, e a chave privada (que nunca é enviada) comprova a identidade. As chaves de host SSH são separadas dos certificados PKI, mas desempenham a mesma função de estabelecer confiança.

A PKI permite a assinatura digital de documentos com validade legal em muitas jurisdições. Assinaturas de PDF da Adobe, DocuSign e sistemas governamentais de assinatura eletrônica usam certificados PKI para assinar documentos. Um complemento essencial à assinatura de documentos é a marcação de data e hora: uma Autoridade de Carimbo de Tempo Confiável (TSA) assina também o hash do documento com um horário confiável, comprovando que o documento existia em um momento específico. A marcação de data e hora também é essencial para a assinatura de código — sem ela, as assinaturas de código se tornam inválidas quando o certificado de assinatura expira, mesmo no caso de software distribuído antes do vencimento.

À medida que os dispositivos IoT se proliferam, a PKI fornece um mecanismo para autenticar dispositivos em larga escala. Cada dispositivo recebe um certificado exclusivo durante a fabricação (um processo chamado provisionamento da identidade do dispositivo), permitindo que os servidores autentiquem dispositivos individuais por meio de seus certificados. Isso possibilita cenários como: um medidor inteligente comprovar sua identidade ao servidor da concessionária, um dispositivo médico se autenticar na rede de um hospital ou uma frota de veículos se autenticar no sistema de retaguarda do fabricante. A PKI para IoT precisa lidar com milhões de dispositivos com recursos limitados, impulsionando a adoção de certificados ECC por seu tamanho reduzido e sua verificação rápida.

A autenticação de VPN baseada em certificados é significativamente mais segura do que a autenticação de VPN baseada em senha. Cada usuário ou dispositivo de VPN recebe um certificado de cliente emitido pela CA interna da organização. Ao estabelecer a conexão, o gateway de VPN verifica o certificado do cliente, garantindo que ele foi emitido pela CA interna confiável, está dentro do período de validade e não foi revogado por meio de CRL/OCSP. Quando um funcionário deixa a organização, a revogação imediata do certificado impede o acesso à VPN — uma medida mais confiável do que esperar que ele não tenha compartilhado a senha com outras pessoas.

Os profissionais de segurança devem ser capazes de diagnosticar erros comuns de certificados. Certificado expirado: a data notAfter já passou — renove o certificado. Incompatibilidade de nome de host: o SAN do certificado não corresponde ao nome de host solicitado — verifique os CNs e SANs; pode ser necessário um certificado curinga ou com vários SANs. Certificado autoassinado: nenhuma CA atestou esse certificado — adicione-o ao repositório de confiança local ou substitua-o por um certificado assinado por uma CA. Cadeia incompleta: o certificado da CA intermediária não foi fornecido pelo servidor — configure o servidor para enviar a cadeia completa. Certificado revogado: a CRL ou o OCSP indica a revogação — é necessária uma resposta imediata ao comprometimento da chave.

Dois tipos de certificados lidam com vários nomes de host. Um certificado curinga abrange todos os subdomínios de primeiro nível de um domínio: *.example.com abrange www.example.com, mail.example.com e api.example.com, mas NOT sub.api.example.com (dois níveis). Um certificado e uma chave privada para todos os serviços — conveniente, mas arriscado se a chave for comprometida, pois todos os serviços serão afetados. Um certificado com vários SANs lista explicitamente vários domínios específicos na extensão SAN (por exemplo, example.com, www.example.com e api.example.com). Ele oferece mais granularidade, mas exige a atualização do certificado quando novos domínios são adicionados.

Test sua compreensão dos conceitos do CompTIA Security+ (SY0-701) abordados nesta lição.

Nesta lição, você aprendeu que os certificados HTTPS/TLS usam certificados de servidor para criptografar o tráfego da web e autenticar servidores; os certificados S/MIME permitem assinar e criptografar e-mails; os certificados de assinatura de código comprovam a integridade do software e a identidade do editor; e os certificados de cliente permitem a autenticação mútua para VPNs e APIs. A seguir, exploraremos políticas de senha e autenticação multifator.