0
0
A mudança está em andamento. O setor privado, público e terceiro está em transição de infraestrutura on-premises e datacenter para arquiteturas híbridas utilizando software-as-a-service (SaaS) e infra-estrutura-as-a-service (IaaS) hospedados em uma variedade de plataformas em nuvem. O pivô para os provedores de infraestrutura em nuvem não é surpreendente, dado os benefícios do aumento da escalabilidade e flexibilidade da implantação e de um modelo de preços pay-as-you-go mais atraente em comparação com implantações no local. Como resultado, as empresas estão cada vez mais querendo contratar pessoas com as habilidades para gerenciar e garantir esse novo tipo de infraestrutura.
Quando há uma demanda de habilidades, os salários competitivos seguem e os funcionários em potencial estão procurando se tornar conhecedores de tecnologias em nuvem.
Mesmo antes da pandemia, as ferramentas baseadas em nuvem eram muito populares. A pandemia acelerou ainda mais a adoção dessas ferramentas e serviços, à medida que a força de trabalho global se converteu em funcionários remotos durante a noite. Simplesmente não havia tempo para construir uma infraestrutura no local quando a colaboração fora da prateleira e soluções de trabalho remoto estavam prontamente disponíveis. De acordo com a publicação Statista Cloud (IaaS) Market Share, Amazon Web Services (AWS), Microsoft Azure e Google Cloud Platform (GCP) são os três maiores provedores de serviços em nuvem, tendo capturado mais de 60% do mercado entre eles.
Outra vantagem da nuvem é o conceito de “corrigir uma vez, corrigir para todos”, o que não é possível com implantações de infraestrutura no local. No entanto, a nuvem não é uma panaceia de segurança cibernética, e as violações de dados envolvendo a nuvem não mostram nenhum sinal de abating.
Cloud (in)segurança?
Um exemplo muito conhecido de um problema de segurança na nuvem foi a violação do Capital One em 2019. Um firewall de aplicativo web hospedado em uma instância do Amazon EC2 foi encontrado para sofrer de uma vulnerabilidade SSRF (Server Side Request Forgery), que foi aproveitada por um hacker para acessar o serviço interno de metadados de instância eC2 (IMDS). Os metadados continham credenciais que permitiam acesso a um balde S3 contendo o PII de mais de 100 milhões de americanos.
Esse problema poderia ter sido evitado evitando o uso do IMDS versão 1, o que não requer qualquer autenticação. No entanto, no momento da escrita, o AWS ainda permite o IMDSv1 por padrão em instâncias EC2 recém-criadas, e até mesmo adverte contra desativá-lo.
Historicamente, uma questão ainda mais simples tem sido implicada em inúmeras violações de dados – baldes de armazenamento em nuvem que foram configurados incorretamente para permitir o acesso público. Este problema não está restrito aos baldes AWS S3; existem muitos exemplos on-line de armazenamento em nuvem GCP e Azure sendo igualmente mal configurados. Embora a AWS e outros provedores de nuvem agora forneçam avisos amplos quando os dados estão prestes a ser tornados acessíveis publicamente, essas questões persistem.
Há também uma falta de consciência de que as contas de serviços padrão em nuvem são muitas vezes super-privilegiadas. Ao girar uma computação GCP, por exemplo, se a conta de serviço padrão do projeto for usada e for concedida o escopo de acesso “Permitir acesso total a todas as APIs em nuvem”, isso apresenta uma oportunidade fácil de escalonamento de privilégios. Os desenvolvedores geralmente têm latitude para girar suas próprias instâncias de computação e infraestrutura, nas quais as equipes de TI ou de segurança podem não ter visibilidade. Estes podem ficar muito abaixo dos padrões organizacionais de segurança, que aumentam os riscos de TI sombra e oportunidades atuais para hackers. Também pode haver um mal-entendido ou uma falta de consciência dos controles de acesso e das relações entre os recursos de nuvem provisionados.
As organizações podem ser pegas pensando que podem levantar e transferir seus aplicativos, serviços e dados existentes para a nuvem, onde estarão seguras por padrão. A realidade é que a migração de cargas de trabalho para a nuvem requer planejamento significativo e due diligence, e a adição de experiência em gerenciamento de nuvem à sua força de trabalho. As cargas de trabalho na nuvem contam com um modelo de responsabilidade compartilhada, com o provedor de nuvem assumindo a responsabilidade pelo tecido da nuvem, e o cliente assumindo a responsabilidade pelos servidores, serviços, aplicativos e dados dentro (assumindo um modelo IaaS).
No entanto, esses limites podem parecer um pouco confusos, especialmente porque não há um modelo uniforme de responsabilidade compartilhada entre os provedores de nuvem, o que pode resultar em mal-entendidos para empresas que usam ambientes multi-nuvem. Com tanto investimento em infraestrutura em nuvem – e com uma falta geral de conscientização sobre questões e responsabilidades de segurança na nuvem, bem como a falta de habilidades para gerenciar e proteger esses ambientes – há muito a ser feito. É crucial que desenvolvedores e administradores sejam fornecidos com treinamento em nuvem e segurança, permitindo que eles codam e provisionem recursos com segurança.
Hackear a lacuna de habilidades
De acordo com o Manual de Perspectivas Ocupacionais do Bureau of Labor dos EUA para analistas de segurança da informação, lançado em setembro de 2021, as profissões de segurança cibernética em geral são um dos setores profissionais que mais crescem, com papéis ligados à segurança na nuvem em demanda particularmente alta. Os atuais 3 milhões de talentos globais de cibersegurança estão criando desafios para as organizações, já que as habilidades dos funcionários existentes para gerenciar com segurança a infraestrutura tradicional não se traduzem em ambientes em nuvem. Um novo conjunto de habilidades é necessário para gerenciar a segurança na nuvem à medida que as pessoas procuram pivotar seus conjuntos de habilidades para a nuvem, o que está levando a um aumento na demanda por treinamento.
Para pessoas ofensivas, a infraestrutura tradicional pentesting é um pouco como pentesting de nuvem. Por exemplo, um indivíduo pode obter acesso através de um aplicativo web exposto ou outro serviço hospedado na nuvem, procurar aumentar privilégios no host comprometido e, em seguida, mover-se lateralmente para outros aplicativos identificados e serviços em nuvem. Depois de se mover lateralmente e potencialmente ter acesso a uma conta mais privilegiada no ambiente de nuvem, isso poderia permitir que alguém assumisse completamente o ambiente.
No entanto, existem muitos vetores que são exclusivos da nuvem. O conhecimento desses vetores e a familiaridade com as ferramentas de gestão CLI para cada plataforma em nuvem permitirão que os profissionais realizem um exame mais rigoroso da postura de segurança de um cliente. Para upskill na nuvem, é necessário estar confortável com scripts, estar familiarizado com as ferramentas de gerenciamento CLI para cada plataforma de nuvem (ou aquela em que você quer se especializar) e ter um conhecimento sólido de kits de ferramentas ofensivas em nuvem. Recomenda-se obter experiência prática com a implantação e intencionalmente recursos que podem ser explorados e olhar para várias maneiras que poderiam ser endurecidos.
Ferramentas ofensivas de nuvem
Ambientes em nuvem, assim como os ambientes tradicionais do Active Directory, contêm uma série de permissões desconcertantes e possibilidades de objeto acorrentado para controle de objetos.
Embora seja possível usar ferramentas CLI para enumerar e identificar os melhores caminhos de ataque, ferramentas de segurança ofensiva de código aberto foram criadas para realizar o levantamento pesado da enumeração e podem acelerar o progresso em direção aos nossos objetivos.
A ferramenta de auditoria bloodhound active directory precisa de pouca introdução – é amplamente utilizada por equipes cibernéticas vermelhas e azuis. O Azure AD não é o Active Directory, embora existam semelhanças conceituais, e a capacidade do BloodHound foi estendida para poder avaliar ambientes Azure. Os tipos atualizados de nó Bloodhound incluem assinaturas do Azure, VMs, Usuários, Diretores de Serviços, Aplicativos, Grupos de Recursos, Tenents, Key Vaults e Dispositivos, enquanto as novas bordas do Azure incluem auditoria para permissões de Administrador Global, Contribuinte, RunAs e muito mais além disso. Projetos do GitHub, como o VulnerableAzure, criam um ambiente intencionalmente vulnerável do Azure para explorar os novos recursos do Bloodhound.
Para a AWS, alguns kits de ferramentas ofensivas populares incluem pacu e WeirdAAL. Embora eles não exibam graficamente o objeto para controlar relacionamentos de controle de objetos ou destacar potenciais cadeias de ataque que levam à aquisição de contas, ambos identificam configurações erradas e privilégios que podem nos permitir mover-nos lateral e verticalmente dentro dos ambientes AWS. Para ambientes GCP, ScoutSuite é uma ferramenta CLI que identifica possíveis vetores de ataque. O tooling para Azure e AWS é geralmente mais prevalente, mas o ferramentas ofensivos para GCP deve estar mais amplamente disponível à medida que a adoção do GCP aumenta.
Os profissionais devem realizar treinamento dedicado de segurança na nuvem para garantir que suas habilidades, ofensivas ou defensivas, possam proteger as informações confidenciais armazenadas em ambientes em nuvem.
FONTE: HELPNET SECURITY