Pular para o conteúdo principal

Casos de Uso

Abaixo são apresentados exemplos práticos de como o GuardianKey Auth Bastion Enterprise pode ser configurado para diferentes cenários de proteção de sistemas web. Cada caso de uso traz uma descrição resumida, o objetivo da proteção, o fluxo de autenticação esperado e as configurações recomendadas no bastião.

⚠️ Importante: cada implementação pode ter variações conforme as características técnicas do sistema protegido. A equipe de Sucesso do Cliente da GuardianKey está disponível para apoiar nas decisões de configuração e integração.

Índice​

🧩 Caso 1: Sistema com login baseado em e-mail (2FA com TOTP)​

Descrição​

Sistema web onde o usuário se autentica com e-mail e senha. Deseja-se proteger o acesso adicionando autenticação em dois fatores (2FA) com TOTP (ex: Google Authenticator).

Objetivo​

Adicionar MFA antes do formulário de login, sem alterar o sistema.

Fluxo​

Usuário acessa /login → Bastião exige TOTP → Se válido, exibe formulário → Autenticação no sistema

Configuração no bastião​

  • Auth Type: TOTP
  • Registration Method: email
  • Token Path: /login
  • Token TTL: 3600
  • User Pool: opcional
  • Backends: http://10.0.0.10:8080

📌 Dica: não há necessidade de API externa, pois o bastião usa o e-mail como identificador principal.

🧩 Caso 2: Sistema com username diferente de e-mail (2FA com validação via credenciais)​

Descrição​

Sistema onde o login usa um identificador personalizado (ex: matrícula, apelido etc.). A proteção com 2FA usará TOTP, mas o bastião precisa validar a identidade do usuário para permitir o cadastro do segundo fator.

Objetivo​

Proteger o acesso com MFA e validar a identidade antes de registrar o 2FA.

Fluxo​

Usuário acessa /login → Bastião exige 2FA (não cadastrado) → Redirecionado ao login do sistema → Validação via credenciais → TOTP gerado → Acesso liberado

Configuração no bastião​

📌 Dica: o bastião observará a resposta do login original para verificar se as credenciais estão corretas. A API pode retornar 200 OK ou um campo específico no corpo da resposta.

🧩 Caso 3: Autenticação com GovBR (CPF como identificador)​

Descrição​

Sistema web público onde o login é baseado em CPF. Deseja-se substituir o login local por autenticação via GovBR (OAuth2).

Objetivo​

Usar identidade federada do GovBR como método principal de autenticação.

Fluxo​

Usuário acessa sistema → Bastião exibe botão "Login com GovBR" → Login via OAuth2 → CPF recebido → Redirecionamento para aplicação autenticada

Configuração no bastião​

  • Auth Type: GovBR
  • Registration Method: Disabled
  • GovBR Integration:
    • Client ID / Secret / Endpoint fornecidos pelo GovBR
    • JavaScript customizável para injeção do botão
  • Token TTL: 3600
  • User Pool: opcional

📌 Requisito: o sistema protegido deve ter o CPF do usuário para correlação pós-login.

🧩 Caso 4: Integração somente via API (sem uso do painel do GDN)​

Descrição​

Ambiente corporativo que gerencia usuários e 2FA exclusivamente via API REST, sem utilizar a interface gráfica do bastião.

Objetivo​

Automatizar o provisionamento e validação de 2FA diretamente no backend.

Fluxo​

Sistema chama API /register-user → Usuário recebe chave TOTP → App lê QR Code → Valida código via API /verify → Acesso liberado

Endpoints utilizados (exemplo fictício)​

  • POST /api/users/register 
    { "username": "joao", "email": "[email protected]" }
  • GET /api/users/joao/totp → Retorna QR Code
  • POST /api/users/joao/verify 
    { "totp": "123456" }

Configuração no bastião​

  • Auth Type: TOTP
  • Registration Method: API
  • Data Integration Endpoint - Auth: https://meusistema.local/api/verify
  • User Pool: obrigatório (para correlacionar via API)
  • Painel: não utilizado neste cenário

📌 Nota: ideal para sistemas com painel próprio ou integração com portais já existentes.

🧩 Caso 5: Múltiplos sistemas no mesmo domínio com usuários compartilhados​

Descrição​

Empresa com vários sistemas hospedados sob o mesmo domínio (ex: /erp, /rh, /portal) e deseja proteger todos com 2FA compartilhado.

Objetivo​

Aplicar MFA em diversos serviços reutilizando a base de usuários.

Fluxo​

Usuário acessa /erp/login → Bastião valida TOTP → Redireciona ao ERP  
Usuário acessa /rh/login → TOTP já ativo → Redireciona direto

Configuração no bastião​

  • Criar um authgroup por sistema (ex: ERP, RH, Portal).
  • Usar o mesmo User Pool em todos.
  • Definir Token TTL e Token Path específicos por sistema.
  • Configurar Backend por serviço.

📌 Dica: o token 2FA pode ser reutilizado enquanto estiver dentro do TTL.

🧩 Caso 6: Usuário com política personalizada (whitelist ou TTL especial)​

Descrição​

Cenário onde um usuário específico deve ter comportamento diferente dos demais, como:

  • Isenção de 2FA (whitelist).
  • Sessão com TTL estendido.

Objetivo​

Aplicar controle granular com base no perfil do usuário.

Configuração no bastião​

  1. Acesse User Policies.
  2. Adicione uma nova linha:
    • Authgroup: Portal
    • Username: admin01
    • Action: Whitelist ou Token TTL = 14400 (4h)

📌 Nota: as políticas por IP (IP Policies) têm prioridade sobre as de usuário.

🧩 Caso 7: Política por IP (liberação para redes confiáveis)​

Descrição​

Empresa deseja isentar a exigência de 2FA para acessos originados de uma rede interna ou IP fixo confiável.

Objetivo​

Reduzir fricção para usuários internos, mantendo segurança externa.

Configuração no bastião​

  1. Acesse IP Policies.
  2. Adicione nova linha:
    • Authgroup: Intranet
    • CIDR: 192.168.0.0/24
    • Action: Whitelist

📌 Boa prática: combine com Firewalling para restringir países de origem e fortalecer a segurança externa.

📘 Conclusão​

Os casos apresentados demonstram a flexibilidade e facilidade de adoção do GuardianKey Auth Bastion Enterprise em diferentes contextos. Seja com foco em MFA, login federado via GovBR, automação via API ou controle granular por política, a solução permite proteger aplicações web de forma robusta e escalável.

Para apoiar em qualquer etapa de integração, conte com a equipe de Sucesso do Cliente da GuardianKey.