Configurer les administrateurs et profils Sophos Firewall en toute sécurité

Pour l’administration quotidienne, chaque personne devrait disposer de son propre compte. Il faut d’abord créer un profil Device Access adapté, puis ajouter sous Authentication > Users un utilisateur local avec User type: Administrator. Le profil détermine ce que l’administrateur peut consulter ou modifier. La MFA, les sources de connexion et Device Access protègent également l’authentification et l’accessibilité de WebAdmin.

L’administrateur par défaut admin reste un accès de secours testé et ne sert pas de compte quotidien partagé. Les changements restent ainsi attribuables à une personne et une erreur dans un profil restreint ne bloque pas la dernière voie de récupération.

Configurer un administrateur local en huit étapes

1. Vérifier la sauvegarde, l’administrateur par défaut et l’accès de récupération. Conserver une session administrateur existante jusqu’à la réussite du test.
2. Documenter la mission et les droits nécessaires, par exemple uniquement le diagnostic ou également la modification d’objets réseau.
3. Créer un profil personnalisé sous Profiles > Device access > Add et laisser sur None les domaines inutiles.
4. Sous Authentication > Users > Add, saisir un nom d’utilisateur personnel et définir User type sur Administrator.
5. Attribuer le nouveau profil, un mot de passe personnel robuste et l’adresse e-mail professionnelle.
6. Sous Administrator advanced settings, limiter si nécessaire Schedule for device access et Login restriction for device access.
7. Vérifier que Local reste disponible sous Authentication > Services > Administrator authentication methods. Configurer ensuite la MFA et l’accès WebAdmin depuis le réseau de gestion.
8. Effectuer un test positif et négatif du compte dans une fenêtre de navigation privée. Ne migrer d’autres comptes ou désactiver d’anciens accès qu’après cette validation.

⚠️ Un nouveau profil ne doit pas être utilisé en production avant qu’un deuxième administrateur fonctionnel et une voie de récupération documentée soient disponibles. Le profil intégré Administrator donne un accès complet et doit être réservé au groupe le plus restreint possible.

Distinguer les cinq niveaux de protection

Plusieurs paramètres agissent ensemble pour les accès administrateur. Ils répondent à des objectifs différents et ne se remplacent pas mutuellement :

• Compte utilisateur : Identifie la personne. Les comptes personnels rendent les changements traçables ; les comptes d’équipe comme firewalladmin masquent cette attribution.
• Profil Device Access : Définit avec None, Read-only et Read-write quels menus et fonctions sont visibles ou modifiables. Les droits s’appliquent aussi à l’API.
• Schedule et Login Restriction : Limitent les horaires et les adresses IPv4 depuis lesquelles ce compte administrateur précis peut utiliser WebAdmin.
• Device Access et Local Service ACL : Définissent les zones et sources depuis lesquelles WebAdmin est accessible. Configurer Device Access et Local Service ACL en toute sécurité explique la mise en œuvre.
• MFA et Audit Trail : La MFA ajoute une protection au mot de passe. Audit Trail aide à attribuer les changements pris en charge à une identité, une source et une console. Pour Data Anonymization dans les logs et les rapports, au moins deux authorizers personnels disposant de comptes distincts sont également préparés.

Un profil Read-only, par exemple, ne protège pas contre le vol du mot de passe. Inversement, la MFA n’empêche pas l’attaque d’une page de connexion inutilement exposée à Internet. Seule leur combinaison réduit à la fois les droits et la surface d’attaque.

Les avertissements de connexion et les messages personnalisés ajoutent uniquement des informations visibles à ces couches. L’acceptation n’étend ni le profil Device Access ni l’autorisation réseau et ne remplace aucun des cinq contrôles.

Administrateur par défaut, comptes locaux et identités centrales

L’utilisateur par défaut admin possède les droits du profil intégré Administrator. Il convient comme accès de secours local, mais pas comme compte quotidien partagé. Son mot de passe, sa MFA, son accès console et sa procédure de récupération doivent être documentés et testés indépendamment des comptes personnels.

Les administrateurs locaux personnels conviennent aux petites équipes, aux firewalls isolés et à un accès de secours délibérément maintenu. Les équipes plus importantes peuvent gérer les rôles administrateur via Microsoft Entra ID SSO pour WebAdmin, TACACS+ avec attribution locale du profil ou les rôles d’administration Sophos Central. Un utilisateur marqué Managed by Central sous Authentication > Users est géré dans Central et ne peut pas être modifié localement.

Les automatisations ne reçoivent pas un compte personnel quotidien. L’API XML utilise un compte de service distinct, avec son propre responsable, des droits limités et une source autorisée fixe. Sécuriser l’accès à l’API XML de Sophos Firewall présente l’ensemble du dispositif de protection.

Planifier le profil Device Access

Sophos fournit plusieurs profils standard non modifiables sous Profiles > Device access :

• Administrator : Accès complet à WebAdmin et à l’API. Sophos décrit également ce profil avec un accès CLI complet ; toutefois, la connexion SSH directe dans SFOS n’accepte que le nom d’utilisateur par défaut admin.
• Audit admin : Accès en lecture et écriture aux logs et rapports.
• Crypto admin : Accès en lecture et écriture aux certificats de sécurité.
• HAProfile : Accès Read-only à l’Auxiliary Appliance d’un cluster HA.
• Security admin : Accès en écriture aux fonctions, à l’exception des profils, logs et rapports.

Ces profils constituent des points de départ pratiques, mais ne sont pas automatiquement adaptés à chaque environnement. Un profil personnalisé est préférable lorsqu’une personne n’a besoin que d’un domaine de responsabilité clairement limité.

Déduire les droits de la mission

Le nom du profil n’a aucun effet technique en lui-même. Un profil nommé ReadOnly peut encore contenir des droits d’écriture. Seule compte la matrice complète des autorisations, y compris les sous-menus déployés.

Un compte Help Desk peut, par exemple, être planifié ainsi :

• Définir le diagnostic, les logs et les domaines de configuration nécessaires au support sur Read-only.
• N’accorder Read-write que si l’équipe doit réaliser elle-même une modification précisément définie.
• Laisser sur None les profils administrateur, les certificats et tous les domaines de produit inutiles.
• Pour chaque droit d’écriture, définir un exemple de ce qui doit être autorisé et un exemple de ce qui doit rester explicitement interdit.

Un profil d’exploitation réseau peut disposer d’un accès en lecture plus large et modifier certains domaines réseau. Il n’a malgré tout pas besoin d’un accès complet aux administrateurs, aux certificats ou à d’autres fonctions de sécurité indépendantes. Le moindre privilège ne consiste pas à afficher le moins de menus possible, mais à attribuer exactement les droits nécessaires à la mission confiée.

Créer un profil personnalisé

1. Ouvrir Profiles > Device access.
2. Sélectionner Add.
3. Saisir un nom explicite, par exemple SFOS-NOC-Limited.
4. Choisir None, Read-only ou Read-write pour chaque menu visible.
5. Utiliser Expand pour ouvrir les sous-menus et limiter plus précisément les droits différents.
6. Enregistrer avec Save.
7. Vérifier de nouveau le profil par rapport aux tâches et aux tests négatifs documentés.

SFOS-NOC-Limited n’est qu’un exemple de nom. Il doit être adapté à l’équipe et à la mission. Les droits réellement attribués doivent également être documentés, car le nom n’explique pas la matrice des autorisations.

Créer un administrateur local personnel

Saisir l’utilisateur

1. Ouvrir Authentication > Users.
2. Sélectionner Add.
3. Sous Username, saisir un identifiant personnel durable, par exemple m.mueller. Le nom d’utilisateur ne peut pas être modifié ultérieurement.
4. Saisir un nom d’affichage explicite et l’adresse e-mail professionnelle.
5. Définir User type sur Administrator.
6. Sous Profile, sélectionner le profil SFOS-NOC-Limited précédemment vérifié.
7. Définir un mot de passe long et unique, puis le transmettre de manière sécurisée. Si le firewall détecte un mot de passe fréquemment utilisé ou un mot du dictionnaire, il exige un mot de passe plus robuste.

m.mueller est un exemple qui doit être remplacé par l’identité unique de la personne responsable. Les noms fonctionnels tels que noc-admin ne devraient être utilisés que s’ils correspondent réellement à une seule identité technique avec son propre responsable. Plusieurs personnes ne doivent pas partager un mot de passe.

Limiter les horaires et la source de connexion

Deux contrôles supplémentaires sont disponibles sous Administrator advanced settings :

• Schedule for device access : Autorise les connexions à WebAdmin uniquement pendant l’horaire sélectionné. Cette option convient au support temporaire ou à des heures d’exploitation définies. Pour une astreinte, l’horaire ne doit pas bloquer involontairement une intervention d’urgence nécessaire.
• Login restriction for device access : Autorise la connexion à WebAdmin uniquement depuis des adresses IPv4 sélectionnées ou une plage IPv4. Pour un jump host administrateur, 10.20.30.25 peut par exemple être utilisé comme Selected node.

L’adresse 10.20.30.25 est un exemple issu d’un réseau privé. Elle doit être remplacée par l’adresse fixe du jump host ou du poste de gestion concerné. Lorsque les adresses client changent, un VPN administrateur ou un réseau de gestion dédié est généralement plus propre qu’une large plage IP.

Access Time pour les utilisateurs et groupes ordinaires contrôle l’accès Internet ; pour WebAdmin, le paramètre Schedule for device access sous Administrator advanced settings est déterminant. Il ne s’agit pas du même réglage.

Conserver l’authentification locale

Sous Authentication > Services > Administrator authentication methods, la base de données locale doit être sélectionnée pour les administrateurs locaux personnels. Le super-administrateur par défaut admin est exclu de cette liste de méthodes, mais les nouveaux administrateurs locaux ne le sont pas.

La méthode locale ne doit pas être supprimée avant que le nouveau compte ait été testé avec succès dans un navigateur distinct. Avec des serveurs d’authentification externes, l’ordre détermine la destination initiale d’une tentative de connexion. Toute modification de cet ordre doit donc figurer dans le même plan de validation et de retour arrière que le compte lui-même.

Sécuriser la MFA et l’accessibilité

La MFA devrait être activée pour les administrateurs interactifs. Les administrateurs personnels sont ajoutés sous Authentication > Multi-factor authentication pour Web admin console. L’utilisateur par défaut admin dispose d’un réglage séparé sous Administration > Device access > MFA for default admin. Activer la MFA pour WebAdmin de Sophos Firewall explique le groupe pilote, l’enregistrement des tokens, Login Security et la récupération. La MFA doit d’abord être testée avec un seul nouvel administrateur, pas avec tous les comptes simultanément.

WebAdmin reste en outre limité aux réseaux de gestion, au VPN ou à des sources précisément définies. Une Login restriction for device access active ne sécurise pas une large autorisation WAN. Inversement, une Local Service ACL ne remplace ni le compte personnel ni son profil de droits.

Un test WebAdmin réussi n’autorise pas SSH. SFOS n’accepte que le nom d’utilisateur admin pour la connexion SSH directe ; un administrateur WebAdmin local personnel n’est donc pas testé comme compte SSH. SSH nécessite également sa propre décision Device Access. La gestion des clés publiques de l’administrateur par défaut et l’accès SSH sécurisé sont traités séparément dans Se connecter à Sophos Firewall par SSH.

Sous Administration > Admin and user settings, Administrator password complexity, le délai d’expiration de session et Block login complètent les paramètres du compte. Ces valeurs s’appliquent à l’ensemble du système et ne doivent donc pas être durcies de manière excessive pour un seul compte. Block login, en particulier, peut bloquer l’adresse IP source pour tous les services de connexion après des échecs ; une deuxième source de gestion ou l’accès console doit être disponible avant le test.

Tester les droits et la connexion en toute sécurité

Pendant le test, la fenêtre administrateur existante et une voie de récupération indépendante restent disponibles. Il ne faut pas provoquer plusieurs échecs de connexion volontaires, car Block login peut temporairement bloquer l’adresse IP source partagée pour d’autres services de connexion.

1. Ouvrir une fenêtre de navigation privée et accéder à WebAdmin via le FQDN prévu depuis le réseau de gestion autorisé.
2. Se connecter avec le nouveau compte et la MFA.
3. Vérifier que tous les menus nécessaires sont visibles et que les informations prévues peuvent être consultées.
4. Si le profil contient des droits d’écriture, effectuer une modification de test sans risque, approuvée au préalable, avec un retour arrière immédiat.
5. Ouvrir un domaine défini sur None ou Read-only. Le compte ne doit pas pouvoir y enregistrer une modification interdite.
6. Tester au maximum une fois une connexion contrôlée depuis une source non autorisée. Si le résultat n’est pas clair, analyser d’abord les paramètres et les logs plutôt que de générer d’autres échecs.
7. Vérifier la modification de test et l’administrateur utilisé dans Configuration Audit Trail. Tous les objets n’y produisent pas le même niveau de détail ; vérifier également l’effet technique dans la fonction concernée.
8. Se déconnecter, se reconnecter, puis seulement migrer le compte suivant.

Dans un cluster HA, une nouvelle connexion au nœud désormais actif est également testée après un basculement planifié. Une session WebAdmin existante ou sa poursuite transparente ne constitue pas un critère de réussite fiable.

Un menu visible ne prouve pas que le droit d’écriture fonctionne. Un menu masqué ne prouve pas que les autres fonctions attribuées sont correctes. Test positif, test négatif et attribution dans l’audit vont donc de pair.

Vérifier et supprimer les comptes en toute sécurité

Les accès administrateur sont régulièrement vérifiés en fonction du responsable, de la mission, du profil, de la MFA, de la source de connexion et de la dernière utilisation. Les comptes de support temporaires reçoivent également une date de fin documentée. Pour un cas Avanet limité dans le temps, la procédure dédiée Configurer l’accès support Avanet sur Sophos Firewall reste déterminante.

Pour l’offboarding, une procédure contrôlée est plus sûre qu’une suppression immédiate :

1. Vérifier si le compte est utilisé dans des scripts API, des coffres-forts de mots de passe, des documentations ou des processus de support.
2. Sous Authentication > Users, définir le statut sur inactif.
3. Vérifier dans une fenêtre de navigation privée qu’une nouvelle connexion n’est plus possible.
4. Examiner séparément les sessions WebAdmin actives et les changements récents. La désactivation ne doit pas être considérée comme la preuve que toutes les sessions existantes ont immédiatement pris fin.
5. Supprimer ou renouveler les tokens MFA, les secrets et les attributions externes liés au compte.
6. Après la période d’observation convenue, supprimer l’utilisateur s’il ne subsiste aucune dépendance.
7. Ne supprimer un profil personnalisé devenu inutile que lorsqu’il n’est plus attribué à aucun administrateur.

L’administrateur par défaut reste en dehors de ce processus d’offboarding normal. Si son mot de passe ou son accès MFA est perdu, Récupérer le mot de passe administrateur de Sophos Firewall aide à préparer la voie de récupération.

Identifier les problèmes courants

Le compte existe, mais la connexion WebAdmin échoue

Vérifier les points suivants dans l’ordre :

• User type est bien défini sur Administrator.
• Le statut de l’utilisateur est actif et le mot de passe est correct.
• Local est sélectionné sous Administrator authentication methods.
• Schedule for device access autorise l’heure actuelle.
• Login restriction for device access contient l’adresse IPv4 source réelle.
• Le token MFA, l’heure système et l’enregistrement sont corrects.
• Block login n’a pas bloqué l’adresse IP source après des échecs.
• Device Access ou une Local Service ACL autorise HTTPS depuis cette source.

Si la page de connexion est totalement inaccessible, l’analyse commence par Device Access, le routage et l’adresse source. Si elle est accessible, mais refuse uniquement ce compte, il faut d’abord examiner l’utilisateur, le profil, la méthode d’authentification, Schedule, Login Restriction et la MFA.

Pour la corrélation temporelle, la zone Authentication de Log Viewer et access_server.log couvrent l’authentification et l’autorisation. syslog.log ajoute des événements système et déclenchés par des administrateurs. Les modifications d’objets pris en charge sont vérifiées séparément dans configuration-audit.log.

Le compte voit trop ou pas assez

Vérifier le profil attribué et ses sous-menus déployés. Read-only et Read-write peuvent être configurés différemment au sein d’un menu principal. Recommencer ensuite le test avec une nouvelle connexion sans se fier uniquement au nom du profil.

Avec Managed by Central, le rôle provient de Sophos Central et ne peut pas être modifié localement dans la fiche utilisateur. Avec Entra SSO, l’association de rôle ou de groupe du serveur Entra détermine le profil Device Access local.

WebAdmin fonctionne, mais pas l’API ou SSH

Le profil Device Access s’applique aussi aux droits de l’API, mais celle-ci nécessite en plus un accès API activé et une source autorisée. SSH est un service local distinct et ne constitue pas un test de réussite adapté à un profil WebAdmin restreint. Un compte n’obtient pas un accès SSH uniquement parce que la connexion WebAdmin fonctionne.

Checklist d’exploitation

• L’administrateur par défaut et la voie de récupération sont testés et ne sont pas partagés.
• Chaque personne utilise son propre compte.
• Les profils sont déduits des missions et les sous-menus déployés ont été vérifiés.
• L’accès complet est limité au groupe le plus restreint nécessaire.
• La MFA, Schedule et la source de connexion correspondent à l’usage prévu.
• WebAdmin est accessible uniquement depuis les sources de gestion prévues.
• Des tests positifs et négatifs des droits ont été réalisés.
• Lorsque cela est pris en charge, les changements sont attribuables à un compte administrateur personnel dans Audit Trail.
• Les comptes API et de support ont leurs propres responsables et cycles de vie.
• L’offboarding couvre le statut, les sessions, la MFA, les secrets et les dépendances.

FAQ