Cuando hablamos de proteger un entorno SQL Server, lo primero que nos viene a la cabeza suelen ser los backups, la alta disponibilidad, los roles de seguridad, incluso el cifrado. Pero curiosamente, uno de los elementos más básicos de la protección –el antivirus– sigue siendo tratado como un accesorio molesto, o lo que es peor, como una amenaza potencial para el rendimiento. Y claro, en ese dilema entre seguridad y rendimiento, muchas veces se acaba apostando por el camino más cómodo: desactivar o ignorar.
No vamos a defender aquí que el antivirus es la piedra angular de la seguridad (no lo es), pero tampoco podemos dejar que el miedo a una caída de rendimiento justifique decisiones negligentes. Lo que necesitamos es un enfoque racional: configurar el antivirus de forma que proteja sin interferir con la operación normal del motor de base de datos. *Spoiler*: se puede. Lo difícil es que alguien lo haga bien.
¿Qué hace el antivirus y por qué molesta (si lo dejamos)?
El trabajo del antivirus es inspeccionar archivos y procesos en busca de patrones maliciosos. Nada nuevo. Lo que sí suele pasarse por alto es *cómo* lo hace: analiza archivos al abrirse, al modificarse, y en ocasiones al cerrarse. También puede inspeccionar procesos en memoria, acceder a redes compartidas, lanzar escaneos programados… y todo eso suena bastante normal hasta que lo dejas funcionando en un servidor SQL Server con una carga seria.
Porque claro, cuando el antivirus decide inspeccionar `tempdb.mdf` mientras el motor está haciendo un `HASH JOIN` como si no hubiera un mañana, empieza la fiesta: bloqueos, ralentizaciones, timeouts y, si tenemos suerte, algún bonito `IO_COMPLETION` en el error log. Y no olvidemos el momento en que el antivirus escanea los archivos `.ldf` en pleno `checkpoint`. Porque sí, todo archivo es sospechoso, incluso los que cambian cien veces por segundo.
El problema no es el antivirus. El problema es no configurarlo.
Archivos y procesos que debemos excluir
Vamos al grano. Hay una serie de rutas, extensiones y procesos que deben quedar fuera del radar del antivirus si queremos mantener la estabilidad y el rendimiento del servidor SQL Server. No es opcional. No es debatible. Está documentado por Microsoft, y si no lo aplicas, estás jugando a la ruleta rusa con discos girando.
Empezamos por los archivos:
– Las bases de datos, claro: archivos `.mdf`, `.ndf` y `.ldf`. Eso incluye todas las rutas donde se ubiquen, incluyendo `tempdb`. Da igual si están en discos SSD, en cabinas SAN o en la nube: fuera del antivirus.
– Los archivos de backup: `.bak`, `.trn`, `.sqb`, `.dif`, etc. Si el antivirus decide escanear un `.bak` de 500 GB en pleno restore, luego no nos preguntemos por qué tarda 2 horas más de lo previsto.
– Los archivos de trace, log y dumps generados por SQL Server (`.xel`, `.trc`, `.dmp`). Algunos de ellos se escriben en caliente, y otros pueden ser enormes.
– Las rutas de instalación de SQL Server y sus binarios (`sqlservr.exe`, `sqlagent.exe`, etc.). Los procesos de SQL no deberían ser intervenidos por el antivirus, especialmente durante eventos como reinicios o cambios de configuración.
También conviene excluir herramientas relacionadas que trabajen cerca del metal, como agentes de backup de terceros (Veeam, Commvault, etc.), soluciones de monitorización, y carpetas temporales utilizadas en procesos ETL, especialmente si están en el mismo servidor.
Y por supuesto: nada de escaneos programados sobre las unidades donde residen estos archivos. ¿Queremos una caída de rendimiento nocturna «espontánea»? Pues eso.
El antivirus SI tiene cabida en un servidor SQL
Llegados a este punto, alguien siempre pregunta: «¿Y si directamente no pongo antivirus?». Bueno, también puedes dejar la puerta del CPD abierta por si alguien quiere entrar a ver qué hay. Todo es cuestión de prioridades.
Un servidor SQL Server, aunque no navegue por Internet, puede estar expuesto a amenazas reales. Las vías de entrada son múltiples: conexiones RDP inseguras, accesos compartidos, usuarios que suben archivos, integraciones con sistemas vulnerables, incluso malwares que viajan dentro de backups. Y no olvidemos el ransomware, que no necesita un navegador para hacer su trabajo. Lo único que necesita es una puerta entreabierta.
Así que sí, el antivirus es necesario. Pero como con cualquier otra herramienta, hay que usarla con cabeza.
Buenas prácticas de configuración del antivirus
Ya sabemos qué excluir, pero ¿qué más podemos hacer para convivir con el antivirus sin odiarlo?
Lo primero, usar soluciones corporativas que permitan configurar políticas centralizadas. Nada de versiones domésticas ni «freemium» que prometen IA mágica y acaban con el 30% de tu CPU. Necesitamos un antivirus que permita gestionar exclusiones, programar escaneos fuera del horario de carga, y monitorizar actividad sin interferir con los procesos críticos.
Lo segundo, documentar las exclusiones. Es increíble la cantidad de veces que se instala un nuevo motor, se configura bien, y meses después alguien cambia el antivirus o actualiza políticas sin revisar nada. Resultado, el rendimiento se degrada, y nadie sabe por qué. Tener un documento claro con las rutas y configuraciones esenciales debería ser parte del estándar de despliegue.
Tercero, coordinar con el equipo de seguridad. Sí, esos que mandan correos con gráficos de amenazas que nadie entiende. Hablad con ellos. Enseñadles los KB de Microsoft. Explicad por qué hay que excluir ciertos archivos. Si lo hacéis bien, es posible que incluso lo agradezcan. Al final, todos queremos lo mismo, que el sistema esté seguro y funcione bien.
Y por último, revisar con cada parche o actualización. Las rutas cambian, las versiones cambian, y lo que funcionaba en SQL Server 2016 puede no ser igual en 2022. La tecnología cambia más deprisa que las excusas para no leer la documentación.
Recursos recomendados (y válidos)
Si alguien necesitas pruebas documentales para convencer al comité de seguridad, que tire de lo oficial. Microsoft tiene un artículo actualizado con las exclusiones recomendadas para SQL Server que puedes encontrar aquí.
También hay buenas prácticas en la documentación de cada solución antivirus empresarial. Lo importante es no quedarse en lo básico: si hay un `.exe` que escanea un `.mdf`, eso es un problema.
Conclusión
El antivirus en un servidor SQL Server no es el enemigo. El enemigo es la ignorancia operativa. Dejar un antivirus sin configurar es tan irresponsable como dejar que todo el mundo sea `sysadmin`. Y no, no exageramos.
Podemos tener rendimiento y seguridad. Pero como casi todo en esta vida (excepto los planes de licenciamiento de Microsoft), requiere esfuerzo. Excluir bien, revisar políticas, hablar entre equipos y no asumir que las cosas «ya vienen bien puestas».
Si seguimos confiando en que el antivirus «sabrá lo que hace», luego no nos sorprendamos si decide escanear `master.mdf` en mitad de un failover. Porque ya lo hemos dicho antes: el antivirus no es malo. Lo malo es dejarlo pensar por sí mismo.
Y no, no vamos a acabar este artículo diciendo que “la seguridad empieza por uno mismo”. La seguridad empieza por no meter la pata.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
Hola Roberto. Gracias por compartir. Excelente contenido.