0
0
Por um bom motivo, as empresas confiam em criptografia , blockchain, acesso de confiança zero, estratégias distribuídas ou multipartidárias e outras tecnologias essenciais. Ao mesmo tempo, as empresas estão efetivamente escondendo as chaves que podem minar todas essas proteções sob um capacho (figurativo).
A criptografia forte é de pouca utilidade quando um invasor ou invasor pode obter o controle das chaves privadas que a protegem. Essa vulnerabilidade existe quando as chaves precisam ser executadas em servidores para processamento. A criptografia pode proteger bits e bytes em armazenamento ou trânsito, mas quando eles precisam ser executados em uma CPU, eles estão “limpos” para realizar a computação necessária. Como resultado, eles são acessíveis a invasores, invasores e terceiros desonestos, como consultores, parceiros ou até mesmo fornecedores de software ou componentes de hardware usados na infraestrutura do data center.
Essa é a natureza da criptografia. Ele fornece forte segurança para armazenamento e trânsito, mas quando a execução é eventualmente necessária – e sempre é necessária em algum momento para que dados, códigos ou ativos digitais sejam úteis ou para permitir uma transação – o processo enfrenta seu calcanhar de Aquiles.
As chaves privadas requerem execução, usando uma CPU, para sua criação inicial, a criptografia ou descriptografia necessária para a troca de chaves, o processo de assinaturas digitais e alguns aspectos do gerenciamento de chaves, como lidar com chaves públicas expiradas. Esse mesmo princípio – a necessidade de execução em uma CPU – se aplica a determinadas tarefas de blockchain e computação multipartidária (MPC). Ainda mais geralmente, apenas a execução de código ou dados criptografados do aplicativo os expõe, pois as CPUs exigem que os dados e o código estejam limpos.
Os CIOs precisam fazer perguntas às suas equipes para avaliar essa possível exposição e entender o risco, além de estabelecer planos para lidar com isso.
Felizmente, avanços recentes conseguiram eliminar essa lacuna de criptografia e manter a proteção total para chaves privadas. Os principais fornecedores de CPU adicionaram hardware de segurança em seus microprocessadores avançados que impedem qualquer acesso não autorizado a códigos ou dados durante a execução ou posteriormente no que resta nos caches de memória. Os chips estão agora na maioria dos servidores, principalmente naqueles usados por fornecedores de nuvem pública, envolvendo uma tecnologia geralmente conhecida como computação confidencial.
Essa tecnologia de “enclave seguro” fecha a lacuna de criptografia e protege as chaves privadas, mas exigiu alterações no código e nos processos de TI que podem envolver uma quantidade significativa de trabalho técnico. É específico para um determinado provedor de nuvem (o que significa que deve ser alterado para uso em outras nuvens) e complica futuras alterações no código ou nos processos operacionais. Felizmente, a nova tecnologia “intermediária” elimina a necessidade de tais modificações e potencialmente oferece portabilidade multinuvem com escala ilimitada. Em outras palavras, as desvantagens técnicas foram praticamente eliminadas.
Os CIOs precisam perguntar a seus líderes de gerenciamento ou equipes como as chaves privadas são protegidas e qual lacuna de exposição eles podem enfrentar durante o processamento. O mesmo vale para a execução de dados e códigos que, de outra forma, são criptografados em repouso e em movimento. Qual lacuna ou exposição os dados ou código podem estar enfrentando?
As empresas que usam código de aplicativo proprietário com uma chave secreta precisam se perguntar como a chave secreta é protegida e que tipo de risco ela pode enfrentar. Se os aplicativos envolverem o uso de IA ou aprendizado de máquina, os algoritmos desenvolvidos provavelmente serão extremamente valiosos e sensíveis.
Como eles são protegidos durante o tempo de execução? Mesmo o teste de algoritmos, geralmente feito usando MPC para utilizar dados reais (talvez de clientes ou parceiros), pode envolver a exposição de dados, código ou ambos. Que proteções estão agora em vigor para protegê-los? Blockchain também envolve essa exposição de execução – como isso está sendo gerenciado?
A lacuna de execução não se limita à nuvem pública. A nuvem privada e os datacenters locais enfrentam os mesmos problemas. Os CIOs precisam se perguntar se a lacuna está sendo mitigada e como. Talvez seja contra-intuitivo, mas a nuvem pública, com o uso de computação confidencial, pode ser o local mais seguro para a execução de código, algoritmos e dados. Se uma organização não estiver usando nuvem pública no momento – devido a preocupações com a possível exposição de dados regulamentados ou proprietários – talvez seja hora de reexaminar seu uso.
Evitar a nuvem pública geralmente ocorre devido a problemas de controle e acesso. Com nuvens privadas e data centers locais, as organizações geralmente sabem e podem controlar quem tem acesso a quê por meio do uso de combinações de segurança física, de rede e de aplicativos, registro ou monitoramento e várias formas de acesso de confiança zero. A preocupação com a nuvem pública tem sido como impedir o acesso de pessoas não autorizadas, terceiros, vários componentes de hardware ou software de terceiros e até mesmo possíveis invasores. Agora, com a computação confidencial, essas preocupações podem ser totalmente eliminadas.
Os CIOs devem desafiar as noções populares de criptografia totalmente segura – e até mesmo a garantia de blockchain e MPC. Com tanta coisa dependendo das chaves privadas, os líderes devem garantir que elas sejam protegidas usando as melhores práticas e as melhores tecnologias disponíveis.
FONTE: HELPNET SECURITY