Proteção de Redes, Aplicações e Segredos no Azure

radio_button_uncheckedshort_text 1. Introdução: do perímetro físico à infraestrutura definida por software

A segurança de redes nasceu em ambientes nos quais servidores, usuários e equipamentos estavam concentrados dentro de prédios e datacenters. Roteadores, listas de controle de acesso e firewalls formavam um perímetro relativamente estável entre a rede interna e a internet. Com virtualização, aplicações web, dispositivos móveis e computação em nuvem, esse perímetro tornou-se distribuído. Redes, regras de tráfego, balanceadores e cofres de segredos passaram a ser configurados por software e consumidos como serviços.

Essa transformação contribui diretamente para organizações e para a sociedade porque serviços essenciais - bancos, hospitais, escolas, governos e plataformas de comunicação - dependem de disponibilidade, confidencialidade e integridade. Uma arquitetura bem protegida reduz interrupções, vazamentos e fraudes, além de permitir inovação com riscos controlados. O desafio é compreender que “estar na nuvem” não torna um sistema automaticamente seguro: a Microsoft protege a plataforma, enquanto o cliente deve configurar adequadamente redes, identidades, aplicações e dados.

Ao longo deste capítulo, pense em uma aplicação de três camadas: uma interface web exposta ao público, uma API interna e um banco de dados. Cada serviço estudado responde a uma pergunta diferente. Um ataque volumétrico exige mitigação DDoS; uma exploração HTTP exige WAF ; o tráfego entre sub-redes exige NSGs e, em cenários centralizados, Azure Firewall; a administração de VMs exige Bastion; senhas, chaves e certificados exigem Key Vault . Entender essas fronteiras é mais importante do que memorizar nomes.

Pergunta-guia

Se uma aplicação usa WAF , ela ainda precisa de NSG , Azure Firewall, DDoS Protection e Key Vault ? Sim. Cada controle atua em uma superfície, camada ou objetivo distinto.

1.1 Segurança como arquitetura, não como produto isolado

Defesa em profundidade significa combinar controles preventivos, detectivos e responsivos. Um controle pode falhar, ser contornado ou não enxergar determinado tipo de tráfego. A segmentação limita o movimento lateral; um firewall central controla rotas e destinos; o WAF entende protocolos web; o Key Vault reduz a exposição de credenciais. O resultado é uma sequência de barreiras complementares, e não uma promessa de invulnerabilidade.

radio_button_uncheckedshort_text 2. Fundamentos técnicos: camadas, fluxos e estado

2.1 Camadas de rede e aplicação

Para o SC-900, não é necessário memorizar todo o modelo OSI, mas é essencial diferenciar controles de rede e de aplicação. Camadas 3 e 4 lidam principalmente com endereços IP , protocolos de transporte e portas, como TCP 443 ou UDP 53. A camada 7 interpreta o protocolo da aplicação, por exemplo métodos, cabeçalhos, caminhos e conteúdo HTTP . DDoS Protection atua principalmente contra ataques de rede L3/L4; NSGs filtram fluxos por IP , porta e protocolo; o WAF analisa HTTP / HTTPS em L7. Azure Firewall combina inspeção stateful , regras de rede e regras orientadas a aplicações e destinos.

2.2 Tráfego norte-sul e leste-oeste

Tráfego norte-sul entra ou sai do ambiente, como usuários acessando um site ou servidores consultando a internet. Tráfego leste-oeste circula entre componentes internos, como uma API acessando um banco de dados ou duas redes virtuais trocando informações. Uma arquitetura segura controla ambos: a borda não deve ser a única barreira, pois um invasor que compromete um componente pode tentar movimentar-se internamente.

2.3 Filtragem stateful e stateless

Um controle stateful acompanha o estado de uma conexão. Quando um fluxo de saída permitido inicia uma sessão, o tráfego de resposta correspondente pode ser reconhecido sem uma regra espelhada manual. NSGs e Azure Firewall são stateful . Isso não significa que “todo retorno é permitido”; significa que o serviço relaciona os pacotes à conexão autorizada. Controles stateless avaliam pacotes de forma independente e normalmente exigem regras explícitas para cada direção.

2.4 Cinco elementos de um fluxo

Conceito-chave para prova

Porta 443 não significa automaticamente “tráfego seguro”. TLS protege a comunicação, mas uma requisição HTTPS ainda pode carregar uma tentativa de SQL injection. Por isso o WAF continua relevante.

radio_button_uncheckedshort_text 3. Azure Virtual Network, sub-redes e segmentação

Azure Virtual Network, ou VNet, é a base da rede privada no Azure . Ela fornece um espaço lógico e isolado no qual recursos podem comunicar-se usando endereços IP privados. Uma VNet existe em uma região, pode abranger zonas de disponibilidade dessa região e pode conectar-se a outras redes por peering, VPN ou ExpressRoute. O isolamento entre VNets é uma propriedade importante: redes diferentes não se comunicam automaticamente, a menos que uma conexão seja criada.

3.1 Espaço de endereçamento e CIDR

Ao criar uma VNet, define-se um ou mais blocos de endereços, normalmente privados conforme RFC 1918, como 10.20.0.0/16. A notação CIDR informa quantos bits identificam a rede. Um bloco /16 contém mais endereços que um /24. O planejamento evita sobreposição com redes locais e com outras VNets, pois intervalos sobrepostos dificultam peering, VPN e roteamento.

3.2 Sub-redes como limites funcionais e de segurança

Uma subnet divide o espaço da VNet. Em vez de colocar todos os recursos no mesmo segmento, a organização separa componentes por função, sensibilidade ou necessidade de comunicação. Uma camada web pode aceitar tráfego do balanceador; a camada de aplicação aceita somente chamadas da web; a camada de dados aceita somente a porta do banco proveniente da aplicação. Essa organização reduz a superfície de ataque e facilita a aplicação de NSGs e rotas.

3.3 Conectividade não equivale a autorização

VNet e peering criam caminhos de rede; eles não substituem autenticação, autorização ou controles da aplicação. Da mesma forma, bloquear uma porta não substitui o princípio do menor privilégio em identidades. Segurança de rede limita “quem consegue alcançar o serviço”; identidade e autorização definem “quem pode usar o serviço e o que pode fazer”.

radio_button_uncheckedshort_text 4. Network Security Groups (NSGs)

Um Network Security Group filtra tráfego de entrada e saída associado a sub-redes ou interfaces de rede. Ele contém regras que permitem ou negam fluxos com base em prioridade, direção, protocolo, origem, destino e portas. NSGs são controles distribuídos e stateful : ficam próximos dos recursos e são adequados para restringir comunicação entre camadas.

4.1 Componentes de uma regra

4.2 Regras padrão

O Azure cria regras padrão de menor prioridade. Elas permitem tráfego dentro da VNet, permitem respostas associadas a determinados serviços de plataforma e negam entrada vinda da internet, enquanto a saída para internet é permitida por padrão em muitos cenários. Regras personalizadas de prioridade maior podem alterar o resultado. Para a prova, o ponto principal é que regras são processadas por prioridade até que uma correspondência seja encontrada.

4.3 Service tags e Application Security Groups

Service tags representam conjuntos de prefixos IP mantidos pelo Azure , como Internet, VirtualNetwork ou serviços específicos. Application Security Groups permitem agrupar interfaces de máquinas virtuais por função lógica, como WebServers ou DatabaseServers, reduzindo dependência de endereços individuais. Esses recursos tornam regras mais legíveis e adaptáveis.

Exemplo

A subnet de aplicação pode aceitar TCP 443 somente do grupo WebServers e negar outras origens. A subnet de banco pode aceitar TCP 1433 somente do grupo AppServers. Assim, mesmo que um host web seja comprometido, o caminho até outros recursos permanece limitado.

4.4 O que um NSG não faz

• Não analisa SQL injection, XSS ou semântica HTTP .
• Não é um proxy de aplicação nem um serviço de publicação web.
• Não substitui uma solução central de firewall quando são necessários controle de egress, NAT , inspeção avançada ou políticas entre muitas redes.
• Não armazena segredos e não autentica usuários finais.

radio_button_uncheckedshort_text 5. Azure Firewall

Azure Firewall é um firewall como serviço, nativo da nuvem, totalmente stateful e com alta disponibilidade integrada. Ele pode inspecionar tráfego norte-sul e leste-oeste , funcionando como ponto central de controle em arquiteturas hub-and-spoke. Em vez de administrar appliances virtuais individualmente, a organização usa um serviço gerenciado que escala com a plataforma.

5.1 Tipos de regras

5.2 Azure Firewall versus NSG

NSG é um filtro distribuído aplicado a subnets e interfaces. Azure Firewall é um serviço centralizado pelo qual o tráfego pode ser roteado. Em ambientes pequenos, NSGs podem atender a vários requisitos básicos. Em arquiteturas corporativas, o firewall centraliza egress, inspeção, NAT , logs e políticas entre múltiplas redes. Frequentemente ambos são usados: o firewall controla caminhos centrais e os NSGs impõem microssegmentação local.

5.3 SKUs e profundidade

A documentação atual apresenta SKUs Basic, Standard e Premium. A escolha depende de escala e recursos, como filtragem avançada, inspeção TLS e sistemas de prevenção de intrusão disponíveis em camadas superiores. Para o SC-900, é mais importante reconhecer o Azure Firewall como firewall de rede gerenciado e stateful do que memorizar todos os limites comerciais de cada SKU.

Armadilha de prova

Azure Firewall e WAF não são sinônimos. O Firewall protege fluxos de rede e destinos de forma ampla; o WAF é especializado em ataques contra aplicações web e interpreta HTTP / HTTPS .

5.4 Rotas definidas pelo usuário

Para garantir que o tráfego passe pelo Azure Firewall, subnets podem utilizar tabelas de rotas e rotas definidas pelo usuário, conhecidas como UDRs. Esse padrão é chamado forced tunneling quando a organização força determinado tráfego por um ponto de inspeção. Sem planejamento de rotas, criar um firewall não garante que todos os fluxos o atravessem.

radio_button_uncheckedshort_text 6. Azure Web Application Firewall ( WAF )

O Azure Web Application Firewall fornece proteção centralizada para aplicações web contra explorações e vulnerabilidades comuns. Ele opera na camada de aplicação, entendendo requisições HTTP e HTTPS . Pode ser integrado ao Azure Application Gateway , para entrada regional, e ao Azure Front Door, para entrada global na borda. O WAF reduz a necessidade de implementar a mesma proteção isoladamente em cada aplicação, embora não elimine correções no código.

6.1 Ataques e anomalias observados

• SQL injection: tentativa de manipular consultas ao banco por entradas maliciosas.
• Cross-site scripting ( XSS ): inserção de scripts em páginas consumidas por outros usuários.
• Inclusão de arquivos, command injection e violações de protocolo HTTP .
• Bots, scanners, padrões de reputação de IP e volume excessivo, conforme recursos e regras disponíveis.
• Cabeçalhos, caminhos, métodos e parâmetros incompatíveis com políticas definidas.

6.2 Regras gerenciadas e regras personalizadas

Conjuntos de regras gerenciadas são mantidos para detectar classes conhecidas de ataques, frequentemente alinhadas às categorias OWASP . Regras personalizadas permitem bloquear ou permitir com base em endereço, país/região, cabeçalho, caminho, tamanho, taxa e outras condições. Em modo de detecção, o WAF registra correspondências; em modo de prevenção, pode bloquear solicitações. A implantação deve começar com observação e ajuste para reduzir falsos positivos.

6.3 WAF não substitui desenvolvimento seguro

Um WAF é uma camada compensatória. Ele pode bloquear uma carga conhecida, mas não corrige falhas de autorização, lógica de negócio, exposição indevida de APIs ou segredos no código. Aplicações continuam precisando de validação de entrada, autenticação, autorização, correção de dependências e testes de segurança.

radio_button_uncheckedshort_text 7. Azure DDoS Protection

Um ataque distribuído de negação de serviço, ou DDoS, tenta esgotar largura de banda, conexões, CPU, memória ou outros recursos para tornar um serviço indisponível. Ele é distribuído porque utiliza muitas origens, frequentemente dispositivos comprometidos. Qualquer endpoint publicamente acessível pode ser alvo.

7.1 Proteção de infraestrutura e proteção aprimorada

A plataforma Azure possui proteção de infraestrutura contra ataques comuns. Azure DDoS Protection adiciona recursos aprimorados e adaptados aos recursos protegidos. A documentação atual diferencia DDoS Network Protection, associado a redes virtuais por meio de um plano, e DDoS IP Protection, habilitado por IP público. Ambos compartilham recursos centrais de engenharia, mas diferem em modelo comercial e serviços adicionais.

7.2 Como o serviço atua

• Monitoramento contínuo dos padrões de tráfego.
• Ajuste adaptativo de limites com base no perfil do recurso.
• Mitigação automática quando o tráfego excede parâmetros de ataque.
• Métricas, alertas, logs e relatórios para investigação.
• Proteção de vetores de camada 3 e 4, como floods TCP , SYN e UDP .

7.3 DDoS Protection e WAF são complementares

DDoS Protection é especializado em disponibilidade e ataques volumétricos de rede. O WAF protege a lógica HTTP /S e pode aplicar rate limiting ou regras contra bots e explorações. Uma aplicação web crítica frequentemente usa ambos: DDoS para L3/L4 e WAF para L7. Azure Front Door também oferece proteção de borda e integração com WAF , mas o conceito examinável permanece o uso de camadas complementares.

Não confunda

DDoS não significa invasão bem-sucedida nem roubo de dados. O objetivo principal é indisponibilidade. Contudo, ataques podem ser combinados com outras técnicas ou usados como distração, por isso monitoramento e resposta continuam necessários.

7.4 Resiliência é parte da defesa

Mitigação não substitui arquitetura resiliente. Distribuição regional, zonas de disponibilidade, balanceamento, autoscale, caching e planos de resposta reduzem impacto. Segurança de disponibilidade depende de serviço de proteção e de desenho capaz de continuar operando durante falhas ou picos.

radio_button_uncheckedshort_text 8. Comparando DDoS Protection, NSG , Azure Firewall e WAF

8.1 Como resolver questões por eliminação

1. Identifique o ativo: IP público, subnet, fluxo entre redes, aplicação HTTP ou máquina virtual. 2. Identifique a ameaça: inundação, porta indevida, destino não autorizado, exploração web ou exposição administrativa. 3. Observe a camada: L3/L4 favorece DDoS, NSG ou Firewall; L7 favorece WAF . 4. Procure palavras-chave: “sem IP público para RDP / SSH ” aponta para Bastion; “segredos, chaves e certificados” aponta para Key Vault .

Regra mental

Disponibilidade volumétrica = DDoS. Filtragem distribuída = NSG . Controle central de rede = Azure Firewall. Ataque HTTP = WAF . Administração privada = Bastion. Material secreto = Key Vault .

radio_button_uncheckedshort_text 9. Azure Bastion

Azure Bastion é um serviço PaaS gerenciado para conexão RDP e SSH a máquinas virtuais por meio de TLS . Ele é implantado na rede virtual e permite alcançar VMs usando endereços IP privados. O benefício central é evitar IP público diretamente na VM e reduzir a exposição das portas administrativas 3389 e 22 à internet.

9.1 Por que abrir RDP / SSH para a internet é arriscado

Serviços administrativos expostos recebem varreduras, tentativas de senha, exploração de vulnerabilidades e ataques automatizados. Mesmo com NSG restrito a determinados endereços, mudanças de origem e erros de regra podem ampliar a exposição. Bastion cria um ponto gerenciado de entrada, enquanto as VMs permanecem privadas.

9.2 O que o Bastion oferece

• Sessões RDP ou SSH protegidas por TLS .
• Conexão pelo portal e, conforme SKU, por clientes nativos e recursos adicionais.
• Ausência de agente especial dentro da VM para o cenário principal.
• Redução de IPs públicos e de portas administrativas expostas.
• Possibilidade de recursos de auditoria e gravação de sessão em ofertas específicas.

9.3 O que o Bastion não resolve sozinho

Bastion não substitui autenticação forte, RBAC , atualização do sistema operacional, proteção de endpoint , logs e princípio do menor privilégio. Um administrador excessivamente privilegiado continua sendo um risco. O serviço protege o caminho de rede; a identidade e o sistema operacional ainda precisam de controles próprios.

Detalhe de arquitetura

Implantações dedicadas utilizam uma subnet reservada chamada AzureBastionSubnet. Essa subnet deve ser planejada conforme requisitos atuais do serviço e não deve hospedar workloads comuns.

radio_button_uncheckedshort_text 10. Azure Key Vault : segredos, chaves e certificados

Azure Key Vault é um serviço de nuvem para armazenar e acessar material sensível com controle rigoroso. Ele reduz a prática insegura de inserir senhas, tokens ou chaves em código-fonte, variáveis compartilhadas, arquivos de configuração, pipelines ou imagens de contêiner. O serviço separa a aplicação do ciclo de vida das credenciais e fornece autorização, auditoria e integração com identidades do Microsoft Entra .

10.1 Três tipos principais de objetos

10.2 Vault e Managed HSM

Cofres do Key Vault armazenam segredos, chaves e certificados; chaves podem ser protegidas por software ou HSM conforme camada. Managed HSM é um serviço dedicado para chaves protegidas por módulos de segurança de hardware e atende cenários de controle criptográfico mais rigoroso. Para o SC-900, o ponto central é que Key Vault gerencia segredos, chaves e certificados; Managed HSM aprofunda proteção e controle de chaves.

10.3 Plano de controle e plano de dados

O plano de controle administra o recurso Azure : criar o cofre, configurar rede, diagnósticos e políticas. O plano de dados acessa os objetos: ler um segredo, assinar com uma chave ou obter um certificado. Uma identidade pode ter permissão para administrar o recurso sem ter permissão para ler os segredos, e o inverso. Essa separação aplica menor privilégio.

Segredo versus chave

Uma senha precisa ser revelada à aplicação para uso e normalmente é armazenada como segredo. Uma chave criptográfica pode permanecer dentro do serviço: a aplicação solicita uma operação de assinatura ou descriptografia sem receber o material privado.

radio_button_uncheckedshort_text 11. Acesso seguro e ciclo de vida no Key Vault

11.1 Autenticação e autorização

O Microsoft Entra autentica usuários, aplicações e identidades gerenciadas. Depois, o Key Vault autoriza a operação por Azure RBAC ou, em ambientes legados, políticas de acesso. RBAC permite atribuir funções em escopos como assinatura, grupo de recursos ou cofre. A recomendação moderna é aplicar papéis mínimos e separar administradores de infraestrutura de consumidores de segredos.

11.2 Identidades gerenciadas

Uma identidade gerenciada elimina a necessidade de uma credencial fixa para a aplicação autenticar-se no Entra. O recurso Azure recebe uma identidade e obtém tokens automaticamente. A aplicação usa o token para solicitar somente o objeto ou a operação autorizada. Assim, não é necessário guardar uma “senha do Key Vault ” no próprio código.

11.3 Proteção de rede

Além de autorização, o cofre pode restringir caminhos de rede. Firewall do Key Vault , redes selecionadas e Private Endpoint permitem acesso privado a partir de uma VNet. Essa combinação reduz exposição pública, mas não substitui RBAC : estar na rede correta não concede direito de ler um segredo.

11.4 Versionamento, rotação e recuperação

• Objetos possuem versões, permitindo atualização sem reutilizar o mesmo valor indefinidamente.
• Rotação reduz o período em que uma credencial comprometida permanece válida.
• Expiração e alertas ajudam a evitar certificados vencidos e segredos esquecidos.
• Soft delete mantém objetos excluídos por um período de retenção.
• Purge protection impede exclusão definitiva durante o período configurado, protegendo contra destruição maliciosa ou acidental.
• Logs e diagnósticos registram solicitações para auditoria e investigação.

Boa prática

Use cofres separados por aplicação, ambiente e região quando isso reduzir impacto e simplificar

radio_button_uncheckedshort_text 12. Arquitetura integrada: como os serviços trabalham juntos

Considere uma aplicação de comércio eletrônico. Usuários chegam pela internet. A camada de borda absorve e distribui tráfego; DDoS Protection ajuda contra ataques de rede volumétricos; o WAF bloqueia requisições HTTP maliciosas. O front-end está em uma subnet própria, a API em outra e o banco em uma terceira. NSGs permitem somente os fluxos necessários entre essas camadas.

O Azure Firewall no hub controla saídas para a internet, acesso a destinos aprovados e comunicação entre redes. Administradores alcançam máquinas virtuais por Bastion, sem IP público nas VMs. A aplicação usa uma identidade gerenciada para recuperar no Key Vault a connection string ou para executar uma operação com chave. Logs de WAF , NSG , Firewall, Bastion e Key Vault são encaminhados para monitoramento e investigação.

12.1 Fluxo normal de uma requisição

5. O usuário envia HTTPS para o ponto de entrada público. 6. A proteção DDoS monitora o volume e mitiga padrões de ataque L3/L4. 7. O WAF inspeciona a requisição HTTP /S e aplica regras gerenciadas e personalizadas. 8. O front-end chama a API somente pela porta autorizada no NSG . 9. A API autentica-se com identidade gerenciada e obtém o segredo necessário no Key Vault . 10. A API acessa o banco apenas pelo fluxo permitido entre subnets.

12.2 Fluxo durante um incidente

Se uma origem tenta explorar SQL injection, o WAF pode detectar e bloquear. Se o volume cresce de forma anormal, DDoS Protection atua na disponibilidade. Se um servidor comprometido tenta acessar um destino malicioso, Azure Firewall pode alertar ou negar com inteligência de ameaças. Se alguém tenta ler um segredo sem função adequada, o Key Vault nega e registra a solicitação. A arquitetura converte um incidente amplo em eventos observáveis e limites de contenção.

radio_button_uncheckedshort_text 13. Decisões de projeto, monitoramento e erros comuns

13.1 Começar por requisitos, não por produtos

A seleção de controles deve partir de ativos, ameaças, caminhos de dados e requisitos regulatórios. Uma aplicação interna sem IP público pode não precisar do mesmo desenho de borda que um portal global. Um ambiente com poucas redes pode começar com NSGs; uma organização com dezenas de assinaturas pode precisar de hub-and-spoke, Azure Firewall e políticas centralizadas. Key Vault é útil sempre que há segredos, mas a forma de isolamento e HSM depende do risco.

13.2 Observabilidade

Controles sem logs limitam detecção e investigação. Diagnósticos podem ser enviados para Log Analytics, Storage, Event Hubs e soluções como Microsoft Sentinel , conforme o serviço. Métricas DDoS mostram mitigação; logs do WAF registram regras acionadas; NSG flow logs ou recursos equivalentes ajudam a entender fluxos; Firewall registra decisões; Key Vault registra operações; Bastion pode oferecer auditoria de sessão em ofertas compatíveis.

13.3 Princípio do menor privilégio em todas as camadas

Menor privilégio não se limita a funções de identidade. Em rede, significa permitir somente origens, destinos, portas e protocolos necessários. Em WAF , significa publicar apenas caminhos e métodos esperados. Em administração, significa reduzir pessoas e máquinas que podem iniciar sessões. Em Key Vault , significa conceder apenas ações específicas sobre objetos necessários.

Estratégia de implantação

Planeje, implemente em modo de observação quando aplicável, valide logs , ajuste falsos positivos, automatize por infraestrutura como código e revise periodicamente regras e permissões.

radio_button_uncheckedshort_text 14. Cenário prático integrado

Uma empresa migra seu portal de atendimento para o Azure . O portal é público, possui APIs internas, banco de dados e duas máquinas virtuais de suporte. A organização quer reduzir indisponibilidade, impedir exposição administrativa, limitar comunicação entre camadas e remover senhas do código.

14.1 Solução proposta

14.2 Sequência de implantação

11. Planejar blocos CIDR sem sobreposição e criar subnets por função. 12. Aplicar NSGs com regras explícitas para web, aplicação, dados e administração. 13. Criar o ponto de entrada com WAF e validar regras em modo de detecção antes de bloquear. 14. Habilitar proteção DDoS adequada aos IPs públicos críticos. 15. Implantar Azure Firewall e rotas quando houver requisito de inspeção central e egress controlado. 16. Implantar Bastion e remover IPs públicos desnecessários das VMs. 17. Criar Key Vault , habilitar recuperação, configurar rede, atribuir RBAC mínimo e usar identidade gerenciada. 18. Enviar logs para uma plataforma de monitoramento e testar cenários de falha e resposta.

14.3 Resultado

O ambiente não se torna invulnerável, mas ganha limites claros. Ataques volumétricos encontram mitigação; ataques web encontram inspeção; comprometimentos internos encontram segmentação; administração não depende de portas públicas; credenciais deixam de circular em código. Cada evento gera evidências para operação e auditoria. Essa é a essência da defesa em profundidade aplicada à infraestrutura Azure .

Ponto de prova

A melhor resposta costuma ser o serviço mais específico para o requisito apresentado, não o produto “mais avançado”. Leia o verbo: mitigar DDoS, filtrar fluxo, inspecionar HTTP , administrar VM ou armazenar segredo.

radio_button_uncheckedshort_text 15. Revisão rápida para o exame SC-900

• VNet é a rede privada lógica no Azure ; subnets dividem seu espaço de endereçamento e organizam workloads.
• NSG é stateful e filtra entrada/saída por prioridade, direção, protocolo, origem, destino e porta.
• Azure Firewall é um firewall como serviço central, stateful , com regras de rede, aplicação, NAT e recursos de ameaça.
• WAF protege aplicações web contra ataques e anomalias HTTP / HTTPS na camada 7.
• Azure DDoS Protection mitiga ataques distribuídos de negação de serviço, principalmente nas camadas 3 e 4.
• Bastion permite RDP / SSH a VMs por IP privado sem exposição direta de IP público na máquina.
• Key Vault armazena segredos, chaves e certificados e integra-se ao Entra, RBAC e identidades gerenciadas.
• Private Endpoint restringe o caminho de rede, mas não substitui autorização.
• Os serviços são complementares e implementam defesa em profundidade.

radio_button_uncheckedshort_text 16. Conclusão

Proteger infraestrutura em nuvem exige compreender fluxos, camadas e responsabilidades. Redes virtuais e sub-redes criam isolamento; NSGs restringem comunicação local; Azure Firewall centraliza políticas de rede; WAF interpreta tráfego web; DDoS Protection preserva disponibilidade; Bastion reduz exposição administrativa; Key Vault protege segredos e material criptográfico. A segurança emerge da combinação coerente desses serviços com identidades, monitoramento e processos humanos.

Na minha avaliação, o conceito mais valioso deste capítulo é a especialização de controles. Projetos inseguros frequentemente tentam fazer um produto resolver todos os riscos. Projetos maduros perguntam qual ativo está exposto, qual camada está sendo atacada, qual fluxo precisa existir e qual evidência será gerada. Essa forma de pensar prepara o aluno não apenas para o SC-900, mas para decisões reais de arquitetura.

radio_button_uncheckedshort_text 17. Questões de revisão

1. Uma empresa precisa bloquear tentativas de SQL injection em um portal HTTPS . Qual serviço é o mais diretamente indicado?

A) NSG B) Azure Web Application Firewall C) Azure Bastion D) Azure Key Vault

Resposta comentada

Resposta correta: B. O WAF interpreta HTTP / HTTPS em camada 7 e possui regras para ataques web, incluindo SQL injection.

2. Qual serviço permite conectar-se por RDP ou SSH a uma VM usando IP privado, sem expor diretamente um IP público na VM?

A) Azure Bastion B) Azure DDoS Protection C) WAF D) Network Security Group

Resposta comentada

Resposta correta: A. Azure Bastion fornece um caminho gerenciado para RDP / SSH sobre TLS até VMs privadas.

3. Qual afirmação descreve melhor a diferença entre NSG e Azure Firewall?

A) NSG protege somente HTTP e Firewall somente bancos. B) NSG armazena segredos e Firewall emite certificados. C) NSG é filtro distribuído em subnets/interfaces; Azure Firewall é controle central stateful para tráfego entre redes e internet. D) Não existe diferença funcional.

Resposta comentada

Resposta correta: C. Eles podem ser usados juntos: NSG para segmentação local e Azure Firewall para políticas e inspeção centralizadas.

4. Uma aplicação precisa acessar uma senha de banco sem manter credenciais fixas no código. Qual combinação é mais adequada?

A) WAF e DDoS Protection B) Azure Key Vault e identidade gerenciada C) Bastion e NSG D) Azure Firewall e IP público

Resposta comentada

Resposta correta: B. A identidade gerenciada autentica a aplicação, e o Key Vault entrega somente o segredo autorizado.

radio_button_uncheckedshort_text 18. Glossário essencial

radio_button_uncheckedshort_text 19. Referências oficiais para aprofundamento

• Microsoft Learn - Study guide for Exam SC-900: Microsoft Security, Compliance, and Identity Fundamentals. Atualizado em 26 de junho de 2026.
• Microsoft Learn - Azure DDoS Protection overview.
• Microsoft Learn - What is Azure Firewall?
• Microsoft Learn - Introduction to Azure Web Application Firewall.
• Microsoft Learn - Azure network security groups overview.
• Microsoft Learn - Azure virtual networks and subnets.
• Microsoft Learn - What is Azure Bastion?
• Microsoft Learn - Azure Key Vault basic concepts.
• Microsoft Learn - Azure Key Vault keys, secrets, and certificates overview.
• Microsoft Learn - Secure your Azure Key Vault .

Observação sobre atualização

Serviços de nuvem evoluem continuamente. Para preços, SKUs, regiões, limites e recursos em disponibilidade, consulte sempre a documentação oficial mais recente. O foco deste capítulo é a finalidade e a diferenciação conceitual exigidas no SC-900.