Senhas, MFA, OAuth 2.0, Tokens JWT e RBAC — Estudos de Cibersegurança

01

Fundamentos de IAM, Governança e o Ciclo IAAA

A disciplina de Gestão de Identidade e Acesso (IAM - Identity and Access Management) estabelece os processos, diretrizes e tecnologias que asseguram que os indivíduos e sistemas corretos tenham o acesso adequado aos recursos corporativos adequados, pelos motivos corretos e no tempo estritamente necessário. Toda a arquitetura de IAM repousa sobre quatro pilares sequenciais e interdependentes conhecidos como o Ciclo IAAA:

1. Identificação (Identification)

O ato de uma entidade declarar quem afirma ser perante o sistema. Não envolve prova imediata de veracidade.
Exemplos: Nome de usuário (username), endereço de e-mail, matrícula funcional, identificador de dispositivo (UUID).

2. Autenticação (Authentication)

O processo criptográfico ou lógico de verificar e comprovar a identidade alegada. O sistema desafia o usuário a apresentar evidências de autenticidade irrefutáveis.
Exemplos: Senha cifrada, código TOTP de 6 dígitos, biometria facial, assinatura com chave privada WebAuthn.

3. Autorização (Authorization)

A determinação das permissões e privilégios concedidos à identidade previamente autenticada sobre recursos específicos.
Exemplos: Verificação de permissão RBAC (leitura de faturamento), escopos OAuth 2.0 (read:reports), políticas ABAC.

4. Auditoria / Rastreabilidade (Accountability)

O registro imutável de eventos (logs) associando cada ação executada à identidade responsável, assegurando não-repúdio.
Exemplos: Logs SIEM de login, emissão de queries com ID do usuário, trilhas de auditoria protegidas contra exclusão.

Princípio do Menor Privilégio e Segregação de Funções (SoD)

O Princípio do Menor Privilégio (Principle of Least Privilege) determina que qualquer usuário, serviço ou aplicação deve possuir apenas os privilégios estritamente indispensáveis para o cumprimento imediato de sua função operacional. Em conjunto, a Segregação de Funções (SoD - Separation of Duties) impede que uma única pessoa detenha controle total sobre processos críticos (por exemplo, quem cadastra uma conta bancária fornecedora não pode ser a mesma pessoa com privilégio para autorizar o pagamento).

O Ciclo de Vida da Identidade: O Processo JML (Joiner, Mover, Leaver)

A governança de identidades deve monitorar todo o ciclo de vida dos colaboradores na organização:

Joiner (Admissão): Criação da identidade com provisionamento automatizado de acessos baseados na função inicial (evitando concessão manual indiscriminada).
Mover (Movimentação/Promoção): Revisão obrigatória de acessos. A grande falha corporativa é o Privilege Creep (acumulação histórica de privilégios de departamentos anteriores). Os privilégios antigos devem ser revogados ao assumir novas atribuições.
Leaver (Desligamento): Desprovisionamento imediato e sistemático (bloqueio de credenciais no IdP, revogação de tokens de sessão ativos e recolhimento de dispositivos) para evitar contas órfãs exploráveis.

02

Armazenamento Seguro de Senhas & Autenticação Multifator (MFA)

Senhas continuam sendo o mecanismo de autenticação primária mais difundido, porém o mais suscetível a erros de implementação. O armazenamento de senhas em bancos de dados corporativos nunca deve ser em texto claro nem através de cifras reversíveis. Mais importante ainda: funções de hash criptográfico tradicionais rápidas (como MD5, SHA-1 e SHA-256) são totalmente inadequadas para armazenamento de senhas.

Por que SHA-256 e MD5 Falham no Armazenamento de Senhas?

Funções de hash de uso geral foram projetadas para serem extremamente rápidas (capazes de validar gigabytes de arquivos em frações de segundo). Um invasor utilizando um rig moderno com 8 placas de vídeo (GPUs RTX 4090) é capaz de computar mais de 100 bilhões de hashes SHA-256 por segundo, permitindo quebrar qualquer senha humana alfanumérica de 8 caracteres em poucos minutos por força bruta ou ataque de dicionário com tabelas pré-computadas (Rainbow Tables).

Para armazenar senhas com resiliência, a indústria de segurança utiliza Funções Adaptativas de Derivação de Chaves (KDFs lentas), que exigem um custo computacional configurável e impõem uso massivo de memória RAM para inviabilizar ataques paralelos em hardware dedicado:

Argon2id (Recomendação Atual)

Vencedor oficial da Password Hashing Competition (PHC). Sua variante Argon2id combina resistência a ataques de canal lateral (side-channel) na CPU e inviabilidade de paralelização massiva em GPUs e circuitos ASIC através de alto consumo forçado de memória RAM (memory-hard function).

bcrypt (Padrão de Mercado)

Baseado na cifra de bloco Blowfish. Utiliza um parâmetro de custo exponencial (work factor de 10 a 14) e um salt criptográfico de 128 bits gerado aleatoriamente por senha. Cada incremento no fator de custo dobra o tempo de cálculo necessário.

PBKDF2 e scrypt

PBKDF2: Padrão NIST com milhares de iterações HMAC (recomendado mínimo 600.000 iterações com HMAC-SHA256).
scrypt: Criado para combater ASICs ao exigir parâmetros de memória estritos (N, r, p).

Os Três Fatores Canônicos de Autenticação

A Autenticação Multifator (MFA) exige que o usuário apresente com sucesso evidências pertencentes a duas ou mais categorias distintas de fatores. Requisitar uma senha e uma pergunta de segurança não é MFA, pois ambas pertencem à mesma categoria de conhecimento.

1. Algo que Você Sabe (Knowledge)

Informação que o usuário retém mentalmente: senhas, códigos PIN alfanuméricos, frases secretas (passphrases).

2. Algo que Você Tem (Possession)

Dispositivo físico ou virtual sob controle do usuário: chaves de segurança USB/NFC (YubiKey), smartphone com aplicativo autenticador, smartcard.

3. Algo que Você É (Inherence)

Características biométricas físicas ou comportamentais: leitor de impressão digital, reconhecimento facial 3D, varredura de íris, padrão de digitação.

A Fragilidade Crítica do MFA por SMS e Chamada Telefônica

O envio de códigos OTP via SMS ou ligação telefônica sofre com ataques de SIM Swapping (clonagem da linha telefônica junto à operadora de telecomunicação por engenharia social) e interceptação de sinalização na rede móvel (vulnerabilidades SS7). O NIST SP 800-63B classifica SMS como um método restrito e desaconselhado para sistemas de alto risco.

TOTP (RFC 6238) vs FIDO2 / WebAuthn

Para superar a fragilidade do SMS, adotam-se geradores criptográficos em aplicativo ou tokens de hardware:

TOTP (Time-Based One-Time Password - RFC 6238): Gera um código temporal (geralmente 6 dígitos) derivado de um segredo compartilhado previamente trocado via QR Code e da contagem de épocas Unix dividida em passos de 30 segundos:
TOTP = Truncate(HMAC-SHA1(SegredoCompartilhado, floor(UnixTime / 30))).
Limitação: Embora excelente contra interceptação de rede, o TOTP ainda é vulnerável a ataques modernos de Phishing com Adversary-in-the-Middle (AiTM) (como ferramentas Evilginx), onde o proxy reverso do invasor repassa o código TOTP digitado pela vítima em tempo real para o serviço legítimo.
FIDO2 e WebAuthn (Passkeys): O padrão ouro da indústria. Utiliza criptografia assimétrica vinculada à origem web (Origin Binding). O navegador e a chave de segurança física (ou enclave seguro do dispositivo) assinam o desafio criptográfico do servidor vinculando o domínio exato (ex: banco.com.br). Se a vítima estiver em um site clonado de phishing (ex: banco-falso.com.br), a chave se recusa a assinar ou assina com credencial inválida para o domínio falso, tornando o phishing tecnicamente inviável.

03

Federação de Identidades, OAuth 2.0 e OpenID Connect (OIDC)

Em ecossistemas modernos com dezenas de aplicações e microsserviços, exigir que cada software armazene suas próprias senhas é uma anti-prática perigosa. A Federação de Identidades centraliza o gerenciamento de credenciais em um Provedor de Identidade (IdP - Identity Provider) confiável (como Okta, Microsoft Entra ID, Keycloak ou Google Workspace).

OAuth 2.0 (RFC 6749)

Protocolo de Autorização Delegada. Permite que uma aplicação de terceiros acerte acesso a recursos de um usuário sem que o usuário precise fornecer sua senha à aplicação.
Exemplo: Permitir que uma ferramenta de calendário acesse sua lista de contatos do Google.
Artefato emitido: Access Token.

OpenID Connect (OIDC)

Camada de Autenticação construída sobre o OAuth 2.0. Fornece a identidade do usuário final para a aplicação cliente. Responde à pergunta: "Quem é este usuário logado?".
Exemplo: Botão "Entrar com Conta Gov.br" ou "Entrar com Google".
Artefato emitido: ID Token (em formato JWT legível).

Os Quatro Papéis Fundamentais do OAuth 2.0

Resource Owner (Proprietário do Recurso): A entidade capaz de conceder acesso a um recurso protegido (tipicamente o usuário final).
Client (Aplicação Cliente): A aplicação que faz solicitações de recursos protegidos em nome do Resource Owner (pode ser uma aplicação web, mobile ou Single Page App).
Authorization Server (Servidor de Autorização): O servidor que autentica o Resource Owner e emite tokens após receber autorização (o IdP).
Resource Server (Servidor de Recursos / API): A API backend que hospeda os recursos protegidos e aceita requisições acompanhadas de um Access Token válido.

Authorization Code Flow com PKCE (RFC 7636)

Historicamente, o fluxo Implicit Flow era utilizado em aplicações frontend (SPAs e Apps Mobile), mas foi depreciado pelo consórcio OAuth devido a riscos de vazamento de tokens em fragmentos de URL. A recomendação obrigatória atual é o Authorization Code Flow com PKCE (Proof Key for Code Exchange).

O cliente gera aleatoriamente um segredo temporário (code_verifier), calcula seu hash SHA-256 (code_challenge) e o envia ao iniciar o fluxo. Ao receber o código de autorização, o cliente envia o code_verifier original via canal seguro. O servidor confere o hash e emite o token. Isso impede que malwares em dispositivos móveis que interceptem o código de autorização consigam trocá-lo pelo token de acesso.

04

Anatomia, Ciclo de Vida e Vetores de Ataque em Tokens JWT

O JSON Web Token (JWT - RFC 7519) é o padrão aberto dominante para transmissão compacta e autossuficiente de declarações (claims) de segurança entre duas partes em formato JSON. Ele é composto por três partes distintas separadas por pontos (.), codificadas no formato Base64URL:

Formato Canônico de um Token JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJ1c2VyIjoiYWxpY2UiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3NzAyODgwMDB9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

1. Header (Cabeçalho)

Define o algoritmo criptográfico utilizado para assinar o token e o tipo do token:
{"alg": "HS256", "typ": "JWT"}
Algoritmos comuns: HS256 (HMAC com SHA-256 simétrico), RS256 (RSA com SHA-256 assimétrico), ES256 (ECDSA com curvas elípticas).

2. Payload (Corpo de Declarações / Claims)

Contém as declarações sobre a entidade (usuário ou serviço) e metadados contextuais:
Claims Registradas (RFC 7519):
• sub (Subject): identificador único do usuário.
• iss (Issuer): entidade emissora do token.
• aud (Audience): destinatários pretendidos do token.
• exp (Expiration Time): timestamp Unix de validade limite.
• iat (Issued At): timestamp Unix de momento de emissão.

3. Signature (Assinatura Criptográfica)

Calculada a partir da concatenação do Header codificado e Payload codificado com a chave de segredo:
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), segredo)
Garante que o payload não foi adulterado em trânsito (integridade e autenticidade).

Atenção Crítica: O JWT Não Criptografa Dados por Padrão!

Uma confusão comum entre desenvolvedores iniciantes é acreditar que o JWT esconde dados confidenciais. A assinatura garante integridade, mas NÃO confidencialidade. Qualquer pessoa com acesso ao token pode decodificar a string Base64URL em texto claro e visualizar todas as claims. Nunca inclua senhas, chaves de API ou dados de cartão de crédito no payload de um JWT assinado comum (JWS). Para confidencialidade, deve ser utilizado o padrão JWE (JSON Web Encryption).

Vulnerabilidades Críticas de Implementação em JWT

Ataque do Algoritmo "none" (Bypass de Assinatura): A especificação RFC 7519 previa o algoritmo "alg": "none" para tokens desprotegidos. Muitas bibliotecas iniciais de backend continham a falha grave de aceitar tokens com "alg": "none" sem assinatura, permitindo que atacantes adulterassem o payload para {"role": "admin"} e obtivessem acesso irrestrito.
Confusão de Algoritmo (Key Confusion / HMAC vs RSA - CVE-2015-9235): Ocorre quando a API espera um token assinado assimetricamente com RSA (RS256), possuindo a chave pública RSA disponível publicamente. Se o atacante trocar o header para HS256 e assinar o token usando a chave pública RSA do servidor como se fosse a chave simétrica secreta, bibliotecas vulneráveis usam a mesma chave para validar HMAC e aceitam a assinatura forjada!
Chaves Secretas Fracas (Brute-Force Offline): Como o invasor possui o Header, Payload e Signature válidos capturados, ele pode testar bilhões de senhas por segundo offline em ferramentas como Hashcat ou jwtcat para descobrir o segredo HMAC simétrico e assinar novos tokens arbitrários.
O Desafio da Revogação de Tokens (Stateful vs Stateless): Por ser autossuficiente e sem estado (*stateless*), um JWT permanece válido até atingir a data de expiração (exp), mesmo que o usuário troque de senha ou seja demitido. Para mitigar isso, arquiteturas seguras utilizam Access Tokens com tempo de vida ultra-curto (ex: 5 a 15 minutos) combinados com Refresh Tokens opacos armazenados em banco de dados e sujeitos a revogação instantânea e rotação automática.

05

Modelos de Controle de Acesso: DAC, MAC, RBAC e ABAC

Após a identidade do usuário ser comprovada pela autenticação, o subsistema de autorização deve decidir se uma requisição para ler, criar, alterar ou excluir um recurso deve ser concedida ou negada. Existem quatro modelos formais consagrados de controle de acesso:

DAC (Discretionary Access Control)

O proprietário do recurso (owner) possui total discricionariedade para conceder ou revogar permissões a outros usuários.
Exemplo: Permissões de arquivos em sistemas operacionais tradicionais (POSIX/Linux: chmod 755 arquivo) ou compartilhamento de documentos no Google Drive.

MAC (Mandatory Access Control)

Controle centralizado imposto pelo sistema operacional baseado em níveis estritos de sensibilidade e autorização de segurança (clearance). Os usuários comuns não podem repassar permissões discricionariamente.
Exemplo: SELinux, AppArmor, modelos militares Bell-LaPadula (Top Secret, Secret, Confidential).

RBAC (Role-Based Access Control)

Permissões são atribuídas a papéis / funções corporativas (Roles), e os usuários recebem papéis. Simplifica drasticamente o gerenciamento de permissões em empresas de médio e grande porte.
Exemplo: Perfil Auditor tem acesso de leitura a relatórios; perfil Financeiro tem permissão de emissão de notas.

ABAC (Attribute-Based Access Control)

Modelo dinâmico que avalia políticas baseadas em atributos múltiplos em tempo de execução: atributos do sujeito (cargo, setor), do recurso (classificação confidencial), da ação solicitada (leitura, escrita) e do contexto ambiental (IP de origem, horário comercial, nível de risco de conformidade do dispositivo).
Exemplo: "Permitir leitura de prontuários médicos apenas se o médico pertencer ao mesmo hospital e a requisição ocorrer durante o plantão ativo via rede interna".

Comparativo Estratégico: RBAC vs ABAC

O RBAC é excelente e amplamente suficiente para a vasta maioria das aplicações de pequeno e médio porte. No entanto, conforme a complexidade da organização cresce, o RBAC sofre com o fenômeno da "Explosão de Papéis" (Role Explosion), onde surgem centenas de papéis micro-específicos (ex: Vendedor_Filial_Sul_Turno_Noite). Nesses cenários hipercomplexos e em arquiteturas modernas de Nuvem e Zero Trust, a transição para ABAC (utilizando motores de política como Open Policy Agent / OPA ou padrões XACML) viabiliza decisões granulares e contextuais de alta precisão.

06

Laboratório Interativo: Decodificador JWT e Avaliador de Matriz RBAC

Experimente na prática o ciclo de inspeção, manipulação e avaliação de segurança de tokens JWT. Neste laboratório interativo desenvolvido em Vanilla JavaScript, você pode inspecionar tokens legítimos, editar claims em tempo real, simular ataques reais (como a injeção do algoritmo none ou forja de assinatura) e avaliar em tempo de execução como um motor de autorização RBAC processa requisições corporativas.

LAB PRÁTICO INTERATIVO

Simulador de Segurança de Tokens JWT e Controle RBAC

Decodifique o token, altere declarações críticas e teste o impacto em permissões corporativas.

Token JWT Codificado (Compact JWS):

Visualização Estrutural do Token

Header (JSON Decodificado)

Payload (Declarações / Claims)

Papel (role):

Validade (exp):

Assinatura Criptográfica

Segredo Simétrico HMAC do Backend:

Motor de Decisão de Controle de Acesso (RBAC)

Avaliação imediata dos privilégios de acesso às operações corporativas com base no token atual:

Operação / Endpoint	Papel Exigido	Decisão do Backend	Justificativa Técnica

07

Checklist de Aplicação Prática: Auditoria e Implementação de IAM

Utilize este checklist técnico durante revisões de arquitetura, auditorias de conformidade (ISO 27001 / LGPD / SOC 2) ou desenvolvimentos de novas aplicações para assegurar que controles fundamentais de identidade foram implementados:

Armazenamento com KDF Lenta e Salt Único: Todas as senhas são armazenadas utilizando exclusivamente Argon2id ou bcrypt com fator de custo verificado, rejeitando terminantemente qualquer uso de hashes simples (MD5, SHA-1, SHA-256) ou reversíveis. Obrigatoriedade de MFA Resistente a Phishing: Contas administrativas, acessos remotos (VPN/ZTNA) e sistemas corporativos críticos exigem MFA, priorizando chaves FIDO2/WebAuthn ou TOTP corporativo, abolindo SMS como fator exclusivo para sistemas confidenciais. Adoção de PKCE em Clientes Públicos (OAuth 2.0): Aplicações Single Page (SPAs) e aplicativos mobile utilizam estritamente Authorization Code Flow com PKCE (RFC 7636), com verificação estrita do code_challenge e descontinuação do fluxo Implicit Flow. Bloqueio Rigoroso do Algoritmo 'none' e Validação de Algoritmos em JWT: O backend impõe uma lista estrita de algoritmos permitidos (whitelisting), rejeita incondicionalmente tokens com "alg": "none" e previne ataques de confusão de chave (HMAC vs RSA). Tokens de Acesso de Curta Duração e Rotação de Refresh Tokens: Access Tokens JWT possuem tempo de expiração curto (5 a 15 minutos), e Refresh Tokens são armazenados com atributos de segurança (HttpOnly, Secure, SameSite) e sofrem rotação a cada uso, com revogação imediata em anomalias. Revisão Periódica de Acessos e Desprovisionamento Automatizado: O processo JML (Joiner, Mover, Leaver) é integrado com sistemas de RH para revogação imediata de contas no desligamento, com auditorias semestrais para erradicação de acúmulo indevido de privilégios (Privilege Creep).

08

Questões de Fixação e Concursos Públicos

Avalie seu entendimento técnico resolvendo questões baseadas em bancas de concursos públicos de alto nível (Cespe/Cebraspe, FGV) e certificações internacionais de segurança (CompTIA Security+, CISSP, CCSP):

Questão 1 • Autenticação Multifator

Em uma auditoria de segurança da informação, um especialista em segurança avalia o mecanismo de autenticação adotado pelos administradores de servidores de banco de dados. Os administradores utilizam uma senha complexa de 16 caracteres e, logo em seguida, respondem a uma pergunta de segurança ("Qual a cidade de nascimento da sua mãe?") cadastrada na criação da conta. Considerando os conceitos normativos de Autenticação Multifator (MFA) do NIST SP 800-63B, é correto afirmar que:

Ver resposta comentada

Gabarito: O procedimento NÃO constitui autenticação multifator (MFA), configurando apenas autenticação de fator único duplo (Two-Step).

Justificativa: Para constituir autenticação multifator (MFA), as credenciais exigidas devem pertencer a categorias distintas de fatores (conhecimento, posse e inerência). Tanto a senha quanto a pergunta de segurança baseiam-se em informações memorizadas, pertencendo exclusivamente à categoria "algo que você sabe" (fator de conhecimento). Para configurar MFA legítimo, o segundo fator deveria pertencer à posse (ex: token físico FIDO2, aplicativo TOTP) ou à inerência (ex: biometria).

Questão 2 • Vulnerabilidades em JWT

Uma equipe de desenvolvimento web implementou autenticação baseada em JSON Web Tokens (JWT). Durante um teste de invasão (pentest), o analista capturou o token de um usuário comum ({"sub":"42", "role":"editor"}), alterou a claim de papel para {"role":"admin"}, modificou o cabeçalho para {"alg":"none", "typ":"JWT"}, removeu completamente a assinatura criptográfica (mantendo o ponto final) e reenviou a requisição para o endpoint de administração da API. O backend processou a requisição com sucesso e concedeu privilégios administrativos. Qual falha estrutural possibilitou essa vulnerabilidade?

Ver resposta comentada

Gabarito: Aceitação incondicional do algoritmo 'none' na verificação do token, permitindo bypass completo da validação de assinatura.

Justificativa: O algoritmo "none" indica tokens não assinados. Bibliotecas ou implementações que não exigem estritamente um algoritmo criptográfico seguro configurado no servidor (algorithm whitelisting) confiam cegamente no valor do cabeçalho enviado pelo cliente. Ao receber "alg": "none", a biblioteca pula a rotina de validação de assinatura e confia nos dados adulterados do payload. A correção definitiva exige rejeitar explicitamente o algoritmo none e forçar a validação com o algoritmo simétrico ou assimétrico esperado pelo servidor.

Questão 3 • Modelos de Autorização (RBAC vs ABAC)

Uma instituição hospitalar necessita implementar uma política de acesso aos prontuários eletrônicos de pacientes com a seguinte regra: "Médicos podem visualizar prontuários de pacientes apenas se estiverem presencialmente no hospital durante seu horário de plantão ativo e se houver vínculo assistencial direto com a ala de internação do paciente." Entre os modelos clássicos de controle de acesso, qual deles é o mais indicado para implementar nativamente essa política sem gerar sobrecarga ou proliferação caótica de perfis estáticos?

Ver resposta comentada

Gabarito: ABAC (Attribute-Based Access Control).

Justificativa: A política descrita depende de variáveis contextuais dinâmicas em tempo real: atributos do usuário (cargo de médico, escala de plantão), atributos ambientais (localização física / IP da rede interna hospitalar, horário da requisição) e atributos do recurso/relacionamento (ala de internação do paciente). Modelos RBAC baseiam-se em papéis estáticos e, para atender a essa regra, causariam uma explosão de papéis (ex: Medico_Plantao_AlaNorte_Dia). O ABAC avalia expressões booleanas sobre múltiplos atributos no momento da requisição, sendo a arquitetura ideal para controle contextual granular.

09

Fatos Essenciais e Próximos Passos

O Ciclo IAAA é Sequencial

Identificação declara quem é; Autenticação prova a declaração; Autorização concede privilégios; Auditoria registra os atos para não-repúdio.

Hashes Rápidos São Proibidos em Senhas

MD5, SHA-1 e SHA-256 sucumbem a ataques de força bruta em GPUs. Utilize Argon2id ou bcrypt com salts aleatórios e alto fator de custo.

FIDO2/WebAuthn Vence o Phishing

Ao vincular criptograficamente o domínio web da origem (Origin Binding) na assinatura, chaves de segurança físicas anulam ataques AiTM.

OAuth 2.0 Não Autentica, Autoriza

OAuth 2.0 fornece Access Tokens para autorização de APIs. Para autenticação federada de usuários, adota-se a camada OpenID Connect (OIDC).

JWT É Assinado, Não Cifrado

Tokens JWS garantem integridade, mas o payload é Base64URL aberto. Nunca insira credenciais sensíveis no payload de um token comum.

Próximo Módulo da Trilha 1

No Estudo 05 (Segmentacao-e-Firewall), você dominará o isolamento de redes, zonas desmilitarizadas (DMZ), tabelas de estado e filtragem de pacotes.