¿Qué carpetas puede excluir del antivirus para SQL Server?

Dos frases se usan de forma intercambiable en las revisiones de bases de datos, y significan cosas muy distintas. Una dice que una carga de trabajo concreta necesita una excepción concreta; la otra dice que el host ya no necesita protección de punto final. La primera es una decisión de ingeniería acotada, y la segunda es un riesgo sin propietario. Separarlas es toda la tarea, y empieza por lo que el servidor hace en realidad.

Dos frases que suenan igual

Una excepción nombra una ruta, un proceso o un tipo de archivo y da una razón para ello. Un abandono retira un control de una máquina y, en su lugar, da una razón para eso. Los dos pueden producir cifras de rendimiento parecidas y posturas de seguridad completamente distintas.

Un servidor de bases de datos es un mal candidato para el abandono porque guarda los datos de los que depende todo lo demás. También es un mal candidato para una directiva de nivel de escritorio, porque analizar archivos que una base de datos mantiene abiertos causa problemas que un escritorio nunca ve. La postura honesta está en el medio, y hay que argumentarla en vez de suponerla. Ese argumento es lo que una revisión debe recoger.

Compare la excepción y el abandono

Ponga las dos opciones una al lado de la otra en cuatro puntos: qué sigue protegido, qué queda expuesto, quién es dueño de la decisión y qué pruebas la respaldan.

Una excepción acotada deja el resto del host bajo la misma protección que antes, mantiene la decisión en un propietario nombrado y se apoya en un síntoma reproducido. Un abandono retira la protección de todo y suele apoyarse en la afirmación de que la máquina no está expuesta. Esa afirmación tiene que sobrevivir a los roles reales del servidor, porque los recursos compartidos, los servidores vinculados, los trabajos del agente y las transferencias administrativas de archivos crean una exposición que un cortafuegos nunca ve. Solo una columna de la comparación de abajo sobrevive a un cambio de propietario, porque registra qué se decidió y por qué.

Ajuste la excepción a la interacción demostrada

Empiece por el síntoma en lugar de por una lista. Un conflicto de acceso a archivos, la presión de recursos y una consulta lenta se ven distintos en los registros y llevan a correcciones distintas. Reproduzca el síntoma con la protección activada y luego identifique la ruta o el proceso exacto que interviene.

Los candidatos típicos son los archivos de la base de datos, los archivos de registro, las copias de seguridad y los archivos del catálogo de texto completo, y la guía de Microsoft sobre software antivirus y SQL Server sigue siendo la referencia para la versión desplegada y el producto de seguridad. No copie una lista de otro servidor ni suponga que un solo nombre de servicio cubre todos los componentes instalados. La excepción más pequeña que atiende la interacción demostrada es la que hay que proponer. Cualquier cosa más amplia necesita su propio argumento.

Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled

Revise esa lista contra el rol del servidor, porque una excepción añadida por un incidente tiende a quedarse para siempre. Una nota breve junto a cada entrada basta para hacer posible la próxima auditoría.

Mantenga los controles de red y de identidad

Una excepción de punto final no dice nada sobre quién puede llegar a la base de datos. La política del cortafuegos debería seguir limitando qué fuentes pueden abrir una sesión SQL o de gestión, y las cuentas de aplicación deberían seguir limitando qué pueden hacer esas sesiones.

Una VPN pertenece a esa misma conversación y a menudo se usa mal como argumento. Restringir la ruta de acceso no valida los archivos, los scripts ni las consultas que llegan por ella. Un túnel cifrado también es opaco para un sensor de red, así que la visibilidad que le da un sensor no es la visibilidad que le da un agente del host. Son flujos de pruebas distintos y ninguno sustituye al otro. La gestión de parches, las herramientas administrativas de confianza y una ruta de recuperación probada siguen siendo responsabilidades separadas con sus propios dueños. La higiene de roles también corresponde aquí: la navegación, las descargas y las tareas de compartir archivos no relacionadas deberían quedar fuera del host de la base de datos salvo que su propietario las haya aceptado explícitamente.

Pruebe el cambio y luego hágase cargo

Pruebe con una carga de trabajo representativa y las comprobaciones de seguridad que importan, y luego compare estabilidad, rendimiento y protección continuada en lugar de solo el error original.

Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20

Mantenga una ruta de reversión soportada y un propietario que revise la excepción tras actualizaciones de componentes o de producto, porque una excepción escrita para una compilación puede sobrevivir al motivo por el que existía. Registre el alcance, el motivo y la fecha de revisión en el mismo sitio que el registro de compilación del servidor. Sin eso, el siguiente revisor hereda una lista sin argumento detrás. Una excepción solo es defendible mientras su motivo siga siendo cierto.