0
0
Uma coisa não tão engraçada aconteceu à medida que as organizações transitaram para a nuvem: em muitos casos, elas também perderam a responsabilidade e esqueceram as responsabilidades críticas.
No mundo local, a equipe de TI sabe que é responsável pela infraestrutura em que os aplicativos são implantados. Normalmente, existem procedimentos e políticas estabelecidos para manter a conformidade de segurança, o risco e a detecção de violações. Talvez mais importante, também há uma linha clara de responsabilidade sobre quem é o responsável pelas operações, configuração e segurança de um determinado sistema. E quando não houve colaboração, as equipes de segurança envolvidas em processos como controle de mudanças e tecnologia em torno da infraestrutura.
A nuvem é um modelo diferente. Os provedores de nuvem estão literalmente fornecendo a infraestrutura com a quais as organizações dependem — e, em muitos casos, os serviços também. Além disso, o ritmo de inovação e frequência de mudanças é tal que processos antigos não se aplicam ou o retardam. Vivemos em um mundo efêmero agora.
De um modo geral, os provedores de nuvem são responsáveis por sua própria infraestrutura, incluindo hardware, rede, host OS e hypervisor, além de fornecer um certo nível de serviço e disponibilidade. Mas só porque um aplicativo ou serviço está sendo executado na nuvem não significa que um usuário final ou organização não seja mais responsável pela segurança. Todos os principais provedores de nuvem pública nos últimos anos adotaram o conceito comumente referido como “responsabilidade compartilhada”.ANÚNCIO. CLIQUE PARA VER O SOM.
O Modelo de Responsabilidade Compartilhada é muito bem compreendido agora para significar: “Se você configurá-lo, arquitetar ou codá-lo, você possui a responsabilidade de fazer isso corretamente.”
Embora o relacionamento entre o cliente e a nuvem seja bem compreendido, nossa experiência trabalhando com equipes de software indica que as responsabilidades de organização e segurança arquitetônica dentro das organizações não são. E é aí que entra em jogo o Modelo de Irresponsabilidade Compartilhada.
Por que a irresponsabilidade compartilhada É comum
Quando algo dá errado na nuvem – algum tipo de problema de segurança ou incidente – a gestão corporativa inevitavelmente virá à procura da pessoa mais sênior da organização de TI para culpar.
As equipes de organização e desenvolvimento de TI podem não ter ido linha por linha através dos vários modelos de responsabilidade compartilhada dos provedores de nuvem para entender completamente o que é e não é algo com que eles têm que lidar. Os desenvolvedores estão focados em desenvolver e obter códigos em execução, normalmente com altas taxas de mudança.
Com a nuvem, empurrar o código para a produção não tem muitos obstáculos. O provedor de nuvem não é responsável pela própria conformidade de uma organização e, por padrão, normalmente não alertará sobre configurações erradas que podem introduzir riscos, também. Assim, nem a equipe de desenvolvimento nem o provedor de nuvem assumem a responsabilidade pela segurança. Embora isso possa parecer duro, ambos são funcionalmente irresponsáveis.
O Modelo de Irresponsabilidade Compartilhada é uma função do que acontece nas empresas quando todos estão focados em resultados e implantação rápida para aproveitar ao máximo a nuvem. Seu inevitável estado final é apontar o dedo dentro de grupos e organizações sobre quem não fez seu trabalho.
Trazendo responsabilidade para a nuvem
Para ajudar a corrigir isso, existem quatro áreas críticas para investir.
- Arquitetura e organizacional
- Ferramentas e afinação
- Causalidade e correlação
- Fluxo de trabalho e automação
Arquitetura e Organizacional
A lacuna entre seu processo de desenvolvimento e arquiteturas não pode estar anos-luz à frente de sua arquitetura de segurança. Se sua equipe de segurança está tentando mover um produto de segurança tradicional para a nuvem (também conhecido como lavagem de nuvens), você encontrará todos os tipos de obstáculos. A segurança deve ter paradigmas de nuvem de arquitetura semelhantes, como visibilidade em um mundo efêmero, automação, política como código e análise em tempo real. Sua organização também deve estar alinhada. O DevOps precisa estar ciente dos trilhos de segurança e as necessidades de processo e segurança para se encaixar no processo de desenvolvimento, não em torno dele. A cooperação e uma compreensão clara da triagem, notificação de violação e exposição ao risco devem ser acordadas entre as equipes.
Ferramentas e Sintonia
Assim como os silos organizacionais, ferramentas díspares também causarão atrito. As equipes devem compartilhar o conjunto de ferramentas apropriado e trabalhar a partir dos mesmos dados ou uma “fonte de verdade”. O compartilhamento de conhecimento sobre como as ferramentas são usadas, os dados são armazenados e consultados, e uma compreensão completa da saída permitirá que as equipes conversem com uma linguagem comum e ajudem a ajustar riscos e exposições ao longo do tempo.
Embora a votação eletrônica tenha sido atormentada por temores de adulteração ou fraude, a Voatz está procurando tornar o processo mais transparente e auditável, de acordo com o fundador da empresa, Nimit Sawhney. Ele oferece pontos de aprendizado de três pilotos recentes que destacam como os governos podem melhorar a integridade e proteger melhor o processo de votação e seus dados.Trazido a você por Voatz
Causalidade e Correlação
Um dos maiores benefícios da computação em nuvem é a capacidade de executar a infraestrutura como código e provisão automaticamente para cima e para baixo em tempo real. Além disso, o aumento do serviço de plataforma como serviço permitiu a implantação de armazenamento, aprendizado de máquina, provisionamento de API e, literalmente, milhares de outros serviços com algumas linhas de código. No entanto, esse incrível poder também pode expor as organizações a riscos e ameaças que de outra forma eram inexistentes e muito mais fáceis de rastrear em data centers privados. Uma compreensão completa da mudança disso em seu ambiente de nuvem é fundamental para o sucesso. A causa e o efeito e a capacidade de correlação entre os serviços também são fundamentais.
Fluxos de trabalho e automação
As organizações mais maduras entendem e combinam fluxos de trabalho em DevOps e segurança. Isso pode ser algo tão simples quanto um sistema de roteamento de bilhetes, um sistema mais complexo, como integrações de chat-ops ou um fluxo de trabalho completo de automação. No entanto, se você não tem as arquiteturas apropriadas, ferramentas compartilhadas e data warehouses, e um entendimento da mudança, isso é muito difícil.
A utopia da ponte do Modelo de Irresponsabilidade Compartilhada é exatamente isso. Um sistema automatizado exige uma compreensão organizacional completa em tempo quase real dos riscos e ameaças ao seu ambiente. Nunca assuma que só porque um aplicativo ou serviço está na nuvem, isso significa que outra pessoa está protegendo-o. Intensifique, coloque as ferramentas de conformidade no lugar, e assuma a responsabilidade… porque se você não fizer isso, então quem vai?
FONTE: DARK READING