Texto escrito por autores da Cloud Security Alliance.

À medida que nos aproximamos de meados de 2023, achamos que é um momento apropriado para refletir sobre os riscos e ameaças de segurança na nuvem que vimos até agora este ano.

Após uma análise cuidadosa dos resultados agregados da verificação de janeiro a maio deste ano, o Orca Research Pod identificou os cinco principais riscos de segurança em nuvem mais comuns, porém graves, que são onipresentes em muitos ambientes de nuvem. Além de revelar os riscos e apresentar os dados que encontramos, também fornecemos informações básicas sobre cada risco, bem como as principais recomendações sobre como evitar que esses riscos ocorram. Esperamos que esta pesquisa ajude as organizações a entender quais áreas podem fornecer a maior melhoria na postura de segurança na nuvem para que saibam onde concentrar seus esforços.

Sumário executivo

• O Orca Research Pod descobriu que os cinco riscos de segurança na nuvem mais comuns e graves de 2023 até agora são, em ordem de gravidade: (1) serviços da Web expostos sem correção, (2) informações confidenciais em repositórios Git, (3) informações confidenciais não seguras Chaves da AWS, (4) funções IAM superprivilegiadas e (5) funções AWS Lambda superprivilegiadas. Cada um desses riscos foi encontrado generalizado em organizações de todos os tamanhos, mesmo naquelas com alto nível de maturidade em termos de segurança na nuvem.

• Mesmo que esses não sejam os problemas mais recentes e mais comentados, eles fazem parte da segurança cibernética 101 (como a necessidade de corrigir serviços da Web vulneráveis e aplicar políticas que aderem ao Princípio do Privilégio Mínimo (PoLP)) e destacam ainda mais o que é comumente dito no setor: devemos primeiro nos concentrar nos fundamentos da segurança para fazer a maior melhoria nas posturas de segurança na nuvem.

• Também é importante reconhecer que muitas equipes de segurança estão enfrentando um grande acúmulo de alertas de segurança abertos enquanto estão com falta de pessoal. Isso está prejudicando sua capacidade de lidar com os riscos em tempo hábil, e é por isso que a priorização de alertas, juntamente com a correção guiada e automatizada, são essenciais para superar esses desafios.

• O Orca Research Pod compilou esta pesquisa analisando dados de carga de trabalho, configuração e identidade capturados de bilhões de ativos de nuvem de produção do mundo real na Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Kubernetes e funções sem servidor, verificados a partir de 1º de janeiro – 1º de maio de 2023.

Resultados da pesquisa

Abaixo estão listados os cinco riscos de segurança na nuvem mais comuns e críticos de 2023 até agora, em ordem de importância:

Descoberta nº 1: a aplicação de patches está atrasada em serviços expostos da Web

O Orca descobriu que 36% das organizações têm um serviço da Web sem patches em seu ambiente de nuvem que está exposto à Internet e, portanto, facilmente acessível por invasores. Serviços não corrigidos, com vulnerabilidades e bugs conhecidos, podem ser um dos principais vetores de ataque em ambientes de nuvem. Na verdade, a maioria dos caminhos de ataque que a equipe de pesquisa da Orca Security detecta e analisa começa com a exploração de uma vulnerabilidade conhecida. As apostas são consideravelmente maiores se o serviço for voltado para a web, ou seja, acessível de fora da rede.

Atores mal-intencionados podem explorar com relativa facilidade uma vulnerabilidade não corrigida para causar tempo de inatividade do serviço, possível execução remota de código ou mais. Em alguns casos, o acesso remoto não autorizado também pode ser uma possibilidade.

Todo software tem o potencial de ter vulnerabilidades e bugs, incluindo serviços da web. Os fornecedores de software são responsáveis por descobri-los e corrigi-los antes que sejam encontrados e explorados por agentes mal-intencionados. Os consumidores de software, por sua vez, são responsáveis por aplicar imediatamente essas correções, lançadas por meio de atualizações ou patches.

Descoberta nº 2: informações confidenciais geralmente armazenadas no repositório Git

O Orca descobriu que 50% das organizações têm pelo menos um repositório Git contendo dados confidenciais. Informações confidenciais, como senhas de banco de dados, chaves de API, chaves de criptografia, sais de hash e segredos, podem ser enviadas por engano para um repositório Git. Além disso ser contraditório com as melhores práticas de segurança, se eles fizerem parte do código-fonte do seu aplicativo, os invasores podem potencialmente extraí-los e comprometer seus sistemas. Quaisquer dados confidenciais enviados devem ser detectados e removidos imediatamente, tanto do repositório quanto do histórico.

Descoberta nº 3: Chaves da AWS confidenciais geralmente armazenadas em sistemas de arquivos

49% das organizações têm chaves AWS confidenciais armazenadas em um sistema de arquivos dentro de uma máquina virtual. Pense nas chaves da AWS como chaves literais para o seu sistema. Qualquer pessoa com sua chave tem acesso a todos os seus recursos e pode executar qualquer operação que você puder, como iniciar instâncias EC2, excluir objetos S3, etc. É por isso que você deve sempre armazenar suas chaves em um local seguro e nunca compartilhá-las com ninguém , especialmente não partes externas.

Por padrão, as chaves confidenciais da AWS são armazenadas no sistema de arquivos. Se essas chaves forem obtidas por um ator mal-intencionado, ele poderá usá-las para acessar recursos confidenciais e realizar operações não autorizadas.

As chaves da AWS fornecem acesso indefinido, a menos que sejam revogadas manualmente. No entanto, para muitos casos de uso, você não precisa de acesso de longo prazo sem data de validade. É por isso que a AWS recomenda o uso de credenciais temporárias (geradas usando o Security Token Service) em vez de chaves da AWS. Além do ID da chave de acesso e da chave de acesso secreta, as credenciais temporárias também possuem um token de segurança que especifica a data de expiração das credenciais.

Descoberta nº 4: muitos usuários administradores por organização

O Orca descobriu que 33% das organizações concedem privilégios administrativos completos para mais de 10% das funções IAM em seu ambiente de nuvem, com 10% das organizações concedendo permissões administrativas a mais de 40% de suas funções. Isso é demais.

Uma função do IAM em uma conta da AWS é uma identidade com permissões específicas que determinam quais ações a identidade pode executar e quais recursos ela pode acessar. Ao contrário dos usuários do IAM, as funções do IAM não estão vinculadas a uma única pessoa e podem ser assumidas por qualquer pessoa autorizada a fazê-lo.

Não há credenciais de segurança de longo prazo ou indefinidas associadas a uma função. Em vez disso, credenciais de curto prazo são emitidas sempre que um usuário assume uma função. As funções fornecem uma ótima maneira de delegar acesso a usuários ou aplicativos que geralmente não precisam acessar seus recursos.

Os privilégios IAM são um exemplo de como as vezes a segurança é menos conveniente, mas ainda é a escolha correta. Embora seja muito mais rápido e fácil conceder muitos privilégios aos usuários – em vez de restringir permissões e criar a necessidade de mais supervisão – é um caso de ganho de curto prazo e (potencialmente) danos maiores a longo prazo.

Como regra de ouro, é melhor não, exceto em raras circunstâncias, definir uma função IAM com privilégios administrativos totais, pois qualquer pessoa que assuma a função poderá realizar qualquer ação em qualquer recurso da conta. Isso viola o Princípio do Privilégio Mínimo (PoLP), aumenta muito a superfície de ataque e aumenta o risco de controle total da conta.

Descoberta nº 5: a maioria não usa papéis separados para funções Lambda

A Orca descobriu que 70% das organizações têm pelo menos duas funções do Lambda que compartilham a mesma função do IAM. Além disso, quase 86% de todas as funções do Lambda estão compartilhando sua função IAM.

Quando se trata do AWS Lambda, a AWS recomenda a criação de papéis separados para cada função, a fim de promover o Princípio do Menor Privilégio. “Ao usar uma função IAM dedicada por função, você pode controlar as permissões de forma mais intencional. Cada função do Lambda deve ter um relacionamento 1:1 com uma função do IAM. Mesmo que inicialmente algumas funções tenham a mesma política, sempre separe as funções do IAM para garantir políticas com menos privilégios.”

Isso protege os dados contra acesso não autorizado e permite que você cumpra vários padrões de segurança e conformidade.

Principais recomendações

Como mencionado, esses riscos não são novos. O fato de serem tão difundidos, portanto, é evitável. Seguindo as recomendações abaixo, as organizações podem fortalecer sua postura de risco de segurança na nuvem e minimizar ao máximo a ocorrência desses riscos:

1. Cumpra com o princípio do privilégio mínimo – garanta que os privilégios de administrador sejam concedidos apenas àqueles que realmente precisam deles e que os usuários comuns não tenham o poder de aumentar seus próprios privilégios ou criar novas contas. Revise regularmente as políticas do usuário para garantir que os usuários não recebam permissões de que não precisam estritamente. Se os usuários não usarem as permissões em 90 dias, elas devem ser revogadas.

2. Nunca pare de corrigir – Independentemente de quão rigorosos sejam seus controles de segurança, se você não corrigir seu software regularmente, estará correndo sério risco de comprometimento. Isso ocorre porque os cibercriminosos gostam de escanear e visar redes com vulnerabilidades conhecidas e não corrigidas. Sempre que possível, os sistemas com vulnerabilidades conhecidas devem ser corrigidos. Como é impossível corrigir todas as vulnerabilidades, é importante entender quais vulnerabilidades permitem caminhos de ataque perigosos e garantir que elas sejam corrigidas primeiro.

3. Utilize listas de verificação e benchmarks CIS – Para minimizar o erro humano, use listas de verificação ao criar e configurar ativos, direitos e recursos de nuvem. Além disso, recomendamos a implementação de políticas que sigam as melhores práticas de benchmarks CIS conhecidos.

4. Realize varredura contínua na nuvem para identificar riscos – Examine continuamente seus ambientes de nuvem em busca desses e de outros riscos. Você só pode realmente fazer isso de forma eficaz e acompanhar a velocidade com que os ambientes de nuvem mudam adotando uma plataforma de segurança em nuvem que tenha ampla visibilidade em nuvens, contas e cargas de trabalho. Idealmente, ele irá capacitá-lo a entender o contexto completo dos riscos e reconhecer quando problemas aparentemente não relacionados podem criar caminhos de ataque perigosos.

5. Aproveite a priorização para evitar a fadiga de alertas – A priorização de riscos é um requisito fundamental para uma segurança de nuvem eficaz. As ferramentas de segurança geralmente geram muitos alertas. Quando você considera que as equipes de segurança – muitas vezes com falta de pessoal e sobrecarregadas, e trabalhando sob forte pressão – geralmente monitoram várias ferramentas simultaneamente, isso é muito para lidar. Embora nunca seja possível corrigir todos os riscos, é importante que você se concentre naqueles que são mais críticos.

Para saber mais, clique aqui.

Faça uma varredura completa de seus ambientes e seus ativos, incluindo os ambientes em nuvem. Conheça o Pentest Clavis, encontre gaps de segurança e proteja a sua organização contra possíveis ataques cibernéticos.