Boas práticas de Workloads
Teste mudanças em staging antes da produção, feche o workload domain quando o seu domínio servir tráfego e substitua certificados sem interrupção.
O ponto de entrada de um site decide quem pode alcançá-lo e se uma conexão é confiável. Erros nesse ponto raramente aparecem como um erro no seu código. Uma mudança testada no tráfego real alcança todos os visitantes de uma vez, um endereço que você esqueceu fica aberto a qualquer pessoa que o encontre e um certificado que expira deixa de proteger o tráfego no dia em que vence.
Estas práticas se aplicam a um workload, aos hostnames e às configurações de TLS que ele guarda e aos certificados que ele usa. Os mecanismos por trás delas estão em Como Workloads funciona, e cada campo está em Configurações de workload.
Uma mudança em um workload leva vários minutos para alcançar toda a infraestrutura distribuída da Azion e, nesse meio-tempo, as requisições podem encontrar a configuração antiga ou a nova, como descreve Propagação. Cada verificação desta página só vale quando requisições repetidas concordam.
As quatro primeiras práticas se aplicam a todo workload: testar uma mudança em um workload de staging, fechar o workload domain quando o seu próprio domínio servir tráfego, manter o mTLS permissive para testes e garantir que os clientes enviem SNI. As práticas para os certificados que um workload usa vêm em seguida, em Certificate Manager.
Teste uma mudança em um workload de staging antes da produção
Um workload criado em Staging Infrastructure roda na Staging Network, separado da produção, então um erro ali não alcança nenhum visitante do seu site. Ele responde apenas no seu workload domain, <id>.preview.azionedge.net, porque um workload de staging não aceita domínio personalizado. O custo é um segundo workload com o seu próprio deployment, que você mesmo mantém em sincronia com a produção. A infraestrutura é fixada na criação, então uma configuração testada chega à produção como um novo workload, não como uma edição do workload de staging.
Este arquivo, enviado com azion create workload --file, cria um workload de staging por meio de "infrastructure": 2:
A CLI responde Created Workload with ID <workload-id>, e azion describe workload --workload-id <workload-id> --format json retorna um workload_domain que termina em .preview.azionedge.net. Para testar um hostname de produção antes que os registros DNS dele mudem, liste-o em um workload de produção e mapeie-o para o endereço do workload domain no seu arquivo hosts, como descreve Teste uma aplicação pelo arquivo hosts.
Feche o workload domain quando o seu domínio servir tráfego
Enquanto Workload Domain Allow Access está ativado, que é o padrão, um workload responde no seu workload domain e também nos seus próprios hostnames. Desativá-lo deixa os hostnames em domains como a única entrada, então todo cliente chega por um nome que você escolheu listar. O custo é uma dependência: a API recusa a mudança em um workload cuja lista domains está vazia, com When the workload hostname access is blocked, the workload requires alternate domains or domains.
Envie este corpo com azion update workload --file, que lê o ID do workload da chave "id":
A CLI responde Updated Workload with ID <workload-id>. Depois que a mudança se propaga, uma requisição ao workload domain responde 404, enquanto os seus próprios domínios continuam servindo. Desative a opção somente depois que os seus próprios hostnames responderem em todos os lugares, para que os clientes sempre tenham um hostname que funcione. Para apontar o seu domínio para o workload antes, consulte Aponte um domínio para um workload.
Use mTLS permissive apenas para testes
Com o mTLS ativado, mtls.config.verification decide o que um workload faz com um cliente que não apresenta certificado, ou que apresenta um que a sua Trusted CA não assinou. No modo enforce, o handshake falha para esses clientes. No modo permissive, ele se completa e a requisição alcança a aplicação, então um workload permissive mal configurado admite os clientes que o mTLS deveria recusar.
Use permissive para testar o acesso em condições específicas e sirva a produção com enforce, como neste corpo para azion update workload --file:
Enquanto um workload permanece em permissive, uma regra de firewall sobre a variável Client Certificate Validation é o que recusa um cliente sem um certificado válido, como explica Modos de verificação. Para verificar o modo em vigor, envie curl -skv https://<your-domain>/ -o /dev/null sem certificado de cliente: em enforce, o handshake falha e o curl sai com o código 56. Para os passos, consulte Configure mTLS em um workload.
Garanta que toda aplicação cliente envie SNI
Server Name Indication (SNI) é a extensão de TLS na qual um cliente nomeia o host que deseja durante o handshake. Os domínios servidos com um certificado que você envia dependem dela. Uma conexão sem SNI alcança a configuração padrão, que apresenta o certificado SAN da Azion em vez do seu. Em um workload com mTLS no modo enforce, a Azion fecha essa conexão antes de resolver uma rota da sua aplicação.
A configuração fica em cada cliente, como o cliente de API de um parceiro ou um serviço que chama o seu workload, então a Azion não pode adicioná-la por eles. Confirme com o responsável por cada aplicação cliente que a biblioteca TLS dela envia, como nome do servidor, o hostname que ela chama. Um cliente que apresenta um certificado que a sua Trusted CA assinou e, ainda assim, nunca alcança a aplicação é o primeiro a verificar. Para os demais requisitos do mTLS, consulte mTLS.
Certificate Manager
Certificate Manager armazena os certificados de servidor que um workload apresenta e os certificados de CA confiável com os quais o mTLS verifica os clientes. As práticas abaixo tratam de substituir um certificado de servidor antes que ele expire, manter o registro de desafio de um domínio hospedado em outro lugar, escolher um nível de validação, restringir as credenciais de DNS e manter certificados wildcard fora de sistemas críticos.
Substitua um certificado de servidor antes que ele expire
Um certificado de servidor que você envia não se renova sozinho e, depois que a data em validity passa, ele deixa de proteger o tráfego. Trocar enquanto o certificado antigo ainda é válido deixa tempo para confirmar que o novo funciona e para voltar ao antigo se ele não funcionar. A entrada antiga permanece em Certificate Manager depois da troca, então o custo é mais um certificado para excluir. A Azion renova os certificados Let’s Encrypt que gerencia, como descreve Emissão e renovação.
Envie o novo certificado e, depois, aponte tls.certificate para o ID dele com azion update workload --file. Mantenha ciphers e minimum_version nos valores que o workload já tem, para que o certificado seja o único valor que muda:
A CLI responde Updated Workload with ID <workload-id>. Em seguida, azion list digital-certificate --details mostra o novo certificado como active e o antigo como inactive quando nenhum workload o nomeia mais. Quando o novo certificado estiver active e a mudança tiver se propagado, exclua a entrada antiga. Para o envio em si, consulte Envie um certificado digital.
Mantenha o registro de desafio de um domínio hospedado fora do Edge DNS
A Azion renova um certificado Let’s Encrypt gerenciado antes que ele expire, executando o desafio dele novamente. Para um certificado DNS-01 cuja zona está no Edge DNS, a própria Azion escreve o registro _acme-challenge. Para uma zona hospedada em outro provedor de DNS, você adiciona esse registro. Excluí-lo depois faz a próxima renovação falhar, e o certificado então expira.
Mantenha o registro no seu provedor enquanto um workload usar o certificado. Para verificar, confirme antes de cada renovação que o registro ainda existe e que o status do certificado em Certificate Manager não é failed. Para o registro a criar, consulte Solicite um certificado Let’s Encrypt.
Escolha um certificado validado por domínio, a menos que precise de mais
A autoridade certificadora que emite um certificado que você envia valida a solicitação em um de três níveis. Domain Validation (DV) confirma o seu direito de usar o domínio. Organization Validation (OV) acrescenta verificações sobre a organização solicitante, e Extended Validation (EV) pede documentos que comprovem a existência física, jurídica e operacional dela.
A Azion recomenda DV para a maioria das empresas. OV e EV são mais complexos de obter, e as verificações extras dão garantias sobre a sua organização, não sobre o domínio. Peça OV ou EV somente quando um requisito que você consiga nomear exigir essas verificações. Para os três níveis, consulte Níveis de validação.
Limite as credenciais de DNS-01 aos registros de desafio
Quando uma zona está hospedada fora do Edge DNS e a sua própria automação escreve o registro _acme-challenge nesse provedor de DNS, a automação guarda as credenciais de API do provedor. Credenciais que alcançam todos os registros dão a quem as obtiver o controle do domínio e de todos os registros dele.
Restrinja essas credenciais a registros _acme-challenge, para que um vazamento exponha apenas o desafio. O custo é uma credencial separada para criar e manter só para essa automação. Uma zona no Edge DNS não precisa de nenhuma credencial sua, porque a própria Azion escreve o registro. Para verificar, confirme no seu provedor que as permissões da credencial nomeiam apenas registros _acme-challenge.
Mantenha certificados wildcard fora de sistemas críticos de produção
Um certificado wildcard, como um para *.example.com, cobre todos os subdomínios com uma única chave privada. Se essa chave vazar, ou se o certificado for revogado, todos os subdomínios são afetados de uma vez. A Azion recomenda um certificado wildcard quando a gestão centralizada é uma prioridade, a mesma equipe gerencia os subdomínios, existe uma arquitetura de proxy reverso bem definida e as suas políticas de segurança permitem o compartilhamento controlado de chaves.
Sob requisitos mais rígidos, dê a cada sistema crítico de produção o seu próprio certificado, mantenha certificados separados para ambientes de desenvolvimento e deixe o wildcard para serviços de menor criticidade. O custo é uma substituição por certificado em vez de uma para todos. Mantenha a chave privada de um wildcard em Certificate Manager, vinculada a workloads, em vez de espalhada por servidores: depois de salva, a chave não pode ser lida de volta pelo Azion Console nem pela API. Para verificar, liste os workloads que nomeiam cada certificado wildcard em tls.certificate e dê a qualquer workload crítico de produção um certificado próprio.