Private CA registra cada emissão: guia de campo do IssueCertificateDetails

O que existia antes: três fontes parciais. O evento de gerenciamento IssueCertificate provava que a chamada à API passou e entregava o ARN do certificado. O evento SignCertificate registrava a operação de assinatura. E o relatório de auditoria, gerado no máximo a cada 30 minutos para um bucket S3, listava serial, subject, validade e revogação. Nenhum dos três trazia SAN, extensões X.509 ou o algoritmo de assinatura. Para saber que nomes DNS saíram de fato num certificado, o caminho era GetCertificate por ARN e openssl x509 -text, com um teto padrão de 75 chamadas por segundo e uma condição dura: a CA precisa ainda existir. CA apagada, certificado irrecuperável.

Onde isso quebra: no modo de certificado de curta duração. Uma CA nesse modo custa US$ 50 por mês e emite certificados de até 7 dias a US$ 0,058 cada; é o modo certo para mTLS entre workloads. Com 20 mil workloads renovando a cada 3 ou 4 dias, são 5 a 6 mil emissões por dia. Reconstruir o inventário retroativamente por GetCertificate vira um job de horas que corre contra a própria validade dos certificados. A própria documentação do relatório de auditoria hoje diz, com todas as letras, para capturar o detalhe no momento da emissão em CAs de alto volume.

O que ninguém via: falha antes da assinatura. Template errado, violação de name constraints, CSR fora do padrão: a chamada falhava, o cliente recebia uma exceção e o auditor não tinha linha nenhuma para olhar. Em ambiente com BACEN ou PCI-DSS, ausência de registro de tentativa negada é achado de auditoria, não detalhe.

O IssueCertificateDetails é um evento de serviço (eventType: AwsServiceEvent, managementEvent: true) com eventSource: acm-pca.amazonaws.com. Chega sozinho, sem opt-in, em toda região onde o Private CA existe, e só paga o preço padrão do CloudTrail. O conteúdo útil mora em serviceEventDetails:

• tbsCertificate: o DER do certificado to-be-signed em base64, com todos os campos e extensões, sem a assinatura.
• issuerName, issuerSerialNumber, issuerAuthorityKeyIdentifier: qual CA assinou, útil quando você roda hierarquia com várias intermediárias.
• subject, serialNumber, notBefore, notAfter, issuedAt, templateArn, signingAlgorithm: os campos de conveniência que vão virar colunas.
• status (ISSUED ou FAILED) e statusReason, por exemplo Name Constraints violation: DNS name not found in a permitted subtree.
• requesterAccountId e requesterArn para chamadas diretas, ou requesterServicePrincipal (como acm.amazonaws.com) quando um serviço ou conector pediu em seu nome.

Três armadilhas que o guia documenta e eu confirmei: primeiro, o userIdentity do envelope é invokedBy: acm-pca.amazonaws.com, não o chamador; filtrar por principal no CloudTrail não acha nada, o solicitante está dentro de serviceEventDetails. Segundo, nenhum dos três campos de solicitante é garantido: emissões atribuídas a processo interno da AWS vêm sem os três. Terceiro, status nunca é PENDING: o evento só sai quando a emissão chega a estado terminal, e numa falha anterior à geração do TBS os campos derivados dele (tbsCertificate, subject, serialNumber) simplesmente não existem. Em CA compartilhada, o anúncio diz que o evento vai para a conta dona da CA; o guia do usuário diz que vai para a dona e para a solicitante. Quando a conta dona é a de segurança, o auditor olha num lugar só.

O caso de uso que me interessa de verdade: migração de algoritmo. Toda PKI financeira que eu toquei tinha uma mistura de SHA256WITHRSA em certificados antigos e ECDSAWITHSHA256 nos novos, e a única forma de medir o progresso era amostrar. O campo signingAlgorithm em cada evento transforma isso numa consulta: percentual de emissões por algoritmo por semana, por template, por conta solicitante. Quando a hora da criptografia pós-quântica chegar, é a mesma consulta com outro valor. Alarme de CloudWatch sobre um metric filter contando emissões SHA256WITHRSA depois da data de corte é o controle mais barato que existe para "ninguém voltou a usar o template antigo".

Inventário: o relatório de auditoria continua sendo a fotografia oficial (serial, revogação, validade) e continua necessário, porque o novo evento não cobre revogação; RevokeCertificate é outro evento de gerenciamento. Mas o inventário operacional, o que responde "quantos certificados expiram nas próximas 72 horas e de quem são", passa a ser notAfter e requesterArn numa tabela, atualizada em minutos, sem GetCertificate e sem depender de a CA ainda existir. Desde 31 de março de 2026 o Private CA também publica no CloudWatch a contagem de certificados emitidos por CA e de CAs por região; use a métrica para vigiar a cota (100 milhões por CA, ou 1 milhão quando a CA usa CRL completa) e o evento para saber o que compõe esse número.

O que o evento não resolve: certificados emitidos antes de 5 de outubro de 2026 não ganham evento retroativo. O backfill desses continua pelo caminho antigo, relatório mais GetCertificate, e é a última vez que você precisa rodá-lo.

Custo de trilha: a primeira cópia de management events é gratuita; cópias adicionais custam US$ 2,00 por 100 mil eventos. A cota padrão de IssueCertificate é 25 por segundo por conta e região, ajustável, o que dá um teto de cerca de 2,16 milhões de emissões por dia. No pior caso teórico, uma segunda trilha dedicada custaria US$ 43 por dia; na prática, com 6 mil emissões diárias, são US$ 0,12. O que pesa é o que você empilha em cima: Insights a US$ 0,35 por 100 mil eventos analisados e Lake a US$ 0,75 por GB ingerido. Assumindo cerca de 3 KB por evento (o TBS em base64 é a maior parte), 6 mil eventos por dia são 18 MB por dia, meio GB por mês, centavos. É a consulta mal escrita, sem filtro de partição, que estoura o orçamento, não o evento.

Custo de manutenção, que é o que importa: o decodificador de TBS é código seu. Vai quebrar quando um template novo introduzir uma extensão que o parser não conhece, e vai quebrar em silêncio se você não contar eventos de entrada contra linhas de saída. Coloque esse diferencial num alarme desde o primeiro dia.

LGPD e segregação: certificados de usuário emitidos pelo conector de Active Directory carregam nome e e-mail no subject e no SAN. O bucket da trilha vira, sem ninguém decidir, um repositório de dado pessoal com retenção longa. Isso muda quem pode ler o bucket, exige chave KMS própria com política que negue kms:Decrypt fora da conta de segurança, e entra no registro de operações de tratamento. Não é problema do Private CA; é consequência de ter, finalmente, o conteúdo inteiro no log.