Primeiras aulas do curso
Olá! Meu nome é Danilo Regis. Sou arquiteto de soluções há cerca de 15 anos.
Audiodescrição: Danilo é um homem negro, com barba, pouco cabelo e usa óculos. Veste uma camiseta azul-marinho e está nos estúdios da Alura.
Tenho especialização em segurança da informação e perícia forense computacional. Também tenho pós-graduação em Direito Digital e Compliance (conformidade) e possuo um MBA em Gestão de Empresas pela Fundação Getulio Vargas.
Em muitos incidentes, nós tendemos a atribuir a responsabilidade diretamente à área de cibersegurança e ao que ela deixou de fazer. Entretanto, dentro da própria área de cibersegurança, a pergunta recorrente costuma ser a inversa: como as áreas de arquitetura de sistemas, arquitetura de soluções, arquitetura de software e a própria área de desenvolvimento deixaram de aplicar práticas adequadas, permitindo que uma vulnerabilidade se instalasse no ambiente, nas soluções e nos sistemas?
É esse o conteúdo que nós vamos abordar neste curso de Segurança Arquitetônica e Threat Modeling (modelagem de ameaças).
Durante minha carreira, apoiei empresas pequenas, médias e grandes nas áreas de cibersegurança, arquiteturas de solução e de software, sempre buscando trabalhar de forma que a mitigação de riscos correspondesse às necessidades mais exigentes do mercado, seja altamente regulado, seja orientado a ações contábeis, à saúde, à logística e ao comércio exterior.
Nós vamos passar, ao todo, por sete blocos. O primeiro tratará do conceito da segurança como um requisito arquitetural. Revisaremos o conteúdo de Threat Modeling (modelagem de ameaças), usando dois frameworks (estruturas) como exemplos: STRIDE e PASTA. Abordaremos o conceito e a arquitetura de Zero Trust (confiança zero), amplamente difundida atualmente.
Revisaremos pontos importantes de autenticação e autorização. Vamos falar sobre OpenID Connect (protocolo de autenticação OpenID Connect), SAML (Linguagem de Marcação para Declarações de Segurança) e OAuth 2.0 (protocolo de autorização OAuth 2.0).
Também trabalharemos conceitos relacionados à segurança de APIs (interfaces de programação de aplicações), compreendendo que sempre existe um trade-off (compensação) entre segurança, usabilidade e, muitas vezes, custo.
Ao final, faremos um exercício: a criação de uma arquitetura defensiva baseada no conteúdo aprendido.
Este curso é voltado para profissionais da área de tecnologia que atuam diretamente na criação de soluções. Falamos de pessoas desenvolvedoras, com frequência pessoas analistas de segurança, lideranças técnicas e pessoas arquitetas de solução e de software.
E é isso. Nos vemos no nosso próximo e primeiro bloco.
Vamos começar nosso curso entendendo que a segurança, como requisito arquitetural, existe desde os primeiros sistemas. Nos sistemas mais básicos, havia um usuário administrativo para recursos avançados, enquanto o acesso a ferramentas padrão muitas vezes nem exigia início de sessão. Esse cenário evoluiu devido ao aumento da demanda, do número de sistemas e dos pontos de contato com clientes.
Vejamos um exemplo de incidente que poderia ter sido evitado com medidas relacionadas ao que vamos aprender. Em 2019, a Capital One, uma das principais empresas de cartões de crédito dos Estados Unidos, sofreu um grande vazamento que expôs milhares de dados. O FBI atuou, identificou responsáveis, mas houve um dano expressivo, especialmente à reputação da Capital One, devido à sua relevância no mercado estadunidense. Até hoje, mantêm uma página em seu site explicando exatamente o que aconteceu. Na época, foram transparentes e comunicaram todes os clientes sobre a filtragem: tratava-se dos dados relacionados ao processo de solicitação de cartões de crédito. No processo de solicitação, a pessoa potencial cliente fornecia dados pessoais, dados de contato, dados de endereço, número de seguridade social, e havia uma análise de crédito. Todos esses dados, tanto os fornecidos quanto os relacionados à análise, foram expostos.
É importante entender que o sistema não foi invadido no sentido clássico. Não podemos afirmar simplesmente que um mecanismo de segurança foi quebrado. Nenhuma autenticação foi comprometida, nenhum acesso foi forçado, não houve ataque de força bruta. Nenhuma regra foi violada: as regras do firewall (barreira de rede) e as políticas foram respeitadas. Todas as credenciais em uso eram válidas e o acesso autorizado parecia legítimo. Observamos, portanto, um cenário em que a arquitetura existente não cobriu as necessidades.
O que ocorreu? Houve uma solicitação manipulada: uma entrada externa permitiu ao atacante enviar dados específicos, instruções para que o back-end (camada de servidor) as executasse. Com isso, foi possível acessar recursos porque o back-end tinha acesso livre a determinados componentes e havia uma confiança estabelecida entre o back-end e o que estava dentro da rede. Credenciais foram obtidas e dados foram acessados. O que permitiu esse ataque? Basicamente, quando o back-end recebia instruções, as aceitava sem validação específica, tanto da entrada quanto da saída. É comum validarmos a entrada, mas vamos entender que a saída também pode — e deve — ser validada. A resposta que está sendo devolvida é válida? É possível avaliá-la. O acesso interno não estava restrito; havia uma confiança implícita em tudo que vinha do perímetro.
Nesse caso, o atacante explorou um ataque que chamamos de Server-Side Request Forgery (falsificação de requisição no lado do servidor). Havia um OAuth, que é nosso primeiro ponto aqui de PEP. No nosso bloco sobre Zero Trust (confiança zero), vamos entender que PEP é um ponto de aplicação de políticas, em inglês, Policy Enforcement Point (ponto de aplicação de políticas). O PEP encaminha a solicitação a uma máquina e, mediante credenciais obtidas dentro do próprio ambiente — repare que o atacante não possuía credencial elevada para obter os dados —, o back-end tinha acesso a um cofre que continha essas informações. Assim, os dados puderam ser acessados e entregues como se nada estivesse errado, como se a transação fosse totalmente legítima.
Por que não houve alerta? Porque o acesso foi realizado pelo back-end; isso era esperado. As credenciais eram válidas e não havia sinais de suspeita: tudo funcionou como deveria. Muitas vezes, na área de tecnologia, temos uma falsa sensação de segurança por contarmos com um DLP, Data Loss Prevention (prevenção de perda de dados), uma ferramenta conectada à rede que tenta identificar vazamentos. O DLP funciona muito bem para vazamentos massivos e atípicos, mas, neste caso, as transações pareciam legítimas, e por isso o DLP não identificou nada inadequado.
O impacto para o negócio da Capital One foi grande: mais de 100 milhões de registros de pessoas dos Estados Unidos e do Canadá foram expostos; houve mais de 80 milhões em multas e diversas sanções; e a reputação ficou extremamente prejudicada.
A partir desse ponto, passamos aos problemas arquiteturais que trataremos ao longo do curso. Primeiro, a confiança implícita: a ideia de que, uma vez dentro da rede, tudo é permitido. Se temos acesso ao sistema X, assume-se que tudo o que está atrás do sistema X está liberado. Isso ocorre, por exemplo, quando há uma autenticação em um front-end (camada de apresentação) que chama um back-end. Do back-end para uma derivação, a credencial original se perde e assume-se um usuário sistêmico, um service principal (identidade de serviço). Nessa situação, há uma confiança implícita de que nada que venha do back-end para dentro seja ilegal ou indevido.
Segundo, o modelo perimetral: aquele em que fazemos tratamento apenas na borda, no perímetro. Uma vez passado o perímetro, tudo é considerado seguro. É a lógica por trás da expressão “estou dentro”: ao obter acesso à rede — em filmes, muitas vezes, vemos a tentativa de romper um firewall (barreira de rede) e a celebração quando ele é vencido —, com confiança implícita e segurança perimetral, tudo lá dentro estaria liberado.
Terceiro, a falta de validação, controles insuficientes e ausência de contexto e de intenção. Com base no que está sendo invocado, no que a aplicação deveria fazer e no que ela tem acesso, percebemos que eram partes que não se comunicavam adequadamente.
Diante disso, como pessoas arquitetas, devemos nos perguntar: onde está o problema? O que falta nesse desenho? Como detectar quando ocorre algum tipo de abuso? E como evitá-lo? Precisamos sair da ideia de que ferramentas conectadas nas margens ou tangenciando nossa aplicação são suficientes para detectar esse tipo de problema. Não existe ferramenta plug-and-play (conectar e usar) que, instalada no ambiente, automaticamente o torne Zero Trust (confiança zero).
Vamos aprender que identidade não é suficiente. Uma identidade legítima não implica acesso irrestrito. Uma conta sistêmica não deve ser confiável por si só. Sabemos que às vezes existe a necessidade de usar um usuário sistêmico em aplicações — isso faz parte —, mas hoje já existem modelos mais modernos com OAuth que permitem uma chamada mista, na qual um determinado usuário está embutido dentro do nosso token (token) OAuth ao encaminharmos a requisição adiante. Assim, teremos uma identidade de sistema e também rastreabilidade para saber qual usuário está solicitando informação dentro de um determinado contexto.
Portanto, a confiança não pode ser implícita; o contexto deve ser considerado. Se um cliente acessa, por exemplo, um sistema bancário para realizar uma consulta de informação, isso exige um nível de segurança. Para executar uma transação, o nível é outro. Para alterar um dado cadastral, é um nível diferente. Cada contexto tem um peso, e precisamos graduar a autenticação, por exemplo, incorporando esse nível dentro de um token (token) conforme a necessidade.
Naturalmente, entendemos que a segurança precisa evoluir. Esse incidente ocorreu em 2019, mas, em 2004, um grupo ligado à organização The Open Group (The Open Group), o fórum chamado Jericho Forum (Fórum Jericho), começou a propor uma ideia que, até então, era nova e oferecia uma nova perspectiva sobre como abordamos a segurança. De forma didática, dizemos que o perímetro foi comprometido e já não pode ser defendido. O perímetro é aquela camada externa de segurança da nossa rede.
A premissa é que as cargas de trabalho, nossas aplicações, devem aprender a se proteger por si mesmas e considerar que os ambientes são hostis por padrão. Isso surgiu em 2004 e foi formalizado em 2007, muito antes de o órgão norte-americano de padronização, o NIST (Instituto Nacional de Padrões e Tecnologia), lançar a arquitetura Zero Trust (confiança zero) em 2020. A segurança como requisito foi incluída na ISO (Organização Internacional de Padronização) em 2011, como um atributo de qualidade.
Sempre temos requisitos funcionais e requisitos não funcionais. Muitas vezes, a área de desenvolvimento acredita que, se a área de negócios não solicitar determinadas medidas de segurança, elas não são necessárias. Nós costumamos classificar isso como uma falha de entendimento. Um exemplo: nenhuma pessoa profissional de medicina precisa que lhe digam para lavar as mãos antes de uma cirurgia; nenhuma pessoa instrumentista precisa que lhe digam para higienizar os instrumentos. Espera-se que, ao contratar uma pessoa cirurgiã, médica ou instrumentista, ela saiba executar o procedimento da forma mais segura possível. O mesmo se aplica a uma pessoa analista de sistemas, a uma pessoa desenvolvedora, a uma pessoa programadora ou à liderança técnica (tech lead, liderança técnica). Espera-se que cuidemos desse tipo de aspecto. A área de negócios fornecerá requisitos de negócio, e a área técnica deve incorporar isso nas especificações do sistema, deixando claro qual é o risco se algo não for incluído dentro da sprint (iteração) e da aplicação.
Afirmamos, então, que toda decisão de arquitetura implica risco. Por exemplo, quando utilizamos um ambiente elástico, corremos o risco de ele não evoluir adequadamente para responder à demanda. Em uma Black Friday (sexta-feira de descontos), é comum aumentar o número de pods e de microserviços antes do pico, para que já estejam carregados e prontos para uso. Isso implica elevar o custo antes de existir a demanda real. Logo, toda decisão implica algum tipo de risco, seja operacional, financeiro ou reputacional. Precisamos tomar decisões de forma consciente e mitigar onde for possível.
Devemos dar atenção especial a cinco domínios:
Há consequências arquitetônicas importantes. O egress (saída de dados) é um ponto de atenção: entender o que está saindo é tão importante quanto validar entradas. Precisamos de validação contínua de acesso: não é porque uma pessoa usuária possui um JWT (JSON Web Token) que concederemos carta branca, pois o token pode ter sido comprometido. Adotamos monitoramento comportamental, logs (registros) e rastreabilidade, além de políticas adaptativas para oferecer fricção proporcional à necessidade.
Não podemos desconsiderar impactos financeiros diretos e indiretos. Falamos de gastos operacionais e de custos decorrentes de processos legais. No Brasil, temos a LGPD; na Europa, a GDPR (Regulamento Geral de Proteção de Dados); cada país terá sua própria legislação. Existem também impactos reputacionais que podem afetar o aspecto financeiro, reduzindo o valor das ações de uma empresa. Tudo isso sempre competirá por investimentos; ao elaborarmos uma lista de investimentos, precisaremos equilibrar quando e quanto investir para obter segurança e previsibilidade. Frequentemente, o que as pessoas acionistas desejam é previsibilidade. Assim, um investimento muitas vezes funciona como um seguro: alocamos recursos para obter estabilidade no ambiente e sermos percebidos externamente como uma empresa estável. Quanto maior a estabilidade, maior tende a ser a capacidade de captação de investimentos.
Para atribuir números às nossas avaliações, muitas vezes qualitativas, podemos utilizar o framework FAIR (Análise de Fatores de Risco de Informação), que ajuda a medir e quantificar riscos. Nesse fluxo, a arquitetura dá uma direção; a área de segurança realiza uma avaliação de ameaças, frequentemente fornecendo retorno e solicitando algum ajuste ou mitigação; a área de negócios define seu apetite de risco. Um exemplo clássico é o de um supermercado com alto volume de atendimento: sabe-se que haverá alguns casos de fraude, mas o negócio aceita esse risco porque compensa. Assim, o apetite de risco é definido pelo negócio e, estando a decisão documentada, seguimos com o risco mitigado na medida adequada, sempre de forma consciente.
Existem compensações inevitáveis:
Nenhuma decisão é neutra. Sempre colocaremos na balança o que faz mais sentido. Segurança mal projetada compromete diversos pontos, gera retrabalho e pode comprometer o negócio. O negócio pode afirmar que não tinha conhecimento do risco. Por exemplo, entregamos uma solução para a Black Friday (sexta-feira de descontos) cumprindo o Time to Market (tempo de chegada ao mercado), mas ocorreu uma filtragem de dados. Muitas vezes, o negócio argumenta: “Entendemos que vocês encontrariam uma forma de cumprir o prazo com segurança.” Em muitos casos, a área técnica assume o risco sem comunicá-lo ao negócio. Precisamos documentar as etapas, formalizar a carta de riscos e colocar todas as informações sobre a mesa para a tomada de decisão.
Algumas referências técnicas que utilizaremos ao longo do curso: ISO (Organização Internacional de Padronização), NIST (Instituto Nacional de Padrões e Tecnologia), FAIR (Análise de Fatores de Risco de Informação) e TOGAF (The Open Group Architecture Framework, estrutura de arquitetura corporativa).
Em síntese, a segurança é obrigatória, não é opcional. A área de negócios pode não solicitá-la explicitamente, mas cabe à arquitetura e às análises considerá-la. Segurança não está isolada; ela está atrelada à jornada do negócio, à previsibilidade e aos trade-offs (compensações). Não é gratuita: envolve custos no sentido amplo, como latência, infraestrutura, perdas financeiras, reputação e processos legais. Tratamos a segurança como aspecto arquitetônico essencial para que o sistema funcione da maneira mais adequada, entendendo requisitos de negócio, atributos de qualidade e restrições.
Com isso, finalizamos este bloco e seguimos adiante.
Vamos apresentar agora dois frameworks (estruturas de referência) para modelagem de ameaças. Naturalmente, não são os únicos existentes, mas servem perfeitamente para ilustrar o que devemos buscar e utilizar em nossas arquiteturas. Esse tipo de trabalho tem mais valor quando é realizado em tempo de projeto. Daí o conceito de Segurança desde o projeto. Poderia ser feito a posteriori, quando a aplicação já está sendo construída ou até mesmo quando está em produção? Sim, certamente também pode ser feito. Porém, idealmente, é algo a ser realizado de forma antecipada. Também pode ser conduzido de modo granular. Em um processo ágil, no qual especificamos uma feature em cada sprint, por exemplo, podemos executá-lo continuamente, envolvendo os riscos de negócio, modelando e mitigando esses riscos.
O framework (estrutura de referência) PASTA, Process for Attack Simulation and Threat Analysis (Processo para Simulação de Ataques e Análise de Ameaças), trata precisamente do vínculo entre os objetivos de negócio e o impacto que um incidente pode causar. Isso fica mais claro quando o correlacionamos com TOGAF, The Open Group Architecture Framework (Estrutura de Arquitetura do The Open Group), um framework (estrutura de referência) de arquitetura empresarial que começa no modelamento dos serviços de negócio. Assim, analisamos nosso fluxo de valor, nosso value stream (fluxo de valor), o que estamos entregando, quais são nossas capacidades de negócio correlacionadas, qual é o impacto disso para nossa camada estratégica, o que a empresa busca e como essa realização de negócio avança na direção da estratégia da organização. Em seguida, descemos para a camada de aplicação, a qual será sustentada por uma camada de tecnologia.
Quando estamos na fase de design, design (projeto) da solução, analisamos a estratégia da empresa, observamos o objetivo de negócio e criamos algo para suportá-lo. Quando ocorre um incidente, fazemos o caminho inverso. Observamos, por exemplo, um microserviço ou um servidor, verificamos qual é a aplicação que está em execução nele e qual é a capacidade de negócio correlacionada. Com isso, conseguimos, por exemplo, entender qual é o impacto de uma interrupção do sistema e qual é o impacto de um vazamento de informações.
Por outro lado, temos o STRIDE. STRIDE é um framework (estrutura de referência) técnico. É técnico porque não conhece o negócio; reconhece que existem determinados riscos tecnológicos. O que ele estabelece? Cada letra da palavra STRIDE tem um significado:
S — Spoofing (falsificação): falsificação de identidade ou de atributos. Pode ocorrer, por exemplo, quando uma pessoa atacante manipula o cabeçalho (header) de uma chamada HTTP, simulando que está usando um agente “seguro” quando, na realidade, está usando um script — declara “estou usando Chrome, estou usando Safari”. Também pode ser feito para manipular dados de usuário, como ao alterar o X-Forwarded-For, o IP de origem da chamada. Essas informações são suscetíveis a spoofing; devemos usá-las, mas não confiar 100%.
T — Tampering (adulteração/alteração): alteração de dados ou do fluxo de dados.
R — Repudiation (repúdio): ocorre quando uma pessoa atacante ou uma pessoa usuária consegue afirmar que determinada ocorrência ou registro é ilegítimo. Por exemplo, no processo de contratação de cartão de crédito, como no cenário da Capital One: uma pessoa cliente adquire um cartão, realiza compras e, ao receber a fatura, alega que não foi ela nem solicitou o cartão. Como garantimos o não repúdio? Podemos nos precaver usando, por exemplo, biometria e certificado digital.
I — Information Disclosure (exposição de informações): a conhecida fuga, nosso leak (vazamento) de informação.
D — Denial of Service (negação de serviço): base do famoso ataque DDoS (ataque de negação de serviço distribuído), que sobrecarrega determinadas instâncias de serviço até que caiam.
E — Elevation of Privilege (elevação de privilégios): quando a pessoa usuária consegue escalar privilégios; começa com determinados acessos e obtém outros acessos de qualquer tipo, por alguma estratégia utilizada para isso.
As limitações do STRIDE residem no fato de ser extremamente técnico. Não conhece o negócio, não prioriza exatamente os riscos e não sabe se uma determinada aplicação movimenta transações de pagamento ou consultas de relatórios. É algo muito mais simplificado e, muitas vezes, transforma-se em uma espécie de checklist (lista de verificação) que pode ser executada de forma muito mecânica. Assim, recebemos da área de riscos as indicações e apenas registramos: “mitigado, mitigado, é muito comum, não precisamos nos preocupar com isso”. Esse é um risco que corremos com todos os checklists que caem na rotina.
As aplicações práticas desses frameworks (estruturas de referência) são, precisamente, identificar os ativos, os riscos envolvidos e o impacto a ser explorado. Tomamos algo muito técnico e o correlacionamos com algo muito específico do negócio. Perguntamos: como ocorreria o ataque? Essa é a ideia de pensar como uma pessoa atacante. Diante de uma aplicação, olhamos para o STRIDE e avaliamos como ela poderia ser afetada por um ataque.
Podemos avaliar se é possível realizar um spoofing. Também podemos questionar se um serviço pode ser derrubado. Nesse contexto, definimos, por exemplo, um rate limit (limite de taxa), pois corremos o risco de um ataque de negação de serviço ao depender de um sistema legado que não suporta mais de 100 chamadas por segundo.
Esse é o olhar crítico: o que permite esse tipo de ataque? É o caso de implementar um captcha (verificador humano) no front-end (camada de interface)? É o caso de adotar algum tipo de token (comprovante de acesso) específico por chamada? Cada caso é um caso e, naturalmente, sempre buscamos entender como reduzir determinado risco.
Um exemplo de ferramenta interessante e gratuita é a Microsoft Threat Modeling Tool (ferramenta de modelagem de ameaças da Microsoft), que estamos apresentando. Como funciona? De forma semelhante a outras ferramentas de diagramação, como o Draw.io (ferramenta de diagramação) ou o Diagrams.net (ferramenta de diagramação), nas quais posicionamos os elementos e os interconectamos. Podemos incluir, de maneira interligada, cada um dos elementos do sistema. No exemplo, adicionamos um navegador, o Azure Storage (armazenamento do Azure), equivalente a um bucket (repositório) do S3, um banco de dados Redis, um banco de dados SQL, uma Web API e um cliente móvel.
Ao fazermos isso, a ferramenta apresenta uma série de riscos classificados com STRIDE. Nesse caso, temos riscos como negação de serviço, adulteração de dados em uma API, repúdio, elevação de privilégios e spoofing. Quando clicamos na linha respectiva, visualizamos, na parte inferior, as propriedades da ameaça. O primeiro item editável é o Estado. Esse campo existe porque a ferramenta, além de modelar, permite trabalhar o processo de mitigação. Ao clicar em Estado, abre-se uma lista na qual podemos alterar o risco para “requer investigação” (needs investigation), “não se aplica” ou “mitigado”. Cada um desses itens corresponde a uma etapa do processo de avaliação.
É importante lembrar que, ao colocarmos uma base de dados, uma Web API e a comunicação entre elas, a ferramenta não sabe se estamos apenas realizando uma consulta simples de uma imagem ou acessando dados muito sensíveis, dados restritos ou informações financeiras. Ela desconhece o contexto; sabe apenas que existe uma API e uma base de dados. Por isso, com o conhecimento do negócio, podemos alterar a severidade: muito alta, média ou baixa.
Também existe uma indicação de em que momento a ameaça precisa ser mitigada. O próprio mecanismo de Threat Modeling (modelagem de ameaças) indica que determinada situação deve ser tratada no SDL (Software Development Lifecycle, ciclo de vida de desenvolvimento de software), isto é, na fase de implementação ou na fase de desenho (design). Também é possível gerar um relatório completo, incluindo as possíveis mitigações e a fase respectiva. Ao gerarmos um relatório, obtivemos um HTML destacando cada uma das etapas inseridas no diagrama. Por exemplo: entre a Web API e o Azure Storage, qual é o risco? Em seguida, cada risco é listado. Da mesma forma, para a comunicação entre a Web API e o fluxo para uma base de dados, constam riscos como elevação de privilégios e fuga de informação. Para cada bloco, há uma indicação correspondente. Podemos usar esse material para a tomada de decisão.
Outra ferramenta à qual podemos recorrer são os famosos GPTs (modelos generativos pré-treinados). Temos na tela um exemplo de prompt (instrução) que pode ser utilizado em um GPT para realizar uma avaliação de ameaças com base em um diagrama. Trouxemos o diagrama apresentado no primeiro bloco do curso, que é o do caso Capital-UA. Inserimos uma camada de OAuth, um Workload (carga de trabalho), o IMDS (Instance Metadata Service, serviço de metadados da instância) — metadados acessados pela própria EC2 —, as roles (funções) do IAM, um bucket (repositório) do S3 e o monitoramento.
Ao utilizarmos esse prompt para gerar um log (registro) com todos os riscos do STRIDE, obtemos, por exemplo, o risco de spoofing, uma explicação de que uma pessoa invasora pode forjar uma solicitação e uma indicação de possível mitigação: implementar o IMDS v2 — exatamente o que foi feito no caso Capital-UA. A primeira versão do serviço de metadados era apenas o IMDS; hoje já se utiliza a v2, que não apresenta o mesmo risco de coleta de credenciais para acesso a outros recursos. De fato, o Copilot e o Gemini apontaram exatamente a mitigação aplicada no caso Capital-UA. Além disso, há a indicação da fase em que isso deve ser implementado e uma lista de impactos de negócio: risco alto, com possibilidade de roubo de credenciais temporárias da role (função) do IAM — exatamente o que ocorreu em 2019. Naquele momento, ainda não havia a v2 do IMDS.
Temos, portanto, uma lista de riscos de adulteração e de repúdio, entre outros. Ao simplesmente fornecer um diagrama — já testamos com C4 e com ML —, o processo funciona perfeitamente. Obtemos um direcionamento inicial: se não soubermos por onde começar, basta inserir o diagrama no Copilot e solicitar uma lista detalhada para ser avaliada e mitigada dentro da solução.
Com isso, finalizamos mais um bloco do curso e nos encontramos a seguir no bloco número 3.
O curso Segurança Arquitetural: modelagem de ameaças e Zero Trust possui 152 minutos de vídeos, em um total de 38 atividades. Gostou? Conheça nossos outros cursos de Arquitetura de Software em Back-end, ou leia nossos artigos de Back-end.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Todos os cursos, trilhas e certificados para evoluir.
7 dias para cancelar com reembolso
Aprenda mais rápido com IA, idiomas e imersões.
7 dias para cancelar com reembolso
TUDO DO PLUS, MAIS:
Aceleração de carreira: mentoria, vagas e prática guiada.
7 dias para cancelar com reembolso
TUDO DO PRO, MAIS:
