Olá! Já nos perguntamos como empresas de grande porte, como instituições financeiras e empresas de tecnologia, com ambientes mistos, centenas de usuários e aplicações rodando em ambientes diversos, às vezes até mesmo em multi-cloud, conseguem reduzir os riscos cibernéticos? Pois bem, é sobre isso que trataremos em nosso curso de Arquitetura Zero Trust em Cloud.
Meu nome é Danilo Regis e sou arquiteto de soluções há cerca de 15 anos, atuando em empresas de pequeno, médio e grande porte.
Audiodescrição: Danilo é um homem negro, com barba e óculos. Ele tem poucos cabelos e está usando uma camisa azul escura. Está nos estúdios da Alura, com um ambiente decorado com diversos itens ao fundo.
Sou especialista em segurança da informação, perícia forense computacional, direito digital e compliance, além de especialista em gestão de empresas pela Fundação Getúlio Vargas.
Neste curso, aprenderemos inicialmente os fundamentos do Zero Trust, como chegamos até aqui e por que isso é tão importante e relevante para o mercado atualmente. Também aprenderemos as melhores práticas de governança de identidade. Hoje, existem muitas aplicações e plataformas, mas ferramentas sozinhas não resolvem tudo. É fundamental termos noções de boas práticas e entender o que é mais adequado para nossa empresa, independentemente do seu porte.
Falaremos também sobre a ideia de micro segmentação de redes e workloads. Como veremos nos fundamentos, é extremamente importante não só isolarmos os componentes em cloud, mas também garantir que cada um deles seja autossuficiente dentro dos seus limites e restrições de segurança.
Além disso, aprenderemos a fazer controles de acessos dinâmicos. Por exemplo, é diferente quando estamos acessando do Brasil ou de outro país na Europa, onde pode haver mais restrições e históricos de ameaças cibernéticas. Vamos entender como funcionam os múltiplos fatores de forma adaptativa.
Já repararam que, ao consultar um extrato, apenas o login já embarcado no aplicativo é suficiente? Mas, se formos fazer uma transação bancária, é solicitado um fator de autenticação adicional. O mesmo vale para o uso de ferramentas SaaS e ferramentas online. Enquanto estamos apenas utilizando, muitas vezes não é necessário inserir novamente nossas credenciais, mas se quisermos, por exemplo, alterar nossa senha, um segundo fator pode ser solicitado.
Vamos entender que a federação é uma ferramenta que podemos utilizar para fornecer acesso a uma empresa externa. Por exemplo, se temos um e-mail associado ao IAM Cloud, podemos conceder acesso a uma empresa parceira para que ela utilize suas próprias credenciais para acessar nosso ambiente.
Existem diversos protocolos que precisam ser utilizados para garantir a integração entre sistemas de forma centralizada. Esses protocolos já estão disponíveis para conectar aplicativos entre si ou até mesmo para conectar uma cloud a outra.
Também aprenderemos sobre o processo de orquestração e as ferramentas que auxiliam nosso dia a dia. Por exemplo, em um ambiente com milhares de usuários, é importante garantir que uma pessoa da área de segurança não forneça, de forma errônea, uma credencial a alguém ou que não deixe habilitado o usuário de um funcionário que já foi desligado da empresa. Isso é feito através de ferramentas e orquestrações, pacotes pré-prontos que utilizamos, por exemplo, conectados ao nosso ambiente de recursos humanos.
Além disso, é importante realizarmos avaliações periódicas de maturidade, não apenas em relação ao nosso ambiente de infraestrutura virtual, redes virtuais e recursos em cloud, mas também em relação a como lidamos com as aplicações publicadas na cloud e com nossos usuários. Precisamos verificar com que frequência fazemos revisões periódicas para garantir que todos tenham o acesso adequado, e tudo isso gera indicadores de maturidade.
Este curso se destina a especialistas em segurança da informação ou aspirantes a se tornarem especialistas, que trabalharão de forma próxima com profissionais da área de infraestrutura cloud. Muitas vezes, esses são departamentos mistos, ou são compostos por profissionais distintos, com um atuando na parte de infraestrutura e outro na parte de segurança.
Arquitetos de sistemas em geral, sejam arquitetos de soluções, arquitetos corporativos ou arquitetos de software, também devem ter um entendimento do que está disponível para ser utilizado. Desenvolvedores, assim como outros profissionais dentro das empresas, muitas vezes acreditam que a segurança é responsabilidade exclusiva de um time de segurança ou da área de infraestrutura. Durante o curso, entenderemos que a segurança é sempre algo compartilhado, e todos precisam participar. Os desenvolvedores têm um papel especial nesse conceito, pois são eles que podem realizar verificações dentro dos workloads e das aplicações, utilizando informações dos sistemas IAM e de gerenciamento de identidades em cloud.
Esperamos que apreciem o curso. Utilizem os espaços disponíveis para enviar dúvidas e entrem em contato através dos nossos fóruns no Discord. Nos encontramos na nossa próxima aula, a primeira aula.
Vamos iniciar nossa primeira aula do curso de arquitetura Zero Trust em Cloud, abordando tópicos fundamentais e os fundamentos do Zero Trust. Vamos mostrar como ele resolve problemas que surgiram durante os anos 80, 90 e início dos anos 2000. Vamos entender os princípios centrais deste framework, que hoje é um framework, mas que nem sempre foi assim, e identificar os componentes principais e a visão arquitetural geral de uma arquitetura Zero Trust.
Começando pelas origens, tudo começou no contexto dos firewalls, das redes e dos perímetros, desde o início, quando surgiram as primeiras redes. Em filmes como "Hackers" e "Piratas de Computador", víamos que uma pessoa que conseguia acessar um determinado modem dizia: "Estou dentro da rede". A partir desse momento, havia a possibilidade de realizar movimentações laterais. O invasor conseguia entrar na rede, fazer movimentações laterais e acessar todos os recursos, pois, naquela época, a barreira de segurança mais forte era a rede.
Nos anos 2000, começamos a ver uma segmentação e um tunelamento. Surgiram dois aspectos: as DMZs (zonas desmilitarizadas), que são zonas com acesso mais aberto da rede, e as VPNs, que até hoje utilizamos. Em 2010, muitas aplicações que antes eram acessadas dentro das empresas passaram a estar do lado de fora, em aplicativos e notebooks, com pessoas trabalhando remotamente ou alocadas em outros clientes. Isso gerou um grande impacto, com diversas demandas de segurança para mitigar riscos de elementos de IoT, mobile e pessoas externas.
Com o tempo, a quantidade de SaaS (softwares como serviços), como o Office.com e o Google Docs, começou a crescer dentro da comunidade, abrindo mais portas para as empresas e ambientes híbridos. Em 2020, tivemos a consolidação de um framework Zero Trust. Anteriormente, existia o conceito de "castle and moat" (castelo e fosso), uma analogia que indica que uma ponte dá acesso a um castelo. Dentro do primeiro portão, era feita uma verificação de identidade. Uma vez dentro do castelo, o acesso era livre. Para chegar às dependências do rei, havia novas verificações, mas, de forma geral, todos tinham livre circulação dentro do castelo, enquanto o lado externo era protegido por um fosso.
Esse modelo fornecia uma segurança elevada, mas credenciais comprometidas tinham um impacto muito grande. Até hoje, enfrentamos vazamentos de credenciais, mesmo com criptografias. Existiam tabelas que faziam a correspondência de credenciais criptografadas para senhas abertas, dando liberdade aos atacantes. O VPN se tornou um ponto único de falha, pois quem tinha acesso a uma VPN tinha um passe livre. Empresas maiores, com contratos com empresas de telemarketing, por exemplo, enfrentaram problemas com funcionários que tinham acesso a VPNs de grandes empresas, aumentando a superfície de ataque.
Antigamente, todos os softwares eram instalados dentro das dependências da empresa. Com o SaaS, um funcionário de uma empresa de grande porte precisa acessar a internet, pois muitas ferramentas são externas. Para isso, é necessário abrir portas, como a porta 443, para a internet. Empresas que antes forneciam condições para o trabalho interno agora precisam fazer exposições. O ambiente em cloud precisa, por exemplo, de um link privado dentro da empresa, aumentando os pontos de risco, como mobile, IoT e parceiros.
O modelo tradicional foi saturado com muitos problemas e surgiram novas ameaças, que sempre acompanham as vulnerabilidades. Ransomwares, que capturam e criptografam dados, pedindo resgates, começaram a se movimentar lateralmente. Ao entrar em uma máquina, fazem uma varredura dos IPs na mesma rede, procurando backdoors e vulnerabilidades para se instalar em outras estações.
O MFA (autenticação multifator) já existe há muito tempo, mas os atacantes sempre encontram maneiras de burlar. Surgiram ataques de MFA, com robôs testando senhas conhecidas e tentativas aleatórias de numeração de segundo fator de autenticação. Existem variações, mas, em geral, é isso.
Ataques à cadeia de suprimentos também são uma preocupação. Empresas grandes, como instituições financeiras, têm departamentos de segurança rígidos, mas contratam empresas menores com fragilidades de segurança. Atacar uma empresa terceira é mais fácil do que uma grande empresa com um departamento de segurança robusto. Isso é conhecido como ataque à cadeia de suprimentos ou supply chain attacks.
Os ataques persistentes são caracterizados por serem mais inteligentes e informados, frequentemente utilizando engenharia social e sendo direcionados. Um exemplo de ataque é o DDoS, que é uma negação de serviço onde se sobrecarrega um sistema até ele cair. No entanto, os ataques persistentes são mais sutis, a ponto de, às vezes, as ferramentas não conseguirem detectá-los, pois aparentam ser comportamentos normais. Esses ataques se tornaram mais frequentes, representando um grande risco.
Em 2004, o grupo The Open Group identificou que havia um problema emergente. Naquela época, perceberam que o perímetro de segurança estava comprometido e que não era mais possível defendê-lo adequadamente. A segurança deveria se mover para dentro de cada ativo, como um workload ou um recurso, por exemplo, um blob storage, um S3 ou uma fila. Cada aplicação deveria buscar sua própria segurança, sem confiar que todos com acesso à rede poderiam acessá-la.
Em 2007, concluiu-se que o perímetro não era mais viável. Os elementos deveriam se proteger, e a autorização e autenticação precisariam ser granulares e contínuas. As aplicações devem ser seguras em ambientes hostis, antecipando-se a possíveis movimentações laterais. A criptografia deve ser ubíqua e de fim a fim, presente tanto em dados em repouso quanto em trânsito. Para isso ser possível em grande escala, como em contextos de cluster ou Kubernetes, é essencial que haja interoperabilidade e padrões bem definidos, como REST, SOAP e GRPC.
Os sistemas legados, por vezes, recebem menos atenção e camadas de segurança, e a confiança implícita pode levar a violações. A proposta é eliminar essa confiança implícita para mitigar riscos. A segmentação é crucial, indo além de criar redes virtuais ou sub-redes. Independentemente do tipo de rede, a Zero Trust prega que ela não é mais segura. A autenticação estática e não contextual é problemática, e a autenticação pode variar conforme o contexto e objetivo, como o uso de MFA diferenciado.
As identidades são um ponto frágil, e credenciais simples oferecem riscos significativos. Hoje, fala-se em sistemas sem senhas ou passwordless. Os padrões atuais de acesso, como usuário, senha e perfil, são insuficientes. Em 2009, ocorreu um ataque em massa, explorando vulnerabilidades do Internet Explorer, conhecido como Zero-Day. Ferramentas avançadas hoje garantem segurança contra Zero-Day, mas na época, isso era limitado. Foi implantada uma backdoor, permitindo extração de dados sensíveis de várias empresas.
Cinco anos após os primeiros alertas sobre a insegurança da rede, muitas empresas ainda estavam vulneráveis. Em 2014, dez anos após os primeiros sinais, o Google apresentou uma nova proposta. Em 2010, o Google admitiu ser vítima do ataque Aurora e iniciou um trabalho que resultou no primeiro framework moderno de Zero Trust. Este modelo foi a primeira formalização de ambientes modernos.
Os motivadores incluem o SaaS First, mobilidade e o conceito de Bring Your Own Device (BYOD), permitindo que pessoas utilizem seus próprios dispositivos. O crescimento dos microserviços e APIs, impulsionado pelo Kubernetes, também influenciou essa mudança. As regras de conformidade exigiram mudanças significativas, culminando na cultura atual de Zero Trust.
Concluindo o primeiro bloco, o perímetro deixou de ser seguro. A confiança implícita foi o maior risco identificado, e o Zero Trust surgiu como uma resposta arquitetural para mitigar os riscos do modelo tradicional. Com isso, encerramos o primeiro bloco e nos vemos no próximo bloco da primeira aula.
Para sermos profissionais de segurança da informação e arquitetura, é essencial que tenhamos um entendimento tanto prático quanto teórico. Isso se deve ao fato de que o modelo Zero Trust costuma ser exigido em processos de compliance, contratações com terceiros e auditorias. Nosso segundo bloco tem como objetivo fornecer um entendimento teórico, um embasamento sobre os princípios do Zero Trust, suas variações, focos e frameworks que podem ser utilizados em diferentes contextos, como em um ambiente governamental ou em interações com empresas de outros países. Muitas vezes, dependendo do país, haverá normativas específicas que, embora sigam princípios gerais, apresentam variações e focos que podem ser mais úteis conforme os objetivos da empresa.
O Zero Trust é um modelo de segurança que elimina a confiança implícita e exige verificação contínua baseada em dispositivos, contextos e identidade. Vamos detalhar isso, e esses conceitos estarão presentes em cada um dos frameworks. Não é necessário decorar o que cada framework especificamente contém. É importante saber que eles existem e que seus focos são diferenciados, mas, ao memorizar e aprender este princípio básico, conseguiremos lidar com todos eles de forma tranquila.
Em 2010, após as primeiras movimentações em 2004 e os primeiros artigos em 2007, uma consultoria chamada Forrester realmente formalizou o Zero Trust. John Kindervag propôs inicialmente dar maior visibilidade, algo que hoje vemos em sistemas de monitoramento como Line 3, Kibana, Datadog, Application Insights, entre outros. Ele enfatizava a importância de monitorar intensamente a camada 7, a camada de aplicação, onde conseguimos ver os dados trafegados. É nessa camada que o HTTP opera, onde podemos analisar headers e, muitas vezes, até mesmo payloads. Essa é a camada 7 ou L7 (Layer 7).
O primeiro framework moderno que temos, baseado nesses princípios, afirmava que não podemos proteger o que não podemos ver e que as regras deveriam ser baseadas em aplicações e usuários, e não apenas em IPs e portas. Embora ainda façamos controle por IPs e portas, o que John queria dizer é que isso não é suficiente e deve ser complementado com outros controles. O conceito surgiu no artigo "No More Chewy Centers", que criticava a ideia de que o perímetro tinha uma casca dura em torno da rede, mas era mais vulnerável internamente. O artigo defendia que nunca devemos confiar, sempre verificar, assumir a violação como estado base, adotar o menor privilégio como princípio e orientar-se a recursos, não a redes. Recursos são tudo o que uma cloud fornece, como armazenamento de dados, bancos de dados e aplicações.
Em 2020, o NIST apresentou um framework e uma arquitetura Zero Trust. Após 15 anos de espera, esse modelo foi formalizado. O que o Google criou em 2014 já era forte e formalizado, mas muito voltado ao modelo do Google. O NIST, por outro lado, é universal e aplicável a qualquer tipo de provedor ou empresa. Ele trouxe a primeira versão do 800-207, um número importante de conhecer. Diferente do ISO, que são normas pagas, o NIST é gratuito e acessível. É importante entender que ele pode ser reutilizável e prescritível, permitindo que um auditor externo especialista em NIST venha à nossa empresa e cobre elementos independentemente da nossa natureza. O auditor não precisa conhecer detalhes de uma instituição financeira para auditá-la, pois o NIST é aplicável a qualquer negócio, produto ou ferramenta.
O NIST integra-se com sistemas importantes de gestão e monitoramento, como CDM e CEM, e introduz novos elementos que vamos explorar, como PE, PA e PEP. PE, Policy Engine, é o ponto de verificação de segurança ou políticas. PA é o Policy Administration. PEP, importante para arquitetos, é o ponto de execução de uma política. CDM aplica-se a ferramentas de diagnóstico contínuo e mitigação, enquanto CEM é o Sistema de Segurança da Informação e Gestão de Eventos. Para mais detalhes sobre o NIST, é possível acessá-lo em csrc.nist.gov, onde estão disponíveis os documentos, também acessíveis via QR Code. O NIST é uma instituição nacional dos Estados Unidos, semelhante ao nosso Inmetro, que fornece padrões de segurança para empresas. Em 2018, houve uma revisão que serviu de base para o NIST, e certamente outras revisões ocorrerão ao longo dos anos.
Ele foca em domínios e não em componentes. O que seriam domínios? Seriam, de certa forma, alguns tipos de contextos, como contextos de aplicações e contextos de rede. Ele é menos prescritivo e mais conceitual, com uma ênfase forte na proteção de dados, mais do que o NIST. Portanto, continuam existindo o Forrest e o NIST. Devemos recorrer a qual? Aos dois, de acordo com a nossa necessidade. É importante que ambos os modelos sejam conhecidos.
O Google, através do Forrest, está focando nesses domínios de pessoas, dispositivos, redes e workloads (cargas de trabalho). Workloads são aplicações dentro de um Kubernetes, por exemplo, onde cada aplicação publicada é considerada um workload. No entanto, não estamos falando apenas de Kubernetes ou de clusters. Aqui, qualquer aplicação que esteja realizando algum trabalho dentro do nosso contexto é relevante. Também discutimos sobre dados, visibilidade e análises, automação e orquestração.
Em 2014, o Google lançou o BeyondCorp, criado após o ataque Aurora, também conhecido na literatura como ataques APT (Advanced Persistent Threats, ou ameaças persistentes avançadas). Ele aborda acessos baseados em usuários e dispositivos, adotando proxies como pontos de decisão. Atualmente, também utilizamos muitas políticas em proxies. Quando colocamos um ponto de passagem com verificação, como um API gate verificando um conteúdo, estamos utilizando esse modelo. No entanto, é importante observar que o proxy está antes do workload. Teoricamente, deveríamos complementar com as verificações no workload. O BeyondCorp foi uma implementação real e não apenas conceitual.
O NIST são padrões, enquanto o FORREST é uma consultoria que indica determinadas ações. O Google aplicou essas ações. Observemos a diferença: o Google, como empresa de tecnologia, aplicou de fato o que estava escrevendo, diferente do FORREST e do NIST.
A Gartner, outra consultoria de grande porte, lançou um documento chamado CARTA, que significa Continuous Adaptive Risk and Trust Assessment (Avaliação Contínua e Adaptativa de Risco e Confiança). A adaptação contínua e o levantamento dos elementos seguros são propostas do CARTA. Ele oferece níveis mais granulares que o NIST. O NIST é um modelo conceitual, enquanto o CARTA, estando dentro da empresa, muitas vezes ao lado da área de TI, tem a possibilidade e a necessidade de fornecer mais detalhes. Quando indicamos para uma área de segurança o que ela deve fazer, não pode ser simplesmente de um nível muito alto; eles querem detalhes. O CARTA traz mais detalhes, é um framework de decisão e orienta sobre como mensurar. Consultorias gostam muito de números e sempre indicam métricas. Assim, a Gartner fornece formas de mensurarmos o que estamos aplicando.
O Okta Zero Trust, lançado em 2019, lida muito com Posture. Vamos discutir bastante sobre Posture em capítulos seguintes, que é a ideia de avaliação dos nossos dispositivos e sinais. Que sinais? Vamos detalhar mais sobre isso durante o curso, como informações sobre geolocalização, biometria, IPs, usuários e diversos outros pontos. Ele tem uma dependência forte do IDP (Identity Provider), que está embarcado nos IAMs Clouds. O Okta complementa o NIST e não o contradiz. É importante entender que nenhum deles contradiz o NIST; eles são sempre complementares, às vezes com foco um pouco diferente de um para o outro.
A Microsoft também apresentou seu modelo de Zero Trust, com princípios de verificação, minimização e assumir a violação como o estado padrão, como já aplicado anteriormente. Assim como o Google foi guiado pelos produtos do Google, a Microsoft é direcionada aos produtos da Microsoft. Mas se aplica apenas a eles? Não, podemos utilizar os mesmos princípios em outras ferramentas. Cada pilar do modelo deles indica uma solução da Microsoft. Por exemplo, se precisamos fazer uma verificação da rede, eles sugerem uma ferramenta específica. Para a verificação do workload, indicam o Microsoft Defender. Eles fazem uma correspondência entre o que precisa ser protegido e uma ferramenta Microsoft para resolver o problema.
De forma geral, todos esses modelos são muito bons e podem ser utilizados de forma independente, mas cada um tem um aspecto diferenciado. O NIST é interessante para a projeção de uma arquitetura. Podemos começar pelo NIST para estratégias de governança, lidando com nossos ativos e recursos. O Forrester, com o ZTX, versão extended, é um framework interessante para ser utilizado. O Google BeyondCorp é adequado para aplicações corporativas e gestão de dispositivos, principalmente. O CARTA é útil para políticas mais dinâmicas. É importante conhecermos todos e aplicarmos de acordo com a necessidade. Lembrando que existem outros modelos mais específicos de fornecedores, como o Okta, que é centrado na identidade, parte da proposta do Zero Trust. Embora centrado na identidade, não se trata apenas de um login; há mais elementos envolvidos. O modelo da Microsoft é voltado para ferramentas da Microsoft ou Microsoft First, mas não exclusivamente Microsoft, inicialmente indicando ferramentas e produtos Microsoft.
Resumindo, o NIST é voltado à arquitetura, o Forrest para estratégia, o BeyondCorp para implementações, lembrando que surgiu no contexto de muitas implementações e não era apenas teórico. O CARTA, pensando no modelo de auditoria e consultoria, oferece uma avaliação contínua e um rico contexto de mensurações de métricas. O Okta, como sistema de identidade, tem uma centralidade em identidade de sinais. A Microsoft aplica princípios inicialmente a produtos Microsoft, que podem ser estendidos para outros.
Com isso, chegamos ao final do nosso segundo bloco e nos encontramos no próximo.
O curso Zero Trust: implementando segurança digital moderna possui 662 minutos de vídeos, em um total de 71 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Impulsione a sua carreira com os melhores cursos e faça parte da maior comunidade tech.
1 ano de Alura
Matricule-se no plano PLUS e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Mobile, Programação, Front-end, DevOps, UX & Design, Marketing Digital, Data Science, Inovação & Gestão, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Acelere o seu aprendizado com a IA da Alura e prepare-se para o mercado internacional.
1 ano de Alura
Todos os benefícios do PLUS e mais vantagens exclusivas:
Luri é nossa inteligência artificial que tira dúvidas, dá exemplos práticos, corrige exercícios e ajuda a mergulhar ainda mais durante as aulas. Você pode conversar com a Luri até 100 mensagens por semana.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para estudantes ultra comprometidos atingirem seu objetivo mais rápido.
1 ano de Alura
Todos os benefícios do PRO e mais vantagens exclusivas:
Mensagens ilimitadas para estudar com a Luri, a IA da Alura, disponível 24hs para tirar suas dúvidas, dar exemplos práticos, corrigir exercícios e impulsionar seus estudos.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
