Configurer Data Anonymization sur Sophos Firewall

Data anonymization chiffre les informations d’identification dans les logs et rapports de Sophos Firewall. Cela comprend notamment les noms d’utilisateur ainsi que les adresses IP, MAC et e-mail. Un administrateur autorisé peut réafficher ces informations dans le cadre d’une analyse légitime.

La procédure sûre est courte :

1. Documenter l’objectif, les sorties concernées et la procédure d’approbation.
2. Préparer deux comptes d’administrateur personnels comme authorizers.
3. Activer la fonction sous System services > Data anonymization et sélectionner les deux authorizers.
4. Vérifier avec un événement de test contrôlé que Log viewer et la recherche fonctionnent toujours.
5. Afficher délibérément l’identité avec un authorizer et effectuer un test négatif de l’accès non autorisé.
6. Ajouter des exceptions uniquement pour des cas individuels justifiés.
7. Contrôler séparément les exports CSV et les rapports PDF effectivement générés.

⚠️ Data Anonymization ne supprime pas les données et ne garantit pas la protection de chaque chemin de données externe. Remote Syslog, Sophos Central, CTR, les fichiers d’Advanced Shell et les backups sont contrôlés séparément. Un export n’est transmis qu’après vérification du fichier concret afin de détecter les identités sensibles.

Ce que protège Data Anonymization

Sophos décrit la fonction comme le chiffrement des identités dans les logs et les rapports. Sont notamment mentionnés :

• les noms d’utilisateur ;
• les adresses IP ;
• les adresses MAC ;
• les adresses e-mail.

Cela réduit l’exposition inutile lors des analyses quotidiennes et du reporting. Un NOC peut, par exemple, analyser un problème selon l’heure, la règle et l’action sans voir immédiatement chaque identité d’utilisateur ou de client. Une divulgation contrôlée reste possible pour un cas légitime de sécurité ou de protection des données.

La fonction ne remplace toutefois pas les droits d’accès, les règles de conservation ni un transport protégé. Un rapport anonymisé peut toujours contenir des noms de pare-feu, des URLs, des noms de règles, des horodatages et des événements de sécurité. Ces informations peuvent également être confidentielles.

Ce qui ne doit pas être présumé de manière générale

L’aide Sophos actuelle confirme l’effet sur les logs et les rapports ainsi que l’affichage des informations dans Log viewer. Elle ne décrit cependant pas chaque chemin de sortie possible avec le même niveau de détail. Le paramètre on-box n’est donc pas automatiquement étendu aux chemins de données suivants :

• Remote Syslog ou SIEM ;
• Sophos Central Firewall Reporting ;
• Consolidated Troubleshooting Reports et logs de support individuels ;
• fichiers sous /log dans Advanced Shell ;
• backups et exports de configuration ;
• e-mails déjà envoyés ou fichiers PDF et CSV stockés.

Remote Syslog nécessite toujours la procédure de protection et de validation dédiée décrite dans Envoyer le Syslog de Sophos Firewall de manière sécurisée à un SIEM. Les rapports centraux sont contrôlés séparément comme décrit dans Sophos Central Firewall Reporting.

Préparer les authorizers et le double contrôle

Lors de l’activation, des administrateurs sont sélectionnés comme Authorizer. Ce rôle permet d’afficher les identités anonymisées après une nouvelle authentification. Sophos recommande au moins deux authorizers. Si l’administrateur actuellement connecté est lui-même enregistré comme authorizer, l’approbation d’au moins un autre authorizer est requise.

Deux comptes personnels sont donc préparés avant l’activation, par exemple :

• privacy.authorizer1
• privacy.authorizer2

Ces noms sont des exemples et sont remplacés par deux comptes d’administrateur clairement attribués à des personnes. Un compte d’équipe partagé serait inadapté, car l’affichage, l’approbation et le contrôle ultérieur ne pourraient plus être attribués à une personne. Configurer les administrateurs et les profils Device Access de manière sécurisée explique comment créer des comptes personnels et des profils restreints.

Les points suivants sont également définis à l’avance :

• les cas de support, de sécurité ou de protection des données dans lesquels l’affichage est autorisé ;
• la personne qui demande et approuve l’analyse ;
• la manière de documenter le ticket, l’objectif, la période et les identités concernées ;
• la date d’expiration et de nouvelle vérification d’une exception ;
• l’administrateur de récupération local qui reste disponible si un authorizer ne fonctionne pas.

L’activation est interrompue si un seul administrateur fonctionne ou si le deuxième authorizer n’a pas encore réussi un test positif.

Activer Data Anonymization

1. Se connecter à WebAdmin avec un compte d’administrateur personnel.
2. Ouvrir System services > Data anonymization.
3. Sélectionner Enable data anonymization.
4. Sélectionner au moins les deux authorizers préparés.
5. Sélectionner Apply.
6. Si l’administrateur connecté est sélectionné comme authorizer, fournir avec le deuxième authorizer l’approbation exigée par Sophos.
7. Recharger la page et vérifier que le paramètre activé est toujours affiché.

Cette modification n’est pas combinée avec un changement des profils d’administrateur, de la MFA ou des destinations de logs. Une modification unique est plus facile à vérifier et à annuler.

Générer un événement de test contrôlé

Le test de validation utilise un client pilote connu, par exemple 10.20.30.25, et un utilisateur de test clairement attribué, comme privacy.test. L’adresse IP privée est un exemple. Elle est remplacée par un client pilote réel du réseau de gestion ou de test afin que l’événement généré soit clairement identifiable dans le Log viewer local.

L’heure, la Source, la Destination, le service et le Firewall Rule ID attendu sont documentés pour le test. Le client pilote génère ensuite une courte connexion autorisée dont la règle a Log firewall traffic activé. Cela permet de distinguer une anonymisation fonctionnelle de l’absence d’un événement correspondant.

Si l’événement est totalement absent, le chemin de logging normal est d’abord vérifié. Associer correctement les services Sophos Firewall et les fichiers de log aide à effectuer ce contrôle. Data Anonymization ne répare pas un logging de règle désactivé ni un Log viewer bloqué.

Effectuer des tests positifs et négatifs dans Log viewer

1. Ouvrir Log viewer et sélectionner le module concerné.
2. Limiter la période et les filtres à l’événement de test documenté.
3. Vérifier que les champs d’utilisateur et d’adresse apparaissent anonymisés.
4. Effectuer une recherche en texte libre avec les informations anonymisées visibles. Sophos confirme que la recherche fonctionne également avec des informations anonymisées.
5. En tant qu’authorizer enregistré, utiliser le bouton Data anonymization et saisir les propres identifiants d’authentification du compte.
6. Vérifier que l’identité attendue devient visible pour l’analyse.
7. Fermer la vue autorisée et utiliser un administrateur de test qui n’est pas enregistré comme authorizer pour vérifier que les informations ne peuvent pas être affichées.

Un test réussi de l’authorizer ne prouve que ce chemin WebAdmin précis. Il ne prouve pas encore que PDF, CSV, Central, Syslog ou les archives de support utilisent la même présentation.

Ajouter des exceptions uniquement avec justification

Une exception empêche le chiffrement de l’identité sélectionnée dans les logs et les rapports. Elle peut être définie pour des utilisateurs ainsi que pour des adresses IP, MAC ou e-mail. Il ne s’agit pas d’une fonction de recherche plus pratique, mais d’une divulgation délibérée.

Un cas défendable peut être une identité de service technique qu’un processus opérationnel automatisé doit impérativement distinguer en clair. Même dans ce cas, l’exception nécessite :

• un objectif documenté ;
• le périmètre d’identité le plus réduit possible ;
• un owner ;
• une date d’expiration ou de révision ;
• un test positif de l’exception et un test négatif d’une identité qui reste anonymisée.

La procédure documentée est la suivante :

1. Ajouter l’exception précise sous System services > Data anonymization.
2. Sélectionner Apply.
3. Saisir le nom d’utilisateur et le mot de passe d’un authorizer.
4. Sélectionner Save.
5. Générer un nouvel événement de test et contrôler la présentation réelle.

Après une authentification réussie, les identités sélectionnées ne sont pas chiffrées. Une large plage réseau, un groupe d’utilisateurs complet sans justification individuelle ou une exception ouverte en permanence ne sont pas utilisés par défaut.

Contrôler réellement les fichiers PDF et CSV

La vue WebAdmin ne constitue qu’une partie du test de validation. Les sorties peuvent ensuite être stockées hors du pare-feu, envoyées par e-mail ou copiées dans un système de tickets.

Contrôler un rapport PDF planifié

Pour les rapports locaux envoyés par e-mail, il ne faut pas attendre la prochaine exécution régulière après l’activation. Le planning est exécuté avec Generate now et le PDF effectivement reçu est contrôlé. Planifier des rapports Sophos Firewall et les envoyer par e-mail décrit la procédure complète d’envoi et de validation.

Au moins les points suivants sont vérifiés :

• les champs d’utilisateur, d’IP, de MAC et d’e-mail ;
• les exceptions prévues ;
• les URLs, les noms de règles et les autres contenus sensibles ;
• les destinataires, le transport des e-mails et la conservation dans la boîte aux lettres.

Un PDF généré auparavant ne devient pas une nouvelle preuve de validation après une modification ultérieure du paramètre. Un nouveau fichier est généré pour le test.

Contrôler un export CSV de Log viewer

Log viewer peut exporter la vue actuelle au format CSV. L’aide Sophos actuelle confirme l’export, mais ne décrit pas séparément la portée de l’anonymisation du fichier. Un petit export de l’événement de test contrôlé est donc ouvert et vérifié champ par champ.

Ce chemin d’export n’est utilisé en production que lorsque les identités anonymisées et les exceptions prévues s’affichent correctement. Le fichier est ensuite stocké de manière sécurisée ou supprimé. Un nom de fichier sans identité n’empêche pas son contenu de comporter des données sensibles.

Valider HA et les chemins de données externes

Dans un cluster HA, Data Anonymization est de nouveau contrôlé après un failover maîtrisé. Une nouvelle session de test est générée sur le nœud désormais actif et la procédure Log viewer est répétée. Une session WebAdmin existante ou un test effectué uniquement sur l’ancien Primary ne constitue pas une preuve suffisante.

Remote Syslog, Central Reporting, CTR et les logs d’Advanced Shell sont traités comme des chemins de données distincts :

1. Définir la destination et la responsabilité.
2. Générer un événement de test contrôlé.
3. Contrôler la sortie effectivement reçue ou téléchargée.
4. Documenter l’accès, la conservation et la suppression sécurisée.

Si un chemin de données externe contient toujours des informations en clair, cela n’est pas masqué par une exception large ou par la désactivation du logging local. L’accès et le transport du système concerné sont renforcés, ou l’export est interrompu jusqu’à ce que l’exigence de protection des données soit clarifiée.

Délimiter systématiquement les erreurs

Les identités apparaissent toujours en clair

Il faut d’abord vérifier que Enable data anonymization est toujours actif et que l’événement visible a été généré après la dernière modification. Les exceptions pour les utilisateurs et les adresses IP, MAC ou e-mail sont ensuite contrôlées. Un événement peut contenir plusieurs identités ; une exception pour la Source IP n’explique pas automatiquement un nom d’utilisateur visible.

Log viewer est ensuite réinitialisé, un nouvel événement de test est généré et la vue est de nouveau contrôlée. Les anciens PDF, les téléchargements du navigateur ou les captures d’écran ne constituent pas des preuves fiables du paramètre actuel.

Un authorizer ne peut pas afficher une identité

Il faut vérifier que le compte personnel est réellement sélectionné comme authorizer et que ses propres identifiants d’authentification actuels sont utilisés. Si l’administrateur connecté est lui-même authorizer, l’approbation nécessaire d’un autre authorizer est planifiée.

Les profils d’administrateur, la MFA et la source de connexion ne sont pas modifiés simultanément. Si l’affichage échoue malgré une sélection correcte et une connexion normale réussie, l’heure, le navigateur, le compte et le message visible sont documentés. Les authorizers ne sont pas supprimés avant qu’un deuxième accès testé et un chemin de récupération soient disponibles.

Un fichier PDF ou CSV diffère de Log viewer

Les chemins sont évalués séparément. Pour le PDF, le type de rapport, l’heure de génération et Generate now sont documentés. Pour le CSV, le module, les filtres et l’heure d’export sont consignés. Pour Central, Syslog ou les archives de support, aucune anonymisation locale n’est promise ; le fichier cible ou la plateforme concrète est contrôlé.

Les services de reporting ou de logging ne sont pas redémarrés et les données de rapport ne sont pas supprimées uniquement parce qu’une sortie est présentée différemment. Un test reproductible avec un nouveau fichier est d’abord créé.

Revenir en arrière en toute sécurité

Les paramètres précédents sont documentés avant le pilote. Si la nouvelle configuration ne répond pas aux exigences opérationnelles convenues, l’état précédent est restauré sous System services > Data anonymization au moyen d’un changement autorisé. Un nouvel événement de log, la vue de l’authorizer, un export CSV et, si nécessaire, un PDF sont ensuite contrôlés.

Les exceptions sont d’abord supprimées ou leur périmètre précédent est restauré. Les fichiers déjà exportés continuent d’exister séparément et doivent être traités selon les règles de conservation et de suppression applicables. Le retour en arrière du paramètre du pare-feu ne supprime pas les copies dans les boîtes aux lettres, le SIEM, les tickets ou les dossiers de support.

Checklist d’exploitation

• objectif, owner et procédure d’approbation documentés
• deux authorizers personnels ont réussi un test positif
• administrateur de récupération local disponible
• Enable data anonymization actif et confirmé après rechargement
• événement de log contrôlé visible sous forme anonymisée
• affichage par l’authorizer réussi et accès non autorisé refusé
• exceptions limitées, justifiées et assorties d’une date de révision
• nouveau PDF et CSV de Log viewer contrôlés
• Syslog, Central, CTR et logs de shell évalués séparément
• failover HA validé avec un nouvel événement
• fichiers déjà exportés protégés et traités selon la règle de conservation

Questions fréquentes

Data Anonymization supprime-t-il les données personnelles ?

Non. Sophos décrit la fonction comme le chiffrement des identités dans les logs et les rapports. Un administrateur autorisé peut rendre les informations de nouveau visibles après authentification. Cela ne correspond ni à une suppression ni à une anonymisation irréversible.

Remote Syslog et Sophos Central sont-ils automatiquement anonymisés ?

La description actuelle de la fonction ne le confirme pas explicitement pour ces chemins de données. Un événement contrôlé permet donc de vérifier ce qui est visible sur la destination Syslog réelle, dans Central, dans le CTR ou dans un fichier téléchargé.

Un seul authorizer suffit-il ?

L’interface autorise un ou plusieurs authorizers, mais Sophos en recommande au moins deux. Si l’administrateur connecté est également authorizer, au moins un autre authorizer est nécessaire pour l’approbation. Deux comptes personnels et testés sont donc utilisés pour éviter tout blocage opérationnel.