À medida que as organizações migram cada vez mais para a nuvem, garantir dados confidenciais nunca foi tão crítico. Embora a computação em nuvem ofereça flexibilidade e escalabilidade, ela também abre a porta para uma variedade de riscos de segurança.
De simples configurações incorretas a ameaças complexas, violações de segurança em nuvem custaram às empresas grandes somas de dinheiro e comprometeram milhões de informações privadas dos usuários. Neste artigo, exploramos 10 falhas de segurança em nuvem de alto perfil, cada uma que fornece uma lição very important sobre a importância de práticas de segurança robustas. Esses incidentes da vida actual servem como contos de advertência para empresas que dependem de serviços em nuvem, oferecendo takea-vase para ajudar a evitar a próxima grande violação.
Aqui está o que deu errado, o que poderia ter sido feito de maneira diferente e como as empresas podem fortalecer suas defesas contra o cenário em constante evolução das ameaças à segurança da nuvem.
1. Dropbox (2012)
Incidente: Um hacker obteve credenciais de usuário do Dropbox através de uma violação de terceiros e acessou os arquivos armazenados em nuvem dos usuários, expondo milhões de contas.
Resposta: Uma investigação do Dropbox determinou que os nomes de usuário e senhas roubados de outros websites foram usados para entrar em “um pequeno número” de contas do Dropbox. A empresa entrou em contato com esses usuários, oferecendo -se para ajudá -los a proteger suas contas.
Aditya Agarwal, então vice -presidente de engenharia do Dropbox, disse: “Uma senha roubada também foi usada para acessar uma conta Dropbox de funcionários que contém um documento do projeto com endereços de e mail do usuário. Acreditamos que esse acesso inadequado é o que levou ao spam”. Ele acrescentou que o Dropbox estava implementando controles adicionais para ajudar a garantir que não houvesse repetição do problema.
A empresa de armazenamento em nuvem optou por introduzir autenticação de dois fatores (2FA) e monitoramento aprimorado de segurança para evitar violações futuras. Mais tarde, em 2016, foi revelado que a violação havia afetado mais de 68 milhões de contas de usuário. A Dropbox levou os usuários que não haviam alterado suas senhas desde 2012 a fazê -lo como medida de precaução.
Lição: A importância da autenticação forte e multifatorial (MFA) e monitoramento para atividades de login incomuns.
2. Snapchat (2014)
Incidente: A infraestrutura baseada em nuvem do Snapchat foi comprometida devido a vulnerabilidades na maneira como lidou com os dados do usuário. Os hackers exploraram sistemas em nuvem e vazaram milhões de fotos.
Resposta: Nesse vazamento de dados, geralmente chamado de “o snapping, o próprio Snapchat não foi hackeado diretamente. Em vez disso, aplicativos de terceiros que armazenavam fotos do Snapchat foram comprometidos. Um porta-voz da empresa disse:“ Snapchatters foram vitimados pelo uso de aplicativos de terceiros para enviar e receber SNAPs.
Proibimos expressamente aplicativos de terceiros que acessam nosso serviço, pois comprometem a segurança dos usuários. ” O Snapchat alertou os usuários contra aplicativos de terceiros e melhorou suas políticas de segurança para ajudar a evitar o acesso não autorizado.
Lição: Medidas de segurança adequadas para dados do usuário e manuseio de imagens no armazenamento em nuvem podem impedir vazamentos de dados de massa.
3. Uber (2016)
Incidente: Os hackers acessaram o armazenamento baseado em nuvem da Uber e obtiveram dados pessoais de 57 milhões de usuários e drivers. O Uber inicialmente não conseguiu relatar a violação.
Resposta: Os executivos do Uber finalmente comentaram a violação em 2017, mas somente depois de ter sido divulgada. A empresa de transporte confirmou que 57 milhões de contas foram comprometidas, incluindo nomes, endereços de e -mail e números de telefone de usuários e drivers. Em vez de relatar a violação na época, a Uber pagou aos hackers US $ 100.000 sob o disfarce de uma recompensa de insetos para excluir os dados e permanecer em silêncio.
Em novembro de 2017, Dara Khosrowshahi, que se tornou CEO da Uber após a violação, admitiu o fracasso da Uber em divulgar o incidente mais cedo. Ele disse: “Nada disso deveria ter acontecido, e eu não darei desculpas por isso. Estamos mudando a maneira como fazemos negócios. Estamos tomando medidas para garantir que façamos a coisa certa daqui para frente”.
Joe Sullivan, CSO da Uber durante a violação, foi posteriormente demitido e acusado de encobrir o hack. Os promotores o acusaram de obstruir a justiça ao classificar incorretamente a violação como um pagamento de recompensa de insetos. Durante seu julgamento de 2022, Sullivan defendeu suas ações, afirmando: “Eu estava seguindo os processos que estavam no Uber na época”.
No entanto, ele foi considerado culpado de obstruir a justiça, marcando a primeira vez que um executivo de segurança foi condenado por manipular uma violação de dados. Após esse escândalo, a Uber fortaleceu suas políticas de segurança e alcançou um acordo de US $ 148 milhões por não divulgar a violação.
Lição: Monitore regularmente e proteja o armazenamento em nuvem, aplique o controle rigoroso de acesso e garanta protocolos adequados de resposta a incidentes.
4. AWS S3 Breach (2017)
Incidente: Um grande vazamento de dados ocorreu quando as empresas deixaram os baldes da AWS S3 acessíveis ao AWS. Esses dados confidenciais expostos, como informações do cliente, documentos de negócios internos e comunicações privadas.
Resposta: AWS Enfatizou que as violações não foram devidas a vulnerabilidades na própria AWS, mas sim incrustações incorretas por clientes que inadvertidamente deixaram seus baldes de armazenamento S3 acessíveis ao público.
O provedor de computação em nuvem emitiu uma declaração esclarecendo que essas violações foram o resultado do erro do usuário, explicando: “A Amazon S3 é segura por padrão e o acesso ao balde é controlado pelo cliente. Fornecemos orientações e ferramentas claras para os clientes configurarem seus recursos com segurança.”
AWS continuou a lançar adiçãol Recursos de segurança e aprimoramentos para ajudar os clientes a proteger seus dados.
No ano seguinte, o AWS CISO, Stephen Schmidt (AWS CISO), abordou essas preocupações na AWS RE: Invent 2017. Ele disse: “O risco de segurança número um que vemos hoje ainda é equivocado. Incentivamos fortemente os clientes.
Lição: Sempre configure as permissões de acesso com cuidado e audite regularmente o armazenamento em nuvem para riscos de segurança.
5. Accenture (2017)
Incidente: A Accenture expositou acidentalmente seus bancos de dados de nuvem internos, que continham informações confidenciais do cliente, incluindo senhas, devido a configurações de segurança fracas.
Resposta: Após a descoberta, a Accenture garantiu prontamente os dados expostos e declarou: “Não havia risco para nenhum de nossos clientes – sem credenciais ativas, PII ou outras informações confidenciais foram comprometidas”.
Ele esclareceu ainda que as informações expostas não concederam acesso a sistemas de clientes e não estavam relacionados a dados ou aplicativos de produção.
Lição: Sempre criptografar dados confidenciais e gerenciar cuidadosamente o acesso à infraestrutura baseada em nuvem.
6. Github (2018)
Incidente: O Github experimentou um ataque de DDoS maciço que alavancou a capacidade da nuvem de escalar. O ataque superou a infraestrutura do Github, mas o incidente mostrou como os serviços em nuvem podem ativar e mitigar ataques em larga escala.
Resposta: Esse ataque de DDoS foi um dos maiores já registrados na época, chegando a 1,35 terabits por segundo (TBPS). Foi um ataque de amplificação em memcached, que alavancou servidores não garantidos para inundar a infraestrutura do Github com o tráfego.
Depois de mitigar com sucesso o ataque, Github’s A equipe de engenharia publicou uma postagem no weblog detalhando o incidente. Ele afirmou: “Entre 17:21 e 17:30 UTC, o Github foi impactado por um ataque de DDoS volumétrico recorde. Exigimos brevemente a disponibilidade intermitente, mas nossos sistemas mitigaram automaticamente o ataque. Modelamos nossos capacidades de resposta a DDoS em ataques anteriores e imediatamente roteou o tráfego ao nosso provedor de mitigação de DDOS.”
O engenheiro do Github, Sam Kottler, acrescentou: “Este foi o maior ataque de DDOs que nós-e o mundo-já vimos na época. Estratégias de mitigação baseadas em nuvem ajudaram a absorver o enorme influxo de tráfego”.
Lição: Os serviços em nuvem são incrivelmente escaláveis, mas é essencial ter estratégias de mitigação de DDOs em vigor, mesmo em ambientes em nuvem.
7. Capital One (2019)
Incidente: Um Bucket AWS S3 e dados incorretos expostos a dados confidenciais de mais de 100 milhões de clientes. Um ex -funcionário da AWS explorou uma vulnerabilidade, acessando informações pessoais, pontuações de crédito e detalhes bancários.
Resposta: Em 29 de julho de 2019, a Capital One anunciou que, em 19 de julho de 2019, havia determinado que havia acesso não autorizado por um indivíduo externo que obteve certos tipos de informações pessoais relacionadas a pessoas que se candidataram a seus produtos de cartão de crédito e a capitalizar clientes de cartão de crédito.
A Capital One disse que consertou imediatamente a vulnerabilidade de configuração que foi explorada e prontamente começou a trabalhar com a aplicação da lei federal. O indivíduo responsável pela violação foi preso pelo FBI, e o Capital One ofereceu monitoramento de crédito gratuito e proteção de identidade aos afetados.
Lição: A importância do gerenciamento adequado de configuração e controle de acesso nos serviços em nuvem.
8. Microsoft (2019)
Incidente: Em 2019, a Microsoft expôs milhões de registros de suporte ao cliente devido a configurações incorretas de armazenamento em nuvem. Os dados foram armazenados no Azure Blob Storage e descobriu -se que os registros, que incluíam tickets de suporte ao cliente e outras informações confidenciais, eram acessíveis ao público devido a configurações inadequadas de segurança.
Resposta: A Microsoft garantiu rapidamente os dados expostos e reconheceu que um fornecedor de terceiros foi responsável pelo erro. Eles esclareceram que os dados não foram acessados por atores mal -intencionados, mas eram visíveis publicamente devido à equação. A Microsoft trabalhou para evitar incidentes semelhantes no futuro, apertando os protocolos de segurança para armazenamento em nuvem.
Lição: Este incidente destaca a importância crítica de configurar corretamente o armazenamento em nuvem e a aplicação dos controles de acesso adequados. As auditorias regulares de segurança e o monitoramento são necessários para identificar e corrigir vulnerabilidades antes que possam ser exploradas.
9. Fb (2019)
Incidente: O Fb expôs mais de 540 milhões de registros por meio de armazenamento em nuvem não garantidos, incluindo dados como comentários, curtidas e reações do usuário, tornando -o vulnerável ao acesso externo.
Resposta: Depois que a exposição foi descoberta, o Fb reconheceu que os desenvolvedores de terceiros eram responsáveis pelo armazenamento não garantido. O Fb esclareceu que os dados não vazaram diretamente de seus próprios sistemas, mas foram o resultado de práticas inadequadas de segurança por desenvolvedores de aplicativos que usaram as APIs do Fb para coletar dados do usuário.
O Fb teria trabalhado para notificar os desenvolvedores de terceiros e os incentivou a consertar as vulnerabilidades de segurança. Também restringiu o acesso à API que permitia que os aplicativos coletassem esses dados, dificultando a ocorrência de vazamentos de dados futuros devido a incorporação incorreta.
Lição: Verifique se o armazenamento em nuvem está configurado corretamente e implemente a criptografia para proteger os dados em repouso.
10. Slack (2020)
Incidente: A infraestrutura em nuvem do Slack foi comprometida depois que o token da API de um funcionário foi exposto publicamente. Isso permitiu acesso não autorizado a dados corporativos sensíveis.
Resposta: Slack reconheceu a violação e forneceu detalhes aos clientes sobre como o incidente foi tratado. Ele enfatizou que o incidente period de escopo limitado e não levou a um compromisso mais amplo de sua infraestrutura.
Em um put up, afirmou: “Determinamos que o incidente foi o resultado de um token da API exposto. Permitiu o acesso não autorizado a certas partes do nosso sistema. O problema foi totalmente resolvido e o token exposto foi invalidado”.
A empresa também enfatizou que nenhum dado de usuário confidencial (como mensagens privadas ou credenciais de conta) foi exposto na violação.
A Slack atualizou suas práticas de segurança em torno do gerenciamento de token da API, incentivando as organizações a usar métodos mais seguros para lidar com os tokens de API e adotar medidas adicionais de autenticação para evitar incidentes futuros.
Lição: Monitore regularmente e gire os tokens e as chaves da API para mitigar o risco de uso indevido.
Imagem por Akash Kumar de Pixabay
Deseja aprender mais sobre segurança cibernética e nuvem dos líderes da indústria? Confira Cyber Safety & Cloud Expo Ocorrendo em Amsterdã, Califórnia e Londres.
Discover outros próximos eventos de tecnologia corporativa e webinars alimentados pela TechForge aqui.