É provável que as violações da nuvem aumentem em “velocidade e escala” devido à predominância de práticas inadequadas de segurança cibernética em configurações de nuvem que estão criando vulnerabilidades. É o que afirma o relatório “The State of DevSecOps”, da Accurics, que avalia práticas de configuração da nuvem que levam a violações.
O estudo constatou que 93% das implantações em nuvem analisadas continham serviços mal configurados, enquanto 91% das implantações apresentavam ao menos uma exposição de rede, em que um grupo de segurança é deixado em aberto. A Accurics observou que “essas duas práticas sozinhas estiveram no centro de mais de 200 violações que expuseram 30 bilhões de registros nos últimos dois anos”.
O relatório também detectou outras práticas que criaram exposições. Isso incluiu a presença de chaves privadas codificadas em 72% das implantações. Além disso, metade das implantações tinha credenciais desprotegidas armazenadas nos arquivos de configuração do contêiner. O estudo acrescenta que “essas chaves e credenciais podem ser usadas por usuários não autorizados para obter acesso a recursos sensíveis da nuvem”.
Segundo a empresa, ficou demonstrado que quase um terço (31%) das organizações possui recursos não utilizados, com a causa principal sendo que esses recursos são adicionados a uma nuvem privada virtual (VPN) padrão na sua criação, se um escopo não estiver definido. O relatório revela que, embora os serviços de armazenamento em nuvem expostos sejam um tema batido, problemas como chaves codificadas estão se tornando cada vez mais comuns.
Além dos hábitos suspeitos, os pesquisadores também observaram algumas práticas que estão criando exposições. Apesar da disponibilidade de ferramentas populares, como o HashiCorp Vault e o AMS Key Management Service (KMS), chaves privadas codificadas foram encontradas em 72% das implantações.
Especificamente, uma em cada duas implantações tinha credenciais desprotegidas armazenadas nos arquivos de configuração de contêiner, o que é preocupante, pois 84% das organizações estão usando contêineres. Essas chaves e credenciais podem ser usadas por usuários não autorizados para obter acesso a recursos sensíveis da nuvem.
Violações na Capital One, Imperva e CenturyLink
O relatório estuda os principais riscos de infraestrutura de nuvem que afetam as organizações e ilustra como eles contribuíram para três violações recentes — na Capital One, Imperva e na CenturyLink.
Em setembro do ano passado, foi descoberta uma brecha na CenturyLink que expunha 2,8 milhões de registros de clientes, incluindo nome, endereço de e-mail, número de telefone, endereço residencial, número da conta CenturyLink, registros de notificação e registros de conversação. Uma análise da violação revelou que houve uma configuração incorreta da rede em nuvem que expôs o banco de dados MongoDB.
Uma conta não administrativa com diretivas de gerenciamento de identidade e acesso (IAM, na sigla em inglês) excessivamente permissivas possibilitou o acesso ao banco de dados devido à configuração incorreta da rede. Por fim, os dados contidos foram expostos, pois o banco de dados não foi criptografado. O mais preocupante é o fato de a violação ter sido detectada por aproximadamente dez meses após ter ocorrido.
Veja isso
Empresas migram para nuvem e negligenciam redes locais
CISOs e CIOs dizem não ter capacidade de resistir a ataque na nuvem pública
A Imperva sofreu incidente semelhante em agosto do ano passado, quando um instantâneo do banco de dados contendo e-mails, hash de senhas e chaves de API e TLS (segurança da camada de transporte) de alguns clientes foi exposto. Embora a exposição de e-mails e senhas seja preocupante, as chaves API e TLS expostas podem ser aproveitadas pelos invasores para interromper a criptografia e acessar diretamente os aplicativos corporativos.
Uma análise da violação revelou que um ambiente de nuvem de teste foi criado e um recurso de computação foi configurado incorretamente, expondo-o à internet. Essa instância de computação continha uma chave de API codificada que foi descoberta pelos hackers e usada para acessar o banco de dados. As chaves API e TLS não foram divididas em hash (violação de práticas recomendadas), o que acabou colocando os clientes da Imperva em risco. Essa violação também não foi detectada por aproximadamente dez meses.
Pouco antes da invasão à Imperva, uma das maiores violações da nuvem até o momento foi descoberta na Capital One, em julho de 2019. Ela afetou 100 milhões de pessoas nos Estados Unidos e aproximadamente 6 milhões no Canadá. Os dados expostos incluem aproximadamente 140 mil números de seguridade social (SSN), 80 mil números de contas bancárias de consumidores norte-americanos e 1 milhão de números de seguridade social (SIN) para clientes de cartão de crédito canadenses.
Análise do FBI revelou que foi explorada uma vulnerabilidade em um recurso de computação em nuvem que forneceu ao invasor um conjunto de chaves de acesso da AWS associadas a uma função do IAM com permissões excessivas. O invasor conseguiu descobrir e acessar um serviço de armazenamento em nuvem no ambiente que contém os dados não criptografados (violação de política).
Remediação como código
Embora a maioria das organizações concorde com a necessidade de incorporar a segurança na infraestrutura de nuvem nativa ao longo do ciclo de vida do desenvolvimento, ela não pode ter um custo de agilidade. Detecção e correção de riscos formam o yin e o yang da segurança. Para que a agilidade seja mantida, ambos os aspectos devem ser codificados em pipelines de desenvolvimento. Política como código, segurança como código e drift como código permitem a detecção de riscos na velocidade do DevOps. Infelizmente, a correção de riscos continua sendo um processo manual e apenas 6% dos problemas são abordados.
Uma prática emergente conhecida como remediação como código (remediation as code) está permitindo que as organizações resolvam problemas na velocidade do DevOps. Depois que um risco é detectado, o código para corrigir o problema é gerado automaticamente e enviado ao desenvolvedor. Este precisa simplesmente revisar e aceitar a alteração. Os resultados dessa abordagem foram extremamente encorajadores: 80% dos riscos foram abordados. Os 20% restantes dos riscos não puderam ser tratados sem a contribuição dos desenvolvedores, embora a equipe de pesquisa e desenvolvimento esteja progredindo em direção a uma solução. Uma edição futura do relatório aprofundará os resultados da nova abordagem.
O próximo nível de maturidade para remediação como código envolve a aplicação automática de código durante as fases de compilação e implantação para substituir configurações incorretas. Embora existam perigos inerentes à automação, as organizações parecem ter um apetite para implementá-lo para certas configurações incorretas de alto risco. Os exemplos incluem configurações incorretas que criam serviço de armazenamento em nuvem, serviço de banco de dados em nuvem e exposições de rede. Essa abordagem abre o caminho para a infraestrutura nativa de autorrecuperação da nuvem.
