Cifragem e gestão de chaves: verificar a cadeia de proteção

A cifragem protege a informação sob determinados pressupostos. Uma implementação útil explica que dados são protegidos, contra que tipo de acesso e como as chaves se mantêm controladas ao longo de todo o seu ciclo de vida. Uma definição «cifragem ativada» responde apenas a uma pequena parte dessa questão.

Para um CTO, a tarefa de engenharia consiste em verificar a cadeia de proteção: onde nasce o texto em claro, por onde circula, onde é guardado o texto cifrado, quem pode pedir a decifragem e o que acontece em caso de falha ou de recuperação. Essa cadeia inclui aplicações, identidades, serviços cloud, administradores, cópias de segurança e procedimentos operacionais.

As recomendações práticas que se seguem oferecem uma forma de conceber e rever essa cadeia. Comece por um repositório de dados sensíveis e, depois, alargue o mesmo método aos sistemas dependentes e às cópias secundárias.

Defina o objetivo de proteção antes de escolher a tecnologia

Comece por uma declaração de ameaça, não por um algoritmo. «Proteger os registos de clientes» é demasiado vago para orientar a implementação. «Impedir que alguém na posse de uma cópia de segurança roubada leia os registos de clientes sem chaves controladas separadamente» identifica um ativo, uma capacidade do atacante e um limite de proteção.

Ameaças diferentes exigem controlos diferentes. A cifragem do disco pode proteger um portátil roubado e desligado, mas um utilizador autenticado ou um processo malicioso pode continuar a ler ficheiros enquanto o disco está desbloqueado. A cifragem da base de dados pode proteger os suportes de armazenamento e, ainda assim, permitir que as consultas à base de dados devolvam texto em claro. A cifragem na camada aplicacional pode restringir o que os administradores da base de dados veem, mas pode não proteger contra uma aplicação comprometida com permissão para decifrar.

Utilize um breve inventário de fluxos de dados para tornar estas distinções explícitas. Inclua registos de produção, documentos carregados, caches, filas, extrações para análise, logs, ficheiros temporários, snapshots e cópias de segurança. A descoberta de dados deve identificar as cópias que escapam à arquitetura de armazenamento principal, e não apenas os sistemas que constam do diagrama de arquitetura.

Para cada fluxo importante, registe:

• A categoria de dados e as suas necessidades de confidencialidade.
• A origem, o destino, os serviços intermédios e os limites onde existe texto em claro.
• O atacante ou a função não autorizada que a cifragem pretende limitar.
• A identidade autorizada a decifrar e a razão pela qual precisa dessa permissão.
• Os requisitos de disponibilidade, retenção e recuperação.
• Um responsável pela implementação e um revisor responsável pelas evidências.

Uma abordagem de modelação de ameaças ajuda a testar se o limite escolhido corresponde à ameaça. Se um atacante conseguir assumir a identidade da aplicação, a cifragem transparente do armazenamento, por si só, não impedirá o acesso através dessa aplicação.

O resultado é um mapa de proteção: um diagrama de fluxos de dados acompanhado de pressupostos e exceções explícitos. Este passa a ser a referência para as verificações de configuração, os testes de autorização e os exercícios de recuperação.

Perceba o que os blocos criptográficos fornecem realmente

A cifragem transforma texto em claro em texto cifrado utilizando um algoritmo criptográfico e uma chave. A sua confidencialidade depende da construção, da implementação, do sigilo da chave e do ambiente operacional. Um algoritmo forte não compensa uma chave guardada num repositório de código nem um endpoint aplicacional que devolve os registos de outro cliente.

A criptografia simétrica e a assimétrica têm funções diferentes

A cifragem simétrica utiliza uma chave secreta partilhada para cifrar e decifrar. É habitualmente utilizada para grandes volumes de dados por ser eficiente. O AES suporta chaves de 128, 192 e 256 bits, mas a indicação do tamanho da chave, por si só, não descreve uma implementação segura: o modo, o tratamento do nonce, a autenticação e o comportamento da biblioteca também contam.

A criptografia assimétrica utiliza chaves públicas e privadas relacionadas. Consoante o algoritmo e o protocolo, suporta cifragem, assinaturas ou acordo de chaves. O RSA e as construções de curvas elípticas têm capacidades e parâmetros diferentes; não são designações intermutáveis. A criptografia assimétrica não é intrinsecamente «mais segura» do que a cifragem simétrica.

Os sistemas modernos combinam-nas muitas vezes. Um protocolo de transporte seguro pode autenticar um interlocutor e estabelecer segredos partilhados e, em seguida, utilizar cifragem simétrica para proteger o tráfego. Os ficheiros volumosos são normalmente cifrados com chaves de dados simétricas, em vez de se processar diretamente o ficheiro inteiro com um algoritmo assimétrico.

Confidencialidade não é o mesmo que integridade ou autenticidade

A cifragem autenticada, como o AES-GCM corretamente utilizado, protege a confidencialidade e deteta alterações não autorizadas ao texto cifrado protegido e aos dados associados. A reutilização de um nonce com a mesma chave pode comprometer essa proteção. Prefira bibliotecas mantidas e formatos bem suportados que tratem estes requisitos com segurança; não invente uma cifra, um modo ou um protocolo de troca de chaves.

O hashing produz um resumo e não um texto cifrado recuperável. Um hash comum não prova quem criou uma mensagem. O armazenamento de palavras-passe exige funções de hashing próprias para palavras-passe, e não cifragem reversível nem apenas um resumo rápido de uso geral.

Um código de autenticação de mensagens utiliza um segredo para verificar a integridade e a autenticidade entre as partes que partilham esse segredo. As assinaturas digitais utilizam uma chave privada de assinatura e uma chave pública de verificação; não tornam confidencial o conteúdo assinado.

Estas distinções são importantes durante a revisão. Pergunte que propriedade é exigida e que mecanismo a fornece, em vez de aceitar «criptografia» como um controlo único e indiferenciado.

Verifique cada camada de armazenamento e todas as cópias secundárias

A cifragem em repouso abrange a informação armazenada, incluindo os dados utilizados ativamente por um serviço em execução. A expressão não se refere apenas a dados arquivados ou inativos.

Camadas diferentes protegem contra vias de acesso diferentes:

Verifique a configuração real dos recursos, e não apenas uma predefinição da conta. Uma predefinição pode aplicar-se apenas ao armazenamento criado de novo. Objetos existentes, volumes importados, réplicas ou snapshots históricos podem seguir definições diferentes.

Nas bases de dados, inspecione os logs de transações, o armazenamento temporário, as réplicas, as exportações e os procedimentos administrativos de dump. No armazenamento de objetos, verifique os carregamentos, as cópias, os destinos de replicação, os objetos com versões e os caminhos de descarga. Nos endpoints, verifique o tratamento das chaves de recuperação e se os suportes amovíveis estão abrangidos.

A cifragem na camada aplicacional merece uma decisão de conceção autónoma. Pode reduzir a exposição aos operadores da base de dados ou restringir as cargas de trabalho que podem decifrar determinados campos. Também pode complicar a indexação, a pesquisa, a análise de dados e os fluxos de suporte. Documente onde os valores decifrados entram na memória, nos logs, nos relatórios de erros ou nas exportações.

Evite tratar a cifragem como substituto da autorização. Uma aplicação pode decifrar corretamente um registo e, ainda assim, divulgá-lo ao tenant errado. Mantenha o isolamento entre tenants, as verificações de acesso e os controlos de acesso privilegiado na mesma revisão.

Verifique o transporte desde o primeiro emissor até ao destinatário final

A cifragem em trânsito protege os dados que circulam entre endpoints. A pergunta útil não é «Utilizamos HTTPS?», mas «Que ligações estão protegidas e que identidades são autenticadas?»

Mapeie as ligações do browser até à edge, da edge até à aplicação, entre serviços, da aplicação até à base de dados, de replicação, de transferência de cópias de segurança, de acesso administrativo e de exportação para terceiros. A terminação TLS num balanceador de carga cria um limite: o salto seguinte exige a sua própria decisão de proteção. Uma rede privada não elimina automaticamente os riscos de interceção ou de movimento lateral.

Como base prática, prefira configurações TLS modernas suportadas e bibliotecas cliente mantidas. O TLS 1.3 é uma predefinição robusta onde é suportado; um TLS 1.2 corretamente configurado pode continuar a ser necessário por razões de compatibilidade. O SSL legado não é uma opção de segurança moderna adequada.

A validação de certificados faz parte da proteção. Verifique a validação do nome do host, os repositórios de confiança, a monitorização da expiração, a renovação dos certificados e a ausência, em produção, de definições que desativem a validação. A cifragem para um endpoint não autenticado pode proteger o tráfego da observação passiva e, ainda assim, enviá-lo à parte errada.

O TLS mútuo pode autenticar ambas as extremidades de uma ligação, mas não substitui a autorização aplicacional. A emissão de certificados, a identidade das cargas de trabalho, a renovação e a revogação tornam-se dependências operacionais que precisam de responsáveis e de testes.

Distinga a cifragem em trânsito da cifragem ponta a ponta. Um serviço que termina o TLS e processa texto em claro não oferece confidencialidade ponta a ponta perante si próprio. As arquiteturas ponta a ponta reservam a decifragem a endpoints designados; introduzem questões próprias sobre o registo de dispositivos, a verificação dos destinatários, o acesso a partir de vários dispositivos e a recuperação.

As evidências devem incluir testes de configuração e de ligação. Teste a rejeição de certificados inválidos e de versões de protocolo proibidas, e não apenas uma ligação cifrada bem-sucedida.

Faça a governação das chaves como ativos com um ciclo de vida

As chaves exigem geração, armazenamento, utilização autorizada, substituição, revogação, retenção e destruição. Cada fase deve ter um responsável e um procedimento definido.

Gere e registe as chaves de forma deliberada

Gere as chaves com recursos criptográficos mantidos e com aleatoriedade adequada. Não derive chaves de cifragem de produção a partir de palavras-passe fáceis de memorizar, identificadores, carimbos temporais ou funções comuns de geração de números aleatórios das aplicações.

Mantenha um inventário de chaves com a finalidade, o responsável, o ambiente, os sistemas protegidos, o algoritmo, o identificador da chave, a data de criação, o estado e as dependências de recuperação. Registe metadados, e não o material secreto das chaves. Distinga chaves de cifragem, chaves de assinatura, chaves privadas TLS e credenciais de API, porque os procedimentos em caso de exposição e de substituição são diferentes.

Separe a produção do desenvolvimento e dos testes. Partilhar uma chave entre ambientes amplia o impacto de um ambiente de menor confiança e torna os registos de utilização mais difíceis de interpretar.

Separe o controlo das chaves do acesso aos dados

Um serviço de gestão de chaves, ou KMS, fornece normalmente operações sobre chaves sujeitas a governação, políticas de acesso, gestão de versões e registos de utilização. Um módulo de segurança de hardware, ou HSM, fornece um limite suportado por hardware para as operações criptográficas e a proteção das chaves. Os serviços podem combinar estas funções, mas os nomes dos produtos não determinam o limite de segurança exato.

Determine se as chaves são exportáveis, que operações ocorrem dentro do limite, quem administra as políticas e como funciona a recuperação. Escolha serviços geridos de chaves ou proteção por hardware em função do risco e dos requisitos operacionais, em vez de tratar o hardware dedicado como universalmente necessário. Os HSM protegem sobretudo as chaves e as operações criptográficas; não são repositórios de uso geral para todos os dados de negócio cifrados.

A cifragem em envelope é um padrão comum. Uma chave de cifragem de dados cifra o conteúdo, e uma chave de cifragem de chaves protege essa chave de dados. A chave de dados cifrada pode acompanhar o texto cifrado. A sua segurança depende de a capacidade de a desembrulhar ser controlada separadamente, e não de esconder cada blob de chave cifrada noutro local.

Limite a decifragem às cargas de trabalho que dela precisam. Sempre que possível, separe a administração das chaves da utilização das chaves e da administração do armazenamento. Verifique se um administrador que atualmente não consegue decifrar pode atribuir a si próprio essa permissão. O acesso de emergência deve ter aprovação explícita, duração limitada e um registo para revisão.

Trate a rotação como um processo de alteração, e não como uma caixa de verificação

Defina os criptoperíodos de acordo com a sensibilidade dos dados, a exposição, as restrições do algoritmo, o volume de utilização e os requisitos aplicáveis. A rotação também é adequada após uma suspeita de comprometimento ou uma alteração material na confiança.

Esclareça o que a «rotação» faz no serviço escolhido. Criar uma nova versão da chave para cifragens futuras pode deixar os dados históricos dependentes de versões mais antigas. Voltar a embrulhar as chaves de dados com uma nova chave de cifragem de chaves é diferente de decifrar e voltar a cifrar os dados subjacentes. Nenhuma destas operações deve ser presumida a partir de uma definição de rotação automática.

Um plano de rotação deve identificar as aplicações afetadas, os identificadores de chave armazenados, as versões históricas, a implementação faseada, a monitorização de falhas, as condições de reversão e a retirada final. Teste leituras com versões mistas e tarefas de longa duração antes de remover o acesso antigo.

Distinga revogação de destruição

A revogação retira a permissão ou desativa a utilização futura da chave. Não apaga o texto em claro já obtido, não invalida todas as chaves de dados em cache nem faz desaparecer um segredo exportado.

A destruição pode tornar irrecuperável o texto cifrado retido, mas apenas se forem tratadas todas as cópias utilizáveis e todas as vias de recuperação. Considere réplicas, custódia de chaves, material exportado, cópias de segurança e dependências de chaves partilhadas. Se registos sem relação entre si partilharem uma chave, destruí-la pode também destruir o acesso a dados que têm de continuar disponíveis.

Mantenha a conceção da retenção e da eliminação interligadas. A retenção indefinida das chaves pode comprometer um objetivo de eliminação; a destruição prematura pode causar um incidente de disponibilidade.

Avalie os modelos de chaves na cloud pelo seu limite de controlo real

A cifragem na cloud pode reduzir o trabalho de implementação, mas as predefinições do fornecedor não determinam o seu modelo de ameaças. Avalie em conjunto o serviço, a política de chaves, o acesso administrativo, a região, o modelo de recuperação e as evidências de suporte.

As chaves geridas pelo fornecedor podem adequar-se a alguns riscos com uma carga operacional relativamente reduzida. As chaves geridas pelo cliente podem proporcionar um controlo de políticas, uma titularidade e decisões de ciclo de vida mais explícitos. As chaves mantidas externamente podem criar um limite de confiança diferente, introduzindo também uma dependência da disponibilidade e da conectividade externas.

Termos como bring your own key, bring your own encryption e encryption as a service não são garantias arquiteturais equivalentes. Importar uma chave para um serviço do fornecedor não significa necessariamente que o fornecedor nunca possa decifrar. Implementar cifragem do lado do cliente altera o limite do texto em claro, mas pode complicar as funcionalidades da aplicação e a recuperação.

Pergunte a um potencial fornecedor:

• Conseguimos identificar a chave utilizada em cada recurso de armazenamento e cópia de segurança relevante?
• Quem pode alterar as políticas de chaves e como são registadas essas alterações?
• O que acontece quando uma chave é desativada ou o serviço de chaves está indisponível?
• Como é que a exportação, a replicação, a migração e o encerramento da conta afetam a proteção?
• Que eventos de utilização estão disponíveis e que atividade fica fora da sua visibilidade?

Avalie o desempenho com cargas de trabalho representativas: débito, latência, quotas do serviço de chaves, comportamento da cache e modos de falha. Um serviço que funciona numa pequena demonstração pode falhar durante uma restauração em massa. A localização dos dados e a titularidade das chaves pelo cliente são contributos úteis para a conceção, não prova de soberania nem de conformidade regulatória.

Selecione uma solução através de um ensaio operacional

Compare as candidatas com o mapa de proteção, e não com uma lista de nomes de algoritmos. Inclua a manutenção das bibliotecas, as plataformas suportadas, a separação administrativa, a disponibilidade de evidências, as opções de migração e a capacidade da equipa para operar o serviço. Se um contrato exigir um módulo criptográfico validado, determine o módulo, a versão, o ambiente operacional e o âmbito da validação relevantes; a indicação AES, por si só, não satisfaz esse requisito.

Um ensaio prático deve cifrar dados representativos, executar leituras normais, fazer a rotação de uma chave, restaurar uma cópia mais antiga e simular a indisponibilidade do serviço de chaves. Inclua importações e exportações em massa, porque o seu comportamento pode diferir dos pedidos aplicacionais habituais. Meça o efeito na latência e nos objetivos de recuperação da própria aplicação, em vez de aceitar uma alegação genérica de desempenho.

Registe uma decisão de aceitação explícita: que ameaças são tratadas, que dependências são introduzidas, o que fica fora do âmbito e quem é responsável por esses riscos residuais. Teste também a portabilidade. O texto cifrado exportado tem pouco valor operacional se o seu formato, as chaves embrulhadas ou os metadados necessários não puderem ser interpretados depois de terminada a relação com o serviço.

Conceba a recuperação a par da confidencialidade

Para uma cópia de segurança, assegure três coisas: os dados estão cifrados, o pessoal de recuperação autorizado consegue obter as operações de chave necessárias e a restauração é bem-sucedida.

Não coloque a única via de recuperação dentro do mesmo limite de falha da produção. Um bloqueio de conta, uma perturbação regional ou um erro administrativo podem afetar tanto a cópia de segurança como as respetivas chaves. Os mecanismos de recuperação separados devem continuar rigorosamente controlados; torná-los independentes não os deve tornar amplamente acessíveis.

Documente as versões de chave necessárias para cada geração de cópias de segurança, as identidades exigidas, os passos de aprovação, as dependências do fornecedor e as restrições aplicáveis aos dados restaurados. A restauração num ambiente de testes não deve expor silenciosamente informação de produção aos programadores.

Faça exercícios de recuperação num ambiente isolado. Registe se foi possível localizar a cópia de segurança, se as verificações de integridade foram aprovadas, se as chaves necessárias continuaram utilizáveis, se os dados da aplicação eram legíveis e se o tempo de recuperação alcançado cumpriu o objetivo da organização. Quaisquer valores de tempo dizem respeito ao exercício real, e não a um benefício presumido da cifragem.

Inclua a falha do serviço de chaves nos testes de resiliência. Decida se uma carga de trabalho deve falhar de forma fechada, voltar a tentar ou utilizar uma chave em cache aprovada. A cache pode melhorar a disponibilidade, mas prolonga o período durante o qual um processo consegue decifrar depois de o acesso central ter sido retirado. Documente esse compromisso de forma explícita.

Prepare-se para uma suspeita de comprometimento de chaves

A resposta depende do que foi exposto. Uma credencial aplicacional divulgada com permissão para chamar um KMS é diferente de uma chave de cifragem exportada: remover a credencial pode impedir o acesso futuro ao serviço, enquanto um atacante na posse da chave e do texto cifrado pode decifrar de forma independente. Uma chave de assinatura comprometida cria um problema diferente, que envolve a confiança nas assinaturas e não apenas a confidencialidade.

Prepare um runbook que identifique o decisor, os identificadores das chaves afetadas, os sistemas dependentes, as opções de contenção e as evidências a preservar. Investigue alterações de políticas, operações de chave invulgares, descargas de dados, acessos aplicacionais e a possível janela de exposição. A ausência de eventos nos logs não prova que não tenha ocorrido decifragem, sobretudo quando as chaves podem ser exportadas ou mantidas em cache.

A contenção pode passar por desativar uma identidade, restringir uma política, isolar uma carga de trabalho ou desativar uma chave. Avalie as consequências para a disponibilidade antes de uma ação irreversível. Não destrua a única chave de recuperação como medida de contenção improvisada.

Após a contenção, determine que dados precisam de ser migrados para chaves não comprometidas. Fazer a rotação de uma chave de embrulho não é suficiente se o atacante tiver obtido as chaves de dados subjacentes. Voltar a cifrar os dados retidos pode proteger as cópias futuras, mas não consegue recuperar texto cifrado e chaves já roubados em conjunto. Do mesmo modo, substituir uma identidade aplicacional comprometida sem corrigir a sua falha de autorização deixa aberta a via de divulgação original.

Conserve a cronologia do incidente, a avaliação dos dados afetados, os registos de substituição e validação e as incertezas que subsistem. Quando estejam envolvidos dados pessoais, avalie separadamente os deveres de notificação; «a base de dados estava cifrada» não responde à questão de saber se o atacante conseguiu obter texto em claro ou chaves utilizáveis.

Construa evidências que testem a cadeia

Uma política descreve o comportamento pretendido. As evidências devem demonstrar que a implementação a cumpre e que as vias de falha importantes se comportam como esperado.

Utilize em conjunto exportações de configuração, revisões de políticas, testes de acesso, logs de utilização de chaves, verificações de implementação e registos de recuperação. As capturas de ecrã podem apoiar uma revisão, mas raramente explicam, por si só, o âmbito, o comportamento histórico ou os desvios.

Interprete a cobertura dos logs com cuidado. Com a cifragem em envelope e chaves de dados em cache, uma operação do serviço de chaves pode permitir várias decifragens locais posteriores. Um log do KMS não é, por isso, necessariamente um registo completo de todos os acessos ao texto em claro. Combine-o com registos de autorização aplicacional e de acesso aos dados, quando adequado.

Retire os segredos dos dossiês de evidências. Nunca carregue chaves em bruto, frases de recuperação, credenciais ativas nem registos em texto em claro desnecessários. Preserve o identificador do recurso, a data e hora, o âmbito, o revisor, o resultado do teste e a configuração relevante, sem criar uma nova exposição.

As exceções devem indicar o sistema afetado, a razão, os controlos compensatórios, o responsável, a data de expiração e a tarefa de remediação. Uma exceção temporária para um transporte legado precisa de uma decisão e de um plano de saída, e não de uma nota permanente numa folha de cálculo.

Como recomendação prática, repita verificações direcionadas após alterações ao armazenamento, às identidades das cargas de trabalho, às políticas de chaves, aos certificados ou aos destinos das cópias de segurança. As revisões agendadas continuam a ser úteis, mas uma implementação pode alterar o limite de proteção antes da próxima revisão de calendário. As verificações automáticas devem gerar constatações acionáveis com o contexto do recurso e um responsável, enquanto os revisores humanos avaliam as exceções e as alterações ao modelo de ameaças.

Exemplo prático: rastrear um serviço de documentos de clientes

Suponha um serviço SaaS ilustrativo que guarda documentos confidenciais de clientes em armazenamento de objetos. A sua aplicação obtém documentos para utilizadores autenticados, e cópias de segurança diárias suportam um objetivo de recuperação definido pelo negócio. As ameaças em análise são cópias de armazenamento roubadas, acessos administrativos não autorizados e divulgação entre tenants.

A equipa mapeia o TLS do browser até à edge, o TLS da edge até à aplicação, as ligações da aplicação ao armazenamento, o bucket de produção e um destino separado para as cópias de segurança. Descobre que uma tarefa de exportação para resolução de problemas grava ficheiros decifrados numa pasta de suporte. Essa pasta passa imediatamente a fazer parte do âmbito; a definição de cifragem do bucket de produção não a abrange.

Na conceção inicial, a cifragem do armazenamento com uma chave gerida pelo cliente protege os objetos de produção. A identidade da aplicação pode obter objetos autorizados e invocar as operações de chave necessárias. A função de implementação pode criar recursos, mas não tem permissão de decifragem no dia a dia. A administração das políticas de chaves segue um circuito de aprovação separado.

A equipa reconhece o limite que subsiste: um comprometimento da aplicação continuaria a permitir obter texto em claro. Considera a cifragem na camada aplicacional para uma categoria de documentos particularmente sensível e avalia depois os requisitos de pesquisa, o acesso do suporte e a complexidade da recuperação, antes de decidir se o limite adicional se justifica.

A verificação produz resultados concretos:

• Uma identidade de serviço não autorizada não consegue obter nem decifrar um documento.
• Um utilizador autenticado de outro tenant é bloqueado pela aplicação.
• Os certificados inválidos a montante são rejeitados em vez de ignorados.
• Uma cópia de segurança mais antiga é restaurada com êxito com a versão histórica da chave de que necessita.
• Uma alteração faseada da chave permite ler tanto os documentos existentes como os novos carregamentos.
• A tarefa de exportação do suporte é alterada para utilizar um destino cifrado aprovado, com acesso controlado e retenção definida.

O revisor conserva o mapa de fluxos de dados, as exportações de configuração, as políticas de identidade, os resultados anonimizados dos testes negativos, o registo da rotação e o relatório de restauração. Um exercício de desativação da chave num ambiente que não é de produção confirma que o serviço devolve um erro controlado, em vez de expor dados ou descartar silenciosamente escritas.

Este exemplo não demonstra proteção contra todos os ataques. Demonstra que ameaças a conceção trata, que identidade continua a ser de confiança e que evidências sustentam essas conclusões.

Ligue os requisitos legais e as alterações futuras à conceção

As decisões de cifragem devem refletir os requisitos legais, contratuais e dos referenciais, sem os transformar em afirmações genéricas. O artigo 32.º do RGPD segue uma abordagem baseada no risco e inclui a cifragem entre as medidas adequadas; não impõe uma obrigação universal de cifragem a todas as atividades de tratamento. A cifragem também não elimina os deveres relativos à licitude do tratamento, ao acesso, à conservação ou à avaliação de incidentes.

Num SGSI ISO 27001 com âmbito definido, documente o tratamento do risco, os controlos aplicáveis, os responsáveis e as evidências, em vez de presumir que uma base de dados cifrada satisfaz todo o sistema de gestão. Quando a NIS2 se aplique através da lei nacional, as suas medidas do artigo 21.º incluem políticas e procedimentos relativos à criptografia e, se for caso disso, à cifragem. Confirme separadamente a aplicabilidade e os requisitos nacionais.

Planeie a mudança criptográfica como uma dependência de engenharia. Inventarie algoritmos, certificados, bibliotecas, protocolos e formatos incorporados, para que os mecanismos obsoletos possam ser substituídos. Para dados confidenciais de longa duração, avalie a relevância de futuras ameaças criptanalíticas e quânticas. As questões da migração pós-quântica diferem entre o estabelecimento de chaves, as assinaturas e a cifragem simétrica; evite uma substituição integral não testada apresentada como solução universal.

Torne concreta a próxima revisão

A Secani pode ligar os sistemas-alvo, os requisitos de controlo, as descrições de implementação, as evidências, os responsáveis e as decisões de revisão deste trabalho. Associe o mapa de proteção e os registos de testes anonimizados aos sistemas e controlos relevantes, transforme as questões em aberto sobre o acesso às chaves ou a recuperação em tarefas e conserve a razão pela qual cada opção criptográfica foi aprovada. Reveja as sugestões assistidas por IA face às respetivas fontes e mantenha a aprovação humana explícita.

Comece por um repositório de dados sensíveis e rastreie em conjunto o acesso aos dados, o acesso às chaves e a recuperação. Selecione um teste de autorização negativo e um exercício de restauração, atribua responsáveis e registe os resultados antes de alargar o âmbito. O nosso guia de segurança na cloud fornece o contexto de configuração envolvente.