O Cloud Discovery é uma ferramenta de código aberto da Twistlock que se conecta a provedores cloud e obtém um inventário dos vários recursos de infraestrutura implantados. O Cloud Discovery reúne e relata os metadados dos recursos de maneira agregada.
Com o Cloud Discovery, os usuários não precisam procurar em consoles de diferentes provedores cloud e não precisam navegar manualmente por todas as páginas de serviço (como o AWS EC2 ou o Azure Virtual Machines), para depois exportar os dados e agrupá-los novamente em uma planilha. Além disso, as falhas de segurança dos aplicativos podem ser identificadas quando há mais visibilidade em vários ambientes, como quais recursos precisam de uma regra de firewall. Por exemplo, você poderia usar o Cloud Discovery para executar verificações de segurança depois que os recursos da cloud forem criados em um pipeline de CI/CD e, em seguida, alertar ou aplicar um patch automaticamente antes que as novas alterações entrem em vigor. Independentemente de os aplicativos serem implantados na AWS, no Azure ou no Google Cloud Platform, o Cloud Discovery só precisa de permissões de leitura para coletar as informações necessárias.
Além de descobrir serviços fornecidos pelo provedor da cloud, o Cloud Discovery também pode identificar componentes nativos da cloud "auto-instalados". Por exemplo, os registros do Docker em instâncias do EC2 ou os servidores da API do Kubernetes gerenciados pelos usuários. Em seguida, com os dados coletados, ele identifica configurações fracas de segurança nesses clusters, como abrir publicamente o acesso SSH.
O InfoQ conversou com Liron Levin, arquiteto-chefe da Twistlock, para saber mais sobre os casos de uso e como usar o Cloud Discovery.
InfoQ: Por que usar o Cloud Discovery? Por que não usar as ferramentas de métricas nativas existentes dos provedores de cloud para obter um inventário dos recursos implantados?
Liron Levin: Hoje, os provedores de cloud estão lançando novos serviços a uma taxa impressionante e os quais os desenvolvedores ficam empolgados para experimentar. Essas duas tendências culminam em uma tempestade perfeita em que as organizações não conseguem acompanhar com facilidade quais serviços estão sendo implantados, em qual provedor ou região da cloud e com quais permissões específicas. Queríamos tornar rápido e fácil para qualquer organização saber exatamente quais serviços foram implantados e onde, dando-lhes visibilidade sobre aquilo "desconhecidos não conhecidos" da expansão de serviços nativos da cloud.
Uma organização usaria o Cloud Discovery para ter melhor visibilidade em cloud para, então, começar a proteger esses recursos, sejam eles PaaS ou IaaS. Quanto mais serviços implantados não estiverem protegidos, mais propensa a organização está a ataques e ameaças. Com o Cloud Discovery, a organização consegue obter um inventário de todos os vários artefatos de cloud que foram implantados em suas contas nos provedores de cloud pública instantaneamente e entender quais estão protegidos e quais não estão.
InfoQ: Como começamos a usar o Cloud Discovery em um ambiente com multi-cloud? Onde e como você implementamos a ferramenta?
Levin: o Cloud Discovery foi criado para ser executado como um serviço autônomo em um contêiner. Por exemplo, você iniciaria um contêiner executando o seguinte comando:
docker run -d --name cloud-discovery --restart=always \ -e BASIC_AUTH_USERNAME=admin -e BASIC_AUTH_PASSWORD=pass -e PORT=9083 -p 9083:9083 twistlock/cloud-discoverEm seguida, para verificar e listar todos os recursos da AWS, você consulta o Cloud Discovery com a seguinte chamada de API:
curl -k -v -u admin:pass --raw --data \ '{"credentials": [{"id":"<AWS_ACCESS_KEY>","secret":"<AWS_ACCESS_PASSWORD>"}]}' \ https://localhost:9083/discoverOu, se você quiser as mesmas informações do GCP, faça a seguinte chamada:
SERVICE_ACCOUNT=$(cat <service_account_secret> | base64 | tr -d '\n') curl -k -v -u admin:pass --raw --data '{"credentials": [{"secret":"'${SERVICE_ACCOUNT}'", "provider":"gcp"}]}' https://localhost:9083/discover?format=jsonEstamos atualmente no processo de adicionar instruções para o Azure.
InfoQ: Como podemos integrar o Cloud Discovery com outras ferramentas?
Levin: Criamos o Cloud Discovery com um foco específico em interoperabilidade e facilidade de integração. Seguindo a filosofia Unix de fazer bem uma coisa, ela é projetada para extrair metadados sobre cada serviço nativo da cloud que você está usando em cada provedor, conta e região e retorná-lo em um formato JSON aberto padrão. Há todo um universo de ferramentas que já funcionam bem com o JSON e facilitam o monitoramento, o alerta e o rastreamento de alterações ao longo do tempo. Vimos pessoas usarem o Cloud Discovery para fornecer relatórios aos auditores, para integrarem-se ao SIEM e alertarem sobre serviços intrusos recém-implantados e até mesmo para ajudar a identificar possíveis recursos desperdiçados na cloud.
Portanto, se uma organização já estiver usando uma pilha de monitoramento que possa consumir JSON, as APIs de integração poderão ser usadas para obter a resposta JSON e exibir os dados na ferramenta. Na verdade, um aplicativo pode ser gravado para usar o Cloud Discovery em um intervalo de tempo para receber atualizações e, em seguida, atualizar as outras ferramentas de monitoramento e alerta por meio de suas APIs.
InfoQ: Poderia nos dar um exemplo de como integrar o Cloud Discovery? Podemos configurar alertas?
Levin: Por exemplo, alguém poderia usar o Cloud Discovery para executar um comando de varredura de porta, em seu ambiente diariamente, como por exemplo:
curl -k -v -u admin:pass --raw --data '{"subnet":"172.17.0.1", "debug": true}' https://localhost:9083/nmapA chamada acima geraria uma saída como a da seguinte imagem:
Neste exemplo, uma pessoa poderia determinar rapidamente que alguém forneceu um registro e uma instância do MongoDB que são inseguros porque não têm autorização.
De lá, eles enviam os dados JSON para qualquer aplicativo que estejam usando no momento para alertar e alimentar esses dados em um cronograma predefinido. Em seguida, alerte quem precisa saber que existem recursos inseguros ou recursos que não deveriam estar lá.
InfoQ: Qual é o roadmap para o Cloud Discovery?
Levin: O Cloud Discovery já suporta os três principais provedores de cloud (AWS, GCP e Azure), mas estamos procurando adicionar suporte para o IBM Cloud e o Oracle Cloud em um futuro próximo. Também estamos trabalhando na inclusão de uma verificação adicional para aplicativos populares inseguros, incluindo o RabbitMQ, o Redis, o Postgres, o Wordpress (suporte a força bruta), o Elasticsearch, o Kibana, o Vault (garantir que o https esteja configurado) e o Nats.
O terceiro aprimoramento em que estamos trabalhando é a detecção de ataque de força bruta de senhas comuns para esses aplicativos inseguros. Isso inclui verificações adicionais de detecção de força bruta que verificam nomes de usuário e senhas predefinidas, bem como uma lista de senhas personalizadas.
InfoQ: O Cloud Discovery é a primeira contribuição independente que o Twistlock fez. Mas você esteve ativo na comunidade de código aberto antes dessa ferramenta, correto?
Levin: Sim, nossa equipe criou o framework de autorização no Docker, que é usada pelo OpenShift, e pelo Open Policy Agent e pelo back-end secreto de terceiros para o Docker Swarm. Também contribuímos para o benchmark Kubernetes CIS. Nosso CTO John Morello foi co-autor do NIST SP 800-190, o Container Security Guide, e nosso braço de pesquisa, a Twistlock Labs, encontrou 14 vulnerabilidades de segurança que foram divulgadas publicamente, com IDs de CVE que foram alocadas para o NVD. Portanto, além das contribuições de código aberto, nossa equipe contribui significativamente para melhorar a segurança de contêineres para o ecossistema nativo mais amplo da cloud como um todo.
Alguns exemplos específicos de nossas contribuições de código aberto incluem um backend de segredos conectáveis para o Docker, um plug-in de autenticação no Docker, compatibilidade de contêineres privilegiados com usuários, autenticação TLS no Docker e uma alteração no comportamento padrão de autenticação do registro do Docker.
O código está disponível escrito em Go no repositório oficial do GitHub e quais implementações em cada provedor de cloud ele suporta.