Entenda o risco das políticas. Faça perguntas sobre políticas em linguagem natural. Solicite uma demonstração →

Published:

Aprimorando a Grande Teoria Unificada da Governança de Nuvem

by Rich Mogull

Há pouco mais de um ano, escrevi a Grande Teoria Unificada da Governança de Nuvem. É um conceito com o qual venho trabalhando há cerca de 5 ou 6 anos, na tentativa de sintetizar a causa raiz das dificuldades que as empresas enfrentam ao se adaptar à nuvem. É verdade que o título é um pouco egocêntrico, mas eu já fui analista do Gartner, então, fazer o quê?

Como qualquer teoria (espero) boa, continuo a desenvolvê-la ao longo do tempo, à medida que trabalho com mais empresas e converso com mais pessoas. Tenho usado bastante essa teoria nos últimos dois anos em minhas palestras e treinamentos, especialmente porque tenho sido convocado para mais cenários de governança. Repetidas vezes, os principais problemas que encontro não são tanto técnicos, mas organizacionais. Sim, existem MUITAS complexidades técnicas na segurança em nuvem, e elas podem resultar e resultam em violações, mas, pela minha experiência, as questões de governança superam em muito as técnicas.

Uma boa governança não corrige um zero day, mas uma má governança faz com que o atacante nunca precise de um.

O núcleo da teoria não mudou de fato; apenas continuo buscando formas melhores de explicá-la. Também decidi enxugá-la um pouco. Veja como atualmente a coloco em meus slides:

  • A nuvem descentraliza operações e infraestrutura
  • Mas a nuvem unifica todas as interfaces administrativas
  • E coloca todos os portais administrativos e recursos na Internet, protegidos por um nome de usuário e uma senha

Em relação à versão anterior, as mudanças são pequenas, mas também grandes:

  • Todas as funções administrativas e de gerenciamento são unificadas em uma única interface de usuário que está na Internet.
  • Protegida por um nome de usuário, uma senha e, talvez, MFA.
  • A tecnologia evolui mais rápido do que a governança.

Ainda uso a expressão “sem pontos de estrangulamento nem guardiões” nas minhas apresentações, mas percebi que é uma forma mais longa de dizer “descentralizado”. A questão fundamental é o controle independente de toda a pilha fora da infraestrutura centralizada. O fato de uma equipe de desenvolvimento ou de aplicações poder construir e gerenciar toda a sua própria infraestrutura em seu próprio ambiente apenas com um cartão de crédito. Agora, existem ainda algumas dependências e controles, especialmente no plano de dados ou quando é necessário reconectar-se às redes, mas isso não altera o ponto principal.

Tentar recentralizar completamente raramente vai funcionar.

Em seguida, não alterei realmente a unificação das interfaces administrativas. Para detalhar: descentralizamos toda a infraestrutura e o controle no nível da implantação, mas todos, no mundo inteiro, usam o mesmo console web e os mesmos endpoints de API.

Os atacantes têm um único portal para infinitos alvos.

Depois, peguei o subitem da versão um e o transformei no item 3. Esses portais administrativos estão todos na Internet e, por padrão, usam pouco mais do que um nome de usuário e uma senha. Todos os recursos também estão a uma configuração de distância de ficarem expostos na Internet; basta perguntar a todos aqueles buckets S3 e clusters ElasticSearch.

É realmente simples assim. As equipes gerenciam seus próprios recursos de forma independente. Todas elas, no mundo inteiro, usam os mesmos portais web e endpoints de API. E qualquer idiota com as credenciais certas pode bisbilhotar e mexer nos bastidores do seu “datacenter”.

Agora a parte curiosa: tudo isso já estava descrito em 2011 no NIST 800-145, as 2 páginas da Definição de Computação em Nuvem do NIST. Esse documento definiu as cinco características essenciais da computação em nuvem como:

  • Autosserviço sob demanda
  • Amplo acesso à rede
  • Pooling de recursos
  • Elasticidade rápida
  • Serviço mensurado

Tomando os três primeiros pontos, temos:

  • As equipes gerenciam seus próprios recursos
  • Está tudo na Internet
  • E tudo baseado em pools coletivos de recursos

Muito bem, então o que tudo isso significa e o que devemos fazer?

Aceitar.

Esse é o primeiro passo. Compreender o problema e usá-lo como lente para conceber nossas soluções. Como escrevi recentemente em meu artigo sobre Autorização Forte:

Porque não estão acostumados a ter tudo (potencialmente) na Internet. Todo o plano de gerenciamento está na Internet, portanto, se um atacante obtiver credenciais, não será possível detê-lo com um firewall ou bloqueando o acesso a um servidor.

Comece por aí. Aceite a realidade básica. O que podemos fazer para reduzir esse risco? Para reduzir esses ataques? Acredito que a escolha de maior impacto seja focar em IAM e na interseção entre governança e IAM. Quem gerencia as permissões? E o acesso? Quais controles de segurança podem prevenir, detectar e corrigir ataques relacionados a IAM? Quais são os seus processos em torno de IAM? Os seus responsáveis por resposta a incidentes conhecem a fundo o IAM do(s) seu(s) provedor(es) de nuvem? Você utiliza JIT/Autorização Forte? Como gerencia o IAM para prestadores de serviços e serviços externos?

Comece pela sua governança e pelos seus processos de IAM. Depois, escolha e utilize tecnologias para apoiá-los. Essa é a forma isolada de maior impacto para melhorar a sua segurança em nuvem. Espero sinceramente não ser a primeira pessoa a lhe dizer isso.

Aprimorando o modelo unificado de governança de nuvem | FireMon