Toda plataforma de segurança acaba enfrentando a mesma questão fundamental:
Como as regras de segurança devem ser organizadas?
À primeira vista, isso parece uma simples escolha de modelagem de dados. Na prática, ela define a realidade diária das operações de segurança: a rapidez com que os incidentes podem ser depurados, a segurança com que as políticas podem evoluir, a facilidade com que novos escritórios ou comunidades de usuários podem ser integrados e se o crescimento leva à clareza ou ao caos.
Na última década, as plataformas SASE e SSE convergiram para um pequeno conjunto de padrões arquitetônicos. Esses padrões são frequentemente combinados em produtos do mundo real, mas cada um representa uma filosofia de projeto distinta com seus próprios pontos fortes e modos de falha.
A compreensão desses modelos – e das dimensões em que eles diferem – explica por que as plataformas modernas estão se afastando do pensamento centrado no mecanismo e se aproximando de abordagens mais estruturadas e dimensionáveis.
Dimensão 1: Como as regras são agrupadas
(O eixo primário da concepção de políticas)
1. Base de regras por mecanismo de segurança
(O Modelo Fragmentado)
Essa é a abordagem mais antiga e ainda amplamente implementada.
Cada recurso de segurança possui sua própria base de regras independente :
- Firewall
- IDS / IPS
- DLP
- Varredura de malware
- Filtragem de URLs e categorias
- Controles de SaaS
- Múltiplas proteções GenAI / LLM
Em ambientes modernos, isso não é mais apenas um punhado de mecanismos. A “segurança GenAI” por si só se expande em vários sub-motores especializados, como:
- detecção imediata de injeção,
- validação de entrada/saída da ferramenta
- detecção de código
- Segurança de conteúdo
- Categorização e filtragem de conteúdo
- segurança do URL incorporado
- DLP semântico
Cada mecanismo tem sua própria lógica de correspondência, ações, ciclo de vida e proprietário operacional.
Pontos fortes
- Controle profundo e especializado
- Propriedade clara dos especialistas no domínio
- Evolução independente dos mecanismos de segurança
Limites estruturais
- Visibilidade fragmentada dos fluxos de tráfego
- Decisões conflitantes entre motores
- Alta sobrecarga operacional
- Baixa escalabilidade à medida que os motores se multiplicam
Esse modelo reflete equipes de segurança em silos e herda os mesmos desafios de coordenação e operacionalidade.
2. Base de regras única e unificada
(O modelo consolidado)
Com a unificação das plataformas, muitas passaram para o extremo oposto: colocar todas as decisões em uma tabela de regras globais.
Cada regra define:
- Condições de correspondência (usuário, aplicativo, destino, contexto)
- Referências a perfis de inspeção para DLP, malware, GenAI e outros mecanismos
Pontos fortes
- Uma regra explica uma decisão
- Auditoria e solução de problemas mais fáceis
- Alinha-se bem com o pensamento Zero Trust (“uma intenção = uma regra”)
Limites estruturais
- As tabelas de regras ficam muito grandes em ambientes complexos
- As alterações de perfil podem ter um amplo raio de alcance
- Os especialistas perdem autonomia
- A governança se torna um gargalo
Esse modelo otimiza a visibilidade e a simplicidade, mas muitas vezes tem dificuldades para ser dimensionado com segurança em organizações grandes ou que mudam rapidamente.
3. Base de regras por tipo de destino
(O modelo Destination-First)
Uma evolução mais recente organiza as regras de acordo com o destino do tráfego, e não com o mecanismo que o inspeciona.
As categorias de destino típicas incluem:
- Internet
- Aplicativos SaaS
- Aplicativos privados
Cada tipo de destino tem sua própria base de regras de controle de acesso, refletindo diferentes modelos de confiança, riscos e semântica. As regras ainda avaliam as condições de correspondência e produzem uma decisão de permissão ou negação no nível da sessão, mas o agrupamento se alinha naturalmente à intenção do tráfego.
Pontos fortes
- Separação clara da intenção de acesso
- Modelo mental mais intuitivo para os administradores
- Características de desempenho previsíveis
- Redução da mistura de lógicas de políticas não relacionadas
Limites estruturais
- Não resolve, por si só, a expansão da política
- Requer estrutura adicional para ser dimensionado de forma limpa em grandes organizações
A organização baseada em destino melhora a clareza, mas é necessária outra dimensão para gerenciar o escopo e a reutilização.
Dimensão 2: como as políticas são delimitadas e reutilizadas
(Ortogonal ao agrupamento de regras)
Os modelos a seguir respondem a uma pergunta diferente:
Como a política é empacotada, reutilizada e aplicada em locais, usuários ou ambientes?
Eles podem ser combinados com qualquer uma das abordagens de agrupamento de regras acima.
4. Perfis de configuração
(Política como um objeto de primeira classe)
Os perfis de configuração introduzem uma abstração de nível superior que contém a política, em vez de ser a própria política.
Normalmente, um perfil de configuração agrupa:
-
- Uma ou mais bases de regras de controle de acesso
- Perfis de inspeção (lógica “allow but scan”)
Objetos de segurança específicos do mecanismo (objetos DLP, controles GenAI, assinaturas IDS, etc.)
O perfil se torna uma postura de segurança portátil que pode ser aplicada:
- Escritórios físicos
- Regiões
- Sites lógicos
- Comunidades de usuários
Em vez de incorporar a lógica de escopo (como site ou região) em cada regra, o escopo da política é aplicado ao perfil de configuração apropriado.
Por que isso é importante
- Reduz a explosão de regras
- Melhora a legibilidade e a capacidade de manutenção
- Permite limites RBAC mais claros
- Torna as mudanças de política mais seguras e previsíveis
Essa abordagem é cada vez mais comum nas plataformas SASE e SSE modernas, mesmo quando não é explicitamente rotulada como tal.
5. Herança de políticas
(Modelos de controle em camadas)
Outro padrão muito difundido, mas muitas vezes implícito, é a herança.
As políticas são estruturadas hierarquicamente:
- Uma linha de base global
- Sobreposições regionais ou funcionais
- Substituições específicas do site ou do grupo
A herança permite que as organizações compartilhem padrões e, ao mesmo tempo, permite a especialização controlada.
Compensações
- Potente, mas complexo
- A depuração requer a compreensão da ordem de resolução
- Uma herança mal concebida pode obscurecer uma política eficaz
A herança é frequentemente combinada com perfis de configuração para equilibrar a reutilização com a clareza.
Reunindo as dimensões
As plataformas de segurança modernas raramente dependem de um único modelo.
Em vez disso, eles se combinam:
- Organização de regras com base no destino (clareza de intenção)
- Perfis de configuração (escopo e reutilização de políticas)
- Herança (especialização controlada)
- Inspeção baseada em perfil (modularidade do motor)
Essa abordagem em camadas reflete uma percepção central:
A complexidade da segurança não pode ser eliminada, apenas estruturada.
Onde a IA>se encaixa com segurança
IA>O Secure from Aryaka explicita suas escolhas arquitetônicas nessas duas dimensões:
- Dimensão 1 – Organização de regras: modelo de regras baseado em destino, organizando o controle de acesso em torno da Internet, SaaS e aplicativos privados.
- Dimensão 2 – Escopo e reutilização de políticas: Abordagem baseada em perfil de configuração, em que bases de regras de acesso, perfis de inspeção e objetos de segurança específicos do mecanismo são agrupados em unidades de política reutilizáveis e aplicados a sites lógicos.
Dentro dessa estrutura:
- Cada regra avalia as condições de correspondência (atributos de rede, URL e contexto do aplicativo, identidade do usuário, sinais de reputação).
- Primeiro, é tomada uma decisão de permissão ou negação no nível da sessão.
- A inspeção no nível de dados é realizada somente se a sessão for permitida, garantindo a aplicação previsível e o uso eficiente de mecanismos de inspeção profunda.
- A intenção de inspeção é explícita, por meio de perfis de inspeção anexados às regras, e não implícita em cadeias de regras ocultas.
Ao combinar a organização de regras de destino primeiro com o escopo baseado em perfil de configuração, o AI>Secure evita os dois extremos:
Fragmentação em bases de regras específicas do mecanismo
Expansão e raio de explosão de uma única tabela de regras globais
Por que essa arquitetura é importante agora
O aumento do SaaS, dos aplicativos privados e dos fluxos de trabalho orientados pela GenAI alterou fundamentalmente os requisitos de segurança:
- As decisões dependem de um contexto mais rico
- A inspeção é cara e deve ser intencional
- Muitos mecanismos de segurança
- A política deve ser dimensionada entre locais, usuários e cargas de trabalho
A arquitetura de regras teve que evoluir de acordo.
O futuro do design de políticas de segurança não está relacionado a mais regras ou mecanismos mais inteligentes. Trata-se de uma separação clara de preocupações, intenção explícita e arquiteturas que são dimensionadas sem entrar em colapso sob sua própria complexidade.
Essa é a direção que o setor está tomando e a base arquitetônica sobre a qual a AI>Secure foi construída.