Configurar a autenticação multifator¶
A autenticação multifator (MFA) pede ao utilizador uma segunda prova, além do seu identificador e da sua palavra-passe. CyberElements propõe várias formas de a obter. Esta página cobre quatro delas, pela ordem em que são habitualmente consideradas, e detalha em seguida aquela que não tem página de integração própria: a palavra-passe de utilização única enviada por correio eletrónico.
Quatro fatores, e não o quadro completo
Estes quatro são os que esta página percorre — não são os únicos segundos fatores que a plataforma pode pedir. Também estão disponíveis, e fora do âmbito desta página:
- um OTP enviado por SMS, através de um dos muitos operadores propostos pelo módulo OTP Token Generators;
- um conector Radius para uma solução de MFA de terceiros, através do tipo OTP - Radius desse mesmo módulo;
- a autenticação por certificado x509, que não é um token mas um método de autenticação do próprio domínio — User certificate, ou User certificate and form para manter também a palavra-passe;
- uma MFA imposta a montante por um fornecedor SAML, ou por qualquer outra autenticação delegada. O segundo fator é então pedido antes de a plataforma intervir, e esta não o configura nem o vê.
A MFA define-se no fornecedor de identidade, nunca num utilizador
Qualquer que seja o fator escolhido, é ativado num fornecedor de identidade e aplica-se a todos os utilizadores que iniciam sessão através dele. Não existe definição por utilizador: para sujeitar apenas parte da sua população à MFA, coloque esses utilizadores atrás de um fornecedor de identidade dedicado.
Escolher um fator¶
| Fator | O que o utilizador faz | O que exige | Procedimento |
|---|---|---|---|
| Neomia Pulse | Nada. O utilizador é reconhecido pela forma como escreve no teclado. | A opção Neomia Pulse, um fornecedor de identidade de tipo local ou LDAP, e um segundo fator desta tabela no mesmo fornecedor. |
Integração do Neomia Pulse |
| FIDO2 | Apresenta o seu autenticador — ligando uma chave de segurança, ou aprovando no dispositivo ou no cofre que guarda a passkey — e introduz depois um PIN se o autenticador o pedir. | Um autenticador FIDO2 por utilizador, uma relying party declarada na consola e uma conta pessoal — um fornecedor de identidade anónimo está excluído. | Integração da Yubico |
| TOTP | Lê um código de seis dígitos numa aplicação de autenticação. | Uma aplicação no telemóvel ou no posto de trabalho do utilizador (Google Authenticator, FreeOTP, Microsoft Authenticator, etc.) e um registo por utilizador. | Integração do Google Authenticator |
| OTP por correio eletrónico | Copia um código recebido por correio eletrónico. | Um servidor SMTP acessível pela plataforma e um endereço de correio eletrónico guardado num atributo do utilizador. | Configurar um OTP por correio eletrónico |
O Neomia Pulse configura-se por cima de outro fator
Ativar o Neomia Pulse exige que outra MFA esteja ativada no mesmo domínio. As suas definições decidem então para que serve esse outro fator: pode ser ignorado quando o Pulse valida o utilizador e exigido quando o Pulse não o valida. O Neomia Pulse é, por isso, uma forma de poupar o segundo fator, mais do que de o substituir.
Onde se declara cada fator e onde se ativa¶
A configuração tem duas fases possíveis — declarar o fator no seu próprio módulo, depois ativá-lo no fornecedor de identidade — mas dois dos quatro saltam uma delas:
| Fator | Declarado em | Ativado no fornecedor de identidade |
|---|---|---|
| Neomia Pulse | nada a declarar | ✅ a opção Enable neomia Pulse authentication |
| FIDO2 | Relying parties | ❌ nada a ativar — ver a nota abaixo |
| TOTP | OTP Token Generators | ✅ como token de autenticação |
| OTP por correio eletrónico | um servidor SMTP, depois OTP Token Generators | ✅ como token de autenticação |
O FIDO2 não tem interruptor no fornecedor de identidade
As chaves de segurança não são ativadas fornecedor a fornecedor: a plataforma propõe o fator assim que pelo menos uma relying party estiver declarada, em todos os fornecedores de identidade que não sejam anónimos — uma chave tem de estar associada a uma conta pessoal. E é o utilizador que regista o seu autenticador a partir do portal, não o administrador que lho atribui.
O Neomia Pulse não tem nada a declarar previamente
O Pulse não é um token a criar num módulo: a opção é ativada diretamente no fornecedor de identidade, que é também onde se define o seu comportamento.
O resto desta página cobre o OTP por correio eletrónico de ponta a ponta. Os outros três fatores estão cobertos pela respetiva página de integração, ligada na tabela acima.
Configurar um OTP por correio eletrónico¶
Um OTP por correio eletrónico envia ao utilizador um código de utilização única por correio eletrónico depois de o seu identificador e a sua palavra-passe terem sido aceites. O utilizador introduz esse código no portal para concluir o início de sessão.
Antes de começar: o que um OTP por correio eletrónico protege realmente¶
Um OTP por correio eletrónico nem sempre acrescenta um fator
Leia isto antes de escolher este fator em vez dos outros três.
Se o utilizador iniciar sessão com a sua conta Active Directory e obtiver o código numa caixa de correio associada a essa mesma conta, o segundo fator quase nada acrescenta: um atacante que tenha obtido as credenciais abre a caixa de correio com essas mesmas credenciais e lê o código.
Vale a pena implementar um OTP por correio eletrónico quando a caixa de correio não é acessível com as credenciais que estão a ser verificadas, ou seja, quando:
- o utilizador inicia sessão com uma conta local, ou com uma conta distinta da da sua caixa de correio;
- o código é enviado para um endereço diferente daquele que pertence à conta de início de sessão.
Passo 1 — Dispor de um servidor SMTP¶
O código é enviado pela plataforma através de um servidor SMTP declarado no módulo SMTP servers. Se ainda não houver nenhum disponível, declare um antes de prosseguir:
Configurar o envio de correio eletrónico
Utilize em seguida o bloco SMTP configuration test desse módulo para confirmar a entrega: uma falha diagnosticada nesta fase é uma falha que não terá de procurar mais tarde no fluxo de início de sessão.
A mensagem de teste não utiliza o remetente que vai configurar
O teste envia a partir de noreply@cleanroom.com, um endereço escrito no produto: não pode ser alterado em lado nenhum e serve também de endereço de resposta. O seu próprio remetente é o SMTP sender do token, definido no passo 2 — é esse que as mensagens OTP reais transportam.
Vale a pena conhecer a consequência antes de concluir: um servidor SMTP que restrinja os endereços de envio pode recusar o teste deixando passar as mensagens reais, e ao contrário.
A ligação é aberta pela plataforma
O fluxo para o servidor SMTP parte da plataforma, não do posto de trabalho do utilizador. Se o seu servidor SMTP estiver na sua LAN, esse fluxo tem de ser autorizado.
Passo 2 — Criar o token OTP¶
Abra o módulo OTP Token Generators e clique em +. Na janela Add OTP token, selecione o tipo OTP - email e preencha os campos.
| Campo | O que introduzir |
|---|---|
| OTP Type | OTP - email. Esta escolha não pode ser alterada posteriormente — um canal diferente significa um token diferente. |
| Name | O nome do token. É apresentado ao utilizador no portal, pelo que deve ler-se como um nome de fator e não como uma referência interna. |
| Description | Texto livre, visível apenas para os administradores. |
| OTP usable characters | O alfabeto a partir do qual o código é gerado. |
| OTP Length | O número de caracteres do código. |
| Validity period of a token (seconds) | Quanto tempo o utilizador tem para introduzir o código antes de este ser recusado. |
| Message before the OTP | A frase que precede o código no corpo da mensagem. |
| Mail subject | O assunto da mensagem. |
| SMTP sender | O endereço de remetente da mensagem. |
| SMTP server | O servidor declarado no passo 1. |
A lista completa dos campos, com os seus valores predefinidos e as suas restrições, está na página de referência: Bloco genérico e Envio por correio eletrónico.
Clique em Validate para guardar o token.
Passo 3 — Ativar o token num fornecedor de identidade¶
Abra o módulo Identity Providers e edite o fornecedor que deve pedir o OTP.
| Campo | O que introduzir |
|---|---|
| Authentication token | O token criado no passo 2. Podem ser selecionados vários tokens. |
| User attribute used to send the OTP | O nome do atributo do utilizador que contém o endereço para onde o código é enviado. |
| Token expiration duration | Quanto tempo um OTP validado permanece aceite antes de ser pedido novamente. 0 desativa a expiração, o que significa que o OTP é pedido em cada início de sessão. |
| Time unit | Hours ou Days, aplicado ao campo anterior. |
| Expiration starts | Se a contagem começa na última validação do OTP ou no último início de sessão bem-sucedido. |
Que atributo contém o endereço
O atributo é o do diretório para o qual o fornecedor de identidade aponta, e não um nome à nossa escolha: utilize o atributo em que os seus utilizadores têm efetivamente um endereço. Num diretório local, o endereço introduzido nas propriedades do utilizador é o que deve visar; num diretório LDAP, é o próprio atributo mail do diretório.
Clique em Validate. Os utilizadores desse fornecedor de identidade passam a ter de indicar um código no próximo início de sessão.
Passo 4 — Verificar primeiro num fornecedor de identidade de teste¶
Ativar a MFA num fornecedor de identidade aplica-a a todos os utilizadores que estão atrás dele, incluindo a si próprio se iniciar sessão através dele. Antes de ativar o token no seu fornecedor de produção, crie um fornecedor de identidade de teste com uma única conta e faça um início de sessão completo através dele: identificador, palavra-passe, receção da mensagem, introdução do código.
Um utilizador sem endereço nunca recebe um código
A um utilizador cujo atributo esteja vazio não pode ser enviado nada, e o seu início de sessão não pode ser concluído. Verifique se o atributo está preenchido em todas as contas que estão atrás do fornecedor de identidade antes de ativar o token nele.