Sua verificação de tempo de atividade indica que a aplicação está bem. Enquanto isso, ninguém consegue fazer login, porque o provedor de identidade que fica na frente está com tempo esgotado. Para qualquer aplicação atrás da autenticação de Gerenciamento de Identidade e Acesso (IAM), o login é parte do produto, e um monitor que para na parede de login está monitorando a coisa errada. A regra prática: trate a autenticação como código da aplicação voltado ao usuário, mesmo quando o IdP pertence a um fornecedor, porque os usuários nunca experimentam “app funcionando, login fora” como uma interrupção parcial — para eles, o produto simplesmente desapareceu.
Aplicações autenticadas são o ponto cego clássico do monitoramento sintético. Uma simples verificação HTTP recebe um 200 saudável da página pública de login enquanto a cadeia de redirecionamento SSO, o desafio MFA ou a troca de token por trás dela está quebrada. A única maneira de ver o que um usuário autenticado vê é scriptar todo o fluxo, credenciais, segundo fator e tudo mais, e executá-lo em uma programação.
Isso levanta as perguntas que este guia responde: como scriptar por uma cadeia de redirecionamento SSO, o que fazer com códigos MFA que são projetados para derrotar automação, onde guardar as credenciais para que não vazem, e como saber se um login lento é culpa da sua aplicação ou do seu provedor de identidade?
O que é Gerenciamento de Identidade e Acesso (IAM)?
Gerenciamento de Identidade e Acesso é a estrutura de políticas e serviços que decide quem pode acessar quais recursos, e comprova isso no login. Na prática, significa que um provedor de identidade (IdP) central, como Okta, Microsoft Entra ID, Auth0 ou Ping, gerencia a autenticação para muitas aplicações por meio de single sign-on (SSO), geralmente via SAML ou OpenID Connect, com autenticação multifator (MFA) sobreposta. Se quiser entender os detalhes do protocolo, veja nosso conteúdo complementar sobre como funciona a autenticação de gerenciamento de identidade. Para fins de monitoramento, uma característica importa mais: o caminho de login agora cruza sistemas que você não controla totalmente, e cada um deles pode falhar independentemente da sua aplicação.
Por que aplicações autenticadas são difíceis de monitorar
Quatro coisas tornam as aplicações protegidas por IAM mais difíceis de monitorar do que uma página pública.
A parede de login cega verificações simples. Uma verificação de disponibilidade HTTP só pode confirmar que a página de login é exibida. Tudo que os usuários realmente utilizam está atrás da autenticação, então uma falha no fluxo de login ou na aplicação em si é invisível até que alguém reclame.
O fluxo abrange múltiplas partes. Um login único toca sua aplicação, seu IdP, o serviço MFA e muitas vezes um endpoint de token, cada qual em seu próprio domínio com seu DNS, TLS e infraestrutura. Sua aplicação pode estar perfeitamente funcional enquanto uma falha no IdP de terceiros bloqueia todos. O mesmo problema de dependência aparece em aplicações que dependem de SSO em geral.
SSO é uma cadeia de redirecionamentos, não uma página. Fluxos SAML e OAuth/OIDC fazem o navegador pular por dois ou três domínios, trocam asserts ou códigos de autorização, e configuram cookies de sessão no caminho. Uma ferramenta em nível de requisição que não executa JavaScript e segue redirecionamentos como um navegador real vai reportar incorretamente o fluxo em cada etapa.
MFA existe para impedir scripts. Códigos de uso único, prompts push e CAPTCHAs são deliberadamente hostis à automação. O monitoramento precisa trabalhar com o motor de políticas do IdP, não contra ele, o que requer planejamento que uma verificação simples de uptime nunca precisou.
Mapeie a cadeia de redirecionamento SSO antes de scriptá-la
Antes de gravar qualquer coisa, faça o login uma vez em um navegador com as ferramentas de desenvolvedor abertas e anote cada salto. Um fluxo típico iniciado pelo SP (service provider) parece assim: o usuário solicita a aplicação, é redirecionado ao IdP, a página de login do IdP é exibida, as credenciais são enviadas, um desafio MFA aparece, o IdP envia um assert SAML ou retorna um código de autorização OAuth para sua URL de callback, a aplicação o troca por uma sessão, e a primeira página autenticada carrega.
Cada salto dessa cadeia é um ponto de falha distinto: resolução de DNS para o domínio do IdP, certificado expirado na URL de callback, renderização lenta da página do IdP, uma troca de token com timeout. Os saltos que você anotou se tornam os pontos de verificação do seu script, e os limites onde você vai querer dividir o tempo depois.
Anote quais domínios são seus e quais pertencem a um fornecedor. Essa distinção transforma um alerta em uma decisão de roteamento: uma falha no domínio do IdP vai para o time de identidade ou para a página de status do fornecedor, uma falha na callback vai para seu time de aplicação. Se sua arquitetura utiliza OAuth para APIs também, o endpoint de token merece sua própria verificação em nível de requisição; veja monitoramento de tokens JWT e endpoints OAuth para como observar diretamente a emissão de tokens.
O mapa de domínios é também a razão de a página de status do IdP não poder substituir seu próprio monitoramento. Uma faixa verde “Todos os Sistemas em Operação” significa que o serviço do fornecedor está ativo globalmente; não diz nada sobre a configuração SAML do seu tenant, o certificado na sua URL de callback, ou o caminho de rede entre seus usuários e sua página de login. O script ponta a ponta é a única verificação que responde a pergunta que seus usuários realmente fazem.
Como scriptar um fluxo de login autenticado, passo a passo
Passo 1: Crie uma conta dedicada para monitoramento. Configure um usuário de teste com estilo de serviço no seu IdP que exista apenas para monitoramento: privilégios mínimos, sem acesso a dados reais de clientes, e um nome reconhecível como svc-synthetic-monitor para que seus logins sejam fáceis de identificar em logs de auditoria.
Passo 2: Grave o login como uma transação multi-etapas em navegador real. Use uma ferramenta de script em navegador real como EveryStep para capturar a sequência completa: abrir a URL da aplicação, seguir o redirecionamento para o IdP, inserir credenciais, enviar, e chegar na página autenticada. Um navegador real importa aqui porque executa JavaScript, segue redirecionamentos entre domínios, e carrega cookies exatamente como o navegador do usuário.
Passo 3: Decida sua estratégia MFA antes de terminar o script. As opções e seus trade-offs são abordados na próxima seção. Escolha uma deliberadamente; um script que funciona apenas porque o MFA estava em cache vai falhar em algum ponto arbitrário depois.
Passo 4: Faça uma asserção em algo que apenas um usuário logado vê. Acesso a uma URL não prova login. Valide um elemento pós-login, como o título do painel de controle ou o nome de exibição da conta, usando asserções de conteúdo. Muitos logins falhos caem numa página de erro estilizada que retorna HTTP 200, e só uma asserção detecta isso.
Passo 5: Estenda o script uma tarefa além do login. Abra um registro, execute uma busca, carregue um relatório. A autenticação suceder enquanto a aplicação está quebrada é um modo real de falha, e um passo extra cobre isso. A estrutura é igual a qualquer script de monitoramento de transações web: cada ação do usuário é um passo, e cada passo é medido.
Passo 6: Defina limites e alertas por passo. Dê a cada passo seu próprio orçamento de tempo e conecte falhas às suas regras de alerta, para que a mensagem diga “passo MFA ultrapassou limite,” não só “login lento.”
Passo 7: Execute-o de onde seus usuários estão. Locais externos para uma aplicação SaaS pública; um agente privado dentro da sua rede para aplicações internas cujo IdP ou camada app não seja acessível da internet pública.
Gerenciando MFA e OTP em scripts sintéticos
MFA é onde a maioria dos projetos de monitoramento autenticado emperra, porque o objetivo do segundo fator é que apenas a senha, que é tudo que um script naturalmente tem, não basta. Existem quatro estratégias viáveis, e a correta depende do quanto do passo MFA você precisa testar versus o quão estritamente seu time de segurança controla exceções.
| Estratégia | Como funciona | Compromisso | Melhor para |
|---|---|---|---|
| Isenção de acesso condicional | Política do IdP pula o MFA para a conta de teste quando faz login de IPs de monitoramento conhecidos | O passo MFA em si não é testado; exige escopo rigoroso de IP | Times cujo IdP suporta políticas baseadas em rede |
| Seed TOTP no script | Conta de teste se inscreve num autenticador; o script armazena a seed em um cofre e calcula o código atual em runtime | A seed é um segredo permanente que deve ser guardado e rotacionado | Exercitar e cronometrar totalmente o passo real de MFA |
| Recuperação de OTP por email ou SMS | O script consulta uma caixa de email de teste ou endpoint SMS pelo código de uso único e o digita | Lento e dependente de entrega, causando mais falsos positivos | Apps que só oferecem códigos por email ou SMS |
| Senhas de app / códigos de bypass | Uma credencial secundária estática evita o desafio interativo | Opção mais fraca; muitos IdPs estão eliminando isso | Aplicações legadas sem opção melhor |
A abordagem TOTP merece a posição padrão quando seu IdP permite. Como códigos baseados em tempo são gerados a partir de uma seed compartilhada por um algoritmo documentado, um script pode produzir um código válido em tempo de execução e passar pelo desafio real, ou seja, o monitor cronometra o passo MFA em vez de ignorá-lo. Para um guia detalhado desse padrão, veja como monitorar aplicações web protegidas por OTP.
O que quer que escolha, restrinja isso à conta de monitoramento apenas. Uma isenção de MFA ou código de bypass aplicada além de um único usuário de teste com privilégios mínimos, restrito por IP de origem, transforma uma conveniência de monitoramento numa superfície de ataque. Seu time de segurança deve aprovar o mecanismo, e a isenção deve aparecer nas revisões de política deles.
Mantendo as credenciais de monitoramento seguras
Um monitor de login é um conjunto de credenciais válidas executando em uma programação, e deve ser tratado com o mesmo cuidado de qualquer outra credencial de serviço.
Nunca use a conta de um humano. Contas reais expõem dados reais em capturas e gravações, quebram o monitor a cada troca de senha, e poluem logs de segurança com atividade que ninguém pode atribuir. A conta que você criar deve passar na pergunta do raio de impacto: se essa credencial vazar, o que alguém poderia ver ou alterar antes de ser desativada? A resposta correta é entediante — sem papéis administrativos, sem registros de clientes, sem capacidade de criar tokens duráveis.
Guarde os segredos num cofre. Senhas, seeds TOTP e segredos de cliente devem ficar em armazenamento criptografado que o script referencia em runtime, como o Secure Vault do Dotcom-Monitor, nunca em texto no script, onde eles acabam em exportações, histórico de versões e telas compartilhadas. A mascaramento deve se estender a logs, capturas de tela e gravações que o monitor produz.
Rotacione periodicamente e agende isso. Rotação de credenciais é boa prática, e uma senha expirada da conta de teste é também a fonte mais comum de alertas falsos de login. Rotacione a entrada no cofre, não os scripts, para que uma atualização se propague a todos os lugares, e defina um lembrete antes de qualquer política de expiração forçada que seu IdP aplique.
Torne logins sintéticos identificáveis. Uma conta claramente nomeada e IPs de origem conhecidos permitem que seu time de segurança distinga o monitor de tentativas de stuffing de credenciais, e permitem que você exclua suas sessões das análises do produto para que não inflacionem os números de uso.
Expiração de sessão, atualização de token e lógica de novo login
Sessões são onde monitores autenticados silenciosamente apodrecem. Dois comportamentos opostos causam problemas: um monitor que reutiliza um cookie de sessão em cache para de testar o login completamente, e um que herda uma sessão semi-expirada falha de maneiras que a aplicação nunca mostrou a um usuário real.
A regra que previne ambos: comece cada execução programada com uma sessão de navegador limpa, sem cookies ou tokens trazidos da execução anterior. Uma página limpa força toda a cadeia de redirecionamento, envio de credenciais e MFA a cada ciclo, portanto uma falha do IdP aparece na próxima execução ao invés de ficar escondida atrás de um cookie ainda válido.
A persistência da sessão vale a pena ser testada também, mas com intenção e separadamente. Se sua aplicação depende de atualização silenciosa de token para manter usuários logados, construa uma transação mais longa cujos passos posteriores sejam executados após o tempo de vida do token de acesso expirar, e valide que o usuário continua logado ao final. Uma falha na atualização aparece quando usuários são jogados de volta à página de login no meio de uma tarefa, que é exatamente o sintoma que este script reproduz.
No nível da API, a emissão de tokens pode ser monitorada sem navegador: uma verificação em nível de requisição contra o endpoint OAuth verifica se tokens estão sendo emitidos e aceitos em cada ciclo. O monitoramento OAuth API do Dotcom-Monitor lida com esse fluxo, e combina bem com o script no nível do navegador, pois juntos eles separam “o IdP não pode emitir tokens” de “a aplicação não pode consumi-los.”
Cronometragem por passo: onde o fluxo autenticado desacelera
“Login demorou nove segundos” não é algo acionável. Nove segundos em que parte? Um fluxo autenticado cruza pelo menos duas organizações, então o valor do monitor depende de dividir esse total nos limites que você mapeou antes: redirecionamento inicial, renderização da página do IdP, validação de credencial, desafio MFA, troca de assert ou token, e carregamento da primeira página autenticada.
Passos roteirizados em navegador lhe dão exatamente essa divisão, porque cada passo é cronometrado independentemente e vem com sua própria cascata de requisições. Estabeleça um intervalo normal para cada passo baseado em linha de base, em vez de olhar execuções individuais, e alerte em desvios no nível do passo, para que uma regressão num salto se destaque mesmo quando o total ponta a ponta ainda pareça aceitável.
Cronometragem por passo transforma uma discussão numa decisão de roteamento. Se o tempo de renderização da página do IdP dobrou, o ticket vai para o fornecedor de identidade com timestamps anexados. Se o carregamento da página pós-callback dobrou, vai para seu time de aplicação. Sem essa divisão, ambos os times apontam um para o outro.
O roteamento fica mais claro se cada passo carrega uma tag de dono desde o dia que você o mapeou: pertencente à aplicação (a URL de callback, criação da sessão, a primeira página autenticada), pertencente ao IdP (renderização da página de login, validação de credenciais, troca de token), pertencente à política (o desafio MFA, decisões de acesso condicionado, prompts de consentimento), e pertencente à rede (DNS, TLS, proxies, acessibilidade do agente privado). Um alerta que diz “passo pertencente à política mudou” abre uma transferência de incidente em vez de um debate na sala de crise.
Bases por passo também detectam modos lentos de falha que verificações binárias de ativo/inativo nunca captam: um serviço MFA que vai de um segundo para cinco ao longo de um mês nunca dispara um alerta de interrupção, mas degrada cada login, e isso é claramente visível numa linha de tendência de cronometragem por passo. Monitore o fluxo do login como você monitoraria qualquer página de login, e deixe os dados por passo mostrar qual lado da fronteira SSO precisa de atenção.
Conclusão
Monitorar uma aplicação protegida por IAM significa monitorar o caminho da autenticação como parte da aplicação, porque para seus usuários é isso. A receita prática: mapeie a cadeia de redirecionamento SSO, rode o login completo como uma transação multi-etapas em navegador real sob uma conta dedicada de privilégios mínimos, trate o MFA deliberadamente com uma isenção restrita ou uma seed TOTP em cofre, mantenha todos os segredos em armazenamento criptografado, comece cada execução com uma sessão limpa, e divida os tempos em cada salto para que as falhas sejam encaminhadas ao time correto no primeiro alerta.
Faça isso, e a parede de login deixa de ser um ponto cego. Você vai saber que o IdP está lento antes que o suporte saiba, vai saber se a falha é sua ou do fornecedor, e terá o registro passo a passo para provar qualquer caso.
Monitore por trás da parede de login
Scripte todo o seu login SSO como uma transação de monitoramento sintético em navegador real com o EveryStep, guarde as credenciais em cofre, e cronometre cada passo do fluxo. Comece um teste gratuito.
