Ir al contenido
Avanet

De Server Lockdown a Unauthorized File Protection: piloto y migración

En resumen: Seleccionar un grupo de políticas cuyos servidores aún estén bloqueados, documentar el estado actual y asegurar la vía de recuperación; antes de desbloquear, preparar una copia Monitor desactivada y sin asignaciones. Desbloquear los servidores piloto únicamente durante la ventana aprobada y, entonces, asignar y activar la copia solo para esos servidores. Esperar al menos 24 horas después de cada cambio de política antes de evaluar los eventos UFP; autorizar de forma específica las ejecuciones legítimas y repetir el ciclo. Solo entonces probar la copia Monitor refinada como una política Block independiente y de asignación limitada. La política Lockdown original y sus asignaciones para los servidores que siguen bloqueados deben permanecer intactas.

Situación inicial y autorización

Se ha anunciado el fin del soporte de Server Lockdown en octubre de 2026, sin indicar un día concreto. Las políticas Lockdown existentes ahora se denominan Unauthorized File Protection (UFP/SUFP). Sus entradas permitidas y bloqueadas se conservan tras el cambio de nombre. Sin embargo, esto no migra ningún host bloqueado: es necesario desbloquearlo antes de aplicarle una política UFP activada. Lockdown también considera de confianza los archivos creados o modificados por software permitido; por tanto, las mismas entradas de política no implican la misma base de confianza en UFP. Este procedimiento se aplica a servidores Windows existentes con Server Lockdown, no a una nueva instalación de Lockdown; Server Lockdown no está disponible con XDR Sensor.

Antes de intervenir: Registrar, por tenant y grupo de políticas, los servidores, responsables, ventanas de mantenimiento y el Lockdown status en My Products > Server > Servers. En la vista de cada servidor, anotar las versiones del producto y del agente que aparecen en Summary, así como la política realmente aplicada a cada host en Policies. Documentar la política original, sus entradas, asignaciones y prioridad como referencia inalterada. Definir, con una carga de prueba representativa y sus responsables, los servicios, tareas programadas, actualizaciones e instalaciones MSI que se probarán; que una instalación MSI termine correctamente no demuestra que los archivos PE extraídos puedan ejecutarse después. Comprobar licencia, sistema operativo, versiones y permisos. Confirmar la copia de seguridad de la aplicación, la vía de recuperación y los contactos de escalado. No empezar sin una ventana aprobada, una vía de retorno probada y la aceptación del riesgo de desbloquear. Las vistas del portal, por sí solas, no demuestran que la protección actúe en el host.

Migrar un grupo de políticas como piloto

  1. Delimitar el piloto. Identificar unos pocos servidores de prueba representativos, su grupo y la política prevista. Registrar de antemano el estado de Lockdown, el estado de los servicios y los procesos importantes de las aplicaciones. Detenerse si no está claro el efecto de la política o falta una vía de recuperación; no migrar un segundo grupo al mismo tiempo.
  2. Preparar Monitor antes de desbloquear. En My Products > Server > Policies, clonar la política UFP existente (antes Lockdown) y denominarla Monitor – [Originalname]. Inmediatamente, en la copia, revisar y eliminar las asignaciones heredadas de Assigned Servers y Assigned Server Groups: el clon no debe incluir de forma amplia ni al grupo que sigue bloqueado ni a otros servidores. Solo en esta copia, eliminar todas las entradas heredadas de Allowed items (en vistas Lockdown anteriores, Allowed files/folders); no eliminar las autorizaciones de la política original. Revisar las entradas heredadas de Blocked items (antes Blocked files/folders) para detectar las obsoletas y las necesarias. En Settings, activar Enable tracking of unauthorized file changes y seleccionar Monitor execution of unauthorized files without blocking. Guardar la copia, por ahora, desactivada y sin asignaciones. No modificar la política original activada, su prioridad ni las asignaciones de los hosts que siguen bloqueados.
  3. Desbloquear el piloto y activar Monitor. Durante la ventana de cambio, acceder a My Products > Server > Servers > [Servername], seleccionar Unlock para cada host elegido y confirmar la operación; comprobar después el estado. Desbloquear no elimina automáticamente el componente Lockdown local; desinstalarlo no forma parte del piloto. Solo entonces, en My Products > Server > Policies, incluir en Assigned Servers/Assigned Server Groups de la copia Monitor exclusivamente los servidores piloto desbloqueados o su grupo de prueba delimitado. Antes de activarla y pulsar Save, volver a comprobar que no queden asignaciones heredadas ni otras asignaciones amplias. Activar y guardar la copia. Para cada servidor piloto, comprobar en My Products > Server > Servers > [Servername] > Policies que la copia Monitor se aplica realmente como política UFP; si se aplica otra, corregir primero el ámbito y la prioridad de la copia piloto, sin cambiar la política original ni las prioridades de los hosts que siguen bloqueados. El modo Monitor informa de las ejecuciones no autorizadas en lugar de bloquearlas.
  4. Observar y autorizar de forma específica. Probar servicios, trabajos, actualizaciones e instaladores representativos. No antes de que transcurran 24 horas desde la asignación o cualquier cambio posterior de la política, revisar los eventos UFP en My Products > Server > Servers > [Servername] > Events o en Reports > General Logs > Events. Cotejar servidor, hora, archivo y operación con la carga de prueba. Autorizar de forma limitada, en Allowed items de la copia Monitor, solo las ejecuciones legítimas confirmadas por los responsables; no conceder permisos generales a carpetas temporales o de descargas en las que se pueda escribir. Documentar la decisión y los responsables, pulsar Save en la página de la política, esperar de nuevo al menos 24 horas y revisar los nuevos eventos. Repetir hasta que los procesos legítimos probados ya no generen eventos sin aclarar. La ausencia de eventos sin una carga de prueba pertinente no autoriza a pasar a Block; investigar lo desconocido en lugar de permitirlo a ciegas.
  5. Probar Block por separado. Clonar la copia Monitor refinada y denominarla Block – [Originalname]. Inmediatamente, revisar y eliminar todas las asignaciones heredadas de Assigned Servers/Assigned Server Groups en la copia Block; antes de activarla y pulsar Save, asignar solo los servidores piloto desbloqueados previstos para evitar que otro host reciba Block por error. En Settings, seleccionar Block execution of unauthorized file, activar la copia y guardarla. Conservar la copia Monitor como vía de retorno específica. Para cada servidor piloto, comprobar en My Products > Server > Servers > [Servername] > Policies que Block se aplica efectivamente; si es necesario, ajustar únicamente el ámbito o la prioridad de las copias piloto. Probar que los servicios, trabajos y actualizaciones funcionan, revisar Events por si hay bloqueos inesperados y volver a evaluar los eventos no antes de que transcurran 24 horas desde la asignación o los cambios. No ejecutar ningún archivo de prueba en producción sin una autorización independiente. Solo después de documentar la aceptación, abordar el siguiente grupo de políticas mediante el mismo procedimiento.

Detención, reversión y escalado

Si aparecen bloqueos sin aclarar, fallan aplicaciones, no hay eventos pese a una carga de prueba que debería generarlos o se aplica una política incorrecta, detener la ampliación. Conservar los datos del servidor, la hora, el archivo, la política aplicada y el estado de los servicios; no crear una excepción Allow amplia como solución rápida. Si surgen problemas con Block después de la aprobación, retirar la asignación de Block a los servidores piloto afectados o desactivar la copia Block para ese ámbito. Eso, por sí solo, no constituye una reversión: La copia Monitor activada debe estar asignada a cada host afectado y ser la política UFP aplicable de mayor prioridad; de lo contrario, al retirar Block podría aplicarse otra política. Corregir en consecuencia el ámbito y la prioridad de las copias piloto sin modificar la política original ni las asignaciones de los hosts que siguen bloqueados. Guardar y comprobar para cada host, en My Products > Server > Servers > [Servername] > Policies, que la política Monitor realmente aplicada es la prevista; después, volver a probar los servicios e instaladores y observar los eventos. Revertir las entradas Allow o Block incorrectas únicamente según el cambio documentado. Si la incidencia persiste, activar el plan de recuperación de la aplicación e implicar a los responsables operativos y al soporte de Sophos.

Límite de la vía de retorno: Volver a Monitor no restaura el estado anterior de host bloqueado, la base de confianza de Lockdown ni los archivos modificados. Conservar la política original tampoco garantiza poder volver a bloquear el host con un efecto idéntico. No volver a bloquearlo de forma improvisada ni eliminar el agente; si es necesario, revisar con el soporte de Sophos la vía de recuperación específica del host. Entre el desbloqueo y la aceptación de Block, el grado de protección puede ser distinto; no se garantiza una transición sin brechas de protección.

Para conocer las entradas UFP y un piloto general en servidores Windows ya desbloqueados, consulte Unauthorized File Protection para servidores Windows.