Pular para o conteúdo principal

Painel e Interface (Guia para Administradores)

O painel do GuardianKey Auth Bastion Enterprise, acessado por meio da GDN Cyber Security Platform, concentra todas as funcionalidades de administração, monitoramento e configuração do bastião.

Todas as opções estão organizadas no menu lateral esquerdo em “GK Auth Bastion”. Esta seção apresenta um guia prático para administradores, explicando o propósito e a utilização de cada item do painel.


📌 TOC (Table of Contents)


🧩 Conceitos Fundamentais

Antes de começar a configurar o GuardianKey Auth Bastion Enterprise, é importante entender a estrutura lógica da ferramenta. Compreender esses conceitos permitirá criar uma arquitetura de autenticação organizada, escalável e segura.

A seguir, explicamos os principais elementos e como eles se relacionam:


🏢 Organization

A Organization é o nível mais alto da estrutura. Ela representa uma entidade lógica ou cliente dentro da plataforma. Toda a configuração do bastião (domínios, grupos de autenticação, usuários, tokens, políticas) fica dentro do escopo da organização.

Características:

  • Cada organização pode ter vários domínios e authgroups.
  • Você pode ter múltiplos bastiões (nós) atuando em alta disponibilidade ou balanceamento dentro da mesma organização.
  • As integrações com módulos externos (GovBR, GKAS, GKTinc) também são feitas por organização.

Exemplo: Em um ambiente multicliente, cada cliente pode ter sua própria Organization, isolada logicamente.


🌐 Domain Name

O Domain Name representa o FQDN (nome de domínio completo) que será protegido pelo bastião.

Características:

  • Pode ser um domínio (ex: empresa.com.br) ou subdomínio (ex: sso.empresa.com.br).
  • O bastião escuta na porta definida (ex: 443) para esse domínio.
  • Pode usar certificado manual (enviado pelo administrador) ou Let's Encrypt (renovação automática).
  • Deve estar vinculado a pelo menos um Authgroup para ter funcionalidade.

Importante: Domínios sem authgroups vinculados não possuem lógica de proteção e não são operacionais.


🔐 Authgroup

O Authgroup representa uma unidade de autenticação — geralmente um sistema ou serviço protegido.

Características:

  • Cada authgroup é vinculado a um único domínio.
  • Pode proteger múltiplos caminhos (paths) dentro do domínio (ex: /sistema1, /sistema2).
  • Define:
    • Caminhos protegidos
    • Tipo de autenticação (TOTP, e-mail, GovBR etc.)
    • Método de cadastro (registro por e-mail, senha, API, etc.)
    • Token TTL e path
    • Integrações externas (GovBR, GKAS, GKTinc)
  • O roteamento para o sistema de destino é feito via lista de backend servers.

Exemplo: No domínio cliente.com.br, você pode ter:

  • Authgroup "Sistema 1" protegendo /sistema1
  • Authgroup "Sistema 2" protegendo /sistema2

Nota: Não é possível usar o mesmo authgroup em mais de um domínio. Para isso, é necessário duplicar a configuração em outro authgroup.


🧑‍🤝‍🧑 User Pool

O User Pool permite compartilhar os usuários de 2FA entre authgroups diferentes.

Características:

  • Se dois ou mais authgroups estiverem vinculados ao mesmo user pool, os usuários 2FA são comuns entre eles.
  • Permite aplicar uma política unificada de MFA em múltiplos sistemas.
  • Pode ser editado a qualquer momento, sem impacto de segurança.

Exemplo: Se o usuário "[email protected]" se registra no authgroup do Sistema A, ele poderá ser autenticado no Sistema B sem novo cadastro, desde que ambos compartilhem o mesmo User Pool.


🔁 Backend Servers

Os Backend Servers são os destinos para onde o bastião encaminha a requisição após a autenticação ser validada.

Características:

  • Podem ser um ou mais IPs/hosts (um por linha).
  • O balanceamento é feito por round-robin.
  • Suporta backends HTTP ou HTTPS, de qualquer tecnologia (PHP, Node, Java, etc).

Exemplo: um authgroup pode redirecionar usuários autenticados para http://10.0.1.20:8080, http://10.0.1.21:8080 etc.


🔑 Token Path e Token TTL

O Token Path e o Token TTL definem como o bastião gerencia a sessão autenticada de um usuário.

Token Path:

  • Define em que URL o token de sessão será válido.
  • Evita reutilização do token em outras rotas.

Token TTL:

  • Define o tempo de validade do token de sessão (ex: 30 minutos, 2 horas).
  • Após expirar, o usuário precisa passar pelo 2FA novamente.

Importante: O TTL se aplica apenas à sessão, não ao código TOTP.


🔐 Tipos de Autenticação

Você pode escolher o método de autenticação e registro dos usuários 2FA:

  • Tipos de autenticação:

    • TOTP: padrão por aplicativo autenticador.
    • E-mail: código enviado ao e-mail do usuário.
    • Bastion: controle total via bastião.
    • GovBR: login via OAuth2.
    • Disabled: desativa autenticação.
  • Métodos de registro (onboarding):

    • E-mail: usuário se registra com base no e-mail.
    • Credentials: usuário informa login/senha e o bastião valida no sistema protegido.
    • API: integração direta com sistema externo para validação.
    • Bastion: bastião controla todo o processo.

🧱 Estrutura Lógica (Resumida)

Organization
└── Domain Name(s)
└── Authgroup(s)
├── Protected paths
├── Backends
├── Auth method
├── Token policy
└── (opcional) Integrações externas

Essa estrutura lógica resume a hierarquia principal do GuardianKey Auth Bastion, facilitando o planejamento e a configuração inicial. Certifique-se de que cada elemento esteja devidamente configurado para garantir a segurança e o funcionamento adequado da solução.

📊 Dashboards

Objetivo: Monitorar a atividade e o estado da solução em tempo real.

  • Bastion Events: gráfico temporal com eventos classificados em:
    • info (verde): eventos operacionais normais.
    • warn (amarelo): situações atípicas que não impediram o funcionamento.
    • error (vermelho): falhas críticas ou bloqueios.
  • Authentication Event Levels: visão geral dos níveis de evento (gráfico pizza).
  • Top Users / IPs / Types / Status: rankings úteis para identificar abusos ou picos.

🔧 Ações recomendadas:

  • Usar os filtros avançados para analisar períodos específicos.
  • Clicar em "Show/hide filter panel" para refinar os dados.
  • Exportar relatórios (Excel, CSV, PDF) para auditoria ou gestão.

👤 Users (Usuários 2FA)

Objetivo: Gerenciar usuários que utilizarão autenticação em dois fatores.

Tela principal:

  • Exibe todos os usuários com 2FA habilitado.
  • Colunas: ID, Authgroup, Username, E-mail, Data de criação, TOTP status.

Ações:

  • Editar/Visualizar: permite alterar o status do TOTP:
    • not set: sem TOTP.
    • active: TOTP ativo.
    • validated: TOTP confirmado.
    • inactive: TOTP desativado.
    • renew: forçar novo cadastro de TOTP.
  • Excluir: remove o usuário do 2FA.

📌 Importante: para "resetar" um TOTP, basta alterar seu status para renew.


🔑 Auth Tokens

Objetivo: Visualizar e administrar os tokens de sessão gerados após o 2FA.

Tela principal:

  • Lista de tokens ativos.
  • Colunas: ID, Authgroup, Username, User ID, TTL, Criação, Atualização.

Ações:

  • Editar: consultar e alterar:
    • TTL (tempo de vida da sessão)
    • IPs permitidos (Allowed IPs)
  • Excluir: força expiração do token.

🛡️ Boa prática: usar Allowed IPs para limitar reutilização de tokens em IPs não autorizados.


📁 Explore Events

Objetivo: Investigar e auditar eventos em detalhe.

Tela:

  • Mostra todos os eventos gerados pela solução.
  • Colunas: Data/hora, Authgroup, Username, IP, Tipo, Status, Nível, Detalhe.

🔍 Dicas de uso:

  • Use o campo "search" para localizar termos específicos (em qualquer coluna).
  • A filtragem pode ser feita por qualquer campo.
  • Para exportações maiores, entre em contato com o suporte GuardianKey.

⚙️ Settings

Objetivo: Realizar a configuração central da solução. Esta é a parte mais sensível do painel.


🌐 Domain Names

Cadastro de domínios monitorados pelo bastião.

  • Cada linha da tabela representa um domínio (FQDN) protegido.
  • Permite escolher método de certificado:
    • Let's Encrypt (renovação automática)
    • Manual (cliente insere o certificado)

📥 Para adicionar:

  1. Clique em “Add new row”.
  2. Preencha os dados, incluindo certificado (ou deixe em branco para autoassinado).

🔒 Auth Groups

Grupos de autenticação por sistema (ex: sistema1, sistema2 etc.)

  • Relacionam domínios, caminhos e métodos de 2FA.
  • Permite definir:
    • Caminhos protegidos
    • Backends de autenticação (balanço automático entre servidores)
    • Tipo de autenticação (e-mail, TOTP, GovBR, etc)
    • Forma de cadastro de usuário
    • TTL do token
    • Endpoints de integração com sistemas legados
    • Reaproveitamento de usuários com “User Pool”

💡 Importante:

  • Cada authgroup define como o 2FA funciona em um sistema.
  • Você pode ter vários authgroups no mesmo domínio, protegendo sistemas diferentes.

🔌 GK Integrations

Integrações com os módulos avançados GuardianKey.

  • GK Auth Security: insere análise de risco baseada em score.
  • GK TINC: aplica desafios criptográficos contra bots.

📌 Para ativar:

  • Preencha os campos de ID, chave e IV conforme dados da integração.

🧩 Templates

Personalize os HTMLs das mensagens e telas do bastião.

  • E-mails: suportam variáveis dinâmicas (ex: {{username}}, {{token}}).
  • Telas do bastião: estáticas (não suportam variáveis dinâmicas).

📝 Dica: use para adaptar a comunicação visual da sua empresa.


📧 E-mail Settings

Configure o envio de e-mails da solução (OTP, cadastro, notificações).

  • Defina:
    • Assuntos e domínios permitidos por tipo de e-mail.
    • SMTP (host, porta, método, autenticação).
  • Use o botão de teste para validar as configurações.

🌍 Firewalling

Restringe acesso por país (georrestrição).

  • Modos disponíveis:
    • Desabilitado
    • Permitir somente países selecionados
    • Negar apenas os países selecionados

📌 Exibição por nome do país (não código ISO).


🆔 GovBR Integration

Configura a autenticação via GovBR para o login principal (não é 2FA).

  • Define:
    • Ambiente (staging / produção)
    • OAuth2 Client ID e Secret
    • Endpoint e script de injeção do botão "login com GovBR"

📌 Importante: para múltiplos ambientes, crie um authgroup por ambiente.


📜 Audit Logs

Exibe todas as alterações realizadas nas configurações do bastião.

  • Útil para rastrear mudanças administrativas.

👤 User Policies

Regras aplicadas a usuários específicos.

  • Permite criar exceções ou ajustar TTL individualmente.
  • Exemplo: liberar 2FA para um admin temporariamente.

📌 Prioridade: regras de IP têm precedência sobre regras de usuário.


🌐 IP Policies

Regras por IP/CIDR.

  • Ideal para whitelisting de redes corporativas.
  • Útil para isentar máquinas específicas da exigência do 2FA.

✅ Boas Práticas para Administradores

  • Revise periodicamente os authgroups e domínios cadastrados.
  • Use os dashboards para detectar anomalias de acesso.
  • Utilize User Policies e IP Policies com moderação.
  • Ative as integrações com GKAS e GKTinc para máxima segurança.
  • Documente e revise alterações com base nos audit logs.

📘 Documentação Complementar

Para detalhes sobre permissões de acesso, gerenciamento de usuários da plataforma e integração com outras soluções GuardianKey, acesse:

👉 guardiankey.io/docs/gdn