0
0
As empresas estão cada vez mais usando a nuvem para testes de desenvolvimento e teste, para disponibilizar instâncias de desenvolvimento rapidamente para suas equipes de desenvolvimento de aplicativos. Esse processo permite que as organizações assumam um ciclo de lançamento mais rápido, usem DevOps e desfrutem da agilidade e flexibilidade da nuvem. Mas também apresenta maiores riscos de segurança e privacidade quando os desenvolvedores migram dados confidenciais, claramente, para a nuvem.
Um fluxo básico de migração na nuvem para suportar esse modelo de desenvolvimento envolve um banco de dados de origem de dados de produção e um banco de dados de destino que não seja de produção ou de desenvolvimento que os desenvolvedores podem usar para criar e testar seus aplicativos. Às vezes, existem ferramentas disponíveis para ajudá-lo a mover grandes conjuntos de dados para o Amazon Web Services (AWS) ou Azure usando serviços de migração de banco de dados. Inevitavelmente, o uso de clones de dados de produção pode criar uma réplica de informações confidenciais em um banco de dados na nuvem, o que pode violar as políticas de segurança e conformidade ou pode não receber o mesmo nível de segurança que um ambiente de produção normalmente recebe.
O efeito downstream é que uma implantação de não produção sem proteção pode ficar em execução e, como resultado, um invasor ou um scanner da Internet pode descobrir registros de texto não criptografado. Nos últimos anos, houve várias instâncias de ambientes abertos ou de não produção, com seus dados expostos.
Os desafios de segurança dessa nova realidade
Em uma migração para nuvem, desenvolvedores e administradores de banco de dados podem acessar todos os seus dados, sem problemas, mesmo se você estiver usando uma solução de criptografia em repouso ou criptografia de dados de espaço de tabela / transparente para proteger esses dados .PROPAGANDA. CLIQUE PARA OUVIR.
Além disso, várias exposições recentes de dados foram vinculadas a implantações de nuvem não atendidas ou mal configuradas. A violação da Starwood / Marriott do ano passado envolveu cerca de 339 milhões de registros – e pode receber uma multa de US $ 124 milhões sob o Regulamento Geral de Proteção de Dados (GDPR).
A First American Financial Corporation vazou 885 milhões de registros, começando em 2003.
E, mais recentemente, há o exemplo da implantação da AWS da Capital One e de um firewall de aplicativo da Web mal configurado. Nesse cenário, um usuário não autorizado pôde acessar registros de dados confidenciais, colocando em risco 106 milhões de clientes.
A criptografia de dados transparente (TDE) não conseguiu proteger essas empresas ou seus usuários porque nunca foi feita para isso. Ele foi projetado para proteger contra o que chamamos de “modelo de ameaça Tom Cruise” – onde alguém invade um data center e desce do teto (como em Missão Impossível ) para roubar discos que contêm seus dados. A realidade é que os hackers não estão invadindo fisicamente os data centers no mundo de hoje. Eles são hackeados usando credenciais comprometidas e, em seguida, movendo-se lateralmente em seu ambiente. Criptografar os discos físicos ou usar a criptografia de banco de dados em repouso não faz nada para proteger os dados contra esses ataques modernos.
O “modelo de responsabilidade compartilhada” exige que os usuários protejam tudo na nuvem , enquanto o provedor de nuvem garante a segurança da nuvem . Não se pode culpar um provedor de nuvem por buckets abertos ou mal configurados. Essa foi e sempre será de responsabilidade do usuário da nuvem.
Novos ataques exigem novos métodos de defesa
Está claro que as abordagens tradicionais (como criptografar dados em repouso e em movimento) não são mais suficientes para se proteger contra novos métodos de ataques, principalmente quando os desenvolvedores criam e migram para ambientes de teste e desenvolvimento na nuvem.
Por muito tempo, os profissionais de segurança usaram essas tecnologias como um método “marque a caixa” para obter conformidade. Os ataques modernos, no entanto, exigem que repensemos nossos processos para defender o que é mais importante: os dados em si, não os sistemas ou as defesas de perímetro que os cercam.
Estou particularmente encorajado pelo anúncio do MongoDB em junho de 2019 de que ele começará a implementar a “criptografia em nível de campo”, que permite aos usuários ter “campos criptografados no servidor – armazenados na memória, nos logs do sistema, em repouso e em backups – que são renderizados como texto cifrado, tornando-os ilegíveis para qualquer pessoa que não tenha acesso ao cliente ou as chaves necessárias para descriptografar os dados “. Embora isso permita operações limitadas nesses dados criptografados, certamente é um passo na direção certa. Mais empresas em segurança devem reconhecer que a abordagem tradicional de criptografia é inadequada para defender o que é mais importante.
Medidas proativas, não reativas,
Para evitar uma quantidade significativa de violações de dados, que acionam multas regulatórias significativas, por que não cortar esse problema pela raiz? Os reguladores fariam bem em expandir os mandatos para criptografar dados em todo o ambiente de “em repouso” e “em movimento” apenas para incluir também “na memória” e “em uso”. Isso impediria algumas violações de dados – especialmente nos casos descritos acima – manchetes negativas, questões legais e de reputação e multas regulatórias antes que elas ocorram. A criação da criptografia no processo de migração de dados protegeria dados confidenciais o tempo todo, automaticamente, impedindo a exposição inadvertida.
Evitando a abordagem do aprendizado de máquina, os centros de operações de segurança devem aprender a identificar e explorar o melhor de ambas as abordagens, de acordo com Tim Vidas, da Secureworks, e Nash Borges, da Secureworks. Em conjunto, a inteligência humana e da máquina pode ser um multiplicador de forças contra os ciber adversários humanos, dizem eles.Trazido a você por Secureworks
As conseqüências da inação estão crescendo significativamente, pois os reguladores perceberam claramente a importância da privacidade dos dados. Veja a multa de US $ 5 bilhões da Federal Trade Commission contra o Facebook por não proteger os dados de terceiros abusivos (como a Cambridge Analytica). Cinco bilhões de dólares representam cerca de 10% da receita da empresa em 2018 e 20% de seus lucros em 2018 .
O GDPR, que entrou em vigor em meados de 2018, provocou uma onda de novos regulamentos de privacidade de dados nos EUA. A mais importante delas é a Lei de Privacidade do Consumidor da Califórnia, que fornece um poder sem precedentes para os consumidores controlarem a coleta, o uso e a transferência de seus dados. Até 40 outros estados também estão em vários estágios de implementação de regulamentos de privacidade de dados.
Juntando tudo
Como escrevi em uma coluna anterior do Dark Reading , a segurança não deve ser um gargalo e diminuir as funções dos negócios. Quando feito corretamente, a segurança pode realmente capacitar um negócio e criar uma vantagem competitiva sustentável.