Uma configuração TLS segura protege a comunicação e permite ao cliente verificar a identidade do serviço com que comunica. Para uma organização, o trabalho envolve versões do protocolo, parâmetros criptográficos, certificados, chaves e todos os pontos onde a ligação é terminada. Ter um certificado válido no endereço público não demonstra que o percurso até à aplicação e às integrações está protegido.
O resultado deste plano é um inventário de ligações, uma configuração de referência e um processo de renovação e verificação. O âmbito deve incluir páginas web, API, ligações internas e outros serviços que utilizem TLS. As recomendações técnicas não devem ser apresentadas como uma obrigação portuguesa de seguir integralmente uma referência nacional estrangeira.
Situar TLS na proteção de dados
TLS protege dados em trânsito entre os pontos da ligação que o utilizam. Não impede que o destinatário autorizado leia os dados, não corrige permissões excessivas na aplicação e não anonimiza o conteúdo. Um ficheiro enviado por uma ligação protegida pode continuar a ser disponibilizado à pessoa errada.
O artigo 32.º do RGPD relaciona as medidas de segurança com o risco e as circunstâncias do tratamento. A análise deve considerar o percurso efetivo e as restantes medidas. A cifragem de dados e gestão de chaves trata a proteção do conteúdo noutros estados e os meios necessários para o recuperar.
Comece por identificar o que a ligação transporta e quem controla cada extremidade. Uma API de faturação, um portal público e um serviço de administração podem exigir decisões distintas sobre autenticação de clientes, exposição e continuidade.
Rever as versões com documentação atual
O RFC 9325 reúne recomendações para utilização segura de TLS e DTLS, incluindo a retirada de versões antigas e escolhas de configuração. O RFC 9852, publicado em julho de 2026, atualiza a orientação para novos protocolos que utilizam TLS: devem especificar TLS 1.3 como predefinição, podendo admitir TLS 1.2 como opção adicional não predefinida por razões de implantação.
Essa atualização tem um âmbito preciso. Não estabelece uma data de proibição legal portuguesa de todas as ligações existentes em TLS 1.2 e não aplica essa alteração a DTLS. A migração de um serviço existente deve considerar clientes, bibliotecas e configuração; uma referência antiga que exige suporte universal de TLS 1.2 não deve ser copiada como regra para novos protocolos.
Como ponto de partida técnico para o serviço web do exemplo, a equipa retira SSL 2.0, SSL 3.0, TLS 1.0 e TLS 1.1, de acordo com as recomendações de versões do RFC 9325. Adota TLS 1.3 e conserva TLS 1.2 apenas para os clientes identificados, com configuração atual que privilegia troca efémera de chaves e cifragem autenticada, como ECDHE com AES-GCM. A referência identifica a biblioteca e os conjuntos efetivamente permitidos; uma exceção de compatibilidade não reativa protocolos obsoletos para todos os clientes.
No inventário, registe versões permitidas e versões efetivamente negociadas. Uma aplicação pode anunciar suporte de TLS 1.3, mas um componente intermédio terminar a ligação com outra configuração. A verificação precisa de observar o ponto que o cliente realmente contacta.
Escolher parâmetros sem copiar uma lista fora do contexto
As escolhas criptográficas dependem da versão, da biblioteca e da aplicação. Use recomendações atuais e configurações suportadas, identificando a referência e a data. Evite copiar parâmetros de uma página antiga apenas porque a lista inclui o nome de uma autoridade de cibersegurança.
Para um serviço que ainda precisa de TLS 1.2, examine os mecanismos de troca de chaves, a proteção autenticada do conteúdo e as extensões relevantes. Uma biblioteca atualizada não implica que a aplicação deixou de oferecer opções antigas. A equipa deve confirmar a configuração efetiva e manter uma razão documentada para a compatibilidade necessária.
A proteção de sessões passadas em caso de comprometimento posterior de uma chave de longa duração depende do mecanismo usado. Não confunda uma chave de certificado maior com a resolução de todos os riscos de negociação. As opções devem ser avaliadas em conjunto e mantidas pela pessoa responsável pela plataforma.
Associe esta configuração ao perfil de segurança de Windows e Linux quando esses sistemas suportam os serviços. Se o TLS termina num serviço gerido, registe quais os parâmetros controlados pela organização e quais dependem do fornecedor.
Inventariar certificados e proprietários
Para cada certificado, registe os nomes abrangidos, a entidade emissora, a validade, a localização da chave privada, os componentes que o utilizam e o responsável pela renovação. Inclua ambientes de administração e integrações menos visíveis. Um certificado esquecido num serviço interno pode interromper uma atividade mesmo quando o sítio público funciona normalmente.
Os Baseline Requirements do CA/Browser Forum para certificados TLS publicamente confiáveis preveem, para certificados emitidos a partir de 15 de março de 2026 e antes de 15 de março de 2027, um máximo de 200 dias, com recomendação de não ultrapassar 199 dias. O âmbito é o ecossistema de emissão publicamente confiável abrangido pelo documento; não é um prazo geral do RGPD para todo e qualquer certificado interno.
Este encurtamento reforça a utilidade de renovação automatizada e acompanhamento. Não mantenha num procedimento atual a antiga referência de 398 dias como máximo universal. Confirme também a política efetiva da entidade emissora, que pode emitir certificados com duração inferior.
Renovar e confirmar a instalação
A renovação tem várias etapas: demonstrar controlo do nome, emitir, disponibilizar a chave e a cadeia, carregar o certificado nos componentes e confirmar o resultado observado pelo cliente. Um processo pode emitir corretamente e falhar na instalação, deixando o serviço a apresentar o certificado antigo.
Defina alertas independentes sobre o certificado servido. No exemplo fictício, uma empresa decide alertar antes do fim da validade com margem para intervenção e escalar se a renovação não alterar o certificado observado. Os intervalos concretos são escolhas operacionais, ajustadas ao prazo de emissão e à disponibilidade de suporte.
Quando houver vários pontos de presença ou servidores, verifique se todos apresentam o resultado esperado. Uma falha intermitente pode ocorrer porque apenas parte da infraestrutura recebeu a atualização. Guarde evidência suficiente para identificar o componente em falta, sem incluir chaves privadas nos registos de diagnóstico.
Proteja as credenciais usadas para validação e automatização. Uma integração com permissões amplas sobre DNS merece revisão do âmbito. O mecanismo de renovação não deve criar um acesso desnecessário a zonas e serviços sem relação com os certificados que mantém.
Verificar nomes, cadeias e validação do cliente
O cliente deve validar a identidade do serviço e a cadeia de confiança aplicável. Não contorne um erro desativando a validação de certificados na aplicação. Esse contorno pode permitir que uma ligação cifrada termine numa entidade indevida, frustrando a finalidade de autenticação.
No exemplo, uma integração falha após mudança de fornecedor porque o nome configurado já não corresponde ao certificado servido. A equipa corrige o endereço e o percurso de confiança adequado. Não aceita uma opção «ignorar certificado» como solução permanente para manter a operação.
Inclua relógios, cadeias intermédias e diferenças entre clientes suportados na análise de falhas. Um navegador pode funcionar enquanto uma biblioteca utilizada por uma aplicação antiga rejeita a cadeia. A resposta deve identificar a causa concreta e um percurso de atualização, em vez de reduzir a segurança para todos os clientes.
Mapear terminação em intermediários
A cartografia dos sistemas deve mostrar onde TLS termina: serviço de distribuição, balanceador, proxy e aplicação. A ligação entre navegador e intermediário pode estar protegida enquanto o segmento seguinte tem configuração distinta. Examine confidencialidade, autenticação e controlo de acesso em cada trecho relevante.
Uma empresa fictícia coloca o portal atrás de um serviço de distribuição. Descobre que a origem continua acessível diretamente e aceita pedidos sem passar pelas verificações previstas. A correção inclui restringir o acesso à origem e configurar a proteção adequada desse segmento. O certificado público não resolvia esse caminho alternativo.
Se um intermediário consegue ler o conteúdo, considere o seu papel no tratamento e as condições contratuais. A utilização de TLS não elimina a necessidade de analisar responsável e subcontratante nem, quando aplicável, as transferências internacionais.
Aplicar políticas web com compreensão do alcance
HSTS permite indicar ao navegador que use ligações seguras para um domínio durante um período. Antes de alargar a política a subdomínios, confirme que esses serviços conseguem cumprir a configuração. Uma implantação sem inventário pode bloquear utilizações legítimas em subdomínios esquecidos.
O RFC 6797 sobre HSTS descreve o mecanismo. Escolha os parâmetros e a expansão segundo o ambiente, sem apresentar um ano de duração como mínimo legal universal. Uma política persistente exige particular cuidado com reversão e dependências; a alteração no servidor não garante que todos os clientes deixem imediatamente de aplicar um estado anterior.
Verifique ainda que páginas e integrações não carregam conteúdo sensível por percursos não protegidos. Um redirecionamento inicial para HTTPS não cobre automaticamente todos os recursos e chamadas usados pela aplicação.
Exemplo preenchido: implantação num portal e numa API
A empresa do exemplo identifica um portal web, uma API para parceiros e um serviço interno de administração. Decide configurar o portal com preferência por TLS 1.3 e manter apenas a compatibilidade necessária, fundamentada nos clientes suportados. Na API, um parceiro ainda utiliza uma biblioteca antiga; a equipa estabelece uma migração delimitada e verifica as opções efetivamente negociadas.
| Componente | Decisão | Evidência de aceitação |
|---|---|---|
| Portal | Configuração atual e versões antigas retiradas | Clientes suportados ligam; versões retiradas são recusadas |
| Certificado público | Renovação automatizada com alerta independente | Novo certificado observado em todos os pontos |
| Origem | Acesso restrito ao percurso previsto | Pedido direto não autorizado recusado |
| API de parceiro | Compatibilidade identificada e plano de atualização | Registo do cliente, versão e responsável pela migração |
| Administração | Percurso restrito e identidade do servidor validada | Acesso autorizado funciona sem ignorar certificado |
| Recuperação | Procedimento para falha de renovação | Substituto consegue executar os passos autorizados |
Os valores técnicos específicos ficam na configuração versionada da plataforma. A tabela conserva as decisões e os critérios, permitindo verificar se a execução corresponde ao que foi aprovado. Uma classificação externa favorável pode complementar esta evidência, mas não cobre necessariamente a API privada ou o segmento até à origem.
Manter observação e resposta a comprometimento
Inclua alterações de configuração e falhas relevantes no plano de eventos de segurança. Monitorize expiração, erro de renovação e desvios de versão, limitando a recolha ao que ajuda a detetar e resolver problemas. Os alertas precisam de destinatário e substituto.
Se uma chave privada for comprometida, trate substituição e revogação conforme o caso e investigue o alcance. Renovar o certificado sem resolver a exposição da chave pode repetir o problema. O plano de recuperação de TI deve indicar como restaurar o serviço com material criptográfico seguro e como confirmar o estado final.
O controlo fica concluído quando a organização consegue mostrar o percurso protegido, a identidade validada, a renovação funcional e a resposta a falhas. Esta evidência deve ser mantida ao longo das mudanças de infraestrutura e de clientes, não apenas no dia em que o certificado foi instalado.
Referências técnicas verificadas em 8 de setembro de 2026.