APRENDER. PRATICAR. EVOLUIR.1. Inventariar o âmbito da cifragem
Um indicador de cifragem só é útil quando se sabe o que abrange. Regista volume, snapshot, base de dados, canal e endpoint separadamente. EBS encryption by default é uma configuração regional para recursos novos no seu âmbito; não converte volumes antigos. Uma evidência recolhida em eu-west-1 não demonstra a configuração em eu-central-1. A cifragem EBS protege dados em repouso e o percurso entre EC2 e o storage ligado, sem transformar automaticamente HTTP externo em TLS. Num projeto de obsolescência, liga o inventário às ações de migração necessárias e às equipas responsáveis. Se o legado continua sem cifragem, reporta essa lacuna explicitamente em vez de contar a ativação da opção como conclusão de toda a aplicação.
2. Tratar novas chaves como migrações
A chave associada a um volume ou snapshot EBS existente não muda por editar um alias. Uma cópia de snapshot permite escolher outra chave e preparar um novo volume. Planeia o cutover e a preservação dos dados posteriores à snapshot. Quando a API recebe um identificador KMS inválido, a falha pode ser assíncrona; confirma o estado final antes de aceitar a criação. Para partilhar uma snapshot cifrada, verifica também o acesso à chave gerida pelo cliente. A autorização do recurso e a autorização criptográfica são dependências diferentes. No pacote de mudança, inclui origem, cópia, chave de destino, permissões, validação funcional e critério para retirar recursos antigos. Não elimines o caminho de recuperação só porque um pedido de cópia foi aceite.
3. Distinguir cópia RDS e serviço migrado
Uma DB instance RDS cifrada conserva a chave escolhida na criação. Para outro identificador de chave, prepara snapshot, cópia com a chave pretendida e restauro de nova instância. Para uma origem sem cifragem, a cópia cifrada da snapshot é a etapa necessária antes do restauro. Uma snapshot protegida pela chave AWS managed não pode ser partilhada diretamente entre contas nesse estado. Em replicas cifradas da mesma Região, usa-se a chave da origem; noutra Região, define-se a chave desse destino. Estas regras de DB instances não devem ser generalizadas a todos os desenhos Aurora. No cenário de pagamentos, valida reconciliação, conectividade e dados pendentes antes de mudar o destino da aplicação. DNS não sincroniza dados nem prova um rollback utilizável.
4. Provar TLS e identidade do servidor
Cifrar RDS em repouso não impede um cliente SQL autorizado de obter resultados em claro; a desencriptação é transparente. Para o canal PostgreSQL, aplica a configuração efetiva de rds.force_ssl quando o requisito exige rejeitar ligações sem TLS. Testa tanto a ligação permitida como a rejeitada. No cliente libpq, verify-ca confirma a cadeia e verify-full acrescenta a correspondência do hostname. Cifra e identidade são garantias relacionadas, mas distintas. Numa mudança de CA para clientes diretos RDS, prepara a confiança da aplicação antes da alteração do servidor e confirma requisitos de reinício para a versão usada. Uma ligação antiga ainda aberta não demonstra um novo handshake com a nova cadeia. Inclui criação de ligações novas nos critérios de aceitação.
5. Localizar a validação em load balancers e APIs
Um target group HTTPS do ALB cifra o percurso até ao backend, mas o ALB não valida esses certificados de target. Não uses essa configuração como prova de rejeição de certificados expirados. No sentido do cliente, mutual TLS passthrough entrega a cadeia para validação pelo target; verify faz autenticação no ALB. Se o requisito exige revogação, confirma também o mecanismo e a atualização das listas relevantes. Em API Gateway REST, mutual TLS no domínio personalizado não desativa o endpoint execute-api por omissão. Um teste que só passa pelo nome divulgado pode ignorar esse caminho alternativo. Desenha cada segmento e identifica onde o certificado é apresentado, que identidade representa e que componente toma a decisão. A palavra HTTPS no diagrama não responde a todas essas perguntas.
6. Separar emissão, renovação e deployment
ACM não faz managed renewal de certificados importados de uma CA externa. A equipa tem de obter a renovação e gerir reimportação ou substituição e associações. Certificados públicos exportáveis emitidos por ACM têm outro ciclo: ACM gere a renovação, mas o deployment no host externo continua a ser responsabilidade do cliente. Um servidor pode apresentar o certificado antigo quando o gestor central já mostra a versão nova. Protege a chave privada e verifica cada endpoint depois da instalação. Para ALBs em Regiões diferentes, disponibiliza o certificado ACM em cada Região pertinente. Para o certificado de viewer CloudFront, o requisito é us-east-1, independentemente da localização da origem. Não generalizes essa exceção para todos os load balancers.
7. Aceitar a mudança com evidência de execução
O exercício local usa um inventário fictício de endpoints e serials observados para decidir se a instalação está completa. Não faz handshakes, não valida cadeias e não substitui ferramentas reais de diagnóstico. Um endpoint em falta mantém a aceitação pendente, mesmo quando todos os observados têm o serial pretendido. Na mudança real, acrescenta cadeia, hostname, validade, protocolo e comportamento funcional aos critérios acordados. Distribui tarefas entre PKI, cloud, aplicação e RUN, com responsáveis pelo fim de semana. Planeia recuperação sem pressupor que um certificado já revogado pode voltar a ser usado. O resumo desta aula liga a configuração desejada ao recurso criado, à ligação exercitada e ao serviço aceite. São provas complementares que devem acompanhar reporting, handover e decommissioning.
# Original fictional deployment-evidence model, not a TLS validator.
# No credentials, network calls, or certificate changes.
def deployment(required, observed, expected_serial):
if not required or not required.issubset(observed):
return "evidence-incomplete"
if any(observed[name] != expected_serial for name in required):
return "old-certificate-present"
return "serials-match-further-validation-required"
assert deployment(set(), {}, "new") == "evidence-incomplete"
assert deployment({"a", "b"}, {"a": "new"}, "new") == "evidence-incomplete"
assert deployment({"a", "b"}, {"a": "new", "b": "old"}, "new") == "old-certificate-present"
assert deployment({"a", "b"}, {"a": "new", "b": "new"}, "new") == "serials-match-further-validation-required"
assert deployment({"a"}, {"a": "new", "out-of-scope": "old"}, "new") == "serials-match-further-validation-required"
print("five deployment-evidence cases passed; no TLS connection was made")
O gestor de certificados mostra renovação, mas dois servidores ainda apresentam a versão antiga. A equipa valida o deployment por endpoint.
Armadilhas comuns
Default como migração do legado; snapshot como serviço restaurado; TLS como qualquer verificação; renovação como deployment.
Tópicos relacionados: Identidade e dados · Aceitação e continuidade
Confirma o recurso e o endpoint em uso; a configuração pretendida e a emissão central não demonstram todo o resultado.
Referência: EBS encryption by default · SCS-C03