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.
Um motor de fluxo que possui autenticação, MFA, decisões e roteamento em uma única definição baseada em serviço.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
Está em desenvolvimento uma linguagem de expressão nativa que permite que uma única política combine identidade, grupo, tempo, IP de origem, geolocalização e postura de dispositivo em uma única regra legível — por exemplo, uma única expressão que diz 'papel admin E tempo dentro do horário de trabalho E origem geográfica na lista permitida E confiança de dispositivo acima do limite'. A mesma lógica pode ser obtida hoje encadeando ações Switch e DecisionPoint; o DSL compacta cadeias comuns em uma única expressão.
Avaliadores nativos para lookup de IP-para-geo, janela de tempo e score de confiança de dispositivo (via endpoint trust manager) estão no roadmap; assim, os fluxos podem ramificar sobre esses sinais sem que o upstream precise calculá-los primeiro. Para ambientes que já têm uma fonte preferida de geo ou de reputação de IP, o caminho de injeção de header continua suportado.
A mecânica que garante a distribuição segura das alterações de política e a auditoria fácil.
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.
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.
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.
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.
Está em desenvolvimento um editor gráfico para o motor de fluxo; os operadores poderão construir fluxos de acesso visualmente, validar transições e pré-visualizar resultados com usuários sintéticos sem editar o JSON manualmente. Até ser lançado, os fluxos são definidos na configuração versionada e revisados com controle de mudança padrão.
O modo dry-run planejado passa uma sessão sintética por um fluxo sem afetar usuários reais; retorna o rastreamento ação por ação e o resultado final. Combinado com o construtor visual, transforma as alterações de política em artefatos testáveis em vez de implantações cegas em produçã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.
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.
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.
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.
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.