Origens: segmentação nunca foi sobre segurança

A primeira segmentação era física e não tinha nada a ver com atacantes. A inicial era um meio compartilhado: toda estação ouvia todo quadro, e as colisões cresciam com a população. Pontes, e depois switches, cortaram o domínio de colisão para que o tráfego entre duas portas não perturbasse o resto.

O tráfego de broadcast continuou sendo o custo compartilhado, e foi isso que produziu a - um jeito de recortar um switch físico em vários domínios de broadcast. O padrão relevante, o 802.1Q, define uma etiqueta de quatro bytes inserida no cabeçalho Ethernet, carregando um identificador de VLAN de doze bits, que é de onde vem o limite conhecido de 4.094 VLANs utilizáveis.

Note o que motivou aquilo: contenção de broadcast e arrumação administrativa. Segurança foi efeito colateral - se dois grupos não conseguem trocar quadros sem passar por um roteador, você construiu sem querer um ponto de aplicação de política. A indústria então passou trinta anos formalizando esse acidente, e o fato de a fundação ter sido uma otimização de desempenho explica vários problemas que vêm a seguir.

Evolução, geração a geração

ACLs de roteador e a (anos 1990). Uma vez que VLANs precisavam de um roteador entre si, o roteador virou o lugar de escrever política. A zona desmilitarizada formalizou a primeira arquitetura de segurança de verdade: fora não confiável, dentro confiável, e uma terceira zona para o que precisa ser alcançável dos dois lados. Ela mapeia bem num prédio com portaria, e falha pela mesma razão que uma portaria - passou dali, está tudo dentro.

Firewalls com estado e zonas (anos 2000). A política saiu das listas de acesso por interface para zonas nomeadas com estado de conexão, o que tornou as regras expressáveis em termos humanos. É o modelo que a maioria das empresas ainda roda, e sua propriedade definidora é ser forte no norte-sul (entrada e saída do parque) e quase ausente no leste-oeste (servidor a servidor lá dentro).

VRFs e sobreposições. Uma (instância virtual de roteamento e encaminhamento) dá a um roteador várias tabelas de roteamento independentes, então dois segmentos podem ser genuinamente separados na camada três, até reusando espaço de endereços. Depois a virtualização quebrou o teto de doze bits da VLAN e a premissa de que um segmento mora num lugar físico: a , especificada na RFC 7348, encapsula quadros Ethernet em UDP com um identificador de rede de 24 bits - cerca de dezesseis milhões de segmentos -, deixando um segmento atravessar datacenters sobre um tecido IP.

Baseada em host e em identidade (dos anos 2010 em diante). A percepção que produziu a microssegmentação é que o ponto de aplicação não precisa ser a rede. Se um agente de política roda em cada carga de trabalho, a fronteira acompanha a carga, sobrevive à migração, e deixa de depender de onde um cabo termina. Em paralelo, abordagens por etiqueta ou identidade - tags de grupo de segurança, grupos de segurança de nuvem, rótulos - permitem escrever política sobre o que uma coisa é, e não sobre onde ela está.

Cada geração resolveu o teto anterior. Cada uma também herdou o mesmo problema não resolvido, que é o ponto deste artigo.

As arquiteturas que você vai encontrar de fato

Perímetro por zonas. Um punhado de zonas, política num par de firewalls. Barato, compreensível, fraco internamente. Ainda correto para parques pequenos, e desonesto quando descrito como segmentação do datacenter.

Em camadas. Web, aplicação e banco, cada uma no próprio segmento, com regras só entre camadas adjacentes. É a arquitetura clássica de conformidade - é como se costuma argumentar o escopo de dados de cartão - e funciona exatamente até onde as camadas forem reais.

Baseada em sobreposição (). Um controlador programa uma sobreposição, então os segmentos são lógicos e a política mora no controlador, e não na configuração dos equipamentos. Flexibilidade enorme, uma dependência nova: o controlador virou um ponto de estrangulamento, e os modos de falha dele são os seus.

Microssegmentação em host. Agentes aplicam regras por carga de trabalho a partir de uma política central. A fronteira é por processo, e não por sub-rede, que é a granularidade mais fina disponível e o maior número de regras a manter.

Nativa de nuvem. Grupos de segurança e políticas de rede são microssegmentação com outro nome, aplicadas pela plataforma em vez de por um agente. A armadilha é que são por provedor, expressas de forma diferente em cada um, e raramente portáveis - o que vira custo real num parque multinuvem.

Interoperabilidade e dependências, ditas sem rodeio

A segmentação é incomumente dependente de coisas fora do controle da equipe de redes, e é aí que os projetos empacam:

  • Um inventário. Não se escreve política sobre sistemas que não se consegue enumerar. A maioria das organizações descobre no meio do projeto que não existe inventário exato.
  • Identidade. Política por identidade exige uma fonte autoritativa do que uma carga ou usuário é, e herda a exatidão dessa fonte.
  • Telemetria. Escrever regras sem dados de fluxo é adivinhação; é aqui que a segmentação encontra a engenharia de detecção, porque as duas precisam saber o que de fato fala com o quê.
  • Resolução de nomes e certificados. Segmentos que quebram DNS ou caminhos de validação de certificado produzem falhas que não se parecem nada com problema de firewall.
  • Legado e tecnologia operacional. Protocolos industriais, appliances antigos e tudo com pilha não atualizável acabam em exceções, e as exceções são onde o risco se concentra.

Sobre interoperabilidade: etiquetas não atravessam fabricantes, sobreposições não federam com elegância, e os modelos de política de nuvem diferem o bastante para que uma mesma intenção precise ser reescrita por plataforma. Quem promete uma linguagem única de política para tudo isso está descrevendo uma ambição.

O cenário de fabricantes, com honestidade

As categorias importam mais que os nomes, e cada uma carrega um viés estrutural:

  • Fabricantes de rede - Cisco (ACI, TrustSec/SGT), Arista, Juniper, Extreme, Nokia - aplicam no tecido. Fortes onde a rede é uniforme, mais fracos em nuvens que não são suas.
  • Fabricantes de firewall - Palo Alto, Fortinet, Check Point - aplicam em zonas e, cada vez mais, junto à carga. Boa expressão de política e inspeção; você está comprando um ponto de inspeção em cada caminho que lhe interessa.
  • Hipervisor e sobreposição - o VMware NSX sendo o arquétipo - aplicam no switch virtual, perto da carga e sem agente dentro do sistema convidado.
  • Especialistas em agente de host - Illumio, Akamai Guardicore e outros - são independentes de plataforma e dão a melhor visibilidade do fluxo leste-oeste, ao custo de um agente em tudo.
  • Provedores de nuvem - grupos de segurança, ACLs de rede, políticas de rede do - já estão lá e já estão pagos, e são os que mais ficam no padrão.

A pergunta de compra não é qual é o melhor. É onde você consegue aplicar de forma consistente em tudo o que possui, porque um programa de segmentação com uma lacuna grande de aplicação é um jeito caro de mudar o risco de lugar.

O que isso habilita

  • Raio de explosão. O benefício mensurável: uma invasão alcança o que o host comprometido tinha permissão de alcançar, que é o mesmo argumento do ZTNA (acesso à rede zero trust) noutra camada.
  • Contenção de . A maioria das campanhas de cifragem depende de alcance leste-oeste amplo, sobretudo compartilhamentos de arquivo e protocolos de gerência.
  • Escopo de conformidade. Reduzir os sistemas no escopo de uma auditoria é, com frequência, o que de fato financia o projeto.
  • Detecção com significado. Um fluxo negado entre segmentos é sinal de alta qualidade, enquanto o mesmo pacote numa rede plana é invisível.

Por que ela falha sempre no mesmo lugar

Toda geração desta tecnologia falhou por uma razão, e ela não é técnica: ninguém sabe o que fala com o quê.

A política é escrita a partir de um diagrama de arquitetura que descreve intenção, e não realidade. A primeira tentativa de aplicação quebra uma dependência que ninguém documentou - um agente de backup, um coletor de monitoração, uma verificação de licença, uma tarefa agendada num servidor que todos esqueceram. Algo importante para, a mudança é revertida, e o projeto ganha fama.

O padrão que funciona é sem glamour e é o mesmo em qualquer produto:

  1. Observe primeiro. Colete dados de fluxo por semanas num modo que registra sem bloquear.
  2. Comece grosso. Separe ambientes - produção de corporativo, dados de cartão de todo o resto - antes de tentar regras por carga de trabalho.
  3. Aplique um segmento por vez, com uma reversão que já foi testada.
  4. Trate exceções como um registro, com donos e datas de revisão, porque a lista de exceções é o verdadeiro registro de risco.
  5. Alerte nas negativas, porque uma negativa é uma detecção, e porque uma regra que ninguém monitora é uma regra cuja quebra ninguém percebe.

A contralição também merece ser dita: granularidade tem curva de custo. Política por carga de trabalho num parque que não consegue manter regras por carga de trabalho produz permissões velhas que silenciosamente viram permanentes - e uma implantação de microssegmentação cheia de exceções permite-tudo é menos honesta que um desenho em camadas bem operado, porque reporta uma cobertura que não tem.