O acesso condicional não pode ser gerenciado com uma simples lista de permissões
A decisão de acesso moderna já não consiste apenas na pergunta "o nome de usuário está correto?". A decisão correta deve olhar em conjunto para a identidade do usuário, o estado de confiança do dispositivo, a localização, o tempo, a sensibilidade do serviço acessado, o nível de MFA exigido e as mudanças de risco dentro da sessão.
Regras estáticas e listas de permissão simples não conseguem carregar essa complexidade. Com o tempo, cada exceção torna-se uma nova regra, cada aplicação um novo caso especial, cada sinal de risco um ponto de controle separado. O resultado é uma pilha de políticas que ninguém consegue ler de ponta a ponta e cujo motivo de permissão ou negação não pode ser claramente explicado em uma auditoria.
Algumas soluções transferem essa decisão para uma nuvem de política separada. Isso torna o momento mais crítico da autenticação dependente de uma API externa. Quando identidade, MFA, roteamento de serviço e auditoria se dispersam por sistemas diferentes, o caminho de acesso torna-se invisível; a organização vê apenas o resultado, não como a decisão foi formada.
No entanto, o acesso condicional deve ser um único motor de decisão que roda ao lado das suas identidades e serviços. Cada passo deve ser visível, cada condição explicável, cada decisão auditável.
Porque a segurança de acesso não tem a ver apenas com quem entrou; tem a ver com em qual contexto, com qual força de validação e com qual justificativa o acesso foi concedido.
Nossa abordagem
Um motor de fluxo que possui autenticação, MFA, decisões e roteamento em uma única definição baseada em serviço.
Cada serviço executa seu próprio fluxo de acesso
Um fluxo de acesso encadeia login, MFA, pontos de decisão, switches, gerenciamento de lockout e os terminais de access-granted/denied. Cada serviço declara seu próprio fluxo; uma aplicação de intranet de baixo risco permanece simples, um caminho administrativo privilegiado permanece rígido — sem forçar ambos à mesma forma.
Ramificação baseada em padrões sobre qualquer variável
Os nós switch roteiam sobre qualquer variável que o fluxo possa ver — propriedades de sessão, headers da requisição, templates avaliados, sinais upstream vindos da sua borda — com cinco modos de correspondência (exact, prefix, suffix, contains, regex) e uma opção case-insensitive opcional. As decisões são expressas como correspondência de padrões, não como script.
Sinais vindos da borda entram no fluxo
Geolocalização, reputação de IP, score de risco, zona de rede — tudo o que a sua borda consegue calcular pode ser injetado como header da requisição e lido por um switch ou ponto de decisão. O fluxo permanece como fonte única; os sinais vindos de fora do gateway alimentam o fluxo sem inserir um serviço externo no caminho de autenticação.
Cada transição está no log de auditoria
Cada avaliação de ação — qual passo rodou, qual era a entrada, qual ramo foi escolhido, qual terminal foi alcançado — cai em um fluxo de auditoria estruturado. Os operadores reproduzem as sessões passo a passo; as equipes de segurança correlacionam as decisões de acesso com o restante da telemetria via SIEM streaming.
Capacidades
O motor de fluxo em detalhe, os blocos de construção que compõem as regras de política e as adições planejadas para expandi-los.
Motor de fluxo — uma única cadeia para auth, MFA, decisão e roteamento
Um único motor orquestra login, desafio multifator, gerenciamento de lockout, pontos de decisão, roteamento switch e os terminais access-granted / access-denied. Cada passo é uma ação com transições explícitas; o caminho da requisição anônima à sessão autenticada é um grafo composto em vez de configuração dispersa.
Definição de fluxo baseada em serviço
Cada serviço registra sua própria definição de fluxo. Um proxy SaaS pode exigir apenas SSO; uma aplicação interna pode adicionar TOTP; um sistema de produção pode encadear TOTP mais um OTP novo mais um ponto de decisão explícito. Alterar a política de um serviço não afeta os demais.
Switch — roteamento multivias por correspondência de padrões
A ação switch avalia uma variável configurável (header, propriedade de sessão, template AAM) e roteia o fluxo para uma ação alvo, comparando-a com uma lista ordenada de padrões. Cinco modos de correspondência — exact, prefix, suffix, contains, regex — junto com case-insensitive opcional; abrange tudo, desde verificação de papel até correspondência regex no caminho da requisição.
Pontos de decisão para ramificação sim/não
As ações DecisionPoint dividem o fluxo em dois caminhos com base na presença ou ausência de um sinal configurado. Hoje, o sinal é um header da requisição definido pela sua borda (CDN, módulo de política upstream ou gateway de rede); a superfície da ação mantém a estrutura do fluxo fixa, enquanto a condição subjacente é evoluída para avaliar expressões mais ricas.
Variáveis de template AAM nas condições
As variáveis embutidas na configuração do fluxo — identidade do usuário, pertinência a grupos, id do serviço, ambiente, propriedades de sessão personalizadas — são resolvidas no momento da avaliação pelo motor de template AAM. A mesma sintaxe de template usada em branding, roteamento e mensagens de erro também conduz as decisões de política; os operadores aprendem uma única linguagem de substituição e a usam em todos os lugares.
Step-up e MFA encadeado conduzidos pelo fluxo
Como o MFA é uma ação dentro do mesmo fluxo, o acesso condicional pode solicitar um segundo fator apenas em ramos específicos — por exemplo, solicitar TOTP quando o switch detecta o papel admin, ou encadear TOTP mais um OTP novo quando a rota alcança um terminal de alta sensibilidade. O step-up vive na política, não na percepção do usuário.
Profundidade operacional
A mecânica que garante a distribuição segura das alterações de política e a auditoria fácil.
Auditoria passo a passo com entrada e resultado
Cada avaliação de ação no fluxo escreve uma entrada de auditoria estruturada — id da ação, tipo de ação, variáveis de entrada, ramo escolhido, terminal alcançado, latência. As sessões são reproduzidas passo a passo em uma única visualização de linha do tempo, em vez de reconstruídas a partir de logs dispersos.
Execução de fluxo stateless coordenada via Redis
O estado do fluxo vive no Redis; assim, qualquer instância de gateway pode assumir qualquer sessão em qualquer passo. O escalonamento horizontal e os rolling upgrades sem interrupção não perdem o estado de autenticação em andamento; os operadores podem rodar múltiplos pods de gateway atrás de um balanceador de carga sem sobrecarga de coordenação.
Lockout coordenado ao longo do fluxo
Tentativas de fator falhas, desafios de MFA rejeitados e terminais access-denied alimentam os mesmos contadores de lockout que a camada de login-attack-protection da plataforma usa. Um usuário não pode fazer brute-force de um fator falho enquanto aguarda uma tentativa paralela em um ramo de switch em um passo diferente.
Configuração de fluxo versionada
As definições de fluxo vivem na configuração JSON entregue ao gateway; as alterações de configuração podem ser distribuídas, revisadas e implantadas de forma gradual por ambiente. A combinação de configuração versionada com auditoria passo a passo torna a pergunta 'por que esse usuário entrou ontem?' respondível a partir de uma única fonte.
Em quais cenários é usado
Imposição de MFA baseada em serviço
O mesmo motor de fluxo que autentica o usuário decide se um serviço específico requer MFA, qual fator será aplicado e se o atalho de dispositivo confiável é válido. A política de MFA não é um produto separado — é um nó no fluxo de acesso daquele serviço.
Acesso ciente de geo e reputação de IP
Componentes de borda (CDN, feeds de reputação de IP, gateway de rede) injetam headers de geo e de reputação; os switches e pontos de decisão do fluxo ramificam de acordo com esses sinais — por exemplo, negando logins de redes maliciosas conhecidas ou roteando regiões de alto risco para cadeias de MFA mais rígidas.
Ramificação baseada em papel e grupo
Os nós switch que roteiam por papel do usuário ou pertinência a grupos compõem camadas de acesso em um único fluxo — os administradores passam por um caminho com MFA mais rígido, os usuários comuns por um caminho sem fricção, os contratados por um terceiro caminho vinculado a tempo e a uma lista de recursos. O fluxo permanece auditável como um único artefato.
Caminhos de acesso com escopo de conformidade
Os serviços com escopo de PCI-DSS, HIPAA, GDPR, ISO 27001 executam seus próprios fluxos mais rígidos — MFA obrigatório, registro obrigatório no início da sessão, sem atalho de dispositivo confiável. O auditor examina uma única definição de fluxo e um único fluxo de auditoria, em vez de uma pilha sobreposta de regras.
Perguntas frequentes
Como uma política de acesso condicional é definida hoje?
Como condições como geolocalização, tempo e postura de dispositivo são avaliadas?
O switch (roteamento por correspondência de padrões) suporta regex?
Como cada decisão de acesso é auditada?
Uma alteração de política pode ser testada antes de entrar em produção?
Traga sua política de acesso de volta para um único motor
Um único motor de fluxo, uma única fonte, um único fluxo de auditoria — para cada serviço, cada passo, cada decisão. Vamos guiá-lo por uma instalação ao vivo nas suas próprias aplicações.