Qual o problema?

Grande parte do desenvolvimento de software acontece de forma local, nas máquinas dos desenvolvedores. Seja Windows, Mac ou Linux, uma coisa não muda, conforme você cresce o seu sistema, o consumo da capacidade computacional também aumenta.

Essa “limitação” e necessidade de capacidade computacional limita o que os desenvolvedores podem fazer, limitando inclusive engenheiros que estão em início de carreira e não tem a possibilidade de ter uma máquina robusta para colocar em prática seus aprendizados.

A popularização dos LLMs e dos agents também trouxe luz a essa particular situação. Os engenheiros se encontram limitados na utilização dessas tecnologias pela necessidade de se ter um dispositivo de placa de vídeo em suas máquinas, dispositivo esse obrigatório para execução desses modelos. A única alternativa para isso é a utilização das plataformas em nuvem (Azure, AWS, GCP, etc.), que ofertam servidores com placas de vídeo de forma on-demand e de diversos tamanhos. Nesse caso, o problema é só o preço, que pode sair bem salgado ao final do mês.

Tendo em mente todos esses problemas, Offload ao resgate!

Offload

falar sobre a proposta, como agora até alguém com computadores antigos e sem capacidade pode usufruir do poder do docker e o aumento da possibilidade de criação de soluções AI e ML based sem a existencia de uma GPU no computador

O Docker Offload foi criado com a proposta de oferecer aos engenheiros, desenvolvedores e usuários de Docker uma forma de executar seus contêineres sem fazer uso da sua capacidade computacional local.

Tudo que você precisa fazer é trocar de workspace (do seu local para o Offload), isso pode ser feito no toggle presente ao lado do logo do Docker Desktop. Uma vez no workspace do Offload, você pode criar seus contêineres exatamente da mesma maneira que faria no ambiente local, executando o seguinte comando:

docker run <IMAGE>

Seu contêiner será criado e você poderá utilizá-lo como já está acostumado!

Como funciona?

Tudo ocorre com uma conexão SSH por trás dos panos, estabelecida pelo Docker Desktop com um Docker Daemon que está sendo executado na nuvem. Todas as atividades que você executar referentes aos contêineres e ao ambiente Docker será feita na instância do Offload executada em cloud, isso até que você altere para seu workspace local novamente.

Facilitando a manutenção do ambiente, a cada 30 minutos de inatividade, o ambiente do Offload é limpo e fechado, garantindo economia de recursos e de custos (a partir do momento em que o free tier tenha sido esgotado).

Essa abordagem permite manter o seu ambiente bem organizado e otimizado, alocando os recursos apenas quando necessário e evitando desperdício.

Usando

A utilização da plataforma é bem trivial e como vimos anteriormente, funciona da mesma forma que o Docker local.

Uma vez habilitado seu workspace, você poderá executar seus contêineres de forma livre e sem complicações. Caso esteja utilizando apenas a linha de comando, você pode habilitar o Offload através do seguinte comando:

docker offload start

Seu workspace será movimentado para o ambiente do Offload, não havendo a necessidade de se realizar mais nenhuma ação.

Caso queira encerrar sua seção, um simples:

docker offload stop

Cumprirá a ação.

Simples, né?

AI & ML Everywhere!

Não podíamos deixar de falar de Inteligência Artificial, o tema do momento (e dos últimos 3 anos)!

A popularização da AI, dos modelos de ML, MCP e dos agentes também chegou no ecossistema Docker. O Docker MCP foi anunciado há algumas semanas e com a estratégia de expandir ainda mais o uso dessas capacidades para os engenheiros, o Docker Offload permite que os engenheiros usufruam dos poderes das GPUs NVIDIA L4 de forma gratuita e simples.

Para fazer uso dessas capacidades gráficas da infraestrutura, ao iniciar o workspace do Docker Offload, você será questionado se necessita de suporte para GPU. Ao marcar que sim, seu ambiente estará apto para receber seus workloads de ML e AI!

Oportunidade

Para que você comece a utilizar o Docker Offload sem a preocupação de ter custos atribuídos em seu cartão de crédito, a plataforma oferece 300 minutos GRATUITOS para você executar seus contêineres e modelos de machine learning.

Não existe desculpa para não aproveitar essa plataforma e tudo que ela nos fornece. Entre de vez no mundo da inteligência artificial, machine learning e agentic AI!

O Offload é muito mais do que um novo produto, é uma nova forma de fazermos tecnologia.

Use e abuse dessas capacidades!

Obrigado, time Docker 💙

Pensando do ponto de vista do desenvolvedor, a responsabilidade deste profissional gira em torno de:

• Atender as demandas de negócio, criando serviços e funcionalidades que permitam a “tradução” da regra de negócio.

• (periodicamente) auxiliar no design da solução, fornecendo insights e trabalhando com staff engineers, arquitetos de solução e outros engenheiros na construção da arquitetura.

• Construir código “bem escrito”, seguindo as boas práticas de engenharia, guardrails de qualidade e segurança da empresa em que trabalha.

• Realizar manutenção nas bases de código existentes no ambiente, sejam elas de sua autoria ou da autoria de outros engenheiros.

Nós, profissionais de segurança, sabemos que até o melhor dos engenheiros está sucetível ao erro. Nós também estamos. Por isso existem os controles, para “pegar” o que os olhos humanos não pegaram.

Dito isso, os controles implementados nas pipelines de DevSecOps são para evitar que erros não vistos e escondidos dentro da aplicação, passem despercebidos. Não é por desconfiança no trabalho dos desenvolvedores e dos times de engenharia de software que esses controles existem, eles servem como aliados dos desenvolvedores, que uma vez que recebem o rápido “feedback” das ferramentas de qualidade, podem ajustar seus entregáveis.

Controles

Sabemos que esses controles existem, mas afinal de contas, o que são eles? Para que servem? O que analisam?

SCA - Software Composition Analysis

Como todo código hoje em dia faz uso de bibliotecas externas e de SDKs para integrações com os mais diversos service providers do mundo, é crucial que essas relações de dependência com fornecedores externos seja mapeada e esteja visível.

As ferramentas de Software Composition Analysis auxiliam nesta atividade, fazendo um scanning nas bibliotecas e avaliando a conformidade com o licenciamento das mesmas.

Ferramentas de mercado: Snyk e WhiteSource

XAST - X Application Security Testing

Agora vamos comentar de uma série de ferramentas que fazem análise do código escrito de maneiras diferentes. Os acrônimos mencionados abaixo são frequentemente mencionados nas conversas entre os times de DevOps, pois representam um pilar muito importante na cultura de segurança de uma empresa, o de Segurança de Código.

Essas ferramentas são utilizadas em momentos diferentes do ciclo de desenvolvimento de software, oferecendo insights diferentes em cada um desses momentos, insights esses que fazem com que o desenvolvedor compreenda melhor o comportamento da aplicação dele mediante determinados cenários.

Essas análises diferenciadas habilitam a redução da superfície de ataque das aplicações, dado que os cenários avaliados são mais extensos e permitem a captura mais precisa de falhas de segurança.

SAST - Static Application Security Testing

Aqui temos a primeira validação do código escrito pelo engenheiro. A análise será feita de forma estática, com o código sem compilação, do jeito que está no repositório.

Essa primeira análise busca por erros “comuns” presentes no código fonte, erros como SQL Injection e Cross-Site Scripting são capturados antes que possam expor a aplicação à falhas graves de segurança.

Ferramentas de mercado: SonarQube e Fortify

DAST - Dynamic Application Security Testing

Após a análise do SAST, temos o DAST, que faz seu scanning após a compilação da aplicação.

As falhas aqui identificadas são mais sofisticadas e de difícil captura. Aqui, todo o contexto é levado em conta, não apenas o código escrito pelo usuário.

Os problemas aqui identificados costumam ser mais complexos e caros de se corrigir, visto que há a necessidade de se fazer toda uma análise nos componentes da aplicação para alterar seu funcionamento, mitigando a vulnerabilidade. Esse trabalho costuma ser feito em conjunto com os times de arquitetura, que precisam compreender as ligações entre os componentes para evitar que essa vulnerabilidade se espalhe para outras aplicações.

Ferramentas de mercado: Burp Suite

IAST - Interactive Application Security Testing

Tudo que falamos das ferramentas anteriores é integrado em uma só, com o IAST!

Essas soluções visam capturar com mais precisão e efetividade os problemas de segurança identificados nos passos anteriores. Essa precisão nos ajuda a validar as identificações, que muitas vezes podem ser o que chamamos de “falsos positivos".

Com casos de uso definidos, a ferramenta configurada fará a análise de uso da aplicação, validando se as vulnerabilidades são verdadeiramente exploráveis.

O uso computacional de uma ferramenta de IAST é muito mais alto do que o das ferramentas anteriores, muito por sua complexidade, robustez e cobertura, portanto é crucial que sua solução de IAST esteja bem parametrizada e com seus workflows bem definidos.

Ferramentas de mercado: Seeker

Secret Scanning

Agora já não estamos mais falando de como o código está escrito, mas sim o que está contido nele.

Na era da segurança, toda chamada deve ser autenticada e autorizada, garantindo que apenas o “dono” de um recurso tenha acesso a ele.

Essas camadas de segurança apresentam certa complexidade na escrita do código, visto que muitas vezes o engenheiro precisa trabalhar com múltiplas credenciais com o propósito de validar as chamadas ao ambiente.

Para evitar que credenciais sejam enviadas aos repositórios de código, as pipelines devem implementar controles para identificar possíveis credenciais “mockadas”, que possam ser vazadas ao público uma vez que o repositório não esteja bem protegido.

Essa análise pode ocorrer em diversas etapas do processo, tanto nas automações, quanto diretamente no repositório de código, através do uso das capacidades avançadas da sua plataforma. Utilizar um ecossistema como o presente no GitHub, permite que o administrador da ferramenta tenha uma visão completa dos repositórios que contém algum tipo de credencial salva. Essa visão permite a criação de workflows de notificação aos owners dessas aplicações como também o estabelecimento de guardrails, que podem evitar que códigos com credenciais embutidas sejam enviados aos repositórios das mesmas.

Ferramentas de mercado: GitHub Advanced Security e GitGuardian

Indo além das ferramentas

Ferramentas são ótimas e nos permitem passar ao ambiente uma visão esperada pelos times de segurança da empresa, porém nem sempre temos facilidade para modificá-las.

Como qualquer plataforma, ao ser selecionada, o time responsável por ela se encontra em uma gangorra, que equilibra a capacidade de personalização daquela ferramenta e o custo de operacionalização da mesma.

Quanto mais personalização, mais complicada de se manter, porém com mais possibilidades.

Menos personalização significa menos possibilidades, contudo, mais facilidade na manutenção.

No final das contas as ferramentas não são nada além de softwares. Softwares esses que podem conter vulnerabilidades e falhas, como as aplicações que nós escrevemos.

Para aumentarmos ainda mais a superfície coberta do nosso ambiente, é crucial que os times de engenharia de plataforma e segurança façam um trabalho de “evangelização” dos desenvolvedores da sua empresa. É necessário que eles não só entendam a necessidade e os controles implementados, mas também que saibam receber o feedback dessas plataformas.

Além disso não podemos virar nossas costas aos treinamentos. Melhor que um cenário onde você encontre desenvolvedores despreparados e ferramentas bem configuradas, é quando achamos ferramentas bem configuradas e desenvolvedores BEM CAPACITADOS. Desenvolvedores esses que melhoram seu código escrito a cada semana que passa, utilizando da análise das ferramentas e dos treinamentos fornecidos como seus aliados na construção de uma melhor plataforma.

Cursos externos, playlists no YouTube, treinamentos internos ministrados por especialistas no assunto, plataformas de codificação, artigos na internet, tudo que possa servir como fonte de conhecimento para o desenvolvedor deve ser considerado. Essas capacidades devem ser passadas aos novos engenheiros (ingressantes na empresa e estagiários efetivados) e aos experientes, oferecendo a eles a possibilidade de fornecimento de feedback para melhoria dos materiais. Os insumos também devem ser atualizados de maneira frequente, para que sempre correspondam aos controles recomendados pela empresa.

Não é só uma ferramenta de SCA ou SAST que fará com que o seu ambiente esteja seguro e protegido de vulnerabilidades. O verdadeiro shift-left começa com o seu desenvolvedor sabendo o que está fazendo!

Mesmo no momento em que nos encontramos hoje, com o crescimento cada vez maior de ferramentas de inteligência artificial e popularização do vibe coding, quem coloca o código em produção é o desenvolvedor, não o “robô". Não há melhor controle do que um engenheiro que sabe o que faz. Te poupará dores de cabeça no curto, médio e longo prazo.

Invista nos seus engenheiros!

Nos vemos em breve com mais conteúdo sobre security!

Até logo! :)

O que é?

Sabemos que ao construirmos uma aplicação contêinerizada, temos que começar com algo. Nossa aplicação e suas dependências devem ser instaladas e configuradas em alguma coisa. Esse alguma coisa é uma Imagem Base.

Como o próprio nome já diz, nosso contêiner será inicializado com essa imagem, que por sua vez receberá todas as instruções declaradas posteriormente no arquivo de configuração (como um Dockerfile, por exemplo).

Abaixo temos um exemplo do início da configuração de um Dockerfile que mostra exatamente onde declaramos a imagem base da nossa aplicação.

FROM alpine:latest AS base

Após inicializarmos o contêiner com essa imagem base, vamos passar para todos os outros passos.

• Copiar os arquivos da aplicação.

• Instalar dependências.

• Passar argumentos e variáveis de ambiente.

Todo esse processo tornará a imagem final do contêiner muito mais complexa, visto que a mesma terá uma série de outros componentes dentro de si.

Conforme vamos adicionando essas “camadas”, não é apenas a complexidade da nossa aplicação que vai crescendo, mas também sua superfície de exposição, visto que a versão do framework que você está utilizando também tem vulnerabilidades já conhecidas, somadas as libs e outros componentes instalados para que sua aplicação funcione, no final da construção do arquivo teremos uma lista imensa de vulnerabilidades e de preocupações, que precisarão ser direcionadas.

Para garantir as aplicações executadas em seu ambiente estejam bem mapeadas e que não apresentem nenhum grande risco ao contexto maior da sua plataforma, integramos em nossos workflows uma ferramenta de Image Scanning, como o Docker Scout e Aqua Trivy.

Por quê utilizar?

Se pensarmos em todo o ciclo de desenvolvimento de software e como hoje em dia as empresas trabalham em um modelo distribuído, as capacidades de segurança também tiveram que se modernizar e passaram a ser construídas de forma decentralizada. Os times de segurança e plataforma ainda as controlam e parametrizam porém o primeiro contato do desenvolvedor/engenheiro com um recurso PRECISA ser um contato seguro, caso contrário temos mais uma demonstração de abertura de brecha no ambiente.

Acima temos um desenho simples sobre como funciona uma pipeline CI/CD. No terceiro passo, que é de fato onde o build da aplicação se inicia, a pipeline buscará no arquivo de configuração os recursos apontados.

Dentro de uma organização, é importante deixar claro que JAMAIS deve-se buscar imagens diretamente da internet. Os requisitos de segurança são variados de acordo com a criticidade dos serviços que sua empresa presta e acima de tudo devem ser modificados pelos times de segurança, compliance, auditoria e jurídico. Dito isso, as imagens utilizadas de forma corporativa devem passar por um extenso processo de análise, que visa garantir a qualidade do artefato inicialmente utilizado.

E essa é um dos momentos que entra o nosso image scanning.

Acima, um print retirado diretamente da console do Docker Desktop rodando o Docker Scout. Podemos visualizar na esquerda as duas camadas que essa imagem contém e à direita todas as dependências dela, bem como suas vulnerabilidades.

Essa visão nos permite entender o estado em que aquele recurso se apresenta e à partir do apetite a risco da sua organização, qual será a origem dele.

Mesmo podendo ser utilizado dessa maneira, o image scanning não costuma estar “na mão” dos engenheiros de software, mas sim nos times de Plataform Engineering e Segurança, isso sem falar das integrações através das pipelines, que falaremos sobre agora!

CI/CD Integration

O primeiro scanning que falamos é extremamente necessário para criarmos a base da nossa pipeline, que é: fornecer imagens base seguras e com vulnerabilidades controladas/aceitas pela empresa em questão.

Ao longo do processo de build, as dependências serão instaladas no contêiner e no final da execução, um “pacotinho” será gerado, que contém a aplicação autossuficiente (com tudo que ela precisa para ser executada). Esse pacotinho deve mais uma vez ser analizado pelo nosso image scanner para avaliar algum problema de configuração que possa ter passado em branco.

No final do ciclo, sua imagem conterá tudo que precisa para ser executada e esse é o motivo da segunda validação.

Nós passamos de uma image base, que já continha algumas dependências e possivelmente vulnerabilidades, para uma imagem “carregada” e com vários outros componentes adicionados. A única forma de garantirmos a boa proteção das nossas imagens é realizar essa validação em camadas, garantindo sempre que pelo menos uma validação tenha sido feita nas novas adições daquele componente.

Dentro de uma pipeline, a análise da imagem estará próxima do final do ciclo de execução da mesma, fornecendo em grande parte das vezes um score que nos permite determinar se aquele insumo está seguro ou não para ser utilizado.

Container security é crucial para que sua estratégia de cloud security seja efetiva. Visto que hoje tudo é contêinerizado, é de extrema importância que você proteja bem sua plataforma.

Espero que tenha gostado do texto. Nos vemos no próximo!! :)

Há mais de 40 anos o ecossistema open source vem impulsionando a evolução técnológica das empresas e das comunidades, trazendo novos padrões de mercado e mudanças que mudaram completamente a forma com que fazemos tecnologia. Contudo, muitas empresas ainda interpretam o tema como um risco. Será que é mesmo?

Nós já estamos beeeeeeem distantes da época em que open source não era seguro. Hoje não só as maiores empresas do mundo baseiam suas arquiteturas em soluções open source e cloud native como também temos diversas iniciativas que garantem a boa qualidade e os padrões de segurança dos projetos da comunidade, como a OpenSSF.

Ao pararmos para analisar, tudo que é cloud hoje veio do Linux. Servidores, storage, contêineres, Kubernetes!!!! Se este pensamento relacionado a falta de segurança em projetos OSS fosse verídico, estaríamos muito atrasados em tudo que fazemos hoje, então vamos esquecer esse estigma.

Ótimo, mas e a escalabilidade? O quão escalável é a aplicação de soluções OSS dentro das grandes organizações?

Integração

A utilização dessas soluções pode ser feita de forma descentralizada ou centralizada, alocando uma equipe para a governança desses projetos.

Pensando no ciclo de vida da solução dentro da sua empresa, é interessante que seja feito um trabalho de popularização do uso daquela ferramenta.

Com a construção de templates, documentações e com uma boa estratégia de comunicação, outros times internos poderão usufruir da ferramenta e herdar os benefícios notados no momento de sua adoção.

No longo prazo, essa cultura engaja mais engenheiros no tema open source e potencializa a capacidade de contribuição da empresa e do projeto, dado que a experiência de implantação somado ao domínio técnico, permitirão que os engenheiros proponham novas features, reportem issues e auxiliem no desenvolvimento e solução das mesmas.

Do ponto de vista de governança, a existência de uma equipe centralizada ou de um CoE (Center of Excellence) permite a rápida atuação em cenários onde a mesma se faz necessária. Resposta a incidentes produtivos, identificação de vulnerabilidades e oportunidades de melhora são pontos frequentemente notados pelos times de engenharia e que serão direcionados de forma muito mais efetiva com a existência de uma liderança direcionada para open source.

Agora que a minha empresa passou a adotar soluções open source em seu landscape de tecnologia. Há algo mais para se fazer?

SIM! Devolver para a comunidade.

Corporate x Community

Do ponto de vista da empresa usuária do projeto, as preocupações variam de acordo com o segmento da companhia, porém sempre estarão em torno dos seguintes pontos:

• Processo legal - relacionado diretamente ao licenciamento do projeto. A empresa deve garantir que não sofrerá ações legais por conta do uso indevido da solução.

• Segurança - diferente do que comentamos no início do texto, essa referência à segurança é comum em soluções open source e prioritárias. Vulnerabilidades encontradas nas soluções precisam ser mitigadas com pressa, para evitar danos a imagem e reputação da empresa.

• Gerenciamento - por serem ferramentas sem gerenciamento, toda a responsabilidade de manter os sistemas rodando fica com a empresa. Isso não é um problema, porém será necessário infraestrutura e mão de obra para essas atividades.

• Versionamento - projetos open source costumam ter releases frequentes de novas versões, o que torna responsabilidade completa da empresa de manter os sistemas atualizados e com os devidos patches aplicados.

Contudo, nesse “jogo” não há apenas a empresa. Não podemos nos esquecer da comunidade, que é quem mantém os projetos de pé, implementa funcionalidades novas e responde à vulnerabilidades e incidentes.

A grande parte desses desenvolvedores fazem esses trabalhos em seu tempo livre, por hobby e por acreditar nos projetos. São poucos os projetos que tem incentivos para influenciar no desenvolvimento.

Dito isso, é extremamente importante que haja um retorno das empresas para a comunidade, permitindo assim que mantenhamos a saúde dos projetos e a comunidade engajada.

Esse incentivo pode vir de diversas formas:

• Financeiro - apoio (patrocínio) aos desenvolvedores e mantenedores do projeto.

• Suporte - empresas auxiliam com os custos ligados ao projeto (infraestrutura, licenças para ferramentas, etc.).

• Contribuição

  • Direta - algumas empresas já adotaram a postura de permitir que seus engenheiros contribuam diretamente das contas e ambientes corporativos para projetos open source. Isso geralmente exige uma série de camadas de segurança para proteção dos ativos da empresa e mitigação de possíveis vazamentos de dados.

  • Indireta - membros da comunidade são incentivados por suas empresas a contribuírem para os projetos, porém não podem utilizar sua identidade corporativa. Esse é o passo anterior a total integração das empresas no ecossistema.

• Project Ownership - esse é um modelo de contribuição mais raro, onde a empresa doa um projeto (ou mais) para a comunidade. O core de mantenedores pode ainda ser o mesmo, porém o código foi aberto e disponibilizado para a comunidade.

Essas contribuições partindo das empresas mantém o ecossistema saudável e funcional e influencia outros players do mercado a fazerem o mesmo.

Nós, engenheiros e engenheiras, precisamos voltar a cobrar as nossas empresas dessa devolução para a comunidade e para o ecossistema. Como vimos, os incentivos podem ser realizados de diversas maneiras, porém é importante que eles sejam feitos!

Conclusão

A grande verdade é que open source pode (e deve) ser MUITO considerado como estratégico para sua empresa. Dar liberdade para que os engenheiros testem e experimentem soluções novas é a melhor forma de fazer com que seu ambiente se torne mais maduro e inovador.

Como tudo na área de tecnologia, temos um trade-off. A integração da sua empresa com a comunidade open source deve ser avaliada de acordo com o seu cenário e a partir daí, as possibilidades devem ser exploradas. Os projetos precisam de apoio e é certo que uma hora ou outra, a conta dessa falta de contribuição, vai chegar.

O importante é começarmos a engajar cada vez mais as empresas para manter o nosso ecossistema “afiado” como estamos acostumados a ver.

Muito obrigado e até logo! <3

Motivadores

Como comentado brevemente na introdução do artigo, uma boa parcela dos sistemas web que estão em execução hoje em dia rodam em ambientes Microsoft, especialmente em ambientes windows.

Dito isso, as razões que você pode considerar para executar containers windows em um ambientes kubernetes irão variar conforme as necessidades do seu negócio, ficando a seu critério a tomada de decisão referente ao direcionamento de uso dessa arquitetura.

Um motivador muito comum para escolha dessa arquitetura é a falta de tempo para reformulação de uma aplicação que hoje já é executada em ambiente Microsoft e que sofreu certo tipo de evolução, atingindo a marca de ser containerizada. Executar essa aplicação em kubernetes pode trazer benefícios que um monolíto em um windows server não poderia fornecer, como a capacidade de escalabilidade horizontal.

Outro ponto também importante e frequentemente considerado na tomada de decisão é o uso de biblioteca do sistema. Caso sua aplicação utilize funcionalidades fornecidas a nível de sistema operacional, executar sua aplicação em um ambiente linux retirará recursos essenciais para o funcionamento do serviço, a não ser que seu código tenha sido previamente refatorado.

Em grandes empresas, onde o parque tecnológico é muito grande, é comum vermos diversas tecnologias diferentes sendo utilizadas para o mesmo propósito. Para reduzir essa complexidade, utilizar um orquestrador centralizado poderá economizar muita dor de cabeça dos times de tecnologia.

Características técnicas

Como qualquer outra solução, os containers windows tem suas particularidades. Já há algum tempo, o ecossistema do kubernetes foi preparado para permitir a execução de containers windows, garantindo o suporte da solução.

Para habilitar essa execução o primeiro passo é ter em seu cluster nodes que executem o sistema operacional windows. Esse é um pré requisito extremamente necessário dado que não será possível executar seu container sem ele.

Tendo em mente uma arquitetura produtiva que faça uso de nodes windows e linux, é interessante separar os nodes do seu cluster de alguma forma que permita que o seu time consiga identificar qual o sistema operacional executado naquele node, evitando dessa forma muita dor de cabeça em cenários de troubleshooting.

Uma solução para esse cenário é utilizar nos nodes os chamados node taints, que nos permitem taggear os nodes conforme desejado e selecionarmos através das labels onde desejamos que as aplicações tenham o deployment feito.

Com os nodes taggeados podemos utilizar no scheduling dos pods os Node Selectors, que nos permitirão selecionar quais hosts deverão receber aqueles pods. No cenário apresentado, os nodes selecionados serão os que tem como sistema operacional o windows.

Outros pontos para ficar de olho

Os reais motivadores para se utilizar containers windows em ambientes kubernetes já foram discutidos, mas de forma resumida, eles são “pessoais”, devendo ser determinados dentro da sua organização.

O que nós não podemos deixar de comentar é: existem diferenças que não podem ser deixadas de lado.

A construção de sistemas que utilizam como base um ambiente linux é totalmente diferente dos que utilizam ambientes windows. Não são todas as funcionalidades que estão disponíveis e as APIs não foram completamente estendidas.

Consultando diferentes fóruns na internet, algumas das diferenças mais notáveis são:

• Permissionamento em arquivos - é configurado em um modelo de ACL (Access Control Lists).

• File path - (quem nunca teve problema com isso, rs) onde utilizando windows, representamos os paths com a barra ao contrário (\).

Esquecendo um pouco esses pontos de atenção, gostaria de mencionar o incentivo que a comunidade vem tendo para evoluir esse cenário. Constantemente me pego lendo as releases notes das novas versões do kubernetes e frequentemente encontro menções a novas features que foram implementadas e que tem suporte para ambientes windows containerizados.

Portanto, independente do quão polêmico é o uso de windows em kubernetes é importante sabermos que a cada dia que se passa, essa combinação de tecnologias se torna ainda mais viável, abrindo as possibilidades para os mais diversos cenários que podemos encontrar!

Por menos convencional que seja, os containers Windows apresentam uma alternativa a execução de workloads em ambientes kubernetes. Você não precisa necessáriamente os utilizar, porém é interessante conhecer a possibilidade, que pode vir a ser útil a qualquer momento.

Muito obrigado por acompanhar até aqui, caso tenha alguma dúvida não deixe de me contatar.

Até logo!

Sobre o evento

A KubeCon + CloudNativeCon é o principal evento de tecnologia open source e vendor neutral do planeta. Tendo edições na américa do norte, europa, Índia, China e (agora) Japão, a conferência tem como seu principal propósito trazer a comunidade de tecnologia para um ambiente de respeito, colaborativo e extremamente engajado.

No evento você encontra pessoas de todos os backgrounds, técnicos, não técnicos, DevOps, SRE, Software Engineers, QAs, Designers, Arquitetos entre outros cargos. Devido sua diversidade de participantes e de conteúdos, todo mundo tem algo a fazer a todo momento!

Em relação ao conteúdo técnico, temos palestras de todos os níveis. Palestras avançadas, para iniciantes, workshops e demos ocorrem o tempo todo. Além de toda a seção de palestras, que ocorre de maneira simultânea em diversas partes do centro de conferência onde é hospedado o evento, ainda há o Project Pavillon e o Solutions Showcase, que servem para conectar a comunidade com os maintainers dos projetos e contribuidores das empresas participantes.

Por mais que as palestras sejam simplesmente fantásticas e a todo momento você esteja aprendendo algo novo, a melhor parte do evento é a conexão com outros membros da comunidade. Conhecer outras pessoas, fazer novos amigos, aprender coisas novas com colegas de diferentes culturas e diferentes históricos é algo que realmente não tem preço. Nessas conversas você conhece alguém que trabalha na empresa dos seus sonhos, ou que teve uma mudança brusca de carreira, que superou dificuldades parecidas com as suas, que conquistou coisas que você também deseja conquistar, e é exatamente esse o propósito do evento, a COMUNIDADE.

Essa foi a principal mensagem que trouxe para mim da minha primeira KubeCon e que com certeza absoluta levarei para os próximos eventos que fizer parte.

Agora, vamos ao técnico…

Hot topics

O evento tem apenas dois temas (que se complementam), cloud native technologies e open source. Todos os temas abordados ao longo das palestras falam sobre soluções open source que vem mudando a forma com a qual construímos nossos sistemas em nuvem.

A lista de temas vai de observabilidade a testes, de segurança a developer experience, e somados a esses, temos uma série de outros tópicos que foram explorados.

Abaixo farei uma lista com alguns temas que pude extrair o máximo dos conteúdos compartilhados.

Observabilidade

Nós que trabalhamos com DevOps, SRE e desenvolvimento temos plena consciência da necessidade de termos uma boa estrutura de observabilidade em nosso ambiente. Sem observabilidade não há vitória!

No landscape de soluções cloud native temos uma série de ferramentas de observabilidade que já estão consolidadas no mercado e que representam boa parte da stack utilizada por grandes empresas.

Com o surgimento cada vez mais rápido de ferramentas de observabilidade proprietárias, que consequentemente aplicam seus próprios padrões, a expansão do OpenTelemetry aparece como um alívio.

Seus componentes tem ampla contribuição da comunidade e com toda certeza, OpenTelemetry is the way to go!

Seu uso tem se tornado o padrão de mercado para arquiteturas de observabilidade, por conta de sua flexibilidade, por ser agnóstica a provedores e principalmente por definir padrões de nomenclatura, métricas e de outros recursos.

Ficou claro durante o evento que todas as soluções de observabilidade daqui para frente utilizarão o OpenTelemetry como um padrão para suas aplicações. Para provar essa ampla adoção do padrão, empresas como Grafana e Datadog já publicam e contribuem de maneira pública para o repositório da solução.

GitOps/IaC

Com ambientes cada vez mais complexos e difíceis de se gerenciar, tem se tornado claro que precisamos de controle dos nossos artefatos mais do que nunca. Não existe mais um mundo onde os deployments nos clusters não são mais feitos através de pipelines.

Tudo isso já tem sido reforçado há anos na comunidade, porém enxergar a forma que projetos como Argo, Flux e Open Tofu vem crescendo, mostra que precisamos sempre repensar na forma como estamos utilizando esses recursos.

No mundo da engenharia de plataforma (e também do DevOps), habilitar aos desenvolvedores a rápida criação de seus artefatos, possibilitando a entrega de valor mais rápida ao cliente e diminuindo o trabalho dos times de engenharia, tem sido possível pela utilização das ferramentas anteriormente mencionadas.

A reutilização dos artefatos criados para os times de engenharia é uma prática que deve ser considerada obrigatória. Habilitar que outras equipes possam consumir os insumos já produzidos de forma que possam realizar a criação de seus recursos cada vez mais rápido, trará benefícios não apenas locais na empresa, mas também criará uma cultura de colaboração entre os times, tornando-os ainda mais poderosos.

IA

IA é o assunto do momento há alguns anos, porém não era um tema constantemente abordado quando falávamos de kubernetes. Até agora.

Um ponto interessante abordado de forma ampla no evento foi a ampliação no uso de soluções como Kubeflow, que permite a execução de workloads de machine learning em clusters kubernets de forma nativa.

Nessa mesma linha tivemos também a divulgação do suporte de provedores de nuvem pública a imagens de VMs que tem o uso de GPUs habilitadas e que possibilitam a criação de clusters nessas máquinas.

Com essas evoluções, o treinamento de modelos de machine learning em ambientes cloud native se tornou muito mais eficiente e difundido, possibilitando que todos, independente do tamanho e dos recursos, pudessem treinar seus modelos e construir suas soluções.

Edge Computing

Borda tem sido um tema extremamente relevante no mundo das empresas de telecomunicações por pelo menos 10 anos. A crescente quantia de dispositivos móveis que executam processamentos complexos na palma da mão dos clientes tem sido um chamado para a garantia de uma infraestrutura que suporte todo esse processo e sustente todas essas estruturas com a garantia da não interrupção do serviço.

Dito isso, kubernetes on edge foi um tema bastante abordado. Soluções como KubeEdge e k3s foram amplamente faladas por sua elasticidade e eficiência, possibilitando que as empresas processem largas quantias de dados e tornem a experiência do usuário cada vez mais personalizada, com tecnologias eficiêntes onde quer que esteja.

A ampliação do uso desses recursos possibilitarão uma evolução mais rápida nas indústrias automotivas e de telecomunicações, que tem sua malha de dispositivos amplamente distribuída e que precisam de baixíssima latência e processamento eficiênte, cada vez mais próxima dos usuários finais.

e é claro, Kubernetes…

Obviamente não poderia deixar de comentar sobre o dono da festa!

No ano em que o projeto completa 10 anos, a comemoração é toda para ele! Se tornando o projeto open source de maior sucesso após o Linux, o Kubernetes é peça essencial em grande parte das empresas que está na nuvem.

Ao longo da conferência, uma série de anúncios foram feitos relacionados ao projeto. Soluções exclusivas para clusters kubernetes dominaram o pavilhão de exposição, independente do seu domínio (seja segurança, observabilidade, resource management, entre outros).

O Gateway API, uma nova forma de expor suas aplicações na internet foi amplamente explorado em diversas palestras.

eBPF também foi um tema fortemente presente nas talks, com soluções como Falco e Cilium comandando a lista de projetos mais populares que fazem uso desse recurso.

Além dos recursos novos e projetos sensacionais desenvolvidos pela comunidade, pude sair com uma certeza, todo o sucesso dos projetos se deve 100% a contribuição da comunidade e a paixão que temos pela área.

Open Source é o presente e o futuro!

Espero que tenha gostado dos relatos, aproveito para deixar aqui o canal da CNCF onde você pode consumir todas as palestras que foram apresentadas no evento: https://youtube.com/playlist?list=PLj6h78yzYM2Pw4mRw4S-1p_xLARMqPkA7&si=LafAAlqJ5mtyZw7k

Até logo!

Entendendo o recurso

Toda funcionalidade que será utilizada pelo cliente deve ser exposta de alguma forma para a internet, tornando-a acessível para o consumidor final. Se as suas aplicações são executadas em clusters Kubernetes, você com certeza já fez uso de algum dos "flavors” do Kubernetes Ingress.

O propósito do Ingress (e agora do Gateway API) é de fornecer uma forma de acesso externo às aplicações que são executadas dentro de um cluster, aplicações essas expostas internamente através de services.

Imagine que você tem dentro do seu cluster os produtos A, B e C. Esses produtos fazem parte da mesma linha de negócio, ou seja, estão todos relacionados, mesmo que façam parte de jornadas diferentes. O que você deve fazer para que as plataformas e canais utilizados pelos clientes possam acessar essas funcionalidades expostas pelas suas aplicações?

Como vemos na arquitetura acima, o Gateway API realiza a exposição das aplicações (que estão representadas “atrás” dos services) através do próprio gateway e de seu recurso auxiliar, a HTTP Route.

• Gateway API - recurso “primário”, que realiza a exposição das aplicações.

• HTTP Route - objeto que declara a rota que será exposta pelo Gateway API.

• TLS Route - parecido com o HTTP Route, porém sua exposição ocorre com o acréscimo de certificados, garantindo a criptografia in-transit na comunicação.

Essa separação das rotas que serão publicadas em um objeto próprio garante maior dinamismo e um design mais limpo e escalável para seu cluster. Se for um desejo do seu time de engenharia migrar o provedor do Gateway API (para o Cilium, por exemplo), essa separação das rotas facilitará o processo, visto que apenas o objeto principal deverá ser modificado, mantendo as rotas e suas regras intactas.

Exploraremos mais sobre algumas features interessantes do recurso nas próximas seções. Agora falaremos brevemente sobre as diferenças para o Ingress.

Qual a mudança do Ingress?

Falando do “legado”, o Ingress e seus flavors foram utilizados por muitos anos como o padrão para exposição de services no Kubernetes. As alterações e evoluções do Ingress ao Gateway API são majoritariamente funcionalidades diferentes, suporte a outros protocolos e alteração na arquitetura do componente.

Abaixo uma breve lista com algumas das principais diferenças de um recurso para outro:

• Protocolos suportados - agora podemos criar recursos que fazem uso de protocolos como gRPC, TCP, UDP e os já suportados HTTP/S.

• Modularização - como comentado anteriormente, com a nova versão, temos completa separação dos recursos, habilitando a troca do provedor e reutilização das rotas declaradas.

• Granularidade das rotas - a declaração das rotas se tornou muito mais detalhada, permitindo a construção de regras mais complexas e habilitando a criação de testes como A/B e blue green com mais facilidade.

Acima temos uma arquitetura simples sobre como o recurso funciona. Podemos notar algumas diferenças para a arquitetura do Gateway API, como mencionado anteriormente.

Coisas legais do recurso

Agora que entendemos de fato as diferenças entre um e outro, vamos nos concentrar nos recursos interessantes que a nova versão do objeto nos traz.

Acho importante reforçar o valor que a “modularização” do recurso traz para os ambientes Cloud Native. Estamos sempre buscando tornar nossas soluções escaláveis, sustentáveis no longo prazo e acima de tudo, vendor-neutral. A separação dos componentes que compõem o Gateway API facilitará na utilização de novos recursos e até na migração para outras plataformas.

TLS era algo já existente no Ingress Controller, porém agora podemos ter de maneira organizada nossas rotas que devem ser expostas de maneira segura e seus certificados, que são binded diretamente na rota. Para os times de segurança e DevOps isso trará um ganho extremo no momento de troubleshooting, visto que será possível identificar os recursos conectados com mais rapidez.

Por último, gostaria de falar sobre o modelo de criação do recurso, através de CRDs (Custom Resource Definitions). Os CRDs tornam as pipelines de execução mais limpas e organizadas, visto que são manifestos iguais aos default do Kubernetes. Criar recursos utilizando esse modelo torna a arquitetura mais modular, garantindo mais uma vez escalabilidade na sua plataforma!

O Gateway API traz uma série de benefícios para seu ambiente e sua equipe. Como qualquer outra tecnologia, não é uma bala de prata. Você deve avaliar se o serviço cumpre com os seus requisitos antes de adotá-lo em larga escala.

Espero que tenha gostado do artigo, não deixe de me contatar caso tenha alguma dúvida ou queira conversar mais sobre o recurso.

Até logo!

Microssegmentação

É uma nova forma de segregação de redes amplamente utilizado em ambientes de nuvem pública. Em uma era onde segurança entra acima de todo o restante e o principal “norte” para os times de engenharia são os pilares do zero trust, proteger a base da sua infraestrutura é essencial.

Independente do tamanho do ambiente, precisamos garantir a aplicação dos princípios do zero trust, implementando de forma eficiente os controles necessários para evitar que atores indesejados consumam nossos recursos, que as aplicações da organização fiquem expostas à possíveis vulnerabilidades e ainda pior, exponham os demais recursos do ambiente a esses atores.

A microssegmentação olha ao nível “mais baixo” dos recursos, atuando como uma malha entre todos os serviços da sua nuvem e permitindo o controle de acesso entre os recursos de maneira flexível e detalhada.

O desenho acima exemplifica em alto nível como a microssegmentação atua nos ambientes. Com ela, é possível definir um perímetro ao redor de cada um dos recursos, controlando o acesso por origem, IP, protocolo e outras informações.

Network Policies

Reduzindo nosso escopo de atuação apenas aos clusters Kubernetes, precisamos falar das Network Policies.

Entendendo o recurso

As Network Policies são recursos padrão existentes nos clusters Kubernetes, que possibilitam a segmentação dos recursos sendo executados no cluster (namespaces, pods, svc, etc). Com as policies padrão já estamos habilitados a incrementar a segurança do nosso ambiente, porém segurança nunca é demais.

Para termos um maior nível de detalhes na criação das políticas, podemos utilizar a versão deste recurso fornecida pelo Cilium, solução que tratamos no post passado. Ao utilizarmos o Cilium como a solução de Container Network Interface dos nossos clusters, podemos implementar regras em diferentes camadas (L3, L4 e L7) e utilizando informações adicionais, trafegadas nas requisições feitas entre os recursos. Não apenas isso, se tivermos a Cluster Mesh habilitada entre nossos clusters que executam o Cilium, podemos criar policies que ultrapassam os limites de cada um dos ambientes Kubernetes. Bom, né?

Antes de passarmos para a real configuração das policies, gostaria de trazer conceitos gerais sobre elas, que facilitarão o seu entendimento no momento de configuração dos recursos.

Funcionamento

Como explicado anteriormente, as policies permitem que nós controlemos o acesso feito aos recursos do cluster e saindo dos recursos. São “regras” criadas com um escopo específico e que validarão TUDO que passar por ali.

No desenho acima podemos visualizar um cluster com 3 namespaces com policies aplicadas e o fluxo de rede que é permitido/proibido em cada uma delas.

Podemos confirmar que a policy do namespace 2 permite consumo vindo de pods com a label color:green. Essa policy também permite o acesso ao mundo externo (fora do cluster) pelos pods que ali estão. A policy aplicada no namespace 2 não declara em momento algum o permissionamento para que os pods restantes no namespace 1 possam acessar seus recursos, o que por padrão, proíbe a chamada.

Para dar uma ideia, uma policy parecida com a que seria aplicada no namespace 2 seria:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: namespace2-policy
  namespace: <NAMESPACE>
spec:
  endpointSelector:
    matchLabels: {}
  ingress:
    - fromEndpoints:
      - matchLabels:
          color: green
  egress:
    - toEntities:
      - "world"

A policy representada acima será aplicada no <NAMESPACE> determinado e permitirá as chamadas vindas de recursos com a label color:green (Ingress) e permitirá também chamadas feitas dos pods presentes no namespace para fora do cluster.

Agora que entendemos como as policies são construídas e aplicadas, vamos detalhar mais os diferentes tipos e as diferenças entre elas.

Comportamento padrão

O funcionamento padrão dos clusters Kubernetes é permitir todas as chamadas de origem interna. Para contornarmos essa situação, é necessário aplicar uma policy qualquer no escopo desejado. Uma vez que temos uma policy aplicada, o cluster passará a levar em conta APENAS o que está determinado nela.

Esse comportamento pode parecer problemático, porém alterá-lo “cegamente” pode desencadear uma série de problemas que não foram mapeados anteriormente pelos times. Existem recursos do cluster que precisam acessar endpoints externos para que sua execução ocorra da forma esperada. Ao aplicar uma policy que modifique esse comportamento, estaremos modificando o funcionamento do cluster, interrompendo as operações de negócio que são apoiadas pelas aplicações ali executadas.

Portanto, CUIDADO!

O escopo de aplicação das policies também é importante. Dentro do Kubernetes, temos recursos que são namespaced, restritos ao namespace onde foram criados e cluster-wide, ou seja, disponíveis pelo cluster todo. A aplicação das policies também cai nesse cenário. Uma policy “default” será configurada no namespace onde o usuário executar sua criação, a não ser que ela seja do tipo CiliumClusterwideNetworkPolicy. As policies protegerão seus próprios namespaces, então tenha em mente que liberar chamadas no namespace destino pode não ser suficiente, havendo a necessidade de alterar a policy cadastrada na origem.

Ingress/Egress

A direção do tráfego é parte crucial na montagem das policies. Precisamos declarar para qual direção aquelas regras deverão ser aplicadas.

• Ingress - todas as chamadas que estão entrando no determinado escopo.

• Egress - chamadas oriundas do escopo de aplicação da policy, independente do destino.

Essa declaração nos permite entender o fluxo das chamadas feitas pelas aplicações que ali estão hospedadas.

Seguindo o exemplo das seções acima, o template que aplicaria essa policy seria:

 ingress:
    - fromEndpoints:
      - matchLabels:
          color: green
  egress:
    - toEntities:
      - "world"

Scoped Network Policies

Passando a falar sobre as policies em si, temos o primeiro “tipo”, que são as policies com escopo. Essas são aquelas policies aplicadas em namespaces específicos, que aplicarão os controles aos recursos ali contidos.

Todo o tráfego de entrada e de saída do namespace especificado será tratado pela policy.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: namespace2-policy
  namespace: <NAMESPACE>
spec:
  endpointSelector:
    matchLabels: {}
  ingress:
    - fromEndpoints:
      - matchLabels:
          color: green
  egress:
    - toEntities:
      - "world"

Esse é o tipo “padrão” das policies, levando em si o comportamento default aplicado no cluster.

Cluster-wide Network Policies

Para cenários onde é necessária a configuração de restrições de acesso independente do recurso, podemos utilizar as policies de escopo cluster-wide.

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: cluster-policy
spec:
  endpointSelector:
    matchLabels: {}
  ingressDeny:
    - fromEntities:
      - "world"
  egress:
    - toEntities:
      - "world"

Por trás dos panos, a policy é identica às policies namespace scoped, com sua principal diferença sendo seu kind que agora é CiliumClusterwideNetworkPolicy e a disponibilidade de uso do recurso nodeSelector, que nos permite especificar os nodes para quais a política será aplicada.

Cross-cluster Network Policies

Chegamos a um extremo diferencial entre as policies default e as policies oferecidas pelo Cilium.

Utilizando as capacidades de cluster mesh, podemos configurar policies dentre os diferentes clusters que fazem parte da nossa mesh. A integração é possibilitada pelo uso da label io.cilium.k8s.policy.cluster que nos permitirá identificar o cluster que originou a requisição.

Esse recurso é especialmente útil para ambientes consumidos por diversas outras áreas, que precisam garantir que apenas os recursos disponibilizados estão sendo consumidos. Ambientes com grandes quantidades de clusters também podem usufruir dos benefícios gerados pela utilização das cluster-wide policies.

Ter a cluster mesh habilitada é um pré-requisito para utilizar as cluster-wide policies, porém a habilitação deste recurso ficará para os próximos artigos.

Por enquanto é só. Espero que tenha gostado do texto.

Até logo!

O que é Cilium?

Falamos brevemente na introdução do artigo sobre o que de fato podemos esperar do Cilium, porém antes de nos aprofundarmos na solução, é importante comentar sobre a tecnologia que habilitou sua construção e que vem revolucionando como nós estruturamos soluções de observabilidade e segurança, o eBPF.

eBPF (extended Berkeley Packet Filter) - foi lançado em 2014 como uma atualização do BPF, utilizado em hosts Linux. O eBPF foi criado com o intuito de fornecer uma maneira de ampliarmos as capacidades do kernel Linux sem a necessidade de recompilarmos todo o sistema. Com programas eBPF podemos interceptar e visualizar chamadas ao nível do kernel, possibilitando a utilização dessas informações capturadas para construirmos aplicações que levam em consideração o mais baixo nível de funcionamento do sistema.

Utilizando as capacidades fornecidas pelo eBPF, a Isovalent construiu uma solução que revolucionou a forma como enxergamos e protegemos nossos clusters e a maneira como desenvolvemos capacidades adicionais para os ambientes.

Para começarmos a falar sobre o Cilium, vamos iniciar com um desenho que mostra em alto nível as capacidades funcionais da solução e seus componentes.

Como podemos visualizar no diagrama, temos 3 pilares sobre os quais o Cilium atua:

• Service Mesh

• Observability

• Networking

As capacidades de segurança são fornecidas em parte pelo Tetragon, que falaremos em outro artigo.

Começando pela feature mais popular, o Cilium CNI é instalado nos clusters Kubernetes e serve como uma substituição (ou complemento) das interface de redes dos contêineres. Com o Cilium CNI controlando a camada de rede do ambiente, nós passamos a ter completa visibilidade (+ Hubble) das chamadas e dos processos que ali estão ocorrendo. Além das capacidades de visualização de tráfego, também temos recursos que habilitam a comunicação multi-tenant e a criptografia do tráfego das chamadas.

Indo para o segundo pilar, temos o Hubble, responsável por grande parte das capacidades de observabilidade do ecossistema do Cilium. Podendo se conectar com soluções que compõem o ecossistema de monitoramento das empresas como Prometheus e OpenTelemetry, o Hubble oferece as capacidades de compreensão de problemas para os times, fornecendo informações detalhadas do ambiente, possibilitando um troubleshooting mais efetivo.

Por último temos o Cilium Service Mesh, que vai na contramão de outras soluções de mercado, oferecendo visibilidade da mesh de maneira sidecar-less. Essa é uma das proezas do Cilium Service Mesh, falaremos mais sobre ele as próximas seções.

Para entender melhor as capacidades da solução, vamos entrar em maiores detalhes sobre cada uma das funcionalidades presentes no ecossistema!

Networking

As capacidades de networking do Cilium são expostas pelo Cilium CNI, que é o primeiro componente a ser instalado no cluster. Uma vez instalado, você terá de forma nativa uma série de funcionalidades já disponíveis para uso.

Nas capacidades de networking, o Cilium se diferencia por fornecer de maneira nativa recursos que precisariam ser implementados utilizando add-ons de outras soluções. Por termos controle de camadas mais profundas dentro do cluster, podemos executar operações em cima de protocolos como IPv4, IPv6 e BGP, suportados de forma nativa pela solução.

Além disso, visto que a responsabilidade de gerenciar a rede dos clusters é do Cilium CNI, conseguimos aplicar regras de rede nas camadas 3, 4 e 7 (com suporte à políticas de roteamento personalizadas).

Hoje em dia é difícil encontrarmos empresas que tenham só um cluster. Gerenciar um ambiente já é uma tarefa complexa, se pensarmos que cada vez mais as equipes terão autonomia de gerenciar seus próprios clusters, a nossa cluster mesh se tornará “inadministrável”. Com Cilium temos a possibilidade de gerenciar as camadas de rede dos nossos clusters de maneira centralizada, implementando políticas de acesso entre eles e controlando diversos aspectos das interfaces de rede de cada um dos ambientes.

Performance e segurança são pilares prioritários no Cilium e ao notarmos as capacidades de criptografia e balanceamento de carga isso fica ainda mais evidente. Com o wireguard e IPsec podemos configurar criptografia para a rede interna do cluster e para as comunicações na camada de rede (L3/L4).

Com as capacidades de DSR (Direct Server Return) podemos implementar uma arquitetura performática, que garantirá a resolução das chamadas e as respostas aos clients de maneira mais veloz e precisa.

Observabilidade

Com o objetivo de estender as funcionalidades de rede e fornecer visibilidade de uma série de coisas que ocorrem dentro do cluster, podemos realizar o deployment do Hubble, solução complementar ao Cilium CNI e Service Mesh que nos permite visualizar os flows existentes dentro do nosso cluster.

Para fornecer as capacidades que temos hoje, o Hubble foi separado em alguns componentes, segregando assim as responsabilidades de cada um.

• Server - responsável por fazer a interface com o Cilium para coleta dos eventos de rede, é executado dentro do container do Cilium Agent, que por sua vez é criado à partir de um DaemonSet.

• Relay - aplicação única que centraliza os endpoints dos servers que estão sendo executados no cluster.

• Hubble CLI - componente que pode ser instalado no client para recuperar informações do ambiente.

• Hubble UI - interface gráfica que interage com o relay para disponibilizar as informações coletadas.

O desenho não mostra o Hubble CLI, que é um componente que pode ser instalado no client para que possamos interagir diretamente com o Hubble Server, pois não se faz obrigatório na instalação da solução no seu cluster.

Outra capacidade importante do Hubble é a visualização de métricas capturadas por coletores como o prometheus. Com o Hubble UI nós podemos visualizar essas métricas em formato de gráficos, tornando a identificação de problemas mais simples.

Service Mesh

A sidecar-less mesh apresentada pelo Cilium é construída por uma junção dos componentes de networking, observability e por componentes padrão do Kubernetes.

Com o uso de componentes como o Kubernetes Ingress e a Kubernetes Gateway API podemos implementar diversas capacidades que antes eram atingidas apenas com a utilização de uma tecnolgia adicional no modelo sidecar.

Com o Cilium Service Mesh podemos implementar roteamento baseado em headers, teste A/B, deployment multi-version, exposição de APIs com TLS e mTLS configurados e diversas outras funcionalidades, tudo isso sem que precisemos nos preocupar com o deployment de containers distribuídos pelos nossos clusters.

Por quê utilizar?

Se você é um SRE, DevOps Engineer, SysAdmin ou se apenas gosta de tecnologia, já pode ter percebido que gerenciar um cluster não é apenas garantir que ele esteja performando conforme o esperado. Além do “básico”, nós precisamos nos preocupar com FinOps, com as aplicações que estão sendo executadas ali “dentro”, com os add-ons do cluster (que normalmente consomem muuuuuuuitos recursos de infraestrutura, consequentemente aumentando os custos), com a segurança, controle de acesso e muitos outros pontos.

Até por “limitação” do Kubernetes muitas dessas coisas precisam de recursos adicionais para serem feitas, o que em si não é um problema, porém em determinado momento você perceberá que tem em seu ambiente recursos em execução que nem sabemos para que serve.

Pela forma em que foi arquitetado, o Cilium fornece diversas capacidades (das quais comentamos na seção anterior) de forma “nativa”, não havendo a necessidade de instalarmos soluções diferentes.

Ter essas soluções de forma nativa tornará o trabalho dos times de tecnologia muito mais simples, visto que o monitoramento do ambiente e a atualização das novas versões poderá ser implementada de maneira mais rápida.

Arquitetura

De maneira bem simplificada, o deployment do Cilium se parece com o seguinte:

Possibilitando a interação com o cluster e com seus componentes, temos do lado do client o Cilium CLI instalado no laptop do usuário. O CLI é um simples executável que facilita a instalação do Cilium e seus componentes adicionais em qualquer um que seja seu cluster.

Após instalado o Cilium CNI, você poderá habilitar outros add-ons como Prometheus e o Hubble.

Aproveitando que já falamos do Hubble, na arquitetura acima temos uma referência a um “port-forwarding“ que é configurado. O intuito deste recurso é possibilitar o acesso local do laptop ao Hubble UI, que está sendo executado dentro do cluster. Quando configurado, o usuário poderá utilizar a UI com um acesso local (por padrão, o endereço é http://localhost:12000).

É importante destacar que todos os componentes do Cilium são criados de maneira a serem altamente disponíveis, garantindo que mesmo mediante a falhas nos recursos de infraestrutura que sustentam o cluster, nossa visibilidade dos recursos e proteção da plataforma seguirão intactos!

Implementando Cilium no Azure Kubernetes Service

Para “prepararmos o terreno” para os próximos artigos, vamos realizar a criação de um cluster Azure Kubernetes Service com apenas 2 nodes para iniciarmos nossos testes e não sermos surpreendidos com uma conta gigantesca no final do mês. Os 2 nodes terão baixa capacidade computacional, porém servirão perfeitamente para o propósito que desejamos cumprir.

Para conseguirmos criar o cluster de maneira simples, execute o seguinte comando em seu terminal:

az aks create \
  --resource-group <resource-group> \
  --name <aks-cluster-name> \
  --node-count 2 \
  --node-vm-size Standard_D2plds_v5 \
  --network-plugin none \
  --enable-managed-identity \
  --generate-ssh-keys

Aguarda a criação do seu cluster e recupere suas credenciais utilizando o comando:

az aks get-credentials --resource-group <resource-group> --name <aks-cluster-name>

Com o cluster no ar e o Cilium CLI instalado na sua máquina, vamos executar o seguinte comando para instalar o Cilium CNI e deixar nosso ambiente pronto para as próximas etapas:

cilium install --version <cilium-version> --set azure.resourceGroup="<resource-group>"

Para garantir que tudo foi instalado corretamente, podemos abrir uma nova instância do terminal e executar o seguinte comando, que acompanhará a instalação fornecendo detalhes visuais do status dos componentes criados:

cilium status --wait

Na primeira instalação, apenas o Cilium e o Operator serão criados, portanto não se assuste caso veja os outros componentes marcados com “disabled“.

Por hoje é só. Espero que tenha gostado do texto e te aguardo para falarmos mais sobre essa solução nas próximas semanas.

Caso tenha alguma dúvida, não deixe de me contatar no Linkedin.

Até logo!

O que é uma solução de EDR?

Contexto

Já parou para pensar na dimensão de certas organizações? Aquelas empresas de tecnologia globais, prestadoras de serviço que estão em todos os cantos do planeta, empresas da indústria financeira e de saúde, que contém todo tipo de dado que consideramos sensível. Essas organizações contém largas capacidades de infraestrutura e prestação de serviços e contam com ambientes de infraestrutura gigangtescos.

Além dos ambientes que sustentam os produtos, jornadas e serviços prestados pelas empresas, temos também seus funcionários, aqueles que residem e atuam em diversos países diferentes, em funções diferentes, com equipamentos diferentes, com clientes, parceiros e outros funcionários, fazendo de tudo: criando apresentações, construindo demonstrações, desenvolvendo softwares, mantendo a infraestrutura, entre outras atividades.

Essa extensão global dos serviços prestados pelas empresas gera um aumento exponencial na superfície de ataque exposta pelas organizações, deixando a organização cada vez mais atraente para agentes maliciosos que visam explorar alguma vulnerabilidade. Essa larga superfície exposta pode ser protegida por uma solução de EDR.

EDR

A solução de EDR recebe eventos os dispositivos gerenciados pela organização, realização não apenas seu monitoramento, mas também para sensibilizando outras soluções para possíveis ameaças detectadas. Essas detecções geram alertas que podem ser enviados ao time de SOC responsável pelas respostas à incidentes da organização em questão ou também podem servir como gatilhos para execução de workflows automatizados, que "resolvam" a vulnerabilidade sem a necessidade de interação humana.

Com o advento da Inteligência Artificial, as soluções passaram a trazer mais funcionalidades e consequentemente gerar insights mais valiosos e eficiêntes, reduzindo a quantidade de "falsos positivos" enviados para os times de operação de cibersegurança. Acessos de usuários aos endpoints são logados, arquivos recém baixados/criados são analisados, os acessos às portas disponíveis são monitorados, e assim a monitoração e proteção dos recursos vai ganhando forma, gerando ganhos diretos e indiretos à sua organização.

Defender for Endpoint

O Microsoft Defender for Endpoint faz parte da suite de produtos que compõem o Microsoft 365 Defender. Como mostra o desenho acima, retirado da documentação oficial do Defender, a solução pode ser integrada com diversos outros componentes disponíveis não apenas na plataforma da Microsoft, mas também em soluções externas utilizadas na sua empresa.

Planos

Antes de falarmos mais sobre as capacidades técnicas da solução, é importante deixar claro que o Defender está disponível em dois planos (P1 e P2), que se diferenciam no preço e também em algumas das capacidades. O plano P2 se destaca por sua maior cobertura e range de funcionalidades. Um comparativos sobre os dois pode ser visto abaixo:

A solução

O Defender fornece uma extensa cobertura para os dispositivos gerenciados pela sua organização, bastando que o onboarding desses aparelhos seja feito com as configurações desejadas pela sua empresa. Se a sua empresa utiliza alguma das seguintes plataformas, o Defender pode ser configurado para proteger seus usuários e dispositivos:

• Windows

• macOS

• Android

• iOS

Uma vez integrados na solução, podemos começar a monitorar as ameaças que permeiam os ativos da organização e que trazem riscos às operações da empresa.

O Defender oferece 7 pilares de defesa para os endpoints:

• Core Vulnerability Management - recurso que possibilita a identificação de vulnerabilidades e problemas de configuração.

• Attack Surface Reduction - permite a configuração de controles que serão aplicados nos dispositivos para evitar a exposição à recursos maliciosos.

• Next-generation Protection - recurso de proteção avançado que garante a segurança dos endpoints contra as mais modernas ameaças emergentes.

• Endpoint detection and response - permite identificar ameaças sofisticadas por meio de queries previamente escritas e solucioná-las através de automações.

• Automated investigation and remediation - garante a padronização da resposta à certos alerats que são gerados com devida frequência.

• Secure Score for Devices - fornece uma visão aos administradores e times de segurança das configurações de segurança dos dispositivos de acordo com certos benchmarks configurados.

• Threat Experts - recurso de hunting avançado, que possibilita a integração com o SOC da organização para análise e respostas mais profundas em relação ao incidente.

Através de recursos avançados e modernos, o Defender possibilita a cobertura de uma parte essencial da infraestrutura das empresas, garantindo desde a identificação das vulnerabilidades e ameaças, até as respostas e análilse dos incidentes, permitindo que a organização crie controles efetivos e que considerem os mais diversos pontos identificados pelo Defender.

Qual a importância?

Com o crescimento das empresas e a maior adoção do trabalho flexível e do home office, as organizações perderam boa parte do controle que tinham sob o que seus funcionários podiam acessar e com o que estavam interagindo.

A sofisticação das ameaças cibernéticas e o aumento do uso da inteligência artificial e machine learning tornou a vida dos times de segurança mais complicada nos momentos de resposta às ameaças.

Ter uma ferramenta que fizesse uso de recursos avançados e que pudesse ser escalada conforme crescimento da sua organização (até escalas globais) passou a ser uma das prioridades dos times de segurança e executivos de tecnologia, permitindo dessa forma proteger os ativos da empresa e garantir a liberdade e flexibilidade que seus funcionários precisam para trabalhar.

EDR é um assunto extenso e nos próximos capítulos falaremos mais sobre as funcionalidades e recursos de proteção que estão disponíveis na solução.

Até logo!

Contexto

Temos notado hoje em dia que as senhas em texto plano tem entrado cada vez mais em desuso, com sua utilização desencorajada pelas principais empresas de tecnologia e orgãos reguladores. Com isso, a recomendação frequentemente vista nas empresas é do uso de passwordless, ou seja, autenticações que não requerem senha.

Dentro das organizações é comum termos uma série de contextos referentes às identidades dos usuários. Temos dispositivos gerenciados (mobile, notebooks, desktops, tablets, etc.), redes internas (VPNs, SASEs, etc.) e escritórios, o que já nos possibilita personalizar o acesso de diferentes maneiras de acordo com o local onde o usuário está, com o dispositivo que está sendo utilizado e de acordo com outros "pontos" de informação que são retirados das suas interações com as aplicações corporativas.

Organizações com essas características estão bem postadas para utilização de autenticação passwordless, inclusive fazendo uso de certificados!

Por quê usar?

Habilitar diferentes maneiras de autenticação para seus usuários de acordo como cenário em que se encontram, deixará a jornada deles muito mais simples e agradável, permitindo que foquem na execução das atividades de negócio e trabalhem de maneira mais segura.

Os diferentes métodos de autenticação disponíveis servem para o mesmo propósito, porém fornecem ganhos diferentes. Um certificado deve ser utilizado em junção a outro fator de autenticação (como por exemplo uma leitura biométrica ou até mesmo um PIN), garantindo que o usuário que está fazendo uso daquele "objeto", é o owner do mesmo. Com os certificados em especial devemos implementar um fator de autenticação adicional, visto que o detentor do dispositivo onde o certificado está instalado, o poderá utilizar para acesso aos sistemas da organização.

Agora que entendemos a peculiaridade de utilizar um certificado como fator de autenticação, gostaria de esclarecer algo:

Um certificado não é nada além de um "objeto" que contém informações sobre um ator/agente (não necessariamente humano) e que é utilizado para provar que quem o detém, é quem diz ser. Para as autenticações, o certificado será emitido para o usuário que planeja o utilizar, não sendo válido para outros usuários.

Após esclarermos esse entendimento, vamos falar brevemente sobre como um certificado pode ser utilizado em uma autenticação.

Um usuário acessa aplicações empresariais conectadas ao Microsoft Entra ID através de dispositivos gerenciados (ou pelo menos conhecidos) pela organização. Esses dispositivos, confiáveis, contém certificados criados para o usuário e atribuídos aos dispositivos registrados em seu nome. Esse certificado, junto de outras informações de seu login, sessão, dispositivo e contexto, é utilizado nas regras de acesso condicional presentes do Entra ID da empresa.

É importante comentar que o certificado pode ser utilizado como único fator de autenticação e também como parte de uma autenticação mais rigorosa e forte, exigindo algo a mais para que consiga se autenticar corretamente na aplicação. Como você fará depende do contexto apresentado pela sua empresa, havendo a necessidade de se analisar os requisitos apresentados e de avaliar os possíveis impedimentos técnicos.

Pensando na implementação dos processos e na habilitação da tecnologia, vamos falar um pouco sobre como o Entra permite esse integração e o que deve ser feito para disponibilizá-la para seus usuários.

Entendendo a solução

Pensando em entender melhor como funciona o fluxo de autenticação de um usuário que utilizará um certificado, podemos ter como base a seguinte imagem:

No momento da autenticação do usuário no Entra ID, o browser disponibiliza uma caixa de seleção ao usuário para que o mesmo possa selecionar o certificado desejado dos presentes no dispositivo. Uma vez selecionado, certos campos do certificado são validados de acordo com as regras definidas no próprio IdP. Essa validação faz o match das informações da conta do usuário no Entra e do certificado utilizado. Esse processo de matching de atributos do certificado com a conta do usuário é chamado de binding. A imagem abaixo oferece uma visão de alguns bindings pré-configurados:

Como podemos ver na imagem acima, na seção username binding é onde devemos configurar o Entra para referenciar alguns campos do certificado com alguns campos do usuário.

A coluna "Affinity binding" define a "força" do atributo que será utilizado no binding, classificando alguns campos como "baixos" e alguns como "altos".

Acima estão listados os campos do certificado que podem ser selecionados e qual a "força" de cada um deles. Entenda que por "High affinity - alta afinidade" nós temos campos que são mais confiáveis e por isso tem valor maior no momento de autenticação do usuário.

Esses bindings são importantes pois no momento de autenticação do usuário perante o Entra, os valores cadastrados no binding serão validados e levados em conta no momento da avaliação do processo de autenticação.

A imagem abaixo mostra a visão de uma autenticação via certificado rejeitada pelo Entra.

Os problemas podem ser dos mais variados, affinity bindings configurados de maneira errônea, certificado vencido, problemas com o certificado, entre outras. Ao receber um erro em seu processo de autenticação, valide o passo a passo realizado, conferindo todas as etapas do processo.

Pontos de preocupação

Como qualquer solução, além de seus pontos positivos, é necessário jogar luz nos pontos negativos.

Os certificados são extremamente úteis em diversos cenários, mas se implementados de maneira incorreta ou sem os devidos processos definidos, podem apresentar grande risco à sua organização.

Para que sua implementação tenha sucesso, os processos relacionados à gestão do ciclo de vida dos certificados devem estar maduros e eficientes. É importante que um certificado seja atualizado quando estiver próximo de seu vencimento, que um usuário desligado da organização tenha seu certificado invalidado (o proibindo de utilizá-lo em autenticações subsequentes), que os times de gestão tenham o histórico e as informações relacionadas aos certificados gerados e que todo o processo, desde a geração até a entrega do objeto seja automatizado e "limpo". Por se tratar de algo que impactará diretamente no dia a dia de trabalho dos funcionários, interrupções no processo e demora nas entregas poderão ser os grandes culpados da improdutividade das equipes, tornando assim a solução inviável.

Outro ponto importante e que foi mencionado anteriormente é a necessidade de se utilizar o certificado em junção a outra solução. Por estarem "presos" aos dispositivos, um usuário em posse daquela plataforma oferece grande risco aos ativos ali gerenciados. Combinar a autenticação baseada em certificado com uma leitura biométrica do windows hello for business ou com uma chave FIDO2 ou até com um push gerado pelo Microsoft Authenticator no dispositivo móvel do usuário, reduzirá os riscos exponencialmente, mantendo a experiência agradável e tornando o ambiente mais seguro.

O processo de autenticação da sua empresa não precisa ser moroso e complicado para ser seguro. Utilizando das tecnologias corretas e de processos bem implementados, a experiência dos usuários pode ser muito agradável e com segurança end-to-end.

Espero que tenha gostado do artigo e que de alguma forma eu tenha contribuido para a melhora da postura de segurança em seu ambiente.

Até logo!

Entendendo o recurso

Nas fundações das estruturas em nuvem, temos o design, construção e configuração da camada de rede (virtual networks, subnets, firewalls, etc). A construção dessa camada estabelece o perímetro do nosso ambiente, principalmente quando adotamos uma arquitetura hub-and-spoke. É necessário garantir que tudo que estiver entrando em nosso ambiente, tenha sido devidamente analisado e seja seguro.

Exigir que os primeiros passos de um objeto dentro do nosso ambiente sejam a validação de integridade daquele arquivo não exime validações posteriores (principalmente quando estivermos colocando em prática uma arquitetura zero trust).

Para garantirmos a tranquila ingestão dos arquivos disponibilizados de diferentes maneiras (através de interfaces com clientes, parceiros, etc.) é importante realizar uma varredura e possivelmente implementar um processo de segregação dos blobs para garantir que apenas os documentos "limpos" e íntegros possam ser consumidos e internalizados nas diferentes construções feitas em seu ambiente.

Considerando que o Microsoft Defender for Storage está habilitado em sua Storage Account e o recurso de malware scanning está configurado, podemos começar a trabalhar para proteger nossos storages e também nossas soluções como um todo.

Como a solução funciona?

Uma vez ativo, o defender for storage irá escanear todos os arquivos que forem colocados nas storage accounts que estiverem sendo monitoradas. Por padrão, é criado um Azure Event Grid System Topic que receberá todos os eventos disparados pela storage account. Esse tópico pode ser utilizado por outras soluções para decidir o que fazer com o objeto (entraremos em mais detalhes na próxima seção).

Ao receber o evento BlobCreated na storage account, o defender for storage executará o malware scanning em near real time, disponibilizando rapidamente o resultado da análise.

O objeto analisado, por padrão, é mantido na storage account, a não ser que uma automação seja criada para removê-lo ou modificá-lo. Após a análise, o blob tem uma tag criada em si, representando o resultado da análise. Essa tag é representada como na imagem abaixo:

Além disso, caso seja identificado uma espécie de malware em um dos arquivos, será gerado também um alerta na seção Security Alerts do Microsoft Defender for Cloud. O alerta será semelhante ao representado abaixo:

Ao selecionar o alerta, você pode ter mais informações sobre o evento gerado e tudo que está relacionado a ele. Na seção "MITRE ATT&CK" podemos visualizar os vetores de ataque que estão relacionados com esse evento e de que forma nosso ambiente pode ser prejudicado caso seja exposto a esse malware.

O tópico do event grid criado para envio dos eventos gerados pela storage account também pode ser consumido com o objetivo de validar a verificação contra malware e automatizar a manipulação dos arquivos.

Respondendo às análises

Falamos com profundidade sobre como a solução funciona e o que é possível fazer com ela, agora vamos comentar sobre as automações que podem ser construídas com recursos nativos da nuvem.

Utilizando as análises geradas

Após configurar seu defender (independente do nível), chegou a hora de fazer uso dos resultados das análises. Os eventos gerados pelo defender permitem a criação de workflows e arquiteturas orientadas a eventos. Vamos explorar essas opções nas seções abaixo.

A imagem acima, retirada da documentação oficial da Microsoft, lista os métodos de integração com os resultados do scanning feito pelo defender for storage. Podemos utilizar as funcionalidades e recursos representados acima como "repositórios" para os resultados gerados pelo scan. Esses repositórios fornecem maneiras de integração com outros recursos da plataforma, que permitirão a automação e a construção de soluções serverless e orientadas a eventos.

O desenho abaixo mostra as diferentes maneiras que cada recurso pode ser integrado:

As 4 formas de integração são representadas pela seção Integration. Os Security Alerts do Defender for Cloud podem ser utilizados para acionamento da equipe de SOC e para automações utilizando o Azure Logic Apps. Os dois recursos farão uso dos alertas gerados pelo defender para serem executados. Esses alertas são gerados automaticamente, com a criticidade devida e com as características do tipo de ameaça identificada.

As Index Tags colocadas nos blobs podem ser utilizadas pela sua aplicação para garantir que o documento acessado é de fato seguro e não representa nenhum perigo para a solução. Caso a arquitetura montada faça uso de storages secundários para armazenamento dos arquivos válidos, a análise das tags garante uma segunda etapa de validação.

A terceira opção elencada representa o uso do Azure Event Grid, solução de streaming que permite a construção de arquiteturas orientadas a eventos. Fazendo uso das Azure Functions, podemos criar uma aplicação que recebe os estímulos vindos do event grid e respondem como desejado. Nos eventos enviados ao grid pelo defender for storage, devemos nos atentar nas propriedades eventType e scanResultType, que fornecem informações sobre o resultado da análise de malware feita no blob.

Por último temos o Log Analytics Workspace. Esse recurso não tem o propósito de automatizar qualquer tipo de resposta ou operação, a proposta é ingerir os logs gerados pelo defender e analizá-los, a fim de obter insights sobre os arquivos carregados e sobre os resultados obtidos. Todos os resultados são colocados em uma tabela chamada StorageMalwareScanningResults, sendo a fonte que deve ser consultada para visualização das métricas e logs gerados pelo defender.

Testando

Com o intuito de testar a viabilidade da solução, podemos seguir o passo a passo do seguinte repositório: Defender for Storage - Labs.

O repositório contém todo o passo a passo desde como configurar o defender até como visualizar alertas e automatizar as respostas aos eventos.

O lab consiste na configuração da solução e upload de alguns arquivos, incluindo um arquivo que contém conteúdo possivelmente malicioso. Podemos visualizar os alertas gerados no defender for cloud, as index tags criadas nos blobs analisados e criar uma aplicação para consumir o tópico do azure event grid criado.

Proteger os storages vai muito além de garantir apenas a segurança dos arquivos, precisamos pensar também no controle de acessos e nas configurações de rede, mas ter a garantia de que os conteúdos utilizados pela soluções estão livres de ameaças, dá a liberdade que as equipes precisam para continuar evoluindo suas jornadas e seus produtos.

Espero que tenha gostado do conteúdo.

Até logo!

O que é o Defender for Storage?

Como comentamos no último artigo, o Microsoft Defender for Cloud é a solução de CNAPP (Cloud Native Application Protection Platform) da Microsoft e entre seus muitos módulos, temos o Defender for Storage.

O Microsoft Defender for Storage nos permite incrementar a postura de segurança das nossas storage accounts, bem como proteger nosso ambiente contra arquivos maliciosos que podem ter sido inseridos e também contra vazamentos de dados pessoais.

Utilizar uma solução como o Defender para aumentar a profundidade de proteção nos recursos do seu ambiente trará inúmeros benefícios para sua empresa. Os times de segurança da sua organização poderão aproveitar recomendações personalizadas e análises de segurança avançadas, garantindo um nível de proteção diferenciado ao seu storage e mantendo seu ambiente livre das ameaças mais avançadas.

Chegou a hora de explorar em alto nível os recursos expostos pelo Defender for Storage, passando nas próximas seções para os recursos mais relevantes na solução.

Capacidades

Como falamos na seção anterior, o Defender é utilizado para garantir que nossos storages estejam sempre protegidos e alinhados com as melhores práticas e configurações, porém para garantirmos a extração de todo o potencial da solução, é importante entender o que ela pode fazer.

• Recommendations - também presente nas outras soluções do Defender for Cloud, as recomendações visam propor melhorias para seus recursos, com o intuito de deixá-los mais seguros. Essas recomendações são classificadas de acordo com a criticidade e podem ter a resposta automatizada, garantindo maior facilidade na adesão das mesmas.

• Threat Detection - "carro chefe" do Defender, as capacidades de threat detection analisam o comportamento dos usuários, consumo dos recursos e integridade dos objetos armazenados nos contêineres e file shares. Atividades suspeitas e atores maliciosos são detectados pelo Defender e podem ser rapidamente anulados pelas estratégias de resposta configuradas pela sua empresa.

  • Sensitive Data Threat Detection - faz uso do motor de identificação de informações sensíveis utilizado pelo Microsoft Purview (Sensitive Data Discovery) para reconhecer possíveis exposições de dados pessoais e confidenciais dentro dos storages.

• Malware Scanning - para garantirmos a integridade dos documentos publicados em nossos contêineres blob, podemos realizar varreduras nesses arquivos para garantir a inexistência de malwares e outros agentes que podem vir a se infiltrar em nosso ambiente com o intuito de explorá-lo e causar prejuízos a organização.

Habilitação

Habilitar o Defender for Storage não é nada complicado, você pode fazer isso diretamente do painel da sua storage account ou do portal centralizado do Defender for Cloud. O Defender for Storage pode também ser ativo no nível das subscriptions, disponibilizando todas as capacidades de segurança para todas as storage accounts ali presentes.

A funcionalidade de Malware Scanning não é ativa por padrão, porém pode ser habilitada com apenas um "tick" em uma das caixinhas do formulário disponibilizado na página.

Pricing

Os custos de proteger melhor seu ambiente não deveriam ser considerados um problema, mas é importante se manter de olho nos valores.

O Defender for Storage é cobrado mensalmente pela quantidade de storage accounts ativas em sua subscription. O valor é de 10 dólares/mês com um possível acréscimo de acordo com a quantidade de requisições feitas para o storage.

A funcionalidade de Malware Scanning também representa um acréscimo na conta mensal, porém dessa vez sendo cobrada por GB de dados processados. O valor é de 0.15 dólares/GB. Para controlar o gasto com essa funcionalidade, podemos configurar um limite de transações (em GB) por mês para o storage em questão, garantindo assim que sua conta não seja astronômica!

Malware Scanning

Como comentado brevemente, o Defender for Storage tem a capacidade de avaliar a integridade dos arquivos armazenados em seus repositórios. Essa funcionalidade habilita a criação de soluções escaláveis e que utilizam o Azure Storage Account como seu core e de maneira abundante.

O malware scanning possibilita que suas soluções confiem nos arquivos armazenados nos storages, pois garante que cada arquivo que passar pelo repositório terá sido escaneado e está seguro para sua ingestão.

A arquitetura acima demonstra em alto nível o funcionamento da solução e suas possíveis integrações para automação.

Podemos utilizar um tópico do Azure Event Grid para realizar a análise dos eventos gerados pelo Defender for Storage e agir conforme desejado. Outra forma é o uso direto dos alertas gerados pelo Defender, que podem ser integrados com o Azure Logic Apps para recebimento dos alertas e automação da resposta.

As duas formas de automação abrem o leque para as possibilidades de criação de soluções responsivas e escaláveis, deixando com você a responsabilidade de escolher a opção que melhor se encaixa nos seus requisitos.

Sensitive Data Threat Detection

Desviando um pouco do assunto "malware detection", vamos falar sobre a capacidade de DLP (Data Loss Prevention) e proteção contra vazamento de dados sensíveis do Defender for Storage.

Utilizando o motor de identificação e classificação de dados do Microsoft Purview (solução de proteção de dados e informações), o Defender for Storage disponibiliza uma camada de segurança contra o vazamento de informações sensíveis vindas da sua organização.

Podemos monitorar os repositórios para identificar padrões de dados publicamente conhecidos como sensíveis (PII - Personal Identifiable Information, PCI - Payment Card Industry) e evitar que essas informações caiam nas mãos erradas, protegendo sua organização de possíveis multas e processos legais.

Podemos também monitorar o vazamento de informações confidenciais da sua organização, fazendo uso das poderosas Sensitivity Labels. Essas labels são aquelas classificações disponíveis nas soluções do Office 365 que permitem classificar o nível de confidencialidade de um documento (público, interno e confidencial). Fazer uso dessas labels em toda a organização pode evitar muitos problemas para sua empresa.

As Custom Sensitivity Information Types nos permitem identificar informações únicas ao seu negócio através de regras customizadas. Esse recurso permite uma maior cobertura das informações valiosas para o seu negócio, evitando também perdas internas da organização.

Espero que tenha gostado do artigo e que eu tenha conseguido te auxiliar a reforçar a segurança da sua organização. Estou à disposição para conversarmos através das minhas redes sociais, que se encontram em meu perfil aqui no blog.

Até logo!

Como foi o encontro?

Como todos os nossos encontros do chapter cloud native, as principais regras de participação são o respeito e a diversidade, mantendo um ambiente confortável para que todos possam se expressar da maneira que bem desejarem.

O encontro foi hospedado no escritório da Claro Brasil em São Paulo, no dia 06/06/2024, quinta-feira das 18:00 às 21:00. Como todos os eventos, contamos com uma série de patrocinadores que de diferentes formas, mantém as ações da comunidade vivas e acessíveis para todos. O flyer abaixo contém informações sobre o evento e sobre os patrocinadores.

Nosso encontro se iniciou com uma talk sobre "a vida de um contribuidor open source", comandada pelo amigo Ricardo Katz. Logo em seguida, partimos para o open mic e seção de networking, onde pudemos sentar para conversar com amigos contribuidores e entusiastas e discutir sobre as iniciativas open source em que estamos presentes.

Os encontros costumam contar com o apoio das empresas patrocinadoras para compra de caixas de pizzas e bebidas (refrigerantes, sucos e cervejas) e ao final das talks, nos juntamos por algumas horas para conversar com os amigos e conhecer novos integrantes do grupo.

Talks e Open Mic

Como comentei brevemente na seção anterior, o meetup foi dividido em duas partes, sendo a primeira uma talk sobre contribuição aos projetos open source e a segunda um espaço aberto para qualquer um que desejasse compartilhar sua experiência com os projetos.

Na seção de open mic tivemos diversos amigos compartilhando suas experiências com open source. Alguns falaram sobre como a comunidade e os responsáveis pelos projetos foram acolhedores e essenciais para que continuassem interagindo com os grupos, mas também tivemos alguns colegas reportando suas experiências negativas e como agiram em cima disso para melhorar a comunidade que abriga o projeto.

Algumas fotos e posts

Para registrarmos o sucesso do nosso encontro, aqui vão algumas fotos com os amigos e alguns dos posts feitos no Linkedin.

Meus registros sobre o meetup bem como informações sobre os outros participantes e organizadores: linkedin.

Esse foi apenas um dos muitos encontros que temos ao longo do ano, se você se interessa por tecnologias open source e gostaria de fazer parte do grupo pode se inscrever no website oficial da CNCF e se juntar ao nosso grupo CNCF Cloud Native São Paulo: website. Temos outros chapters que podem ser visualizados aqui: community groups.

Até mais!

O que é CNAPP?

O termo CNAPP (Cloud Native Application Protection Platform) faz referência a uma solução centralizada de segurança para ambientes cloud. Todas as funcionaliades de segurança necessárias em um ambiente cloud, estão presentes na solução, facilitando o trabalho dos administradores e dos times de segurança.

Uma característica importantíssima das soluções de CNAPP é a segurança de ambientes multi-cloud, não se limitando apenas a um provedor. Para que sua organização consiga extrair todos os benefícios da solução, é importante que você escolha uma ferramenta que habilite essa visão cross-provider, caso contrário, teremos replicado o problema de se ter múltiplas visões dos ambientes, tendo que orquestrar diferentes soluções, paineis e acessos.

Além do suporte multi-cloud e visão centralizada, as seguintes (também) são características das soluções de CNAPP existentes no mercado:

• CSPM (Cloud Security Posture Management) - importante em qualquer ambiente cloud, a solução de CSPM é a responsável por fornecer uma visão de como o ambiente está em relação aos benchmarks e melhores práticas de mercado. Com ela podemos visualizar as configurações críticas que não estão aplicadas em nosso ambiente e solucionar o tal problema, garantindo assim uma melhor cobertura das boas práticas de segurança.

• CWPP (Cloud Workload Protection Platform) - focado nos recursos do provedor de nuvem, o CWPP identifica e analisa ameaças nos recursos da plataforma. A análise de ameaças é feita nos workloads que estão sendo rodando em seu ambiente, explorando a variedade de opções existentes para execução dessas aplicações.

• CIEM (Cloud Infrastructure Entitlement Management) - considerado uma parte da disciplina de IAM (Identity and Access Management) o CIEM é responsável por centralizar o gerenciamento de acessos privilegiados nos provedores. Essas contas (muitas vezes superpoderosas) apresentam alto risco ao ambiente, pois caso comprometidas, possibilitarão ao detentor das credenciais, alto escopo de acessos ou de permissões.

Essa são algumas das principais características de uma solução de CNAPP. Com o intuito de incentivar a adoção desse tipo de ferramenta em sua organização, vamos agora falar sobre os benefícios que uma ferramenta como o Defender for Cloud pode trazer para o seu ambiente.

Benefícios

Na seção anterior, mencionamos algumas vezes a tendência das empresas de adoatarem múltiplos provedores de nuvem e a complexidade que isso gera no trabalho dos times de segurança. Somado a isso, a vasta variedade de recursos que podem ser criados nas plataformas fazem com que qualquer problema de configuração possa se tornar em uma tremenda dor de cabeça para a sua organização.

Se tirarmos os olhos do painel centralizado e focarmos nos recursos existentes em cada uma das ofertas da solução, enxergaremos ainda melhor os benefícios gerados.

Para as integrações ao SDLC (Software Development Lifecycle), podemos garantir aos times de engenharia de software a tranquilidade de saber que o código executado em produção foi escaneado para vulnerabilidades de diversas maneiras. Análises do código foram feitas durante o pipeline, buscando situações perigosas e que pudessem comprometer a integridade do código. As dependências também foram "varridas", evitando que uma dependência com vulnerabilidades altas seja utilizada nos códigos produtivos. "Segredos!", que são tão problemáticos, são identificados em tempo de commit, garantindo que as credenciais não cheguem aos repositórios (independente se forem públicos ou privados).

Em relação aos recursos de infraestrutura, temos uma série de atribuições que nos permitem protegê-los. Servidores poderão ser varridos e monitorados para ameaças e recomendações de hardening. Bases de dados diversas serão analisadas, na busca de servidores com autenticação fraca, criptografia at-rest desabilitada e até falta de mascaramento de dados. Sendo o alicerce de qualquer infraestrutura em nuvem, as estruturas de networking capturam muitos pontos de informação, que serão utilizados para detecção avançada de ataques ao seu ambiente e também na identificação de atores maliciosos ali presentes.

Até agora falamos apenas dos benefícios tecnológicos. E os benefícios financeiros? Afinal de contas, essa será a informação questionada pelos times de negócio que financiarão essas iniciativas de segurança.

O benefício financeiro está "escondido" no valor gerado pela solução de CNAPP. Não será logo de cara que os executivos da sua organização notarão o retorno financeiro da adoção do CNAPP, mas isso ficará evidente quando (e é só questão de tempo) houver um problema de segurança em algum dos ambientes da sua empresa. Um incidente grave, uma ameaça detectada, ou algo parecido. Após a rápida identificação e mitigação do problema de segurança, os analistas reportarão aos executivos (e ao CISO) o impacto no ambiente e é aí que estará escondido o valor dessa solução.

A rápida capacidade de identificação e remediação reduziu exponencialmente os danos à sua organização, poupando muuuuuuita dor de cabeça aos times de segurança e infraestrutura. É importante que os times de segurança levem esse report aos executivos para garantir o constante patrocínio para compra e manutenção das ferramentas de segurança, possibilitando a constante evolução nas camadas de proteção dos ativos da sua organização.

Microsoft Defender for Cloud

Falando especificamente da solução da Microsoft, o Defender for Cloud se apresenta como a principal ferramenta de CNAPP do mercado, tanto em capacidades funcionais quanto em cobertura. Atendendo ambientes multi-cloud (Azure, AWS, GCP e on-premise), o Defender possibilita a proteção dos workloads desde a concepção do código, ao sair da máquina do desenvolvedor, passar pelas pipelines e ter seu deploy feito em ambiente produtivo.

Para entrar em mais detalhes nas capacidades existentes no Defender for Cloud, vamos partir da seguinte imagem:

Temos mapeado acima os domínios específicos do Defender for Cloud, não havendo necessariamente um serviço do Defender para cada um dos domínios apresentados.

Com o landscape apresentado acima, podemos enxergar claramente a cobertura cloud-wide do Defender. Baseado nos 3 pilares do gartner, podemos classificar as soluções da seguinte maneira:

Artifact Scanning

No Defender for Cloud DevOps Security, temos diversos recursos de segurança aplicados nos artefatos que passam nas soluções do Azure Pipelines, Azure DevOps e Github, nesse caso protegendo não apenas os códigos das aplicações, mas também os artefatos de IaC (Infrastructure as Code) que passam por ali.

Cloud Configuration

Tudo que diz respeito às boas práticas de segurança em uma plataforma cloud estão aqui representadas. Com soluções como o Defender for Servers, Defender for Storage, Defender for Database, Defender for Container, Defender for App Service, Defender for Key Vault, Defender for APIs, Defender for DNS, Defender for Resource Manager e principalmente o CSPM habilitadas, receberemos recomendações de segurança baseadas nos benchmarks utilizados pelo Azure, que nos permitirão reforçar a configuração dos nossos recursos, reduzindo a superfície de ataque para atores maliciosos.

Runtime Protection

Os recursos de runtime protection visão garantir a proteção das plataformas de execução de aplicações. Nesses recursos, não são feitas apenas recomendações de melhora nas configurações, mas também temos a análise das possíveis ameaças que permeiam aquela plataforma.

CNAPP pode ser um conceito novo para você, da mesma forma que é um termo recente no campo da cibersegurança. É um daqueles assuntos que a cada dia que passa, ganha mais força e reconhecimento no mercado, por isso é importante ficar ligado!

Espero que tenha gostado do texto, me coloco à disposição para conversarmos sobre o tema, caso deseje.

Até logo!

Por quê conectar múltiplos tenants?

A dinâmica das organizações hoje em dia é muito diferente do que era há alguns anos atrás. A velocidade de entrega esperada pelos gestores de negócio é frequentemente impulsionada pelo uso de empresas parceiras, as chamadas "consultorias". Essas consultorias trazem expertise de mercado e profissionais capacitados para as tarefas planejadas pelos gestores.

Geralmente esses profissionais não vem em unidades, mas sim em grupos. São contratados desenvolvedores, engenheiros, arquitetos, scrum masters e tech leads, todos em somente uma "leva".

Dentro dos times de IAM da sua organização, esses casos são mais do que comuns e exigem a boa aplicação dos controles de acesso. Esses controles são implementados pelas integrações entre as ferramentas de IAM e IGA e podem deixar a transição dos consultores para a sua organização muito mais simples!

Entendendo o Cross-tenant Access

Como comentamos anteriormente, as capacidades de acesso cross-tenant existem para facilitar a integração entre diferentes tenants, sejam eles de empresas parceiras ou da mesma organização. Independente do cenário apresentado pela sua empresa, a conexão entre tenants é utilizada para disponibilizar acesso a recursos de um tenant a outro.

Um ponto que é importante endereçarmos em relação a conexão entre os tenants é a direção. A partir do seu tenant, é possível controlar o que os usuários que vem de fora (convidados singulares ou de outros tenants) podem acessar e visualizar no seu diretório, MASSSSS também podemos controlar o que os usuários do tenant da nossa empresa podem fazer em aplicações de empresas externas, conectadas ao nosso diretório. É possível controlar por exemplo se os usuários podem ou não ser convidados por tenants externos.

Hoje o Entra disponibiliza duas maneiras diferentes de colaboração entre organizações (tenants), vamos desvendar nas próximas seções as características de cada um dos métodos disponíveis.

B2B Collaboration

Este é o modelo que mais estamos acostumados, um usuário (representado por uma conta), recebe um convite para se juntar à sua organização (através do e-mail de sua escolha) ou realiza um cadastro caso esteja disponível. Uma vez inscritos (independente do método), os usuários terão suas contas criadas, utilizando como base os dados fornecidos no momento de cadastro.

Ter a conta do usuário representada no seu diretório permite que sejam aplicados os controles requeridos pelo time de segurança da sua organização em cima das aplicações expostas para os usuários. Essas contas estarão sujeitas às políticas de acesso condicional configuradas no seu ambiente, bem como aos processos de IAM da sua empresa.

B2B Direct Connect

Com o direct connect, é configurada uma relação de confiança entre o tenant da empresa parceira e da sua empresa. O tenant que esta recebendo a solicitação de conexão não recebe os usuários em sua base, fazendo com que as suas contas não sejam visíveis dentro do diretório.

Outro ponto importante de ressaltar é a necessidade de configuração dos dois lados. Como nesse modelo os objetos das organizações serão "compartilhados" entre elas, é importante que os administradores dos dois lados tenham configurado a relação de confiança.

Cross-tenant Synchronization

Diferente dos dois modelos apresentados anteirormente, essa não é uma forma de integração. Com a sincronização entre tenants, podemos automatizar a criação de contas entre os diretórios de diferentes organizações.

Esse recurso é especialmente interessante para cenários onde a colaboração entre organizações é constante e frequente, muitas vezes sendo empresas do mesmo grupo que por algum motivo, tem diretórios diferentes. Uma vez configurado, a sincronização entre tenants manterá as identidades atualizadas com as últimas mudanças feitas no tenant de origem.

Configurando os acessos

Dentro do Portal do Entra, podemos navegar até External Identities e acessar Cross-tenant Access Settings.

O portal em que caímos nos apresenta uma visualização das configurações de acesso padrão, das organizações conectadas ao nosso tenant e as opções de configuração para as instâncias "especiais" do Azure (fazendo parte desse grupo as regiões governamentais e as operadas pela 21vianet).

Organizational settings

Pensando no cenário apresentado na seção anterior sobre múltiplos tenants em uma mesma organização, neste painel podemos configurar os acessos dos diretórios que devem se conectar ao da empresa principal.

A informação obrigatória para configuração desse tenant é o Tenant ID, informação útnica de cada diretório e que permite sua identificação através da internet. Após ser configurado, a organização sofrerá o impacto das configurações existentes no Default Settings, podendo ser alteradas para configurações específicas da organização (imagine que você tenha tenants em que todo o acesso deve ser concedido mas tenha alguns onde deve-se manter restrito apenas à alguns usuários e aplicações, nesse modelo podemos determinar essas restrições e manter nosso ambiente seguro).

Default Settings

Com o propósito de proteger os ambientes de forma padrão, os Default Settings apresentam restrições que "fecham" seu tenant para conexões externas e colaborações com outras empresas.

Aqui podemos configurar os dois caminhos de acesso/sincronização, inbound (para os acessos que estão sendo feitos em nosso tenant) e outbound (para tudo que estiver sendo feito pelos usuários do tenant principal em tenants externos, que tenham colaboração ativa e configurada).

As configurações são combinações de objetos (usuários, grupos e aplicações) e ações (permitir ou negar).

Para as grandes organizações de hoje em dia, manter seus colaboradores com os acessos devidos representa produtividade, segurança e conforto. É importante garantir que o ambiente esteja protegido de atores mal intencionados e de possíveis vulnerabilidades causadas por erros de configuração.

Espero que tenha gostado do texto e que eu tenha conseguido te mostrar a importância das configurações entre tenants e o valor que elas podem trazer para a sua empresa.

Até logo!

A importância do MFA

Garantir a segurança nos acessos dos funcionários da sua organização é fundamental para a manutenção da boa operação dos ambientes em nuvem. O mercado vem aderindo à tendência de ambientes passwordless, fugindo das credenciais tradicionais e combinando fatores de autenticação que façam uso de outros recursos. Independente do modelo de autenticação adotado pela sua organização, o MFA é exigência para manter a tranquilidade e segurança do ambiente.

A solução de MFA escolhida pela sua organização irá variar de acordo com os recursos disponíveis e também com os casos de uso apresentados pelos stakeholders. As restrições que os ambientes impõem e os custos das soluções (compra, distribuição, operação, resolução de problemas) são pontos que podem rapidamente inviabilizar uma ferramenta escolhida para servir como solução de MFA corporativa.

Por isso é de extrema importância que antes de se definir às cegas qual solução deve ser utilizada na organização, os times técnicos e de negócio tenham ciência dos requisitos funcionais e não funcionais apresentados pelo negócio.

Nas próximas seções, vamos discutir as possibilidades expostas pelo Entra, bem como suas aplicações e seus controles.

MFA no Entra ID

O desenho acima nos fornece uma visão interessante sobre os diferentes tipos de MFA disponíveis no Entra ID, bem como seu posicionamento em uma escala que julga as soluções como não recomendadas (soluções à esquerda) e recomendadas (soluções mais à direita).

Note que como qualquer recomendação, as menções sobre uma solução ser boa ou ruim, são apenas recomendações. Apenas você pode avaliar uma solução como boa no contexto da sua organização, seja por capacidade de segurança ou puramente por restrições em relação ao ambiente/aplicação.

O insight que é importante tirar dessa imagem é a ida para as soluções passwordless, soluções essas que já são uma realidade há anos. Para garantir a proteção de mais alto nível para os ambientes, sua organização deve caminhar para implementar esse modelo em um futuro próximo.

Agora que interpretamos o diagrama, entraremos em mais detalhes sobre as soluções representadas acima, e em cada caso, comentaremos os motivos da colocação da ferramenta na posição onde se encontra.

Soluções disponíveis

Começando pelas senhas, são cadeias de caracteres que foram previamente cadastradas pelo usuário. Estão sujeitas aos vetores de ataque mais comuns (password spray, engenharia social, phishing, etc.). O usuário utiliza a credencial previamente cadastrada para acessar as aplicações e apenas esse primeiro fator de autenticação satisfaz a segurança do acesso.

Evoluindo a estratégia de segurança da nossa empresa, temos agora a configuração de um segundo fator de autenticação, podendo ser um OTP enviado via SMS ou via chamada de voz. O uso de qualquer um dos dois realmente eleva a segurança do acesso, mas ainda não deixa o ambiente da organização protegido da forma que deveria. Ambas as soluções são vulneráveis a ataques de engenharia social, onde é possível que um atacante engane o usuário a fornecer o código repassado a ele.

Melhorando ainda mais a segurança do nosso ambiente, temos a adoção de "2FAs" mais poderosos (porém ainda orquestrados com uma credencial). Aqui passamos a fazer uso de "algo que o usuário tem" que permite que o acesso ao nosso ambiente seja mais reforçado. Esses métodos de MFA são resistentes aos vetores de ataque mencionados anteriormente, porém o elo frágil nesse modelo são as credenciais, que ainda tornam os usuários suscetíveis a esses ataques. As soluções representadas nesse modelo são o hardware OTP tokens, os software OTP tokens e o microsoft authenticator.

PASSWORDLESS! Chegamos ao suprassumo das formas de autenticação. Nesse modelo, esquecemos completamente das senhas, não serão mais utilizadas pelos usuários da nossa organização no acesso aos sistemas da empresa. Aqui podemos fazer uso de soluções extremamente seguras e recomendadas pelas principais referências de cibersegurança do mercado. O uso das chaves FIDO2 Key, Microsoft Authenticator (somado da digital ou biometria facial para confirmação do login), certificados e Windows Hello for Business (fazendo uso da leitura biométrica ou da digital nos dispositivos que a tem disponível) possibilita uma experiência completamente sem senhas e sem os principais fardos que são gerados pelo uso delas.

Estratégias de adoção

Antes de configurarmos qualquer recurso em nosso ambiente, devemos ter ciência do que será impactado com aquelas mudanças (e principalmente se algo der errado). É importante que decisões como essa, que afetam uma organização em toda sua escala, sejam comunicadas aos usuários finais e aos times de suporte, para que saibam como agir quando forem acionados.

Outra boa prática é realizarmos o lançamento dessas funcionalidades de maneira faseada, isto é, iniciar com um grupo pequeno de usuários e com o passar das semanas incluir mais usuários nos grupos de teste, até o momento em que a organização estará madura para suportar uma migração total desses usuários.

Registration Campaign

Esse recurso do Entra permite configurar alguns controles que garantem que todos os usuários registrem seus dispositivos e habilitem o Microsoft Authenticator para que possa ser utilizado em seus acessos posteriores.

Nesse exemplo, estamos permitindo que os usuários adiem o registro do dispositivo no máximo 3 vezes, sendo obrigados a seguir o fluxo de registro após os 3 adiamentos.

Policies

Pensando em implementar controles de acordo com o método de autenticação escolhido, nessa blade podemos configurar regras de uso e também controlar quem pode utilizar determinado recurso (extremamente útil quando estamos testando ao mesmo tempo diversos métodos e queremos garantir que um não tenha interferência no outro).

Todos os métodos terão duas seções, "Enable and Target" e "Configure". Em "Enable and Target" você poderá configurar quais usuários e grupos poderão utilizar aquele recurso (pelo menos até que seja ativo globalmente no tenant), em "Configure" você entra em configurações mais específicas do método, variando de recurso para recurso.

Reporting Suspicious Activity

Um recurso interessante para incrementarmos a segurança das soluções de MFA são os alertas de atividade suspeita. Uma vez configurado, os usuários poderão notificar que estão recebendo tentativas de autenticação que não foram eles que iniciaram. Esse report classifica o acesso do usuário como de alto risco, o colocando como alvo de possíveis políticas de acesso condicional que podem estar configuradas em seu ambiente.

Algumas ações das políticas de acesso condicional podem exigir que o usuário: altere a senha ou registre novamente o dispositivo no Entra.

Weekly Digest

Com a proposta de fornecer visibilidade das atividades do tenant aos administradores, uma vez configurado, esse recurso envia e-mails semanais aos usuários e grupos cadastrados, contendo informações sobre os acessos considerados arriscados identificados pelo ID Protection.

Implementação

Indo além dos recursos mencionados anteriormente, uma peça fundamental para toda a estratégia de segurança da sua organização (não apenas para a implementação das soluções de MFA) são as Regras de Acesso Condicional. Essas regras determinam qual controle deve ser aplicado, em quais aplicações essas regras devem ser implementadas e quais usuários e grupos sofrerão os impactos dessas regras.

Com o conditional access nós podemos personalizar as atividades que devem ser cumpridas pelos usuários de acordo com os cenários que são apresentados. Nós podemos interpretar os acessos baseados no nível de risco que eles apresentam e aí sim controlar de diferentes maneiras o que deve ser feito. Podemos também implementar proteção contra os ataques mais sofisticados, garantindo a integridade máxima dos nossos ativos.

Estabeleça um padrão para criar e utilizar as políticas de acesso condicional, aplique-as de maneira faseada até que cubram todos os acessos da organização. Document corretamente o processo de montagem da política, bem como o que ela faz e quais públicos atinge. E acima de tudo, governe corretamente as políticas do seu ambiente, para evitar que políticas existentes sejam muito alteradas e percam seu propósito. Essas mudanças sem histórico podem gerar riscos sérios por não serem planejadas e deixarem alguma "porta aberta" no seu tenant.

Arquitetura

Pensando em unificar todos os pontos que tratamos nesse artigo, trago esse desenho de alto nível que demonstra todas as capacidades que utilizariamos para implementar uma arquitetura que disponibiliza aos usuários uma série de soluções de MFA e ao mesmo tempo, implementa controles de segurança para garantir a integridade dos dispositivos e dos acessos.

Todos os recursos devem ter seu uso bem planejado e configurado, sempre tendo em mente o usuário final.

Sua empresa não terá ganhos se implementar controles e proteções que dificultam o dia a dia do usuário. Sistemas com usabilidade ruim (por excesso de controles ou aplicação errada dos mesmos) fará com que os usuários busquem caminhos alternativos para acessar aquela aplicação, não seguindo os baselines determinados pelos times de segurança.

Outro ponto que é importante destacar é a visibilidade do ambiente. Precisamos ter monitoramento constante por parte das ferramentas de SIEM da sua empresa nos eventos privilegiados gerados no seu tenant. Isso garantirá que as atividades consideradas suspeitas possam ser avaliadas pelo time de SOC da organização, garantindo um controle ainda mais granular e efetivo em cima dos acessos.

Não é de um dia para outro que uma organização passa a adotar soluções de MFA de maneira corporativa, isso leva tempo. O importante é que caso sua organização ainda não tenha esses controles implementados, você comece levantar os riscos de ter o ambiente tão desprotegido.

Esse artigo foi construído para te fornecer um ponto de partida para iniciar a implementação do MFA, sugerindo alguns controles e mencionando os principais recursos, utilizados em quase todas as arquiteturas.

Espero que tenha gostado, nos vemos na semana que vem.

Até logo"

O que são Passkeys?

Com a tendência de desativação das tradicionais senhas por problemas de segurança e usabilidade, os métodos de autenticação passwordless surgem como principais opções para a autenticação dos usuários.

Dentro desse grupo, temos como novo integrante as Passkeys!

As passkeys foram criadas e divulgadas pela FIDO Alliance, uma das principais referências quando o tema é identity security. A proposta cumprida pela criação das passkeys foi: deixar os acessos mais seguros, ao mesmo tempo fornecendo para o usuário maior conforto em seu uso.

Com o uso de uma passkey para se autenticar na aplicação, o usuário se beneficia do uso de um dos fatores de autenticação configurados para acessar aquele dispositivo (sendo um PIN ou sua biometria) para confirmar o acesso a aplicação. O "cumprimento" dessa etapa de autenticação permitirá que o processo de interação com a aplicação seja concluído.

Como elas funcionam?

Antes de entrarmos no detalhe sobre como as passkeys funcionam, é importante deixar claro que o pré-requisito para as utilizarmos é: a plataforma que estamos acessando deve fornecer suporte a esse método de autenticação. Isso se dá por conta das interações que serão feitas entre cliente e servidor, sendo necessário validar o "desafio" gerado pelo evento de autenticação.

Após garantirmos que a plataforma que será utilizada suporta o uso desse método de autenticação, chegou a hora de entrarmos no detalhe sobre o que mais é necessário e como ocorrem as interações.

As passkeys contém 2 componentes principais utilizados em suas interações:

• Chave Privada - armazenado no cliente (dispositivo do usuário)

• Chave Pública - armazenada no servidor da aplicação

A chave pública será gerada à partir da chave privada e enviada ao servidor de aplicação, onde será armazenada. Quando um fluxo de autenticação for executado, um "desafio" será enviado para o dispositivo do usuário. Será solicitado que o usuário desbloqueie o dispositivo, "assinando" o desafio e retornando para o servidor, que validará o resultado da assinatura, garantindo que o usuário autenticado é o detentor daquela passkey.

Esse é de maneira simplificada, o processo de uso de uma passkey. Antes do uso, temos seu cadastro, que se dá dessa forma:

O usuário inicia a interação na aplicação web selecionando a opção de "criar uma passkey". A partir dessa interação, o back-end iniciará o processo de criação da passkey, enviando ao dispositivo a solicitação para criação da chave privada e chave pública e recebendo a própria chave pública, gerada após o desbloqueio do dispositivo pelo usuário.

Após a criação da passkey, toda vez que for se autenticar na aplicação em questão, o usuário poderá selecionar a opção "login with passkey". Receberá uma solicitação para selecionar a passkey e se autenticará utilizando um PIN ou uma biometria.

E é isso!

Um exemplo de aplicação que tem o uso das passkeys habilitado é o GitHub. Logo na primeira página (formulário de login) você será questionado se deseja acessar sua conta utilizando uma passkey ou seu conjunto de credenciais padrão (usuário + senha + 2FA).

Ao clicar em "sign in with a passkey" você receberá uma tela parecida com essa:

Esse prompt é do Windows Hello e permite que você selecione com qual passkey deseja autenticar na aplicação.

Você também tem a opção de utilizar uma passkey diferente, como por exemplo uma existente em outro dispositivo.

Benefícios

Sendo um método de autenticação phishing resistant, temos bem claro que a segurança contra vazamentos de dados e roubo de credenciais são benefícios herdados quando utilizamos esse método de autenticação.

Do ponto de vista do usuário, o fato de não ser mais necessário recordar as credenciais para todos os acessos traz conforto e confiança no momento de acesso à aplicação. Do lado da aplicação, não se preocupar com armazenar informações sensíveis e protegê-las contra o vazamento de dados retira uma significativa carga de trabalho dos administradores.

Outro benefício das passkeys que nenhum outro método de autenticação tem é o "link" com informações que não podem ser utilizadas por outros usuários. Em dispositivos que contém o windows hello for business, você pode utilizar sua biometria facial para acessar sua conta. Esse recurso garante que você (e apenas você) possa acessar aquela conta com a passkey selecionada.

O futuro é passwordless e o quanto antes as organizações implementarem esse novo modelo de acesso, mais rápido os times de segurança e os usuários poderão usufruir dos benefícios gerados pela sua adoção.

Espero que tenha gostado do texto e nos veremos em breve.

Até logo!

Importância do Zero Trust

A guinada das empresas para a nuvem pública levantou uma série de preocupações para os times de segurança.

Com menos controle sobre o ambiente, como será possível garantir a segurança em todas as etapas do processo?

Esse questionamento é gerado pela experiência dos administradores em manter ambientes próprios, onde o controle de acesso à infraestrutura era de completa responsabilidade da empresa, devendo garantir a proteção do acesso físico e também dos acessos lógicos.

Essa perspectiva foi alterada com a chegada da nuvem pública e seu modelo de responsabilidade compartilhada. Agora, os administradores e times de segurança só precisam se preocupar com o acesso lógico aos seus ambientes e soluções. Essa "redução" de responsabilidade pode representar uma maior facilidade na manutenção dos ambientes, porém para os usuários de ambientes em nuvem mais experientes, essa afirmação é completamente enganosa.

Com isso estabelecido, podemos tratar do "novo" modelo de segurança recomendado para os ambientes em nuvem pública, saindo do modelo de 3 camaddas e chegando com o modelo Zero Trust.

Identidade nos 3 pilares

Centralizando nossa estratégia de segurança nas identidades, chegou a hora de avaliarmos o comportamento de cada um dos princípios e também a aplicação de alguns controles que nos permitirão ter sucesso em nossa implementação.

Minimum Privilege

Toda e qualquer operação dentro do nosso ambiente será executado por uma identidade, que terá o permissionamento necessário para executar tal ação. Independente do tipo de identidade utilizada (humana para ações executadas por usuários e sistêmica para atividades comandadas por aplicações), sempre teremos uma conta por trás da ação, permitindo primeiramente a autenticação e posteriormente a autorização da credencial.

Pensando na execução da estratégia e implementação do pilar, temos o RBAC (Role Based Access Control) como principal "aliado". Ao utilizarmos o mecanismo de RBAC do nosso Cloud Provider é possível granularizar o acesso aos recursos da plataforma, sejam eles feitos por usuários humanos ou contas de sistema.

Atribuindo acesso apenas ao escopo necessário e com as permissões controladas para que a identidade possa realizar as ações requeridas, nós reduzimos a capacidade de danos que podem ser feitos ao nosso ambiente, caso aquela credencial seja comprometida ou o usuário por trás dela tenha más intenções.

O simples desenho acima mostra a aplicação das roles em diversos tipos de identidades (e trambém grupos) e seu uso para acessar os recursos da plataforma. Temos também o uso do PIM, feito para acessos privilegiados dentro do Azure e do Entra.

Verify Explicitly

O nosso segundo pilar exige a validação de todas as requisições feitas para a plataforma, independente de quem esteja fazendo.

Para requisições feitas para as APIs do cloud provider esse conceito é aplicado por padrão. Todas as chamadas exigem que as credenciais do usuário que está acessando o recurso, sejam validadas. Quando utilizamos identidades sistêmicas (tanto service principalls quanto managed identities), as validações são as mesmas, sendo feitas pelo Entra a cada chamada.

O desenho abaixo mostra de maneira simplificada e sem detalhes de implementação, como as requisições são feitas e autorizadas pelo IdP:

As chamadas à plataforma são feitas utilizando um access_token, gerado pelo Microsoft Entra ID e vaildado a cada passo da jornada.

Assume Breach

O último dos pilares determina que devemos tratar todo o nosso ambiente como "hostil", assumindo que todos os acessos são inseguros.

A aplicação desse princípio permite assegurar que a identidade que está realizando o acesso é de fato uma identidade válida e poderá ter sua requisição permitida após todas as validações necessárias.

Dentro da plataforma, outros controles devem ser aplicados para satisfazer esse pilar, porém com as nossas identidades, deveremos validar diferentes pontos de informação para garantir que aquela conta não está sendo utilizada indevidamente.

O uso de algumas dessas funcionalidades requer a adesão de recursos extras, como licenças do Entra e também o Microsoft Intune, para gestão dos dispositivos.

Garantindo os controles com o Microsoft Entra ID

Na seção anterior falamos sobre os pilares que compõem o Zero Trust e como as identidades podem se tornar o centro de cada um deles. Utilizando o Microsoft Entra ID, podemos implementar controles robustos, que permitirão proteger o acesso aos nosso recursos.

• Azure RBAC e Entra RBAC: utilizados para permissionar o acesso aos recursos, o acesso baseado em funções do Azure e do Entra nos permite aplicar o minimum privilege, oferecendo diferentes escopos de acesso e níveis de privilégio;

• Certificados, Credenciais e Passwordless: para o verify explicitly podemos configurar para a identidade diferentes tipos de autenticação. Para identidades de aplicação, temos disponíveis apenas as credenciais e certificados, porém para contas humandas, podemos configurar todas as opções existentes;

• Conditional Access: recurso utilizado em todos os pilares, as políticas de acesso condicional nos permitem avaliar uma série de informações sobre um acesso feito por uma identidade. É com essas políticas que nós poderemos validar a origem da chamada feita pela identidade, o dispositivo que está sendo utilizado, o risco da atividade, entre outras informações.

Esses controles somados às soluções existentes do Azure (como as Azure Policies) garantirão a excelência da postura de segurança da sua organização, bem como a boa operação das jornadas de negócio!

Identidade é um tema quente nas comunidades de cibersegurança, por isso é importante que você e sua organização estejam preparados para aplicar os controles mais modernos com o intuito de proteger seu ambiente da melhor maneira possível.

Espero que de alguma forma eu tenha conseguido contribuir com a melhora na segurança do seu ambiente e que tenha gostado do texto.

Até logo!

Entendendo o Conceito

Dentro do seu ambiente de nuvem pública (independente do provedor), os diversos workloads que estarão sendo executados precisarão de uma forma para autenticar e autorizar o consumo dos seus serviços e dos recursos de plataforma. Esses dois processos se dão por meio das chamadas Identidades de Aplicação (ou Workload IDs).

Ter bem estabelecida uma boa estratégia de autorização na sua organização é essencial para a boa manutenção do seu ambiente e para a aplicação do Zero Trust, por isso é de extrema importância que os times de segurança e arquitetura definam os baselines para uso dessas identidades e as melhores práticas de acordo com o fornecedor e com a empresa.

Estratégias para a proteção das identidades

Como qualquer identidade, o IdP (Identity Provider) necessita de algumas informações para validar a veracidade daquele recurso. Se tratando do Microsoft Entra ID (Identity Provider da Microsoft), nós temos duas maneiras de identificar o nosso workload id:

• Object ID + Secret

• Object ID + Certificate

As duas formas tem seus pontos positivos e negativos, vamos comentar sobre eles agora e entender melhor esses pontos e as características de cada um dos métodos.

Secret

Os segredos (também conhecidos como "senhas") são utilizados pela aplicação em questão para autenticar a chamada frente ao Identity Provider. Em todas as requisições, tanto o Object ID (que representa a aplicação perante do IdP) quando o Secret, devem ser transmitidos, para que o provedor de identidade consiga validar a veracidade daquela chamada.

As secrets são strings que apenas através da visualização a olho nu, não representam nada, porém devem ser guardadas a "sete chaves" pelos times de segurança da organização, visto que são valores sensíveis e que se expostos, poderão representar alto risco ao ambiente.

Por serem geradas diretamente no Identity Provider, a gestão das secrets pode ser considerada mais complicada pelo time de segurança, visto que novos processos e controles deverão ser implementados para identificar a expiração de uma secret, sendo necessário renová-la antes da expiração para evitar a interrupção nos serviços que utilizam aquelas credenciais.

Outro problema frequentemente enfrentado é o envio das secrets para os repositórios de código. Por serem utilizadas direto no código, é possível que algumas secrets sejam enviadas para o repositório de código da sua organização. Isso é especialmente perigoso caso o repositório seja público, expondo a secret para qualquer um que acessar o repo. Para evitar esse problema, é importante termos dentro da pipeline de desenvolvimento, controles para identificar essas secrets que foram enviadas de maneira errônea, reduzindo ainda mais a chance de termos problemas de segurança.

Certificate

Os certificados são "objetos" de segurança utilizados de diversas maneiras. Nesse caso, o utilizariamos para identificar uma identidade e garantir que a mesma é valida dentro do nosso tenant.

Diferente dos segredos, um certificado não é apenas uma string, ele tem uma série de outras informações e atributos próprios, que permitem qualquer uma das partes possa identificar o certificado em questão e validar sua veracidade.

Os certificados devem ser gerados por uma autoridade certificadora confiável e devem ser carregados dentro do Microsoft Entra ID, sendo referenciados diretamente na identidade criada. Dessa forma, o identity provider consegue validar o certificado e garantir que o mesmo não tenha sido revogado.

Ainda fazendo referência aos certificados, seu uso é mais recomendado que o das secrets pois não só porque não são passados diretamente no código, mas também por conta dos processos de gestão de certificados já existentes na sua empresa. Por ser uma solução utilizada de diversas maneiras nas organizações, é costume que as empresas já tenham uma boa gestão desses objetos, pois a má gestão pode levar a interrupções nos serviços fornecidos pela organização, impactando não apenas clientes internos mas também os clientes finais.

Estratégias de proteção

Não importa se estivermos falando sobre secrets ou certificates, algo imprescindível é a boa gestão de expiração e distribuição desses objetos. Visando manter seus serviços disponíveis e sem interrupções, identificar quando um objeto estiver próximo da expiração permitirá que os times de segurança e engenharia atualizem o recurso em questão (manualmente ou via automação). O envio de alertas quando o objeto estiver próximo do vencimento facilitará esse trabalho.

Aplicar regras de acesso condicional pode reduzir drasticamente a possibilidade de uso de uma credencial comprometida. Criar regras referêntes à localização de onde vem a requisição possibilitará a recusa de conexões vindas de localidades não reconhecidas. Isso pode ser feito utilizando as Named Locations do Entra, que permitem o cadastro de ranges de IP para que possam ser utilizados posteriormente dentro das políticas de acesso condicional.

Como qualquer identidade dentro do Entra, as workload IDs também geram logs. Esses logs são objetos extremamente valiosos para o reforço da postura de identidade da organização, pois permitem validar para o que a identidade foi utilizada.

Explorando o Workload IDs do Microsoft Entra ID

Dentro do Microsoft Entra ID, as workload IDs podem ser visualizadas em um painel centralizado, parecido com esse:

Podemos visualizar a quantidade de identidades que temos dentro do nosso tenant, também separado pelo tipo de identidade.

Ter visibilidade e controle do que é criado no seu tenant é de extrema importância, para que os recursos possam ser bem governados e terem seu ciclo de vida gerenciado e acompanhado pelos times responsáveis.

Além disso, ao rolar a página para baixo, temos uma série de recomendações de melhores práticas fornecidas pela Microsoft, que podem ser acessadas e implementadas para incrementar os controles do seu ambiente.

As identidades são o objeto central dentro da estratégia Zero Trust de todas as empresas, porém não podemos pensar que identidades são apenas de usuários humanos. Negligenciar as contas sistêmicas pode se tornar um problema de forma repentina caso sua empresa não tenha controles bem estabelecidos e ajustados.

Espero que tenha gostado do texto e que de alguma forma eu tenha conseguido contribuir com o seu planejamento de segurança.

Até logo!