Pular para o conteúdo principal

Especificações Técnicas

Abaixo são apresentadas as especificações técnicas do GuardianKey Auth Bastion Enterprise, detalhando as principais funcionalidades, que podem ser usadas para comparar com outras soluções.

Índice​

Especificações Gerais​

O GuardianKey Auth Bastion tem como foco a proteção de sistemas contra acessos não autorizados.

O sistema possui as seguintes partes: i) Bastião que atua como proxy-reverso para as aplicações protegidas, interceptando as requisições e implementando as camadas de proteção; ii) Controlador que processa os eventos e mantem a base de dados e configurações; iii) Console de administração web que permite a configuração do sistema e visualização dos eventos.

O GuardianKey Auth Bastion possui as seguintes recursos de segurança que podem ser configurados para proteger sistemas web: i) Implementação de segundo fator de autenticação (2FA) sem necessidade de alteração do sistema protegido; ii) Integração de aplicação protegida com login a autenticador via protocolo OAuth2/OIDC; iii) Bloqueio de acessos a partir de países previamente definidos;

O sistema permite a proteção de mais de um sistema web a partir do mesmo Bastião, permitindo a segmentação de usuários e políticas de segurança por sistema protegido.

O sistema permite a configuração de políticas de segurança por caminho (path) do sistema protegido.

Ao acessar uma aplicação protegida pelo GuardianKey Auth Bastion, o sistema intercepta a requisição e procede conforme as configurações definidas pelo administrador via console de administração web.

O sistema permite a configuração de políticas de segurança por Authgroup, que é a política de segurança que pode ser aplicada para um ou mais caminhos (paths) de uma URL de aplicação protegida.

O sistema permite a implementação do Second Factor First Authentication SFFA, que exige a autenticação do segundo fator antes do acesso ao formulário de login do sistema protegido, permitindo maior proteção e simplicidade na implementação.

O sistema permite os seguintes métodos de autenticação que podem ser definidos por Authgroup.

  • TOTP por aplicativo - autenticação de segundo fator por meio de aplicativo autenticador, compatível com RFC 6238, como Google Authenticator, entre outros;
  • OTP via e-mail - autenticação por meio do envio do código de uso único (segundo fator) por e-mail;
  • OTP via integração - autenticação por meio do envio do código de uso único (segundo fator) via POST em endpoint configurável, que pode ser usado para envia via canais como Telegram, SMS, dentre outros;
  • OAuth2/OIDC - autenticação via sistema OAuth2/OIDC, como o GovBR.
  • Customizado (Bastion) - autenticação que pode ser customizada por meio de código LUA.
  • Interação por API (Disabled) - o sistema permite que uma aplicação protegida interaja com o GuardianKey Auth Bastion via API, para a geração de códigos criptográficos, validação de OTPs, registros de eventos, dentre outros recursos.

Para as telas apresentadas pela solução, o sistema permite a integração com as seguintes soluções:

  • GuardianKey Auth Security - integração com o GuardianKey Auth Security na validação de OTPs e no registro de usuários a fim de geração de QR Code, com o objetivo de proteger esses acessos a ataques de autenticação;
  • GuardianKey GKTinc - integração com o GuardianKey GKTinc nos formulários submetidos a fim de dissuadir ataques de força bruta e tentativas automatizadas de acesso.

O sistema registra auditorias de alteração de configurações realizadas pela console de administração web das entidades: políticas (Authgroup), URLs protegidas (Domain names), políticas de usuários (User Policies), políticas para IPs (IP Policies), usuários (Users) e tokens (Auth Tokens).

O sistema permite criar organizações que podem conter vários grupos de autenticação (Authgroups) e URLs protegidas (Domain names), permitindo segmentar os usuários e políticas de segurança por organização.

O sistema permite a definição de um ou mais backend (servidores de aplicação) para cada Authgroup.

Quando necessário para controle de sessão, o sistema faz uso de token de autenticação, que é gerado pelo Bastião e enviado para o navegador do usuário. Na administração do sistema, é possível definir o tempo de vida do token (TTL) e o path de sua validade.

Os tokens são assinados com uma chave criptográfica informada na configuração do Authgroup, que pode ser usada para validar a autenticidade do token pela aplicação protegida.

Os tokens possuem as seguintes informações:

  • Username: nome do usuário autenticado;
  • Tokens auxiliares: tokens auxiliares, quando aplicável, como exemplo para integrações OAuth2/OIDC;
  • Allowed IPs: lista de endereços IP válidos para o token, isto é, aqueles que foram autenticados;
  • Token Hash: assinatura usando hash SHA-256, que é usado para validar a autenticidade do token.

Na configuração do Authgroup, é possível definir um grupo de usuários (user pool) de outro Authgroup, permitindo o reaproveitamento ou compartilhamento de usuários já cadastrados em mais de um grupo de autenticação.

Para os métodos de autenticação que implementem o segundo fator de autenticação (2FA) antes do formulário de login, o sistema possui um fluxo com telas customizáveis, que podem ser adaptadas para o estilo visual da aplicação protegida.

O sistema permite a configuração de envio de e-mails por meio de SMTP, permitindo os métodos "clear text", "TLS" e "SSL", com autenticação ou não, para o envio de instruções de cadastro do TOTP por aplicativo e envio de OTP via e-mail.

O sistema permite parametrizar o endereço de e-mail do remetente, assunto da mensagem e corpo da mensagem, para o envio de instruções de cadastro do TOTP por aplicativo e envio de OTP via e-mail.

A solução permite o provisionamento de um ou mais módulos Bastião por organização, que atuam como proxy reverso para as aplicações protegidas, interceptando as requisições e implementando as camadas de proteção.

URLs protegidas​

A solução suporta a geração automática de certificados SSL para as URLs protegidas, utilizando o Let's Encrypt, com renovação automática. O sistema também permite a inserção de certificados SSL manualmente, caso o administrador não queira utilizar o Let's Encrypt.

O sistema permite a configuração para o redirecionamento de portas HTTP para HTTPS, garantindo que todas as requisições sejam feitas de forma segura.

A solução permite a indicação na console de administração web dos parâmetros SSL e cifras SSL que serão utilizados para as URLs protegidas, permitindo a configuração de segurança adicional.

Para cada URL protegida, é possível configurar um ou mais backends (servidores de aplicação), permitindo o balanceamento de carga entre os servidores.

A solução permite a customização do nome de host que deve ser utilizado para acessar a URL protegida, permitindo que o sistema seja acessado por um nome de domínio específico, para permitir o correto funcionamento do proxy reverso.

Método de autenticação TOTP por aplicativo​

Conforme RFC 6238, a autenticação TOTP por aplicativo requer que o usuário tenha o aplicativo autenticador instalado em seu dispositivo móvel, onde o usuário deve cadastrar a chave criptográfica fornecida pelo sistema. O sistema GuardianKey Auth Bastion permite a geração de QR Code para o cadastramento da chave criptográfica, que pode ser lido por aplicativos autenticadores.

O sistema possui processo implementado para a identificação do usuário, validação do código de uso único (TOTP) e geração de QR Code para o cadastramento do usuário no aplicativo autenticador.

Para a validação do usuário a fim de apresentar o QR Code, o sistema permite os seguintes métodos:

  • E-mail - envio de instruções para o e-mail do usuário com link para geração do QR Code;
  • Credenciais - validação do usuário por meio de credenciais (usuário e senha) via endpoint de integração;
  • API - cadastro de usuários e geração de código para QR Code via API;
  • Customizado (Bastion) - validação do usuário por meio de código LUA customizado.

A tela de visualização do QR Code não é apresentada após o usuário ter usado o TOTP por aplicativo pela primeira vez, para evitar que o QR Code seja reutilizado.

O sistema permite a definição de uma data de início para requerer o uso de TOTP por aplicativo obrigatório. Antes dessa data, o usuário pode optar por postergar o uso clicando em botão apropriado. Essa funcionalidade reduz a fricção com usuário e dificuldades de adoção do TOTP por aplicativo.

Na configuração da política de autenticação (Authgroup), é possível definir o "TOTP issuer name", que é o nome da entidade que emite o TOTP, e será utilizado para identificar a origem do TOTP no aplicativo autenticador do usuário.

Para o envio de instruções de cadastro do TOTP por aplicativo para e-mails, o sistema permite a indicação de domínios que são permitidos. Essa funcionalidade permite restringir o cadastro apenas a usuários com e-mails de domínios específicos, como por exemplo, apenas usuários com e-mails da instituição.

Método de autenticação OTP via e-mail e OTP via integração​

Para o envio do segundo fator de autenticação por e-mail, o sistema permite a indicação de domínios que são permitidos. Essa funcionalidade permite restringir o envio apenas a usuários com e-mails de domínios específicos, como por exemplo, apenas usuários com e-mails da instituição.

O sistema permite o envio de código de uso único (OTP) via POST em endpoint HTTP/REST configurável, que pode ser usado para enviar o código por outros canais, como Telegram, SMS, entre outros.

Método de autenticação OAuth2/OIDC​

O sistema permite a implementação em sistemas protegidos de autenticação via OAuth2/OIDC, como o GovBR. Para isso, é necessário informar os parâmetros de integração, como Client ID, Client Secret e Endpoints de autorização.

A implementação do OAuth2/OIDC ocorre por meio da injeção de código JavaScript customizável na página de login do sistema protegido. Esse código deve fazer os ajustes necessários na tela a fim de exibir o botão "Login com OAuth2" com a URL de autorização do OAuth2/OIDC gerada pelo GuardianKey Auth Bastion. O código em Javascript pode ser usado para retirar o formulário e botão de login originais do sistema protegido, caso seja necessário. Dessa forma, a alteração do sistema protegido ocorre sem a necessidade de modificar o código fonte do sistema.

Após a autenticação via OAuth2/OIDC, o autenticador redireciona para a URL de callback do GuardianKey Auth Bastion, que submete informações ao endpoint de integração, que cria a sessão do usuário autenticado diretamente no sistema protegido. Esse código de integração é parametrizado dependendo do sistema protegido.

O sistema envia os cookies de sessão do usuário e redireciona o usuário autenticado para a tela do sistema protegido.

Firewalling por geolocalização​

O sistema permite a configuração de firewalling por geolocalização, que pode ser aplicado para bloquear acessos a partir de países previamente definidos.

A funcionalidade de firewalling por geolocalização é configurada por Authgroup, podendo ficar desabilitada, habilitada no modo "Whitelist" (lista de países permitidos) ou no modo "Blacklist" (lista de países bloqueados). Nos dois últimos modos, é possível indicar quais países devem ser permitidos ou bloqueados, respectivamente.

Endpoints de integração​

O sistema permite integrações via API HTTP/REST para endpoints informados na configuração a fim de:

Recuperar informações de e-mail do usuário para envio de instruções de cadastro do TOTP por aplicativo, ou para o envio de código de uso único (OTP) via e-mail.

Enviar OTP para implementação que permite envio do código por outros canais, como Telegram, SMS, entre outros.

Validação de autenticação de usuário, que pode ser utilizado para validar o usuário e gerar o QR Code para o TOTP por aplicativo.

Identificar as configurações de autenticação de usuário ao método OAuth2/OIDC, o que permite, por exemplo, exigir uso de autenticação por OAuth2/OIDC apenas para usuários específicos.

Console de administração e visualização de eventos​

O GuardianKey possui console web responsivo para a administração de políticas e para a visualização de eventos.

A console de administração e visualização dos eventos é em tecnologia WEB, responsiva, dispensando a instalação de qualquer software adicional para o acesso e uso. Compatível com os principais navegadores do mercado (Chrome, Edge, Firefox, Opera, Safari, dentre outros).

O console web é disponibilizado exclusivamente para acesso com HTTPS.

O console possui painéis (dashboards) para eventos.

Os dashboards podem ser filtrados por tempo ou por grupo de autenticação.

A console permite a pesquisa de eventos ou usuários por meio de filtros, podendo ainda visualizar detalhes do evento.

Requisitos técnicos​

Requisitos para o módulo Bastião​

Para o funcionamento adequado do GuardianKey Auth Bastion Enterprise, é necessário haver ao menos 1 (um) servidor dedicado para hospedar o módulo Bastião, podendo ainda ser um servidor virtual (VM), contendo as configurações abaixo, de acordo com a quantidade de usuários e requisições a serem atendidos:

Até 100.000 usuários e até 1000 requisições por segundo:

  • 8 núcleos de CPU
  • 32GB de memória RAM
  • 100GB de armazenamento usando tecnologia SSD e/ou de latência inferior a 3ms para gravação e no mínimo 1000 IOPS
  • Comunicação com a Internet
  • IP público roteável para acesso externo, caso seja necessário.

Acima desses limites é necessário cluster para processamento. Consultar nossa área de negócios.

Requisitos para o módulo Controlador e Console de administração​

Para o funcionamento adequado do GuardianKey Auth Bastion Enterprise, é necessário haver ao menos 1 (um) servidor dedicado para hospedar os módulos Controlador e Console de administração, podendo ainda ser um servidor virtual (VM), contendo as configurações abaixo, de acordo com a quantidade de usuários a serem atendidos:

Até 100.000 usuários e até 1000 eventos por segundo:

  • 12 núcleos de CPU
  • 128GB de memória RAM
  • 250GB de armazenamento usando tecnologia SSD e/ou de latência inferior a 3ms para gravação e no mínimo 1000 IOPS
  • Comunicação com a Internet
  • IP público roteável para acesso externo, caso seja necessário.

Acima desses limites é necessário cluster para processamento. Consultar nossa área de negócios.