Pedro's blog

Adoção de MFA (+ capacidades do Entra ID)

Tue, 07 Nov 2023 03:00:00 GMT

Fator importante para o sucesso das políticas de segurança de acesso da sua empresa, a adoção do MFA não consiste apenas em escolher um (ou mais) métodos de autenticação. Hoje falo sobre alguns fatores que devem ser considerados para que a sua estratégia seja efetiva!

Definição da estratégia

Planejar a estratégia para adoção de MFA pode ser algo muito estressante. É importante abordar não apenas aspectos técnicos, mas também processuais, sempre pensando no usuário final, que sofrerá os impactos da implantação dos novos processos e das novas tecnologias.

Aspectos não-técnicos que devem ser considerados

Algo de extrema importância que deve ser reconhecido no início do planejamento é a maturidade da sua organização quanto às tecnologias existentes. Tendo em mente a segurança dos acessos, escolher um (ou mais) fator de autenticação que permita à organização ter suporte aos usuários finais, bem como um bom gerenciamento dos dispositivos é essencial.

Aqui vão algumas necessidades que você encontrará ao longo da sua jornada e que podem te poupar muito tempo se você se planejar antecipadamente:

Suporte: com toda certeza, seus usuários precisarão de ajuda com a tecnologia, seja para configurá-la, para utilizá-la ou por algum outro motivo. Garanta que seus recursos do time de suporte saibam como orientar e solucionar os problemas dos usuários;
Guia: fornecer aos usuários um documento que contenha todas as informações que eles precisam saber sobre a nova tecnologia, pode economizar muitos esforços para suas equipes. O guia deve conter:
- Processo de instalação e configuração da solução (utilize imagens e ilustrações para facilitar o entendimento do processo até por funcionários das áreas não técnicas);
- Passo-a-passo sobre a utilização da ferramenta;
- Possíveis problemas que o usuário pode encontrar durante sua ativação (caso mapeado, economizará muitos esforços do time de suporte e do time responsável pela ativação);
- Contatos para apoio (uma lista com alguns contatos que possam apoiar os usuários nos novos processos definidos).
Comunicação: usufruir dos meios de comunicação internos da organização é essencial para informar os usuários das mudanças que estão ocorrendo;

Aspectos técnicos que devem ser considerados

Agora pensando nos recursos técnicos que você deve levar em conta, temos:

Soluções de MFA: temos uma série de soluções disponíveis que podem ser utilizadas como MFA, quando estiver escolhendo as soluções que farão parte do conjunto de tecnologias da sua empresa, deve-se levar em conta a maturidade da organização em relação aos processos necessários para utilizar aquela solução;
Compatibilidade: algumas soluções (como o windows hello for business) contém pré-requisitos para sua utilização. Antes de escolher uma solução, deve-se avaliar o estado das ferramentas fornecidas pela organizçaão bem como sua compatibilidade com a solução desejada;
Grupos de teste: a adoção de novas tecnologias sempre é feita com pequenos grupos de usuário, para fins de teste. Escolha bem seu público para testes, pois o resultado dos testes não é o único ponto que deve ser registrado, mas também o feedback desses usuários, visando melhorar a experiência dos outros usuários da organização.

Após falarmos sobre os problemas que você pode enfrentar quando estiver construindo a estratégia de adoção de MFA na sua organização, vamos falar sobre alguns recursos do Microsoft Entra que podem te ajudar a tornar todo o processo mais simples e menos doloroso para os usuários.

Recursos

Depois de comentarmos sobre alguns pontos que podem fazer sua jornada rumo à adoção de soluções de MFA mais simples, é hora de falarmos dos recursos que podem facilitar essas tarefas.

Essa seção é destinada puramente à soluções de tecnologia, as soluções para as questões processuais serão abordadas em uma sessão posterior.

Soluções do Entra

O Entra ID nos oferece uma série de funcionalidades que visam diminuir as dores encontradas pelas empresas em seus processos de modernização tecnológicas. Desde campanhas para registro de MFA até soluções sofisticadas de análise de segurança, temos diversas capacidades fornecidas dentro de uma mesma interface, o Portal do Entra.

A imagem acima divide em 3 categorias principais (+1 de bônus) os recursos que podem ser utilizados. Vamos aos detalhes em cada uma delas.

Soluções de MFA

Dentro dessa categoria, utilizamos recursos que nos permitem visualizar as opções de soluções disponíveis e realizar algumas configurações préviamente à sua ativação.

Policies - as policies centralizam as configurações dos fatores de MFA disponíveis. Dentro dessa sessão, você consegue visualizar não apenas os modelos de autenticação multi-fator disponível, mas também configurá-los e habilitá-los para utilização pelos usuários da sua empresa. As imagens abaixo mostram a lista de modelos disponíveis e um exemplo de configuração possível.

A imagem acima é referente à configuração do SMS como solução de MFA. Nela podemos visualizar o toggle que deve ser usado para habilitar/desabilitar o modelo e também podemos incluir grupos específicos que poderão usufruir desse modelo de MFA.

Authentication Strengths - visando sua implementação utilizando as políticas de acesso condicional, o authentication strength permite agrupar um conjunto de modelos de autenticação multi-fator para exigir seu uso em determinados cenários. Por padrão, temos 3 conjuntos comuns já criados: multifactor authentication, passwordless mfa e phishing-resistant mfa.

A imagem acima mostra uma das authentication strengths existentes no tenant. Ela engloba todos os métodos de MFA disponíveis na plataforma e como podemos visualizar na última coluna, ainda não está aplicada em nenhuma política de acesso condicional.

Você também pode criar seu conjunto de dispositivos conforme desejar. Esse recurso será útil quando sua organização definir os MFA que poderão ser utilizados e você quiser exigir um (ou mais) deles quando um usuário tentar executar determinada tarefa.

Adoção do MFA

Para uma política efetiva de ativação de MFA, como foi apresentado anteriormente, é necessário uma junção dos recursos técnicos e dos processos.

Registration Campaign - essa funcionalidade nos permite configurar de quanto em quanto tempo os usuários serão “avisados” para configurar seu dispositivo de MFA.

A imagem acima mostra as configurações disponíveis para as campanhas. Podemos destinar à um grupo de usuários específicos, bem como configurar quantas vezes e por quanto tempo o usuário poderá adiar essa configuração (para garantir efetividade nos processos da sua empresa, devemos desabilitar a possibilidade de adiamento ou configurar um período de tempo curto).

Segurança

Visando proteger os usuários e também o tenant, as funcionalidades listadas abaixo permitem que os usuários denunciem atividades suspeitas em seus aplicativos bem como habilitam que os sistemas da Microsoft identifiquem atividades suspeitas automaticamente.

Suspicious Activity - se habilitado, permite que os próprios usuários denunciem atividades suspeitas. Esse modelo está disponível para configurações de MFA que utilizam ou o aplicativo Microsoft Authenticator ou as chamadas por voz.

Account Security - com a proposta de proteger a conta do usuário de ataques do tipo spray, podemos configurar limites de tentativas de autenticação que utilizam o aplicativo Microsoft Authenticator. Essa configuração tem efeito apenas para os usuários que utilizam do PIN para confirmar a autenticação no aplicativo.

Fraud Alert - essa funcionalidade permite que os usuários denunciem notificações de autenticação que não foram iniciadas por eles. No painel abaixo, vemos que é uma possibilidade bloquear automaticamente os usuários que reportarem fraude, com a intenção de proteger o tenant e a conta.

Adicionais

One-time Bypass - não é exatamente um recurso atrelado às soluções de MFA, mas vale sua menção. Essa funcionalidade nos permite configurar um “escape” temporário da utilização do MFA. Esse é um cenário bem comum nas empresas e com certeza você vai se deparar com ele. Aqui configuramos um curto espaço de tempo onde o usuário poderá realizar o login e acessar a plataforma sem realizar a autenticação multi-fator. Uma vez que esse tempo expirar, ele será redirecionado à página de login, onde deverá realizar a autenticação MFA ou não poderá acessar os recursos que deseja.

Supressão das notificações - recentemente implementada, essa funcionalidade “esconde” a notificação que normalmente apareceria no seu dispositivo solicitando a aprovação da autenticação. Baseado em alguns riscos (como viagem atípica e IPs de origem anônimos), isso evita que o usuário receba notificações indesejadas. É importante apontar que mesmo as notificações sendo escondidas, a solicitação para autenticação ainda é existente, então caso o usuário abra o aplicativo ele será apresentado com a necessidade de permitir/negar a solicitação.

Soluções processuais

Tendo em mente os problemas enfrentados pelos usuários e os as pontuações que fiz no início do texto, vamos comentar sobre como podemos solucionar aqueles problemas processuais de maneira satisfatória.

Guia - para construção do guia você pode utilizar qualquer ferramenta de edição de texto. Optando por uma solução como o Microsoft Word ou Google Docs você tem mais possibilidades de exercitar a criatividade e construir um documento completo e compreensível, com imagens, enfoques no texto, divisão de sessões, links, endereços de e-mail, tabelas, etc.

Estruture bem seu documento para evitar deixá-lo confuso e incompreensível. Verifique a ortografia, se os links e informações de contato estão corretas e se o documento aborda todas as informações consideradas necessárias pelo seu time. No final do processo, salve o arquivo como .pdf e o mantenha em um local de fácil localização e acesso para que as outras áreas possam acessá-lo (cuidado com a restrição de acesso, colocar o documento em um local onde o acesso é controlado de maneira granular irá gerar um estresse inesperado para ambas as partes, usuários e times de tecnologia).

Comunicação - para um processo de comunicação efetivo é necessário utilizar os canais selecionados de maneira consistente e visando abranger a maior parcela da organização possível. Um meio efetivo de comunicação é o e-mail, por ser utilizado por toda a organização de maneira consistente (garantindo um maior alcance dos usuários) e para organizações que fazem uso de mensagens periódicas enviadas para grandes grupos da organização (ex: departamentos de tecnologia, gerentes, equipes de customer success) esses destinatários podem ser reaproveitados, tirando a necessidade de se realizar um mapeamento das equipes.

Alinhamento com Suporte - pensando em efetivar o processo de solicitação de suporte por parte dos usuários, é importante que os analistas responsáveis por solucionar as questões apresentadas pelos usuários estejam cientes das demandas e de como devem proceder em cada caso.

Fluxo de excessão - como é impossível prever o futuro e acertar 100% dos casos existentes, é importante que os usuários tenham a possibilidade de executar um fluxo de suporte alternativo, para problemas não mapeados e não registrados anteriormente (nas fases de teste e durante a adoção). Para isso, é uma estratégia interessante indicar alguns analistas da equipe que está conduzindo o projeto como pontos focais para esse contato, fazendo uso de seu conhecimento do projeto e da integração que os mesmos tem com as outras áreas.

A mudança cultural e tecnológica de uma empresa que está iniciando a adoção de novas soluções de autenticação não é simples, porém com um bom planejamento é possível obter êxito mesmo com todas as dores de cabeça que serão geradas ao longo do caminho.

Espero que tenha gostado do texto e que de alguma forma eu tenha conseguido te auxliar nessa jornada.

Até mais!

Aplicações no Entra ID

Wed, 10 Jan 2024 03:00:00 GMT

Em um ambiente empresarial, é comum que tenhamos diversos tipos de aplicações conectadas às nossas soluções. O principal modelo hoje em dia são as aplicações SaaS (Software as a Service) mas não podemos nos esquecer das soluções on-premise, ou instaladas em servidores/máquinas virtuais e também das aplicações desenvolvidas de maneira personalizada, de acordo com a necessidade de negócio. Hoje vamos falar sobre como independente do modelo, é possível integrar essa aplicações ao Entra ID.

Qual a importância de conectarmos os apps no IdP?

Peça fundamental na estratégia de segurança das empresas, os Identity Providers centralizam as operações e controles relacionados às identidades da empresa. Nesse contexto, para garantirmos a boa governabilidade dos acessos às aplicações, é importante que o componente central dessa arquitetura seja o resposável por fornecer essas permissões.

Para conseguirmos implementar esse modelo, precisamos garantir que as nossas aplicações (independente do modelo) estejam “plugadas” ao IdP, no escopo deste artigo, o Microsoft Entra ID.

Com essa estratégia implementada, todos os controles de segurança poderão ser aplicados aos usuários e aplicações sem falhas. Usuários perderão seu acesso quando for requisitado, as renovações de acesso serão disparadas quando configuradas e essas são apenas algumas materializações do que essa arquitetura poderá garantir.

Tipos de aplicação

Pensando na pluralidade dos ambientes encontrados nas organizações, é necessário que nós estejamos cientes dos modelos de aplicações que devem existir. Abaixo, temos uma lista dos modelos mais comumente encontrados.

Aplicações Federadas

Modelo mais simples e frequentemente encontrado nas empresas. Essas soluções são adquiridas pelas empresas já prontas, seja em formato SaaS (Software as a Service, modelo mais popular) ou havendo a necessidade de instalação da solução em recursos de infraestrutura controlados pela empresa (máquinas virtuais, PaaS como o Azure App Service, Kubernetes, etc.).

Essas soluções são integradas ao Entra ID utilizando protocolos como SAML 2.0 e OIDC. Esses protocolos permitem a configuração das chamadas federações.

Federação é o conceito de conectar uma aplicação à um provedor de identidade externo e delegar para esse provedor todas as atividades de autenticação, não havendo necessidade de se ter uma base de usuários local.

Temos no Entra ID uma lista com todas as aplicações com integração out-of-the-box, integrações essas que basta a troca de algumas informações entre as partes e a conexão está feita. Podes acessar a lista clicando neste link.

Aplicações Customizadas

Essas aplicações são desenvolvidas pelos times de engenharia das empresas. Utilizam algum tipo de interface (como uma biblioteca) para se comunicar com o IdP. No Entra utilizamos a MSAL (Microsoft Authentication Library), que contém diversas versões para as tecnologias mais populares do mercado (ex: Angular, JS, .NET).

Os desenvolvedores irão construir a aplicação, sua lógica de negócio (processamentos, integrações com outros serviços e aplicações) e a interface de comunicação com o Entra. O único insumo estritamente necessário é a criação de um objeto de aplicação (App Registration), que representará a identidade daquela solução mediante aos outros recursos existentes.

Recursos adicionais como App Roles, grupos e consentimento podem ser configurados de acordo com a necessidade daquela aplicação.

Por mais que essas aplicações tenham sido desenvolvidas de maneira customizada pela organização, dentro do Entra elas terão as mesmas capacidades das soluções “prontas”, abordadas na seção anterior. Os mesmos controles de segurança implementados poderão ser configurados nessas ferramentas.

O modelo de aplicações personalizadas permite o uso dos Authentication Contexts, recurso esse que fornece uma camada adicional de segurança para acesso à informações privilegiadas.

APIs

Sendo uma funcionalidade específica do Entra, não necessáriamente aplicável à outras ferramentas de mercado, temos a capacidade de integrar APIs publicadas no Azure API Management e utilizar os tokens gerados pelo Entra para realizar a autorização dentro das aplicações.

À partir dessa funcionalidade, podemos configurar no Entra para que as claims necessárias para realizar a autorização na API sejam enviadas no token. Para isso, declaramos na configuração da aplicação no Entra as chamadas app roles.

As App Roles são valores configurados no objeto da aplicação (app registration) e que representam as informações necessárias para sua API realizar o processo de autorização.

Aplicações Legadas (application proxy)

![Publicar aplicativos locais com o Proxy de Aplicativo do Microsoft Entra - Microsoft Entra ID | Microsoft Learn](https://learn.microsoft.com/pt-br/entra/identity/app-proxy/media/what-is-application-proxy/azure-ad-application-proxy-authentication-flow.png align=“center”)

Outro recurso interessante e extremamente útil para organizações que contém muito legado, é o Entra ID Application Proxy. Esse componente permite integrar no Entra ID essas aplicações que precisariam passar por algum tipo de modernização, sem a necessidade de reformulação de código ou de re-deploy da solução.

O proxy é um agente instalado no servidor onde a aplicação é executada. Ele é configurado no Entra ID e servirá como a interface para autenticação nessas aplicações.

Esse agente permitirá utilizar os recursos de segurança existentes (como conditional access e MFA) no acesso à solução, capacidade que será útil em momentos de modernização do landscape de ferramentas da sua organização para soluções de negócio críticas e que tem necessidade de maior proteção.

Como qualquer implementação, a implementação do Application Proxy requer análise dos requisitos. Mesmo suas capacidades sendo úteis em diversos cenários, é importante a avaliação pelos times responsáveis, pois mesmo habilitando as capacidades modernas fornecidas pelo Entra, esse componente tem interdependências com outras soluções, como o Active Directory, o que pode gerar certo desequilíbrio na performance.

Segurança das aplicações

Não poderia encerrar esse texto sem ao menos mencionar as estratégias de segurança para essas aplicações.

Independente do modelo, as aplicações serão visíveis à partir do Entra ID, o que nos permite aplicar (quase todos) os controles tangíveis à plataforma em todas as aplicações. Controles que são esses:

Conditional Access: um dos recursos mais poderosos do Entra, é completamente compatível com as aplicações. Podemos definir políticas de risco de acesso, autenticação multi-fator baseada em risco, controle de acesso por localidade, acesso de dispositivo compliant, entre outras capacidades;
Grupos de acesso: uma outra boa estratégia para controlar o acesso às aplicações é a configuração de grupos de acesso. Aqui cria-se um grupo que será atribuído à aplicação, dessa forma apenas os usuários presentes nesse grupo terão acesso ao app. Usuários não presentes nos grupos cadastrados poderão tentar acessar a aplicação, porém receberão um erro no momento da tentativa de login;
Revisões de acesso: para garantir que os acessos às aplicações são feitos apenas pelos usuários necessários, podemos configurar as revisões de acesso, que podem ser feitas periódicamente (disparadas à cada X dias). Se configuradas de uma maneira em que o gestor da aplicação faça a gestão dessas revisões, o fluxo de controle de acesso ficará eficiente e autocontido no time responsável pelo app.

Vale mencionar novamente os Authentication Contexts, que podem ser utilizados junto das Conditional Access Policies para garantir o acesso seguro a informações confidenciais presentes nas soluções.

Esses são alguns controles de segurança representados em alto nível, podemos aumentar a granularidade do controle e fortalecer a proteção ao personalizar as confugrações desses recursos.

Em uma época onde é cada vez mais comum a aquisição de soluções ao invés de desenvolvimentos proprietários, não é possível mensurar a importância do controle de acesso pelas empresas. Soluções sendo executadas em diversas localizações geográficas, acessadas por times em lugares diferentes do país (e até do mundo), com dispositivos de diversas plataformas e fabricantes, tudo isso resultando em um ecossistema altamente complexo e descentralizado. A convergência em um componente controlado pela organização, permite a aplicação das políticas de segurança necessárias para garantir a proteção dos recursos da empresa.

Espero que tenha gostado do texto e que de alguma forma eu tenha contribuído para a estratégia de segurança da sua empresa.

Até logo!

AZ-104 — Microsoft Azure Administrator Associate

Sun, 02 Jul 2023 03:00:00 GMT

Uma das provas mais difíceis que já fiz mas também uma das mais legais. A AZ-104 é a porta de entrada de muitos nas certificações de nível associate.

Para quem realizou a AZ-900 (Azure Fundamentals), saiba que essa prova é um passo grande na sua carreira e que exigirá muito esforço, mas no final das contas valerá a pena.

Hoje vamos falar um pouco sobre a prova em si, minha experiência com o teste e com a preparação, e no final te darei algumas dicas para que seja bem sucedido na sua tentativa.

Sobre o exame

Como comentei anteriormente, essa prova é totalmente diferente da sua antecessora. Enquanto as provas de fundamentos tratam conhecimentos gerais da plataforma e dos serviços, as provas de nível associate exigem que você tenha conhecimento dos serviços à nível de implementação.

Não existe ao certo um número de questões, quando fiz a prova, me deparei com 54 questões, mas já ouvi relatos de amigos que fizeram provas com mais e com menos questões.

Mesmo não podendo dizer ao certo quantas questões o exame terá na sua tentativa, as provas compartilham alguns modelos de perguntas.

Conhecimentos gerais

Todas as perguntas serão sobre os serviços abordados nos tópicos do exame. Você deve saber como criar os serviços, suas peculiaridades, possíveis configurações e integrações com outros recursos da plataforma.

Dentro dessas perguntas, espere de tudo, networking, logging, monitoring, compute, storage, etc. As perguntas serão das mais variadas mas sempre se mantendo dentro da estrutura declarada do exame.

Você precisará saber se um serviço pode se integrar com outro da forma que foi criado (você receberá as informações necessárias na forma de textos e possivelmente imagens), se o serviço cumpre os requisitos de negócio, se com aquela infraestrutura criada você conseguirá atingir o objetivo determinado, etc. Os cenários são muitos para elencar, mas o que fica de padrão entre eles, é a necessidade que você saiba como os serviços funcionam de verdade.

Caso de uso

Normalmente as provas apresentam apenas 1 caso de uso, porém encontrei relatos na internet de provas com 2 exercícios desse tipo.

Os casos de uso são perguntas complexas, onde você recebe diversas informações de maneiras diferentes (imagens e textos) e precisa responder as questões. Você recebe um cenário (normalmente uma empresa fictícia) e terá que responder 5 questões. Para responder essas 5 questões você precisará navegar entre as informações fornecidas. As informações costumam ser: infraestrutura da empresa, mudanças planejadas no ambiente, requisitos de negócio e coisas desse tipo. As perguntas costumam exigir que você selecione dentre as opções, a alternativa que atenda os requisitos, respeitando o ambiente existente e os direcionamentos da área de negócios.

Sim/não

Em sua grande maioria, é apresentada no final do exame, visto que você já passou pelas duas categorias anteriores.

Esse modelo de pergunta não permite que você retorne à resposta anterior para conferi-la, você terá 1 chance para respondê-la e depois não poderá revisá-la.

Você é apresentado um cenário e uma solução. Seu papel é responder se a solução proposta atende o cenário informado, tendo como opção apenas sim e não.

A grande dificuldade desse modelo de perguntas é que as vezes você responde a primeira e a solução proposta na pergunta seguinte, se adequa melhor ao cenário. Isso nos deixa nervoso, pois ficamos tentando adivinhar quais as soluções propostas nas próximas perguntas e muitas vezes, ao ver a questão seguinte, nos questionamos de nossa escolha.

NÃO faça isso!

Quando estiver respondendo uma dessas perguntas, o importante é que você garanta que a solução proposta atenda o requisito apresentado. Se a solução ATENDER a necessidade de negócio, mesmo não sendo a mais indicada (por questões de custo, performance, etc.) confie no seu conhecimento, não responda a questão pensando que a próxima pode apresentar uma solução mais adequada.

Dicas

Tendo entendido a estrutura da prova, vou te passar algumas dicas para você aplicar durante o teste e para sua preparação.

As dicas não vão abordar perguntas específicas do exame. A ideia é fornecer algumas informações sobre os temas que podem estar presentes e como se capacitar melhor para sua tentativa.

Da prova

Logo após finalizar a última questão da prova, revisar as que tinha deixado marcadas e receber a maravilhosa notícia que havia passado, comecei a refletir sobre o que vi no teste e sobre a minha preparação. Consegui identificar os assuntos que deveria ter me preparado melhor e os que consegui me capacitar de maneira satisfatória para o exame. Aqui estão alguns deles:

Logging: foi um assunto muito presente na minha prova. Soluções como log analytics, azure monitor, application insights e network watcher marcaram presença o exame todo. Para esse ponto a minha recomendação é: entenda o ecossistema do Azure Monitor. O monitor além de ser uma ferramenta extremamente poderosa, é o centralizador do monitoramento na plataforma. É na interface do monitor que nós visualizamos informações, executamos queries, criamos alertas e muitas outras ações relacionadas ao monitoramento dos recursos e do ambiente;
Networking: esse foi o tema que senti mais presente e também o que me trouxe mais dificuldade. Um tipo de questão constantemente visto, é a de integração entre redes. Integração entre dois escritórios da mesma empresa, conexão do ambiente on-premise com a rede em cloud, os diferentes tipos de conexão VPN, todos esses modelos apareceram, alguns mais de uma vez. Não é necessário ter um conhecimento avançado em redes de computadores, porém ter uma boa compreensão da estrutura de networking do ambiente cloud e como fazer para conectar diversas redes à sua (através de VPN, ExpressRoute, WAN, Peering) vai permitir que você responda essas questões tranquilamente, de forma que você não perca mais tempo do que devia;
Computing: presente em praticamente todas as certificações, a parte de computing é muito importante para seu sucesso. Conhecer as ferramentas disponíveis (App Service, Azure Kubernetes Services, Azure Virtual Machines, Azure VM Scale Sets, Azure Container Instances, Azure Container Registry) e praticar a implementação de alguns projetos com elas, te ajudará muito na prova. Nessa categoria, é importante que você conheça também os SKUs de alguns serviços, como o Azure App Service, apenas para entender os recursos que os diferentes níveis de serviço fornecem;
Azure AD: o Azure AD é muito mais do que só a ferramenta de controle de acesso à Azure. Ele é um dos líderes de mercado como ferramenta de IAM, então conhecer essa ferramenta não é importante só para a prova, mas também para sua carreira na cloud, visto que se torna uma habilidade valiosa. Para o teste é importante que você entenda seu funcionamento geral, formas de licenciamento, diferentes tipos de objetos (usuários, grupos, unidades administrativas, etc.), RBAC (role based access control) e políticas de acesso condicional. Esses não são os únicos tópicos que serão abordados, mas são assuntos importantes e que você deve dar mais atenção;

De conteúdo/preparação

A escolha do conteúdo preparatório é parcela importantíssima no seu processo. Junto da disciplina, elas formam o que é necessário para que você atinja seus objetivos.

O primeiro link que quero te passar é o do Canal da Cloud, da Valéria Baptista. A Valéria produz uma série de conteúdos fantásticos na plataforma dela, como cursos preparatórios para certificações, vídeos de aprofundamento técnico em assuntos específicos e bate-papos com convidados da área, onde podemos acompanhar uma troca de conteúdo e experiências muito rica. No canal dela você encontra uma série de 5 vídeos preparatórios para a prova, o primeiro deles você pode acessar clicando aqui!

A segunda recomendação de conteúdo é o curso do Alan Rodrigues na Udemy. O curso é completamente em inglês, porém contém uma abordagem bem diferente do que estamos acostumado a ver. Os vídeos são focados na prática, o instrutor explica um tema abrindo o portal Azure e criando o recurso, para que você possa acompanhar com ele e adquirir a experiência prática para realizar o exame mais confortável.

Para uma revisão rápida, um vídeo que recomendo é esse, do Jhon Savill. Jhon é um youtuber que tem um canal completamente focado em Azure. Ele trata de todos os assuntos, certificações, temas específicos e até atualizações na plataforma. O canal é atualizado semanalmente e sempre conta com vídeos novos. Um conteúdo interessante do canal são os study crams, que são “vídeos resumo” para as provas. Ele explica os conceitos de maneira simples e compreensível, oferecendo nível de detalhe excepcional para um vídeo de menos de 4 horas.

Por fim, temos o assessment oficial da Microsoft. O assessment contém uma série de perguntas sobre os tópicos do exame. É um recurso interessante para praticar antes e pegar confiança antes da prova.

A prova

Como comentei anteriormente, meu teste teve 54 questões. Pode ser que o seu tenha mais ou menos, mas não espere que o número seja muito diferente.

O exame, além de testar seu conhecimento técnico, testa sua habilidade de gerenciamento de tempo. Você terá 100 minutos (1 hora e 40 minutos) para entregar a prova (responder todas as questões e revisar as que você marcou) e mesmo parecendo que é muito tempo, você pode se complicar rapidamente.

Você pode (e deve) utilizar a funcionalidade de revisar posteriormente (review later). Fazendo uso dessa “ferramenta” você vai conseguir organizar seu tempo de prova e não precisará perder tempo em questões que você está confuso ou que está achando difícil. Gerencie bem seu tempo, fique atento à quantas questões faltam para terminar a prova e responda as questões com calma.

100 minutos é bastante tempo, mas quando estamos concentrados tentando resolver as questões da prova parece que o relógio passa mais rápido. Tudo bem se você se sentir confuso com uma questão, essa é uma situação que vai ocorrer com certa frequência durante a prova. O importante é você não perder tempo e não conseguir responder as questões seguintes.

Gerencie seu tempo!

Seguindo essas dicas e prestando atenção aos pontos que comentei, você estará bem preparado para a prova. Pratique seus conhecimentos e esteja confiante que o PASS é garantido.

Boa prova ❤

AZ-305 — Microsoft Azure Solutions Architect Expert

Tue, 06 Jun 2023 03:00:00 GMT

Após concluir (por enquanto) minha jornada pelas certificações da Microsoft, vou tomar esse tempo para compartilhar com você os meus insights, dicas e sugestões para que seja bem sucedido ao fazer a prova.

Sobre o exame

NÃO é uma prova fácil!

É importante deixar isso bem claro, pois ao contrário do que alguns vendem pela internet, a prova é complexa e exige muito do candidato. As questões são multidisciplinares, aglomerando uma série de assuntos diferentes em uma mesma questão para testar seu conhecimento do ecossistema Microsoft.

O exame é direcionado para arquitetos de solução que trabalham diretamente com as tecnologias Microsoft, então já era de se esperar que as perguntas tivessem um viés técnico mais voltado para arquitetura.

A maioria esmagadora das questões solicita que você escolha dentre as alternativas fornecidas, a solução que irá gerar menor esforço operacional, otimizar custos e atingir os objetivos do negócio. Esses são termos que os arquitetos (incluindo eu) estão acostumados a ouvir no dia a dia de trabalho, considerando que essa é a tríade de qualquer projeto.

Para melhorar a vossa perspectiva, vou detalhar cada um desses tópicos para que você vá para seu teste com eles em completo entendimento.

Menor esforço operacional

Considerando o momento de implantação da solução, é comum nas empresas haver um time que vá sustentar as operações da infraestrutura (times dedicados, times autossuficientes, etc). Esse direcionamento, infere que a solução construída, gere a menor quantidade possível de trabalho para as equipes de sustentação. Em termos técnicos, devemos buscar soluções gerenciadas e que não exijam manutenção de infraestrutura pelos times.

Soluções PaaS (Platform as a Service) fornecem o menor esforço operacional quando estamos pensando nas soluções de nuvem, pois o trabalho de gerenciamento da infraestrutura é dedicado completamente ao provedor de cloud.

É importante deixar claro que o “esforço operacional” não tira a responsabilidade das equipes de operar o produto até certo ponto. A infraestrutura sendo gerenciada descarrega um pouco a responsabilidade sob os times, porém outros aspectos do serviço precisam ser operacionalizados. A segurança e as informações nele contidas são duas coisas que precisarão do toque dos times, pois estão sob a responsabilidade do cliente do cloud provider (você).

Otimizar custos

Essa é bem direta, sua solução deve ser o mais cost-optimized possível. Isso incluí, saber selecionar corretamente os recursos que irão compor sua arquitetura, bem como escolher o SKU correto e planejar os aspectos de disponibilidade e escalabilidade da solução.

Se atente às diferenças dos níveis de serviço, em muitos casos os diferentes SKUs entregam alguns recursos em comum, porém quanto mais caro o nível de serviço, mais coisas ele entrega. O tier escolhido deve entregar apenas o essencial para a solução, não sendo necessário contratar mais do que o projeto irá realmente utilizar.

Atingir os objetivos de negócio

Assim como o anterior, esse é simples. A solução construída e todos os componentes que a compõem, deve entregar aos demandantes o que foi solicitado.

A solução deve ser harmônica ao ponto de ser eficiente, ter seus custos otimizados, ser escalável, altamente disponível não deve aumentar a carga operacional das equipes.

Dicas

Da prova

Meu exame estava agendado para maio/2023 e já com a prova marcada fui perceber que a estrutura de tópicos tinha sido alterada. Cuidado!

Essa é a primeira dica, mantenha-se SEMPRE atento à página do exame, pois eles estão em constante evolução e são atualizados regularmente. Os exames são constantemente atualizados para que estejam o mais alinhado com as exigências do mercado.

Por já ser certificado com as provas AZ-104 (Microsoft Azure Administrator Associate), AZ-500 (Microsoft Azure Security Engineer Associate) e estando confortável de maneira prática com os recursos da plataforma, eu estava tranquilo que este exame deveria ser meu próximo passo na jornada das certificações. Ambas as certificações compartilham muito conteúdo com a AZ-305, porém abordam as questões em profundidades diferentes.

A segunda dica é: não pule nenhuma prova da trilha de certificações recomendadas pela Microsoft, elas te ajudarão a se preparar para os testes mais difíceis. As certificações são construídas de maneira que você consiga as fazer seguindo uma “trilha”, começando com as provas que exigem menos profundidade técnica e mais conhecimentos gerais sobre os assuntos e terminando com as provas altamente técnicas, como é o caso desta que estamos falando. Seguir a trilha trará confiança para que você siga em frente com as outras provas e gerará conforto em relação ao que você sabe, incrementando ainda mais sua confiança.

A terceira dica é: PRATIQUE! Existem diferentes formas de se praticar e treinar para as provas. Você pode:

construir projetos;
criar instância dos serviços e aprender a utilizá-los separadamente;
utilizar vídeos de hands-on disponíveis no youtube e que permitirão que você siga um passo a passo de como utilizar aquele serviço;
usufruir das documentações técnicas dos produtos que são muito ricas e fornecem tudo que você precisa para deixá-los operando da maneira correta;
responder os famosos “quizes” na internet. Essa opção fornece uma prática diferenciada, pois você não aprenderá como os serviços funcionam corretamente (que é recomendado), porém as perguntas podem ser úteis para te preparar para a prova;

De conteúdo

Ao fazer uma breve pesquisa na internet, conseguimos recuperar dezenas de links de conteúdo preparatório para a(s) prova(s), porém em meio a todos esses recursos, a verdadeira dificuldade é conseguir escolher alguns que forneçam a qualidade e a profundidade esperada.

Como bem sabemos, é muito simples aprender algo na internet. Hoje temos conteúdo de praticamente todos os assuntos disponíveis de graça em plataformas como o Youtube, porém não precisamos nos limitar apenas aos vídeos. A Microsoft fornece uma plataforma de learning completa, que conta com módulos de leitura, sandboxes, quizes e vídeo aulas que enriquecerão seus estudos.

Para quem optar por cursos pagos, temos plataformas como a Udemy, Pluralsight e A Cloud Guru que fornecem um landscape de treinamentos simplesmente fantástico. Temos conteúdos dos mais variados. De preparatório para certificações mais básicas às mais avançadas, cursos focados em temas e tecnologias específicas dos provedores de nuvem (ex: serverless, conteineres, etc). Algumas plataformas trabalham com o conceito de assinaturas mensais e anuais, outras trabalham com a compra de cursos. Com tantas opções, você pode escolher a que melhor se adapta à sua necessidade.

Os materiais utilizados por mim durante a preparação para a prova foram:

Microsoft Azure Solutions Architect Expert — Alan Rodrigues, Udemy;
Módulos preparatórios do Microsoft Learn;
Cloud Adoption Framework;
Assessment oficial da Microsoft;

Toda a minha preparação girou em cima do curso mencionado acima. Após termina-lo, procurei entender os gaps de conhecimento que tinha e estudei os assuntos de maneira personalizada, utilizando em grande maioria as documentações oficiais dos serviços.

O CAF (Cloud Adoption Framework) foi essencial durante meus estudos, pois com ele eu pude aprender sobre as práticas mais recomendadas pela equipe de especialistas da Microsoft e pude enriquecer o meu processo de tomada de decisão para construção das soluções.

O assessment é composto por um conjunto de questões sobre os diferentes serviços da plataforma. Ele visa fornecer um teste rápido para validação de conhecimento como forma preparatória para a prova. Composto de 50 questões de múltipla escolha, você pode visualizar as respostas das perguntas que você errou no momento da resposta ou ao final do teste, onde é disponibilizado um conglomerado de todas as perguntas e as alternativas selecionadas.

A prova

Por fim, a prova. O meu teste foi composto de 54 questões e continha questões de múltipla escolha, drag-and-drop, casos de uso e perguntas de sim/não.

Os casos de uso são complexos e exigem bastante atenção. Eles costumam representar um cenário “comum” em empresas. Você será perguntado sobre qual a melhor solução para determinada atividade e é sua responsabilidade consumir os requisitos, preferências e verificar a possibilidade de implementar a solução que recomendaste. Cada pergunta do case normalmente exige que você análise as informações fornecidas diversas vezes, pois como em uma empresa de verdade, existem incontáveis variáveis que podem influenciar a forma com que você toma a decisão.

As perguntas de sim e não são mais simples. Em um determinado momento do exame você terá um cenário apresentado e uma solução proposta, é seu dever afirmar ou negar que a solução proposta atende os requisitos. Nessa fase do exame você não consegue voltar para a pergunta anterior, e é aí que entra a dificuldade. Após responder a primeira pergunta, a segunda pergunta pode ser igual à anterior porém com uma diferente solução proposta. Você não poderá voltar e alterar sua resposta, então esteja muito atento aos requisitos e afirme com confiança que a solução proposta atende ou não a necessidade.

O restante do exame é composto de perguntas de múltipla escolha e drag-and-drop. São perguntas menos complexas que as apresentadas no caso de uso, porém exigem profundidade técnica em múltiplas vertentes do ecossistema Azure.

Espero que tenha conseguido te ajudar a ter uma perspectiva mais realista da prova e fornecido insights que te ajudem a sair bem sucedido do exame.

Boa prova ❤

Conditional Access - guia completo!

Wed, 24 Jan 2024 03:00:00 GMT

Nas empresas onde trabalhamos, é comum termos diversos desafios relacionados às identidades. Muitos desses desafios dizem respeito à diferentes cenários, com os quais devemos nos preocupar (cenários como: empresas terceirizadas acessando nossas aplicações). Se considerarmos também os temas de segurança, os desafios ficam ainda maiores e mais complexos. Hoje vamos falar sobre um aliado nessa nossa jornada rumo à uma proteção melhor do nosso ambiente e dos ativos da nossa organização.

O que são as políticas de acesso condicional?

![Diagram showing a high level Conditional Access overview](https://learn.microsoft.com/en-us/entra/identity/conditional-access/media/plan-conditional-access/conditional-access-overview-how-it-works.png align=“center”)

Nós podemos interpretar, de maneira correta, as políticas de acesso condicional como o motor das políticas de acesso e de segurança aplicáveis no Microsoft Entra.

Mas como assim?

Por mais que esse não seja um recurso acessado diretamente em um fluxo de autenticação ou autorização, é um componente presente em todas as etapas desses processos. As políticas são criadas com o intuito de implementar diferentes controles de segurança, em diversos cenários e levando em consideração múltiplas informações diferentes fornecidas pelo próprio Entra ID.

Resumindo: tudo (ou quase tudo) dentro do seu tenant, passará por uma ou mais políticas de acesso condicional (depende de quantas estão definidas).

Neste primeiro momento a explicação pode ter ficado um pouco genérica, porém nessa próxima sessão vamos falar em detalhes sobre as capacidades desses recursos.

Para utilizarmos as políticas de acesso condicional, é necessário termos em nosso tenant licenças P1 ou P2 do Entra.

O que podemos fazer com elas?

Após entendermos o que são essas políticas, chegou a hora de falarmos um pouco sobre alguns recursos importantes que podem ser usados para proteger o seu ambiente.

Controle por dispositivos

Como é comum nas organizações termos dispositivos fornecidos aos funcionários e controlados pela própria empresa, podemos utilizar esse controle como vantagem para proteger o acesso às aplicações de maneira mais efetiva.

Aplicando as políticas em dispositivos gerenciados (ou não, dependendo do caso), podemos exigir controles mais fortes para permitir o acesso ou regras mais “folgadas”, como por exemplo em requisições vindas de um dispositivo gerenciado pelo Microsoft Intune à partir de uma rede confiável.

Podemos também aplicar controles baseados na plataforma de acesso. É possível escolher dispositivos windows, ios, android, linux e mac, como também acessos feitos à partir de browser ou de um client.

Aplicação

Como no final das contas nós estaremos protegendo o acesso aos nosso recursos (aplicações), nada mais justo do que ter a habilidade de selecionar quais aplicações nós queremos que estejam incluídas nas políticas.

Todas as aplicações integradas ao Entra ID, estarão disponíveis para terem os controles de acesso aplicados à elas.

Essa granularidade nos permite testar o funcionamento das políticas em aplicações de diferentes tipos e também aplicar políticas diferentes de acordo com o público que estará acessando as aplicações. Isso é útil para cenários onde as aplicações não serão acessadas apenas pelo público interno, mas também por convidados/terceirizados, para isso devemos aplicar controles mais rígidos e diferentes dos determinados para os funcionários da organização.

MFA

Recurso essencial para todos os momentos, as políticas de acesso condicional são as responsáveis por garantir a aplicação do multi-factor authentication em diversos momentos. Não temos apenas a possibilidade de solicitar um segundo fator de autenticação quando julgarmos necessário, mas também podemos escolher quais os fatores que podem ser utilizados naquele determinado momento.

O Microsoft Entra disponibiliza uma série de opções de fatores de autenticação que podem ser escolhidos e habilitados pelos times de segurança da sua organização. Também é possível organizar esses fatores de autenticação em “grupos” para que possam ser solicitados como opções diferentes para aquela situação.

Riscos

Esse recurso não faz parte diretamente das políticas de acesso condicional, porém podem ser utilizados na implementação das políticas.

Com as capacidades de análise de risco do Microsoft Entra, é possível aplicar os controles baseados no risco apresentado em determinada atividade. Isso quer dizer que de acordo com o risco avaliado (baixo, médio ou crítico), nós podemos aplicar determinados controles (como exigir um segundo fator de autenticação, solicitar a troca de senha ou até bloquear a conta de usuário até que a mesma seja desbloquada por alguém com os privilégios para executar tal ação).

Isso nos permite não apenas aplicar controles específicos em alguns cenários determinados, mas também proteger de fato o nosso ambiente e as nossas aplicações de acessos perigosos!

Token protection

Um controle moderno e avançado que podemos implementar é o de token protection, ou no Entra, “Continuous Access Evaluation”.

Esse recurso permite a análise do contexto das requisições à cada chamada, não ficando preso apenas ao tempo de expiração do token para revogação da sessão.

Esse controle pode ser aplicado em políticas que levam em conta o risco do login ou da identidade do usuário, tornando assim uma funcionalidade valiosa para a mitigação de acessos “arriscados” ao seu ambiente.

Redes confiáveis

É comum termos nas empresas uma série de redes (IP ranges) configurados para serem tratados como confiáveis. Redes essas da nossa própria organização ou de empresas parceiras, com conexões do tipo VPN estabelecidas com o nosso ambiente.

Utilizar essas redes confiáveis nos permitirá “fechar o cerco” para ataques de segurança, uma vez que configuraremos as aplicações para permitirem acesso apenas à partir dessas redes determinadas, mas também poderemos controlar de maneira assertiva os acessos vindo das empresas parceiras, uma vez que temos seus ranges de IP configurados em nosso tenant.

Boas práticas

Todo deploy relacionado à atividades de segurança, tem suas peculiaridades de acordo com o ambiente e a estratégia da sua empresa.

As boas práticas podem ser interpretadas como recomendações de controles que devem ser aplicados, mas também podem ser tratadas como as estratégias de implementação e configuração desses controles.

É importante que como toda implementação, a estratégia adotada seja estudada e planejada. Não podemos nos esquecer que no final da cadeia, temos os usuários que em grande parte do tempo, não tem a menor ideia do que está sendo feito pelos times de segurança. A única coisa desejada por eles é que a habilidade de executar as atividades triviais do seu trabalho não seja afetada.

Sobre a criação das políticas, é interessante que sua empresa defina a própria estratégia, porém alguns pontos que podem ser compartilhados para auxiliar nessa tomada de decisão são:

Crie políticas básicas, que se apliquem à grande maioria dos seus usuários. Essas políticas podem ser para solicitar o segundo fator de autenticação independente de quem esteja acessando as aplicações, bloquear acessos com risco considerado crítico, entre outras opções;
Implemente controles que o permita proteger seu ambiente, não apenas controlar o acesso. Políticas que levam em consideração os riscos de login e implementam os controles adequados, poderão poupar o seu time de segurança de muita dor de cabeça;
É importante pensar também no longo prazo, em como o time responsável pelos acessos daqui alguns anos irá tomar conta do ambiente. Criar suas políticas com nomes claros e descritivos e construir documentações que contenham todo o histórico de criação delas, será essencial para manter a estabilidade no seu ambiente. Ter esses insumos, tornará o trabalho do novo time menos moroso e permitirá um melhor planejamento das mudanças que serão aplicadas;
Agora possívelmente a boa prática mais importante. Não fique bloqueado para fora do seu tenant!!! Aplicar as políticas de acesso condicional para TODOS os usuários é um perigo, pois existe a possibilidade (mesmo que improvável), de que todos os usuários fiquem sem acesso aos recursos. Para isso, é improtante termos algumas contas com MFA diferente dos utilizados pelos demais usuários e também é importante que essas contas sejam colocadas na sessão exclude das políticas, para que esses controles “globais” não sejam aplicados à elas.

Por hoje é isso, espero que as informações passadas nesse texto tenham feito você sentir mais confiança no momento de criar suas políticas de acesso. É importante lembrarmos sempre de apoiar nossas decisões com dados e informações de fontes confiáveis, principalmente se tratando da segurança do nosso ambiente.

Até logo!

Configurando funções (roles) no Entra ID Privileged Identity Management

Mon, 14 Aug 2023 03:00:00 GMT

No último texto falamos sobre o Entra ID PIM. Explicamos os conceitos básicos que regem a proteção do acesso privilegiado e fizemos uma breve tour pela console do PIM no Portal do Azure. Hoje, faremos um hands-on, configurando duas funções diferentes com dois níveis de segurança diferentes.

O que faremos?

Esse tutorial visa te ensinar em detalhes como realizar as configurações das funções no PIM. Nós iremos:

Criar um grupo no Entra ID e popular com 2 aprovadores;
Configurar uma função para solicitar o uso do Azure MFA na ação de aprovação;
Configurar uma função que exige a aprovação de um grupo antes de ter seu uso liberado para o usuário;
Configurar o tempo de eligibilidade das funções para os usuários.

Todas essas operações serão feitas utilizando o Portal do Azure e o Cloud Shell.

Requisitos

Para conseguir realizar esse tutorial, seu tenant precisa ter no mínimo a licença P2 atribuída. Isso é necessário pois o PIM não é um recurso gratuito e disponível para todos os usuários. O Entra ID permite que você faça testes com as licenças, podendo ativar licenças P2 por 30 dias ou o pacote de licenças E5 por 90 dias (pacote que disponibiliza 250 licenças das mais variadas para você testar).

É importante que você esteja utilizando um usuário com privilégios adequados. Se estiver realizando o tutorial em sua conta pessoal, você provavelmente estará utilizando sua conta com privilégios Global Admin, que não é uma boa prática porém para o propósito do tutorial, não tem problema.

Iniciando

O primeiro passo será criar o grupo de aprovadores e inserir alguns usuários nele. Os usuários podem ser existentes ou podem ser usuários criados por você na hora. Como o propósito do tutorial é a configuração das funções no PIM, vou deixar um script para ser utilizado no Azure CLI para você criar um grupo, criar alguns usuários e inseri-los no grupo criado.

Vamos aos preparativos.

Criando os usuários e grupo

Para execução dos comandos eu utilizei o Cloud Shell como mencionado no começo do artigo, mas você também pode executar os comandos na sua máquina local através do CMD ou do Powershell.

Para executar os comandos localmente, certifique-se de que está logado em sua conta executando o comando:az login

Criação do grupo:

Como esse grupo será utilizado para aprovação dos pedidos, sugiro escolher um nome que remeta à função que o grupo executará (ex: Aprovadores).

az ad group create --display-name --mail-nickname

NOME-DISPLAY (obrigatório)— nome que será retornado quando o grupo for consultado, seja através da CLI, Azure Portal ou outros meios.

NOME-EMAIL (obrigatório)— nome utilizado no endereço de e-mail do grupo.

Criação dos usuários:

az ad user create --user-principal-name --display-name --password

EMAIL (obrigatório) — e-mail do usuário que será criado. O e-mail deve utilizar o domínio próprio do tenant (se você não registrou um domínio próprio para ser utilizado em seu tenant, seu domínio será .onmicrosoft.com, busque essa informação na página principal do seu Entra ID Tenant).

NOME (obrigatório) — nome que será retornado quando o usuário for consultado.

SENHA (obrigatório) — senha inicial para o usuário. Quando ele realizar o primeiro login, será solicitado que altere a senha.

Após a criação de cada usuário, é importante que você anote o ID do usuário que é retornado. Esse ID será utilizado para realizarmos a atribuição do usuário no grupo.

Atribuição dos usuários no grupo:

az ad group member add --group --member-id <ID-USUÁRIO>

NOME (obrigatório) — nome do grupo.

ID-USUÁRIO (obrigatório) — IDs dos usuários que foram anotados anteriormente.

Agora que fizemos a atribuição dos usuários ao grupo, vamos passar para a próxima parte, onde vamos configurar as funções.

Navegando no portal do PIM

Dentro do Portal do Azure podemos procurar na barra superior pelo PIM. Ao acessar o recurso você deve visualizar algo parecido com isso:

Dentro da console do PIM na seção “Gerenciar”, vamos acessar a opção Funções do Azure AD. Dentro do próximo painel, novamente abaixo de “Gerenciar” selecione a opção Funções. Será aberta uma lista com todas as funções existentes no Azure AD e que podem ser configuradas no PIM. Você deve estar em uma página igual a essa:

Para te explicar de maneira efetiva como esse recurso pode (e deve) ser utilizado, as funções que nós configuraremos serão:

Administrador da Assistência Técnica (Helpdesk Administrator);
Leitor Global.

Por quê essas funções?

No texto passado comentei sobre um possível problema que pode ser gerado quando estivermos configurando o PIM, que é do “engessamento” dos processos.

Devemos ser cautelosos na configuração das funções para não tirar a autonomia dos times operacionais que precisam de seus acessos para realização das atividades. É importante que os controles sejam bem aplicados mas por outro lado, não podemos esquecer que alguns desses acessos são cruciais para a realização de atividades triviais no dia a dia das equipes.

A função de Administrador da Assistência Técnica permite que o usuário reinicie as senhas outros usuários, exceto Administradores da plataforma e de outros Administrador de Assistência Técnica. Em uma empresa que contenha um serviço de helpdesk para seus funcionários, a atividade de reinicialização das senhas será recorrente, uma tarefa comum para esses funcionários. Não existe motivo para configurar essa função de modo que o usuário elegível para sua ativação precise aguardar a aprovação do acesso vindo de outro time. Isso impactará as tarefas do time aprovador, que receberá pedidos de aprovação constantes, do time de helpdesk, que precisará aguardar a aprovação da solicitação e dos funcionários da empresa, que não conseguirão realizar seus acessos até que a solicitação seja aprovada e a senha restaurada. Por isso, configuraremos a função para solicitar o MFA do usuário toda vez que ela for ativada.

Por outro lado, a função Leitor Global permite ao usuário visualizar informações de todo o seu escopo de aplicação. Se a função for aplicada com escopo de uma subscription ele conseguirá visualizar informações sobre todos os recursos contidos nela. Caso a função seja aplicada no escopo de um management group, o usuário visualizará informações de todas as subscriptions ali contidas. Essa função oferece um alto risco de vazamento de dados confidenciais para a organização, então devido ao seu nível de acesso aos recursos e escopo de aplicação, essa função vale a necessidade da aprovação de um time em específico (no contexto da sua empresa, essa equipe pode ter diversas responsabilidades).

Configurando a primeira função

Ainda na página que nos fornece uma visão de todas as funções do Azure AD, procure pela função Administrador da Assistência Técnica e a selecione. Uma página parecida com essa deve se abrir:

Nas opções horizontais, 2 nos importam:

“Adicionar atribuições”: opção que nos permite atribuir essa função à certos usuários e grupos. A utilizaremos após configurarmos as propriedades da função;
“Configurações”: onde realizaremos nossos primeiros passos, configurando as opções da função.

Clicando em “configurações” e logo em seguida em “editar”, seremos levados à seguinte página:

Iremos habilitar as configurações em 3 etapas:

Ativação: diz respeito às ações que serão tomadas pelo usuário no momento da ativação da função;
Atribuição: onde podemos realizar alterações sobre as propriedades de atribuição da função;
Notificação: definição das partes que poderão ser notificadas quando algum tipo de modificação ou atribuição for feita na função.

Ativação

Como primeiros passos, vamos configurar para que o usuário utilize o Azure MFA para a ativação e vamos diminuir o tempo de duração para 4 horas.

Para esse cenário em específico, as empresas habilitariam a opção “Exigir informações de tíquete na ativação”, visto que muitas delas utilizam softwares que auxiliam na gestão da solicitação de serviços. Para manter nosso exemplo mais simples e conciso vamos deixar essa opção desmarcada.

No final dessas configurações, você presenciará o seguinte cenário:

Para fins de curiosidade, caso o usuário não tenha o Azure MFA conectado com sua conta, no momento de ativação ele será levado para uma jornada que o permitirá instalar o aplicativo Microsoft Authenticator e registrar seu token .

Atribuição

Passando para a tela de atribuição, deixaremos as configurações da seguinte forma:

A primeira opção marcada (“Permitir atribuição qualificada permanente”) permite que a função atribuída ao usuário não expire com o tempo. Ela estará disponível para ser ativada até que seja removida de forma explícita. Caso essa caixa não esteja marcada, poderemos definir um tempo máximo de duração da atribuição. Para nosso exemplo, não configuraremos a expiração visto que os usuários que terão essa função atribuída farão uso dela diariamente.

A segunda caixa funciona de maneira parecida em relação à primeira, se diferenciando no ponto em que neste caso a função pode ser atribuída como ativa para o usuário, não exigindo que ele faça uso do Azure MFA. Também a manteremos habilitada.

Por fim as duas últimas opções. Caso desejássemos solicitar o MFA para atribuições ativas, poderíamos marcar a penúltima caixa mas visto que esse tipo de atribuição será pouco utilizado, vamos deixá-la desabilitada e marcaremos a última opção, que exige uma justificativa para atribuir a função de maneira ativa.

Notificação

O último passo agora é definirmos os usuários que serão notificados quando houver algum tipo de mudança nas configurações e atribuições da função.

Para fins de simplicidade, vamos manter essas configurações da maneira padrão:

Clique em “Atualizar” e pronto! Temos nossa primeira função configurada. Para a próxima, vamos passar pelos passos de maneira mais rápida, visto que grande parte das etapas de configuração é igual ao que acabamos de fazer.

Configurando a segunda função

Voltando à tela que contém a lista das funções, vamos pesquisar pela função Leitor Global. A selecione e acesse a opção “Configurações”.

Ativação

A segunda função não exigirá o uso de MFA pois terá um grupo de aprovadores que receberão as solicitações dos usuários. Também reduziremos o tempo de duração da ativação para 4 horas.

Para cadastrar um grupo de aprovadores, selecione a caixa que diz “Requer aprovação para ativar”. Após selecioná-la a opção para selecionar os aprovadores se tornará disponível. Selecionaremos o grupo “Aprovadores” que criamos no início do tutorial através do Azure Cloud Shell.

Sua página deve ficar parecida com essa:

Atribuição

Diferente da primeira função, essa apresenta um risco muito maior à segurança da informação da empresa, visto que o usuário que contém esse privilégio terá acesso à informações sensíveis dos ambientes.

Para essa função vamos desabilitar a atribuição permanente tanto para as atribuições qualificadas quanto para as ativas. O tempo de expiração das funções também será alterado. As atribuições qualificadas terão duração máxima de 6 meses e as ativas duração máxima de 1 mês.

Manteremos a necessidade de uma justificativa para atribuições ativas.

Notificação

Não faremos nenhuma modificação nesta aba, manteremos as configurações padrão, que são as mesmas da função anterior.

Atribuindo usuários

Após realizarmos as configurações das funções chegou a hora de atribuí-las à alguns usuários.

No painel da função que iremos atribuir vamos selecionar a opção “Adicionar atribuições”.

Dependendo da função que está sendo atribuída você pode ter a opção “Tipo de escopo” habilitada para personalização. O escopo determina sob qual nível a função será aplicada. Quando estamos tratando de funções do Azure AD os escopos existentes são: Diretório e Unidade Administrativa. Para funções do Azure temos uma granularidade maior de escopos que podemos utilizar.

Cabe a você selecionar os membros que terão acesso a essa função. Você poderá escolher usuários ou grupos.

Obs: para que os grupos possam ter funções atribuídas é necessário que no momento de criação ele tenha sido explicitamente configurado para isso.

Após selecionar os usuários para atribuição, você irá configurar o estado da atribuição e o tempo de duração. O estado pode ser Qualificado ou Ativo. O tempo de atribuição deverá respeitar o que foi configurado previamente na função.

Após finalizar essas seleções, a atribuição estará feita!

Conclusão

Após realizar as atribuições dos usuários, o que resta é testar.

Faça login nas contas dos usuários que tiveram funções atribuídas e realize a ativação delas.

Para a função Administrador da Assistência Técnica será necessário apenas a utilização do Azure MFA, então ao realizar a ativação será solicitado que você complete a operação no aplicativo.

No caso da função Leitor Global você precisará realizar login com qualquer uma das contas dos usuários presentes no grupo “Aprovadores”, navegar até o painel do PIM, selecionar “Funções do Azure AD” no painel à esquerda e escolher a seguinte opção:

Dentro desse painel você poderá visualizar as aprovações que estão pendentes e também as renovações de atribuições.

Quando uma solicitação for feita, todos os aprovadores daquela função receberão um e-mail informando da pendência. A aprovação pode ser feita diretamente pelo e-mail recebido, que contém links que fornecem essa facilidade.

Com esse tutorial conseguimos visualizar e entender a importância de se proteger o acesso privilegiado aos recursos e como isso pode ser facilmente implementado com a ferramenta correta.

O Entra ID PIM é extremamente poderoso e contribuirá muito para a estratégia de segurança e zero trust da sua empresa.

Obrigado por acompanhar até aqui e até logo!

Azure Kubernetes Service + Cilium

Tue, 15 Oct 2024 03:00:00 GMT

O advento das arquiteturas Cloud Native gerou grande complexidade quando pensamos na sustentação do nosso ambiente. Estamos falando de arquiteturas distribuídas, microsserviços, alta disponibilidade, APIs, entre outros tópicos. Garantir a segurança nos ambientes e a capacidade de compreender problemas e fornecer soluções de maneira ágil tornou-se um desafio ainda maior ao nos depararmos com um ambiente distribuído e em nuvem. Tendo ciência desse problema, falaremos hoje sobre o Cilium, uma solução open source que surgiu para remodelar a forma como pensamos na observabilidade e segurança dos nossos ambientes.

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.

eBPF é um tema complexo e que merece uma série de artigos própria. Caso tenha curiosidade, recomendo o seguinte link para iniciar seus estudos na tecnologia: What is eBPF? An Introduction and Deep Dive into the eBPF Technology

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.

![Cilium overview diagram](https://github.com/cilium/cilium/raw/main/Documentation/images/cilium-overview.png align=“left”)

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.

É importante deixar claro que utilizar o Cilium em seus clusters não o proíbe de utilizar outras ferramentas, visto que elas podem se complementar. A vantagem é que algumas capacidades (como por exemplo service mesh) podem ser cumpridas sem a instalação de uma solução adicional.

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.

Para ambientes de teste, o CLI se apresenta como uma excelente alternativa para realizarmos o deployment dos componentes. Em ambientes produtivos, que consequentemente são mais controlados, não devemos ter acesso à nenhum tipo de CLI, portanto a melhor forma de se realizar a instalação da solução é através de ferramentas de Infrastructure as Code (IaC) e de Helm Charts.

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“.

O Cilium Operator é o componente responsável por suportar algumas camadas do ciclo de vida da solução dentro do seu cluster. Dentre suas responsabilidades, estão: cluster mesh management, node sync e IPAM.

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!

Criando grupos dinâmicos no Entra ID

Tue, 03 Oct 2023 03:00:00 GMT

Procurando facilitar a inclusão de usuários e dispositivos em grupos, o Entra ID disponibiliza os grupos dinâmicos, que nos permitem utilizar atributos para decidir em qual grupo o objeto deve ser colocado.

O recurso

Quando um grupo é criado no Entra ID ele pode ser de 2 tipos: segurança e Microsoft 365. Os dois tipos tem suas diferenças, que não fazem parte do objetivo deste artigo, porém ambos nos permitem usufruir das atribuições dinâmicas.

Como foi explicado brevemente, as atribuições dinâmicas nos permitem criar regras (ou queries) que serão executadas sobre usuários e dispositivos existentes no tenant. Essas regras irão analisar certas informações que são contidas no objeto e o tornarão um membro do grupo.

Essas regras são criadas através do Portal do Entra ou através do Portal do Azure, acessando o Azure Active Directory. É disponibilizado um construtor para definir a regra, permitindo que você crie regras complexas e interligadas e não exigindo que você tenha conhecimento da sintaxe utilizada.

É importante frisar que a opção de Dispositivos Dinâmicos está disponível apenas para grupos de segurança e não para grupos do tipo Microsoft 365.

Aplicação

Esse recurso traz benefícios para as empresas dos mais diversos tamanhos.

A construção de boas regras de atribuição pode tranquilizar os times de segurança e gestão de acesso, permitindo que os mesmos foquem em outras atividades que agreguem mais valor para a empresa e não em atividades repetitivas e que poderiam ter sido automatizadas.

As regras também eliminam a possibilidade de erro humano. Uma vez que forem bem definidas e os processos de criação dos usuários e dispositivos forem maduros, as regras poderão ter cobertura de praticamente 100% dos casos nas empresas, exigindo que os times se preocupem com isso apenas em casos especiais.

Alguns casos de usos em que a aplicação desta funcionalidade pode ser útil:

Atribuição de novos funcionários nos grupos departamentais específicos;
Atribuição dos funcionários nos grupos de suas equipes (tanto para novos funcionários quanto para funcionários em mudança de equipe);
Atribuição dos dispositivos em grupos utilizados para gerenciamento dos mesmos.

Este recurso pode ser utilizado para atribuir usuários de diversas áreas, cargos e departamentos em grupos comuns a eles, visando facilitar a liberação de acessos, como também pode ser utilizado para cenários mais específicos, onde precisamos analisar com mais detalhe as informações dos usuários.

Usuários sincronizados do Active Directory on-premise através do Azure AD Cloud Sync, também serão “impactados” pelas regras criadas.

Listados os benefícios do uso dessa funcionalidade, vamos explorar a sua aplicação!

Hands-on

Passando para a seção prática do nosso tutorial, a imagem abaixo ilustra o cenário que iremos configurar:

Criaremos 3 grupos e dentro de cada um deles configuraremos as regras de atribuição dinâmica de usuários.

Não é possível criar grupos com atribuição dinâmica através do Azure CLI, então todas as operações deverão ser feitas utilizando o Portal do Azure ou o Portal do Entra.

Ao navegarmos no Portal do Entra, acessarmos o Entra ID e a seção de Grupos, vamos clicar em “Novo Grupo”.

Vamos clicar sobre o texto “Add dynamic query” e seremos direcionados para a seção onde criaremos as regras de atribuição.

Como esse primeiro grupo que estamos criando é direcionado para os gerentes, a regra que iremos construir analisará o cargo dos usuários procurando os que contenham a palavra “Gerente”. Dessa maneira a regra será executada para todos os gerentes da empresa, sem realizar distinção entre os departamentos em que atuam.

O editor visual disponibiliza de todas as propriedades existentes nos usuários, você pode navegar por ele e explorar as mais diversas possibilidades.As queries também podem ser feitas em cima de valores numéricos.O campo “Rule syntax” transformará a query criada no editor gráfico para a sintaxe utilizada pelo Entra ID. No final do campo de texto podemos ver o botão “Edit”. Ao clicarmos sobre ele, o campo de texto é habilitado e nós podemos utilizá-lo para escrever a query utilizando a sintaxe apropriada.

Agora basta salvar a query e confirmar a criação do grupo.

Os grupos dinâmicos criados impactarão usuários já criados no tenant. Pode levar um tempo para você notar as mudanças de acordo com a quantidade de usuários existentes na sua empresa, mas usuários antigos e novos serão afetados pelas queries*.*

Agora que você já sabe criar um grupo do zero e criar sua query, vamos criar os outros dois grupos necessários. Colocarei a seguir as duas queries que devem ser criadas em cada um dos grupos.

Validate Rules: caso você deseje testar a execução da sua query, você pode acessar a funcionalidade “Validate Rules” que está ao lado de “Configure Rules”. Esse recurso nos permite selecionar um ou mais usuários e retornará se esse usuário será colocado no grupo ou não.

Grupos criados, o que nos resta é criar usuários que contenham as informações que foram utilizadas nas queries e verificar a execução.

Como utilizamos as propriedades department e jobTitle, essas mesmas devem ser preenchidas na seção “Propriedades” quando você estiver criando os usuários.

Crie seus usuários e aguarde alguns minutos para que a query tenha tempo de ser executada.

Pronto! Hoje entendemos o poder dos grupos dinâmicos e como eles podem nos ajudar a aumentar a produtividade da nossa organização e diminuir esforços dos times operacionais.

Os grupos dinâmicos podem ter queries complexas, que fazem uso de dezenas de informações diferentes e que funcionam em diferentes granularidades, por isso se demonstra um recurso valioso para as empresas de diferentes tamanhos.

É isso, chegamos ao final do texto. Espero que tenha gostado e que agora você consiga fazer uso desse recurso valioso.

Até mais!

Qual a importância de termos uma solução de CNAPP?

Tue, 04 Jun 2024 03:00:00 GMT

A boa gestão de segurança dos ambientes foi um problema levado do on-premise à nuvem pública. A necessidade de termos diversas ferramentas para monitorar a postura de segurança dos recursos deixava os times desconfortáveis, pois os times frequentemente descobriam recursos não monitorados (e que consequentemente apresentavam riscos à saúde do ambiente). Hoje falaremos do CNAPP (em especial do Microsoft Defender for Cloud), uma solução que veio para deixar a vida dos times de segurança mais tranquila.

Antes de iniciarmos o conteúdo, faço questão de mencionar meu amigo Yuri Diógenes (https://www.linkedin.com/in/yuridiogenes/), Principal PM do Microsoft Defender for Cloud e a maior referência quando o assunto é CNAPP. Aproveito para deixar este link para uma de suas palestras sobre o tema: Improving your multi-cloud security with a Cloud Native Application Protection Platform (CNAPP).

O que é CNAPP?

![What is a Cloud Native Application Protection Platform (CNAPP)?](https://sp-ao.shortpixel.ai/client/to_auto,q_glossy,ret_img,w_1024,h_508/https://www.deepfactor.io/wp-content/uploads/2022/01/Devops-History-Definition-Business-Impact-1024x508.png align=“left”)

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

![Microsoft Defender for Cloud](https://learn.microsoft.com/pt-br/azure/defender-for-cloud/media/defender-for-cloud-introduction/defender-for-cloud-pillars.png align=“left”)

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.

É importante declarar que as integrações do Defender com outros cloud providers está em constante evolução, então é possível que nem todas as funcionalidades existentes em um dos produtos com o Azure esteja disponível no recurso equivalente do provedor de sua escolha.

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.

Os benchmarks utilizados por padrão são construídos pela própria Microsoft, com base nas melhores práticas de mercado e padrões de segurança reconhecidos. Você pode criar regras de identificação personalizadas, com o objetivo de garantir a aderência aos requisitos de compliance da sua empresa.

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.

Outro recurso que é importante comentar é o Defender for Identity, que não foi representado nos diagramas anteriores. O Defender for identity faz parte do conjunto de capacidades do Defender for Cloud, mas não é considerado um "integrante" das funções de CNAPP da ferramenta. Sua responsabilidade é potencializar a proteção das soluções de identidade de uma empresa, fornecendo insights e recomendações em ambientes Entra e Active Directory.

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!

Defesa em profundidade com Microsoft Azure

Wed, 05 Jul 2023 03:00:00 GMT

Um conceito importante no mundo de cibersegurança é a defesa em profundidade (defense in-depth). Nesse texto falo sobre algumas características desse conceito e como ele pode ser aplicado no seu ambiente Azure.

O desenho acima representa as camadas que devem ser protegidas em um ambiente. A proteção começa pela camada externa e vai sendo aplicada nas camadas interiores, por isso é importante não negligenciar a segurança em nenhuma das fases, ao ponto que a camada em questão, é protegida primariamente pela camada externa à si mesma (aplicação > dados, física > perímetro, etc).

As soluções utilizadas para proteção das camadas nesse artigo são exclusivamente da Microsoft. As empresas costumam ter soluções de diversos fornecedores em seu parque tecnológico, então entenda que para escolher a melhor solução, é importante entender corretamente o caso de uso e as necessidades da empresa.

Quando falamos de cloud, um conceito comentado com frequência, é a responsabilidade compartilhada. Esse conceito diz respeito às tarefas que são de responsabilidade do cliente e as que são de responsabilidade do provedor de cloud. Isso é tema para outro artigo, porém é importante que você esteja minimamente familiarizado para entender que através das camadas, a responsabilidade passa a ser cada vez mais do cliente.

Física

Em um ambiente de nuvem pública e fazendo referência ao modelo de responsabilidade compartilhada, a segurança física do ambiente é de responsabilidade total do provedor. Todos as variáveis relacionadas à segurança dos ambientes de data center são de completa custódia da empresa e o cliente não precisa se preocupar com isso.

A segurança dos data centers começa com a não divulgação de sua localização. Empresas como Microsoft, Amazon, Google, Oracle, tem múltiplos data centers ao redor do mundo e o local onde estão implantados é informação sigilosa, conhecida por poucas pessoas até mesmo dentro da própria empresa.

Agora na área dos data centers, a segurança é reforçada do início ao fim, pois a responsabilidade de se gerenciar tantas informações de tantos clientes e empresas diferentes é gigantesca. O acesso é extremamente restrito, permitido apenas a pessoas liberadas, é feito por agentes de segurança da própria empresa e de empresas contratadas. O ambiente contém câmeras em todos os pontos, para garantir que nenhum visitante indesejado tenha a oportunidade de chegar próximo da estrutura principal.

Para entrar no ambiente, existem diversas camadas de segurança que a pessoa deve passar, desde cadastro, revista e sendo sempre monitorada.

Pelo fato das empresas adotarem diferentes modelos de segurança para seus data centers, não é possível detalhar como a segurança é feita, porém no canal da Google Cloud no youtube temos esse vídeo, que é um tour por algumas áreas de um de seus data centers e ao longo do vídeo podemos ver como a segurança é prioridade máxima para as empresas, garantindo a confiança dos clientes de que suas informações estarão protegidas o tempo todo.

IAM

Entrando em seu ambiente cloud, a primeira barreira de defesa é a sua solução de IAM (Identity and Access Management), ou Gerenciamento de Identidade e Acesso. A solução adotada será responsável por controlar quem se autentica e o que essa pessoa poderá fazer no ambiente.

O controle das permissões dos usuários deve ser feito de maneira que o acesso fornecido seja somente o necessário (princípio do privilégio mínimo), reduzindo a margem para possíveis problemas causados pelo comprometimento de alguma identidade ou até mesmo por alguém agindo de má fé, querendo prejudicar a empresa.

Dito isso, aqui estão algumas soluções que podem ser utilizadas quando você estiver planejando seu ambiente de nuvem pública:

Microsoft Entra — Azure AD

Solução de identidade oficial da Microsoft e um dos IdPs (Identity Providers, Provedores de Identidade)mais utilizados no mundo. O Azure AD conta com uma série de recursos que podem ser utilizados para incrementar a segurança dos acessos aos teus recursos.

As Políticas de Acesso Condicional (Conditional Access Policies) permitem a criação de regras que analisam características do acesso de um usuário e realizam algumas ações determinadas, como exigir um segundo fator de autenticação. As políticas fornecem diversas opções de controles, então você pode aplicá-las apenas a uma ou a um grupo de aplicações, restringir sua aplicação a um grupo de usuários, análisar os riscos identificados e aplicar ações de acordo com a gravidade do risco (baixo, médio e crítico), entre outras coisas que você pode conferir neste link.

O Gerenciamento de Identidades Privilegiadas (PIM, Privileged Identity Management) fornece uma forma de proteger acessos com as chamadas permissões privilegiadas, que são permissões aplicadas a grandes quantidades de recursos ou que permitem que o usuário realize ações que devem ser restritas à poucas pessoas.

Defender for Identity

Como componente do Defender for Cloud, o Microsoft Defender for Identity fornece capacidades de segurança para identidades aplicáveis à cloud e ao on-premise (Active Directory).

Essa solução analisa os logs gerados pelos IdPs e identifica atividades suspeitas, compreendidas pelo estudo das diversas informações diferentes que são capturadas pela Microsoft em cada ação dos usuários.

Microsoft Entra — Permission Management

Recentemente lançada, o Gerenciamento de Permissões (Permission Management) do Microsoft Entra fornece uma interface centralizada para que os administradores e times de segurança tenham ampla visão das permissões que os usuários tem nas plataformas (Azure, AWS e GCP).

Perímetro

O perímetro é a segunda camada “lógica” dentro do ambiente cloud, e nela temos recursos que são “transparentes” para as aplicações. Todo ambiente contém alguns desses recursos que serão descritos à seguir, pois sua função é proteger contra os mais diversos ataques e manter os negócios operando sem problemas.

Azure DDoS Protection

Habilitado com o plano standard em todas as subscriptions por padrão, o Azure DDoS Protection tem a função de proteger seu ambiente de ataques DoS (Denial of Service) e DDoS (Distributed Denial of Service).

Fortalecido com o uso de Inteligência Artificial e Machine Learning, o Azure DDoS Protection é um componente robusto e eficiente, que análisa os padrões das requisições e consegue antecipar ataques com a inteligência presente no recurso.

Azure WAF

O Web Application Firewall é o recurso responsável pela proteção das aplicações que funcionam na camada 7 do modelo OSI. Esse recurso tem a capacidade de proteger aplicações web contra os mais variados ataques, como injeção SQL e cross-site scripting (XSS).

O Azure WAF não é criado como um recurso próprio, mas sim uma capacidade em outros recursos. Hoje os serviços que contém a capacidade de WAF disponível na Azure são: Azure CDN (Content Delivery Network), Azure Application Gateway e Azure Front Door. Esses recursos foram “escolhidos” para terem essa funcionalidade de WAF pois são recursos que em uma arquitetura empresarial de larga escala, ficam à frente dos componentes mais sensíveis (como bases de dados e servidores de aplicação). A presença em múltiplas zonas de disponibilidades (e até em múltiplas regiões como é o caso do front door) faz com que a proteção do ambiente se estenda de acordo com a escala do recurso.

Azure Firewall

Diferente do WAF, o Azure Firewall opera nas camadas 3 e 7 do modelo OSI. Com ele é possível construir diversas políticas de segurança de acordo com a origem e com o destino do tráfego. Podemos restringir acesso à sites, realizar análise nos pacotes trafegados nas requisições e bloquear requisições de origens classificadas pela Microsoft como perigosas.

Rede

A rede na cloud começa pela VNet (Virtual Network), que conterá todos os recursos que forem criados. Em um ambiente empresarial, é comum ter centenas de redes diferentes, variando de acordo com o tamanho da empresa. As redes são segmentadas em subnets, que são “pedaços” separados da rede, com range de IPs próprio e com capacidades próprias.

Para manter as VNets e subnets mais seguras, podemos utilizar esses 3 recursos:

Network Security Group

Os NSGs são soluções que podem ser criadas e anexadas às subnets e às interfaces de rede das máquinas virtuais.

São regras que permitem/bloqueiam a entrada e saída de tráfego dentro daquele recurso onde está aplicada. As regras são “simples”, mas contém uma série de variáveis que permitem que você consiga deixar de forma explícita, o que deve ser liberado e o que deve ser bloqueado naquele NSG.

As regras suportam IPs de origem e destino, portas, protocolos, FQDN (fully qualified domain name), entre outras informações que podem ser visualizadas aqui.

Application Security Group

Os ASGs são mais peculiares do que os NSGs. Apesar da semelhança no nome, os ASGs e os NSGs funcionam de maneira parecida mas para propósitos diferentes.

Os ASGs foram criados para incrementar a proteção de aplicações que foram hospedadas em máquinas virtuais. As interfaces de rede das VMs são colocadas em um grupo lógico que permite a criação de regras (como as do NSG) para todas as interfaces de rede que estão presente no mesmo grupo.

Bonus: Network Watcher

As soluções do Network Watcher não são necessariamente de segurança, afinal de contas elas não agem em cima de uma ameaça ou regra criada. O NW fornece uma série de recursos que permitem analisar o tráfego de rede para visualização de logs, entender o funcionamento dos NSGs, verificar o que entra e o que sai de uma VM, entre outras ferramentas.

O NW é muito útil no momento que precisamos entender o funcionamento do tráfego de rede em um ambiente grande com diversas camadas de segurança, componentes e cheio de segmentações de rede.

Compute

Entrando nas 3 camadas do meio, vamos falar sobre compute. A camada de compute (ou computação), é responsável pela execução das aplicações da sua empresa. Nessa camada, temos máquinas virtuais, contêineres, oquestradores de contêiner (azure kubernetes service, azure red hat openshift, etc) entre outras soluções.

Antes de apresentar as soluções dessa camada, um breve histórico:

Um grande problema encontrado em ambientes empresariais, é a exposição desnecessária de portas em máquinas virtuais. Portas como a 22 (SSH) são usadas para acessar o recurso diretamente, dando controle sobre o recurso ao usuário que está conectado. Outro problema comumente encontrado é a falta de segurança das credenciais de acesso à esses recursos (chaves SSH e arquivo de conexão RDP).

Azure Bastion

O Azure Bastion tem o propósito de resolver um desses problemas. Uma vez criado, o recurso permite que o usuário se conecte à máquina virtual de maneira segura, utilizando o protocolo HTTPS (porta 443). O usuário precisa conectar no portal azure e realizar o login para conseguir acesso à máquina, isso sem a preocupação de deixar suas credenciais “soltas” e inseguras, como é o caso de uma conexão direta ao servidor por meio de SSH ou RDP.

JIT VM Access (Just In Time VM Access)

O segundo problema apontado, é resolvido por esse recurso. O JIT VM Access (traduzido ficaria algo como Acesso à VM em tempo real) é parte do Defender for Cloud e realiza a abertura de certas portas apenas quando se faz necessário.

Uma VM tem um NSG atrelado à sua interface de rede e nesse NSG não há regras de liberação das portas 3389 (RDP) ou 22 (SSH). Caso seja necessário se conectar ao recurso, o JIT realiza a abertura das portas por um tempo determinado, para que o usuário possa concluir suas tarefas e após encerrá-las, a porta será fechada novamente e o recurso estará seguro.

Aplicação

Chegando ao nível do código da aplicação, ainda temos que nos preocupar. É importante que saibamos que os códigos que estamos colocando em produção, são seguros e estão sendo monitorados constantemente pelas ferramentas adotadas.

Mesmo com a inserção da segurança no ciclo DevOps (DevSecOps) e com todas as ferramentas de análise de código (SAST/DAST), não podemos simplesmente assumir que uma aplicação é/está segura, é importante a avaliação constante dos recursos que temos.

Defender for Container

Mais um componente da suíte do Defender for Cloud, o Defender for Containers permite aumentar a segurança do seu ambiente que utiliza contêineres.

A plataforma é habilitada por padrão para realizar assessments de segurança em clusters AKS (Azure Kubernetes Service), EKS (Elastic Kubernetes Service — AWS) e em plataformas Kubernetes on-premise.

A ferramenta oferece todas as funcionalidades “padrão” que as outras soluções do defender for cloud disponibilizam (pontuação de segurança, alertas, recomendações, etc.).

Dados

Por último (e com certeza não menos importante) temos a camada central do ambiente. Os dados.

A camada de dados é representada por todas as soluções que de alguma forma armazenam informações (bases de dados, discos, storage accounts, etc.). Em uma era onde os dados são fundamentais em literalmente todos os aspectos, mantê-los seguros at-rest (em descanso), in transit (em trânsito/em movimento) e longe de atacantes é fundamental para a estratégia da empresa.

Para cumprir com esses requisitos, alguns recursos contém funcionalidades nativas para garantir a segurança dessas informações. Aqui estão algumas:

Transparent Data Encryption (TDE)

Funcionalidade disponível em bases de dados SQL (Azure SQL Database, SQL Server e Synapse Analytics), o TDE realiza a criptografia at rest dos dados presentes nos recursos em que é aplicado.

Storage Service Encryption

Recurso ativo por padrão nas storage accounts, o SSE realiza a criptografia e a descriptografia at rest, sem afetar a performance do recurso e de forma completamente transparente ao usuário.

Essa funcionalidade independe do tipo de storage account que você criou, elas sempre estarão protegidas por esse recurso.

Como mencionei no início do texto, é importante que a segurança de todas as camadas seja tratada de maneira séria. A segurança de uma camada se inicia pela segurança de sua camada mais externa, que tem o papel não só de proteger os recursos condizentes à aquele nível, mas também aos recursos que estão em camadas mais “profundas” que ela.

Analise o ambiente da empresa onde você trabalha, seja um ambiente em nuvem ou on-premise. As camadas costumam ser facilmente identificáveis. Veja quais soluções estão sendo utilizadas, se há algum tipo de cobertura diferente sendo feita na empresa, ou até mesmo se há algum gap de proteção que você identificou.

Se você trabalha com ambientes Azure, esse texto é a sua referência para construção de uma arquitetura em camadas segura.

Caso tenha alguma dúvida, não deixe de comentar.

Obrigado pela atenção ❤

Entra MFA: guia completo!

Tue, 14 May 2024 03:00:00 GMT

As identidades são os principais insumos na defesa (e também no ataque) de um ambiente em nuvem. Com elas que realizamos nossas tarefas do dia a dia e acessamos os sistemas e aplicações da nossa organização. Garantir a integridade dos acessos e a garantir da segurança de uma conta é fundamental para a boa operaçaõ do ambiente em nuvem. Por isso, hoje falaremos sobre MFA e as possibilidades disponibilizadas pelo Microsoft Entra ID.

Em adição ao primeiro artigo sobre MFA do blog (que você pode acessar clicando aqui) hoje vamos fazer um deep dive nas soluções de MFA presentes no Microsoft Entra ID.

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

![](https://learn.microsoft.com/pt-br/entra/identity/authentication/media/concept-authentication-methods/authentication-methods.png align=“center”)

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.

Cuidado para não pular etapas! Partir de uma solução de autenticação tradicional baseada em credenciais para soluções passwordless pode ser uma catastrofe. É importante que os integrantes da organização passem por um período de adaptação, aprendendo a utilizar a ferramenta distribuída e ganhando confiança e conforto no modelo implementado.

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.

Esse recurso hoje tem efeito apenas para o uso do Microsoft Authenticator, não podendo ser utilizado com nenhum dos outros recursos disponíveis no Entra.

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.

Esse recurso tem impacto apenas para usuários que estejam utilizando o Microsoft Authenticator ou as chamadas de voz como segundo fator de autenticação.

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”

Criando políticas de acesso condicional

Mon, 24 Jul 2023 03:00:00 GMT

Sendo um dos recursos de maior valor do Entra ID (antigo Azure AD), as políticas de acesso condicional (conditional access policies) fornecem aos times uma maneira poderosa de proteger os recursos no Azure e as aplicações conectadas ao Entra ID. Vamos mergulhar nesse recurso!

OBS: antes de começarmos a trabalhar com as políticas, é importante que você se atente ao licenciamento necessário para utilizá-las. A Microsoft exige que você tenha um tenant do Entra ID com qualquer uma das licenças (P1, P2, E3 ou E5). Tendo qualquer uma delas, você estará habilitado para começar a construir suas políticas e proteger seu ambiente.OBS2: pode ser que ao entrar no portal do Entra na blade de Acesso Condicional (Proteção > Acesso Condicional) você seja apresentado com o seguinte aviso:

Os tenants do Entra ID tem uma configuração chamada padrões de segurança (security defaults) que está habilitada por padrão em todos os novos tenants. Para desativá-la basta clicar no texto clicável do aviso (“desabilitar os padrões de segurança”) e selecionar “Desabilitado”.

Padrões de Segurança (Security Defaults): a função dos padrões de segurança é fornecer alguns requisitos mínimos de proteção ao ambiente do Entra ID. Quando habilitado, os administradores não precisam realizar nenhum tipo de configuração adicional, visto que o tenant como um todo será protegido pelos padrões. Os controles de segurança aplicados pelos security defaults são os seguintes:

Autenticação multifator: exige que os usuários cadastrem alguma forma de autenticação multifator;
Bloqueio de autenticações legado: com o objetivo de oferecer mais segurança ao ambiente, o bloqueio de protocolos legado não permite autenticações que utilizem protocolos legado;
Proteção de atividades privilegiadas: para contas privilegiadas (alto nível de acesso e permissões), os usuários terão que realizar a autenticação multifator;

Iniciando com as políticas

Após desativar os padrões de segurança, podemos prosseguir com a criação da nossa primeira política de acesso condicional.

Nesse tutorial, vamos criar uma política que exija autenticação multifator (MFA) para determinados usuários do nosso tenant.

O primeiro passo é criar um nome. É importante lembrar que sua organização provavelmente terá dezenas (se não centenas) de políticas de acesso condicional, então escolher um bom nome e que descreva corretamente o que a política fará é de extrema importância. Isso facilitará o trabalho dos profissionais que terão que modificar as políticas no futuro ou que desejam consultá-las para entender quais proteções estão sendo aplicadas no ambiente.

Vamos seguir com o seguinte nome:

Exigir MFA para usuários específicos

Usuários

Entrando efetivamente na construção das nossas políticas, o primeiro passo é selecionar quem será afetado por ela:

Ao selecionar o campo “usuários” você poderá escolher na aba “incluir”, usuários e grupos que serão afetados pela política. Na aba “excluir” você colocará as exceções para a política, ou seja, usuários e grupos que não deverão sofrer a aplicação das regras. Ao contrário da aba “incluir”, não é obrigatório preencher nenhum dos campos da aba “excluir”.

Para este exemplo, vamos aplicar a política apenas à um usuário como mostra a imagem a seguir:

Após escolher “selecionar usuários e grupos” você terá essas opções à cima para serem marcadas.

“Usuários convidados ou externos” são contas que não são nativas do seu tenant.

“Funções do diretório” permite que você selecione algumas “roles”, assim os usuários que contenham qualquer uma delas sofrerão a aplicação da política.

“Usuários e grupos” permite que você escolha qualquer um dos usuários e grupos presentes no seu tenant.

Recursos de destino

Após escolher quem será impactado pelas políticas, é hora de escolher O QUE será impactado.

Nessa seção nós selecionaremos quais aplicativos o usuário utilizar e/ou quais ações o usuário realizar que serão impactadas pela política.

Aplicativos de nuvem

Dentro dessa seção nós podemos escolher aplicações que estão “federadas” no Entra ID devem ter seu acesso controlado. Caso seu tenant seja novo, você provavelmente não terá nenhuma aplicação federada, mas por padrão você poderá selecionar o Office 365 e o portal do Azure para terem o acesso controlado.

O aplicativo selecionado (portais de administração da Microsoft) contém um conjunto de aplicações (como o Portal do Entra e o Portal do Azure). Quando seu tenant tiver mais aplicações federadas (SaaS, portais, aplicações próprias, etc) você poderá selecioná-los para serem impactados pelas políticas.

Nesse caso não faremos uso da funcionalidade de exclusão da política, mas para fins de conhecimento ela funciona da mesma forma que na seção de usuários.

Esse campo “editar filtro” permite que você crie regras personalizadas baseadas em atributos das aplicações para selecioná-las de maneira dinâmica.

Ações do usuário

Essa seleção permite escolher duas ações que podem ser realizadas pelos usuários: inserir informações de segurança e entrar com um dispositivo no Entra ID (seja registrá-lo ou apenas realizar login no mesmo).

Para esse tutorial não vamos utilizar essa capacidade da plataforma.

Contexto de autenticação

Os contextos de autenticação fornecem uma maneira de proteger o acesso à áreas e informações sensíveis de aplicações.

Essa funcionalidade habilita que os administradores dos sistemas controlem o acesso à informações personalizadas utilizando a força das políticas de acesso condicional.

Esse recurso também oferece certa granularidade na proteção das aplicações. A usabilidade das plataformas é de extrema importância para os administradores, pois isso afeta a produtividade dos usuários no dia a dia. Apenas imagine, você precisando se re-autenticar o tempo todo enquanto utiliza uma aplicação crítica para suas atividades. Pensando na usabilidade, podemos restringir as re-autenticações apenas ao acesso a informações privilegiadas.

Antes de configurar o contexto de autenticação na política, é necessário registrar o contexto. Se quiser ter mais detalhes, recomendo a leitura dessa documentação.

Condições

Após selecionarmos QUEM e o QUE terão seus acessos controlados, chegou a hora de selecionar outras informações que deverão ser levadas em conta quando estivermos construindo nossas políticas.

Essa seção é enorme e cheia de variáveis, não entraremos a fundo em cada uma das possibilidades. Para melhor conhecimento, sugiro que faça seus testes em casa construindo as mais variáveis políticas.

O Entra ID Identity Protection fornece diferentes capacidades de análise de segurança para os usuários da plataforma. Com ele, diversas informações dos usuários e de seus logins são captadas e analisadas pela própria plataforma, identificando ameaças, invasões, atividades suspeitas e outros riscos às identidades e aos recursos da sua empresa. Os riscos de usuário e riscos de entrada são funcionalidades próprias do Entra ID Identity Protection.

A lista de riscos identificados pelo ID Protection é extensa, então para facilitar o seu entendimento, vou inserir um print das capacidades de cada um deles, bem como o link para a documentação oficial da Microsoft que trata dessas informações.

Risco de usuário

Dentro dessa área da política, você poderá selecionar qual a severidade de risco que deverá ser levada em conta para que a política seja aplicada.

Os riscos de usuário podem ser classificados como baixo, médio e alto.

Risco de entrada

Com uma gama de riscos identificáveis muito maior, os riscos de entrada contém uma categoria a mais que os riscos de usuário. Elas são: sem riscos, baixo, médio e alto.

Plataforma de dispositivo

Nessa seleção, você poderá escolher quais sistemas operacionais devem ser levados em conta quando o acesso for realizado.

Essa seleção pode ser útil principalmente se a sua organização utilizar dispositivos de apenas um sistema operacional. Com essa política, podemos identificar acessos não autorizados vindo de dispositivos de fora da organização.

Locais

Podemos levar em conta a localização física do usuário que está realizando o acesso. Essa capacidade é muito útil para restringir acesso à aplicações apenas de dentro da rede da empresa.

Não é escopo desse artigo, mas com o Entra ID nós podemos registrar ranges de IP que são confiáveis para a empresa e esses podem ser escolhidos dentro da política de acesso condicional.

Aplicativos cliente

Após escolher qual plataforma de dispositivo, é possível selecionar os diferentes locais onde as aplicações estão sendo executadas (aplicações web e/ou nativas do dispositivo).

Filtro para dispositivos

Essa capacidade permite criar regras personalizadas e baseadas em atributos dos dispositivos para aplicação das políticas.

Aqui está um exemplo de uma política com filtro. A query acima seleciona dispositivos que NÃO estejam em compliance com as regras definidas pela empresa. Essa capacidade oferece dezenas de propriedades que podem ser utilizadas e é uma funcionalidade extremamente potente para aumentar a cobertura das suas políticas.

Controles de acesso

Entrando na seção final da nossa política, temos o controle de acesso. Nesse campo nós selecionaremos quais controles serão aplicados aos acessos que tiverem a política aplicada.

Conceder

Podemos escolher entre bloquear o acesso do usuário ou permitir o acesso e aplicar algum dos controles fornecidos logo em seguida. Você pode selecionar um ou mais controles e no final pode escolher se todos os controles selecionados devem ser aplicados ou se somente um deles é necessário.

Caso você selecione a opção “requerer mudança de senha” não será possível escolher mais nenhuma outra opção e será requerido que você selecione a força de autenticação como mostra a imagem abaixo:

Essa configuração exigirá que o usuário realize sua autenticação utilizando o método selecionado na lista acima.

Sessão

O controle de sessão permite impor restrições à usabilidade das aplicações por parte dos usuários.

Dentre as opções existentes podemos exigir uma re-autenticação na aplicação, tempo de duração das sessões (quanto tempo um usuário pode ficar sem se re-autenticar) e muitas outras opções.

Habilitação da política

Após ter construído sua política, podemos colocá-la em 3 estados possíveis:

Somente relatório: a política não agirá de acordo com as regras determinadas, ou seja, o usuário não será impactado de forma alguma. Nesse caso, todos os logins e atividades dos usuários passam pela política e são feitos registros (logs) que informam se a política foi aplicada e de que forma;
Ativado: a política entrará em ação e todos os seus controles serão aplicados quando necessário;
Desativado: sua política será criada mas não estará em funcionamento;

Resultado final: essa política exigirá que o usuário (User A) realize a autenticação multifator ao acessar qualquer um dos portais administrativos da Microsoft. O usuário que não tiver nenhum dispositivo de MFA cadastrado, será apresentado com uma página no navegador que conterá a jornada para download do aplicativo mobile Microsoft Authenticator bem como seu registro para permitir a autenticação.

As políticas de acesso condicional são um grande aliado para você e para sua empresa na luta contra os ciberataques e contra os riscos relacionados às identidades. Utilize-as e proteja seu ambiente de maneira correta e eficiente.

Espero que tenha gostado e que agora se sinta hábil para construir suas policies sozinho.

Até logo!

Certificate-based Authentication

Wed, 17 Jul 2024 03:00:00 GMT

Em mais um artigo sobre segurança de identidades e acessos, vamos falar sobre o que é a autenticação baseada em certificados, quais os cenários em que pode ser utilizada e as características e peculiaridades de sua implementação. A solução base para esse artigo técnico, como sempre, será o IdP da Microsoft, o Entra ID.

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.

Para mais informações sobre passwordless, veja este artigo.

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:

![](https://learn.microsoft.com/en-us/entra/identity/authentication/media/concept-certificate-based-authentication-technical-deep-dive/how-it-works.png align=“center”)

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:

![](https://learn.microsoft.com/en-us/entra/identity/authentication/media/how-to-certificate-based-authentication/issuer-and-serial-number.png align=“center”)

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.

![Microsoft Entra certificate-based authentication technical deep dive - Microsoft Entra ID | Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/authentication/media/concept-certificate-based-authentication-technical-deep-dive/validation-error.png align=“center”)

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!

Azure AD — conceitos básicos

Mon, 10 Jul 2023 03:00:00 GMT

Conhecido como o “substituto” do Active Directory, o Azure AD é a solução de identidade cloud-native da Microsoft. Essa ferramenta é muito mais do que um simples provedor de identidade. Nela temos capacidades de segurança, gestão de dispositivos, autenticação híbrida, federação de aplicações e muito mais.

Estamos tratando de uma ferramenta poderosíssima, não apenas dentro do escopo Azure mas também fora. Suas capacidades oferecem a possibilidade de gerir, controlar e proteger os recursos a ele conectados.

Hoje falaremos de alguns conceitos básicos sobre identidades na nuvem pública, sobre algumas funcionalidades fornecidas pela ferramenta e como ela pode ajudar a garantir a boa operação e a segurança do seu ambiente Azure.

Controlando e protegendo recursos no Azure

O Azure AD é a porta de entrada para os recursos do Azure. Com ele nós operamos a primeira camada de segurança dentro da nuvem pública. É nele que realizaremos a autenticação e a autorização de todos os usuários que acessam não somente o console do Azure mas também todas as aplicações federadas no tenant (o conceito de tenant será explicado mais pra frente neste mesmo artigo).

Mas não estamos falando apenas de uma ferramenta de autenticação e autorização. Ele fornece as capacidades para gestão de bases de usuário gigantescas, permitindo às empresas uma melhor governança dos recursos existentes. Com ele podemos gerir usuários, aplicações e até dispositivos (cenário comum em empresas que fornecem aos funcionários dispositivos como laptops e celulares para trabalho).

A observabilidade nunca foi tão importante para as empresas quanto hoje. É essencial que os times de segurança e auditoria possam monitorar e consultar todas as ações realizadas no ambiente. Essas capacidades são entregues de maneira nativa pelo Azure AD. Com ele temos o registro completo dos logins dos usuários (sign-in logs)e também o registro das ações realizadas dentro da plataforma por eles (audit logs).

A ferramenta é extremamente poderosa e essas foram apenas algumas funcionalidades que estão disponíveis para serem utilizadas. Agora vamos falar um pouco sobre algumas funcionalidades e alguns conceitos da solução, para que você consiga entender o básico e para que fique confortável para os próximos artigos sobre o tema.

Tenant

Conhecido também como locatário (se você visualiza os recursos em português), representa o Azure AD de uma organização. O tenant é o “objeto” que centraliza todas as capacidades do Azure AD e é nele que faremos a criação dos usuários, dos grupos, das políticas de segurança, das aplicações federadas e de muitos outros recursos disponíveis.

Devemos entender que uma subscription SEMPRE estará conectada a 1 tenant do Azure AD.

Empresas podem ter mais de 1 tenant de Azure AD em seu ambiente por diversos motivos (como por exemplo: para executar testes diversos no ambiente) mas não é interessante que exista mais de um tenant produtivo, pois a operação se tornará muito mais complexa e isso consequentemente aumenta a superfície de ataques, visto que falhas de configuração serão mais comuns.

O simples desenho acima representa a relação quantitativa entre uma subsciption e o azure ad tenant. Uma subscription SEMPRE confiará em um tenant, pois ele será o responsável por controlar o acesso à própria subscription e a todos os recursos que estiverem dentro dela.

É importante comentar que um tenant pode estar conectado à várias subscriptions diferentes ao mesmo tempo, mas uma subscription só pode estar conectada a um tenant de cada vez.

Understanding Tenants, Subscriptions, Regions and Geographies in Azure — DevOpsSchool.com

Este desenho representa bem a relação entre o tenant e os outros recursos do Azure. Um tenant pode conter múltiplas subscriptions (que são estruturas que ficam abaixo dos management groups) e uma subscription pode conter múltiplos resource groups (que são as estruturas lógicas onde efetivamente criamos os recursos).

Uma coisa que devemos deixar clara é: o tenant do Azure AD é um recurso apartado das suas subscritptions. O tenant não é criado e gerenciado como um banco de dados ou um cluster AKS por exemplo. Ele é uma estrutura segregada dos componentes hierárquicos do Azure (root management group, management group e subscriptions).

Explicado o conceito de tenant e a relação com algumas das outras estruturas do Azure, vamos falar sobre permissionamento na nuvem e explicar um conceito muito famoso chamado RBAC.

RBAC

O role based access control (ou em português, controle de acesso baseado em função) tem como propósito permitir o controle de acesso aos recursos do Azure (e Azure AD) baseado na função que o usuário exercerá.

Esse modelo de controle garante maior flexibilidade no permissionamento, pois dessa forma os times de segurança podem criar funções que se adaptem aos cargos dos funcionários da empresa e delegar a eles as permissões necessárias para que possam realizar suas atividades.

Para entendermos melhor o funcionamento das RBACs, vamos ao exemplo:

Temos 4 funcionários, como demonstra o desenho acima. O engenheiro é responsável pela criação dos recursos que serão utilizados pelos diversos times e também pela criação das policies de acesso para aumentar a segurança do ambiente. A desenvolvedora é responsável pela construção dos códigos das aplicações, então o acesso necessário para ela é apenas aos recursos da solução, que foram criados pelo engenheiro. A designer não precisa de nenhum acesso dentro da Azure, pois seu trabalho se dá fora dos recursos da plataforma, em ferramentas externas (como Adobe). O último funcionário é responsável por toda a gestão dos acessos, é ele quem criará os usuários, grupos e fará a reinicialização das senhas quando necessário.

Esse exemplo nos permitiu entender como o controle de acesso baseado em função capacita os times para que gerenciem e forneçam acesso aos recursos da nuvem pública com eficiência e para que adicionalmente, consigam aplicar o princípio do privilégio mínimo. Aplicando esse princípio, diminuímos a chance de termos problemas causados por usuários mal intencionados.

Privilégio mínimo: princípio da área de cibersegurança que busca garantir que os usuários detém apenas os acessos NECESSÁRIOS e nada mais.

Funções do Azure x Funções do Azure AD

Agora que você entendeu como funcionam as funções (RBAC), é importante saber distinguir as funções do Azure AD e do Azure.

Como comentado anteriormente, o tenant do Azure AD e os recursos do Azure são duas coisas diferentes, consequentemente as funções para o controle de acesso também são diferentes entre eles.

Azure AD RBAC: permissionamento para ações que os usuários poderão executar no tenant. Essas ações englobam: gerenciar usuários e grupos, criação de políticas de acesso condicional, usuário de helpdesk, administrador de aplicações, entre dezenas de outras funções;
Azure RBAC: as funções do Azure existem para permitir o controle de acesso aos recursos da plataforma, recursos esses como: bancos de dados, filas, tópicos de eventos, cofres de senha, máquinas virtuais, etc. Com as funções do Azure nós podemos controlar quais ações os usuários poderão executar e em qual escopo (recurso, resource group, subscription e até management group).

Esses foram alguns conceitos gerais sobre Azure AD e sobre identidades, para que você pudesse começar a se ambientar com os termos e conceitos que giram em torno do Azure AD. Nos próximos artigos, entraremos no detalhe de algumas funcionalidades da plataforma e buscaremos sempre trazer uma visão de segurança para os apresentados.

Espero que tenha aproveitado a leitura e me coloco a disposição para responder suas dúvidas.

Até logo!

Utilizando a lib @Identity para autenticação no consumo de serviços no Azure

Tue, 21 Nov 2023 03:00:00 GMT

Com a proposta de facilitar a autenticação e autorização para consumo dos recursos no Azure, a Microsoft disponibiliza de uma library que permite implementar essas funcionalidades de uma maneira simples.

Entendendo a lib

Como comentado anteriormente, a proposta da lib é disponibilizar uma maneira simples de autenticar e autorizar o consumo à partir de um serviço aos recursos do Azure.

A lib foi construída de uma maneira onde a sua implementação e a promoção do software para os estágios do desenvolvimento (desenvolvimento, homologação e produção, em sua maioria) é simples e escalável.

Com ela, podemos autenticar a aplicação utilizando uma Managed Identity ou também utilizando as credenciais de uma Service Principal. As classes existentes facilitam a integração com qualquer um dos tipos de identidade.

Acima, vemos um exemplo de alto nível sobre a integração dos diferentes tipos de identidade existentes na plataforma e o consumo de diferentes recursos.

Os recursos no destino não se limitam apenas a esses. Todos os recursos da plataforma podem ter seu consumo controlado através da atribuição das roles no portal de IAM, na console do próprio recurso.

Uma informação interessante de se mencionar é: as classes disponíveis implementam as interações com o IdP (Identity Provider) baseadas nos modelos dos protocolos OAuth 2.0 e OIDC (Open ID Connect), então ao estudar a documentação da lib, você verá diversas menções a termos como “public or confidential client”, que remeterão o desenvolvedor aos conceitos dos protocolos mencionados neste parágrafo. Ter um conhecimento mínimo de como esses protocolos funcionam, permitirá ao desenvolvedor compreender as interações entre aplicação de IdP de maneira mais simples, porém nenhum conhecimento prévio é necessário para utilização da lib.

Implementando ao código

Já que falamos brevemente sobre o funcionamento da lib, vamos aos exemplos em código.

Os exemplos deste artigo serão escritos utilizando Javascript, porém o conceito das classes e a utilização da lib se aplica a qualquer outra tecnologia que você desejar utilizar.

Instalando a lib

O primieiro passo para iniciarmos a utilização dos recursos, é a instalação da lib em seu projeto. Isso pode ser feito utilizando o comando:

npm install @azure/identity

Para o comando acima funcionar, é necessário que você tenha inicializado seu projeto node antes de seguir com a instalação dos pacotes.

Classes para autenticação

Após realizar a instalação da lib, é hora de decidirmos qual tipo de classe iremos utilizar.

A Microsoft disponibiliza uma “matriz” para a tomada de decisão sobre qual credencial utilizar. Para facilitar o vosso entendimento, materializei a matriz no diagrama abaixo:

Como podemos visualizar acima, apenas com duas perguntas é possível compreender qual classe deverá ser utilizada de acordo com o seu caso de uso.

A classe “DefaultAzureCredential” deve ser criada caso seu desejo seja de que o sistema interprete qual o melhor tipo de credencial a ser utilizada.

Importando as classes

Para importar as classes para o seu projeto, utilizamos a sintaxe padrão do Javascript em projetos com NodeJS:

import { 
EnvironmentCredential, 
ManagedIdentityCredential, 
DefaultAzureCredential
 } from "@azure/identity";

As classes acima foram importadas apenas como exemplo, é necessário que você importe apenas as classes que serão utilizadas em seu projeto.

Implementando as classes importadas acima

Para fins de simplicidade no tutorial, utilizaremos apenas as classes que foram importadas no trecho de código acima. Caso você precise utilizar alguma das outras classes que não tiveram sua implementação tratada neste artigo, minha sugestão é a leitura da página oficial do github para o SDK do Entra ID para Javacript: https://github.com/Azure/azure-sdk-for-js/blob/main/documentation/using-azure-identity.md.

EnvironmentalCredential

Essa classe é completamente dependente da criação de uma Service Principal. Service Principals podem ser criadas através da linha de comando ou através dos portais adminstrativos (Portal do Entra ou Portal do Azure).

Para criar uma service principal pela linha de comando, utilize o seguinte script:

az ad sp create-for-rbac --name "name for service principal"

A execução do comando acima gerará um retorno como o exemplo abaixo:

{
  "appId": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "displayName": "name for service principal",
  "password": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "tenant": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}

A única propriedade que você não fará uso é o “displayName”, todas as outras serão utilizadas como variáveis de ambiente.

// Essa classe busca certas variáveis de ambiente para criação do objeto
// AZURE_TENANT_ID e AZURE_CLIENT_ID são variáveis necessárias
// AZURE_CLIENT_SECRET é a primeira variável que será buscada
// AZURE_CLIENT_CERTIFICATE_PATH é a segunda variável buscada
// AZURE_USERNAME e AZURE_PASSWORD será o par da última tentativa
const envcred = new EnvironmentCredential();

O trecho de código acima mostra a simplicidade da implementação deste tipo de classe. Bastando inicializar o objeto, o SDK contém a inteligência necessária para buscar as informações necessárias.

Em tempo de desenvolvimento, talvez seja necessário criar um arquivo “.env” para armazenar as variáveis de ambiente. Caso o projeto esteja utilizando um serviço como o Azure Functions, o recurso tem um próprio modelo de declaração de variáveis de ambiente (sendo nas Azure Functions, o arquivo local.settings.json), então não se faz necessária a criação do arquivo de variáveis.

Utilizando NodeJS, para carregar as variáveis de ambiente para o seu código, é necessário utilizar um pacote como o “dotenv”, que buscará um arquivo de extensão “.env” e carregará as variáveis de ambiente no seu programa, podendo acessá-las diretamente através do objeto process.env.

Serviços recomendados para utilizar essa classe: Azure Functions, Azure App Service, Azure Virtual Machines, entre outros serviços disponíveis.

ManagedIdentityCredential

Agora falando das identidades totalmente gerenciadas, temos as Managed Identities. O interessante dessas credenciais é que não precisaremos criar nenhum tipo de segredo, muito menos de Service Principal.

Quando falamos de Managed Identities existem dois tipos: System-Assigned e User-Assigned. Os dois tipos compartilham o conceito, uma credencial completamente gerada pela plataforma, a diferença entre elas é o ciclo de vida, onde na System-Assigned temos uma credencial que será excluída no fim do ciclo de vida do recurso enquanto com as User-Assigned as credenciais devem ser excluídas de maneira explicita.

Para utilizar uma Managed Identity com a lib, criamos uma instância da seguinte classe:

// Não é necessário a configuração de nenhum tipo de parâmetro
const mngdcred = new ManagedIdentityCredential();

Essa instância de classe funcionará apenas quando o desenvolvimento estiver sendo feito diretamente no recurso, possibilitando que o objeto recupere as informações da Managed Identity atribuída.

Serviços recomendados para utilizar essa classe: Azure Functions, Azure Virtual Machines, Azure App Service, etc.

DefaultAzureCredential

Com a proposta de deixar o modelo de autenticação mais flexível, temos a classe DefaultAzureCredential. Essa classe não expõe nenhum modelo de autenticação de maneira explícita, ela abstrai o modelo de autenticação e autentica o as chamadas com as informações que tem disponível (a classe buscará informações na seguinte ordem: variáveis de ambiente, service principal, managed identity, azure cli, azure powershell e azure developer cli).

Para utilizar a classe, a instanciamos da seguinte forma:

const dfcred = new DefaultAzureCredential();

A instância da classe criada, nos permitirá consumir os recursos da plataforma passando a variável onde a armazenamos como parâmetro na chamada dos métodos!

Utilizando a identidade para consumo dos recursos (ex: Azure Service Bus)

Para exemplificarmos o funcionamento dessa lib, vamos realizar um breve teste enviando mensagens para uma instância do Azure Service Bus:

import { DefaultAzureCredential } from "@azure/identity";
import { ServiceBusClient } from "@azure/service-bus";
const messages = [
  { body: "Albert Einstein" },
  { body: "Werner Heisenberg" },
  { body: "Marie Curie" },
];
const fullyQualifiedNamespace = "<BUS NAMESPACE>.servicebus.windows.net";
const credential = new DefaultAzureCredential();
const queueName = "<QUEUE NAME>";
async function main() {
  const sbClient = new ServiceBusClient(fullyQualifiedNamespace, credential);
  const sender = sbClient.createSender(queueName);
  try {
    let batch = await sender.createMessageBatch();
    for (let i = 0; i < messages.length; i++) {
      if (!batch.tryAddMessage(messages[i])) {
        await sender.sendMessages(batch);
        batch = await sender.createMessageBatch();
        if (!batch.tryAddMessage(messages[i])) {
          throw new Error("Message too big to fit in a batch");
        }
      }
    }
    await sender.sendMessages(batch);
    console.log(`Sent a batch of messages to the queue: ${queueName}`);
    await sender.close();
  } finally {
    await sbClient.close();
  }
}
main().catch((err) => {
  console.log("Error occurred: ", err);
  process.exit(1);
});

O código acima foi retirado do repositório oficial da Microsoft para a SDK do Service Bus para Javascript. Ele contém apenas algumas modificações, para redução do tamanho do arquivo.

Neste snippet de código, utilizamos a classe “coringa” para realizar a autenticação da aplicação, porém de acordo com a sua necessidade, você pode utilizar qualquer uma das classes citadas anteriormente.

Repare que ao instânciar o objetdo do ServiceBusClient nós passamos como segundo parâmetro a instância da nossa autenticação. Esse modelo será utilizado para o consumo de qualquer outro serviço de plataforma e também para qualquer tipo de classe de autenticação escolhida.

Decidindo entre as diferentes classes

Neste texto abordamos apenas as classes que permitem a autenticação do consumo em recursos SEM interação com o usuário.

Como definido no fluxo OAuth 2.0 e OIDC, chamadas de API em nome do usuário devem ter o consentimento explícito do ator que está utilizando a aplicação, por isso que para aplicações executadas no browser, as classes utilizadas são implementadas com o fluxo diferenciado.

Agora, para as aplicações sem interação com o usuário, como é o caso deste exemplo que fizemos ao longo do artigo, as classes abordadas servirão muito bem.

O ponto central para a tomada de decisão sobre qual classe utilizar deve ser: quanto controle você deseja ter sobre o objeto de autenticação?

Utilizar uma classe que abstrai a implementação da autenticação, como é o caso da DefaultAzureCredentials, também retira uma parcela do poder de personalização do desenvolvedor, em troca, o mesmo não precisa se preocupar com nenhum tipo de configuração adicional.Caso seja importante que você tenha acesso a certas informações fornecidas pela credencial, é recomendado que você siga com a implementação de alguma das outras classes abordadas no texto!

Espero que tenha gostado do conteúdo! O consumo seguro dos recursos em nuvem é extremamente necessário e importante, e acima de tudo, simples e efetivo, quando é possível usufruir de uma lib que permite a implementação dos métodos de maneira efetiva.

Até logo!

Evitando o compartilhamento de dados sensíveis com o Purview Communication Compliance

Wed, 07 Feb 2024 03:00:00 GMT

A lista de ferramentas de comunicação e produtividade corporativas cresce a cada dia nos chamados “pacotes empresariais”, como o Microsoft Office 365. Empresas centralizam as comunicações em soluções como o Microsoft Teams, que acaba sendo utilizado por funcionários, terceirizados, convidados e mais. Diante disso, um desafio é apresentado: como evitar o compartilhamento/vazamento de informações sensíveis entre os usuários? Para isso, nós utilizamos o Communication Compliance, solução parte do Microsoft Purview!

O que é o Purview?

![](https://learn.microsoft.com/pt-br/purview/media/purview-solution-areas.png align=“center”)

Parte do Microsoft 365, o Purview é a solução que centraliza todas as atividades relacionadas a compliance, risco e governança de dados. Com essa solução nós podemos implementar políticas e controles contra vazamento de dados, classificação de informações, restrições no compartilhamento de arquivos e muitos outros recursos. Tudo sempre atrelado aos dados!

Como agentes de segurança, o Purview é um grande aliado dos nossos times pois permite que tenhamos uma visão centralizada e unificada de como os usuários das nossas sosluções estão compartilhando informações utilizando as ferramentas corporativas. Em mercados altamente regulados e com alta taxa de informações sensíveis (como o financeiro, saúde e governamental), é importante conseguirmos identificar o uso e compartilhamento de informações confidenciais com o intuito de reduzir possíveis danos (financeiros e de imagem) à nossa organização.

Somado às capacidades do Office 365, o Purview também se integra com as Subscriptions do seu tenant do Azure e com os workspaces do Microsoft Fabric (como mostra a imagem acima) para construir um catálogo dos dados contidos nesses espaços e permitir a visualização dos ambientes conectados.

Entendendo o communication compliance

![](https://learn.microsoft.com/pt-br/purview/media/communication-compliance-workflow.png align=“center”)

Pensando no compartilhamento de informações, o Purview nos disponibiliza uma solução preparada para executar as tarefas de identificação de dados sensíveis e compartilhamento de informações confidenciais entre usuários. Essa solução é o Communication Compliance!

O Communication Compliance funciona a base de políticas que tem o intuito de identificar informações compartilhadas em diversas ferramentas, entre públicos diversos e com padrões cadastrados, para que a busca seja assertiva em seu retorno.

Podemos implementar políticas já existentes tal como criar nossas políticas personalizadas, visando identificar informações específicas no contexto da nossa organização.

Durante a configuração de uma política (seja ela pronta ou customizada), conseguimos direcionar o monitoramento para grupos específicos de usuários (recomendado para testes) ou para todos os usuários do tenant (configuração produtiva), escolher revisores dos alertas gerados, selecionar em quais soluções do Office 365 essa política será aplicada e por fim a condição de detecção, onde definimos o que a nossa política identificará.

Nessa última sessão, nós podemos escolher entre uma série de categorias pré-existentes, que utilizarão os modelos de identificação treinados pela Microsoft para realizar o monitoramento e o match das condições configuradas.

Com as políticas configuradas e ativadas, o monitoramento do ambiente será iniciado e caso haja um match com as condições definidas, um alerta será criado e poderá ser revisado e solucionado pelos usuários indicados no momento de configuração da política.

Políticas anti-vazamento de dados

Para podermos extrair o máximo do Communication Compliance e protegermos nossa organização da melhor maneira possível, podemos utilizar algumas das políticas “prontas” para iniciarmos o controle contra o compartilhamento de informações sensíveis.

A imagem acima representa a lista de políticas padrão existentes no Communication Compliance. Pensando em uma estratégia anti-vazamento de dados, nós devemos ativar as políticas de:

Detecção de dados sensíveis;
Detecção de informações regulatórias (caso sua empresa seja do ramo financeiro);
Detecção de conflito de interesses.

Somado à essas, temos também as políticas customizadas, que nos permitirão implementar as condições com maior flexibilidade (um bom caso de uso das políticas customizadas é quando temos uma série de palavras chave que precisamos monitorar, nesse caso nós podemos realizar o upload de um arquivo que contenha essas informações para que sejam monitoradas).

Com as políticas customizadas, podemos configurar uma série de condições que precisam ser atendidas para que o alerta seja disparado (todas as condições ou apenas algumas delas), além de termos a possibilidade de trabalharmos com análise de texto em imagens, tamanho de arquivos, domínios dos destinatários, tipos de arquivos, tamanho da mensagem, entre outras condições!

Pensando em uma estratégia corporativa para a criação e configuração das políticas, devemos configurar condições básicas de monitoramento, que visam a identificação de categorias de dados sensíveis “comuns” e também precisamos estrutar condições que estejam adequadas às operações da empresa em que trabalhamos, para que possamos identificar informações sensíveis das atividades de negócio que podem estar sendo compartilhadas de maneira non-compliant.

Monitorar os canais de comunicação da sua empresa é extremamente importante. A grande quantidade de informações confidenciais e sensíveis que lidamos no dia a dia exige que políticas robustas de monitoramento e detecção estejam implementadas para evitar danos à imagem e ao resultado da empresa.

Espero que tenha gostado e que eu tenha conseguido te mostrar as posssibilidades desse recurso e como podemos fortalecer nossa estratégia de segurança com ele.

Até mais!

Como é fazer uma prova de certificação em casa?

Mon, 07 Aug 2023 03:00:00 GMT

Todo o processo envolvendo certificações pode gerar estresse no candidato. Você precisa agendar a prova, se capacitar e se manter calmo no momento de realização do exame (que é a parte mais complicada). Para diminuir um pouco a tensão, você tem a opção de realizar a prova em um ambiente conhecido e confortável, mas nem tudo é o que parece.

As certificações cumprem um papel importantíssimo na indústria de tecnologia. Elas são utilizadas para validar os conhecimentos e experiências dos aplicantes e são uma forma muito efetiva para empresas com vagas de emprego abertas que querem captar certos perfis de candidatos. E o primeiro passo para conquistar sua certificação e ficar em evidência no mercado é agendar a prova.

Agendando a certificação

O primeiro passo para realizar o exame de certificação é agendá-lo. Se pegarmos as certificações das empresas de tecnologia mais relevantes no mercado (como Microsoft e Amazon), elas utilizarão empresas terceiras (mediadoras) para realizar a aplicação do exame.

Primeiro passo: selecionando uma empresa certificadora

À primeira vista as empresas certificadoras parecem não ter nenhuma diferença entre elas. Não existe uma lista que fale das diferentes empresas certificadoras e dos seus diferentes recursos disponíveis (até agora). Nesse texto vou comentar sobre as duas empresas mais populares no mercado (PearsonVUE e PSI) e te fornecer insumos para você decidir qual ferramenta escolher.

Ao entrar na página oficial da certificação, você será apresentado com as empresas aplicadoras disponíveis, como mostra a imagem abaixo:

Neste caso, a Microsoft dispõe apenas de uma empresa certificadora, porém pode ser que a certificação de sua escolha tenha mais de uma opção disponível.

Dentro do site das empresas, pode ser que você seja apresentado com duas (ou mais) opções para aplicação do seu teste. Isso vai depender da empresa escolhida: você pode fazer o teste online ou em um centro de testes. A imagem abaixo mostra isso:

Caso selecione a opção do centro de testes, você deverá selecionar uma localização oficial disponível próxima de você. O teste feito de maneira presencial é aplicado em um ambiente controlado pela empresa certificadora, então você não precisará seguir todos os “protocolos” mencionados mais pra frente quando falarmos sobre as provas online.

Uma outra vantagem é o idioma falado pelos instrutores. Nos testes online você precisa escolher entre a lista de idiomas disponíveis, já no centro de testes não.

Segundo passo: escolher uma data e horário

Após selecionar a forma de aplicação da prova, chegou a hora de decidir uma data e um horário.

Você pode escolher de que forma os horários são apresentados para você e pode selecionar também o fuso horário no qual você se encontra.

Não se preocupe! Caso precise ou queria trocar de dia e horário, posteriormente você poderá, contanto que seja dentro do tempo determinado pela empresa. Por isso, fique atento às informações apresentadas à você durante o agendamento da prova. Algumas empresas permitem que você troque a data do teste até 24 horas antes, porém algumas exigem que seja feito em até 48 horas precedentes.

Terceiro (e último) passo: confirmar o teste

Após escolher como fará a prova, a data e o horário, você poderá confirmar seu registro.

Esse último passo normalmente envolve aceitar uma série de condições e termos da empresa certificadora, então leia com bastante cuidado qualquer campo que requeira seu consentimento.

Também faz parte da última etapa o pagamento. Se você estiver utilizando um voucher de desconto, você poderá inseri-lo no final do processo, antes de proceder para o checkout da compra.

Ao finalizar o agendamento de seu exame, você receberá em seu e-mail cadastrado, informações de confirmação da compra. São informações sobre o exame, data e hora, entre outros avisos.

Requisitos básicos

Os requisitos para se fazer uma prova online não são todos técnicos. Você precisará basicamente de um computador com câmera, microfone e auto falantes e talvez de um celular para realizar uma das etapas de verificação.

Fora os requisitos de dispositivos que foram mencionados a cima, você também deve ter em mãos um documento oficial com foto. Esse é a única coisa além dos requisitos da sua máquina que você PRECISA TER em mãos para fazer o teste. Não será possível iniciar o teste sem um documento.

Os outros requisitos dizem respeito ao ambiente onde você realizará o teste. Aqui estão eles:

Você deve estar em uma mesa que não tenha nada além do computador e do documento sobre ela;
Não é permitido que você tenha televisores externos próximos ao local do exame;
Não é permitido o uso de fones de ouvido;
O ambiente onde está realizando o teste deve ser isento de sons externos;
No momento de início da prova, seu aparelho de celular deve estar fora do alcance das mãos;
Você deve encerrar todas as aplicações que estão abertas em seu computador, deixando apenas o essencial para a realização do teste;
Você deve manter sua câmera sempre aberta, estando sempre ao centro da imagem;
Você não pode em momento algum gesticular, ler em voz alta ou tampar a visão da sua boca.

Esses dois últimos requisitos podem ter gerado certa surpresa. Se você está fazendo pela primeira vez uma prova online, saiba que o motivo de você precisar ter a câmera aberta e manter sua boca e rosto desobstruídos, é porque durante todo o exame, você terá um instrutor da empresa o monitorando, garantindo que você não tente fraudar a prova.

O não cumprimento de algum desses requisitos gera motivos para cancelar sua prova, então respeite-os e fique atento com possíveis problemas.

Fazendo a prova online

Após ter agendado seu exame e estar certo de que está cumprindo todos os requisitos acima mencionados, chegou a hora de falarmos sobre a experiência de fazer o teste online.

Como comentei anteriormente, existem diferentes empresas certificadoras e cada uma delas tem sua peculiaridade. Em minha experiência com certificações, utilizei duas das plataformas mais comuns: PearsonVUE e PSI.

PearsonVUE

Ao escolher a PearsonVUE você precisará baixar em seu computador uma aplicação chamada OnVUE. Essa aplicação será utilizada por você para fazer o teste. Quando chegar o momento de fazer a prova, você executará essa aplicação e fará toda a jornada necessária indicada nele. Logo após finalizar o agendamento, será sugerido que você realize um teste para confirmar se o seu computador é compatível com os requisitos da empresa para a realização da prova. Nesse momento, caso não tenha o aplicativo instalado, você será levado à tela de download.

Após finalizar o download da aplicação, você pode executá-la e realizar o teste, que consiste de:

Teste de microfone;
Teste de câmera;
Teste de alto-falantes.

Próximo do inicio da prova, você poderá entrar na aplicação e iniciar os preparativos 30 minutos antes do horário de agendamento (são realmente os 30 minutos que precedem o início do seu teste).

Note na imagem acima o foco nos dois links “Test your system” e “Check in to start exam”. Ambos os links executarão automaticamente o OnVUE em seu computador, o primeiro permitirá executar os testes mencionados anteriormente e o segundo deve ser utilizado no momento de iniciar a prova.

A etapa anterior ao início do exame é a de verificação do ambiente. Você verificará uma parte dos pontos tratados no capítulo anterior (requisitos básicos).

Será mostrado na sua tela um QR code para você acessar o site da PearsonVUE pelo seu celular e seguir com as verificações. Dentro do site será solicitado que você tire uma foto do seu rosto, foto de frente e verso do documento oficial com foto e por fim tire foto dos 4 lados do quarto onde fará o teste.

Após concluído o processo no site, será sinalizado que você pode retornar para o computador e aguardar o último passo.

Você será colocado em uma fila antes de começar a prova. Talvez um agente da empresa entre em contato com você pelo chat, disponível na plataforma. Não é sempre que isso vai ocorrer, mas fique atento ao chat.

Após esse processo, você estará apto para iniciar seu exame!

PSI

O que diferencia a PSI da PearsonVue é o ambiente onde o teste vai ser executado e a forma de verificação.

Diferente do OnVUE que é uma aplicação para desktop, a PSI opta pela utilização de um secure browser. O secure browser funciona nos modelos do OnVUE, fazendo toda a segurança antifraude para o exame.

A maior diferença que notei entre as duas empresas é a forma de verificação. Enquanto a PearsonVUE adota uma estratégia mais simples e cômoda para o usuário, fazendo tudo através de um smartphone, a PSI exige que todas as verificações sejam feitas através da câmera do computador.

Ao iniciar o processo, você fará as seguintes verificações (algumas se repetem em relação ao processo da PearsonVUE, se atente as diferenças):

Mostrará para a câmera seu documento oficial com foto, frente e verso;
Colocará o documento ao lado de seu rosto e mostrará para a câmera;
Será necessário mostrar seu rosto, suas orelhas (para garantir que não está utilizando fones de ouvido) e seus pulsos (garantindo a não utilização de relógios e pulseiras inteligentes);
Por fim, a parte mais trabalhosa, você precisará mostrar através da câmera o ambiente em que está fazendo os testes. Mostrará as paredes, o teto e o chão, a mesa onde está realizando a prova e até embaixo dela (garantindo que não há nenhum tipo de “cola”).

É um processo muito mais trabalhoso e demorado como você pode perceber, mas uma vez encerrado, você poderá iniciar seu exame.

/divider

Durante a prova

As duas plataformas que comentei são diferentes, mas contém recursos em comum.

Você terá disponível:

A capacidade de marcar uma questão para ser revisada posteriormente;
Botões interativos para passar para avançar para as próximas questões;
Chat disponível para contatar o instrutor que está acompanhando seu exame. Esse chat pode ser utilizado para solicitar ajuda para solução de algum problema que você está enfrentando durante a prova e nunca para questões relacionadas ao conteúdo do exame.

Esses recursos estarão disponíveis para uso em qualquer momento durante o seu exame!

Quero reforçar uma coisa

Mantenha SEMPRE seu rosto visível e sua boca desobstruída. É obrigatório que o instrutor consiga confirmar que você não está interagindo com outra pessoa no momento do exame.

Cada modelo e cada ferramenta tem suas características. Analise-as bem antes de decidir em qual você fará sua prova.

Se atente aos requisitos e faça uma prova tranquila.

Muito obrigado! E boa sorte!

Graph API

Tue, 20 Feb 2024 03:00:00 GMT

Já se deparou com a necessidade de desenvolver uma aplicação que precisaria recolher informações do perfil do usuário, talvez da sua lista de contatos, das aplicações que tem acesso ou até mesmo das tarefas que o mesmo tem para executar? Hoje nós temos isso de maneira extremamente fácil com a Microsoft Graph API!

O que é?

![Visão geral do Microsoft Graph - Microsoft Graph | Microsoft Learn](https://learn.microsoft.com/pt-br/graph/images/microsoft-graph-dataconnect-connectors-enhance.png align=“left”)

Você já parou para pensar que todas as soluções que são parte do Microsoft 365 e do Entra são acessíveis de alguma forma? Quando estamos utilizando os portais administrativos e as aplicações para mobile, web e desktop, podemos não parar para pensar nisso, porém “por trás dos panos” essas funcionalidades são expostas de alguma forma que as aplicações consigam consumi-las.

Essas funcionalidades são expostas para as aplicações através de APIs e o conjunto de APIs do Microsoft 365 é chamado de Graph. Com essas APIs, nós podemos consumir informações como as mencionadas na introdução do texto e construir aplicações que potencializarão as equipes a produzirem mais e de maneira mais efetiva.

Não apenas podemos conectar nas soluções do Microsoft 365 e do Entra, mas como parte da prateleira de recursos, podemos integrar nossas aplicações com o Dynamics 365 e também com certos recursos do Windows.

O que podemos fazer?

![What’s new for Microsoft Graph Developers at Build 2017 - Microsoft 365 Developer Blog](https://devblogs.microsoft.com/microsoft365dev/wp-content/uploads/sites/73/2018/05/Microsoft20Graph20Image.png align=“center”)

Como comentado no capítulo anterior, a Graph API nos permite consumir uma gigantesca variedade de informações provindas das soluções do Microsoft 365 e Entra, mas pensando de maneira mais prática, o que exatamente podemos fazer com elas?

TUDO!

Quando falamos de criatividade, o céu é o limite. Nós podemos ter uma aplicação que consuma informações sobre os funcionários de uma determinada equipe, liste algumas informações de contato (como e-mail e telefone), forneça ao gestor da equipe uma visão temporal do que seus funcionários tem realizado de atividades e permita que as pessoas entrem em contato com os recursos via teams ou via outlook.

Podemos seguir na linha também de uma aplicação de segurança, como por exemplo um “monitorador” de acessos privilegiados. Podemos criar uma solução que monitore a ativação de roles privilegiadas no Microsoft Entra ID e que notifique um grupo de administradores quando essas roles forem ativadas.

O exemplo acima pode ser utilizado como uma solução auxiliar no monitoramento de contas break the glass.

As possibilidades do que podemos fazer com as APIs expostas pelo Graph são infinitas. Com os recursos expostos, os produtos que compõem as APIs e as diferentes tecnologias que podemos utilizar, fica complicado pensar em algo que não pode ser construído.

Testando…

Para entendermos melhor algumas das capacidades expostas pela Graph API, temos uma plataforma que nos permite testar alguns dos endpoints mais conhecidos com as informações da nossa própria conta.

O Graph Explorer fornece uma série de chamadas de API prontas para serem realizadas, chamadas essas como “recuperar meu perfil”, “recuperar tarefas”, “criar grupo”, entre outras chamadas.

Ao acessar o site você se deparará com uma tela parecida com essa acima. É aqui que você irá executar todos os seus testes e validará as respostas da API.

Caso você não tenha uma sessão nativa no seu tenant você precisará se autenticar antes de conseguir realizar qualquer chamada para a API visando recuperar suas informações.

No menu esquerdo, você tem a divisão dos endpoints por categoria, dessa forma fica mais fácil de entender os recursos que estão sendo expostos e o que você poderá usar para criar sua applicação.

É possível que ao executar uma chamada, você receba uma mensagem de autorização insuficiente. Para solucionar isso, navegue até "Modify Permissions" e aceite as sugestões existentes.

Segurança com a Graph API

Para os times de segurança, a Graph API pode ser utilizada como origem de informações sensíveis para potencializar aplicações desenvolvidas por eles.

Aplicações de segurança

Como mencionamos anteriormente, podemos construir uma aplicação de monitoramento de ativação de roles privilegiadas do Entra. Podemos também construir fluxos utilizando o Azure Logic Apps, Power Apps e Power Automate que simplificarão as atividades dessas equipes, realizando operações automatizadas, simplificando a interação com clientes internos (equipes de negócio) e também podemos criar aplicações em cima das APIs que apliquem os controles impostos por essas equipes.

Segurança nas informações

No consumo às APIs, os usuários que ainda não forneceram as permissões necessárias precisarão concedê-las. Isso é necessário para que os serviços possam consumir as informações daquele usuário em nome da aplicação.

Para aplicações que acessarão informações dos usuários (de perfil e outros segmentos) é possível fornecer o consentimento de administrador, não havendo a necessidade de que o usuário acesse a aplicação para aprovar o acesso à esses dados.

Os recursos disponibilizados pela Graph vão habilitar suas equipes a desenvolverem aplicações e automações que facilitem o dia a dia na sua empresa. Incentivar o uso desses recursos permitirá o crescimento da cultura de colaboração e automação da sua organização!

Espero que tenha gostado do texto e que de alguma forma eu tenha conseguido te passar os benefícios de utilizar esse recurso no dia a dia da sua organização e dos seus times.

Até logo!

Gateway API: o passo além do k8s Ingress

Tue, 03 Dec 2024 03:00:00 GMT

Pensando na evolução da arquitetura do seu cluster Kubernetes, o Gateway API é um daqueles recursos que você não deve deixar de considerar. Sendo uma solução robusta e elegante, o Gateway API vem se tornando um novo padrão para o controle do roteamento dos serviços expostos pelo cluster. Dito isso, hoje iremos explorar brevemente o que é o recurso, suas diferenças para o tradicional Ingress e algumas de suas principais características.

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.

Vale ressaltar que a evolução do Ingress foi travada, com os esforços concentrados 100% no Gateway API.

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!

Identidades para aplicações

Tue, 23 Apr 2024 03:00:00 GMT

Um conceito vindo do on-premise e potencializado com o uso da nuvem pública, as identidades para aplicações (workload IDs) existem para que possamos aplicar permissões no consumo dos recursos e controlar o acesso aos insumos da organização. Elas nos permitem identificar o consumidor (aplicação) e funcionam como se fossem credenciais de usuários humanos. Hoje falaremos sobre essas identidades, suas características técnicas e aplicações dentro do Microsoft Entra ID.

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

![Screenshot of PEM file](https://learn.microsoft.com/en-us/cli/azure/media/sp-tutorial/pem-file.png align=“center”)

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.

Essa seção dentro do Portal do Entra é relativamente nova, então tome seu tempo para explorá-la dentro do seu tenant e avalie tudo que ela há de oferecer.

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.

Essa visão do workload IDs é oferecida no plano free. A versão premium será tratada posteriormente em outro texto.

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!

Implementando revisões de acesso no Azure e Entra ID

Wed, 23 Aug 2023 03:00:00 GMT

What are Access Reviews in Azure AD — Windows Active Directory (windows-active-directory.com)

Conforme sua empresa cresce, o acúmulo de acessos dos usuários será uma consequência. Se quiser proteger seu ambiente do acúmulo de acessos e de possíveis problemas que pode vir a ter com o comprometimento de uma identidade, esse artigo é para você!

Entendendo melhor o problema

Como foi comentado brevemente no início do texto, o crescimento de uma organização traz consigo diversos desafios para os time de segurança. Operacionalizar um ambiente em nuvem pode se tornar complicado de acordo com a quantidade de funcionários dedicados para essa tarefa.

Conforme sua empresa realiza novas contratações, novos times vão surgindo, times vão se desfazendo e se transformando em novas equipes, pessoas encerram seus vínculos com a empresa, as coisas mudam e é importante que os times de tecnologia (engenharia, operações, segurança, etc.) consigam controlar o ciclo de vida dos “objetos” vinculados à essas partes (equipes, pessoas, etc.).

O crescimento das equipes também leva ao problema mencionado na abertura do tutorial, o acúmulo de acessos. Esse problema se deve à má gestão do ciclo de vida das permissões fornecidas aos usuários e aos times (grupos). O acúmulo de acessos acrescido do comprometimento das identidades pode parecer não apresentar tanto risco, então vamos deixar claro alguns problemas que podem ser causados por esses fenômenos:

Exposição de informações sensíveis: esse é um problema causado pelo comprometimento das credenciais do usuário. Uma identidade comprometida fornece grande risco aos ambientes se não for remediada automaticamente, principalmente se essa identidade em questão tiver acesso à múltiplos ambientes. O usuário por trás do acesso ilegítimo poderá realizar o conhecimento dos ambientes e executar a extração de informações valiosas e confidenciais;
Acesso a recursos indevidos: também potencializado pelo comprometimento das credenciais mas não causado exclusivamente por isso, o acúmulo de acessos habilita que o usuário tenha acessos a recursos que não são mais necessários. Isso pode, por displicência do usuário, impactar outras equipes, que podem ter seus recursos modificados;
Descumprimento do princípio do privilégio mínimo: um dos pilares da estratégia zero trust é o princípio do privilégio mínimo, que consiste em fornecer aos usuários apenas o acesso necessário para suas atividades de trabalho. É importante que as organizações se atentem a esse princípio pois uma vez garantido e aplicado, os danos causados pelo comprometimento de uma credencial podem ser reduzidos drasticamente;
Comprometimento de recursos: mais um ponto atrelado ao comprometimento das credenciais, usuários que contém acúmulo de acessos e acabam tendo suas credenciais comprometidas, potencializam o comprometimento dos recursos aos quais tem acessos. Tendo uma gama ampla de acessos, aumenta-se o escopo de ataques aos recursos.

Esses são alguns perigos existentes quando falamos de acessos acumulados. Pudemos perceber que os danos à organização podem ser severos e possivelmente irreversíveis.

Dito isso, termos uma estratégia eficiente de revisão de acessos pode nos poupar muita dor de cabeça no futuro e trazer mais confiança para os times de segurança e operação.

Qual a solução?

O Entra ID Governance oferece um recurso chamado Revisão de Acessos (Access Reviews). Com esse recurso é possível implementar um processo de revisões de acesso periódicas para usuários, grupos e aplicações. Essa funcionalidade habilita os administradores a selecionarem os objetos de destino, os objetos aprovadores, a frequência da revisão, as ações que devem ser tomadas de acordo com a aprovação do acesso, e mais alguns operações existentes.

Dentro do portal do ID Governance, nós temos a possibilidade de gerenciar todos os acessos existentes na plataforma. O ID Governance centraliza as atividades de gerenciamento relacionadas às identidades e às permissões existentes no Entra ID.

Dentre os recursos que podem ter seus acessos revisados, temos:

Grupos e equipes — grupos de segurança e do Office 365;
Aplicações — acesso à aplicações, controlado pela atribuição de grupos para gestão do acesso;
Atribuições do PIM (Funções do Azure e do Azure AD) —usuários e grupos que tenham funções privilegiadas atribuídas.

Com essas capacidades fornecidas pelo ID Governance, as empresas poderão realizar períodos recorrente de revisão de acesso, com o objetivo de garantir a segurança constante de seu ambiente e para setores onde isso se aplica, garantir a conformidade com os orgãos reguladores (nacionais e internacionais).

Uma funcionalidade, possível com o uso das Revisões de Acesso do ID Governance e visando a gestão ágil dos acessos, é a implementação do self-review.

Self-review: podemos permitir que o próprio usuário revise seus acessos e julgue os que são realmente necessários. Esse recurso pode ser interessante quando se tem uma organização com dezenas de milhares (ou até mais) de funcionários e acessos a aplicações que não são consideradas críticas. Essas aplicações não devem apresentar risco a sua organização, possibilitando que a revisão seja feita individualmente.

OBS: é necessário que os usuários que farão as revisões de acesso tenham atribuído à suas contas uma licença mínima do Entra ID P2. Caso os seja configurado um self-review, os usuários também precisarão da licença.

Implementando a revisão de acessos

Podemos iniciar a configuração através do Portal do Azure ou do Portal do Entra. Toda a experiência fornecida através do Portal do Entra, também é apresentada pelo Portal do Azure, com todos os recursos à sua disposição.

Ao acessarmos a aba do Identity Governance em qualquer um dos portais, devemos selecionar a seção “Revisões de acesso”, representadas pelo ícone abaixo:

Logo após acessar a seção das revisões de acesso, você será apresentado com a tela que nos permite gerenciar as revisões existentes e criar novas.

Caso seja seu primeiro acesso, não haverão revisões criadas, então sua página estará igual à apresentada acima.

Para criação das revisões de acesso para as Funções do Azure e do Azure AD no PIM, devemos acessar diretamente o Portal do PIM, ou podemos acessar mais abaixo na barra de rolagem do menu à esquerda, as opções “Funções do Azure AD” e “Recursos do Azure”. Acessando qualquer uma delas, seremos levados ao Portal do PIM onde podemos configurar as revisões para funções do PIM.

Para este exemplo, vamos clicar em “Nova revisão de acesso” e partir para nossa primeira configuração, que será a configuração da revisão de acesso de um grupo do Azure AD.

OBS: caso você não tenha nenhum grupo criado, crie alguns usuários, crie um grupo e os insira no grupo apenas para fins de teste. Não é necessário ter um ambiente muito populado para conseguir construir as primeiras revisões de acesso.

Tipo de revisão

A primeira configuração nos habilita selecionar quais os destinos da nossa revisão. Aqui podemos escolher entre Usuários e Grupos ou Aplicações, visando controlar quem tem acesso à elas.

Para conseguir revisar aplicações, é necessário que previamente tenhas criado algum registro utilizando o Application Registration ou o Enterprise Application, caso contrário apenas a aplicação “Graph API” estará disponível para seleção.

Para este exemplo, selecionaremos a opção “Grupos e Equipes” e escolheremos um grupo qualquer existente no tenant.

Outra configuração disponível nesta etapa é a escolha de quais tipos de usuários que terão o acesso revisado. Podemos restringir a revisão à usuários convidados (guest users) ou a todos os integrantes do grupo.

Ao final da configuração, seu formulário estará semelhante a este. Executaremos a revisão de acesso em grupos específicos.

No final do formulário temos a opção de restringir o escopo apenas à usuários que estão inativos. Isso é uma boa prática nas empresas, além de ser uma configuração muito comum.

Revisões

A segunda etapa é a configuração de frequência das revisões e dos aprovadores. Aqui selecionaremos quais os responsáveis por fazer a revisão de acesso e com que frequência deve ser disparado a solicitação de revisão.

Para acessos de alta criticidade e de alto risco, é recomendado a criação de uma revisão em estágios (“cascata”). Com esse método, selecionamos dois revisores que obrigatoriamente deverão realizar as atividades de verificação. Visto que estamos implementando um exemplo básico e de uso geral (não crítico), a revisão ser realizada por apenas um agente supre nossa necessidade, então na seção de “Selecionar revisores” escolha a opção “Usuários ou grupos selecionados” e selecione um usuário (ou grupo) para realizarmos a revisão do acesso posteriormente.

Dentre os aprovadores podemos selecionar:

Proprietários do grupo — um cenário muito comum em organizações, é a configuração de um “dono” do grupo. Grande parte das vezes essa pessoa é o gerente ou head da área. Em uma organização que cria seus grupos baseados em equipes, faz sentido permitir que a revisão de acesso seja feita pelo responsável pelo grupo em questão;
Usuários e grupos selecionados — essa seleção pode ser escolhida para cenários mais críticos, onde devemos delegar à uma equipe de segurança a responsabilidade pela revisão dos acessos. Caso em sua organização, tenha usuários e grupos que contenham acessos altamente privilegiados, é uma recomendação deliberar a gestão do acesso para o time responsável pela segurança dos ambientes;
Self-review — caso seja um desejo permitir que os usuários tenham mais autonomia para escolher o que precisam acessar e o que não, o self-review nos fornece essa possibilidade;
Gerentes dos usuários — um dos atributos padrão de um usuário no Entra ID são as informações de seu gerente. Com essa funcionalidade, podemos delegar para o responsável direto pelo funcionário a capacidade de revisão de acesso, deixando o fluxo de gestão mais “limpo” e sem dependências com times externos.

As opções “Proprietários do grupo” e “Gerentes de usuário” permitem a configuração de um fallback de aprovação, garantindo que caso o aprovador principal não possa realizar a revisão, um aprovador secundário seja acionado e tenha as permissões de avaliador.

Para finalizar essa sessão devemos configurar o tempo de duração da revisão, a recorrência (de quanto em quanto tempo ela será disparada) e por último a data de início. As revisões costumam ser rotineiras (trimestralmente, semestralmente, etc.), apenas em casos específicos seu agendamento de revisão deverá ser encerrado, então podemos manter selecionado a opção “Nunca”, que determina o período de encerramento da revisão.

No final das configurações, o seu formulário se parecerá com o seguinte:

*A data inicial representa o dia que escrevi esse tutorial, só é possível configurar a revisão à partir do mesmo dia*

Configurações

Para finalizar a configuração vamos agora às propriedades opcionais.

Dentro dessa seção você poderá tomar uma ação caso os revisores não respondam a avaliação de acesso e enviar notificação ao encerrar uma revisão.

Vamos manter a configuração da forma que está e prosseguir com a criação da nossa revisão.

Examinar + criar

Por fim você deve criar um nome para sua revisão e caso queira, uma descrição que permita compreender os controles que ali estão sendo aplicados.

Essa é a última das etapas, após isso teremos a primeira revisão de acesso criada.

Revisando o acesso

Para iniciar a revisão dos acessos é importante saber duas coisas:

Após a criação, devemos esperar alguns minutos até que o status da revisão esteja atualizado para Ativo;
Os revisores (sejam dedicados ou self-reviewers) receberão um e-mail quando chegar a data inicial prevista para a revisão. Não será necessário que os mesmos acessem o Portal do Azure ou o do Entra. Para fins de simplicidade, a Microsoft disponibiliza um portal próprio para revisão de acessos, o My Access. Esse portal contém todas as ações de revisão que deverão ser feitas pelo usuário em questão.

O uso de um portal específico para a revisão dos acessos retira a necessidade de que todos os usuários tenham acesso aos portais administrativos.

Abaixo temos uma imagem da página principal do portal My Access:

Você deverá clicar sobre o acesso pendente e será direcionado para a página que permitirá realizar a revisão.

Clicando em “Detalhes” ao final de cada linha, temos acesso a um formulário unificado que nos permite Aprovar, Negar ou responder que não conseguimos avaliar a necessidade do acesso (opção “Não sei”). Junto da avaliação do acesso, também temos a necessidade de inserir uma justificativa (configurada na fase de “Configuração” da revisão). A avaliação de acesso pode ser alterada até a data final de duração (nesse caso, nossa revisão dura 3 dias, então você poderá alterar os resultados até 3 dias após o início da revisão).

Para executar essa tarefa mais rápido, temos a opção “Aceitar recomendações”. Essa opção responderá as avaliações com as recomendações fornecidas pela Microsoft, recomendações que podem ser visualizadas na coluna do meio da lista de usuários para revisão.

Agora você já sabe como gerenciar todo o ciclo de vida de um acesso, desde a deliberação desse acesso até a revisão do mesmo (e possivelmente o cancelamento). Esse recurso é muito útil para manter seu ambiente seguro e em conformidade com as regulamentações existentes que se apliquem à sua empresa.

Espero que tenha gostado e que agora se sinta confortável com essa funcionalidade.

Até mais!

Implementando arquitetura Zero Trust no Azure

Sun, 31 Mar 2024 03:00:00 GMT

Um dos conceitos mais importantes quando falamos de cibersegurança é o Zero Trust. Esse “padrão” estabelece controles que devem ser implementados com o objetivo de deixar seu ambiente mais seguro e protegido contra os vetores de ataque mais comuns. Hoje vamos falar sobre como podemos aplicar a estratégia zero trust no seu ambiente Azure e quais serviços utilizar para cada um dos princípios!

Entendendo o Zero Trust

O Zero Trust é um framework de cibersegurança criado para direcionar a construção de ambientes seguros independente da plataforma. Permitiu direcionar as equipes de segurança das empresas na construção de soluções mais seguras e resilientes, declarando as preocupações que devem ser levadas em conta e como devem ser tratadas.

![Diagram of elements of visibility, automation, and orchestration in Zero Trust.](https://learn.microsoft.com/en-us/security/zero-trust/media/diagram-zero-trust-security-elements.png align=“left”)

Acima temos as camadas protegidas pelo Zero Trust. Os pilares que vamos tratar na próxima seção devem ser aplicados a cada uma dessas camadas descritas acima.

Nesse texto falaremos sobre a aplicação do zero trust em nuvem pública (especificamente no Azure), porém o modelo é agnóstico à tecnologia e ambientes, permitindo sua aplicação nos espaços mais variados e com as mais diferentes soluções.

Pilares do Zero Trust

A imagem acima mostra apenas alguns tópicos que são tratados dentro dos pilares. Ao expandirmos a metodologia zero trust, veremos que muitas outras coisas devem ser consideradas.

Nosso ambiente está aderente ao zero trust uma vez que respeitamos os 3 pilares determinantes desse princípio: verify explicitly, minimum privilege e assume breach.

Verify Explicitly (verificar de maneira explícita): esse princípio guia a implementação de modo que todo e qualquer tipo de interação/consumo do seu ambiente deve ser verificado. Entraremos em detalhes mais para frente, porém serviços como o Microsoft Entra ID e o Microsoft Intune são utilizados amplamente para garantir a aplicação do princípio;
Minimum Privilege (privilégio mínimo): consiste em fornecer apenas o mínimo de acesso necessário à identidade. O modelo de RBAC (Role-Based Access Control) disponível no Azure facilita a aplicação deste princípio e permite que os administradores forneçam apenas o acesso necessário aos usuários;
Assume Breach (assuma brechas): não devemos em momento algum assumir que nosso ambiente é seguro, por esse motivo, devemos implementar segurança nas comunicações e nos dados, do começo ao final do nosso ambiente.

Os “pilares” declaram o que deve ser feito, os meios para se atingir aquele estado ficam completamente à critério dos times de segurança, arquitetura, sistemas e infraestrutura.

Por quê implementar o Zero Trust no seu ambiente?

Quando estamos criando novas soluções, é comum que os arquitetos e engenheiros se preocupem com os mais diversos pontos de segurança do projeto. Em quase todos os projetos nós temos: tráfego de dados, exposição de endpoints, interação de usuários, armazenamento de informações, entre outros pontos. Todos esses “tópicos” geram discussões em torno da segurança da solução, por exemplo: “meus dados em repouso devem estar criptografados?”, “minha aplicação pode ser exposta para todos sem autenticação?” ou até “posso liberar acesso total aos meus recursos para os usuários?”.

Como no Zero Trust nós criamos uma série de políticas para garantir que o nosso ambiente siga as melhores práticas de mercado e os padrões de compliance da nossa empresa, essas perguntas citadas no parágrafo anterior são respondidas rapidamente.

A aplicação do Zero Trust no seu ambiente fará com que o mesmo esteja preparado para possíveis falhas de segurança, que não comprometerão seus workloads pois os mesmos estarão resguardados por conta da aplicação dos princípios!

Zero Trust no Azure

Quando começamos a pensar na segurança do nosso ambiente Azure (ou qualquer outra nuvem) é importante pensarmos nas “camadas” existentes. Em cima dessas camadas é que nós aplicaremos os nossos controles e as validações de segurança necessárias para manter nosso ambiente protegido.

Vamos começar falando sobre o que devemos fazer para garantir a aplicação dos 3 pilares que comentamos anteriormente. Resolvendo cada um deles, teremos um ambiente bem estruturado e seguro, oferecendo mais tranquilidade para o desenvolvimento das soluções de negócio.

Minimum Privilege

Expandindo nosso entendimento desse princípio, o privilégio mínimo exige que o acesso fornecido aos recursos do nosso ambiente tenham o escopo estritamente necessário, nem mais, nem menos.

A correta aplicação desse princípio reduz a chance de problemas catastróficos aconteçam devido o vazamento de uma identidade super-privilegiada.

Não apenas relacionado ao comprometimento de credenciais, mas o privilégio mínimo também resguarda a organização de agentes mal intencionados e que querem causar algum prejuízo, seja financeiro ou a imagem da empresa.

Veja abaixo uma arquitetura que demonstra como o privilégio mínimo pode ser aplicado e quais serviços podem ser utilizados:

O vazamento de informações também é tratado quando aplicamos o privilégio mínimo, já que os acessos são fornecidos apenas no escopo necessário para desenvolvimento de certa atividade. Os níveis de aplicação do acesso costumam ser apenas ao recurso que o usuário em questão precisa acessar e as ações que podem ser realizadas são restritas às atividades que ele necessita realizar, não permitindo que o mesmo realize operações que não sejam as necessárias para a execução daquela tarefa.

No desenho acima nós temos ao lado esquerdo uma estrutura de ambiente Azure e do lado direito o nosso Microsoft Entra ID Tenant, responsável por controlar todo o acesso ao ambiente. Utilizando o Entra, nós conseguimos gerir nossas identidades e aplicar de maneira granular o acesso aos recursos, também representados nas setas vindas do tenant.

Acesso aos recursos é o melhor dos cenários, pois podemos controlar qual instância do recurso o usuário estará acessando e o que estará fazendo. Acesso ao resource group não é tão recomendado pois expõe a identidade à múltiplos recursos, as vezes sem a necessidade de acesso. Acesso a subscription é definitivamente o pior dos cenários e o mais desencorajado, pois habilita uma identidade comprometida a acessar tudo que está sendo executado ali.

Quando estivermos falando de privilégio mínimo devemos nos concentrar no escopo do acesso e nas permissões fornecidas, garantindo que o usuário poderá ver e executar apenas o necessário.

O Microsoft Intune (solução de MDM - Mobile Device Management) permite avaliarmos os dispositivos que estão acessando nossas soluções, garantindo que estão em compliance com as regras da empresa e que tem todas as garantias de segurança aplicadas.

Abaixo do desenho também temos o Microsoft Defender for Identity, que nos permite ter visibilidade do nosso ambiente de identidade e fornece insights em identidades “superpoderosas”, isso é, identidades com acesso a nível de administrador (que apresentam alto risco ao ambiente).

Verify Explicitly

Nesse princípio enxergamos a necessidade de garantir a avaliação da interação a qualquer momento. Nenhuma requisição é feita sem ser devidamente autenticada e autorizada.

A devida aplicação desse princípio garante a integridade de todas as requisições e interações realizadas no nosso ambiente, dando certeza de que o ator realizando as operações é confiável e reconhecido e não houve nenhum tipo de comprometimento de informações e credenciais.

Abaixo temos uma representação dos serviços que podem ser utilizados para aplicação desse princípio:

Assim como no princípio do privilégio mínimo, o componente central da adoção desse princípio são as identidades, representadas pelo Microsoft Entra ID. TODA interação dentro do nosso ambiente Azure deve ser devidamente autenticada e autorizada, levando em consideração as diferente informações capturadas pelo Entra.

Para componentes de plataforma, a autenticação e autorização será feita utilizando as capacidades das Managed identities, gerenciadas pelo Entra e que garantem a autenticidade do requisitor sem a necessidade de se passar credenciais de acesso.

Nossas aplicações serão representadas pelas Service Principals (ou Workload IDs), também governadas pelo Entra, mas que trafegam informações da identidade para autorizar a chamada aos recursos.

O Intune assim como no princípio anterior fornece uma camaada adicional de análise para permitir que as políticas implementadas no Entra consigam com mais assertividade avaliar o acesso e a tomada de decisão da requisição.

Do lado do Azure temos alguns componentes de rede que podem ser utilizados para proteção do nosso perímetro. Firewalls, WAF e NSGs são exemplos de recursos que nos permitem proteger nossos workloads e garantir a eficácia contra ataques cibernéticos.

Assume Breach

Falamos muito sobre identidade nos outros dois princípios, agora chegou a vez dos dados e da rede.

Para a implementação desse princípio é essencial termos nosso perímetro de rede bem configurado para evitar acessos indesejados e também criptografia de ponta a ponta em relação aos nosso dados.

Na camada de rede, utilizaremos recursos para garantir que o tráfego será roteado para o destino correto, manteremos abertas apenas as portas necessárias para o funcionamento das soluções e aplicaremos todos os gates de segurança de redes, independente da origem da chamada.

Com nossos dados o importante será mantê-los seguros. Para isso devemos aplicar criptografia nas informações trafegadas e armazenadas (at-rest). Os dados, independentemente de onde estiverem armazenados, deverão estar protegidos contra vazamentos acidentais, garantindo a confidencialidade das informações.

Na junção da camada de dados e de redes temos o “canal” de comunicação, que deverá implementar criptografia in-transit, garantindo assim que nenhum agente mal-intencionado tenha acesso às informações ali trafegadas. Essa necessidade pode ser cumprida com a apliação de mTLS, que não há um serviço próprio para sua configuração, mas fazemos uso do Azure Key Vault, que nos permite armazenar nossos certificados privados, necessários para estabelecimento da comunicação segura.

Uma etapa importante para cumprimento desse princípio é o monitoramento. É essencial que nosso ambiente esteja “visível” para os times de segurança, podendo tomar decisões apoiadas por informações verdadeiras sobre o estado da infraestrutura.

Para captarmos insights mais apurados e precisos, podemos fazer uso do Microsoft Defender for Cloud e suas diferentes capacidades. Infrastructure, Data, Applications e Identity são algumas das áreas que o Defender pode nos ajudar aumentar a cobertura do ambiente.

A criptografia em repouso (at rest) não foi abordada no desenho pois é muito particular de cada recurso. Cada base de dados no Azure tem um recurso próprio de criptografia, devendo ser configurado em cada instância do recurso.

Evolução do seu ambiente

Nada na tecnologia dura pra sempre e é claro que a nossa estratégia de Zero Trust também sofre desse “problema”.

Os times de segurança deverão aprender com os problemas captados no ambiente e atualizar toda sua postura e estratégia de políticas. As políticas de acesso condicional e as Azure Policies deverão ser “vivas” e sempre mantidas atualizadas com as principais recomendações de mercado e lições aprendidas com os incidentes gerados.

Zero Trust é um assunto denso mas extremamente importante. É essencial para a boa operação das empresas e desenvolvimento dos produtos que os ambientes estejam protegidos fim a fim, trazendo confiança para os times de desenvolvimento e stakeholders da organização.

Espero que tenha gostado do texto, estou à disposição para responder quaisquer dúvidas que tiver.

Até logo!

Otimizando custos no Azure Blob Storage

Mon, 04 Sep 2023 03:00:00 GMT

Sempre ouvimos falar sobre como funcionam os object storages e sua capacidade de armazenar os documentos em diferentes “temperaturas”, visando otimizar custos e evitar gastos desnecessários, mas são poucas documentações que mostram como configurar essa funcionalidade. É isso que faremos hoje!

O cronograma do tutorial de hoje será o seguinte:

Criar uma storage account;
Criar um container na storage account;
Realizar upload de um blob;
Criar a lifecycle management rule.

Como o propósito do artigo é ensinar a criação da lifecycle management rule, para as outras tarefas vamos utilizar comandos do Azure CLI.

Introdução

Quando estamos aprendendo sobre storage, é garantido que o material que estamos utilizando contém uma seção que fala sobre as vantagens de se utilizar um object storage, como os diferentes tipos de tiers/níveis/temperaturas funcionam e como os seus custos podem ser otimizados caso sua empresa tenha uma política de arquivamento de dados definida.

Os materiais também comentam que as plataformas em nuvem fornecem os meios para você realizar essas operações nos seus objetos. Esses meios costumam ser templates json, gerados através de formulários (ou digitados em um editor de texto) e que indicam onde as operações devem ocorrer e quais operações devem ser realizadas.

Com o objetivo de te ensinar a otimizar seus custos de armazenamento em cloud de uma maneira simples e automatizada, vamos aprender como deletar os objetos após certo tempo que foram criados, e o mesmo método pode ser utilizado para alterar o tier dos arquivos!

Pré-requisitos

Uma subscription ativa do Azure;
Privilégios para criar e operar os recursos na plataforma (caso esteja utilizando sua conta pessoal, não se preocupe com isso);
Acesso à linha de comando (podendo ser o Cloud Shell que já contém os pacotes do Azure CLI ou um terminal da sua máquina local com os pacotes instalados);
Acesso ao Portal do Azure para criação da Lifecycle Management Rule;
Um resource group (na próxima sessão, antes de realizar a criação da storage account e do container, fornecerei um comando para você criar o resource group).

Criando a Storage Account e um Container

Como mencionado no cronograma, o primeiro passo é a criação dos recursos que serão necessários para prosseguimento do tutorial.

(opcional) Criando um resource group

Caso tenha um resource group disponível desconsidere esse comando.

az group create --location <REGIÃO> --name <NOME-ÚNICO>

REGIÃO (obrigatório) — qual região o recurso deverá ser criado.

NOME-ÚNICO (obrigatório) — o nome do resource group deverá ser único dentro da sua subscription.

Criando a storage account

Para realizar a criação da storage account, você deverá executar o seguinte comando:

az storage account create --name --resource-group

NOME (obrigatório) — o nome da storage account deverá ser único globalmente.

RESOURCE-GROUP (obrigatório) — nome do resource group onde a storage account deverá ser criada. Se você criou o rg utilizando o script passado anteriormente, apenas copie o nome escolhido.

É importante comentar que o comando acima não específica qual tipo de storage account será criada. Quando o atributo que indica o tipo da conta é omitido, a conta criada será do tipo StorageV2 (General Purpose V2).

Criando o container

Para a criação do container, utilizaremos o seguinte comando:

az storage container create --name --account-name

NOME (obrigatório) — o nome do container deverá ser único dentro da storage account.

STORAGE ACCOUNT (obrigatório) — nome da storage account onde estaremos criando o container.

Realizando upload do blob

Agora que temos todos as estruturas necessárias criadas, o próximo passo será realizar o upload de um ou mais blobs para o nosso container.

Caso você esteja utilizando o Cloud Shell para executar seus scripts, o método mais simples para realizar o upload de um arquivo é através do próprio Portal do Azure. Navegue até a storage account, selecione o container, clique em “Upload” e selecione alguns arquivos existentes na sua máquina. Não se preocupe com o tipo dos arquivos, imagens, pdfs, vídeos, slides, todos são tipos válidos.

Agora, caso você esteja executando os scripts de maneira local no seu terminal, para realizar o upload de um arquivo, execute o comando a seguir:

az storage blob upload --account-name --container-name --name --file

STORAGE ACCOUNT (obrigatório) — nome da storage account que criamos.

CONTAINER (obrigatório) — nome do container.

NOME-ARQUIVO (obrigatório) — nome que será utilizado no momento de upload do arquivo. Independente do nome original do arquivo, esse valor será utilizado quando o upload for realizado.

ARQUIVO (obrigatório) — path até o arquivo desejado.

Criando a Lifecycle Management Rule

Agora que você tem todos os recursos que são necessários para a realização do tutorial, chegou a hora de criarmos a configuração que realizará a troca do tier dos objetos.

As Lifecycle Management Rules são puramente templates json que nos permitem criar regras que modificarão os blobs automaticamente. Podemos criar uma regra para alterar o tier do blob ou até para excluí-lo!

Para essa atividade, recomendo fortemente a utilização do Portal do Azure, pois as interações para criação da regra serão mais simples e intuitivas.

Criando a rule através do Portal do Azure

Ao acessar a dashboard da sua storage account, navegue pelo menu à esquerda até a opção “Gerenciamento de Ciclo de Vida”. Nesse menu, selecione a opção “Add rule” e vamos iniciar a criação da nossa política.

Para esse tutorial, vamos realizar a exclusão dos blobs do container após 1 dia criado. Esse cenário não é comum, mas para conseguirmos notar os resultados mais rápido, vamos implementar a política dessa forma.

Os cenários mais comuns que você encontrará, serão as mudanças de tier de acordo com a data de criação do blob com o objetivo de otimizar os custos e atender demandas regulatórias e também a deleção dos objetos quando não eles não forem mais úteis para o negócio.

A primeira parte da configuração deverá ficar dessa maneira. Vamos aplicar a regra para todos os blobs dentro da storage account e limitaremos a aplicação da regra apenas aos block blobs, que são objetos “simples”, que não sofrerão operações complexas.

A opção “Limitar blobs com filtros” permite que você crie queries para selecionar apenas alguns blobs na storage account. Ex: você quer aplicar a política para todos os arquivos em que o nome comece com a letra T.

O próximo passo é realizar a configuração da operação. No formulário, configuraremos que os blobs que foram criados a mais de 1 dia deverão ser excluídos.

Pronto, agora é só confirmar a aplicação da sua regra clicando em “Adicionar”.

Após a criação da política, pode ser que a primeira execução demore de 24 a 48 horas. Então por via das dúvidas, acesse sua storage account 2 dias após a configuração da política.

Resultado

2 dias se passaram e nós voltamos para visualizar os resultados da aplicação da nossa política.

Visualizando o resultado…

No portal do Azure

Acessando o Portal do Azure, navegue até a storage account criada nos passos anteriores, acesse o container e voilá!

Sua política foi executada com sucesso e todos os blobs em seu container foram excluídos!

No Cloud Shell

az storage blob list --account-name --container-name

STORAGE-ACCOUNT (obrigatório) — nome da storage account que criamos.

CONTAINER (obrigatório) — nome do container.

Caso a execução do comando retorne um array vazio, temos a certeza que todos os objetos da storage account foram excluídos, resultado a aplicação da política criada.

Chegando ao final do tutorial, você aprendeu como otimizar os custos da sua storage account de maneira simples e eficiente.

As lifecycle management rules oferecem grande benefício para seu ambiente cloud, além de serem simples de configurar.

Espero que tenha gostado do texto.

Até logo!

Passkeys: o presente do MFA

Tue, 07 May 2024 03:00:00 GMT

Deixando de ser apenas uma tendência, o uso do passwordless passou a ser expandido nas organizações e empresas ao redor do mundo. Sua chegada trouxe como benefícios não apenas a segurança do ambiente, mas também a melhora na experiência do usuário, que não precisa recordar senhas complexas. Apresentando uma outra opção para uma autenticação passwordless temos as Passkeys!

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.

Em dispositivos windows que contenham as capacidades do windows hello for business, podemos fazer uso da biometria facial para desbloqueio da máquina, bem como para autenticação na aplicação.

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:

![](https://web.dev/static/articles/passkey-registration/image/passkey-registration-diagram_856.png align=“center”)

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.

Se a sua organização fizer uso do Microsoft Entra ID, é possível configurar o uso das passkeys junto do aplicativo Microsoft Authenticator para permitir a autenticação nas aplicações que estão conectadas ao Entra.

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!

Private Endpoints

Tue, 19 Mar 2024 03:00:00 GMT

Fazendo referência ao modelo de defesa em profundidade (defense in-depth), uma das camadas que devemos considerar quando estivermos montando nossa arquitetura é a camada de rede (networking). É nessa camada que todos os nossos dados passarão, então é essencial que no momento de projeção da solução, sua segurança seja levada em conta e tratada com cautela. Hoje vamos falar sobre os Private Endpoints, solução do Azure que nos permite manter a comunicação com os recursos da plataforma segura.

O que são?

Manter as comunicações entre recursos privadas é um desejo de quase todas as empresas em praticamente todos os cenários, porém isso nem sempre é possível devido a uma série de fatores - o recurso utilizado não suporta comunicação 100% privada, o custo de utilização e implementação é muito alto e não irá gerar ganhos substanciais ao projeto.

Nos casos onde as necessidades de negócio permitem e justificam esse modelo de comunicação, podemos sugerir o uso dos private endpoints (quando técnicamente possível/viável).

Um Private Endpoint é um tipo de recurso do Azure que permite que suas soluções se comuniquem com recursos da plataforma de maneira segura e privada, não passando pela internet.

São usados em larga escala em ambientes empresariais, que precisam manter suas comunicações privadas por motivos de segurança, performance e até mesmo de compliance.

Os private endpoints estão disponíveis de maneira nativa apenas para soluções PaaS (Platform as a Service) disponíveis no Azure.

É importante compreendermos essas “limitações”, pois no momento de montagem da sua arquitetura, em que estivermos estudando os recursos que deverão ser utilizados, nos depararemos com cenários como esses.

Como funcionam?

Como mencionado anteriormente, os private endpoints funcionam na camada de networking do nosso ambiente Azure, devendo ser implementados dentro das nossas estruturas de VNet (Virtual Network - Rede Virtual).

Por trás dos panos, esse recurso funciona sob o Azure Private Link, serviço que permite estabeler uma comunicação segura com qualquer recurso da plataforma. A diferença é que com os private endpoints a configuração dos recursos já vem pronta, não havendo a necessidade de se entrar em tantos detalhes como é feito com o private link.

Ao criar um private endpoint o que está sendo criado é um IP privado para aquele recurso dentro da sua subnet. Como sabemos, os recursos PaaS não requerem a seleção de uma VNet para serem criados, portanto a criação de um private endpoint para aquele recurso em questão, faz com que ele seja representado dentro da sua própria VPC, podendo então ser referenciado internamente.

Quando uma solução é configurada para utilizar os private endpoints todos os acessos a esses recursos serão roteados através do backbone global da Microsoft, não passando em momento algum pela internet. Isso garante à solução velocidade, segurança e privacidade, alcançando os objetivos anteriormente listados.

Após o estabelecimento de um IP privado para o seu recurso PaaS, um passo importante é termos a configuração da zona de DNS privado para o seu recurso, criando um endpoint legível, compreensível e que faça muito mais sentido do que se especificar um IP dentro da sua aplicação.

Arquitetura

Pensando na simples implementação de um Azure Key Vault com private endpoints, teremos uma arquitetura parecida com a representada abaixo:

Nossos workloads (aplicações) estão sendo executadas na VNet representada, que também contém uma subnet dedicada para os private endpoints. A aplicação executada consome o key vault pelo seu endpoint privado, ou seja, o endpoint configurado utilizando a zona privada de DNS, que faz uma referência ao IP privado do recurso (representado pelo NIC - Network Interface Card).

Com essa arquitetura montada, tods os workloads que estiverem sendo executado na VNet em questão e nas VNets conectadas poderão consumir o key vault através do seu private endpoint.

Quando usar?

Pergunta frequente no dia a dia de um arquiteto, “quando devemos utilizar esse recurso?”.

Os principais motivos foram mencionados ao longo do texto, esses sendo:

Privacidade;
Segurança;
Velocidade/Performance;
Compliance.

Manter uma comunicação entre recursos privada gera benefícios de pequena e de larga escala nas soluções. Para grandes organizações, é provavel a definição de uso dos private endpoints seja à nível corporativo, devido a redução da superfície de ataque (já que os recursos não estarão expostos à internet) gerada pela implementação desse recurso e também pela simplificação das análises dos projetos.

Como não só de segurança e performance vivem as empresas, uma outra preocupação para uso de novos recursos são os custos.

Pricing

A imagem acima (retirada da documentação oficial da Microsoft) representa o modelo de cobrança e pricing dos private endpoints.

Note que temos 3 pontos de preocupação:

Custo base - custo gerado pela solução apenas por ser implementada, nesse caso, $0.01/hora;
Inbound Data Processed - ingestão de dados através dos private endpoints, sendo cobrada de acordo com a quantidade de dados transmitida;
Outbound Data Processed - saída de dados através dos private endpoints, como o modelo anterior, cobrada de acordo com a quantidade de dados trafegados através do recurso.

Essas serão as cobranças realizadas quando seus private endpoints estiverem implementados. Não esqueça de levar esses valores em conta quando for apresentar aos stakeholders do projeto os custos referentes à solução.

Os preços irão variar de acordo com a região que estiver sendo utilizada e também com a cotação da moeda referênciada.

Por hoje é isso, espero que tenha gostado do texto e que eu tenha conseguido contribuir para o seu entendimento de como esse recurso funciona e os motivos que levam os arquitetos a recomendar seu uso.

Estou à disposição para responder quaisquer dúvidas pelo meu Linkedin ou pelo próprio blog.

Até logo!

SC-900 - Microsoft Security, Compliance and Identity Fundamentals

Tue, 27 Jun 2023 03:00:00 GMT

Em mais um episódio falando sobre certificações, vamos conversar sobre a porta de entrada para o mundo de cibersegurança na Azure.

Em um mundo onde tudo está conectado, com acesso à internet e com a velocidade que os negócios vem evoluindo, a segurança é importância no D0 (day zero = início). Não existem empresas que estão na cloud e que não tem nenhum tipo de preocupação com a segurança, confidencialidade, disponibilidade e integridade dos seus dados e serviços.

Agora que você entendeu que a segurança cibernética é realmente um assunto importante e que está “na boca do povo”, hoje falaremos da prova SC-900: Fundamentos de Segurança, Conformidade e Integridade da Microsoft. Vou te contar um pouco sobre a prova, passar dicas de materiais que você pode utilizar para se preparar e no final do texto compartilhar alguns macetes para que a sua experiência no exame seja a mais prazerosa possível.

Sobre o exame

Como todas as provas *-900, essa não é uma prova de especialidades mas sim uma prova de fundamentos, então tenha isso em mente. Não se cobre de entender todos os recursos de fim a fim e saber todas as especificações técnicas e peculiaridades de cada um deles, você está só começando no mundo de cibersegurança em nuvem, então lembre que essa prova é para que você possa dar seu primeiro passo. As provas mais técnicas e profundas serão abordadas nos próximos artigos (AZ-500 e SC-100).

As perguntas do teste não terão profundidade técnica, então não é necessário saber exatamente a fundo como o serviço funciona. O importante é que você saiba quais são os serviços e o que eles fazem, mantendo-se em um alto nível de conhecimento. Ter um conhecimento da plataforma como um todo e talvez brincar um pouco com alguns dos serviços fará com que você se sinta confortável para encarar o teste.

A prova é relativamente simples e contém próximo de 40 questões que poderão ser feitas com tranquilidade.

Dicas

Da prova

Conforme escrevo esse texto, vou deixando algumas opiniões sobre o exame, porém nessa seção vou falar um pouco sobre onde senti mais dificuldade durante a prova e durante a minha preparação.

Por já ter certa experiência trabalhando com Azure, não senti dificuldade ao aprender sobre os recursos de plataforma, pois já conhecia a grande maioria deles, porém os serviços abordados no tópico de conformidade eram novos pra mim. Coisas como Defender for 365, Microsoft Purview, Service Trust portal, entre outros serviços, tiraram um pouco da segurança que eu tinha para fazer a prova. O que me restava? Estudá-los!

Apenas um comentário: esses serviços tinham sido adicionados recentemente na estrutura do exame, então é de extrema importância que você fique de olho na documentação oficial da prova para saber quais foram as mais novas adições.

Falarei um pouco mais dos materiais utilizados no próximo módulo, mas ler sobre os recursos, vê-los funcionando através de demonstrações oficiais e vídeos no youtube fizeram com que eu ficasse muito mais confortável com eles.

Sobre a experiência é isso, não tem muito segredo por se tratar de um exame de fundamentos. Esteja calmo e confiante para o teste, isso é essencial!

De conteúdo

O principal recurso que utilizei foram os módulos do microsoft learn, que você pode encontrar clicando aqui. Os módulos são ricos em conteúdo, separados de acordo com os tópicos do exame para facilitar o estudo, você encontrará textos, imagens, vídeos e testes para validar seu aprendizado. A melhor coisa sobre esses módulos é que você tem liberdade de fazê-los no seu ritmo, anotando, conferindo, pesquisando e testando, sem a pressa de cumprir prazos ou acompanhar um instrutor.

Aproveito para deixar aqui o link do meu repositório no github, que contém o resultado de todo o meu estudo consolidado em um PDF que poderá ajudá-lo a se preparar para a prova. O PDF é um resumo de tudo que aprendi, então não recomendo utilizá-lo como recurso principal de estudo, mas sim como uma forma de consulta quando achar necessário.

Outro recurso interessante e oficial da Microsoft, são os assessments. Os assessments são conjuntos de perguntas de múltiplas respostas que servem para validar seu conhecimento sobre os conceitos abordados na prova, além de que caso você erre a resposta, poderá ver uma explicação da alternativa correta. Caso queira acessar o assessment específico da prova, clique aqui.

E para finalizar as dicas, é hora da mais valiosa, a prática.

A PRÁTICA é sua melhor amiga em todos os cenários existentes. Ela vai fazer com que você consiga fixar o conhecimento adquirido de maneira mais eficiente e te trará muito mais segurança. Mesmo não sendo um requisito para a realização do teste, se você puder praticar um pouquinho sem se preocupar em gastar muito com a plataforma eu recomendaria fortemente. Faça uso do free tier dos serviços, crie um budget para sua prática e aprenda a usar os serviços, mesmo que seja com um passo a passo encontrado pela internet. FAÇA!

A prova

Quando estiver fazendo a prova, preste bastante atenção no tempo restante. Não é necessário ficar olhando o cronômetro toda hora, mas certifique-se de que não está gastando tempo demais em uma só questão e esquecendo as outras, isso pode te prejudicar no final do teste quando ainda tiver uma série de perguntas para resolver e pouquíssimo tempo. Se está “empacado” em alguma questão, marque-a para revisão e assim que terminar as outras você poderá continuar pensando naquela questão que estava preso.

Leia com calma as questões, você tem tempo suficiente para fazer a prova e não precisa correr.

As perguntas não serão extensas, a grande maioria delas será direta ao ponto, sem caso de uso, sem ambiente para ser levado em conta, você vai ler a questão e conseguir identificar dentre as respostas possíveis, qual delas é a correta.

Alguns temas que você deve ficar de olho: Microsoft Purview e suas capacidades (compliance manager, data classification, information protection, data loss prevention, retention labels, retention policies, etc.), Service Trust Portal, Microsoft Priva, 6 princípios de privacidade da Microsoft (controle, transparência, segurança, proteção legal, benefícios para você e sem marketing direcionado), soluções de segurança de plataforma (WAF, Application Gateway, Azure Firewall, Azure Front Door, etc) e é claro, no pilar de identidade, o Microsoft Entra (Azure AD, ID Verificada e Gerenciamento de permissões).

Por fim, estude, revise e passe!

Não existe uma fórmula mágica do sucesso, o trabalho duro e a disciplina sempre serão os responsáveis pelas tuas vitórias, independente do que estiver fazendo.

Espero que tenha conseguido te ajudar a se preparar melhor, se sentir mais calmo e acima de tudo, mais confiante para a prova. Não hesite em comentar nesse artigo caso tenha alguma dúvida e se gostou deixe algumas palminhas por favor!

Boa prova ❤

SSO, é realmente uma boa ideia?

Tue, 14 Nov 2023 03:00:00 GMT

Ao discutir sobre identidade, SSO é um tema bem recorrente, pela simplicidade gerada ao usuário final e pelos seus “benefícios” de segurança. Mas será que uma implementação de SSO é sempre a melhor escolha? Ou melhor, será que realmente é seguro?

O que é o SSO?

![Imagem retirada de: https://frontegg.com/guides/single-sign-on-sso](https://frontegg.com/wp-content/webp-express/webp-images/uploads/2023/04/Inner-graphic_3-1024x528.png.webp align=“left”)

SSO ou Single Sign-On, é o termo que representa uma configuração que pode ser realizada em seu identity provider e que permite que aplicações que estão “plugadas” no IdP compartilhem a mesma sessão, não havendo a necessidade do usuário realizar múltiplas autenticações.

Essa funcionalidade gera ao usuário mais conforto ao utilizar as aplicações, uma vez que como mencionado, o mesmo não precisará utilizar suas credenciais a cada aplicação que estará acessando.

Requisitos para implementação do SSO

A peça chave e componente principal para configuração do SSO é o IdP (Identity Provider - Provedor de Identidade). É necessário que as aplicações que devem sofrer o impacto da aplicação da política estejam federadas no mesmo IdP e que permitam a configuração do SSO.

Entendido como o SSO funciona, vamos discutir e analisar os dois pontos de vista, o do usuário e o dos times de segurança.

Benefícios do SSO (para o usuário)

É comum que nas grandes organizações, a lista de soluções utilizadas pelos diversos departamentos e áreas chegue às centenas. Os times utilizam uma série de soluções com o propósito de conseguir realizar um trabalho mais efetivo e que entregue mais valor à organização e aos clientes, enquanto a lista de aplicações utilizadas só cresce conforme o tempo. Soluções novas são contratadas, soluções antigas são descontinuadas, e isso ocorre em todas as áreas, então se pensarmos nos períodos entre a contratação de uma nova solução e a desativação de uma solução antiga, a lista de aplicações que são utilizadas pelos usuários é enorme.

Saber que existem áreas que utilizam dezenas de ferramentas diariamente para a realização de atividades triviais nos permite avaliar que exigir aos usuários que iniciem um novo processo de autenticação em cada uma das ferramentas toda vez que forem acessá-las, deixará o trabalho muito mais complicado e cansativo, perdendo uma quantia de tempo valiosa, onde poderiam realizando atividades que geram valor para a organização.

Pensando nessa necessidade dos times de negócio, o SSO se apresenta como uma solução extremamente viável porquê:

Simplicidade: os usuários autenticam em uma das ferramentas e sua sessão será compartilhada com as outras soluções que estiverem plugadas ao mesmo IdP;
Segurança ao usuário: por “expor” suas credenciais apenas uma vez (no momento da autenticação), a implementação do SSO é considerada segura do ponto de vista do usuário, já que o mesmo corre menos riscos de ter sua senha visualizada e obtida de alguma forma por um agente externo.

Os benefícios acima apresentados já nos permitem ter uma ideia do valor que a implementação do SSO pode trazer para a organização. Isso sem nem ter mencionado os benefícios indiretos, como por exemplo:

Redução de chamados ao suporte: boa parcela dos chamados abertos nos suportes das empresas são sobre temas relacionados à senha. Usuários que não precisam lembrar inúmeras senhas para diferentes aplicações, não costumam precisar do suporte para reinicialização das credenciais;
Custos com equipes de T.I: optando por adotar uma estratégia moderna e que não necessita de gerenciamento, é possível que sua empresa consiga reduzir o orçamento dos times que costumam dar suporte à essas ferramentas, uma vez que o controle de acesso é tratado de maneira completamente centralizada no IdP.

Após compreender os benefícios gerados para os usuários, vamos estudar a situação dos times de segurança.

É seguro?

A implantação do SSO sempre foi tratada como uma boa prática pelos times de segurança, porém com a evolução das técnicas de ataque, é importante que nós, profissionais de cibersegurança e segurança da informação, não fiquemos “presos” ao que um dia foi senso comum entre os profissionais da área e realizemos novas avaliações de acordo com os cenários existentes.

Um motivo que de um ponto de vista pode ser considerado um benefício, do outro pode ser interpretado como um risco:

Entrada única das credenciais: o uso de apenas 1 conjunto de credenciais para acesso à múltiplos sistemas pode trazer grande perigo aos recursos de uma organização. Caso esse conjunto de credenciais esteja em posse de partes indevidas, o acesso “irrestrito” às aplicações poderá expor a organização a danos extensos se não for identificado rapidamente.

Temos uma outra questão, os tokens.

Token Theft: ataques do tipo token theft garantem ao atacante acesso aos recursos via obtenção indevida de um access token. O atacante utiliza técnicas para capturar o access token fornecido ao usuário e o utiliza para se passar pelo receptor original do token.

Outra questão que agrava possíveis problemas gerados pelo comprometimento das credenciais é o tempo de sessão configurado.

Tempo de sessão: sessões configuradas para durar grandes períodos de tempo possibilitarão ao atacante, em posse de uma credencial ou token roubado, acesso às aplicações que compartilham a mesma sessão pelo período de tempo configurado.

Pelo fato das aplicações estarem conectadas em um mesmo componente (IdP), todas as preocupações de segurança giram em torno dessa solução.

A existência de preocupações de segurança não elimina a possibilidade de utilizar a solução de maneira segura, aplicando os controles necessários e recomendados pelas equipes de segurança.

Reforçando a segurança

Procurando mitigar (ou pelo menos reduzir a possibilidade) as preocupações descritas anteriormente, algumas soluções são as seguintes:

Redução do tempo de sessão: configurar as sessões para exigir uma re-autenticação dos usuários de maneira mais frequente (mas não tão frequente, pois pode prejudicar as atividades de negócio) possibilita reduzir a efetividade dos ataques de roubo de credenciais e token theft;
Monitoramento das atividades: políticas de análise de atividade auxiliarão os times de segurança a captar atividades suspeitas em suas aplicações, como acessos em localidades atípicas, ataques de password spray, entre outras possibilidades (algumas ferramentas como o Entra ID da Microsoft permitem que seja solicitado ao usuário um “reforço” na autenticação caso alguma atividade atípica seja identificada);
Uso de MFA: a utilização de uma ferramenta de multi-factor authentication possiblita que os usuários realizem a autenticação de maneira mais segura e caso somado à uma implementação da funcionalidade passwordless, o perigo gerado pelo roubo das credenciais é minimizado, devido à eliminação de seu uso;
Token Protection (Entra ID): funcionalidade existente na solução de IAM da Microsoft, o token protection visa mitigar os danos causados por um ataque do tipo token theft. Associando o access token ao dispositivo para qual foi emitido, os atacantes não consiguirão utilizar o access token caso tomem posse do mesmo;
Seleção das aplicações: escolher corretamente as ferramentas que devem ter o SSO implementado também pode auxiliar na redução de problemas gerados por ataques bem sucedidos. Ferramentas que contém informações de negócio, confidenciais e estratégicas para a organização, devem ter os controles de segurança apresentados acima configurados de maneira mais rígida.

Vimos que é possível manter a segurança dos acessos e ao mesmo tempo fornecer conforto aos usuários das aplicações, porém é importante ter em mente a necessidade de avaliar os benefícios e os possíveis males causados por problemas de segurança não captados e solucionados.

Conclusão

SSO é SIM uma boa prática para o ecossistema de IAM (Identity and Access Management), mas isso não quer dizer que não tenha perigos.A implementação do SSO com os devidos controles de segurança pode gerar à organização diversos benefícios, tanto aos times de segurança quanto aos times de negócio!

Espero que você tenha gostado do texto e que eu tenha conseguido te fornecer visões diferentes de um tema que por muito tempo foi considerado “unânime” entre os profissionais da área.

Até logo!

Code Quality - indo além dos contêineres

Mon, 30 Jun 2025 03:00:00 GMT

Tudo que vem antes da contêinerização de uma aplicação está nas mãos do desenvolvedor e do engenheiro DevOps, que tem a tarefa de construir e manter as integrações necessárias em todo o ciclo de desenvolvimento de software.

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.

É importante deixar claro que não devemos atribuir uma base de código a apenas um desenvolvedor, mas sim a uma equipe, que ficará responsável por seus insumos ao longo do tempo. Atribuir essa responsabilidade a um time, reforça a necessidade da passagem de conhecimento bem como reduz a possibilidade da erros e da implementação de “vícios” nos códigos escritos. À longa distância, essa distribuição da responsabilidade também facilitará as interações entre os times em atividades de debugging, que costumam exigir dos responsáveis um nível de conhecimento razoável da plataforma que está sendo operada.

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?

Lembrando que esses controles estão integrados nas pipelines CICD, dado que suas paramtetrizações devem ter efeitos em toda a organização. O engenheiro terá acesso ao resultado das análises do código, porém em grande parte das vezes não poderá alterar a parametrização desta ferramenta.

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! :)

Contêineres para todos - Docker Offload!

Thu, 10 Jul 2025 03:00:00 GMT

Há poucos minutos na WeAreDevelopers Conference, o time Docker anunciou a criação do Docker Offload, uma solução que vai virar do avesso a forma com que trabalhamos com o desenvolvimento de contêineres.

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 💙

Image Scanning - protegendo suas imagens e sua organização

Wed, 18 Jun 2025 03:00:00 GMT

No primeiro cápitulo da nossa série sobre segurança de contêineres, vamos falar sobre Image Scanning, um assunto de extrema necessidade, muito considerado por empresas que levam segurança a sério mas que se apresenta com fragilidades frequentes!

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.

Se pensarmos que nosso código também pode ter (e provavelmente tem) vulnerabilidades (como falhas de segurança e credenciais mockadas), adicionamos mais uma camada de complexidade em nosso workflow, camada essa que pode ser verificada por uma ferramenta com capacidade de Image Scanning.

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.

![Your Guide to Software Supply Chain Security | JFrog](https://speedmedia.jfrog.com/08612fe1-9391-4cf3-ac1a-6dd49c36b276/media.jfrog.com/wp-content/uploads/2024/05/09165841/flow-chart_2.png align=“center”)

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.

Estamos falando sobre apetite a risco pois as categorias de vulnerabilidade encontradas necessitam que a empresa assuma certos riscos. Vulnerabilidades críticas apresentam alto risco de exploração e de prejuízo à empresa, portanto, será descartada na grande maioria dos casos.

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.

Em adição ao image scanning, nós também costumamos fazer a proteção dos pacotes e libs que são disponibilizados de forma corporativa aos engenheiros. Suas versões, fornecedores e releases são controlados pelo time de segurança, que mais uma vez deve estar ciente dos possíveis riscos e administrá-los de acordo com o apetite a risco da organização.

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.

Lembre-se que o apetite a risco é CRU CI AL quando falamos de segurança. Não existe recurso perfeito e 100% seguro, portanto se faz obrigatório um alinhamento com a liderança da empresa para compreender como a mesma está se portando.

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!! :)

Implementando a autenticação passwordless no Entra ID

Tue, 17 Oct 2023 03:00:00 GMT

Nos tempos atuais, sabemos que apenas as senhas não são mais suficientes. Sabemos também que além de não ser o meio de autenticação mais seguro, também estão entre os menos convenientes. Dito isso, hoje falaremos sobre a autenticação sem senha do Entra ID.

Introdução

A imagem acima é um quadrante que representa como as diferentes combinações de fatores de autenticação se posicionam em Conveniência x Segurança.

Quando estamos definindo um modelo de autenticação é importante termos em mente quem utilizará esse modelo a maior parte do tempo. Precisamos entender que os usuários em nossa empresa precisam se preocupar apenas em agregar valor, e não deveriam ter que se autenticar toda vez que fossem utilizar uma nova ferramenta e muito menos tendo que lembrar sua senha a cada autenticação.

O uso apenas das senhas hoje também já não é mais recomendado. As senhas estão vulneráveis à vazamentos, engenharia social, phishing, brute force, entre outros tipos de vulnerabilidades.

Para uma autenticação forte, é necessário combinar:

Algo que você sabe — como uma senha ou um PIN;
Algo que você tem — no caso, seu dispositivo;
Algo que você é — uma característica sua que possa ser verificada, como a biometria.

Habilitando a autenticação passwordless nós substituímos a senha por: algo que você tem + algo que você é ou que sabe.

A autenticação passwordless não troca segurança por conveniência e isso é importantíssimo. Os requisitos de segurança estarão sendo cumpridos e os usuários estarão extremamente mais confortáveis para acessar as soluções.

Agora que entendemos os benefícios desse modelo, vamos estudar brevemente quais os tipos de MFA suportados pelo Entra.

Tipos de MFA

Esses acima são os métodos de MFA suportados pelo Entra. Nem todos podem ser utilizados para a autenticação passwordless, porém é interessante que você conheça todas as alternativas possíveis, uma vez que possam ser úteis em algum momento.

A lista de métodos de autenticação disponíveis e configurados pode ser visualizada em “Authentication methods” na aba do ID Protection.

Os dispositivos de MFA válidos para configurarmos a autenticação passwordless são:

Windows 10 — versão que contém disponível o Windows Hello for Business;
Smartphone — com o aplicativo Microsoft Authenticator instalado;
Hardware key — FIDO2 Security Key.

Para esse tutorial, vamos utilizar o mais simples, o smartphone. Não é requerido que você instale o aplicativo neste primeiro momento, durante a jornada de login, será solicitado que você o instale e configure-o.

Configurando o Microsoft Authenticator como para autenticação passwordless, nós cumpriremos 2 dos 3 requisitos representados na seção anterior. Algo temos será representado pelo smartphone com o aplicativo instalado. Para usar o aplicativo, será solicitado que realize o desbloqueio do seu smartphone. Caso utilize o desbloqueio por PIN, será solicitado que o insira, representando algo que você sabe. Caso utilize o desbloqueio biométrico, o requisito atendido será algo que você é.

Configurando autenticação passwordless

Para esse artigo, vamos configurar o Microsoft Authenticator como a solução de autenticação passwordless. Para isso, vamos:

Desabilitar o Security Defaults do tenant;
Criar uma política de acesso condicional que solicite o MFA para autenticação em qualquer um dos portais administrativos;
Configurar no Microsoft Authenticator a possibilidade de login com o smartphone.

O security defaults é uma configuração do tenant que aplica alguns controles básicos de segurança, com o intuito de evitar falhas básicas de segurança.

Desativando o Security Defaults

Dentro do portal do Entra, navegue até a aba “Overview”, abaixo de “Identity”. Acesse o menu “Properties” e navegue até o final da página, onde você encontrará o seguinte:

Clicando sob o link “Manage security defaults”, será mostrado ao lado direito da sua tela um drop que permitirá você selecionar “Enabled” (para manter a configuração ativa) e “Disabled” (para desativar as configurações).

Atente-se ao aviso apresentado na tela. O Security Defaults é um conjunto de configurações que aborda 99,9% dos possíveis comprometimentos de contas. Desative-o apenas no caso de ter políticas de acesso condicional que aplicam esses controles.

Criando a política de acesso condicional

Navegando até a aba “Conditional Access” em “Protection”, selecione a opção “Create new policy”.

Em “Assignments” escolha alguns usuários para teste.

Em “Target resources” selecione “Cloud apps”, “Select apps” e em “Select” escolha a opção “Microsoft Admin Portals”. Essa opção contém portais como Portal do Entra e Portal do Azure.

Na sessão “Grant” marque a opção “Require multifactor authentication”.

Marque sua policy como ativa no final da página e a salve.

Se você receber um aviso que não é possível criar a política, provavelmente você se esqueceu de desabilitar o security defaults. Volte alguns passos e desative-o.

Como administrador do sistema, sua parte foi feita! A próxima etapa é responsabilidade do usuário.

Configurando o smartphone

(Caso você já tenha o Microsoft Authenticator instalado e configurado com sua conta, você pode passar para a próxima etapa)

Acesse de seu computador algum dos portais administrativos da Microsoft (Portal do Azure, Portal do Entra, etc). Insira seu e-mail e logo em seguida sua senha. Você verá a seguinte tela:

Antes de habilitar sua autenticação passwordless, é necessário que você cadastre sua conta no aplicativo.

Selecione “Avançar” e siga os passos informados em sua tela. No final do processo você terá seu aplicativo instalado e sua conta configurada.

(vamos prosseguir com a habilitação da autenticação passwordless)

No seu aplicativo Microsoft Authenticator, selecione sua conta e selecione a opção “Configurar entrada pelo telefone”, será solicitado que você se re-autentique. Após isso, apenas confirme a configuração.

Pode ser que no momento do primeiro login após a configuração no aplicativo, seja solicitado que o usuário insira a senha. Ele pode seguir desta forma ou pode selecionar a opção “Outras formas de login” e logo em seguida será solicitado sua aprovação no aplicativo.

Pronto! Seus usuários podem terão uma experiência mais prazerosa e mais segura ao usar as diversas aplicações configuradas em seu tenant.

Outras pontuações

Uma parpte importante (que não foi abordada nesse artigo) é o estabelecimento de um bom processo de governança e de apoio aos usuários.

Pode ser que durante as jornadas (configuração, cadastro, uso, etc.) os mesmos encontrem problemas e dificuldades. A existência de materiais de apoio para essas situações é essencial para não gerar atrito.

É necessário também que os funcionários do helpdesk e administradores (responsáveis pelo contato com os usuários e resolução de problemas) saibam como agir nas mais diversas situações.

Construa bem sua jornada e procure pensar em todas as partes envolvidas. Talvez você não consiga cobrir tudo, mas é importante que antes de iniciar uma mudança drástica como essa, você proure documentar os possíveis problemas e forneça meios para que os usuários saibam como resolvê-los.

Obrigado por ter lido até aqui, espero que tenha gostado do conteúdo, nos vemos em breve.

Até logo!

Protegendo acessos privilegiados com o Entra ID Privileged Identity Management

Thu, 10 Aug 2023 03:00:00 GMT

Com cada vez mais recursos sendo executados em sua conta do Azure, a importância de controlar o acesso à recursos privilegiados aumenta exponencialmente. Com o Entra ID PIM (Privileged Identity Management) podemos reforçar a segurança de acessos privilegiados em toda a plataforma.

Licença

Para usufruir das funcionalidades do PIM, é necessário que os usuários envolvidos tenham a licença P2 do Entra ID ou a licença de Governança do Entra ID.

Caso você esteja utilizando o período de testes das licenças fornecido pelo Entra ID (30 dias de licenças P2 e 90 dias de licenças E5), você poderá testar essa funcionalidade sem disponibilizar de forma explícita uma licença para os usuários. Uma vez que o período de testes se encerrar, a funcionalidade não estará mais disponível para os usuários que a estavam utilizando.

Que problema o PIM resolve?

Sabemos que uma das vantagens de se utilizar a nuvem pública é a capacidade de controlar os acessos utilizando RBAC (role based access control).

Dentre as funções (roles) existentes no Azure, temos:

Aquelas que permitem que o usuário realize qualquer tipo de operações dentro de um recurso;
Aquelas que fornecem ao usuário alto escopo de visualização.

Em ambos os casos, sua utilização pode ser um problema de segurança grave para a empresa, visto que o usuário terá acesso a informações possivelmente sensíveis e isso aumenta o nível de risco atrelado a identidade.

Para essas funções, podemos usufruir do PIM!

É importante frisar que o PIM deve ser utilizado para acessos privilegiados e não para qualquer acesso. A má utilização de seus recursos pode gerar transtorno aos usuários que necessitam de acessos triviais aos ambientes para realizar tarefas de seu dia a dia de trabalho. Ao utilizar o PIM, é essencial prestar atenção aos fluxos de aprovação criados, para garantir que os acessos de um usuário não fiquem dependentes de outras equipes cujas responsabilidade são outras.

Como o PIM funciona?

Na perspectiva do usuário

Esse é de forma simplificada, o fluxo de utilização do PIM.

O usuário necessita de um acesso considerado privilegiado. Acessa a console do PIM através do Portal Azure e consulta as funções que tem acesso.

No painel que contém as funções disponíveis para o usuário, ele pode escolher a função necessária (as funções disponíveis para o usuário devem ser configuradas previamente para permitir sua utilização).

Após selecionar a função desejada, o usuário entrará na fase de ativação. Essa fase consiste em definir o tempo desejado de ativação (em horas) e inserir uma justificativa para ativação da função.

Como última etapa, se configurada, o usuário pode precisar da aprovação de um outro usuário (ou de uma equipe, como é visto normalmente nas empresas) ou precisará utilizar um segundo fator de autenticação para conseguir finalizar a ativação da função.

Após feito o processo o usuário terá os privilégios necessários para realizar suas atividades!

Na perspectiva dos administradores e dos times de segurança

O papel dos administradores é operar a plataforma e criar junto dos times de segurança os controles de acesso desejados e recomendados.

Dentro do PIM podemos selecionar entre as mais diversas funções do Azure e do Azure AD. Cada função pode ser configurada de uma maneira diferente, atendendo os desejos dos times de segurança. Algumas das configurações disponíveis são:

Duração máxima da ativação — determina quanto tempo uma função que foi ativada ficará disponível para uso;
Aprovador — caso julgue necessário, os administradores podem configurar alguns aprovadores para aquela função. Quando um usuário solicitar a ativação, os aprovadores precisarão justificar o motivo de estarem aprovando/negando a ativação;
Duração qualificada — é possível especificar quanto tempo a função estará disponível para aquele usuário. Uma vez que esse tempo expirar, será necessário uma nova atribuição da função por parte dos responsáveis;
Notificações — os administradores podem configurar notificações para serem enviadas a certos usuários quando novos usuários forem atribuídos à função como qualificados, ativos ou quando a função for ativada.

Vamos à dois exemplos sobre como funções de diferentes privilégios e níveis de acesso podem ser configuradas:

Exemplo 1: as funções Desenvolvedor de aplicações e Analista de insights do Azure AD poderiam ser configuradas para exigirem que o usuário que as tenha disponível utilize o Azure MFA para confirmar a aprovação de seu uso.

Exemplo 2: as funções de Administrador como a Administrador Global, Administrador de Autenticação e Administrador de Cobrança podem ser configuradas para que o usuário elegível para sua ativação, necessite da aprovação de um outro usuário (ou equipe) antes de iniciar seu uso.

Quando os times finalizarem as configurações das funções, será hora de atribuí-las aos usuários conforme necessário.

Ao criar uma atribuição, será selecionado um escopo de acesso da função (se for uma função do Azure AD o escopo pode ser o tenant ou algum outro recurso, caso seja uma função do Azure o escopo pode ser qualquer um dentro das estruturas) e um destino da atribuição, que podem ser usuários ou grupos.

O último passo é escolher se o usuário terá a função disponível para ativação, precisando passar pelo fluxo de ativação configurado na função, ou se ela estará ativa para ele, nesse caso não requerendo a ativação através do PIM. O administrador também pode configurar um tempo de duração da atribuição, que obrigatoriamente deverá estar dentro do tempo de duração que foi configurado para a função (duração qualificada).

Nos familiarizando com o portal do PIM

Dentro do Portal do Azure você pode acessar o portal do PIM, que concentra todas as capacidades do recurso.

Ao acessar o portal, você irá se deparar com a seguinte tela:

Ao lado esquerdo abaixo de “Tarefas” podemos identificar as capacidades do PIM que permitem que o usuário:

Ative suas funções disponíveis (Minhas Funções);
Consulte os status das suas aprovações (Minhas solicitações);
Aprove solicitações de outros usuários (Aprovar solicitações);
Performe revisões de acesso (Análise de acesso);

Logo abaixo na seção “Gerenciar”, os usuários com privilégios suficientes poderão alterar as configurações de permissionamento das funções do Azure, Azure AD e funções atreladas à grupos.

Em “O meu Histórico de Auditoria” é possível visualizar os logs que representam as operações realizadas pelo usuário no PIM. Algumas dessas informações são:

Atualização da configuração da função;
Atribuição de novas funções para usuários e grupos;

O PIM é um recurso poderosíssimo para proteger seu ambiente Azure.

Suas capacidades e funcionalidades permitem inserir uma camada mais rígida de segurança para usuários que desejam acessar recursos e ambientes críticos.

Nos próximos artigos vamos realizar a configuração de algumas roles para exigir o uso do Azure MFA em sua ativação e da aprovação de outros usuários para permitir o acesso.

Em breve falaremos também sobre a revisão de acesso, recurso utilizado para reforçar a aplicação do princípio do privilégio mínimo, garantindo que os usuários tenham somente o acesso necessário e nada além disso.

Espero que tenha gostado do conteúdo e te espero no próximo.

Até logo!

KubeCon North America 2024 - recap

Mon, 09 Dec 2024 03:00:00 GMT

Quase um mês após o evento, chegou o momento de compartilhar os principais pontos que capturei ao longo dos 4 dias em salt lake city. Devido a concorrência, algumas palestras precisaram ser assistidas posteriormente, com a divulgação das gravações, então aqui vamos nós!

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.

Sobre o uso de GitOps e IaC para práticas de engenharia de plataforma, recomendo a palestra dos meus amigos Lucas e Tiago sobre o tema: https://www.youtube.com/watch?v=UFGr2qI9aOI

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!

#KuberTENes, Cloud Native Meetup - São Paulo - 06/06

Fri, 07 Jun 2024 03:00:00 GMT

No dia 07/06/2014 foi criado o projeto open source de maior sucesso da história, o Kubernetes! Com o passar dos anos, essa gigante plataforma de orquestração de contêineres foi adotada pelas maiores empresas do mundo e hoje contém milhares de contribuidores ao redor do globo. Como bons amantes das soluções open source e parte da iniciativa global da CNCF, nosso chapter cloud native - São Paulo fez questão de se reunir e comemorar esse marco tão importante da comunidade open source.

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.

![Pré-visualização da imagem](https://media.licdn.com/dms/image/D4D22AQGs6PpXB4MLfA/feedshare-shrink_800/0/1717529192836?e=1721865600&v=beta&t=BYOtT-y59dyfOKlRyNyCQa_UEeuwaUScm0SF2Eu5z0k align=“center”)

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!

Garantindo segurança na liberação de acessos com os Pacotes de Acesso do Entra ID

Tue, 26 Sep 2023 03:00:00 GMT

Visando facilitar a gestão de concessão de acesso, o Entra ID fornece a capacidade de “Pacotes de Acesso”, que habilita a atribuição de acesso à aplicações e grupos para diversos destinatários. Procurando entender como esse recurso pode agregar à segurança da sua empresa, vamos explorá-lo hoje!

Qual problema resolve?

Com o crescimento das empresas em suas áreas, a necessidade da contratação de novos empregados é certa. Com o alto fluxo de pessoas novas chegando nas empresas, os times de gestão de acesso e segurança serão sobrecarregados com as responsabilidades de criar os usuários e de atribuírem a eles os acessos “básicos” necessários para começar sua jornada na empresa.

Esse cenário se aplica não apenas à funcionários da empresa, mas também à terceirizados (prestadores de serviço) que são contratados, visto que também acessarão os recursos da companhia.

Com esse recurso do Entra ID, nós podemos criar pacotes que contenham os acessos aos recursos necessários em diferentes níveis e granularidades, como mostra a imagem abaixo:

Na imagem podemos ter uma ideia da granularidade alcançável com o uso dos Pacotes de Acesso. Podemos criar pacotes que contenham os recursos de uma equipe, de um departamento, recursos “básicos” para qualquer um na empresa (como acesso ao portal do RH, acesso ao Office 365, entre outros) entre outras possibilidades. Você poderá utilizar esse recurso de uma maneira que ele se aplique da maneira correta ao contexto da sua empresa.

Como começar?

A primeira etapa consiste da criação de um Catálogo de recursos, que nos permitirá organizar quais são os Aplicativos, Grupos e Sites do Sharepoint que o usuário que receber o pacote terá acesso.

Criando o catálogo de recursos

Para essa tarefa, podemos acessar o recurso “Catalog” dentro do Identity Governance em Entitlement Management. Você pode criar um catálogo antes de começar a configurar seu pacote de acessos, que é o nosso caso, porém também é possível realizar a criação do catálogo durante a criação do pacote de acessos.

Ao entrarmos na criação do catálogo você será apresentado com o seguinte formulário:

A criação é simples, basta inserir um nome e uma descrição para o catálogo.

É importante se atentar à opção “Enabled for External Users”. Caso você queira que terceirizados que não tenham e-mail com o domínio da sua empresa possam ter acesso ao catálogo, é importante que você mantenha essa opção habilitada.

Após finalizar a criação do catálogo você poderá atribuir recursos a ele. Ao acessar o catálogo criado, navegue até a aba “Resources” e selecione “Add Resources”. Aqui você poderá adicionar os recursos que farão parte do seu pacote de acesso. Procure definir bem os limites dos pacotes de acesso, garantindo que um determinado pacote forneça acesso apenas ao que diz respeito a ele e que não tenha mais coisas do que o necessário.

Recursos adicionados? Podemos partir para a criação do pacote de acesso!

Criando o Pacote de Acesso

Partindo para a configuração do nosso pacote, iremos configurá-lo desde o início. As etapas de configuração são as seguintes:

Apenas as abas Basics, Requests e Lifecycle são obrigatórias, como você pode notar o asterisco vermelho à esquerda do título. Mesmo as outras opções não sendo obrigatórias, passaremos por elas pois temos configurações importantes e que nos possibilitam aumentar ainda mais a cobertura dos pacotes de acesso.

Basics

As primeiras configurações são as mais simples. Nessa aba nós escolheremos o nome do nosso Pacote de Acesso, uma descrição para ele e também selecionaremos um dos catálogos disponíveis em nosso tenant. Para esse exemplo, você pode utilizar o catálogo que criou anteriormente e que talvez já contenha alguns recursos, porém caso não tenha realizado a criação de um novo catálogo, existe um padrão que está disponível em todos os tenants, chamado “General”.

Terminando o preenchimento dos campos o seu formulário deve estar parecido com esse, só que com as informações preenchidas por você:

Resource roles

Apesar de não ser uma aba de preenchimento obrigatória, aqui iremos configurar quais recursos do catálogo selecionado deverão ser aplicados aos destinatários.

No meu catálogo eu inseri alguns grupos e algumas aplicações existentes em meu tenant. Como pode ser visto na imagem acima, o grupo “Departamento de Segurança” e a aplicação “Portal Intranet” foram selecionadas para fazerem parte do pacote de acesso.

Nos grupos é possível selecionarmos qual papel o usuário assumirá dentro dele, se é um papel de Membro (Member) ou de Dono (Owner) do grupo.

Requests

Passando para a segunda aba obrigatória, essa em si é uma extremamente importante.

Os pacotes de acesso não são restritos à atribuição por um administrador, nós podemos também configurá-los para permitir que os usuários solicitem acesso ao pacote por conta própria. Isso pode ser muito útil para os times de gestão de identidade, que não precisarão ficar atribuindo os pacotes e poderão apenas aprovar ou rejeitar a solicitação do usuário.

A primeira seção nos permite definir quem poderá solicitar acesso ao pacote. Temos as seguintes opções:

Usuários em seu diretório;
Usuários que NÃO estão em seu diretório;
Ninguém — a atribuição deverá ser feita diretamente por um administrador.

Caso você selecione a primeira opção, poderá escolher entre algumas opções para controlar a solicitação de acesso. Você poderá escolher:

Usuários e grupos específicos;
Todos os usuários (excluindo os externos/guests);
Todos os usuários (incluindo externos/guests);

Podemos também configurar uma aprovação necessária para permitir o acesso, podendo escolher até 3 níveis de aprovação, o gerente direto do funcionário como aprovador, validade da requisição e também aprovadores para fallback, garantindo que caso o aprovador primário não esteja disponível, a requisição possa ser atendida por outra pessoa.

A segunda opção habilita a atribuição do acesso à tenants conectados ao tenant da sua empresa. Você poderá escolher tenants específicos, todos os tenants que estão configurados ou até permitir que todos os tenants conectados e todos os usuários novos solicitem acesso (maior cobertura). Essa opção permite por exemplo que uma empresa controle os acessos aos outros tenants de uma mesma holding (grupo de empresas sob o mesmo conselho executivo).

A terceira e última opção é a “mais tradicional”, que exige que os pacotes de acesso sejam atribuídos diretamente por um usuário administrador. Essa opção permite o maior controle sobre quem terá os acessos mas também gera muita carga operacional em cima dos times de gestão de acesso.

Essa opção deve ser utilizada com cuidado por conta da capacidade de “engessamento” dos processos. O uso indevido dessa propriedade causará lentidão na execução das solicitações, sobrecarga de trabalho aos times de gestão de acesso e também poderá gerar impactos nas atividades exercidas pelos funcionários que necessitam do acesso.

Na seção “Enable” podemos configurar se a política configurada deve estar ativa, permitindo que solicitações de acesso sejam registradas ou inativa, não aceitando novas solicitações até sua ativação.

Requestor information

Nesta seção nós podemos criar perguntas que serão mostradas ao usuário no momento em que o mesmo estiver solicitando seu acesso ao pacote.

As perguntas podem ser marcadas como obrigatórias e podem ser do tipo:

Texto curto;
Múltipla escolha;
Texto longo.

Ao acessar o portal do My Access e selecionarem o pacote que desejam ter acesso, os mesmos deverão responder as perguntas obrigatórias para que possam finalizar a requisição.

Lifecycle

Na última aba obrigatória, vamos configurar as propriedades de validade das atribuições dos pacotes de acesso.

Neste ponto podemos configurar para que a atribuição:

Dure até determinada data;
Dure certa quantidade de DIAS;
Dure certa quantidade de HORAS;
Nunca expire.

Podemos além de definir de maneira estática a duração da atribuição, permitir que o usuário que está solicitando o acesso insira a duração desejada.

O uso das Revisões de Acesso também se faz possível nessa seção. Aqui podemos configurar as revisões de acesso que deverão ser executadas em cima desse pacote, garantindo a retirada de qualquer usuário que não necessite mais do acesso.

A opção “Users can request specific timeline” é onde podemos permitir ou negar que o usuário insira sua própria data de expiração do acesso. Da mesma forma que esse recurso é útil, ele se torna um vetor de ataque quando não temos uma política de revisão de acesso configurada, pois não conseguiremos controlar quando aquele usuário terá seu acesso encerrado.

Custom extensions

Visando a automação dos processos, nessa seção nós podemos selecionar alguns fluxos do Azure Logic Apps para que sejam executados quando um evento acontecer.

Os eventos disponíveis são os seguintes:

Você poderá atribuir um fluxo do Logic Apps para cada um dos eventos demonstrados acima.

Review + create

Após todas as configurações, chegou a hora de revisar seu trabalho e confirmar a criação do seu recurso!

E agora?

Caso você tenha configurado o pacote para permitir que os usuários solicitassem acesso, basta seu usuário navegar até My Access e solicitar o acesso ao recurso.

Agora, caso você tenha configurado para que um administrador realizasse a atribuição do pacote aos usuários, será necessário que esse administrador acesse o Portal do Entra e que realize a atribuição do pacote ao usuário desejado. Ao navegar até a página do Pacote de Acesso criado você verá que o primeiro campo de preenchimento para a atribuição é a seleção de uma policy.

Essa policy unifica os mecanismos de governança do pacote e é constituida das informações que foram inseridas durante a criação do pacote. O que você configurou em “Requests”, “Requestor information”, “Lifecycle” e “Custom extensions” é representado de maneira unificada por uma policy. Você pode criar policies diferentes para as diferentes necessidades de governança que você tem.

É importante que a policy esteja ativa, caso contrário ela não entrará em efetividade e seus controles não serão aplicados!

Os pacotes de acesso fornecem muito mais do que apenas organização nas liberações, eles reforçam a segurança e garantem o compliance da empresa.

Espero que tenha gostado do conteúdo e que a partir de agora você consiga usufruir desse recurso tão poderoso.

Até logo!

MDM (Mobile Device Management) + Intune

Tue, 30 Jan 2024 03:00:00 GMT

Com cada vez mais dispositivos sendo utilizados pelos usuários no dia a dia, é importante mantermos os equipamentos utilizados para acessar informações da organização controlados e em compliance com as normas internas.

O que é MDM?

Uma solução de MDM, ou Mobile Device Management, é utilizada pelas organizações para gerir de maneira mais eficiente os dispositivos corporativos fornecidos aos funcionários e terceirizados. Utilizar uma solução de MDM permitirá que os times de segurança implementem as políticas de segurança que melhor se encaixam no uso daquele usuário.

Além da segurança, os controles que podem ser feitos através de uma solução de MDM permitirão otimizar as atividades corporativas dos usuários através da eliminação de aplicativos indesejados, recomendação de aplicativos corporativos e com a personalização das experiências dos usuários dentro do dispositivo e também dos aplicativos.

Podemos também em algumas soluções, controlar o comportamento e a atividade dos usuários dentro de aplicativos. É possível escolher entre diferentes tipos de solução e de plataformas para a aplicação dos controles.

O desenho apresentado no início deste capítulo mostra de maneira genérica os diferentes dispositivos e sistemas que podem ser monitorados. A solução mostrada é o Microsoft Intune, solução de MDM da Microsoft, completamente integrada com o Microsoft Entra e com as soluções do Office 365.

Falaremos com mais detalhes sobre o Intune no próximo capítulo, porém suas capacidades técnicas como solução de MDM são parecidas com as vistas nas demais soluções de mercado. Gestão de dispositivos, gestão de aplicações, proteção contra vazamento de dados, enforcement de políticas de segurança, criptografia de disco, são algumas das funções que o Intune faz e que nós vamos comentar!

Microsoft Intune

![](https://learn.microsoft.com/pt-br/mem/intune/fundamentals/media/what-is-intune/what-is-intune.png align=“center”)

Solução de MDM da Microsoft, o Intune vem nativamente integrado às soluções do Microsoft Entra e do Office 365. Com a integração ao ecossistema do Entra, podemos utilizar informações relacionadas aos dispositivos gerenciados pelo Intune, na configuração das políticas de acesso.

Falando especificamente do Intune, podemos acessar seu portal através do endereço: intune.microsoft.com.

Por ser uma solução com capacidades próprias, o Intune tem um modelo de licenciamento diferenciado. Se a sua organização faz uso das licenças do Enterprise Mobility E3 ou E5, ela estará apta à fazer uso da solução. Outras licenças como 365 Business Premium e Intune for Education, também concedem o acesso à ferramenta. Caso deseje saber mais sobre as licenças, este link fornece outras informações.

Dentro do portal, você poderá explorar todas as funcionalidades fornecidas pela solução. Se for a sua primeira vez acessando e utilizando a ferramenta, provavelmente não terá muitas informações cadastradas e disponíveis. Para iniciarmos a utilização de maneira massiva, devemos iniciar fazendo o onboarding dos dispositivos ao Intune, os registrando na solução e realizando as configurações necessárias no próprio dispositivo.

O processo de onboarding varia de dispositivo para dispositivo. Não existe um modelo padrão para se seguir, as etapas irão variar de acordo com o sistema operacional do dispositivo. Falaremos sobre esse processo de onboarding em outro artigo, porém se quiser saber mais, deixo este link da documentação oficial da Microsoft explicando os processos.

Sem o processo de onboarding, você não poderá fazer muitas coisas na sua solução, então vamos aproveitar para citar alguns recursos interessantes que você poderá utilizar em sua organização:

Device Enrollment: comentamos anteriormente do processo de onboarding, esse recurso fornece funcionalidades que nos permitem realizar esse processo de maneira simplificada e de diversas formas;
Security Baselines: algo que deveria ser adotado por todas as organizações que estão utilizando a ferramenta, os baselines fornecem direcionamentos de segurança baseados nos guias construídos pela Microsoft, contendo as melhores práticas e os padrões de mercado recomendados;
EDR: acrônimo para Endpoint Detection and Response, é uma das principais capacidades do Microsoft Intune. Esse recurso nos permite implementar monitorações com o intuito de detectarmos atividades anômalas nos nossos dispositivos;
Device Compliance: com a proposta de manter todos os dispositivos ativos no ambiente, esse recurso permite que especifiquemos uma lista de ações que serão executadas quando um dispositivo for marcado como non-compliant. Podemos configurar uma lista de ações baseadas em eventos padrões e em períodos de tempo (ex: marque o dispositivo como non-compliant após 2 dias).

Esses foram apenas algumas funções básicas do Intune que exploramos, veremos muito mais nos próximos capítulos.

Por quê utilizar uma solução de MDM?

Ao longo do texto, entendemos quais são as capacidades básicas dessa solução e falamos inclusive sobre o Intune, MDM do Microsoft Entra.

Agora, por quê a sua organização deve adotar uma solução de MDM?

Além dos motivos citados anteriormente, precisamos pensar na evolução da organização. As empresas estão evoluindo cada vez mais rápido, utilizando diversas tecnologias diferentes e com colaboradores em todo o mundo. A dinamicidade de informações e insumos trafegados entre contas e dispositivos aumenta exponencialmente a cada dia, desafiando as estratégias de proteção dos ativos da organização implementadas pelos times de segurança.

Não apenas isso, com a variedade de ataques com propósito de obter informações confidenciais e estratégicas das empresas, garantir a aplicação de controles como antivírus, criptografia de disco e proteção contra vazamento de dados, é essencial para a boa execução das atividades de negócio da organização.

Com a crescente adoção de estratégias BYOD (Bring Your Own Device), as organizações precisam se preparar para problemas que não seriam enfrentados caso os dispositivos utilizados fossem gerenciados e de domínio da corporação. Utilizar uma solução de MDM que permita a aplicação de controles diferenciados e personalizados para dispositivos pessoais, registrados pelos colaboradores, dá às equipes de segurança a tranquilidade na adoção desses equipamentos.

Hoje falamos sobre o básico, o que é e quais as capacidades de uma solução de MDM, comentamos brevemente sobre o Microsoft Intune e também mencionamos o que a sua organização deve levar em conta quando estiver estudando a adoção de uma solução de MDM.

Espero que tenha gostado do texo e nos vemos em breve.

Até logo!

Microsoft Defender for Endpoint

Sun, 28 Jul 2024 03:00:00 GMT

Semana passada presenciamos um outage global causado por uma falha nos sistemas da Crowdstrike, empresa líder no mercado de cibersegurança. A solução de EDR (Endpoint Detection and Response) é responsável por monitorar dispositivos para ameaças e atividades suspeitas que ali podem estar ocorrendo. Como uma alternativa, temos o Microsoft Defender for Endpoint, solução de EDR da Microsoft e que iremos explorar hoje.

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

![Nıŋʝąƈąɬ 🐈 on X: “This short and sweet video explains the Microsoft Defender for Endpoint architecture. Thanks @HeikeRitter https://t.co/6eqWb0AAy4 https://t.co/9eFMrWPnWc” / X](https://pbs.twimg.com/media/FX4BHvYXgAcFCSz.jpg:large align=“center”)

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!

Microsoft Defender for Storage: malware scanning

Tue, 02 Jul 2024 03:00:00 GMT

No artigo anterior falamos de maneira geral sobre as capacidades do Defender for Storage e como o mesmo pode contribuir para a proteção dos storages da sua empresa. Hoje vamos falar com mais detalhes sobre as varreduras que o Defender faz em seus blobs e como utilizar esse recurso para montar sua arquitetura.

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:

![Screenshot that shows an example of a blob index tag.](https://learn.microsoft.com/en-us/azure/defender-for-cloud/media/defender-for-storage-malware-scan/blob-index-tags.png#lightbox align=“center”)

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.

![Diagram showing flow of viewing and consuming malware scanning results.](https://learn.microsoft.com/en-us/azure/defender-for-cloud/media/defender-for-storage-malware-scan/view-and-consume-malware-scan-results.png align=“center”)

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!

Microsoft Defender for Storage

Tue, 18 Jun 2024 03:00:00 GMT

Você já se deparou com a necessidade de receber arquivos de fontes externas sem a certeza da confiabilidade da origem? Já olhou para suas subscriptions e se questionou se havia algo a mais que pudesse ser feito para proteger melhor seus storages? Hoje falaremos sobre o Defender for Storage, solução parte do Defender for Cloud que permite reforçar a segurança das suas storage accounts e garantir a integridade da sua plataforma.

O que é o Defender for Storage?

![Diagram showing the benefits of using Defender for Storage to protect your data.](https://learn.microsoft.com/en-us/azure/defender-for-cloud/media/defender-for-storage-introduction/defender-for-storage-benefits.png align=“left”)

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.

Para relembrar: a proposta do CNAPP é ter de maneira centralizada todas as soluções de segurança necessárias para proteger suas aplicações cloud native. A cobertura de uma solução de CNAPP vai desde o commit do código através das pipelines e chegando aos repositórios, até a execução desse código nas plataformas cloud (em virtual machines, contêineres + kubernetes, etc). Todo o ciclo de vida da aplicação e da infraestrutura em nuvem, é visível através das dashboards do CNAPP, oferecendo aos times de segurança maior conforto e confiança para proteger as iniciativas de negócio.

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.

O Defender for Storage está disponível para as ofertas: Azure Files, Azure Data Lake Storage Gen2 e Azure Blob Storage.

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.

Não é uma boa prática de arquitetura deixar alguns storages habilitados e outros não. É importante que seus repositórios estejam sempre protegidos com as recomendações baseadas no Microsoft Cloud Security Benchmark. Para garantir proteção em todos os repositórios da sua organização, é recomendado o uso de policies para garantir a correta habilitação da funcionalidade.

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!

Microsoft Entra? Entra ID? Verified ID?

Mon, 17 Jul 2023 03:00:00 GMT

No dia 11/07/2023 a Microsoft anunciou uma série de mudanças em seu ecossistema de identidade. Que mudanças foram essas? Vamos conferir algumas das mais impactantes nesse artigo.

No evento online, os especialistas da Microsoft divulgaram de maneira oficial uma série de mudanças aplicadas em seus produtos. Essas mudanças já vinham sendo divulgadas, porém dessa vez foram feitas através de um anúncio oficial.

Além das novas soluções disponíveis em public preview, como o Microsoft Entra Security Service Edge, os produtos da família Azure AD se tornaram oficialmente Microsoft Entra ID.

A imagem abaixo mostra o novo conjunto de soluções que fazem parte do “guarda-chuva” do Microsoft Entra:

Vamos fazer a leitura dessa imagem em sentido horário, começando ao topo e passando por todos os produtos.

Entra ID

O novo nome do nosso grande amigo Azure AD. O Entra ID não traz consigo novas funcionalidades para o produto, as mudanças aplicadas são restritas aos nomes, não só do próprio Azure AD mas como também das licenças, que agora passam a ser chamadas de:

ID Governance

O propósito desse “produto” é centralizar as capacidades de governança de identidades.

No Portal do Entra é temos o seguinte painel lateral:

As capacidades disponíveis nele não são novas, todas elas já eram previamente existentes à reformulação da família de produtos do Entra. Era possível utilizar esses recursos através do Portal do Azure AD, dentro do Portal Azure.

Verified ID

Recurso novo dentro do ecossistema, o propósito do Verified ID é fornecer uma nova forma de verificar a identidade do usuário.

As identidades descentralizadas vem sido bastante comentadas no mercado, e o Verified ID é o responsável por representar o assunto na suíte do Entra.

Este link é a documentação oficial da Microsoft sobre o Verified ID e sobre as identidades descnetralizadas. É um tema complexo e que requer certo empenho para seu entendimento, por isso, gostaria de compartilhar também esse link do Andy Malone, que fornece um hands-on no recurso e permite que você entenda como ele funciona e seus casos de uso. O vídeo é em inglês, porém conta com as legendas automáticas do youtube, para garantir que o idioma não será uma barreira para seu aprendizado!

Permission Management

Com o passar do tempo, é comum que usuários acabem “colecionando” diversas permissões diferentes, em dever da participação em diversos projetos e também da mudança de funções.

Esse excesso de permissões é um problema para a empresa, pois o risco que essa identidade oferece caso seja comprometida, é altíssimo.

O Permission Management (Gerenciamento de Permissões) oferece visibilidade das permissões fornecidas aos usuários em múltiplas plataformas.

Com esse recurso, podemos garantir a aplicação do princípio do privilégio mínimo, pilar do zero trust. Garantimos que os usuários tenham apenas as permissões necessárias para realizar suas atividades.

Internet Access

Uma das novidades apresentadas foi a introdução da solução de Secure Web Gateway, o Microsoft Entra Internet Access.

O propósito de um SWG é fornecer capacidades de segurança para que uma empresa proteja seus funcionários de riscos na web e também de proteger a empresa de possíveis vazamentos de dados.

O Entra Internet Access fica no meio das comunicações do usuário com ferramentas SaaS e com os produtos do Microsoft 365.

Este artigo da Cloudflare explica com mais detalhes o funcionamento da solução.

Private Access

Tratado como um “substituto” das VPN tradicionais, o Entra Private Access habilita que as empresas fortaleçam a segurança do no acesso de aplicações internas por parte dos funcionários.

Somado à funcionalidades fornecidas pelas políticas de acesso condicional, o Entra Private Access habilita os times de segurança à protegerem de melhor forma seus apps e seu ambiente.

ID Protection

Conhecido como identity protection nos tempos de Azure AD, o ID Protection também ganhou uma seção própria dentro do Portal do Entra. O ID Protection utiliza machine learning para oferecer os recursos que permitem às empresas incrementar a segurança das identidades do Entra ID.

Com uma série de dashboards personalizadas, os administradores podem visualizar informações sobre a origem dos ataques às identidades (tentativas de login forçadas, password spray, etc), bem como a quantidade de ataques bloqueados, identidades protegidas e mais uma série de informações sobre como o recurso incrementa a proteção do seu ambiente.

Workload ID

Também com objetivo de centralizar informações em um painel unificado, o Workload ID fornece uma visão geral das identidades não-humanas presentes no Microsoft Entra ID. Essas identidades podem ser aplicações federadas (utilizando o Enterprise Applications e o Application Registration no Portal do Entra ID) mas também podem ser Service Principals, criadas para serem utilizadas por workloads que necessitam de permissão para consumir recursos do Azure.

Dashboard no Portal do Entra que fornece a visão centralizada das identidades não-humanas no tenant

O tema de identidades para workloads vale um outro artigo, mas a divisão fornecida pelo gráfico segrega as identidades gerenciadas (que são atreladas à recursos de infraestrutura), as aplicações Microsoft (que por padrão ficam “invisíveis” no Portal do Entra ID, bastando retirar os filtros para visualizá-las) e as aplicações federadas e service principals (que são respectivamente representações de ferramentas que utilizam o Entra ID como provedor de identidade e identidades mais flexíveis para workloads).

Essas foram as novidades anunciadas. Os novos recursos vieram para fortalecer muito a estratégia de segurança de acesso das empresas, trazendo mais confiança para os times de segurança e operação e também mais conforto para os usuários, que terão a tranquilidade de saber que suas credenciais estão seguras.

Espero que tenha gostado das novidades e recomendo que você as teste.

Até logo!

Microsoft Entra ID: Cross-tenant Access

Wed, 22 May 2024 03:00:00 GMT

Sua empresa faz parte de um grupo de outras organizações? Seus times de segurança tem problemas para gerenciar o acesso de usuários externos (terceirizados, colaboradores, parceiros)? Controlar quem pode acessar o seu tenant é essencial e tem ficado cada vez mais simples. Hoje vamos falar sobre o cross-tenant access, recurso do Entra que permite configurar as diferentes formas de conexão entre tenants e os controles que devem ser aplicados.

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.

Nesse modelo, as contas dos usuários convidados são representadas como contas guest dentro do tenant.

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.

Diferente do B2B Collaboration, os usuários NÃO são representados como contas guest.

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.

Importante frisar que para configurar a sincronização entre tenants, os diretórios devem ter licenças P1 ou P2 atribuídas para seus usuários.

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.

Alterar essas configurações pode gerar alta exposição ao seu tenant, visto que elas serão aplicadas a todas as identidades e aplicações convidadas e sincronizadas, portanto tome cuidado ao alterar as configurações default.

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!

Network Policies: microsegmentação em clusters Kubernetes

Tue, 29 Oct 2024 03:00:00 GMT

Conforme nosso ambiente evoluí, mais e mais aplicações passam a ser executadas em nossos clusters, o que em larga escala, pode se tornar complicado para gerir. Visando fornecer uma maneira mais eficiente de controlar o acesso aos recursos do seu cluster, vamos falar sobre as Network Policies, que com um toque de Cilium, nos permitem garantir a boa proteção dos nosso ambientes, independente da complexidade.

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.

Configurar a microssegmentação nos ambientes é uma tarefa extremamente trabalhosa e exaustiva. Hoje, empresas líderes de mercado como a Akamai oferecem soluções de microssegmentação indepentendente da nuvem que você utilize. Essas soluções tornam mais simples a implementação e a gestão da configuração dos ambientes. Veja: Akamai Guardicore.

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.

Entraremos nos detalhes da criação das policies em um artigo futuro, neste momento se concentre em entender o padrão dos templates e as similaridades entre eles.

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.

Essas políticas terão impacto no cluster como um todo, portanto é preciso ser cuidadoso ao utilizá-la, visto que outros recursos podem sofrer impacto com suas regras.

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!

Named Locations

Thu, 18 Jan 2024 03:00:00 GMT

No momento de design das políticas de segurança da sua empresa, é importante que nós tenhamos disponível diferentes informações, que nos habilitarão a implementar uma maior granularidade nos controles e proteger o nosso ambiente de maneira mais eficiente, considerando sempre a usabilidade do usuário. Uma informação presente na grande maioria das empresas, é a localização dos seus escritórios. Pensando nisso, hoje vamos falar sobre as named locations, recurso do Entra ID que nos permite configurar esses espaços para personalizar a aplicação das políticas de segurança.

O que são as named locations?

Durante a construção das políticas de segurança da sua empresa, você já se pegou pensando que seria ótimo se houvesse uma maneira de representar o seu escritório, ou a rede confiável da sua empresa para aplicar políticas de acesso personalizadas? Hoje nós temos essa possibilidade com as named locations!

Esse recurso permite que representemos as redes das empresas que devem ser tratadas como “confiáveis” para que possam ser utilizadas na aplicação das políticas de segurança.

Ficou confuso? Vamos a um exemplo.

Suponha que a sua empresa tenha a matriz (escritório principal) localizada no Brasil, porém com filiais na Argentina, Estados Unidos, Itália e também Austrália. Você deseja utilizar na sua análise de segurança o IP de onde vem a chamada e também a localização geográfica. Para isso, nós podemos usar as locations!

Seguindo na linha deste exemplo, nós podemos criar uma location que contenha todos os países e uma outra que contenha os ranges de IP que representam as filiais da sua organização. Dessa forma, nós poderíamos utilizar essas informações dos escritórios como insumo para aplicação das políticas de segurança.

Aplicando as políticas através de IP e das localizações, nós teríamos um ambiente parecido com esse:

Neste cenário acima, as requisições vindas dos ranges de IP das filiais e também a origem da requisição, são levadas em conta. Dentro da política de acesso condicional, nós implementaríamos os controles de uma maneira que apenas as requisições vindas das regiões das filiais e também de seus respectivos ranges de IP seriam permitidos e qualquer chamada fora desses locais, seria negada.

Agora que entendemos como o recurso funciona, vamos falar sobre as melhores estratégias para sua utilização, visando sempre proteger o seu ambiente da melhor forma.

Estratégias para utilização

Como qualquer recurso de segurança, é essencial que seja feito um planejamento antes de sua criação e configuração. Com as locations isso não seria diferente.

A primeira coisa que se deve pensar é: o que eu preciso representar com as locations?

Essa pode parecer uma pergunta óbvia, porém não é. Conforme vamos evoluindo nosso pensamento sobre o que deve ser representado pelas locations vamos percebendo o quão complexa é essa tarefa. Essa complexidade é ainda mais agravada se a sua organização contém múltiplas localidades, escritórios, empresas parceiras, prestadores de serviço, etc. Conforme evoluímos nosso planejamento com maturidade, cada vez mais considerações são feitas préviamente à definição de implementação.

Para adequar a configuração dos seus componentes de maneira satisfatória, essa pergunta deve ser respondida levando em consideração todos os ambientes gerenciados pela sua organização, mas também ambientes externos que tenham acesso à ela, ambientes esses que muitas vezes acessam aplicações e serviços internos através de conexões VPN.

Outra consideração que devemos fazer é: de que forma organizaremos essas informações?

Apesar das locations representarem as localizações de certos ambientes, precisamos tomar cuidado com a governança dessas configurações, pois isso pode fugir de controle rapidamente.

Organizar as localizações confiáveis em grupos e os ranges de IPs “seguros” com uma classificação que nos permita identificar de maneira breve que localidade é aquela, é um desafio. A verdade é que não existe uma resposta certa, cada empresa tem suas peculiaridades e seus cenários próprios, por isso é importante que o time de segurança responsável por analisar esses fatores e registrar as locations, atue com cautela e busque a maior quantidade de informações possíveis, pensando na melhor manutenção do seu ambiente.

Para criarmos a lista de regiões, a informação mais importante é: quais são os lugares onde a sua empresa NÃO opera? Responder essa pergunta nos permite eliminar uma grande quantidade de lugares e reduzir as possibilidades de ataques vindo dessas origens. Podemos criar uma lista apenas com países onde a organização contém filiais presentes e proibir qualquer acesso vindo de fora daquela lista.

Outra estratégia comumente encontrada (mas não necessáriamente recomendada) é marcar como “localização confiável” as redes internas da sua empresa. Não marcar qualquer rede como confiável é o mínimo, agora marcar diversas redes da sua empresa como confiáveis, pode expor o seu ambiente à ataques não esperados. Construir uma arquitetura Zero Trust exige que todas as requisições sejam verificadas de maneira explícita, “confiar” em um ambiente fere esse princípio!

Você deve ter percebido que existe certo trade-off em relação à criação e a organização dessas configurações. Devemos utilizar com cautela e sabedoria esses registros, para não expormos nosso ambiente à possíveis ameaças e vulnerabilidades. Utilizá-los para proibir o acesso de localizações não permitidas pode ser uma boa estratégia, porém utilizar as informações para permitir o acesso à partir de localizações confiáveis e sem a aplicação de controles mais rígidos, trará ao seu ambiente altos riscos.

Configuração

No Portal do Entra, podemos navegar até named locations e iniciar a criação dos nossos regisitros.

Como mencionei anteriormente, esse recurso nos permite trabalhar com regiões globais e com ranges de IP.

Countries Location

Selecionando “Countries location”, será necessário fornecer um nome para a nossa política. Após isso, precisaremos escolher qual o modelo de identificação de origem que será utilizado.

Temos duas opções disponíveis, "Determine location by IP address" ou "Determine location by GPS coordinates". A primeira utiliza uma lista de IPs por país para identificar de onde a chamada está vindo. A segunda opção faz uso do aplicativo Microsoft Authenticator para solicitar ao usuário o compartilhamento da sua localização por GPS.

Após isso, teremos uma lista de países para escolher e incluir em nosso registro.

O limite de países por registro é de 195.

IP ranges location

Para os ranges de IP a configuração é mais simples. Além do nome do registro, também é necessário fornecer (é claro) os ranges que devem ser considerados.

Existe um limite máximo de ranges de IP por registro, que é 2.000.

Uma outra configuração que pode ser feita, é marcar aquela location como “confiável”. Registrar uma localização como confiável, não fará nenhuma diferença direta. A grande questão é que na montagem da nossa política de acesso condicional, nós poderemos selecionar TODAS as locations marcadas como confiáveis. Isso nos permitirá aplicar controles de segurança homogêneos entra as diferentes localizações da nossa organização.

As locations por IP permitem o cadastramento de endereços IPv4 e IPv6!

Uso no conditional access

Dentro do nosso editor de política, sob a sessão location, nós teremos as seguintes opções:

Essa política estará sendo aplicada para todas as localizações marcadas como confiáveis. Se selecionarmos a primeira opção “Any location”, qualquer chamada receberá a aplicação do controle, independente da origem. A última opção “Selected locations” nos permite escolher algumas locations previamente registradas (essa opção é útil caso a política de acesso condicional que está sendo configurada, tenha o intuito de aplicar algum controle personalizado por localidade).

Na aba exclude temos o seguinte:

Podemos eximir as localizações confiáveis da aplicação daquela política ou podemos selecionar locations específicas para sofrerem um bypass dos controles.

Utilizar a opção "All trusted locations" na seção Exclude pode fazer sentido se as locations confiáveis forem de posse da sua organização. Reforçando o que foi mencionado anteriormente, a aplicação desse controle fere o princípio verify explicitly de uma arquitetura Zero Trust!

Como profissionais de cibersegurança, é importante que nós tenhamos conhecimento aprofundado em diversos recursos que podem auxiliar em nosso dia a dia, porém ainda mais importante, é saber quando e como nós devemos utilizar essas funcionalidades.

Espero que tenha gostado do texto e que eu de alguma forma tenha contribuído para o fortalecimento da postura de segurança da sua empresa.

Até logo!

Open Source - o quão estratégico pode ser?

Wed, 07 May 2025 03:00:00 GMT

História

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.

Open Source é seguro sim! Toda solução tem suas características e vulnerabilidades, reduzir uma categoria de projetos pura e exclusivamente baseado em uma opinião sem fundamento apenas prejudica a comunidade.

Ó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.

Neste ponto estamos retirando de perspectiva a integração com equipes e fluxos de segurança e times legais da organização. Estamos pensando apenas em tecnologia.

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

É importante termos em mente que estamos falando de empresas end users e não fornecedores. A adoção de uma estratégia open source em uma empresa como o Google e AWS é completamente diferente de uma prestadora de serviços.

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.

Contribuição para o open source é algo voluntário. O engajamento da comunidade é o que faz os projetos crescerem e serem bem sucedidos. É crucial que as empresas tenham essa proposta de usufruir dos projetos e incentivar a comunidade a continuar com o trabalho.

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

Reforçando a segurança de acesso no Entra ID

Tue, 29 Aug 2023 03:00:00 GMT

Para as empresas que estão completamente na nuvem, a primeira camada de defesa é a camada de acesso, pois não tem que se preocupar com a proteção do ambiente físico. Hoje vamos falar de alguns recursos que nos permitem reforçar a segurança dos acessos através de políticas de senha, múltiplos fatores de autenticação e também autenticação passwordless.

Dentro do Portal do Entra, na seção “Proteção” temos a opção “Métodos de Autenticação”. Neste recurso, utilizaremos as diversas funcionalidades fornecidas pelo Entra para reforçar a segurança de acesso do nosso ambiente.

Introdução

Como comentado no início do texto, a segurança de acesso é a primeira camada de proteção que podemos utilizar para nosso ambiente em nuvem (para saber mais sobre segurança em profundidade, clique aqui). Na realidade, antes da camada de acesso nós temos a camada física, porém para ambientes em nuvem a responsabilidade sob esse nível é completamente da provedora de serviços. Para empresas que contém seus próprios ambientes (on-premise) essa responsabilidade entra em jogo.

Existem diferentes maneiras de incrementarmos a segurança de acesso em nosso ambiente, podemos utilizar ferramentas de detecção de ameaças que monitorarão as contas para identificar atividades suspeitas, podemos impor políticas de senha, de dispositivo, exigir autenticações “mais fortes” de acordo com a necessidade, e além das possibilidades apresentadas, temos diversas outras que podem ser adotadas pela sua empresa.

Hoje vamos falar especificamente de algumas das funcionalidades fornecidas pelo Entra para fortalecer os acessos às plataformas.

Ao longo do texto você se irá se deparar algumas vezes com o termo passwordless, então para evitar confusão, vou explicar brevemente o conceito.

Passwordless (ou “sem senha” em português) é o método de autenticação que não exige que o usuário digite uma senha. A autenticação será feita utilizando outros recursos como um aplicativo autenticador (Google Authenticator, Microsoft Authenticator, etc.), identificação biométrica, identificação por voz, OTPs (one-time passwords) e até tokens físicos (padrão FIDO). Esse método é altamente recomendado pois traz mais conforto aos usuários por retirar a necessidade da senha e oferece mais segurança, visto que a superfície de ataque é reduzida pois você estará utilizando algo que você tem, impedindo que o atacante use o recurso.

Proteção por senha

Mesmo sendo um método de autenticação “fraco” devido sua superfície de ataques (engenharia social, password spray, man in the middle, etc.) grande parte das empresas ao redor do mundo ainda tem o processo de autenticação de seus funcionários baseado em senhas. Isso se dá não apenas pelo desejo de manter este método, mas também pela inexperiência das equipes de segurança e tecnologia e pela inefetividade na implementação de fatores mais seguros.

Mesmo esse método sendo desencorajado hoje, não é correto que as equipes de segurança realizem uma mudança radical de uma hora para outra, implementando modelos e ferramentas mais modernas sem treinar suas equipes de suporte, segurança e principalmente os funcionários “comuns” (entende-se como comuns as pessoas fora da área de tecnologia, que não necessariamente entendem todas as motivações pelas trocas), que utilizarão as ferramentas no dia a dia de trabalho. Além do extenso estudo, para entender as ferramentas que melhor se adequam à sua empresa, os testes e as releases progressivas serão as principais garantidoras do sucesso da nova estratégia de segurança adotada pela empresa.

Agora, não é porquê o método tem seu uso desencorajado que não é possível melhorar sua segurança para evitar problemas causados pelos ataques mais conhecidos e mencionados anteriormente.

Dentro da seção “Proteção por senha” dos métodos de autenticação, podemos impor regras personalizadas para as senhas cadastradas pelos usuários no Entra ID.

Nas duas primeiras linhas podemos controlar a quantidade de tentativas permitidas antes de um bloqueio e também a duração do bloqueio. Não é recomendado deixar o número de tentativas tão alto, pois dessa maneira deixamos abertura para que atacantes tentem uma maior quantidade de senhas possível antes do bloqueio. Outro ponto é a duração do bloqueio, 60 segundos é um tempo curto e que habilita que o atacante volte a tentar possíveis senhas após o bloqueio. Sua empresa provavelmente tem um administrador ou até uma equipe de suporte, avalie se é necessário permitir que os usuários tentem tantas vezes suas senhas. Restringir essas duas propriedades pode salvar sua equipe de segurança de dores de cabeça consideráveis.

Agora vamos falar de uma funcionalidade legal, a lista de senhas personalizadas. É comum que as empresas tenham políticas de renovação de senha (nos melhores casos isso ocorre a cada 30 dias, mas conheço casos de empresas que permitiam a mesma senha por mais de 90 dias) e isso leva os funcionários a certo estresse quando o dia do vencimento da senha está próximo. “Qual senha devo colocar?”, “Já usei a senha … antes?”, “Se eu alterar apenas uma letrinha não terei problema algum.”, essas são frases que todo funcionário já pensou antes de trocar de senha. Esse recurso permite a criação de uma lista personalizada de palavras que deverão ser identificadas nas senhas dos usuários, não permitindo seu cadastramento.

O limite é de até 1000 palavras e não é necessário pensar em variações. O Entra ID identifica automaticamente se uma palavra da lista foi utilizada substituindo caracteres por valores parecidos (como um “a” por “@” ou um “o” por “0”) e também identifica valores que utilizam letras maiúsculas mescladas com minúsculas.

A lista de senha deve conter termos utilizados frequentemente na linha de negócio da sua empresa. A Microsoft já disponibiliza com o Entra ID Identity Protection uma lista global de senhas comumente utilizadas e vazadas nas dark webs, impedindo que os usuários tentem registrá-las.

Para cenários de autenticação híbrida, podemos estender as funcionalidades de proteção às senhas aos Domain Controllers do Active Directory. Ao ativarmos a opção “Proteção de senha para o Windows Server Active Directory” os DCs receberão o reforço das políticas implementadas no Entra ID, desde que os agentes necessários estejam configurados.

Por fim, não esqueça de ativar a execução da sua política. Manter a opção “Auditoria” ativa não implementará nenhum controle, os resultados de execução da política serão apenas logados e não implementados.

Pontos fortes de autenticação

Levando em conta a fragilidade da autenticação por usuário + senha, o Entra ID disponibiliza outros métodos que podem ser configurados e utilizados pela sua empresa. Alguns desses métodos são:

Microsoft Authenticator — aplicativo para smartphone;
Windows Hello for Business — solução integrada com estações de trabalho que permite autenticação via biometria e PIN (depende da capacidade técnica da estação de trabalho);
Autenticação por certificado — utiliza um certificado instalado na máquina para realizar a autenticação;
Chave de segurança FIDO — tokens físicos multi-plataforma (smartphones e notebooks).

Na seção “Pontos fortes de autenticação” você pode configurar alguns conjuntos de métodos que serão impostos aos usuários quando configurados através das políticas de acesso condicional (na seção “Conceder” da política de acesso condicional, você pode selecionar a opção “Exigir força de autenticação” e selecionar uma das opções presentes na lista).

Os administradores poderão escolher qualquer um dos métodos existentes e criar combinações de acordo com a necessidade.

Ao acessar o recurso pela primeira vez, você irá se deparar com 3 combinações padrão:

Vamos falar um pouco sobre as três:

Multifactor Authentication: pensado para criar uma camada extra de segurança sem um propósito específico, essa configuração contém uma lista de recursos que podem ser utilizados para implementação da política de MFA. Se você clicar sobre ela, verá todos os métodos que poderão ser utilizados pelo usuário;
Passwordless MFA: como explicado no início do texto, esse modelo retira a necessidade da senha utilizando outros recursos no lugar. Diferente do modelo anterior, temos apenas 4 recursos disponíveis para serem utilizados pelo usuário;
Phishing-resistant MFA: visando evitar o roubo de credenciais, os métodos resistentes à phishing foram atribuídos à essa coleção.

Você também pode criar suas próprias coleções de fatores de autenticação. Se por acaso sua empresa tenha alguma restrição sobre os fatores de autenticação que podem ser utilizados, essa é uma boa maneira de disponibilizar de maneira centralizada para seus usuários os recursos disponíveis.

Mais uma vez, espero que eu tenha conseguido te ajudar a proteger melhor seu ambiente. O Entra ID é uma ferramenta poderosíssima e que contém tantas capacidades de segurança que nós nos surpreendemos sempre com as possibilidades geradas por essa ferramenta.

Torço para que tenha gostado do texto e te vejo em breve.

Até logo!

Reforçando sua postura de identidade com o Defender for Identity

Wed, 06 Dec 2023 03:00:00 GMT

Como aprendemos no último artigo, ter uma ferramenta de CSPM no seu ambiente pode te economizar muitas dores de cabeça e acima de tudo, muito dinheiro! Visando proteger seu ambiente de IAM, um dos “módulos” do Microsoft Defender for Cloud é o Defender for Identity, direcionado exclusivamente para as soluções do Microsoft Entra e Active Directory. É sobre esse cara que falaremos hoje!

Pré-requisitos

Para iniciar o uso da ferramenta, o único pré-requisito que necessita ser cumprido, é a existência da licença Enterprise Mobility + Security E5 ou Microsoft 365 E5. A licença será necessária para habilitação da ferramenta, consequentemente permitindo seu uso para o Entra ID e também para o Active Directory.

Para um deployment híbrido, é necessário a criação de uma máquina virtual que executará o Defender for Identity Sensor. A recomendação é que essa máquina tenha no mínimo:

Sistema Operacional: Windows Server 2016 ou superior;
Microsoft .NET versão 4.7.

Lembrando que a instalação do sensor é feita no servidor do Active Directory Federation Services, então garante que seu componente esteja sendo executada em uma infraestrutura que atenda esses requisitos.

Muito mais que apenas um cloud-identity CSPM

Visando a cobertura de toda a suíte de produtos de identidade da Microsoft, o Defender for Identity foi projetado para proteger seu ambiente em nuvem e também seu ambiente on-premise, tornando seu deployment híbrido!

Por ser comum as empresas terem sua arquitetura de identidade no modelo híbrido, com tenants do Entra e domínios do Active Directory, o Defender veio para “cobrir” a segurança nesses dois ambientes. Por não ser uma solução SaaS/PaaS, para protegermos nossos componentes do Microsoft Active Directory, é necessária a instalação de um componente da solução que fará o monitoramento e a captura de eventos de segurança para serem processados no CSPM.

As especificações técnicas para instalação do Defender for Identity para proteger os componentes do Active Directory, podem ser visualizados neste link.

A arquitetura macro da solução será como a representada pela seguinte imagem, retirada das documentações oficiais da Microsoft:

![Architecture - Microsoft Defender for Identity | Microsoft Learn](https://learn.microsoft.com/en-us/defender-for-identity/media/architecture/architecture.png align=“left”)

Nossa solução em nuvem se comunicará com os tenants do Entra ID, com Provedores de Identidade terceiros e também com os componentes do Active Directory (Domain Controllers, Federation Services e Certificate Services).

Para termos dimensão do que podemos fazer em um ambiente híbrido, podemos consultar o registro de eventos do Active Directory. Não temos a mesma cobertura que das soluções em nuvem, porém teremos uma cobertura efetiva do ambiente on-premise!

Já que compreendemos os diferentes ambientes que podem ser monitorados, agora o que basta é operarmos o portal para entender como utilizar a ferramenta de maneira efetiva e começar a incrementar nossa postura de identidade!

Acessando o portal

Seguindo o padrão aplicado para soluções como o Microsoft Entra e o Microsoft Purview, o Defender for Identity também tem um portal central, que pode ser utilizado para todas as operações relacionadas à ferramenta.

Acessando security.microsoft.com você será direcionado para a página principal da plataforma (caso seja seu primeiro acesso, pode ser que seja solicitado que você entre com suas credenciais), que se parece com a seguinte:

Caso seja sua primeira vez acessando o portal, você será apresentado com um tutorial guiado sobre as capacidades existentes. São informações básicas, para que você não se sinta perdido ao inicar suas operações.

Este portal é do Microsoft 365 Defender, por isso encontramos diversas outras capacidades além das relacionadas à identidade (o defender for identity faz parte deste portal por conta das recentes atualizações nos produtos realizadas pela Microsoft, onde o Entra passou a fazer parte da família do Microsoft 365). Como o foco do artigo é essa solução em específico, vou deixar para abordadar as capacidades restantes em outro momento.

Navegação

No menu lateral podemos navegar entre as funcionalidades da solução. Atente-se à seção “Assets > Identity”, é nesta seção do portal que iremos conectar nosso Defender for Identity ao tenant do Entra ID. Apenas siga os passos indicados e você irá ativar a coleta de dados do seu ambiente.

A primeira análise pode demorar algumas horas, então é importante que após conectar ao ambiente, você aguarde que ele realize a análise e recupere as informações disponíveis!

Após receber as informações do seu ambiente, você será apresentado com uma grande tabela e uma série de filtros, que serão de extrema utilidade quando você quiser procurar informações sobre usuários específicos.

Algumas outras seções inclusas no portal são:

Detecção de ameaças - criação de queries para análise e identificação de atividades suspeitas relacionadas às soluções do Microsoft 365;
Secure score - postura de segurança do ambiente (CSPM);
Cloud apps - capacidade de CASB (Cloud Access Security Broker) do Defender, onde podemos conectar aplicações e realizar a aplicação de controles;
Incidentes e alertas - visão unificada dos alertas gerados pelas queries criadas.

Dica: navegue pelo portal, entenda as capacidades existentes, explore os artigos e treinamentos recomendados. Se sentir confortável com a interface e as capacidades fornecidas, potencializará o que você conseguirá fazer com a solução!

Recomendações

Após conectarmos nosso tenant e aguardarmos para o recebimento dos eventos e a geração das análises pré-existentes, chegou a hora de começarmos a compreender os “buracos” existentes nas nossas configurações.

Se navegarmos até “Secure Score”, conseguiremos ver a postura de segurança do nosso ambiente (gerada à partir do Benchmark da Microsoft), bem como as ações recomendadas para o ambiente, o histórico de mudanças na postura e também as métricas de segurança do ambiente.

Gostaria de chamar atenção para a segunda seção destacada, “Recommended actions”. Dentro dessa seção, temos os direcionamentos gerados pelo Defender for Identity para melhorar nossa postura de segurança. Vamos acessá-lo.

Somos apresentado com uma lista de ações recomendadas, ordenadas por padrão para que as com maior impacto no score sejam mostradas primeiramente.

Cada recomendação contém uma série de métricas que nos permitem avaliar seu estado. Métricas como “Points achieved” e “Status” nos permitem compreender se a recomendação foi atendida como um todo ou se apenas parcialmente.

Outras informações como por exemplo o histórico da recomendação, a data de realização e o produto afetado, podem ser visualizadas na mesma tabela.

Para visualizarmos apenas as recomendações relacionadas às nossas soluções de identidade, devemos filtrar a categoria para o valor “Identity”.

Ao clicar sobre qualquer uma das recomendações, um painel lateral será aberto ao lado direito do portal. Este painel conterá informações sobre a recomendação feita, histórico e sobre o plano de remediação da mesma. Vamos explorar essa parte na próxima seção do artigo!

Remediando o ambiente

Ainda com a seção da recomendação aberta, vamos analisar as informações que nos são fornecidas e como elas nos auxiliarão na remediação do ambiente.

Selecionei uma das minhas recomendações e com o painel aberto na seção “General” consigo visualizar algumas coisas:

Descrição da recomendação;
Progresso da implementação - métrica importante para monitorarmos a evolução do nosso ambiente;
Impacto nos usuários - outro ponto que deve ser analisado com “carinho”. As remediações visam proteger o ambiente, porém não podemos esquecer de quem faz tudo acontecer, os usuários das soluções finais. Eles serão impactados direta e indiretamente com as implementações feitas por nós.

Para as equipes que realizarão as atividades, a seção “Implementation” contém as informações mais valiosas:

Temos uma lista dos pré-requisitos necessários para a implementação da solução, bem como se já estão atendidos ou não;
Passo a passo da implementação - deixando o trabalho dos analistas muito mais simples, visto que não precisam realizar extensas pesquisas sobre como realizar a implantação;
Links extras - servem de apoio aos times para solucionar questões encontradas no processo de implantação.

Com esses mapeamentos realizados, os times podem começar a planejar as mudanças e a implantar as remediações!

Recomendação atendida

O exemplo que visualizamos acima é o de uma recomendação sem implementação. Uma vez identificada e com seu plano de remediação concretizado, a recomendação estará representada da seguinte forma:

Note que abaixo do título temos um “check” que demonstra o sucesso na implementação. Temos também ao lado direito o progresso da recomendação, seção muito útil quando estamos lidando com recomendações que devem ser realizadas em diversas etapas.

Do lado direito, abaixo de “Protects against” temos uma série de ataques que são mitigados ao acatar a recomendação. Ao clicar sobre qualquer um dos links, você será apresentado com uma breve descrição do ataque!

Atualizações do ambiente

Após implementar as recomendações no ambiente, você deve aguardar algumas horas para que seu progresso seja computado e tenha efeito no secure score. Os status das recomendações também podem demorar um pouco para aparecer, então aguarde algumas horas e cheque novamente sua lista de recomendações.

Extra: Windows Active Directory

Comentamos brevemente sobre a extensão do Defender for Identity ao Windows Active Directory e sua capacidade de expandir a proteção de identidade às soluções on-premise.

Em um ambiente que contém o Defender for Identity Sensor instalado e configurado para monitorar os componentes do AD, as recomendações irão aparecer junto das referente ao ambiente em nuvem!

Se a sua organização utiliza um modelo de implementação híbrido, é de suma importância a configuração dessa ferramenta para proteger seus usuários. Sua instalação e configuração é simples e os benefícios são diversos!

Espero que após a leitura desse artigo, você tenha compreendido a necessidade de se ter o CSPM monitorando as soluções de identidade.

Estou à disposição para responder qualquer dúvida e auxiliá-los de alguma maneira.

Até logo!

Tipos de identidades no Azure

Wed, 13 Sep 2023 03:00:00 GMT

Você conhece todos os tipos de identidades existentes no Azure? Para que eles servem e quais suas peculiaridades? Hoje vamos falar sobre as identidades de usuários e os diferentes tipos de identidade para os workloads!

Para que são usadas?

As identidades são utilizadas para identificar algo, seja um usuário ou um recurso/aplicação e para termos uma maneira de controlar o acesso aos recursos da plataforma.

Dentre as identidades existentes no Azure, temos 3 tipos:

Identidades de usuário;
Identidades gerenciadas;
Service principals.

O funcionamento dos 3 tipos é muito parecido, seu propósito é o mesmo porém as características são muito diferentes.

Nas próximas seções, vamos entender seus usos, suas características e como criá-las.

Usuários

Os usuários somos nós. Eu, você, nossos amigos e colegas que usam a plataforma. As identidades de usuário são utilizadas para representar uma pessoa no Entra ID. Esse usuário tem um nome, endereço de e-mail e também uma senha. Ele representa um funcionário, um terceiro, colaborador, ou qualquer outro usuário que vá acessar um recurso da plataforma.

Antes da criação as Service Principals era comum encontrarmos nos ambientes identidades de usuário que eram utilizadas por aplicações para controlar o acesso aos recursos. Com a criação das SPs, hoje temos uma alternativa mais simples e que faz mais sentido para esse caso de uso.

Um usuário não tem a característica dos outros tipos de identidade, ele deve representar apenas uma pessoa. Para representarmos aplicações e outros objetos, temos possibilidades distintas e que se assemelhem mais aos respectivos casos de uso.

Um usuário tem propriedades como: endereço, data de nascimento, cargo, informações pessoais (como número de telefone), entre outras informações, então para distinguirmos um user dentro de todos os outros objetos de identidade existentes na plataforma, podemos nos atentar à algumas informações como essas.

Managed Identity

As Managed Identities (ou Identidades Gerenciadas) são um tipo específico de identidade do Azure que nos permite autorizar o consumo de recursos da plataforma a partir de outros recursos. Ficou confuso? Vamos ao exemplo:

Na arquitetura apresentada acima nós temos uma Azure Functions recebendo requisições HTTP/HTTPS e inserindo os eventos dentro de um tópico do Azure Service Bus. Temos também uma outra Azure Functions consumindo os eventos inseridos no tópico pelo Function App A e inserindo algumas informações dentro de um Azure CosmosDB.

Como bem sabemos, é uma péssima prática de segurança deixar nossos serviços expostos abertamente para consumo, é necessário que tenhamos um processo de autorização para utilização dos mesmos. As Managed Identities nos permitem fazer uso do RBAC (Role-Based Access Control) para controlar o acesso aos recursos!

Uma vez que criamos um recurso e atribuímos a ele uma Managed Identity (isso pode ser feito em alguns recursos durante a criação e também após) nós poderemos navegar até os recursos de destino e atribuir à identidade uma role que nos permita operar aquele recurso. As imagens a seguir mostram como isso é feito.

Dentro da aba de IAM do recurso, nós:

Dessa forma nós temos um recurso que consome outro da maneira correta, sendo autorizado e seguindo as melhores práticas seguidas pelas empresas.

Um outro ponto importante para mencionarmos quando falamos sobre as Managed Identities são os dois tipos existentes.

System-Assigned x User-Assigned

O conceito das Managed Identities se mantém para qualquer um dos dois tipos, o que muda neles é o seu ciclo de vida.

As System-Assigned Managed Identities são criadas diretamente no recurso (no momento de criação dele ou após criado) e estarão atreladas a esse recurso por todo seu ciclo de vida. Isso implica em:

Enquanto o recurso existir, a identidade existirá com ele, caso ele seja excluído, a identidade será excluída junto.

As identidades System-Assigned podem ser utilizadas em apenas um recurso, não podendo ser reaproveitadas em qualquer outro recurso do mesmo tipo. Elas são dedicadas apenas ao recurso em que foram criadas e como mencionei anteriormente, serão afetadas quando o recurso tiver seu ciclo de vida encerrado.

Agora, as User-Assigned Managed Identities acabam por outro lado podendo ser utilizadas em mais de um recurso e não acompanharão todo o ciclo de vida do recurso.

Elas são criadas como recursos separados, podendo ser visualizadas dentro do Portal do Azure na página de Managed Identities ou pelo Cloud Shell utilizando o comando:

az identity list

O comando acima listará todas as identidades gerenciadas que você tem criadas na plataforma.

Para aplicações, as Managed Identities são as mais seguras e quando seu uso é possível, são as mais recomendadas, pela facilidade no gerenciamento e também pela ausência de um segredo. As System-Assigned Managed Identities fornece o maior conforto para os administradores pois o objeto será gerido completamente no seu recurso “pai”. As User-Assigned Managed Identities ainda que não façam o uso de segredos, perdem para as System-Assigned devido ao seu ciclo de vida ser gerenciado fora dos recursos, de maneira independente.

Service Principal

Chegando para nosso último tipo de identidade, temos as Service Principals.

O conceito das Service Principals é tão simples quanto os outros modelos, no final das contas ela é uma identidade utilizada para recursos não humanos, ou seja, quase tudo que não seja usuário, mas diferente das Managed Identities, elas são criadas e gerenciadas em um local e de uma maneira diferente.

As Service Principals são um objeto do Azure AD (Entra ID). Elas não tem um painel específico para elas onde podemos criar e gerenciar as mesmas dentro do Azure. Elas podem ser criadas através do Portal do Azure, Azure CLI, Powershell, Graph API, entre outras ferramentas.

Elas serão utilizadas para que aplicações possam se autenticar e ter o consumo dos recursos autorizado. Para realizar a autorização do consumo, poderemos utilizar as roles dos recursos para atribuir à Service Principal as permissões necessárias para realizar as operações desejadas.

Uma diferença importante das Service Principals para os outros modelos é a forma de autenticação. As Managed Identities não necessitam a gestão dos segredos da identidade, não é nem possível visualizar essa informação pois ela é gerida completamente pela plataforma. Já nas SPs nós precisamos nos preocupar com essa questão, pois para utilizar das roles atribuídas será necessário no nível do código inserir as informações da Service Principal para uso do SDK do recurso. Essas informações são:

Object ID — identificador único utilizado para identificar o objeto dentro do tenant;
Secret (opcional) — chave secreta utilizada como “senha” para autenticação das aplicações no consumo de recursos.

O secret está marcado como opcional pois também é possível autenticar uma Service Principal através de certificado, mas essa questão não é o escopo do nosso artigo.

A criação de uma Service Principal pode ser realizada através do Portal do Azure na seção do Azure AD em “App Registration” ou pode ser feita através do seguinte comando no Cloud Shell:

az ad sp create-for-rbac --skip-assignment

O comando acima cria uma Service Principal e retorna no próprio output do Cloud Shell as informações do objeto criado. Com a propriedade “ — skip-assignment” não é necessário atribuir uma role à identidade no momento de criação.

Dentro dos tipos de identidade de aplicação que apresentamos, essa é a que gera mais riscos de segurança ao seu ambiente, por conta da necessidade de gerenciamento do segredo (quando utilizado) e por conta da necessidade do gerenciamento do ciclo de vida. Como as SPs não contém nenhum tipo de vínculo com o recurso que a utilizará, é necessário uma boa gestão desse objeto visando evitar que suas credenciais caiam em mãos erradas!

Quando falamos sobre estratégia Zero Trust é importante pensarmos nos temas relacionados à identidade. Para garantir o Privilégio Mínimo é necessário gerenciar corretamente as identidades e as permissões atribuídas a elas.

Espero que tenha gostado do texto e que eu tenha conseguido te explicar as diferenças entre os modelos, seus usos, benefícios e também possíveis riscos à segurança do seu ambiente.

Estou à disposição para responder quaisquer perguntas que você tiver.

Até logo!

User Risks e Sign-in Risks - Microsoft Entra ID

Wed, 03 Jan 2024 03:00:00 GMT

Com as identidades sendo a primeira barreira de defesa sob o controle do cliente em qualquer ambiente em nuvem, precisamos estabelecer políticas efetivas de segurança que considerem diferentes níveis de risco apresentados ao ambiente e que coletem a maior quantidade possíveis de informação. Pensando nisso, podemos potencializar a segurança de nosso ambiente com o Microsoft Entra ID Protection!

Entendendo a primeira barreira de proteção

Como mencionado na abertura do artigo, as identidades são a primeira barreira de proteção nos ambientes em nuvem. Mas o que isso quer dizer?

Nos ambientes em nuvem a segurança física do ambiente não é preocupação do cliente. Essa responsabilidade é 100% exclusiva do cloud service provider. No modelo de defesa em profundidade (defense in-depth) a primeira camada é representada pela camada física. Não tendo influência sobre ela, o cliente pode desconsiderá-la da jogada e iniciar a proteção de seu ambiente pela próxima camada, a de identidade.

O acesso aos nossos recursos em nuvem é feito sempre à partir de um IdP (Identity Provider). Por padrão, os IdPs utilizados são os do próprio provedor de nuvem (ex: Azure - Entra ID, AWS - AWS IAM), porém é extremamente comum que em uma arquitetura empresarial multi-cloud, a gestão de acesso nos ambientes seja feita por um IdP centralizado, facilitando a gestão dos acessos e seguindo as melhores práticas de IAM.

Utilizando o Entra ID como IdP empresarial

Considerando o Microsoft Entra ID como o IdP de escolha da sua empresa, você poderá usufruir das capacidades de segurança que nele estão presentes. Capacidades essas que deixarão os acessos aos seus ambientes em nuvem e às suas aplicações federadas muito mais seguros!

Na arquitetura apresentada acima, temos uma visão macro sobre como é representada a gestão de um ambiente multi-cloud com um IdP centralizado. Não entrarei nos detalhes técnicos de configuração, provisionamento de funções (roles) e de outros objetos, mas com uma solução gerenciando os acessos aos múltiplos ambientes com apenas um conjunto de credenciais, nós teremos não apenas uma gestão mais eficiente do ciclo de vida das identidades, mas como também poderemos identificair os riscos atrelados aos acessos e às credenciais em aplicações de diferentes domínios e em diferentes ambientes!

Dentro do ID Protection os riscos são classificados como riscos de usuário e riscos de login. Nas seções abaixo você terá mais informações sobre as identificações feitas e sobre os riscos em si.

Algumas detecções de riscos necessitam de uma licença P2 atribuída, enquanto outras são fornecidas de maneira gratuita pela Microsoft.Algumas detecções são feitas apenas no modo online, enquanto outras ocorrem de maneira offline.

Os parágrafos abaixo conterão tabelas com as informações sobre os riscos. Essas tabelas foram retiradas desta documentação oficial da Microsoft. As tabelas apresentarão em 3 colunas, respectivamente: a detecção, tipo de detecção (offline ou real-time) e o tipo de licença necessária.

Outro fator importante que devemos citar é que por mais que estejamos falando dos riscos identificados e mitigados à partir do Entra ID Protection, algumas detecções citadas abaixo necessitam de outras soluções para garantir sua aplicabilidade (soluções como o Defender for Endpoint).

User Risks

Os riscos atrelados aos usuários dizem respeito à suas credenciais e também às atividades realizadas na conta.

Comentando sobre alguns dos riscos apresentados acima:

Atividade anômala: é detectado que as operações realizadas na conta do usuário não são comuns ao seu padrão de uso. Isso pode indicar um possível uso indevido das credenciais daquele usuário;
Credenciais vazadas: como parte do Entra ID, a Microsoft realiza varreduras em recursos na internet para identificar credenciais vazadas em explorações de vulnerabilidades bem sucedidas;
(Bônus) Inteligência contra ameaças: capacitando as capacidades de defesa do Microsoft Entra, a solução utiliza de modelos de machine learning para identificar vetores de ataque que apresentam ameaças à sua conta.

As detecções de login acontecem quando uma tentativa de login é considerada arriscada pela análise da solução.

Como fizemos com os user risks, vamos comentar um pouco sobre alguns dos riscos mencionados acima:

Viagem atípica: utiliza informações sobre a geocalização do usuário de de outras atividades realizadas na plataforma para compreender se os diferentes acessos vem de destinos onde seria impossível o transporte durante o período de tempo aplicado;
Token anormal: identifica o uso indevido e anormal de um token de acordo com as características do mesmo. Uma das detecções realizadas é o caso de token replay;
Pulverização de senha (password spray): múltiplas tentativas malsucedidas de login com credenciais diferentes podem indicar um ataque do tipo password spray.;
Acesso em massa a arquivos confidenciais: esse é um dos exemplos de risco detectado com a ajuda de uma solução auxiliar, nesse caso o Defender for Cloud Apps. Essa solução identifica os acessos aos recursos protegidos e sensibiliza o ID Protection.

Severidade dos riscos

Antes de seguirmos para a aplicação das políticas é importante entendermos como o Entra ID classifica a severidade dos riscos.

Tanto os riscos de usuário quanto os riscos de login, são classificados como baixo, médio e alto. Essa classificação é dada de acordo com a avaliação dos pontos de informação coletados pela plataforma e análisado pelos algoritmos de detecção de ameaças implementados pela Microsoft.

Aplicação das políticas

Após compreendermos o modelo de classificação dos riscos, seguiremos para a aplicação das políticas, tanto no modelo antigo quanto no modelo novo.

Versão legado

Hoje em dia essas configurações são todas feitas dentro das políticas de acesso condicional. Antigamente, dentro do Identity Protection tínhamos uma seção específica para criação dessas políticas. Essa seção ainda está ativa, porém ao acessá-la, somos apresentados com o seguinte aviso:

Aviso esses que menciona a migração das políticas para o Conditional Access.

Neste modelo, era configurada 1 política de user risk e 1 política de sign-in risk. Nós selecionávamos os usuários e grupos que iriam sofrer os impactos da política, o risco dela (baixo, médio ou alto) e o controle. A grande diferença entre a política de user risk e de sign-in risk é: na detecção de um risco de usuário nós podíamos bloquear o acesso daquele usuário ou aprovar o acesso e requerer uma troca de senha, para as detecções de risco de login era possível bloquear o acesso ou aprovar e requerer o uso de um segundo fator de autenticação.

Neste modelo, os times de segurança tinham pouquíssima flexibilidade de proteção e poucos recursos para proteger da maneira correta o ambiente.

Versão atual

Nos modelos atuais, utilizamos as políticas de Acesso Condicional (Conditional Access policies) para implementar os controles de segurança de acordo com a severidade do risco identificado.

Dentro das políticas de acesso condicional, na seção “Conditions” nós conseguimos configurar qual a severidade do risco e qual tipo de risco aquela política deve monitorar e remediar, como mostra a imagem abaixo.

Somado a isso, nós temos a extensa granularidade de controles que podem ser impostos ao usuário. Controles como:

Uso de multi-factor authentication;
Acesso feito de dispositivo compliant;
Mudança de senha.

Abaixo uma imagem com todos os controles aplicáveis.

Conseguimos aplicar inúmeros controles a mais, isso somado a outros fatores como a localização de onde o usuário está fazendo os acessos, as aplicações acessadas, as plataformas usadas e muito mais!

Melhores práticas

De acordo com as documentações oficiais da Microsoft, para riscos de usuário considerados alto, você deve exigir a troca de senha. Essa implementação conta por padrão com a exigência do uso de MFA antes da atualização da credencial.

Para riscos de login identificados como médio ou alto, o uso de MFA já é suficiente.

Essas são recomendações genéricas e aplicáveis à maioria dos cenários. É importante que você não se prenda apenas ao que diz a documentação e analise seu caso de uso.

Algumas aplicações de negócio podem oferecer acesso à recursos de extremo valor, logo as políticas de segurança aplicadas sobre o acesso à essas aplicações deve ser diferente das aplicações de uso geral. Múltiplas camadas de controle de acesso devem ser aplicadas, bem como diferentes níveis de remediação de acordo com o risco detectado.

É essencial que as suas políticas de acesso condicional estejam bem estruturadas para tratar os casos genéricos e que se enquadram na maioria dos incidentes identificados, porém você deve se manter atento às exceções, aplicações que apresentam alto risco aos ativos da sua empresa. Essas exceções devem ser tratadas com extrema cautela e segurança reforçada!

Depois deste texto, você não apenas está capacitado para promover a segurança do seu ambiente mas também compreendeu a necessidade de se ter um olhar crítico para cada ambiente, não apenas seguir as recomendações padrão.

Espero que tenha gostado do conteúdo e me coloco à disposição para responder suas dúvidas.

Até logo!

Autenticação no consumo de blobs com o Microsoft Entra

Tue, 26 Dec 2023 03:00:00 GMT

As storage accounts estão presentes em grande parte das arquiteturas em nuvem pública, devido a sua elasticidade, facilidade no uso e diversidade de recursos. Como qualquer outro recurso, a segurança é prioridade!

Além de controlar a qualidade dos recursos que são inseridos na sua storage account, é essencial que o controle de acesso à esses recursos seja realizado de maneira correta e seguindo as principais práticas recomendadas. Por isso, hoje vamos aprender como configurar a autenticação do Entra para as Storage Accounts.

Tipos de autenticação para Storage Accounts

Quando estamos planejando a criação das nossas Storage Accounts, é importante saber que temos mais de um modelo de autenticação disponível para proteger o consumo dos recursos. Os modelos existentes são:

Access Keys;
Shared Access Signature;
Entra ID Authentication.

Os três modelos tem suas vantagens e desvantagens, como tudo na vida, então é importante que você escolha uma opção que cumpra seu papel de negócio, ou seja, permita que o objetivo do projeto seja atingido, mas também que seu ambiente esteja protegido e seus recursos seguros.

Access Keys

Toda storage account é criada contendo 2 Access Keys, essas sendo necessárias para permitir o acesso aos blobs quando não estamos utilizando a autenticação do Entra.

Ao acessar sua storage account, você pode consultar suas access keys na blade lateral, disponível à esquerda da sua tela. Você encontrará algo parecido com isso:

Ao clicar sobre “Show” à direita do input “Key”, você será apresentado com o valor da sua access key. O valor “Connection string” é utilizado quando estamos desenvolvendo alguma aplicação que realizará acesso aos blobs armazenados na storage account.

Essas informações são extremamente sensíveis. Quem tiver posse de uma das chaves da sua storage account, pode trazer ao seu ambiente e aos seus recursos grande risco. Não as compartilhe com ninguém!

As access keys podem ser utilizadas para permitir o acesso direto aos blobs, porém também são necessárias para habilitação do recurso que falaremos à seguir.

Shared Access Signatures

As Shared Access Signatures ou apenas SAS, são URIs criadas com diversos controles e assinadas por uma das access keys. Essas URIs visam liberar acesso público à certos recursos da storage account.

Com esses recursos, podemos limitar o escopo de acesso, os objetos que poderão ser acessados, as operações realizadas, determinar uma data de validade da URI de acesso e também controlar a origem do acesso através de endereços e ranges de IP.

Note que caso o endereço de IP de origem não seja cadastrado, qualquer usuário que estiver em posse da URI, poderá acessar o recurso destinado.

Outros dois pontos a serem observados são: o escopo de acesso e as operações permitidas. Caso sejam configurados errado, o usuário poderá acessar mais recursos que deveria e também poderá excluir ou modificar os objetos existentes nos contêineres da storage account.

Entra ID

Utilizando o Microsoft Entra, nós podemos utilizar de todas as capacidades de segurança fornecidas pela ferramenta para proteger o consumo dos nossos recursos.

Utilizando o acesso baseado em função (Role Based Access Control), podemos atribuir permissões aos usuários de acordo com a necessidade, tendo a tranquilidade de que apenas usuários conhecidos acessarão os recursos da storage account.

Com a autenticação do Entra, o usuário se autenticará e a plataforma receberá um access token, esse utilizado para verificar as permissões no escopo de acesso requisitado.

Esse modelo apresenta a melhor opção de segurança, pois permite a aplicação do zero trust através do controle de acesso através de função.

Qual modelo eu devo escolher?

Entendemos os 3 modelos existentes, agora chegou a hora de decidirmos qual é o mais adequado.

Microsoft Entra ID - oferece as melhores capacidades de segurança, permite o controle das operações e do escopo, garante que o acesso aos recursos venha apenas de usuários (ou service principals) autorizados e não requer a publicação do objeto para a internet. É a melhor solução na maioria dos casos!

Shared Access Signature - permite o controle das operações e do escopo, podemos configurar um período para a expiração daquele acesso e podemos limitar o acesso à partir de endereços IP específicos. Tem como ponto negativo a dependência das access keys. Caso o acesso público ao objeto seja necessário, essa é a melhor opção.

Access Keys - por controlar todos os acessos aos objetos da storage account, o uso das access keys oferece grande risco ao ambiente caso caiam nas mãos de agentes indevidos. Não tem seu uso recomendado, apenas em cenários de exceção onde os dois modelos anteriores não são adequados.

Apresentados os cenários e os direcionamentos de uso, vamos comentar brevemente sobre como a autenticação com o Entra pode ser configurada.

Configurando a autenticação com o Entra

Definido o uso do Entra para autenticação no consumo dos seus blobs, podemos facilitar a vida dos nossos usuários ao configurarmos a autenticação através do Entra por padrão para acesso através do Portal do Azure.

Habilitando a autenticação através do Entra por padrão

No momento da criação da storage account, você pode selecionar “Default to Microsoft entra authorization in the Azure portal” na aba “Advanced” para que em todas as requisições de acesso aos blobs, a autenticação através do Entra seja a primeira a ser tentada.

Caso não tenha selecionado a opção no momento de criação, você pode também navegar dentro da sua storage account até “Configuration” e ativar a opção.

Utilizando o RBAC

Utilizando as built-in ou custom roles, poderemos aplicar o Zero Trust aos acessos, mantendo nosso ambiente cada vez mais seguro.

Para vizualização dos objetos via Portal do Azure, a identidade precisará de uma role que permita a visualização da storage account (no mínimo) e de uma que permita a leitura do conteúdo existente dentro dela. Aplicando o privilégio mínimo, as duas roles necessárias para habilitar a vizualização são: Reader com escopo na storage account e Storage Blob Data Reader com escopo na storage account.

Para acesso dos objetos à partir da sua aplicação, utilizando uma Managed Identity ou Service Principal, não é necessário uma role que permite a visualização do recurso. Você pode fornecer acesso apenas ao contêiner onde os objetos se encontram, seguindo assim o Princípio do Privilégio Mínimo.

Nas aplicações, o uso da MSAL (Microsoft Authentication Library) facilitará as interações com o Entra, permitindo que você concentre seus esforços no desenvolvimento das funcionalidades de negócio!

À partir de agora você é capaz de proteger suas storage accounts da melhor maneira possível e não prejudicando a usabilidade e experiência dos seus usuários.

Espero que tenha gostado do texto. Estou à disposição para responder quaisquer dúvidas que tiver.

Até logo!

Uso seguro do Azure Key Vault

Wed, 06 Mar 2024 03:00:00 GMT

No último artigo falamos sobre o que são os cofres de senha, apresentamos o Azure Key Vault, comentamos sobre algumas das suas caracterísicas e sobre sua arquitetura. Hoje, olharemos para ele com um olhar de cibersegurança, pensando em como podemos realizar o acesso seguro a esse componente quando estivermos desenvolvendo nossas aplicações.

Exposição segura

Por ser uma solução PaaS (Platform as a Service), o Azure Key Vault permite que seus usuários se beneficiem do uso dos Service Endpoints e Private Endpoints, recursos disponíveis no Azure e que incrementam a segurança do tráfego roteado para certos recursos. A grande diferença entre eles:

Service Endpoints: permitem a restrição do consumo do serviço através das virtual networks do Azure. O recurso (Azure Key Vault) identifica que o tráfego está vindo da sua virtual network e avalia o consumo de acordo com as políticas cadastradas. Com essa funcionalidade habilitada, o tráfego será roteado através do backbone global da Microsoft até o recurso de destino, porém o endpoint utilizado para acessar o componente, é o endpoint público;
Private Endpoints: suportados pelo Azure Private Link, os private endpoints oferecem uma maneira de deixar o consumo dos seus recursos completamente privado. O tráfego não será direcionado para fora da Virtual Network em momento algum, permanecendo completamente privado o caminho todo.

O desenho acima mostra de maneira simplificada a utilização dos private endpoints no consumo do Azure Key Vault.

Para os desenvolvedores, o método de consumo do recurso não mudará. Mesmo com o uso do private endpoint se faz necessário a utilização do SDK para interação com o recurso e das identidades para autorização do consumo. Os private endpoints "modificam" o funcionamento do recurso na camada de networking, não havendo impacto nos times de desenvolvimento.

Sendo o principal recurso para proteção à níve de plataforma, uso dos private endpoints pode gerar muitos benefícios para as organizações em geral. Alguns deles são:

Redução da superfície de ataque: pelo fato do vault estar protegido do acesso externo e disponível apenas para os recursos existentes dentro da Virtual Network em questão, a possibilidade de vazamento de informações sensíveis é reduzida drásticamente;
Restrição/Controle do Uso: permitindo o controle de acesso via origem, os times de segurança conseguem controlar quem pode acessar o cofre também na camada de rede, garantindo a proteção do consumo além da camada de identidade.

Ainda na camada de networking, o consumo do recurso pode ser protegido através do Resource Firewall, funcionalidade disponível no vault e que nos permite restringir o acesso à ranges de IP e endereços IP específicos.

Quando falamos de proteção de plataforma, não temos muito a explorar além da camada de networking, porém quando pensamos nas ações relacionadas à identidade, é possível controlarmos o acesso de muitas outras formas, como veremos na próxima seção.

Uso de identidades

“Pulando” de camada, temos as identidades, que são a porta de entrada para qualquer ambiente em nuvem.

Dentro do Azure, nós temos diferentes tipos de identidade que podem ser utilizadas na autorização do consumo dos recursos da plataforma. Em sua grande maioria, a função delas é a mesma, o que diferencia é o modelo de uso:

Managed Identities: é o modelo mais seguro, porém o mais “limitado”. As Managed Identities só podem ser utilizadas quando estamos autorizando um recurso da plataforma a consumir outro (ex: uma aplicação sendo executada via Azure Functions precisa consumir uma secret existente em um Azure Key Vault, para facilitar a gestão dessa identidade, nós atribuímos uma managed identity ao recurso consumidor e então atrelamos as permissões necessárias à ela);
Service Principals: sendo o modelo que oferece mais flexibilidade, as Service Principals são utilizadas nos casos onde não conseguimos/devemos autorizar um sserviço de plataforma a consumir o recurso em questão (ex: uma aplicação executada no Azure Kubernetes Service precisa consumir o Azure Key Vault para recuperar uma chave utilizada para criptografar os dados manipulados pela solução, como a aplicação executada no AKS não é um recurso de plataforma “tangível”, utilizamos as Service Principals);

Caso queira saber um pouco mais sobre os tipos de identidade existentes no Azure, tenho esse artigo aqui no blog: Tipos de Identidades no Entra ID.

Os dois tipos de identidade podem ser utilizadas para consumir o Vault, porém caso as service principals sejam escolhidas, temos 2 maneiras de realizar a autenticação:

Certificados: dentro do Entra ID é possível realizar o upload de um certificado para ser utilizado como a credencial da identidade para a autenticação;
Secrets: no momento de cadastramento da identidade, podemos criar uma secret para servir de “senha”, funcionando da mesma maneira que o certificado.

O grande impasse entre utilizar certificados e segredos é a necessidade de se ter um processo bem estabelecido para realizar a atualização/rotação dessas credenciais, que podem gerar problemas ao ambiente se não forem bem gerenciadas.

O uso das Managed Identities é recomendado pelos guidelines de segurança da Microsoft, porém sua limitação à autorização apenas através dos recursos de plataforma restringem sua utilização. Em casos onde não se é possível utilizar esse tipo de identidade, devemos seguir com as service principals e o fator de autenticação de sua escolha.

RBAC

Seguindo para a última sessão do texto, temos o RBAC (Role Based Access Control), recurso que falamos no artigo anterior (neste link).

O modelo de RBAC do Azure Key Vault é um pouco diferente do modelo encontrado nos outros recursos do Azure. Primeiro, o vault é divido em management plane e data plane e o controle de acesso é realizado de maneira segregada nos dois paineis.

Essa arquitetura permite que os times de desenvolvimento tenham acesso exclusivamente aos dados que serão utilizados por eles. Com a criação das políticas de acesso ao data plane, todos os recursos exisitentes no vault e não pertencentes ao projeto em questão, estarão seguros dos acessos indevidos possívelmente realizados por outras equipes e até por agentes mal intencionados.

Essa seção é apenas uma menção ao modelo de RBAC que falamos no artigo anterior. Se desejar aprender um pouco mais sobre esse modelo, recomendo a leitura!

Os vaults são extremamente úteis para armazenar informações sensíveis e sua segurança deve sempre ser pensada meticulosamente.

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

Até mais!

Utilizando o “What if” do Entra ID Conditional Access

Tue, 01 Aug 2023 03:00:00 GMT

No último texto falamos sobre a criação das políticas de acesso condicional e como elas podem enriquecer a segurança do seu ambiente. Hoje vamos falar sobre uma funcionalidade que nos permite testar a efetividade das políticas sem gerar impacto algum aos usuários.

É comum que os times de segurança da sua empresa se preocupem com o funcionamento das políticas existentes. É mais comum do que parece essa “desconfiança” na configuração e isso é resultado de duas coisas:

falta de conhecimento da ferramenta;
ausência de testes.

O primeiro motivo só pode ser superado com treinamento e capacitação dos funcionários da empresa.

O Entra ID é uma solução utilizada globalmente por empresas dos mais diferentes ramos de atuação e dos mais diferentes tamanhos, além de ter sido criada por uma empresa histórica no mundo da tecnologia e que até hoje consta como uma das empresas mais importantes do mercado.

Agora, se a sua desconfiança é resultado da falta de testes e provas de que as políticas de acesso condicional realmente funcionam, esse artigo é pra você!

O “What If”

Como comentado anteriormente, esse recurso do acesso condicional permite testar as políticas desejadas com certas origens, destinos e parâmetros específicos. Essa granularidade nos permite cobrir os mais diversos cenários de acesso.

Se voltarmos ao texto de criação de políticas podemos analisar quais as “variáveis” captadas pelo Entra ID e disponibilizadas para construção das políticas. Essas variáveis são:

Usuários, grupos e recursos (identidades) afetados;
Recursos de destino (aplicações, contextos de autenticação e ações do usuário);
Condições (riscos de login, riscos de usuário, sistema operacional do dispositivo de acesso, local, aplicativo cliente e filtros);

Todas essas variáveis estão disponíveis para a construção do seu teste.

Utilizando o recurso

No portal do entra, no painel de acesso condicional (proteção > acesso condicional) ao entrar na aba de políticas, você vai se deparar com as seguintes opções:

Painel horizontal de opções na aba de políticas

Clique no botão escrito “What If” e será mostrado o seguinte formulário:

Neste formulário vamos preencher as informações que gostaríamos que fossem testadas contra as políticas de acesso condicional existentes.

Se você desejar saber quais políticas existentes afetam acessos de risco médio, você pode filtrar o “risco de entrada” para o valor médio.

Ou talvez queira identificar quais políticas se aplicam ao presidente e aos diretores da sua empresa, para isso você pode selecioná-los em “Identidade do Usuário ou Carga de trabalho” ou escolher um grupo específico que contenha todos eles.

Resultado

Após preencher os campos, de maneira que os usuários escolhidos sejam atingidos pelas regras, basta realizar o teste clicando no botão azul no final da página.

É importante lembrar que nas políticas de acesso condicional, nós podemos selecionar objetos para serem incluídos e para serem excluídos também. Por esse motivo, ao confirmar os campos preenchidos e solicitar a verificação das políticas, nós receberemos dois resultados:

Políticas que serão aplicadas

A política acima será aplicada baseada nos filtros indicados no formulário.

Podemos clicar sobre a política e teremos mais detalhes sobre suas configurações.

Ao final da linha, podemos ver também o estado da política. Essa em questão está em “somente relatório”, ou seja, não está impactando o acesso dos usuários, mas apenas avaliando se a atividade seria impactada pela política em questão.

Políticas que não serão aplicadas

Para as políticas que não terão impacto algum no usuário, temos uma aba dedicada.

Essas políticas podem ser mostradas simplesmente por não terem nenhum tipo de condição que se aplique aos filtros ou pois os usuários selecionados estão na condição de “exclusão” da política.

Além do nome da política (que também é um link para a própria), podemos visualizar o motivo da política não ser aplicada e como na aba anterior, o estado em que a política se encontra.

É comum que grandes empresas tenham grandes quantidades de políticas criadas. Isso se dá por diversos motivos, como a mudança nas estratégias de segurança da empresa ou até devido ao cumprimento de normas internas.

Quando se deparar com um acesso indevido ou quando um usuário estiver tendo dificuldades de acesso por algum tipo de restrição das políticas, lembre desse recurso. O “debug” facilitará muito o trabalho dos administradores que estiverem tentando entender o motivo do acesso se comportar desta forma.

Espero que a apresentação dessa simples funcionalidade o ajude a economizar tempo na hora de testar seus acessos.

Até logo!

Utilizando os templates das Políticas de Acesso Condicional do Entra ID

Wed, 25 Oct 2023 03:00:00 GMT

Visando facilitar a aplicação dos controles de acesso, o Entra ID disponibiliza uma série de templates com os controles mais “comuns” para facilitar sua aplicação. Hoje vamos conhecer a lista de templates e aplicá-las ao nosso ambiente.

Introdução

Os benefícios que as políticas de acesso condicional geram para a empresa já são conhecidos, porém para empresas que estão iniciando sua utilização, muitas vezes os times responsáveis pela segurança dos ambientes não sabem por onde começar. Os novos templates de políticas são um bom começo.

Visando a implementação dos controles que reforçam a aplicação de padrões de segurança (como o zero trust), os templates permitem uma configuração simples e rápida para os times, com controles “básicos” para reforçar a segurança no seu ambiente.

Hoje vamos falar sobre as categorias das políticas existentes, alguns controles que elas reforçam no ambiente, como aplicar algumas dessas políticas e os benefícios de tê-las configuradas.

Para saber mais sobre as políticas de acesso condicional, acesse este link!

Visualizando as políticas

Acessando o Portal do Entra e navegando até a aba de Conditional Access (abaixo de Protection) nós nos encontramos com a opção “Create new policy from templates”. Clique sobre ela e vamos estudar as políticas existentes.

Logo de início, nos deparamos com a seguinte imagem:

Através deste painel nós podemos visualizar as categorias nas quais as políticas foram divididas e já temos também uma breve descrição dos controles aplicados por cada uma.

Vamos aproveitar essa política que está selecionada e clicar sobre a opção “View”.

Você também pode realizar o download do template em formato JSON, formato utilizado pelo Entra ID para exportar e importar novas políticas.

À direita da sua tela uma seção foi aberta. Essa seção demonstra as configurações realizadas na política. As sessões demonstradas são as mesmas encontradas no formulário que utilizamos para construir as políticas do zero.

Essa política que selecionamos aplica um controle básico em contas com privilégios de administrador. Contas que contém alto nível de privilégio de acesso aos recursos, devem ser protegidas por camadas adicionais além do login. Essa política exige que usuários que contém as roles mostradas abaixo realizem a autenticação multi-fator disponível para eles.

Se navegarmos até a opção “Emerging threats” nós veremos que temos apenas uma opção disponível. O template “Require phishing-resistant multifactor authentication for admins” visa aplicar controles que garantem a utilização da autenticação multi-fator por administradores, porém através de mecanismos resistentes à phishing.

Phishing é uma forma de ataque que visa obter as credenciais de certo usuário. Isso pode ser feito de diversas maneiras, como: e-mails enganosos, engenharia social, entre outras maneiras.

Os mecanismos de autenticação resistentes a phishing disponíveis no Entra ID são: certificados, FIDO2 key e Windows Hello for Business. Essa política de acesso condicional exige que os usuários com roles privilegiadas realizem a autenticação multi-fator utilizando um desses métodos. Se aplicada, o usuário com privilégios NÃO conseguirá utilizar nenhum dos outros métodos para autenticação multi-fator existentes no Entra, apenas os aceitos por essa política.

Esse controle sobre quais dispositivos de autenticação multi-fator o usuário poderá utilizar é feito através de um recurso chamado Authentication Strenghts, que permite agrupar diferentes fatores de autenticação.

Vimos que as políticas existentes já nos permitem aplicar uma série de controles básicos ao nosso ambiente. Agora vamos ao simples processo de ativação de uma delas.

Aplicando uma política em seu ambiente

Após escolher da lista de funções disponível a que você deseja aplicar, basta selecionar a opção “Review + Create”. Você será levado para uma página que o permitirá alterar o nome da política e também selecionar o seu estado.

É importante deixar claro que para conseguir ativar uma política de acesso condicional, é necessário que o security defaults esteja desativado em seu tenant, caso contrário a criação da política só poderá ser feita se estiver desligada ou no estado report-only.

Ao clicar sobre o botão “Create” a sua política estará criada e no estado que foi definido!

Caso deseje testá-la, você pode utilizar um recurso do Entra chamado “What If”. Te explico tudo que precisa saber sobre esse recurso e como utilizá-lo neste artigo.

Pronto! Em questão de segundos você fortaleceu a segurança do seu ambiente, precisando de apenas alguns cliques e sem a necessidade de inúmeras reuniões para criação e configuração das políticas.

As políticas de acesso condicional realmente são extremamente importantes para a garantia de segurança no ambiente em nuvem pública, então espero que este artigo tenha agregado valor à sua jornada e acima de tudo, tenha permitido que você reforçasse a segurança do seu perímetro.

Até logo!

Windows containers in Kubernetes

Tue, 17 Dec 2024 03:00:00 GMT

Nós sabemos que boa parcela da infraestrutura que suporta as aplicações que mais utilizamos é baseada em sistemas Microsoft. Com o advento das tecnologias cloud native como o kubernetes, esses componentes parecem ter ficado para trás, porém isso não é totalmente verdade. Visando possibilitar a modernização dos sistemas baseados em windows, temos no kubernetes o suporte para Windows Containers, e é sobre ele que iremos falar hoje!

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.

Gosto de trazer esse ponto logo de cara pois a grande maioria dos clusters é composto apenas de nodes que executam linux. É importante garantir a execução de pelo menos um node windows para possibilitar a criação dos recursos necessários.

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!

Zero Trust: identity at the center

Wed, 01 May 2024 03:00:00 GMT

Nas últimas semanas falamos sobre um tema constantemente abordado nas discussões sobre cibersegurança, o Zero Trust. Ao nos aprofundarmos no tema, percebemos que entre os três pilares que regem o conceito, temos 1 propriedade em comum, as Identidades. Todos os controles implementados avaliam de alguma maneira a identidade do consumidor, sendo ele uma aplicação ou um usuário. Hoje vamos falar sobre como as identidades se aplicam dentro do conceito e quais controles podemos aplicar utilizando o Microsoft Entra ID.

Importância do Zero Trust

![](https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/RWIwt2_tbmnl_en-us?scl=1 align=“center”)

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!

Markdown Example

Thu, 09 May 2024 00:00:00 GMT

This is an example blog post!

Heading 1

This is an example lil thingy wow look at me!

Heading 2

Heading 3

Heading 4

Heading 5

Heading 6

I’m baby tumblr deep v franzen umami hammock scenester retro VHS, pop-up truffaut tacos polaroid gochujang. Jean ugh vexillologist snackwave keytar williamsburg bitters pinterest. Photo booth schlitz quinoa tbh edison bulb vexillologist occupy single-origin dreamcatcher. Chartreuse meggings gochujang synth. Narwhal green juice snackwave thundercats kickstarter XOXO deep v.

numbered
list
of
items

Hello there, welcome to my list.

list
of
items
- nested
- list
wow

Hello, babies, I think that you need to understand what a long line length is

V franzen umami hammock scenester retro VHS, pop-up truffaut tacos polaroid heirloom gochujang.

hello
these
are
tasks

bold italic bold and italic

// This is an example of some React

useEffect(() => {
	let isCurrent = true;

	if (isCurrent === true) {
		fetch("...");
	}

	return () => {
		isCurrent = false;
	};
}, []);

Language-less:

useEffect(() => { // wow
  let isCurrent = true;

  if (isCurrent === true) {
  	fetch('...')
  }

  return () => {
  	isCurrent = false;
  }
}, [])

A horizontal line:

Some inline code between normal text

A blockquote, lorem ipsum dolor

Just some normal text, wow.

Example table	Example things
What	how
Why	when

Okay, that’s it! Good luck! Write more! Follow your dreams!

Exposição pública de objetos, é uma boa ideia?

Tue, 12 Mar 2024 00:00:00 GMT

Nós, engenheiros/arquitetos de nuvem pública, estamos acostumados com os benefícios gerados pelo uso de uma solução de storage (como o Azure Storage e o AWS S3). Comumente considerado um benefício, a possibilidade de exposição pública dos objetos permite que a solução aproveite a escalabilidade e alta disponibilidade nativa do recurso, mas como fica a segurança? Quais as preocupações existentes em uma solução que expõe seus objetos para a internet? É sobre esse assunto que vamos falar hoje!

Ao longo do texto, alguns termos farão referência às soluções de storage em nuvem da Azure e AWS, porém os conceitos podem ser aplicados em qualquer outra solução de storage.

Motivações

Os times de negócio apresentam aos arquitetos as mais diferentes necessidades. Todo o trabalho feito pelos times de tecnologia tem o intuito de atender da melhor forma a demanda de negócio e no final do pipeline, o cliente final.

Os clientes podem se beneficiar do uso de soluções de storage para armazenamento de objetos estáticos, visto que essas soluções podem ser integradas com uma solução de CDN (Content Delivery Network) e oferecem alta disponibilidade e velocidade no acesso aos recursos.

Utilizar os object storages também pode facilitar a entrega de arquivos/documentos ao usuário final, bastando apenas disponibilizá-lo na estrutura e comunicar ao usuário ao link de acesso ao objeto.

Vamos entender um pouco melhor como os storages funcionam e tudo que permeia a exposição pública dos documentos.

Estruturas do Object Storage

Nas soluções de object storage mais utilizadas no mercado, é comum nos depararmos com a possibilidade de organizar nosso recurso em uma estrutura hierarquica, dividindo em caminhos (paths) diferentes os diversos tipos de objetos que serão armazenados ali.

Dentro dos storages, temos basicamente 3 níveis de organização que podem ser criados dentro dessa hirarquia:

Repositório;
Pasta;
Objeto.

O repositório é o nome genérico dado ao recurso que realmente criamos dentro da plataforma. Para o Azure ele é uma Azure Storage Account, para a AWS ele é um S3 Bucket. Esse é o maior componente da estrutura e normalmente é criado com a responsabilidade de armazenar os objetos de uma mesma categoria em uma solução. As regras de criação desse componente costumam ser bem simples, devemos respeitar os padrões de nomenclatura impostos pelo provedor e nosso nome deve ser único globalmente dentro daquela plataforma.

As pastas são o segundo nível organizacional do nosso componente. Abaixo do repositório, podemos criar inúmeras pastas diferentes e inclusive incluí-las dentro de outras pastas. Além de se respeitar o tamanho máximo do nome da pasta imposto pelo provedor, pastas no mesmo nível não poderão ter nomes repetidos.

O último nível da hierarquia são os objetos. Essas são as informações que nós realmente temos interesse e desejamos acessar. Não é possível criar nada abaixo dos objetos, os sacramentando como o último nível dentro do nosso recurso. Por padrão, não temos restrições relacionadas aos objetos, a não ser que durante a configuração do seu repositório, o time responsável tenha realizado alguma mudança nos valores padrão, como por exemplo para limitar o tamanho dos arquivos que poderão ser armazenados.

A imagem acima representa graficamente a estrutura dos objects storage. Temos um repositório contendo diversas pastas diferentes e as pastas contendo os objetos e outras pastas.

Agora que entendemos esse modelo, vamos falar um pouco sobre as diferentes formas de exposição desses objetos de maneira pública.

Escopos de exposição

Entender como os storages são estruturados é essencial para conseguirmos compreender e avaliar os modelos de exposição disponíveis. As estruturas existentes impactam diretamente como os recursos podem ser organizados e expostos. Vamos aos escopos!

Container/Pasta

Como apresentamos anteriormente, o repositório é composto internamente por pastas, essas que armazenarão os documentos que tornaremos disponíveis.

Quando a exposição é configurada nesse nível, tudo que está dentro das pastas torna-se publicamente acessível.

Neste caso as pastas também são expostas, permitindo que os usuários realizem requisições para o recurso e obtenham informações (e metadados) não apenas sobre os objetos, mas também sobre a estrutura onde estão presentes.

Objetos

Sendo a forma mais segura de expor publicamente os objetos, nesse modelo “nenhuma” informação sobre a estrutura de pastas fica disponível. Apenas o objeto em questão tem seu acesso liberado.

Note as aspas em nenhuma. Expor apenas os blobs não permitirá que metadados das pastas sejam acessados, porém a estrutura de pastas até chegar ao objeto estará disponível na URI utilizada para acessar o recurso.

Modelos de exposição dos blobs

Passamos brevemente aos escopos pois é necessário compreendermos em quais níveis nós podemos publicar nossos recursos. Com isso estabelecido, agora falaremos sobre como esses objetos podem ser expostos.

Exposição atemporal

Neste modelo nós habilitamos o acesso público aos recursos das pastas para todos os usuários e sem restrição de tempo. Os objetos serão acessíveis a qualquer momento e seu acesso será não será revogado automaticamente, devendo ser feito de maneira explícita.

Este é o modelo mais simples, visto que selecionamos uma das estruturas de pastas e habilitamos o acesso à partir daquele nível. O que resta determinar é o escopo (como foi tratado na seção anterior).

Todos os objetos presentes no escopo selecionado estarão visíveis até que o acesso público seja revogado por algum usuário com permissão suficiente.

Exposição temporária

Esse modelo faz uso de outra função dos object storages, que permite a criação de um “link” de acesso que estará temporariamente disponível. O acesso ao recurso exposto pelo link será revogado quando o tempo de expiração cadastrado for atingido.

No Azure esse recurso se chama SAS (Shared Access Signature) e utiliza as chaves de criptografia da storage account para construir a URL e assiná-la, a tornando disponível para uso.

Preocupações de Segurança

Em qualquer um dos modelos e qualquer um dos escopos há preocupações de segurança. O principal ponto que deve ser considerado quando estivermos estruturando a nossa arquitetura é: que dados serão armazenados nos storages?

Essa pergunta é importante pois ela que guiará qual modelo apresenta menos risco em relação aos outros.

Arquivos públicos, que não contém dados sensíveis e que serão acessados por diferentes grupos de usuários, podem ter seu acesso liberado sem nenhum controle. Isso se dá ao fato de que as informações contidas nos documentos não geram nenhuma preocupação aos negócios da organização que a detém.

Alguns documentos tem vida útil mais curta do que outros. Documentos que contém informações válidas por apenas algumas horas podem ter seu acesso liberado apenas pelo tempo em que se fazem úteis. Essa é uma boa estratégia de governar o ciclo de vida dos objetos armazenados nos storages. O ponto de atenção desse cenário é o mesmo do anterior, os dados. Mesmo temporariamente, o documento estará acessível de maneira irrestrita, permitindo que qualquer usuário com a URI do recurso possa acessá-lo.

Esquecendo quais dados estarão presentes nos documentos, outra preocupação é a revelação da estrutura do storage. A exposição dos objetos trará à tona parte da estrutura hierarquica de pastas existentes no storage. Isso pode ser um problema caso seu recurso armazene não apenas documentos públicos, mas também informações que devem ser protegidas do acesso externo.

A preocupação exposta pelo trecho anterior é agravada quando pensamos na possibilidade de erro de configuração. Expor publicamente mais do que era necessário pode causar sérios danos à organização, por isso além de ter um processo bem estabelecido para a liberação de acessos públicos, a arquitetura deve ser bem pensada para segregar informações sensíveis e públicas em repositórios diferentes.

As soluções de object storage são utilizadas em grande parte das empresas que fazem uso de nuvem pública. Independente do provedor, os benefícios gerados por esse tipo de recurso são os mesmos, porém precisamos nos atentar para não acabarmos expondo nossa organização a ataques e para evitar o vazamento de dados sensíveis.

Espero que esse texto te ajudado a compreender as preocupações existentes na exposição pública de documentos através de soluções de storage.

Até logo!

Azure Key Vault

Tue, 27 Feb 2024 00:00:00 GMT

Quando estamos consntruindo nossas soluções em nuvem, nos deparamos constantemente com questões relacionadas a segurança. “Onde devo armazenar as credenciais do meu banco de dados?”, “Como posso implementar meu certificado para estabelecer uma comunicação segura”, “De que forma devo armazenar a chave utilizada para criptografar meus arquivos em um blob storage?”, são alguns questionamentos que nos ocorrem. Para responder esses questionamentos, a resposta é a mesma: utilizando o Azure Key Vault.

Para que serve?

Na introdução do texto, mencionei algumas funções para qual o Azure Key Vault pode ser utilizado, porém nessa sessão vamos descrevê-as de maneira mais detalhada.

Os vaults (não restritos apenas ao Azure Key Vault, mas também soluções com o Hashicorp Vault) são utilizados para armazenarmos e acessarmos credenciais sensíveis de maneira segura e protegermos o acesso à elas.

O Azure Key Vault é utilizado majoritariamente sob 3 tipos de recursos: chaves (keys), segredos (secrets) e certificados (certificates).

Chaves - são informações utilizadas para criptografar dados em outros serviços (ex: storage accounts, cosmos db, sql database, etc);
Segredos - podem ser várias coisas diferentes, como senhas, API Keys e outras informações que devem ter seu acesso público protegido;
Certificados - utilizados para estabelecer comunicações seguras e autenticações, podemos gerenciar o ciclo de vida dos objetos dentro do vault.

Os objetos mencionados acima e gerenciados pelo Key Vault poderão ter seu ciclo de vida controlado pelo recurso (dentro das limitações existentes). Certificados poderão ser criados e excluídos, chaves poderão ser criadas, rotacionadas e excluídas, segredos poderão ser atualizados, e por aí vamos.

Entendemos os recursos básicos do Azure Key Vault, mas agora, para que ele serve?

O desenho acima mostra o cenário mais comum de uso do Azure Key Vault. Vemos uma aplicação consumindo não apenas um segredo armazenado no vault (e utilizado para acessar um banco de dados) mas também o consumo de um certificado (utilizado para estabelecimento de comunicação TLS).

No segundo cenário, demonstrado acima, vemos uma Azure Storage Account consumindo uma chave armazenada no Azure Key Vault para criptografar os blobs existentes dentro de si.

Esses são dois dos cenários mais comuns de uso do vault, mas não se limitam apenas a esses. Você pode utilizar um vault como bem entender, desde que a solução proposta atenda a sua demanda.

Arquitetura

Sendo um PaaS (Platform as a Service) não temos o que gerenciar em relação à infraestrutura do Key Vault, porém suas funções são segregadas de forma a termos um painel de gerenciamento e um de acesso aos dados contidos no cofre.

Essa divisão entre management plane e data plane não é visível pelos usuários finais (desenvolvedores, arquitetos, engenheros, etc), porém é altamente influente quando pensamos no controle de acesso (assunto da próxima sessão).

A arquitetura desenhada para o Azure Key Vault nos permite ter maior controle e segurança dos nossos dados e de quem os acessa.

Controle de acesso

Ainda no tema que finalizou a última sessão, o modelo de controle de acesso ao Azure Key Vault é um pouco diferente do que estamos acostumados a encontrar nos outros recursos.

Da forma que foi projetado, é possível separar o uso dos gestores do vault e dos consumidores, dessa maneira estabelecendo um controle granular mais efetivo das responsabilidades de cada um dos atores.

O management plane é responsável por gerenciar todos os aspectos de funcionamento do vault, como suas propriedades, permissões de acesso, configurações de segredos, chaves e certificados. Já o data plane habilita o acesso às informações valiosas do recurso, como os valores dos segredos, as chaves e os certificados armazenados.

Como podemos ver no simples desenho acima, a granularidade das permissões existentes no data plane permite maior controle sobre o que uma identidade pode fazer em um determinado tipo de objeto. Essa granularidade não existe no RBAC do management plane, pois o mesmo implementa grande parte das roles existentes nos outros recursos do Azure (ex: contributor, reader, admin, etc).

Esse modelo permite que as aplicações recebam apenas os acessos necessários para realizarem as operações no objeto em questão. Não é necessário fornecer à aplicação visibilidade sobre as outras coisas que estão no cofre e muito menos do cofre em si. O acesso é feito diretamente ao recurso necessário, sem passar por qualquer outra “barreira”.

As soluções de cofre são de extrema utilidada quando estamos montando nossas soluções em nuvem. Soluções como o Hashicorp Vault, AWS KMS e o Azure Key Vault oferecem maneiras de manter o acesso às informações seguro, seguindo as boas práticas da arquitetura de soluções em nuvem.

Espero que tenha gostado do texto e que de alguma forma eu tenha conseguido te ajudar no entendimento das funcionalidades do vault bem como as formas com que ele possa utilizado nas suas soluções.

Até logo!

Proteção de senhas

Thu, 14 Dec 2023 00:00:00 GMT

Possívelmente o modelo de autenticação mais antigo que ainda é utilizado em larga escala, as senhas fazem parte do dia a dia de grande parte das empresas. Em tempos de passwordless, muitas vezes, essas credenciais acabam sendo “esquecidas” e as empresas deixam de aplicar controles para evitar o compromentimento delas. Hoje falaremos um pouco sobre algumas características das senhas, alguns vetores de ataque e como incrementar a proteção das credenciais do seu usuário!

Cenários de uso das senhas

As senhas são, de maneira simples, uma sequência de caracteres em texto plano. Normalmente, estão atribuídas a algum tipo de identificador, como um e-mail ou um username.

Na empresa onde trabalhamos, estamos sujeitos às políticas e guardrails de segurança aplicados pela organização, o que nos leva muitas vezes, a não ter opções a não ser seguir os direcionamentos dos times de segurança.

Pensando como um usuário comum, fora do âmbito corporativo, as senhas ainda estão extremamente presentes no dia a dia. Elas são utilizadas para:

“Destravar” o smartphone;
Acessar contas de redes sociais;
Desbloquear a estação de trabalho.

Esses foram apenas alguns exemplos, se explorarmos mais as atividades diárias do usuário comum, notaremos muito mais a presença desse recurso.

Vetores de ataque

Dada a alta taxa de uso das senhas, os ataques direcionados às credenciais ainda são extremamente presentes e eficientes. Todos os ataques visam obter acesso à conta do usuário, o que difere entre eles é a forma de se fazer isso e também o alvo.

Alvo

Temos 2 grandes alvos nesse quesito, o usuário e a senha. Alguns ataques visam obter as credenciais através do usuário, isso é, ele de alguma forma fornece as credenciais ou fornece dicas que levam os atacantes a descobrir elas. Os ataques direcionados às senhas consistem na exclusiva adivinhação das mesmas, utilizando ferramentas externas e também insumos gerados por outras fases dos ataques.

Ataques

Após compreender os 2 principais alvos dos ataques, chegou a hora de estudarmos brevemente os ataques mais comuns, utilizados hoje em dia e com grande efetividade, quando não se há políticas fortes de segurança de credenciais.

Phishing

![Imagem retirada do site Simplilearn](https://www.simplilearn.com/ice9/free_resources_article_thumb/phishing_working_2-What_Is_Phishing.PNG align=“center”)

O famoso método do “você foi sorteado!”. Uma estratégia de phishing visa enganar o usuário de maneira que o mesmo forneça suas credenciais aos atacantes. Isso pode ser feito de diversas maneiras, sendo o método mais comum, páginas na web que prometem prêmios/recompensas após o usuário fornecer algumas informações.

Também é comum encontrarmos páginas simulando as landing pages de grandes corporações, como bancos, que levam o usuário a fornecer seus dados bancários, comprometendo assim a integridade das suas contas.

Man-in-the-middle

![Imagem retirada do site da Panda Security Mediacenter](https://www.pandasecurity.com/en/mediacenter/src/uploads/2022/02/02-Phases-of-man-in-middle-attack.png align=“center”)

Uma forma mais sofisticada de se obter informações e que não tem o usuário como alvo.

Aqui, um atacante consegue se “infiltrar” na comunicação entre o usuário e o sistema destino, se passando por um integrante confiável da comunicação e interceptando as informações trocadas entre as partes.

![Imagem retirada do site Terranova Security](https://now.symassets.com/content/dam/norton/global/images/non-product/misc/tlc/in-post-01-social-engineering-explained.png align=“center”)

Esse ataque utiliza como meio as relações interpessoais entre o atacante e sua vítima.

O atacante se porta como alguém confiável à pessoa que deseja obter as informações, coleta diversos dados considerados “valiosos” e utiliza dessas informações para “acertar” a senha da vítima.

Brute Force

![What is a brute attack? What are the types of brute force attacks and how you can prevent it.](https://www.manageengine.com/log-management/images/cyber-security-attackswhat-is-brute-force-attack.png align=“center”)

Os ataques do tipo brute force procuram ganhar acesso à conta do usuário por meio de tentativas de login.

O atacante constrói uma automação que testa combinações de senhas até que uma delas seja uma tentativa bem sucedida!

Credential Stuffing

Este não é um ataque que visa “adivinhar” a senha do usuário. Também não é uma estratégia que pode ser utilizada como ponto de partida na obtenção das credenciais.

O credential stuffing é muitas vezes a segunda fase de um ataque do tipo brute force. Esse método consiste na utilização de uma senha válida para tentativas de acesso à outras contas do mesmo usuário. É um ataque que tem como alvo, pessoas que utilizam a mesma senha para várias contas pessoais.

Protegendo as credenciais

Como vimos na seção anterior, os ataques são construídos de diferentes formas e aplicados com diferentes estratégias, mas sempre visando uma coisa: obter acesso às credenciais do usuário!

Para garantir a integridade das suas credenciais de acesso e evitar que você esteja exposto à qualquer um desses vetores, alguns controles podem ser aplicados. Os controles nem sempre vão garantir a segurança total das contas, mas habilitarão a proteção contra diversas ofensivas feitas aos seus ativos.

Vamos comentar sobre algumas dessas estratégias defensivas.

Lembrando que a proposta do texto é mencionar algumas formas de proteger as suas senhas. Não estamos falando de autenticação do tipo passwordless, que permitem a autenticação por outros métodos.

Troca periódica de senha

Muito comum nas empresas e também uma boa estratégia para as suas contas pessoais, a rotação de senhas é um método efetivo para se garantir a segurança das suas contas.

No caso de uma credencial vazada, a troca de senhas garante que aquela senha não poderá ser utilizada para acessar as contas comprometidas.

Nos ambientes empresariais, é costume a exigência da rotação de senhas de maneira periódica (a cada X dias, por exemplo). Os usuários recebem avisos através do e-mail corporativo ou de algum portal interno da empresa, de que sua senha esta “expirando”. Esse aviso, simplifica a vida do usuário, que não precisa manter um histórico da sua última mudança de senha.

Ataques relacionados: phishing, social engineering, credential stuffing.

Complexidade

Esse controle é implementado em larga escala pelas diferentes plataformas. Quando iniciamos o processo de criação de conta em um aplicativo, estamos mais do que acostumados a ver uma série de requisitos mínimos que devem ser cumpridos para ter a criação da conta validada.

Ex: é necessário que a sua senha tenha no mínimo 8 caracteres, 1 número, 1 letra maiúscula e 1 caractere especial.

Implementar uma política de complexidade diminui a probabilidade de um ataque do tipo brute force ter efeito. Ao adicionarmos números, letras maiúsculas e minúsculas e também caracteres especiais, aumentamos as combinações possíveis das senhas, dificultando muito a adivinhação delas.

![Time Taken For Hackers to Crack Passwords Revealed - IT Security Guru](https://specopssoft.com/wp-content/uploads/2023/05/Time-to-Crack-MD5-Hashed-Passwords_V.3.svg align=“center”)

Na imagem acima, retirada do site “IT Security Guru”, temos a representação de quanto tempo um ataque brute force levaria para adivinhar sua senha de acordo com a complexidade dela.

Conseguimos visualizar que quanto maior o tamanho e maior a combinação de caracteres, mais tempo será necessário para acertar a combinação correta.

Ataques relacionados: phishing, brute force, credential stuffing.

Conscientização

Este é uma implementação não-técnica para evitar que você tenha problemas com os ataques.

Temos muitas iniciativas na internet que visam ensinar o básico da segurança da informação para as pessoas. Questões como: não clicar em links suspeitos, não fornecer suas credenciais para ninguém, não compartilhar dados sensíveis e pessoais nas redes sociais, são as principais ações compartilhadas nessas iniciativas.

Dentro das empresas é comum que o time de segurança da informação realize diversas campanhas de conscientização. Além de cursos e plataformas de aprendizado, os colaboradores são sensibilizados periódicamente com mensagens nos canais de comunicação oficiais e também através de e-mails corporativos.

O importante das políticas de conscientização é garantir a efetividade e a comunicação simples, fazendo com que tanto o usuário mais experiente, quanto o mais vulnerável (principal alvo), entendam a mensagem transmitida e saibam como aplicar esses cuidados em seu dia a dia.

Ataques relacionados: todos.

Extra: Microsoft Entra ID

Pensando em utilizar uma ferramenta que contenha formas de proteger seu usuário, temos a solução de AM (Access Management) mais utilizada no mercado e lider no gartner, o Microsoft Entra ID.

Com o Entra é possível aplicar políticas de senha como as mencionadas anteriormente, suspensão de contas (evitando assim os ataques do tipo brute force), e também podemos utilizar através do Entra ID Protection, as capacidades de machine learning da Microsoft, que analisam as diversas interações dos usuários com os sistemas e identificam até os ataques mais sofisticados.

Utilizar uma solução de AM completa e com capacidades de proteção, pode economizar muito tempo e proteger sua empresa de danos reais contra seus ativos!

Entendemos alguns dos principais vetores de ataque existentes e ainda mais importante, algumas estratégias para defender o ambiente desses ataques mencionados.

Espero que tenha gostado do conteúdo e que à partir de agora, você consiga se proteger e também o ambiente da sua organização.

Até logo!

Para que serve um CSPM?

Fri, 01 Dec 2023 00:00:00 GMT

Não é preciso mencionar a criticidade de se manter os ambientes em nuvem pública seguros contra os ataques existentes, porém se pensarmos nas possíveis escalas de tamanho dos ambientes em nuvem das empresas, podemos nos encontrar em uma “fria” ao tentar proteger esses ambientes sem nenhum modelo de referência. Dito isso, hoje falaremos sobre o CSPM (Cloud Security Posture Management, ou em português, Gestão de Postura de Segurança em Cloud), a solução que nos permite entender e evoluir o estado da segurança dos nossos ambientes em nuvem!

Entendendo as escalas do problema

Como foi comentado na introdução do texto, o constante crescimento dos ambientes em nuvem pública das empresas demonstram aos times de segurança um grande desafio: como manter os ambientes protegidos?

Cada vez mais, vemos empresas apostando em sua estratégia de nuvem pública sem foco em um único provedor, mas em múltiplos, movimento chamado multi-cloud adoption.

A granularidade dos ambientes acrescenta peso à preocupação dos times de segurança, visto que os ambientes não serão iguais nunca. Em um provedor teremos workloads de analytics e big data, no segundo teremos nossos workloads de inteligência artificial e treinamento de modelos de machine learning, no terceiro teremos nossos workloads principais, que atendem os clientes da organização, e assim por diante.

Conseguiu perceber a dificuldade? Cada ambiente tem sua peculiaridade, sua responsabilidade, suas tecnologias e principalmente o seu propósito. Não é possível planejar a implantação dos ambientes de acordo com 1 único blueprint (planta/modelo), por conta dos diversos motivos comentados anteriormente e também pela diferença tecnológica dos provedores.

Outro ponto relevante é a constante evolução dos ataques cibernéticos. É impossível manter a segurança dos ambientes up-to-date sem o auxílio de uma ferramenta dedicada para isso. Os times não tem a capacidade de estarem buscando a todo momento os novos tipos de ataque e nem as evoluções dos ataques existentes. Se acrescermos a esse pensamento a necessidade de se entender como proteger o ambiente desses vetores, a tarefa fica realmente im-po-ssí-vel!

Entendido o problema, vamos à seguinte pergunta:

Como podemos fazer para proteger os diferentes ambientes em nuvem e estar sempre alinhados com as melhores práticas de cibersegurança?

Compreendendo os conceitos

Após entendermos a necessidade de se ter uma ferramenta para gestão da segurança nos ambientes, vamos aprender sobre como as soluções realizam essa gestão.

Disclaimer: ao longo do texto, farei referências ao Microsoft Defender for Cloud, solução de CSPM da Microsoft. Talvez a solução que você utilize em seu ambiente faça uso de uma terminologia diferente da que eu estarei utilizando, porém não se preocupe, pois os conceitos se estendem entre as ferramentas.

É importante entendermos alguns conceitos que são mencionados quando falamos de CSPM, então vamos comentar sobre alguns deles!

Ambientes

O primeiro passo para começar a operacionalizar a sua soluçãod e CSPM é conectá-la aos ambientes que devem ser monitorados. No contexto deste artigo, estamos falando apenas de ambientes de nuvem pública, porém existem soluções de CSPM que nos permitem compreender também a postura de segurança dos nossos ambientes on-premise.

Mencionando os principais provedores de cloud, você precisará conectar:

AWS - organizations;
Azure - subscriptions;
GCP - projects.

Uma vez conetados, os ambientes passarão a ser monitorados pela ferramenta de maneira ativa, com checagens periódicas para atualização do Score de Segurança.

A primeira sincronização dos ambientes com a ferramenta de CSPM não será instantânea. É necessário aguardar algumas horas para que a ferramenta comece a retornar insights valiososo sobre a postura dos seus ambientes.

Score de Segurança

Traduzido do inglês para “pontuação”, o Score de Segurança é a principal métrica gerada pelo CSPM. A pontuação representada demonstra o nível de segurança que os ambientes monitorados se encontram em relação aos padrões de mercado utilizados pela ferramenta como parâmetro.

A imagem acima informa a postura total dos ambientes conectados de acordo com a análise em cima dos benchmarks utilizados pela ferramenta de CSPM.

Repare bem no gráfico. Com essa representação, podemos visualizar como a postura do ambiente evoluiu do período de 25/09 até 30/10 e a sua regressão à partir do dia 04/11. Essa análise nos permite retirar 2 insights:

O ambiente está sendo continuamente monitorado;
As ações realizadas podem impactar de maneira positiva mas também de maneira negativa a nossa postura.

Benchmark

As soluções de CSPM utilizam modelos centralizados de informações para conseguir gerar à partir do seu ambiente, as métricas importantes para a representação da postura.

Dando o exemplo com o Microsoft Defender for Cloud, o “modelo centralizado de informações” é o que a Microsoft chama de MCSB (Microsoft Cloud Security Benchmark). O MCSB é formado por um benchmark de segurança para o Azure, um benchmark de segurança para os outros provedores em cloud e um último benchmark para os outros recursos de nuvem da Microsoft. A imagem abaixo materializa essa composição.

![Image that shows the components that make up the Microsoft cloud security benchmark.](https://learn.microsoft.com/en-us/azure/defender-for-cloud/media/concept-regulatory-compliance/microsoft-security-benchmark.png align=“left”)

O produto final da “soma” desses recursos é o MCSB, utilizado como Golden Source pelo CSPM para fornecer o score do ambiente.

Security Recommendations

Entendemos que a postura do ambiente é uma pontuação (valor numérico) que nos permite compreender o estado da segurança do nosso ambiente, porém para realmente extrair valor da utilização de uma ferramenta de CSPM, precisamos de alguma maneira utilizar esse score para refletir a melhora de segurança nos ambientes. Para isso, temos as Recomendações de Segurança.

As recomendações capturam insights fornecidos pela aplicação dos benchmarks e os transformam em ações que podem ser executadas para incrementar a segurança do ambiente.

É com essa funcionalidade que podemos ver de fato o valor gerado por um CSPM, visto que temos não apenas a visão de como está nosso ambiente, mas também como recebemos “dicas” e sugestões para reforçar os controles em pontos considerados falhos.

Escalando a utilização do seu CSPM

Após entendermos os problemas enfrentados pelas empresas de diferentes segmentos no mercado, conhecermos a ferramenta que nos permite proteger nossos ambientes com os padrões reconhecidos e também compreender sobre os componentes principais da ferramenta, chegou a hora de falarmos sobre pontos importantes para a aplicação do CSPM em sua empresa, de modo que você consiga extrair dele o maior valor possível.

Escolha da ferramenta/Mapeamento do ambiente e Arquitetura

(comentar sobre a necessidade de se conhecer bem o ambiente da empresa para poder selecionar uma ferramenta que se adeque às necessidades)

O primeiro passo para a adoção de um CSPM é a escolha da ferramenta. É importante que você tenha conhecimento dos ambientes da sua empresa, para ser capaz de selecionar uma ferramenta adequada.

Os múltiplos ambientes em nuvem pública, as soluções executadas no ambiente on-premise (caso exista), todos esses são pontos importantes e que devem ser considerados na escolha da ferramenta.

Ferramentas como o Microsoft Defender for Cloud, que mencionei anteriormente, realizam a cobertura de ambientes Azure, AWS e GCP, fato que também foi mencionado anteriormente. Porém, esses provedores também contém suas próprias soluções de CSPM.

A Google Cloud Platform faz uso do Security Command Center, solução prioritária de CSPM e outras capacidades de segurança;
A Amazon Web Services tem o AWS Security Hub, realizando o mesmo papel.

As soluções específicas de cada provedor de nuvem costumam apresentar um nível de cobertura maior e mais eficiente aos recursos daquela plataforma em questão. Por um lado nós podemos optar por utilizar uma solução que irá fornecer uma visão centralizada dos ambientes conectados, mas não terá análises uniformes dos diferentes ambientes. Em contraponto, podemos optar por utilizar a solução nativa de cada um dos provedores de cloud, obter o máximo de eficiência na cobertura dos ambientes mas precisar gerenciar múltiplas soluções ao mesmo tempo. Essa tomada de decisão, deve ser feita de forma conjunta, entre o time de arquitetura e os times de segurança e operações!

Automações

(construir automações para reforçar automaticamente a postura de segurança gera o valor esperado do CSPM e desocupa os times de segurança, que podem focar em outras atividades)

Para atender as recomendações geradas pelo CSPM, as soluções disponibilizam a capacidade de desenvolvimento de automações, que tornarão o trabalho de normalização do ambiente mais tranquilo.

As automações serão desenvolvidas baseadas em recomendações recorrentes. Ex: máquinas virtuais estão sendo criadas sem serem registradas ao Active Directory da empresa, realizando dessa forma um bypass nas políticas de segurança reforçadas pelo AD. Esse cenário é “comum”, visto que máquinas virtuais serão criadas o tempo todo em um ambiente cloud. Para atender essa recomendação, o time responsável pode desenvolver uma automação que registra a máquina virtual no domínio desejado.

Esse é apenas um exemplo, automações de diversas formas e modelos podem ser construídas para solucionar as diversas recomendações geradas pela ferramenta.

Nem todas as recomendações poderão ser atendidas com automações. Algumas delas são pontuais e requerem a solução uma única vez.

Soluções adicionais

Visando o reforço da segurança no seu ambiente e direcionando a segurança de recursos específicos, temos também as soluções auxiliares.

Podemos configurar soluções que nos permitem ter uma visão mais a fundo da segurança em máquinas virtuais. Com a instalação de um agente ou de uma extensão na VM, é possível visualizar informações que o CSPM nativamente não visualizaria e gerar insights que nos permitirão proteger os recursos contra vulnerabilidades.

Constante em ambientes em nuvem pública, é uma ideia excelente termos uma ferramenta para análise dos ambientes Kubernetes que temos em execução. Como a maioria das aplicações em nuvem são contêinerizadas, o ambiente de preferência das empresas para execução dessas aplicações são as variações do Kubernetes (Openshift, AKS, EKS, etc). A utilização de uma solução como o Agentless Container Posture do Microsoft Defender for Cloud, nos auxiliará a previnir vulnerabilidades que podem causar sérios danos financeiros e à imagem da nossa empresa.

Pudemos entender melhor os motivadores para adoção de uma solução de CSPM e também algumas variáveis que devem ser consideradas quando você estiver estruturando seu ambiente.

Espero que tenha gostado do conteúdo.

Até logo!