Configurar e testar um servidor RADIUS no Sophos Firewall

O RADIUS liga o Sophos Firewall ao Microsoft NPS, a um gateway de MFA ou a outro serviço central de autenticação. Primeiro, prepare o sistema remoto e o caminho de rede. Em seguida, crie o servidor em Authentication > Servers e associe-o em Authentication > Services apenas aos serviços de login necessários. A validação deve ser feita com um login real, incluindo a verificação do utilizador, do grupo e das regras.

Para consultas tradicionais de utilizadores e grupos num domínio Windows, a ligação direta do Active Directory ao Sophos Firewall é muitas vezes adequada. Em cenários modernos de acesso remoto, o SSO do Microsoft Entra ID para Sophos Connect e VPN Portal pode ser a arquitetura mais apropriada. Se o objetivo for a firewall reconhecer utilizadores de WLAN já autenticados através de pacotes de accounting recebidos, aplica-se outro procedimento: Configurar RADIUS SSO com accounting no Sophos Firewall.

Quando faz sentido utilizar RADIUS

A firewall envia o nome de utilizador e as credenciais ao servidor RADIUS. Nesse servidor, a origem dos utilizadores, a Network Policy e, se aplicável, o MFA determinam se a resposta será Access-Accept ou Access-Reject. Só depois disso é que o grupo local de utilizadores, a política de VPN e as regras de firewall determinam que recursos ficam acessíveis.

No modelo RADIUS, os dados de autenticação e autorização são armazenados em perfis de utilizador. A autorização de um serviço exige que o pedido corresponda aos atributos previstos, por exemplo ao endereço IP do cliente RADIUS que envia o pedido. O Shared Secret protege as palavras-passe dos utilizadores; isso não implica a encriptação de todo o transporte RADIUS.

Os casos de utilização mais comuns incluem:

• Remote Access VPN com Microsoft NPS ou um serviço de MFA;
• autenticação centralizada no User Portal, VPN Portal ou Captive Portal;
• uma solução de transição quando não se pretende ligar o AD ou LDAP diretamente à firewall;
• vários dispositivos de rede que utilizam o mesmo serviço RADIUS.

Uma WLAN Enterprise gerida pela firewall utiliza também a seleção de servidores em Wireless > Wireless settings. Por isso, o procedimento 802.1X completo está descrito em Configurar uma WLAN diretamente no Sophos Firewall.

Numa WLAN Enterprise gerida pelo SFOS, Accounting Request e Accounting Response contêm informações de sessão e de accounting. São distintos dos pedidos, respostas e challenges de acesso utilizados no login. Para este caminho Wireless, a Sophos documenta suporte de accounting em todos os dispositivos com capacidade Wi-Fi; o Wireless Network tem de utilizar 802.1X e o accounting tem de estar ativado no servidor RADIUS. O guia de WLAN associado explica as portas separadas e a ausência de Interim Accounting Updates. O suporte de accounting não constitui uma garantia de suporte para um servidor RADIUS secundário.

Registar o estado inicial e o procedimento de reversão

Antes de alterar um serviço em produção, registe em Authentication > Services, para cada secção afetada:

• os servidores selecionados e a respetiva ordem;
• o estado de Set authentication methods same as firewall, Same as VPN ou Same as firewall;
• a Default group utilizada até então na autenticação da firewall;
• um utilizador para o qual o método atual funcione comprovadamente.

Durante a alteração dos logins de administrador, mantenha aberta uma sessão WebAdmin existente. Além disso, valide um superadministrador local através de um caminho de gestão já permitido. A seleção de servidores para administradores não se aplica a esse superadministrador; ainda assim, nunca altere um login de administrador externo sem confirmar primeiro uma alternativa local de acesso.

Planear a ligação RADIUS

Funções, caminho de rede e protocolos

Num ambiente NPS, o Sophos Firewall é o cliente RADIUS e o NPS é o servidor RADIUS. O NPS valida o pedido com base na Connection Request Policy e na Network Policy e, normalmente, também no Active Directory. Uma política de VPN ou regra de firewall subsequente continua a determinar o acesso efetivo.

A ajuda geral do SFOS 22 descreve a comunicação entre a firewall e o servidor RADIUS com PAP. No entanto, em Authentication > Services, a Sophos apresenta PAP, CHAP e MSCHAPv2 para ligações L2TP e PPTP. Esta matriz de protocolos não comprova que os mesmos métodos sejam utilizados para IPsec ou outros caminhos de login. Por isso, verifique em conjunto o serviço, o cliente e o método permitido no servidor RADIUS.

O RADIUS tradicional utiliza UDP e o ecrã documentado do SFOS não inclui campos de TLS ou certificados. Por isso, o tráfego deve percorrer um caminho interno controlado ou protegido de outra forma. Um Shared secret robusto não substitui a segmentação nem uma autorização restrita entre a firewall e o servidor RADIUS.

Sistemas mais antigos podem utilizar portas diferentes, como 1645/UDP e 1646/UDP. O que importa são as portas efetivamente configuradas em ambos os lados, e não estes valores históricos.

Escolher deliberadamente os valores de exemplo

Este guia utiliza:

• nome do servidor NPS-HQ-RADIUS;
• IP do servidor 10.20.30.15;
• porta de autenticação 1812;
• porta de accounting 1813;
• Time-out de 5 segundos;
• Domain name corp.example.

Substitua 10.20.30.15 e corp.example pelo endereço interno e pela convenção de nomes da sua organização. Cinco segundos são um valor inicial para uma validação direta da palavra-passe, não uma predefinição da Sophos. Em caso de push, chamada telefónica ou challenge externo, o valor deve ser compatível com o fornecedor e com o cliente real, dentro do intervalo de 1 a 60 segundos permitido pelo SFOS.

O Shared secret é o segredo técnico partilhado pelo cliente e pelo servidor RADIUS, não a palavra-passe de um utilizador. A Sophos limita-o a 48 caracteres. Partilhe o valor através de um canal separado e protegido, armazene-o de forma segura e introduza-o de forma exatamente igual em ambos os lados; o próprio RADIUS não envia o secret pela rede.

Criar o servidor RADIUS em Authentication

O caminho do menu é Authentication > Servers.

1. Abra Add e, em Server type, selecione RADIUS server.
2. Em Server name, introduza, por exemplo, NPS-HQ-RADIUS.
3. Em Server IP, introduza o endereço IP interno do servidor RADIUS; neste exemplo, 10.20.30.15.
4. Ajuste Authentication port à configuração do servidor, normalmente 1812.
5. Defina Time-out. Para o primeiro teste direto, este exemplo utiliza 5 segundos.
6. Ative Enable accounting apenas se o sistema remoto tiver de processar dados de accounting. Nesse caso, ajuste também Accounting port, normalmente 1813.
7. Introduza o Shared secret exatamente como está configurado no sistema remoto.
8. Opcionalmente, defina Domain name. Quando AD e RADIUS são utilizados em paralelo, um domínio uniforme evita que a mesma pessoa apareça como objetos de utilizador local diferentes. Com Domain name, é criada automaticamente, no primeiro login, uma entrada local no formato user@domainname. Sem este valor, o RADIUS cria um utilizador sem domínio, enquanto o AD cria uma entrada qualificada com o domínio; assim, podem surgir duas entradas locais para a mesma pessoa.
9. Preencha Group name attribute apenas se estiver comprovado que o sistema remoto devolve o atributo esperado. A ajuda da Sophos descreve-o como um alias para o nome de grupo configurado, mas não documenta aqui um mapeamento genérico de quaisquer atributos NPS para grupos locais.
10. Abra Enable additional settings apenas se existir uma política correspondente. NAS-identifier identifica o Network Access Server que envia o pedido, por exemplo através de um FQDN. NAS-port-type descreve o tipo de porta do login.
11. Execute Test connection com um utilizador-piloto próprio e, em seguida, selecione Save.

A firewall suporta, no máximo, 20 servidores de autenticação configurados no total. Também é possível selecionar, no máximo, 20 servidores por método de autenticação em Authentication > Services.

Limites da API do SFOS 22 e 23

Para automatização, leia as referências da API separadamente do procedimento do WebAdmin. As notas seguintes não constituem um pedido Add/Edit executável; confirmar os campos no build instalado.

• Exemplo XML e tabela de parâmetros: O exemplo coloca RADIUSServer dentro de AuthenticationServer. Utiliza ServerAddress, Port e DomainName; a tabela utiliza, em contrapartida, ServerIP, AuthenticationPort e domainName. Não considere estas grafias intercambiáveis com base numa normalização de etiquetas presumida.
• Accounting: O comentário do exemplo indica que se deve incluir AccountingPort para ativar o accounting; sem este parâmetro, fica desativado. Isto não comprova um comportamento testado quando um campo é omitido em Edit ou numa atualização parcial. 2222 é apenas o valor do exemplo XML, não a predefinição do WebAdmin 1813; não remova silenciosamente do XML gerado a porta de accounting prevista.
• Valores por esclarecer: Para IntegrationType, o exemplo apresenta LooseIntegration/TightIntegration, mas a tabela indica Only '1' are allowed.; para ServerType, indica Only '4' are allowed.. Não deduza daí um mapeamento de enumerações nem valores válidos para o pedido. Para alterações, o procedimento do WebAdmin acima continua a ser o caminho seguro enquanto não for esclarecida a sintaxe da API para a versão utilizada.
• Limites de entrada da API: ServerName é uma cadeia de, no máximo, 50 caracteres; UTF-8 é permitido, mas as vírgulas são proibidas. GroupNameAttribute e domainName são cadeias de, no máximo, 50 caracteres cada. AuthenticationPort é um inteiro de 1 a 65535, com um máximo de 5 algarismos e o valor predefinido documentado 1812. A tabela assinala ServerIP, AuthenticationPort, SharedSecret e GroupNameAttribute com Yes em Mandatory; a recomendação do WebAdmin acima sobre Group name attribute não torna o campo da API opcional. São limites da referência da API, não restrições da GUI recentemente confirmadas.
• Delete e identidade: Delete também documenta ServerName como identificador do servidor, com os mesmos limites de nome. Para a eliminação prevista, utilize o nome existente exato, não um nome novamente normalizado. Embora Add/Edit e Delete apresentem para ServerName a indicação Mandatory: No com a célula Default vazia, isto não comprova a eliminação sem nome, com caracteres universais ou em massa. Continuam a ser necessárias as verificações das associações de serviços e a reversão segura descritas mais abaixo.

Nota sobre a API do SFOS 23: A referência da API para adicionar e editar servidores RADIUS acrescenta o parâmetro opcional EmailAddressAttribute (cadeia de caracteres, máximo de 50 caracteres) e inclui-o no exemplo XML de RADIUSServer. Não é indicado nenhum valor predefinido. Esta nota diz respeito à documentação da API, não a um campo adicional do WebAdmin.

Respostas da API na migração do SFOS 22 para 23: Para as automatizações existentes, as classes de resposta documentadas mudam ao adicionar e editar servidores RADIUS. As referências da API apresentam os seguintes valores na coluna Status:

Por isso, deve verificar-se o tratamento das respostas separadamente para cada versão do SFOS e cada operação; uma lógica baseada exclusivamente nos valores de erro anteriores não é suficiente para o SFOS 23. Estes valores são valores de estado da API documentados, não uma prova de códigos de estado HTTP. As chaves JavaScript da coluna Message não comprovam qualquer texto de resposta específico em tempo de execução. As tabelas não fornecem nem uma correspondência inequívoca entre cada erro antigo e um novo, nem uma regra para novas tentativas.

Interpretar corretamente o accounting

Com Enable accounting, para os tipos de cliente suportados, a firewall envia uma mensagem Accounting-Start no login e uma mensagem Accounting-Stop num logout normal. A Sophos indica os seguintes tipos: Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client e API client. Os pedidos de Start e Stop também contêm, respetivamente, a hora do login e do logout.

Quando a firewall é desligada ou reiniciada, não é enviada nenhuma mensagem Accounting-Stop. Se uma sessão ficar aberta no servidor RADIUS, verifique a hora do reinício em conjunto com os logs do RADIUS. Esta função de accounting de saída é diferente do RADIUS SSO Accounting de entrada, através do qual a firewall recebe informação sobre sessões externas.

Preparar o Microsoft NPS como sistema remoto

No NPS, o Sophos Firewall tem de estar configurado como cliente RADIUS. A verificação mínima na consola Network Policy Server é a seguinte:

1. Abra RADIUS Clients and Servers > RADIUS Clients.
2. Crie um New RADIUS Client com um Friendly name inequívoco, como Sophos-Firewall-HQ.
3. Em Address (IP or DNS), introduza o endereço a partir do qual o NPS recebe efetivamente o pedido.
4. Em Vendor, selecione normalmente RADIUS standard.
5. Introduza o mesmo Shared secret configurado na firewall.
6. Na Connection Request Policy e na Network Policy correspondentes, verifique as condições, a decisão de acesso e o método de autenticação permitido para o utilizador-piloto.
7. Prepare o Event Viewer e os logs de accounting do NPS para a validação.

Em clusters HA, ligações encaminhadas ou cenários com NAT, não deduza o endereço do cliente NPS apenas a partir da topologia. Um primeiro teste revela no NPS qual é o IP de origem que chega efetivamente. Se o pedido não chegar ou se o NPS não o conseguir validar, verifique primeiro o encaminhamento, a autorização UDP, o endereço do cliente RADIUS e o Shared secret. Por outro lado, um Access-Reject normal indica um problema relacionado com o utilizador, a política ou o método de autenticação.

Associar o RADIUS aos serviços corretos

Depois de guardar, o objeto de servidor ainda não está ativo para nenhum login. Em Authentication > Services, o SFOS 22 disponibiliza as seguintes secções:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

No User Portal, VPN Portal, VPN e para administradores, a seleção de servidores pode estar associada à autenticação da firewall. O SSL VPN disponibiliza Same as VPN e Same as firewall. Antes de efetuar uma alteração, verifique se a secção em causa utiliza uma lista própria ou uma lista associada.

Para um piloto limitado, adicione NPS-HQ-RADIUS apenas à secção necessária, coloque-o na posição prevista e selecione Apply. A firewall consulta vários servidores pela ordem apresentada. Se o mesmo utilizador já conseguir autenticar-se através de um servidor anterior, uma política RADIUS MFA posterior não será aplicada.

Captive Portal e Default Group

O Captive Portal não tem uma secção própria em Authentication > Services. Utiliza Firewall authentication methods. Além disso, a zona prevista tem de estar autorizada para Captive portal em Administration > Device access, e deve existir uma regra de firewall baseada no utilizador devidamente configurada. Um teste funcional oficial consiste em iniciar sessão em https://<firewall-ip>:8090.

A Default group em Firewall authentication methods é relevante para a segurança. Quando um utilizador externo inicia sessão pela primeira vez num serviço da firewall, é criado em Authentication > Users. Se não existir uma associação adequada a um grupo local, será utilizada a Default Group configurada. Antes do piloto, verifique as políticas desse grupo e todas as regras em que é utilizado; uma Default Group com privilégios excessivos não pode tornar-se inadvertidamente a opção de fallback.

Distinguir a MFA com challenge por serviço

Segundo a ajuda do SFOS 22, o VPN Portal não suporta autenticação RADIUS com MFA baseada em challenge. Por isso, um Test connection bem-sucedido não comprova o funcionamento deste caminho do portal. Push, chamada, OTP e challenge também não são equivalentes: teste separadamente cada cliente e serviço previsto. Para a MFA local do Sophos Firewall, siga o procedimento específico em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Remote Access.

Validar a configuração

1. Ligação e sistema remoto

Em Authentication > Servers, abra NPS-HQ-RADIUS e execute Test connection com o utilizador-piloto. Ao mesmo tempo, verifique no NPS ou nos logs do outro sistema remoto se:

• o pedido provém do endereço esperado da firewall;
• é processado pela política correta;
• o resultado é Access-Accept;
• os atributos de resposta esperados estão presentes.

O teste confirma as credenciais e a comunicação com o servidor. Não confirma a ordem dos serviços, a política de VPN, o grupo local nem a regra de firewall.

2. Testar o serviço real

Em seguida, inicie sessão com o mesmo utilizador através do serviço efetivamente previsto. Captive Portal, SSL VPN, IPsec, User Portal e WebAdmin têm requisitos diferentes. No WebAdmin, o utilizador externo tem também de receber o perfil de administrador previsto; uma autenticação RADIUS bem-sucedida, por si só, não concede privilégios de administrador. Os caminhos desnecessários devem permanecer inalterados. Para SSL VPN, Configurar o Sophos Firewall SSL VPN Remote Access descreve a política, o Device Access e a regra de firewall.

Após um login bem-sucedido, verifique:

1. Em Authentication > Users, o utilizador local, o domínio e a Main Group efetivamente atribuída.
2. Em Current activities > Live users, a sessão ativa; se necessário, pode terminá-la com Disconnect.
3. No Log viewer, no canto superior direito do WebAdmin, abra o módulo Authentication e filtre por utilizador, IP de origem e um intervalo de teste curto.
4. No log de tráfego, confirme a Firewall Rule ID efetivamente utilizada e verifique que apenas o recurso de destino autorizado está acessível.
5. Teste o caso negativo com um utilizador que não pertença à política NPS autorizada.

Se o login funcionar, mas a aplicação continuar inacessível, verifique a zona, o pool de IP da VPN, o grupo, a posição da regra, o NAT e o encaminhamento. Regra do Sophos Firewall não é aplicada: verificar as causas descreve este caminho de dados. Se a identidade, a seleção do serviço ou a Main Group já não estiverem claras, consulte Resolver sistematicamente erros de autenticação no Sophos Firewall.

Identificar erros com base no comportamento observado

O sistema remoto não recebe nenhum pedido

Comece por verificar os valores configurados em Server IP e Authentication port. Em seguida, verifique o encaminhamento e a autorização de UDP 1812 entre o endereço de origem utilizado pela firewall e 10.20.30.15. Um objeto de servidor RADIUS não cria automaticamente uma regra de firewall de trânsito.

Para uma rede sem fios gerida pelo SFOS, a Sophos documenta um caso especial estritamente limitado: se o servidor RADIUS estiver ligado à firewall através de um túnel IPsec, é necessário um mapeamento de Source NAT para as redes dos pontos de acesso. Este mapeamento traduz o IP de origem precisamente para o endereço IP da firewall através do qual esta alcança o servidor RADIUS. Para isso, a ajuda de Wireless remete para uma configuração através da shell com sys-traffic-nat; no entanto, não fornece aqui um comando completo e executável. Antes de qualquer alteração, é necessário comprovar as redes dos pontos de acesso, o endereço de origem efetivamente utilizado, o endereço da firewall para a tradução de origem, o túnel, o caminho de retorno e os logs do RADIUS. Sem sintaxe confirmada para esse fim, a configuração concreta na shell, incluindo a verificação e a reversão, deve ser objeto de escalonamento técnico específico. Para outros caminhos RADIUS, este guia de Wireless não comprova uma necessidade geral de NAT. Uma regra LAN-to-VPN ou um exemplo de Forwarding-IPsec-Route não substitui este procedimento de tráfego do sistema.

NAT do tráfego do sistema para um caminho Wireless-IPsec confirmado

A ajuda CLI separada do SFOS 22 e 23 documenta a sintaxe abaixo. Confirmar o modelo no build instalado antes de construir o pedido. Complementa o caso especial Wireless descrito acima; não substitui a verificação das redes dos AP nem o planeamento do túnel e do caminho de retorno.

⚠️ Antes da alteração: Uma alteração de NAT pode interromper a autenticação e outros serviços do sistema para o mesmo destino. Prepare uma cópia de segurança, uma janela de manutenção e um acesso administrativo independente. O destino RADIUS, o IP de origem observado, o IP da firewall necessário, os seletores IPsec ou a rota, o caminho de retorno e o endereço do cliente NPS têm de ser coerentes. Se este caminho não estiver confirmado, continua a ser necessário um escalonamento técnico.

Inicie sessão na Command-line console com privilégios administrativos e selecione 4 – Device Console, não Advanced Shell. Primeiro, registe a configuração existente com este comando apenas de leitura:

show advanced-firewall

O exemplo IPv4 abaixo só se aplica se 10.20.30.15 for o servidor RADIUS e 10.40.50.1 for exatamente o IP da firewall previsto para este caminho. Substitua ambos os endereços. 255.255.255.255 limita o destino a um host; uma máscara mais abrangente inclui outros destinos. O comando não tem filtro de rede de origem nem de porta: não seleciona apenas uma rede de AP ou UDP 1812. Sem interface, o mapeamento aplica-se ao tráfego para este destino através de qualquer interface da firewall. Um parâmetro interface <interface> verificado pode limitar o âmbito; não adivinhe o nome da interface. Não substitua nem elimine mapeamentos existentes ou sobrepostos sem os verificar.

Adicione o mapeamento apenas se estes efeitos tiverem sido expressamente autorizados e ainda não existir um mapeamento adequado:

set advanced-firewall sys-traffic-nat add destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Em seguida, utilize um cliente Wi-Fi real de teste para verificar 802.1X, Accounting-Start e um logout normal com Accounting-Stop. Os logs RADIUS têm de mostrar o IP de origem esperado da firewall, a decisão Access-Accept e o accounting recebido; verifique também o túnel, o caminho de resposta e os outros serviços para o mesmo destino. A apresentação do mapeamento NAT, por si só, não comprova que o login funciona. Se houver diferenças, não amplie as regras de acesso.

Para reverter apenas o mapeamento de exemplo recém-adicionado, utilize os mesmos valores adaptados com delete; se tiver acrescentado interface, mantenha o mesmo parâmetro ao eliminar:

set advanced-firewall sys-traffic-nat delete destination 10.20.30.15 netmask 255.255.255.255 snatip 10.40.50.1
show advanced-firewall

Compare com o estado inicial registado e volte a testar a autenticação original e os serviços do sistema afetados. Um erro de consola ou uma entrada pouco clara exige parar, não efetuar uma reposição geral.

O NPS responde com Access-Reject

Um Access-Reject demonstra que o caminho de rede e a porta funcionam, em princípio. Verifique agora no NPS o Reason Code, a Network Policy correspondente, o estado do utilizador e o método de autenticação permitido. Em contrapartida, um Shared secret incorreto está associado a respostas ausentes, inválidas ou impossíveis de verificar.

Test connection funciona, mas o login no serviço não

Em Authentication > Services, verifique a secção correta, as opções de associação, a ordem dos servidores e Apply. Para o Captive Portal, verifique também Device access e a regra de firewall baseada no utilizador. Para SSL VPN, devem estar corretos o Policy Member, o acesso SSL VPN em Device Access e a regra de firewall necessária.

O login funciona, mas é aplicado o grupo errado

Em Authentication > Users, verifique o domínio e a Main Group. Depois, compare Group name attribute, os atributos de resposta do sistema remoto e a Default group. Uma autenticação bem-sucedida não comprova que a autorização esperada foi aplicada. Por isso, é necessário demonstrar que o utilizador de teste negativo é rejeitado pela condição de grupo ou do NPS.

O push ou challenge termina por timeout

Utilize o cliente real e compare os horários nos logs da firewall, do NPS e do fornecedor de MFA. Aumente o timeout do SFOS apenas dentro do intervalo de 1 a 60 segundos e escolha o menor valor que abranja de forma fiável o fluxo normal de challenge. No VPN Portal, não é possível corrigir a MFA RADIUS baseada em challenge aumentando o timeout, porque este caminho não é suportado pela Sophos.

Reverter a configuração com segurança

Se o piloto falhar, restaure na secção afetada de Authentication > Services a lista de servidores anteriormente registada, incluindo a respetiva ordem, bem como as opções de associação e a Default group. Depois, selecione Apply. Em seguida, autentique o utilizador de referência através do método original e verifique o superadministrador local.

Só depois de todos os serviços afetados voltarem a funcionar deve remover NPS-HQ-RADIUS das restantes associações de serviços. Elimine o objeto de servidor em Authentication > Servers apenas se já não estiver prevista qualquer utilização. No NPS, reponha o cliente, a política e o Shared secret no estado inicial documentado. Os objetos de utilizador local já criados devem ser verificados separadamente; a sua remoção não termina automaticamente todas as sessões existentes. Por isso, verifique também Current activities > Live users.

Operação

O RADIUS é um serviço de identidade de produção. Após alterações no NPS, no fornecedor de MFA, no AD ou na ordem dos serviços, a validação deve incluir um login real positivo e outro negativo. O Shared secret deve ser documentado de forma protegida e alterado segundo um plano de rotação. Configure a monitorização do sistema remoto e defina o período de retenção dos respetivos logs de decisão. Assim, será possível determinar se uma falha ocorreu antes da firewall, durante a autenticação ou apenas na fase de autorização.

FAQ