NSP governa o endpoint público em PaaS: default deny, exceções explícitas (in/out) e logs. Quando usar, quando evitar e como combinar com Private Endpoint.
Legenda (FIG 0): NSP: boundary lógico para governança do tráfego público em PaaS.
A maioria dos incidentes e fragilidades “de rede” em Azure não nasce dentro da VNet. Ela nasce na borda do PaaS: Storage, Key Vault, SQL, Search, Monitor, Event Hubs, e outros serviços que não “vivem” em subnets/NSGs e que, por necessidades reais (SaaS, parceiros, CI/CD, integrações), acabam exigindo algum nível de acesso via endpoint público.
O Azure Network Security Perimeter (NSP) existe para resolver um problema específico — e ele fica mais claro quando você descreve em uma frase:
NSP é o gatekeeper central do tráfego público para recursos PaaS, com default deny (Enforced), exceções explícitas (inbound/outbound) e logs padronizados.
O problema real: “NSG para PaaS” nunca escalou
Antes do NSP, o “padrão” para proteger PaaS costumava ser uma colcha de retalhos:
- firewall do próprio serviço (cada produto com sua semântica),
- allowlists de IP por recurso,
- exceções (“trusted services”) e bypasses,
- Private Endpoint/Private Link (quando dava),
- Service Endpoints (quando fazia sentido).
Isso funciona, mas em ambientes grandes gera três dores recorrentes:
- inconsistência (cada time configura de um jeito),
2. drift (ninguém sabe o “estado real” ao longo do tempo),
3. auditoria difícil (logs e controles espalhados).
O que é NSP (sem marketing)
NSP cria um limite lógico (logical boundary) ao redor de recursos PaaS e oferece uma experiência unificada de governança:
- Network Security Perimeter: boundary “top-level”
- Profiles: agrupamento lógico
- Access rules: regras de inbound e outbound
- Resource associations: associa recursos ao perímetro + define modo
- Diagnostic logs: visibilidade padronizada
“NSP é GA?” Sim — mas atenção ao suporte por serviço
A documentação indica que o NSP está GA em todas as regiões públicas do Azure, porém o suporte varia por serviço e alguns serviços onboarded podem estar em preview (ex.: Cosmos DB, SQL DB, Azure OpenAI no contexto de NSP).
Transition vs Enforced: o pulo do gato para não causar apagão
Os recursos entram no perímetro via resource association em dois modos:
- Transition (padrão): usado para entender padrões e preparar o rollout
- Enforced: default deny para tráfego público; só passa o que você permitir via regras
Princípio operacional: Transition não é “estado final”. Ele é a fase de descoberta e ajustes antes do bloqueio.
Legenda (FIG 2): Rollout seguro: observe (Transition + logs), ajuste regras, valide em canary, então Enforced em ondas.
O que o NSP NÃO é (para evitar decisões erradas)
NSP não substitui Private Link / Private Endpoint
Private Endpoint entrega conectividade privada com IP privado na VNet.
NSP governa o tráfego público (o endpoint público do PaaS).
Em serviços como Storage/Azure Files, a documentação é explícita: NSP não afeta tráfego via Private Endpoint.
NSP não substitui NSG/UDR/Azure Firewall dentro da VNet
Se o seu problema é east-west ou egress de workloads, seu toolkit continua sendo NSG/UDR/Firewall/NVA. NSP não foi criado para isso.
Quando o NSP é um ótimo caso de uso
1) Você precisa manter endpoint público — mas quer governança de plataforma
Quando existe consumo por SaaS/parceiros/integrações externas, o endpoint público tende a ficar “ligado por exceção”. O NSP ajuda a transformar essas exceções em um modelo mais controlado: regras centralizadas (in/out) + logs.
2) Você quer reduzir exfiltração “PaaS → Internet” com outbound control
O NSP foi desenhado para permitir regras de outbound (ex.: por FQDN) e reduzir “saída não autorizada” via tráfego público.
3) Você quer rollout controlado (Transition → Enforced) com evidência
O modo Transition + logs oferece um caminho mais seguro para “travar” sem quebrar produção.
Quando você NÃO deve usar NSP (ou ele agrega pouco)
Caso enterprise: 100% Private Endpoints + on-prem forte + multicloud (AWS/GCP)
Esse cenário é comum em organizações maduras:
- Todos os PaaS críticos em Azure usam Private Endpoint (Private Link).
- On-prem acessa Azure via ExpressRoute/VPN, com DNS privado e rotas controladas.
- Em AWS e GCP, o padrão equivalente é conectividade privada (ex.: AWS PrivateLink / GCP Private Service Connect).
Por que NSP tende a agregar pouco aqui?
Porque o problema que ele resolve é governança do endpoint público. Se você já eliminou public access como padrão, o valor marginal do NSP cai: você já está aplicando isolamento no caminho privado.
Quando ainda faz sentido considerar NSP nesse cenário?
Quando houver tráfego público residual inevitável (terceiros/SaaS) e você quiser padronizar exceções e auditoria dentro do Azure — como controle complementar.
Legenda (FIG 3): Em arquitetura 100% privada e multicloud, NSP tende a ser complementar (apenas para público residual em Azure).
Outros sinais de “não use / agrega pouco”
- Seu problema é segurança dentro da VNet (east-west/egress).
- O serviço que você quer proteger está em preview com limitações (ex.: Cosmos DB, SQL DB, Azure OpenAI no contexto do NSP).
NSP sozinho é suficiente? Preciso combinar com Private Endpoint / Service Endpoint?
A forma mais prática de pensar é:
Private Endpoint governa o caminho privado. NSP governa o caminho público.
- Se você consegue operar sem endpoint público, Private Endpoint tende a ser baseline.
- Se você precisa de endpoint público, NSP vira o mecanismo de governança e auditoria.
- Na prática, é comum usar os dois: Private Endpoint para interno/on-prem e NSP para público residual.
Legenda (FIG 4): Private Endpoint = conectividade privada; NSP = governança do público; Service Endpoint = restrição do público via subnet (Azure-only).
Estratégia recomendada de adoção (sem downtime acidental)
- Defina o boundary por domínio de risco/dados (segredos, dados regulados, observabilidade, etc.).
2. Crie Profiles por padrão de acesso (prod crítico vs shared platform).
3. Associe em Transition + habilite logs para baseline e correções.
4. Converta para Enforced em ondas (canary → lote).
Legenda (FIG 5): Decisão rápida: quando usar Private Link, quando usar NSP, quando combinar.
Conclusão
NSP não é “mais um recurso de rede”. Ele é uma peça de governança escalável para o ponto onde muitas organizações perdem controle: o endpoint público do PaaS.
Se você está em um ambiente maduro de 100% Private Endpoints + híbrido forte + multicloud, o NSP tende a ser secundário (complementar). Mas se o endpoint público precisa existir — nem que seja para poucos casos — o NSP é uma forma pragmática de transformar exceções em política de plataforma, com rollout seguro e visibilidade.
Referências
https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-concepts
https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-transition
https://learn.microsoft.com/en-us/azure/private-link/network-security-perimeter-diagnostic-logs
https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security-perimeter
https://learn.microsoft.com/en-us/azure/storage/files/files-network-security-perimeter
https://learn.microsoft.com/en-us/azure/private-link/private-link-overview