Falco, a ferramenta de segurança de tempo de execução nativa da nuvem e de código aberto, formou-se recentemente no programa de incubação da Cloud Native Computing Foundation. Isso significa que é considerado estável e pronto para uso em ambientes de produção, incluindo o Azure. Ele une muitos dos principais componentes de uma plataforma nativa da nuvem, incluindo Helm, Envoy, etcd, KEDA e Cloud Events.

Recentemente, conversei com Loris Degioanni, CTO e fundador da empresa de segurança nativa da nuvem Sysdig e criador do Falco, sobre a filosofia por trás do projeto e como ele está sendo usado em aplicativos Kubernetes.

Por que Falcão?

Há necessidade de ferramentas de segurança projetadas para funcionar em Kubernetes e em contêineres. Os ambientes de microsserviços que aumentam ou diminuem sob demanda estão muito longe dos aplicativos monolíticos antigos ou das arquiteturas mais recentes, como n-tier ou orientação a serviços. Novas instâncias precisam ser detectadas e monitoradas assim que surgem, garantindo que, à medida que nossas malhas de serviço se tornam maiores e mais complexas, tenhamos a visibilidade necessária para mantê-las seguras.

Você pode pensar na segurança nativa da nuvem como algo semelhante ao papel da observabilidade no Devops. Não estamos procurando incidentes específicos, mas padrões em dados de telemetria que mostrem exceções à norma. As ferramentas de segurança tradicionais podem ajudar a proteger o código executado em um contêiner, mas não são capazes de lidar com padrões sem servidor ou infraestrutura dinâmica.

Patrocinado pela empresa de segurança em nuvem Sysdig, o Falco é uma ferramenta de segurança em tempo de execução projetada para operar em um nível muito baixo em seus contêineres e aplicativos, com acesso direto às funções de rede em nível de kernel. O resultado é a capacidade de detectar intrusões e comprometimentos em tempo real em toda a sua infraestrutura de aplicativos. Os dados do evento são coletados e um mecanismo de regras é usado para identificar problemas de segurança. Você pode criar suas próprias regras ou trabalhar com regras desenvolvidas pela comunidade.

As regras de Falco são melhor entendidas como políticas. Como diz Degioanni, “(Falco tem) uma linguagem de política que você pode usar para definir uma política, como alguém iniciando um shell interativo em um dos meus contêineres Redis”. Quando uma política é correspondida, um evento é gerado e entregue a um serviço central de monitoramento e usado para fornecer a resposta apropriada.

Uma ferramenta importante para a Falco é o uso de sondas eBPF. Esses são scripts em sandbox executados dentro do kernel do Linux, fornecendo monitoramento direto de syscalls em alta velocidade. Isso deve ajudar a identificar invasões rapidamente, permitindo automatizar respostas usando aplicativos externos, por exemplo, lançando um evento na nuvem e acionando ações sem servidor que protegem seus dados.

Protegendo o Kubernetes do kernel Linux

O Falco foi projetado para funcionar em qualquer cluster Kubernetes, incluindo o Azure Kubernetes Service, e entregar eventos para suas ferramentas de segurança existentes. Esta abordagem permite-lhe incluir resultados do Falco no Azure Sentinel e trabalhar com agentes de IA para ajudar a identificar problemas que podem não ser abrangidos pelas próprias regras do Falco.

Como o Falco funciona em um nível baixo e rastreia o escalonamento do serviço, ele se parece mais com uma ferramenta de observabilidade do que com um monitor de segurança tradicional. Degioanni pensa em Falco como uma pergunta: “O que significa garantir algo que é tão dinâmico e que muda tanto?”

Trabalhar com o Kubernetes como um orquestrador de microsserviços também aumenta a complexidade. Degioanni descreve o desafio:

Os usuários têm 500 contêineres em uma única máquina com talvez 96 núcleos. Se você tiver que colocar algo dentro de tudo isso e eles subirem e descerem, você sabe, então é absolutamente inviável. Então, o que fazemos é… a sonda Falco vai para o kernel do sistema operacional. Portanto, não importa quantos contêineres você tenha nesta máquina de 96 núcleos, você terá apenas uma instrumentação. E quando um contêiner sobe e desce, você não precisa esperar que sua instrumentação esteja ativa nesse contêiner porque ela já está ativa no kernel subjacente.

A maneira mais fácil de instalar software no Serviço Azure Kubernetes é usar o Helm. A comunidade Falco mantém um gráfico Helm que instala o Falco como um DaemonSet do repositório Falco GitHub. Essa abordagem permite automatizar a implantação usando Azure DevOps ou GitHub Actions. Realmente não faz sentido pensar em implantações manuais, pois você usará o Falco como parte de uma infraestrutura idempotente, onde cada nova implantação substitui a anterior.

Instalar o gráfico Falco Helm é bastante fácil. Basta executar o gráfico de seu repositório, criando um namespace Falco em seu cluster e configurando instâncias em seus nós. Se você estiver executando o Falco como um DaemonSet, deverá haver um pod Falco por nó, usando o tempo de execução do contêiner atual.

Executando Falco em hosts Kubernetes

Se, em vez de usar o Serviço Azure Kubernetes, você estiver configurando seu próprio ambiente Kubernetes no Azure, poderá instalar o Falco no sistema host, isolando-o da instância do Kubernetes que está monitorando. Os alertas ainda são gerenciados dentro do Kubernetes, mas uma instalação baseada em host oferece uma alternativa no caso de um comprometimento grave. A equipe Falco fornece instruções de instalação para diferentes versões do Linux, tanto distribuições baseadas em Debian como Ubuntu quanto distros baseadas em Red Hat. Há suporte para ARM e também para x64, para que você possa aproveitar as vantagens dos novos servidores Azure de alta densidade baseados em ARM da Microsoft.

Esta tabela e o arquivo values.yaml listam os parâmetros configuráveis ​​do Falco. Eles são usados ​​para controlar como o serviço funciona, por exemplo, gerenciando os drivers usados ​​para hospedar sondagens e as APIs usadas para entregar dados a serviços externos.

Outra característica do gráfico Falco Helm é o seu conjunto de regras padrão. Isso irá ajudá-lo a começar, mas à medida que seus aplicativos Kubernetes crescem e você ganha mais experiência na execução de segurança nativa da nuvem, você pode adicionar suas próprias regras personalizadas em seu próprio arquivo, mencionado no gráfico de instalação.

As regras do Falco são escritas em YAML e podem referir-se a conjuntos de regras adicionais. Por exemplo, você pode garantir que seu aplicativo use apenas portas definidas ou que possa gerar apenas processos conhecidos e específicos. Qualquer coisa que aconteça fora das regras padrão e personalizadas acionará um alerta.

Alimentando o monitor de segurança

Se você já estiver usando uma ferramenta de segurança do Azure como o Sentinel, adicione o Falcosidekick à sua instalação. Esta é uma extensão oficial que ajuda a gerenciar alertas, entregando-os ao Azure Event Hub e ao seu SIEM (gerenciador de eventos e informações de segurança). De forma útil, o sidekick inclui a capacidade de adicionar campos personalizados aos alertas, permitindo adicionar detalhes do cluster Kubernetes que envia o alerta. Isto é importante quando você monitora vários clusters, executando aplicativos diferentes em cada cluster ou replicando aplicativos geograficamente nas regiões do Azure.

Outras ferramentas permitem que você se conecte ao serviço gerenciado do Azure Monitor para Prometheus, que permite usar o Grafana para criar e executar painéis que fornecem informações de segurança à sua equipe de secops.

Por que usar o Falco em vez de outras ferramentas de segurança do Kubernetes? A resposta é simples: o Falco é capaz de identificar novos padrões de ataque que podem não ser visíveis para outras ferramentas. Quer um invasor opere como uma ameaça lenta e persistente ou tente uma rápida exfiltração de entrada e saída, compreender que ocorreu uma intrusão permite que você responda rapidamente, bloqueando o acesso ou iniciando ações forenses mais complexas, ao mesmo tempo que bloqueia esses novos comportamentos inesperados.

Interrompendo o dia zero nativo da nuvem

Ao usar testes eBPF para identificar atividades desconhecidas no nível do kernel, o Falco mantém você informado sobre possíveis explorações de dia zero em seu código. As regras podem ser escritas para alertá-lo sobre atividades que não fazem parte da linha de base do seu aplicativo e que não são cobertas pelos conjuntos de regras existentes. Assim, o Falco oferece um resumo que cobre ações anteriormente não vistas – o que pode indicar bugs em seu código ou nas operações de um agente de ameaça.

No entanto, não faz sentido implantar o Falco por conta própria. O Azure tem as suas próprias ferramentas de segurança que funcionam com o Falco para fornecer uma abordagem em camadas para proteger o seu ambiente Kubernetes. O Falco não foi projetado para funcionar com aplicativos .NET ou para monitorar Redis ou PostgreSQL, portanto você precisará trabalhar com todas as ferramentas disponíveis para proteger seus serviços.

Alimentar um SIEM com todos os sinais do seu ambiente de aplicação é fundamental. Você precisa ser capaz de trabalhar com o Falco e todas as suas outras ferramentas de monitoramento para entender o que é um ataque e o que é uma falha e adaptar suas respostas de forma adequada. Agora que o Falco se formou para se tornar um projeto CNCF completo, integrado à pilha da plataforma Kubernetes, podemos começar a juntar essas peças e construir aplicativos nativos da nuvem seguros e confiáveis, tanto no local quanto na nuvem.