Configurar Data Anonymization en Sophos Firewall

Data anonymization cifra la información identificativa en los logs e informes de Sophos Firewall. Esto incluye, en particular, nombres de usuario y direcciones IP, MAC y de correo electrónico. Un administrador autorizado puede volver a mostrar esta información para un análisis legítimo.

El procedimiento seguro es breve:

1. Documentar el objetivo, las salidas afectadas y el proceso de aprobación.
2. Preparar dos cuentas personales de administrador como autorizadores.
3. Activar la función en System services > Data anonymization y seleccionar ambos autorizadores.
4. Comprobar con un evento de prueba controlado que Log viewer y la búsqueda siguen funcionando.
5. Mostrar de forma deliberada la identidad con un autorizador y realizar una prueba negativa del acceso no autorizado.
6. Añadir excepciones solo para casos individuales justificados.
7. Comprobar por separado las exportaciones CSV y los informes PDF generados realmente.

⚠️ Data Anonymization no elimina datos ni garantiza la protección de todas las rutas de datos externas. Remote Syslog, Sophos Fusion (antes Sophos Central), CTR, los archivos de Advanced Shell y los backups se comprueban por separado. Una exportación solo se comparte después de revisar el archivo concreto para detectar identidades sensibles.

Qué protege Data Anonymization

Sophos describe la función como el cifrado de identidades en logs e informes. Menciona específicamente:

• nombres de usuario;
• direcciones IP;
• direcciones MAC;
• direcciones de correo electrónico.

Esto reduce la exposición innecesaria durante el análisis diario y la elaboración de informes. Por ejemplo, un NOC puede investigar un problema según la hora, la regla y la acción sin ver inmediatamente todas las identidades de usuarios o clientes. Para un caso legítimo de seguridad o privacidad sigue siendo posible mostrarlas de forma controlada.

La función no sustituye los permisos de acceso, las reglas de retención ni la transmisión protegida. Un informe anonimizado puede seguir conteniendo nombres de firewalls, URLs, nombres de reglas, marcas de tiempo y eventos de seguridad. Esta información también puede ser confidencial.

Qué no se presupone de forma general

La ayuda actual de Sophos confirma el efecto en logs e informes y la posibilidad de mostrar la información en Log viewer. Sin embargo, no describe con el mismo detalle todas las rutas de salida posibles. Por ello, la configuración on-box no se aplica automáticamente a las siguientes rutas de datos:

• Remote Syslog o SIEM;
• Sophos Central Firewall Reporting;
• Consolidated Troubleshooting Reports y logs de soporte individuales;
• archivos en /log dentro de Advanced Shell;
• backups y exportaciones de configuración;
• correos ya enviados o archivos PDF y CSV almacenados.

Remote Syslog sigue requiriendo el procedimiento específico de protección y aceptación descrito en Enviar Syslog de Sophos Firewall de forma segura a un SIEM. Los informes centrales se comprueban por separado según Sophos Central Firewall Reporting.

Preparar los autorizadores y definir el límite de aprobación

Al activar la función se seleccionan uno o varios administradores como Authorizer. Esta asignación autoriza la desanonimización; en Log viewer, un autorizador debe facilitar sus credenciales de autenticación. Sophos recomienda al menos dos autorizadores. Si el administrador conectado también está registrado como autorizador, Sophos exige la aprobación de al menos otro autorizador.

De ello se deriva un límite importante: no queda demostrado un doble control técnico para cada visualización. La ayuda de SFOS 22.0 solo confirma autorización y nueva autenticación en Log viewer. Si la política propia exige dos personas para cada análisis, hay que aplicar además ese proceso organizativo y validarlo por separado de la autenticación del producto.

Por tanto, antes de activar la función se preparan dos cuentas personales, por ejemplo:

• privacy.authorizer1
• privacy.authorizer2

Estos nombres son ejemplos y se sustituyen por dos cuentas de administrador claramente asignadas a personas. Una cuenta compartida por el equipo no sería adecuada porque ya no se podría atribuir a una persona la visualización, la aprobación y la revisión posterior. Configurar de forma segura administradores y perfiles de Device Access explica cómo crear cuentas personales y perfiles restringidos.

Authorizer no es un perfil de Device Access independiente. Los perfiles proporcionan acceso basado en roles a WebAdmin y API mediante None, Read-only o Read-write; un usuario local se crea en Authentication > Users con el tipo Administrator y un perfil. Sophos no especifica un perfil mínimo para Data Anonymization. Por tanto, antes del cambio se comprueba que ambas cuentas previstas puedan acceder realmente a la página necesaria y a Log viewer, sin atribuirles un perfil no documentado.

También se definen previamente los siguientes puntos:

• los casos de soporte, seguridad o privacidad en los que se permite mostrar la información;
• quién solicita y aprueba el análisis;
• cómo se documentan el ticket, el objetivo, el periodo y las identidades afectadas;
• cuándo caduca una excepción y se vuelve a revisar;
• qué administrador local de recuperación sigue disponible si un autorizador no funciona.

La activación se detiene si solo hay una cuenta de administrador operativa o si el inicio de sesión normal en WebAdmin del segundo autorizador previsto no se ha probado correctamente. Su función de autorizador solo puede probarse después de asignarla.

Activar Data Anonymization

1. Iniciar sesión en WebAdmin con una cuenta personal de administrador.
2. Abrir System services > Data anonymization.
3. Seleccionar Enable data anonymization.
4. Seleccionar al menos los dos autorizadores preparados.
5. Seleccionar Apply.
6. Si el administrador conectado está seleccionado como autorizador, obtener la aprobación de al menos otro autorizador cuando la interfaz la solicite.
7. Volver a cargar la página y comprobar que la configuración activada sigue apareciendo.

El cambio no se combina con modificaciones de perfiles de administrador, MFA o destinos de logs. Un único cambio es más fácil de comprobar y revertir.

Generar un evento de prueba controlado

La prueba de aceptación utiliza un cliente piloto conocido, como 10.20.30.25, y un usuario de prueba claramente asignado, como privacy.test. La dirección IP privada es un ejemplo. Se sustituye por un cliente piloto real de la red de gestión o de pruebas para que el evento generado pueda identificarse de forma inequívoca en el Log viewer local.

Para la prueba se documentan la hora, la Source, la Destination, el servicio y la Firewall Rule ID esperada. A continuación, el cliente piloto genera una conexión breve y permitida cuya regla tiene activado Log firewall traffic. Así se distingue una función de anonimización operativa de la simple ausencia de un evento coincidente.

Si el evento no aparece, primero se comprueba la ruta de logging normal. Asignar correctamente los servicios y archivos de log de Sophos Firewall ayuda con este paso. Data Anonymization no repara el logging de reglas desactivado ni un Log viewer bloqueado.

Realizar pruebas positivas y negativas en Log viewer

1. Abrir Log viewer y seleccionar el módulo correspondiente.
2. Limitar el periodo y los filtros al evento de prueba documentado.
3. Comprobar que los campos de usuario y dirección aparecen anonimizados.
4. Realizar una búsqueda de texto libre con la información anonimizada visible. Sophos confirma que la búsqueda también funciona con información anonimizada.
5. Como autorizador registrado, utilizar el botón Data anonymization e introducir las credenciales de autenticación propias de la cuenta.
6. Comprobar que la identidad prevista se muestra para el análisis.
7. Cerrar la vista autorizada y utilizar un administrador de prueba no registrado como autorizador para comprobar que no se revelan las identidades. El fallo concreto puede variar según los permisos; la prueba solo tiene éxito si el administrador de prueba no recibe identidades en texto claro.

Una prueba correcta del autorizador solo confirma esta ruta concreta de WebAdmin. Todavía no demuestra que PDF, CSV, Sophos Fusion, Syslog o los archivos de soporte utilicen la misma representación.

Añadir excepciones solo con una justificación

Una excepción impide que la identidad seleccionada se cifre en logs e informes. Puede definirse para usuarios y direcciones IP, MAC o de correo electrónico. No es una función de búsqueda más cómoda, sino una divulgación deliberada.

Un caso defendible puede ser una identidad técnica de servicio que un proceso operativo automatizado deba distinguir en texto claro. Incluso entonces, la excepción necesita:

• un objetivo documentado;
• el menor ámbito de identidad posible;
• un owner;
• una fecha de caducidad o revisión;
• una prueba positiva de la excepción y una prueba negativa de una identidad que siga anonimizada.

El procedimiento documentado es:

1. Añadir la excepción concreta en System services > Data anonymization.
2. Seleccionar Apply.
3. Introducir el nombre de usuario y la contraseña de un autorizador.
4. Seleccionar Save.
5. Generar un nuevo evento de prueba y comprobar la representación real.

Después de autenticarse correctamente, las identidades seleccionadas no se cifran. No se utiliza como configuración predeterminada un rango de red amplio, un grupo de usuarios completo sin justificación individual ni una excepción abierta de forma permanente.

Comprobar realmente los archivos PDF y CSV

La vista de WebAdmin es solo una parte de la prueba de aceptación. Las salidas pueden almacenarse después fuera del firewall, enviarse por correo o copiarse en un sistema de tickets.

Comprobar un informe PDF programado

En los informes locales por correo no se espera a la siguiente ejecución regular después de activar la función. El horario se ejecuta con Generate now y se inspecciona el PDF recibido realmente. Programar informes de Sophos Firewall y enviarlos por correo describe el proceso completo de entrega y validación.

Se comprueban al menos los siguientes puntos:

• campos de usuario, IP, MAC y correo electrónico;
• excepciones previstas;
• URLs, nombres de reglas y otro contenido sensible;
• destinatarios, transporte de correo y retención en el buzón.

Un PDF generado anteriormente no se convierte en una nueva prueba de aceptación después de un cambio posterior de la configuración. Para la prueba se genera un archivo nuevo.

Comprobar una exportación CSV de Log viewer

Log viewer puede exportar la vista actual como CSV. La ayuda actual de Sophos confirma la exportación, pero no describe por separado el alcance de la anonimización del archivo. Por ello, se abre una pequeña exportación del evento de prueba controlado y se comprueba campo por campo.

Esta ruta de exportación solo se utiliza en producción después de que tanto las identidades anonimizadas como las excepciones previstas aparezcan correctamente. A continuación, el archivo se almacena de forma segura o se elimina. Un nombre de archivo sin identidad no impide que el contenido incluya datos sensibles.

Delimitar HA, los backups y las rutas de datos externas

La página Data Anonymization de SFOS 22.0 no contiene afirmaciones específicas sobre la sincronización HA ni sobre el contenido de los backups. Por tanto, ninguna se presenta como garantizada. En un clúster HA existente, un evento nuevo tras un failover planificado es una prueba operativa útil, pero Sophos no lo documenta como requisito previo de esta función.

Sophos confirma con carácter general que un backup contiene toda la configuración del firewall y está cifrado. Al restaurarlo se sustituye la configuración actual, se elimina el backup almacenado en el firewall y se reinicia el firewall; restaurar un estado anterior elimina los cambios posteriores. Sin más pruebas, esto no determina cómo se tratan las identidades históricas anonimizadas. Después de una restauración se vuelven a comprobar la configuración, los autorizadores, las excepciones y un evento de log nuevo.

En restauraciones HA, el backup se restaura en el Primary actual y después se sincroniza con el Auxiliary; el reinicio se produce sin failover y causa downtime. Un backup sin configuración HA desactiva HA. Por ello, restaurar un backup no es una forma ligera de revertir únicamente Data Anonymization.

Remote Syslog, Sophos Central Firewall Reporting, CTR y los logs de Advanced Shell se tratan como rutas de datos independientes:

1. Definir el destino y la responsabilidad.
2. Generar un evento de prueba controlado.
3. Comprobar la salida recibida o descargada realmente.
4. Documentar el acceso, la retención y la eliminación segura.

Si una ruta de datos externa sigue conteniendo texto claro, esto no se oculta con una excepción amplia ni desactivando el logging local. En su lugar, se refuerzan el acceso y el transporte del sistema afectado o se detiene la exportación hasta aclarar los requisitos de privacidad.

Solucionar problemas de forma sistemática

Las identidades siguen apareciendo en texto claro

Primero se comprueba que Enable data anonymization sigue activo y que el evento visible se generó después del último cambio. Después se revisan las excepciones para usuarios y direcciones IP, MAC o de correo electrónico. Un evento puede contener varias identidades; una excepción para la Source IP no explica automáticamente un nombre de usuario visible.

A continuación se restablece Log viewer, se genera un nuevo evento de prueba y se comprueba de nuevo la vista. Los PDF antiguos, las descargas del navegador o las capturas de pantalla no son pruebas fiables de la configuración actual.

Un autorizador no puede mostrar una identidad

Se comprueba que la cuenta personal esté realmente seleccionada como autorizador, que su perfil de Device Access permita el acceso necesario y que se utilicen sus credenciales actuales. Si el administrador conectado también es autorizador, se tiene en cuenta la aprobación de otro autorizador descrita por Sophos; no se presupone una segunda aprobación para cada acción de Log viewer si la interfaz no la solicita.

Los perfiles de administrador, MFA y la fuente de inicio de sesión no se modifican al mismo tiempo. Si la visualización sigue fallando pese a la selección correcta y a un inicio de sesión normal correcto, se documentan la hora, el navegador, la cuenta y el mensaje visible. Los autorizadores no se eliminan hasta disponer de una segunda vía de acceso probada y una ruta de recuperación.

Un archivo PDF o CSV difiere de Log viewer

Las rutas se evalúan por separado. Para PDF se documentan el tipo de informe, la hora de generación y Generate now. Para CSV se registran el módulo, los filtros y la hora de exportación. Para Sophos Fusion, Syslog o los archivos de soporte no se promete la anonimización local, sino que se comprueba el archivo o la plataforma de destino real.

No se reinician servicios de reporting o logging ni se borran datos de informes solo porque una salida se represente de otro modo. Primero se crea una prueba reproducible con un archivo nuevo.

Revertir de forma segura

Antes del piloto se registran tres estados en System services > Data anonymization: Enable data anonymization, la lista de autorizadores y cada excepción. Si el cambio no cumple los requisitos acordados, se devuelven exactamente esos valores al estado registrado mediante un cambio autorizado y se selecciona Apply. Restaurar un backup sería desproporcionado porque sustituye la configuración, reinicia el firewall y puede interrumpir HA.

Sophos no documenta una función Reset independiente ni indica si la desactivación cambia retroactivamente la visualización de identidades ya almacenadas. Por ello, la vuelta atrás se valida con un evento de log nuevo, la vista del autorizador, una exportación CSV y, si hace falta, un PDF recién generado; no se afirma nada sobre entradas históricas sin inspeccionarlas.

Las excepciones se devuelven a su ámbito anterior. Los archivos ya exportados siguen existiendo por separado y deben gestionarse según las reglas aplicables. Revertir la configuración no elimina copias de buzones, SIEM, tickets o casos de soporte.

Checklist de operación

• objetivo, owner y proceso de aprobación documentados
• dos autorizadores personales han superado una prueba positiva
• administrador local de recuperación disponible
• Enable data anonymization activo y confirmado después de recargar
• evento de log controlado visible de forma anonimizada
• visualización del autorizador correcta y acceso no autorizado rechazado
• excepciones limitadas, justificadas y con fecha de revisión
• PDF nuevo y CSV de Log viewer comprobados
• Syslog, Sophos Fusion, CTR y logs de shell evaluados por separado
• comportamiento HA comprobado con un evento nuevo si existe un clúster
• autorizadores y excepciones registrados antes de restaurar; restauración no usada como reversión estándar
• archivos ya exportados protegidos y tratados conforme a la retención

Preguntas frecuentes

¿Data Anonymization elimina datos personales?

No. Sophos describe la función como el cifrado de identidades en logs e informes. Un administrador autorizado puede volver a mostrar la información después de autenticarse. Esto no equivale a una eliminación ni a una anonimización irreversible.

¿Remote Syslog y Sophos Fusion se anonimizan automáticamente?

La descripción actual de la función no lo confirma expresamente para estas rutas de datos. Por tanto, se utiliza un evento controlado para comprobar qué se ve en el destino Syslog real, en Sophos Fusion, en el CTR o en un archivo descargado.

¿Es suficiente un solo autorizador?

La interfaz permite uno o varios autorizadores, pero Sophos recomienda al menos dos. Si el administrador conectado también es autorizador, se requiere la aprobación de al menos otro autorizador. Sin embargo, la ayuda no demuestra una segunda aprobación obligatoria para cada visualización en Log viewer. Para un funcionamiento resiliente se siguen utilizando dos cuentas personales y probadas.