Cisco 300-415: Segurança, Segmentação e Encadeamento de Serviços — Guia de estudos
Faz parte do Cisco SD-WAN 300-415 ENSDWI — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.
Visão Geral
O Cisco SD-WAN fornece uma estrutura abrangente de segurança e segmentação que se alinha aos princípios de Zero Trust, ao mesmo tempo que permite a inserção de serviço escalável e o acesso seguro à internet. As políticas de segurança e a segmentação são expressas centralmente, distribuídas através do plano de controle (OMP) e aplicadas de forma consistente nos roteadores WAN Edge. Esta seção explica como projetar e operar a segmentação baseada em VPN, posicionar e encadear serviços de segurança, proteger o plano de controle e o acesso administrativo, e coletar telemetria de segurança significativa sem degradar o desempenho de aplicações críticas.
Fundamentos de Segmentação e Política
Segmentação baseada em VPN
- Cada tenant ou domínio de segurança é isolado em sua própria VPN SD-WAN (VRF). A alcançabilidade do plano de controle para os controllers usa a VPN 0, enquanto o gerenciamento usa a VPN 512; VPNs do lado do serviço (para usuário, voz, OT, PCI, convidado) transportam o tráfego do plano de dados.
- O espaço de endereço sobreposto é totalmente suportado por tabelas de roteamento por VPN. Filiais ou tenants com 10.0.0.0/8 podem coexistir, pois o OMP transporta rotas com escopo de VPN, TLOCs e rotas de serviço de forma distinta.
- A comunicação entre VPNs ocorre apenas por meio de vazamento de rotas explícito ou política; isso impõe o menor privilégio.
Design de espaço de endereço sobreposto
- Prefira evitar NAT dentro da WAN quando a segmentação for suficiente. Se duas VPNs sobrepostas precisarem interoperar, use:
- Política de controle centralizada para vazar prefixos específicos entre VPNs com prefix-lists e route-maps precisos.
- NAT em um site de rendezvous se a tradução for necessária (por exemplo, migrando um IP legado para um serviço consolidado).
- Modos de falha e trade-offs:
- O vazamento de rotas incorreto ou amplo anula a segmentação e pode criar black holes; sempre teste a política de rotas com a pré-visualização de rotas do OMP (verificação de rotas OMP, TLOC e de serviço).
- O NAT dentro do overlay pode quebrar as expectativas da aplicação e complicar a solução de problemas; use como último recurso.
Hierarquia e aplicação de políticas
- Os controllers vSmart distribuem informações de rota e política usando OMP e também distribuem informações de chaves criptográficas para os WAN Edges para formar túneis IPsec seguros. Políticas centralizadas definem o roteamento ciente de aplicação, a associação a VPNs e a inserção de serviços em toda a malha (fabric).
- Políticas locais (por exemplo, uma ACL por dispositivo para um circuito específico) são aplicadas no WAN Edge. Use uma política de dados local quando for necessária uma classificação específica do dispositivo ou do circuito.
- Políticas de dados são usadas para direcionar, aceitar ou descartar o tráfego de dados entre VPNs e para redirecionar de redes privadas para redes de ISP quando necessário.
- Alinhamento com Zero Trust:
- Negação por padrão (default-deny) entre VPNs; permissão explícita apenas para os fluxos necessários.
- Controles cientes de identidade e aplicação para segmentação leste-oeste usando zonas e políticas discutidas abaixo.
Controles de Segurança e Posicionamento da Inspeção
Firewall Baseado em Zona (ZBFW)
- Construa zonas de segurança por VPN; uma VPN pode pertencer a exatamente uma zona para evitar a aplicação de políticas ambíguas.
- Crie pares de zonas e políticas para permitir, inspecionar ou descartar tráfego. Use correspondência L3/L4/L7 para impor o menor privilégio nos fluxos entre zonas.
- Posicionamento da inspeção:
- Filial (Branch): Aplique segmentação e inspeção stateful perto do usuário; ideal para local breakout e prevenção de movimento lateral contido no site.
- Hub/colocation: Use para tráfego que transita entre domínios ou requer serviços avançados; minimize a latência de hairpin regionalizando os hubs.
- Modos de falha e trade-offs:
- A inspeção stateful requer fluxos simétricos; o roteamento assimétrico ou as diferenças de ECMP entre caminhos podem causar quedas de sessão. Use uma política centralizada para garantir a simetria de caminho para os fluxos inspecionados.
- A vazão e a latência são impactadas pela inspeção profunda; classifique o tráfego de exceção (por exemplo, voz/vídeo) para contornar (bypass) a inspeção profunda, mas ainda aplicando ACLs.
Prevenção de intrusão, filtragem de URL e segurança avançada
- Nos WAN Edges IOS XE SD-WAN, os recursos de Unified Threat Defense fornecem IPS, filtragem de URL e reputação de malware. Mantenha as assinaturas atualizadas e defina o comportamento como fail-open ou fail-closed de acordo com a tolerância a risco do negócio.
- Para tráfego com muito TLS, considere o offload de decriptografia em um hub ou em um gateway web seguro. Se a decriptografia não for possível, confie em SNI, JA3, reputações de IP e análise comportamental.
- Trade-offs:
- A filtragem de IPS/URL introduz latência e consumo de CPU; use uma política ciente de aplicação para inspecionar apenas categorias de alto risco, permitindo que aplicativos de negócios confiáveis sigam por caminhos rápidos.
- Garanta uma política de bypass clara para aplicações críticas caso um mecanismo de IPS fique indisponível para evitar uma interrupção (documente se o fail-open é aceitável).
Orquestração de política de inspeção segura
- O vSmart entrega políticas de segurança centralizadas que redirecionam o tráfego filial-a-filial ou filial-a-DC através de um serviço de rede (firewall, IPS). Isso é a inserção de serviço: corresponda aos fluxos, defina a ação para passar por um serviço nomeado e aplique às VPNs/sites de destino.
- Valide a disponibilidade da rota de serviço por meio das rotas de serviço OMP e monitore a saúde; defina o comportamento de fallback (passar/descartar) em caso de falha do serviço.
Service Chaining, Acesso Direto à Internet e Breakout Avançado
Padrões de encadeamento de serviços (service chaining)
- Firewalls/IDS/IPS físicos ou virtuais em linha podem ser encadeados no hub ou na filial. No hub, configure o endereço do firewall de serviço no vEdge/WAN Edge voltado para o serviço para registrá-lo como um nó de serviço.
- Para obter escala e agilidade, use o Cloud onRamp for Colocation para direcionar o tráfego das filiais para hubs de serviço regionalizados que hospedam funções de rede e segurança encadeadas com acesso de baixa latência. Os roteadores da filial analisam localmente e direcionam o tráfego elegível para essas funções próximas para otimizar o custo e a experiência do usuário.
- Opcionalmente, insira funções adicionais como DLP ou CASB em série. Defina verificações de integridade (health-checks) e SLAs para que o roteamento ciente da aplicação selecione apenas caminhos e encadeamentos que atendam aos requisitos de desempenho.
Considerações de design
- Escolha o encadeamento de serviços central quando uma postura de segurança consistente e a inspeção de conteúdo forem necessárias, mas aceite a latência/hairpin adicionais.
- Escolha o encadeamento de serviços na filial quando for necessária latência ultrabaixa ou para garantir a aplicação de políticas durante brownouts da WAN.
- Planeje a redundância: anuncie vários nós de serviço como rotas de serviço OMP e use políticas para preferir o primário regional com failover para o secundário.
Breakout seguro para a internet e DIA
- O breakout local para a internet reduz o backhaul e melhora o desempenho de SaaS. Use políticas de dados (data policy) para direcionar os fluxos destinados à internet para o caminho DIA.
- O NAT é configurado na interface de saída na VPN 0 para acesso direto à internet; garanta que as ACLs permitam os fluxos de saída e de retorno.
- Combine o DIA com ZBFW, segurança na camada de DNS e filtragem de URL. Considere o Cloud onRamp for SaaS para medir a qualidade do caminho para aplicações SaaS específicas e selecionar um caminho ideal por aplicação.
- Modos de falha e trade-offs:
- NAT mal posicionado ou rotas padrão sobrepostas na VPN 0 podem interromper as conexões de controle (DTLS/TLS) com os controladores; isole as regras de NAT do DIA do tráfego do controlador e valide os requisitos de PnP/ZTP (DHCP, DNS).
- O tunelamento dividido (split tunneling) pode entrar em conflito com exigências de conformidade; aplique o breakout por aplicação com auditoria e DLP quando necessário.
Confiança no Plano de Controle, AAA/RBAC, Proteções de QoS e Telemetria
Proteção do plano de controle e confiança baseada em certificados
- Os WAN Edges estabelecem conexões de controle DTLS/TLS seguras na VPN 0 com o vBond, vSmart e vManage. O controlador vSmart usa o OMP para transportar rotas e políticas do plano de controle; os WAN Edges nunca trocam informações de controle diretamente entre si.
- A autenticação mútua é baseada em certificados. Use a PKI da Cisco ou uma CA corporativa (Enterprise CA); garanta que o NTP esteja correto para evitar falhas na validação de certificados. Rotacione as chaves periodicamente e revogue identidades comprometidas prontamente.
- Faça o hardening dos controladores: restrinja os IPs de gerenciamento, imponha cifras TLS, segmente o gerenciamento na VPN 512 e monitore a contagem e as taxas de sessão do plano de controle. Aplique rate-limit e filtre o gerenciamento de entrada e o tráfego SSH/HTTPS por meio de ACLs.
AAA, RBAC e acesso administrativo
- Imponha AAA centralizado via TACACS+ ou RADIUS com controle de acesso baseado em função (RBAC) para o vManage e as CLIs dos dispositivos. Separe as funções de somente leitura (read-only), operador e arquiteto; aplique MFA sempre que possível.
- Use chaves de API para automação com escopos de privilégio mínimo; audite as chamadas de API.
- Registre todas as alterações administrativas com timestamps; encaminhe para um SIEM.
Implicações de QoS e proteção de fluxos críticos
- Preserve e honre o DSCP através do IPsec com copy-dscp; classifique e marque na entrada (ingress) e, em seguida, mapeie para filas por túnel. Reserve filas de prioridade para fluxos de voz em tempo real ou transacionais (por exemplo, autorização de pagamento).
- Coordene a segurança com o QoS:
- Coloque fluxos de baixa latência e sensíveis a jitter em caminhos rápidos (fast paths) e políticas de inspeção mínimas.
- Aplique “policing” e “rate-limit” ao tráfego desconhecido ou em massa para evitar a privação de recursos (starvation) e reduzir o impacto de DDoS.
- Trade-offs: a inspeção de segurança agressiva pode aumentar a latência e o jitter; quantifique o impacto e crie classes de exceção quando justificado.
Logging, NetFlow, cflowd e telemetria de segurança
- Habilite os logs de ZBFW, IPS e filtragem de URL com limites de severidade; exporte via syslog por canais seguros.
- Use cflowd (telemetria de fluxo da SD-WAN) e/ou exportadores NetFlow/IPFIX para fornecer visibilidade no nível do fluxo por aplicativo, site, VPN e caminho. Alimente o vAnalytics para criar baselines e o SIEM para correlação.
- Colete eventos de alteração de rota OMP e TLOC para detectar possíveis anomalias no plano de controle. Aplique rate-limit ao logging para evitar tempestades de logs (log storms) durante eventos.
- Monitore o desempenho de aplicativos criptografados com sondas de SLA (SLA probes); acione a remediação por meio de política centralizada quando a degradação for detectada.
Aplicação de Zero Trust na WAN
- Trate cada site e caminho como não confiável. Imponha a segmentação por VPN, verifique a identidade por meio de certificados e autorize por classe de tráfego usando ZBFW e política de dados.
- Valide continuamente a postura (posture) do dispositivo e a saúde do caminho; reavalie as políticas dinamicamente com o roteamento com reconhecimento de aplicativo (application-aware routing), configurado como política centralizada.
- Negação por padrão (default-deny) entre zonas e VPNs; vazamento de rotas (route leaking) mínimo necessário e inserção explícita de serviço para inspeção.
Cenário de Problema Prático
O Acme Retail Group precisa segmentar o tráfego PCI, corporativo e de convidados (guest), fornecer breakout local seguro para a internet nas filiais e inserir inspeção avançada de IDS/IPS e DLP em hubs de colocation regionais sem degradar a latência da autorização de pagamentos.
Abordagem
Definir a segmentação baseada em VPN e a linha de base Zero Trust
- Criar a VPN 10 (PCI), VPN 20 (Corporativo) e VPN 30 (Convidados). Não vazar rotas entre as VPNs por padrão.
- Justificativa: As RIBs por VPN suportam sub-redes sobrepostas entre as lojas; a negação por padrão do Zero Trust restringe o movimento lateral.
Construir zonas ZBFW mapeadas para VPNs e políticas entre zonas
- Atribuir cada VPN a uma zona de segurança distinta; criar pares de zonas (zone-pairs) que permitam apenas os fluxos necessários (por exemplo, do POS para gateways de pagamento, do corporativo para servidores de atualização).
- Justificativa: Impõe o privilégio mínimo nas camadas L3 a L7; uma VPN pertence a uma única zona para evitar ambiguidade de política.
Habilitar DIA seguro com breakout com reconhecimento de aplicativo
- Em cada filial, configurar DIA na VPN 0 com NAT na interface voltada para a internet. Usar política de dados centralizada para direcionar o tráfego SaaS e de convidados para o DIA, mantendo o tráfego PCI na WAN privada ou em uma saída inspecionada.
- Justificativa: Melhora o desempenho de SaaS; a política central permite decisões por aplicativo. Deve-se tomar cuidado para isolar as sessões DTLS/TLS do controlador na VPN 0 das regras de NAT do DIA.
Inserir IDS/IPS e DLP regionais via service chaining
- Em cada hub de colocation, registrar o serviço de firewall/IDS no WAN Edge configurando o endereço do firewall de serviço. Construir uma política centralizada no vSmart para redirecionar o tráfego Corporativo e PCI destinado à internet para a cadeia de serviços (service chain); o tráfego de Convidados permanece em DIA com ZBFW local e filtragem de URL.
- Justificativa: O vSmart impõe a inserção de serviço de forma consistente; o OMP anuncia as rotas de serviço para resiliência. A regionalização limita a latência de hairpin e escala a inspeção avançada.
Proteger o plano de controle e fazer o hardening dos controladores
- Garantir que o NTP esteja preciso; usar PKI corporativa para todas as identidades do plano de controle. Restringir o acesso de gerenciamento ao vManage, vSmart e vBond na VPN 512. Monitorar a saúde da sessão OMP e as alterações de TLOC.
- Justificativa: A confiança baseada em certificados impede o onboarding de dispositivos não autorizados (rogue); o gerenciamento com hardening reduz a superfície de ataque e o risco de interrupção do plano de controle.
Aplicar AAA/RBAC e controle de alterações
- Integrar o acesso ao vManage e aos dispositivos com TACACS+; criar funções para NOC (somente leitura), SecOps (edição de políticas) e NetOps (templates de dispositivo). Exigir MFA e registrar todas as alterações no SIEM.
- Justificativa: Limita o raio de impacto (blast radius) de um erro do operador ou comprometimento de credenciais; cria uma trilha auditável.
Alinhar QoS com a segurança para o tráfego de pagamentos
- Marcar o tráfego de POS como EF e fixá-lo em filas de alta prioridade com inspeção mínima; classificar atualizações de software em massa como BE e permitir inspeção profunda. Habilitar copy-dscp sobre IPsec.
- Justificativa: Preserva os SLAs de baixa latência para pagamentos enquanto ainda inspeciona fluxos menos críticos; evita o jitter causado por inspeção pesada.
Habilitar telemetria e verificação contínua
- Exportar eventos de ZBFW/IPS via syslog, habilitar cflowd/IPFIX para um coletor e integrar todos os logs ao SIEM. Usar o vAnalytics para criar um baseline de desempenho por aplicativo e acionar a remediação via política centralizada se o SLA cair.
- Justificativa: Correlaciona detecções de segurança com o contexto do fluxo, suporta a solução proativa de problemas (troubleshooting) e mantém a validação contínua do Zero Trust.
Validar e garantir a tolerância a falhas (fail-safe)
- Testar caminhos simétricos para fluxos inspecionados, verificar as rotas de serviço OMP e simular a falha do nó de serviço para confirmar se o comportamento de bypass/descarte atende à política. Aplicar rate-limit aos logs para evitar tempestades.
- Justificativa: Previne interrupções inesperadas por roteamento assimétrico ou falhas de serviço e mantém a observabilidade durante incidentes.
← Política Centralizada e Engenharia de Tráfego · Todos os domínios · Qualidade de Serviço e Serviços Multicast →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →