Teoría BBDD

Jun

2025

¿Qué es xp_cmdshell y por qué deberías limitar su uso?

Hay ciertas funciones en SQL Server que tienen más leyenda que documentación, y una de ellas es xp_cmdshell. Mencionarla en una reunión de seguridad es como decir “TRIGGER” en una daily de DBAs: inmediatamente empiezan los sudores fríos. Pero como buenos profesionales de bases de datos, no podemos permitirnos el lujo de ignorarla. Hay que entender qué hace, cómo se usa (o se abusa), y sobre todo por qué en la mayoría de los casos deberíamos tenerla bien atada, o mejor aún, desactivada.

¿Qué es xp_cmdshell?

Para los recién llegados (o para los que han tenido la suerte de no cruzárselo nunca), xp_cmdshell es un extended stored procedure que permite ejecutar comandos del sistema operativo directamente desde SQL Server. Tal cual. Es decir, desde una sesión de SQL puedes invocar comandos como si estuvieras en la consola de Windows: copiar ficheros, lanzar scripts batch, ejecutar aplicaciones externas… o destruir medio sistema si tienes permisos suficientes y pocas luces.

El siguiente ejemplo es inocente (más o menos), pero ilustra la idea:

EXEC xp_cmdshell 'dir C:\';

SQL ejecuta el comando y te devuelve el resultado como si estuvieras en una consola de MS-DOS de los 90. Y sí, es tan peligroso como suena.

¿Para qué se usa xp_cmdshell legítimamente?

Hay quien justifica su uso con casos reales: automatización de procesos que interactúan con el sistema de archivos, lanzamiento de tareas administrativas, scripts que integran SQL con otros procesos batch o herramientas de terceros. Incluso estos ojos han visto escenarios donde se usaba para invocar clientes FTP y descargar archivos que luego se importaban con BULK INSERT o mover backups entre servidores.

Y aunque todo esto se puede hacer, la pregunta es: ¿debería hacerse así? Spoiler: no. O al menos, no sin un análisis serio de riesgos y alternativas. Porque una cosa es poder, y otra muy distinta es tener criterio.

La seguridad, el verdadero problema de xp_cmdshell

El mayor problema de xp_cmdshell no es su existencia, sino su potencia. Ya sabes, eso de que un gran poder conlleva una gran responsabilidad. Este procedimiento ejecuta los comandos en el contexto de seguridad de la cuenta del servicio de SQL Server, lo que, si no se ha configurado adecuadamente, puede significar ejecutar con privilegios elevados. Y eso convierte cualquier brecha de seguridad en una puerta abierta al sistema operativo, red y mil cosas más.

Por defecto, xp_cmdshell viene desactivada. Microsoft no es tonta, y sabe que dejar esto habilitado por defecto sería como enviar servidores a producción con el firewall desactivado. Pero como casi todo en SQL Server, se puede activar fácilmente:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

Y una vez activada, el riesgo está servido. Cualquier usuario que tenga permisos para ejecutarla puede comprometer el servidor. Si encima tiene permisos sysadmin (y aún hay entornos donde todo el mundo es sysadmin «porque así funciona»), la fiesta está asegurada.

¿Se puede usar xp_cmdshell de forma segura?

La teoría dice que sí. Microsoft introdujo ciertas medidas para controlar su uso. Por ejemplo, si el usuario no es sysadmin, se puede configurar una cuenta proxy mediante el procedimiento almacenado sp_xp_cmdshell_proxy_account que limita los permisos con los que se ejecutan los comandos.

EXEC sp_xp_cmdshell_proxy_account 'DOMINIO\usuario', 'contraseña_segura';

Esto permite definir una credencial para que el comando xp_cmdshell se ejecute con los permisos de ese usuario en lugar de usar la cuenta del servicio. Pero seamos serios: ¿cuántas veces se hace esto bien en entornos reales? ¿Cuántas veces se revocan luego los permisos cuando ya no hacen falta? ¿Y cuántos servidores en producción tienen la proxy account configurada pero también usuarios sysadmin “temporales” que llevan ahí desde 2016?

Además, aunque configures la cuenta proxy correctamente, sigue siendo un punto de entrada que puede explotarse si no se audita y controla su uso. El riesgo persiste, solo se disfraza de buena práctica.

Alternativas reales y razonables a xp_cmdshell

Casi todo lo que se hace con xp_cmdshell se puede hacer mejor y con más control desde fuera de SQL Server. Si necesitas mover archivos, usar PowerShell o scripts externos lanzados desde un agente de automatización como SQL Server Agent o un sistema de orquestación decente (¿alguien ha dicho Azure Data Factory?) es mucho más razonable.

Para transferencias FTP o SFTP, hay herramientas modernas que no requieren meter comandos del sistema operativo en medio del motor de base de datos. Y si lo que se busca es coordinación entre procesos, los servicios de Windows, los job schedulers o incluso Integration Services son alternativas mucho más limpias.

SQL Server es un motor de bases de datos, no un sistema operativo ni un centro de comandos. Empezar a usarlo como tal es como usar un bisturí para abrir latas: técnicamente se puede, pero no es lo suyo y probablemente acabes con un desastre.

Auditar, controlar, eliminar

Si estás heredando un sistema y no sabes si xp_cmdshell está activa, revísalo. Yo personalmente es de las primeras cosas que compruebo. Para verlo es tan fácil como ejecutar:

EXEC sp_configure 'xp_cmdshell';

Si el valor de «config_value» es 1, está habilitado. Si no se está utilizando (y muchas veces no lo está, pero nadie se atreve a desactivarla “por si acaso”), desactívalo sin piedad:

EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

Y si alguien protesta, que traiga el caso de uso documentado, el análisis de riesgos y una alternativa propuesta. Si no puede justificarlo, no es necesario. Punto. No admito discusiones.

Además, si en algún entorno necesitas activarlo temporalmente, documenta cuándo y por qué, y asegúrate de desactivarla después. Y lo más importante: registra quién tiene permisos para usarlo, y controla ese acceso como si fuera el código para activar el botón rojo nuclear. Porque en cierto sentido, lo es.

Conclusión

xp_cmdshell es una herramienta poderosa, pero como todas las herramientas poderosas, puede causar más daño que beneficio si se usa mal. No está pensada para ser parte habitual de ningún flujo de trabajo moderno en SQL Server. Su existencia tiene sentido en contextos muy controlados, con auditoría, justificación y planificación. Pero la realidad es que en la mayoría de los entornos en los que aparece, lo hace como un parche rápido, una chapuza heredada o un atajo que algún valiente implementó sin medir consecuencias.

Limitar o eliminar su uso no solo mejora la seguridad del entorno, sino que obliga a buscar soluciones más sostenibles, limpias y profesionales. Porque si nuestra base de datos necesita ejecutar scripts del sistema para funcionar, igual el problema no está en xp_cmdshell, sino en cómo hemos diseñado la arquitectura.

Y si aún piensas que «no pasa nada por tenerla habilitada», revisa tus backups. Puede que los necesites antes de lo que crees, o que alguien los haya borrado desde xp_cmdshell.

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 LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Jun

2025

Búsquedas semánticas con IA en SQL Server 2025

En algún momento entre pelear con índices zombis y migraciones eternas, Microsoft ha decidido que SQL Server también podía ser inteligente. Y no me refiero al tipo de inteligencia que esperas de un MERGE bien hecho (que ya sabemos que es difícil de ver), sino a IA de verdad: modelos de lenguaje, embeddings, vectores y búsquedas semánticas integradas directamente en el motor. Sí, en nuestro motor de base de datos favorito.

En este artículo vamos a desmenuzar la nueva funcionalidad de SQL Server 2025 que permite integrar modelos de IA para realizar búsquedas semánticas directamente desde SQL. Sin inventos raros y, lo más sorprendente, sin tener que abandonar nuestro entorno habitual. Ahora podemos chatear con nuestros datos sin salir del Management Studio.

Inteligencia artificial en SQL Server: la cosa se pone serIA

(Perdón por el chiste. Es malísimo, lo sé)

Esto no es un plugin experimental ni una feature de análisis de datos metida con calzador. Microsoft ha incorporado capacidades de IA directamente en el motor de SQL Server. Y eso significa que podemos invocar modelos de lenguaje desde procedimientos almacenados, generar embeddings, indexarlos y hacer comparaciones semánticas en caliente.

Y todo sin que los datos salgan del servidor. La seguridad y el rendimiento siguen siendo prioridad: lo que hacemos es pasar una consulta a un modelo que genera un vector (el embedding) y lo compara con los vectores previamente almacenados localmente. Resultado: respuestas rápidas, semánticamente relevantes y sin montar un chiringuito en Azure (solo unos pocos clicks).

Vectores, embeddings y cosenos: la IA no entiende palabras, entiende números

Esto tiene que quedar claro desde el principio, la IA no trabaja con texto. Aunque lo parezca, la IA no sabe leer. Internamente trabaja con vectores, que son representaciones matemáticas de conceptos. Un vector es simplemente una lista ordenada de números (normalmente de 1536 dimensiones) que representa el “significado” de algo.

Cuando decimos “bicicleta para descenso de montaña”, un modelo de lenguaje genera un vector que encapsula ese significado. Ese vector es un embedding. Y lo interesante es que podemos comparar ese embedding con otros ya almacenados, usando la similitud de coseno, para encontrar los conceptos más cercanos.

Cuanto más cercano es el ángulo entre dos vectores, más parecido es su significado. No hay magia. Hay trigonometría. Pero no te preocupes, que no vas a tener que calcularlo tú: eso se lo dejamos al motor, que para eso está.

¿Cómo implementar esta IA?

En mis pruebas he usado AdventureWorks, cómo no. Desde la tabla de productos, extraemos las descripciones y, a esas descripciones, les generamos embeddings usando un procedimiento almacenado que recibe un texto y lo envía al modelo modelo en Azure OpenAI (podría ser otro, incluso en local, pero aquí opte por ir a lo fácil y rápido). Importante guardar estos embeddings en una tabla separada: más limpio y mejor rendimiento.

Por último, creamos un segundo procedimiento almacenado que recibe una frase, genera su embedding con el SP anterior y, una vez obtiene su embedding lo compara con los embeddings almacenados en base para devolver los más cercanos. Y sí, todo desde SQL. Llamadas REST mediante, pero dentro de una SP.

Así obtenemos resultados en milisegundos. Eso es lo que tarda en calcular el embedding de una petición y compararlo con los datos. Rápido, elegante, sin ETLs de por medio y sin mover los datos de casa (siempre que uses un modelo local, claro).

¿Qué es esto de las búsquedas semánticas? La magia de la IA en SQL

Este es el verdadero factor diferenciador. No estamos hablando de una búsqueda con like ni de índices de texto completo (Full Text Indexes). Los embedding representan el significado de las palabras de manera que aspectos como sinónimos o incluso, el idioma de la búsqueda dejan de ser un impedimento.

En mis pruebas las descripciones de producto están en inglés, francés o incluso en chino. Yo he probado con prompts en español, inglés e incluso con redacciones ambiguas. El modelo entiende el significado, no la forma. Así que da igual si pides “bicicleta de descenso” o “bike for downhill mountain racing”: el embedding será muy similar y los resultados coherentes.

Una vez que te acostumbras, el LIKE te empieza a parecer una piedra tallada con cincel.

Aplicaciones reales más allá del hype

Vale, comparar descripciones de productos es “la demo fácil”. Pero no significa que no tenga valor ni que esto no se pueda llevar mucho más allá.

Gracias a esta funcionalidad puedes recomendar artículos relacionados en tu tienda web. Pero no es el único caso de uso.

¿Tienes transcripciones de llamadas de soporte técnico? Embeddings. ¿Tienes feedback de clientes en la web? Embeddings. ¿Quieres analizar opiniones para saber si tu producto gusta o no? Más embeddings. Puedes clasificar sentimientos, detectar patrones de insatisfacción, anticipar problemas o simplemente automatizar búsquedas que hasta ahora eran imposibles sin intervención humana.

Y todo desde SQL Server. Sin montar pipelines, sin exportar a otro sistema, sin líos innecesarios. Aquí, en casa. Y eso, para un DBA con años de cicatrices, es música celestial pero también asusta. ¿Cómo va a impactar esto en nuestros sistemas? Solo el tiempo y el uso en cada escenario lo dirá.

Comparaciones por dentro: un vistazo rápido al cálculo de la IA

[Modo TryHard Activado] Por si tienes curiosidad matemática (o simplemente quieres saber si todo esto tiene sentido), el cálculo de similitud se basa en cosenos. Lo que estamos haciendo es comparar dos vectores, en nuestro caso el del prompt y el del producto. Para eso lo que se hace es calcular su producto escalar, sus magnitudes, y aplicar la fórmula del coseno.

Similitud = cos(θ) = (A·B) / (||A|| * ||B||)

Y la distancia, por si necesitas algo más crudo, es simplemente 1 – similitud. Cuanto más cercana a cero, más similares. Cuanto más cerca de uno, más distintos.

¿Y qué hacemos con eso? Ordenamos por similitud y nos quedamos con los más relevantes. No hay magia negra. Es álgebra lineal.

Conclusión

Esto no es hype. No es una demo para sorprender en eventos. Es una funcionalidad real, integrada, segura y rapidísima que cambia la forma en la que interactuamos con los datos.

SQL Server 2025 ha dejado de ser solo un motor relacional. Ahora también es un intérprete semántico. Y eso abre puertas que antes ni sabíamos que existían.

Lo dicho: si pensabas que lo habías visto todo en SQL, ya puedes ir quitándote esa idea de la cabeza. Y si no empiezas a trastear con embeddings, búsquedas semánticas y llamadas a modelos de lenguaje… no digas luego que no te avisamos.

Esto ha venido para quedarse. Y aquí, como siempre, trataré de analizarlo en condiciones.

May

2025

Roles de base de datos en SQL Server

Después de explorar los roles de servidor predefinidos en SQL Server, es lógico continuar analizando el otro gran componente del modelo de permisos: los roles de base de datos. Mientras que los primeros afectan a toda la instancia, estos últimos actúan dentro de una base de datos concreta, permitiéndonos aplicar controles más finos sobre quién puede hacer qué, cómo y dónde dentro del entorno de datos.

Gracias a los roles de base de datos, podemos organizar el acceso de usuarios, aplicaciones y servicios en función de necesidades específicas, minimizando el riesgo de accesos indebidos y facilitando la administración. Su correcta utilización es clave para implantar políticas de seguridad sostenibles y alineadas con el principio de privilegio mínimo.

¿Qué son los roles de base de datos y cómo se diferencian de los de servidor?

Los roles de base de datos son “contenedores de permisos” que se aplican dentro del ámbito de una única base de datos. Un usuario puede pertenecer a distintos roles en diferentes bases, con permisos completamente independientes. A diferencia de los roles de servidor, no otorgan privilegios sobre la instancia ni sobre otras bases de datos.

Por ejemplo, un usuario podría ser db_datareader en una base y db_owner en otra, sin que eso afecte a su capacidad de acceder a la configuración global del servidor o a otras bases no relacionadas. Para ser estrictos, cada base de datos tendrá su usuario que pertenece a sus roles y estos usuarios estarán enlazados a un mismo login.

Esta independencia permite diseñar estrategias de seguridad muy detalladas, en las que cada usuario o grupo recibe únicamente los permisos necesarios en cada base, sin arrastrar privilegios innecesarios.

Roles fijos de base de datos

SQL Server incluye una serie de roles fijos que vienen predefinidos en cada base de datos y cubren los escenarios más habituales de gestión y uso:

db_owner otorga control total sobre todos los objetos y permisos de la base de datos. Es el equivalente a un administrador local. Su uso debe restringirse, ya que un miembro de este rol puede concederse cualquier permiso, incluso eliminar datos o activar configuraciones peligrosas como TRUSTWORTHY.
db_securityadmin permite gestionar permisos, roles y pertenencias, sin acceso directo a los datos. Se utiliza en contextos donde la administración de seguridad está delegada a un equipo diferente del que desarrolla o explota la base.
db_accessadmin se centra en controlar qué inicios de sesión pueden acceder a la base de datos, sin permitir alterar los objetos.
db_ddladmin permite crear y modificar objetos, como tablas, procedimientos o funciones, pero no ejecutar o leer datos si no se concede ese permiso explícitamente.
db_datareader y db_datawriter permiten leer o escribir en todas las tablas y vistas de la base, respectivamente. Su uso está muy extendido en entornos donde se busca una división clara entre consumo y generación de datos.
db_backupoperator da acceso a realizar copias de seguridad de la base, pero no restaurarlas ni acceder al contenido.

También existen dos roles especiales diseñados para denegar explícitamente el acceso a los datos.

db_denydatareader impide leer cualquier tabla o vista, incluso si otros roles o permisos lo permiten.
db_denydatawriter bloquea la capacidad de insertar, actualizar o eliminar datos.

Además, todos los usuarios pertenecen al rol public, que funciona como contenedor de permisos comunes. Conviene auditar este rol, ya que cualquier permiso que se le conceda afectará a todos los usuarios de la base, sin excepción.

Roles definidos por el usuario: flexibilidad con control

Los roles fijos no cubren todos los escenarios. En bases de datos complejas, necesitamos diseñar roles personalizados que agrupen permisos según criterios funcionales, de negocio o de seguridad. SQL Server permite crear estos roles mediante la instrucción CREATE ROLE, y a partir de ahí podemos asignarles permisos (GRANT, DENY, REVOKE) y miembros (ALTER ROLE … ADD MEMBER).

Esto nos permite definir roles como lectura_finanzas, escritura_marketing, administrador_reportes o cualquier otro nombre que represente una necesidad específica de acceso.

Una ventaja clara de este enfoque es que facilita la administración a largo plazo: si mañana se incorpora una nueva persona al equipo de marketing, basta con agregarla al rol correspondiente, sin tener que revisar permisos individuales.

También permite mantener las políticas de seguridad documentadas, auditables y fácilmente transferibles entre entornos.

Buenas prácticas en la asignación de roles de base de datos

Diseñar una estrategia sólida de roles no consiste solo en conocer los disponibles, sino en aplicarlos con criterio. No debemos asignar permisos directamente a usuarios individuales. En su lugar, se crean roles personalizados y se asignan los permisos al rol, manteniendo la lógica de acceso desacoplada de los usuarios.

Otra recomendación es que el rol db_owner debe reservarse para tareas excepcionales o de mantenimiento. En la mayoría de los casos, podemos cubrir todas las necesidades combinando db_ddladmin, db_datareader, db_datawriter y roles personalizados.

Como ya hemos comentado antes, revisar el contenido del rol public en cada base de datos es fundamental. En muchas implementaciones antiguas se le han otorgado permisos de lectura general como solución rápida, pero esto impide auditar correctamente qué usuarios acceden a qué objetos.

Por último, documentar el propósito de cada rol, quiénes lo integran y qué permisos tiene asignados nos permitirá mantener el sistema bajo control con el paso del tiempo.

El rol inexistente db_executor: ¿Por qué no existe y cómo crearlo?

Un error común al comenzar a trabajar con SQL Server es suponer que existe un rol fijo llamado db_executor, similar a db_datareader o db_datawriter, que permita ejecutar todos los procedimientos almacenados de una base de datos. Sin embargo, SQL Server no incluye por defecto un rol con este nombre ni con ese comportamiento. Tampoco los roles db_datareader o db_datawriter permiten la ejecución de procedimientos almacenados.

Esto suele generar confusión porque ejecutar procedimientos es una necesidad frecuente, especialmente en entornos donde las aplicaciones solo deben invocar lógica encapsulada sin acceder directamente a las tablas. La buena noticia es que podemos crear este rol manualmente en cualquier base de datos y dotarlo de los permisos necesarios para cumplir esa función. Para ello, basta con ejecutar las siguientes instrucciones:

CREATE ROLE db_executor;
GRANT EXECUTE TO db_executor;

Con esto estamos creando un nuevo rol llamado db_executor y concediéndole el permiso EXECUTE sobre todos los objetos ejecutables de la base. A partir de ese momento, cualquier usuario que añadamos al rol podrá ejecutar procedimientos, funciones o scripts definidos por el usuario, sin necesidad de acceder a las tablas directamente.

Este enfoque es muy útil para separar claramente los permisos de lectura, escritura y ejecución, y encaja perfectamente con una arquitectura basada en acceso controlado mediante procedimientos almacenados. Además, permite mantener el principio de encapsulamiento: los usuarios no necesitan saber cómo se obtiene un dato, solo deben poder invocar la lógica que lo proporciona.

Aunque no sea un rol predefinido, db_executor se ha convertido en una práctica ampliamente aceptada en entornos corporativos y en desarrollos donde se prioriza la seguridad y la trazabilidad de accesos.

Conclusión

Los roles de base de datos en SQL Server nos permiten construir un modelo de seguridad sólido, escalable y alineado con las necesidades reales de uso de cada entorno. Si aprendemos a usarlos correctamente, sin abusar de db_owner, sin asignar permisos individuales y combinándolos con el uso estratégico de esquemas, dispondremos de una estructura de permisos fácil de mantener, auditar y adaptar a los cambios del negocio.

Cuando los roles de servidor y de base de datos se combinan adecuadamente, conseguimos un entorno donde la delegación de tareas y el control de seguridad no son opuestos, sino aliados.

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!

May

2025

¿Qué significa cada rol de servidor en SQL Server?

Cuando administramos SQL Server en entornos de producción o de desarrollo colaborativo, una de las tareas más críticas y delicadas es la asignación de permisos. Necesitamos asegurarnos de que cada persona o aplicación tenga exactamente el nivel de acceso necesario: ni más, ni menos. Para facilitar esa labor, SQL Server proporciona una serie de roles de servidor predefinidos que nos permiten, añadiendo logins a un rol, delegar tareas administrativas sin comprometer la seguridad general del sistema.

Estos roles abarcan un amplio espectro de privilegios, desde el acceso total hasta responsabilidades muy concretas. Entender qué puede y qué no puede hacer cada uno es esencial si queremos implementar una estrategia de seguridad sólida, auditada y coherente con los principios de privilegio mínimo y separación de funciones.

¿Qué son los roles de servidor en SQL Server?

Antes de entrar en detalles, conviene matizar que los roles de servidor se aplican a nivel de instancia, no de base de datos. Esto los diferencia de los roles de base de datos, que tienen un ámbito mucho más localizado. Al pertenecer a un rol de servidor, un inicio de sesión adquiere permisos que pueden afectar a cualquier base de datos, a la configuración del motor, a los recursos del sistema o incluso a las operaciones de seguridad globales.

SQL Server incorpora varios roles fijos de servidor que no se pueden modificar, ni eliminar, ni asignar permisos adicionales. La única acción permitida es agregar o quitar inicios de sesión como miembros. Estos roles están pensados para cubrir la mayoría de escenarios comunes de administración.

Rol sysadmin: control total sin restricciones

El rol sysadmin es, sin lugar a dudas, el más poderoso de todos. Los miembros de este rol pueden realizar cualquier acción en la instancia de SQL Server, incluyendo todas las bases de datos presentes y futuras. No existe ninguna comprobación adicional de permisos cuando el inicio de sesión pertenece a sysadmin, lo que significa que cualquier restricción desaparece.

En la práctica, este rol debería reservarse exclusivamente para los administradores de bases de datos principales y, si es posible, nunca usarse como cuenta de servicio ni asignarse a desarrolladores, aunque sean senior. Desde el punto de vista de seguridad, es recomendable que exista más de una cuenta con este rol (para evitar bloqueos administrativos), pero siempre bajo un control estricto.

Rol serveradmin: configuración del servidor

El rol serveradmin otorga privilegios para cambiar opciones de configuración a nivel de servidor. Esto incluye aspectos como la habilitación de características avanzadas, la configuración de opciones con sp_configure, el arranque de la instancia o incluso el apagado del servicio.

Aunque puede parecer menos crítico que sysadmin, en la práctica sus acciones pueden afectar a todo el sistema, por lo que también debe asignarse con cautela. Es útil en escenarios donde existe un equipo de infraestructura que gestiona SQL Server sin necesidad de intervenir en los datos.

Rol securityadmin: gestión de la seguridad

Este rol permite crear inicios de sesión, asignar permisos a nivel de servidor, administrar certificados y credenciales, así como controlar los roles de servidor. Los miembros de securityadmin tienen una capacidad indirecta de elevar privilegios, ya que podrían agregarse a sí mismos a otros roles, incluyendo sysadmin.

Por esa razón, este rol suele considerarse muy sensible, aunque no tenga acceso directo a los datos. Resulta especialmente útil en entornos donde la seguridad está delegada a otro equipo distinto del que administra las bases de datos.

Rol processadmin: control de procesos

Con este rol se puede finalizar procesos que se estén ejecutando en la instancia. Esto incluye la posibilidad de matar sesiones activas, algo especialmente útil en situaciones de bloqueo o recursos en conflicto. Aunque no otorga permisos para ver o manipular los datos, ni para cambiar configuraciones del sistema, debemos ser cuidadosos, pues si que puede llegar a ser posible capturar información sensible de los planes de ejecución.

Asignar este rol a ciertos operadores puede facilitar la resolución de incidencias sin conceder acceso completo al sistema.

Rol setupadmin: gestión de linked servers

Aunque su uso es mucho menos frecuente hoy en día, setupadmin sigue teniendo sentido en contextos donde se gestionan servidores vinculados (linked servers). Los miembros pueden agregar, modificar o eliminar estas configuraciones, que permiten realizar consultas distribuidas o transferencias de datos entre instancias.

Dado que un linked server puede convertirse en una puerta de entrada a otros entornos, conviene tener claro quién gestiona estos objetos y auditar su uso regularmente.

Rol bulkadmin: importación masiva de datos

Este rol otorga permiso para ejecutar instrucciones BULK INSERT, una opción muy utilizada en procesos de carga masiva de datos, especialmente cuando se trabaja con ficheros planos. Al estar acotado a una funcionalidad muy concreta, resulta adecuado para ciertos perfiles técnicos, como equipos de integración o ETL, que no necesitan más permisos.

Es importante tener en cuenta que la instrucción BULK INSERT puede acceder a archivos del sistema, por lo que, desde un punto de vista de seguridad, también implica cierto riesgo si se combina con rutas de red o recursos compartidos.

Rol diskadmin: gestión de archivos de respaldo

El rol diskadmin es otro de los menos utilizados hoy en día, dado que su funcionalidad está relacionada con la creación y eliminación de archivos de backup desde SQL Server. Su uso tiene sentido solo cuando se utilizan dispositivos lógicos (backup devices), algo cada vez más inusual.

En entornos modernos, donde se realizan backups directamente a rutas del sistema de archivos gestionadas por políticas externas, este rol ha perdido gran parte de su relevancia.

Rol dbcreator: creación y modificación de bases de datos

Este rol permite crear, modificar, adjuntar o restaurar bases de datos. No concede acceso a los datos una vez creadas, pero sí permite establecer configuraciones iniciales que podrían ser utilizadas para ataques indirectos, como por ejemplo habilitar trustworthy o activar clr.

Suele utilizarse para tareas de despliegue automatizado de bases de datos o en escenarios de desarrollo donde los equipos necesitan crear y eliminar bases de datos de forma frecuente. Aun así, es necesario auditar su uso con cierta periodicidad.

Rol public: el rol olvidado

Aunque no se considera un rol de servidor como tal, conviene recordar que todos los inicios de sesión son miembros del rol public, tanto a nivel de servidor como en cada base de datos. Los permisos asignados a este rol afectan a todos los usuarios, por lo que es buena práctica revisar qué privilegios tiene. En general, no deberíamos asignar permisos explícitos al rol public, ni siquiera por comodidad.

Los nuevos roles: control más específico

En versiones recientes de SQL Server, especialmente desde la edición 2022, Microsoft ha introducido una nueva serie de roles de servidor predefinidos que comienzan por el prefijo ##MS_. Estos roles permiten una administración mucho más granular, respondiendo a las necesidades actuales de seguridad y cumplimiento normativo.

A diferencia de los roles tradicionales, que solían abarcar conjuntos amplios de privilegios, estos nuevos roles están diseñados para conceder exactamente el acceso necesario a tareas muy específicas sin otorgar capacidades colaterales. Encontramos, por ejemplo, roles que permiten únicamente conectarse al servidor sin otros permisos (##MS_DatabaseConnector##), gestionar la creación de bases de datos propias (##MS_DatabaseManager##) o administrar inicios de sesión con limitaciones muy concretas (##MS_LoginManager##).

También se han añadido roles orientados a lectura, como los que permiten consultar definiciones de objetos, configuraciones de seguridad o estados de rendimiento del sistema, sin capacidad para alterarlos. Este enfoque resulta especialmente útil en escenarios donde es necesario conceder visibilidad a herramientas de monitorización, auditores, desarrolladores o personal de soporte sin comprometer la integridad del entorno.

En conjunto, estos nuevos roles suponen un avance significativo en la estrategia de seguridad de SQL Server, ya que permiten delegar responsabilidades sin caer en el uso excesivo del rol sysadmin, que históricamente se ha utilizado por comodidad pero a costa de debilitar los controles de acceso. Su correcta implementación no solo mejora la trazabilidad y reduce el riesgo operativo, sino que también facilita el cumplimiento de estándares como ISO 27001, NIST o CIS Benchmarks.

A medida que se estandariza su uso, es previsible que se conviertan en una herramienta clave para los equipos de administración que gestionan entornos compartidos, automatizados o con altos requerimientos de control.

Conclusión

Los roles de servidor predefinidos de SQL Server ofrecen una manera estructurada de delegar funciones administrativas, manteniendo al mismo tiempo el control sobre la seguridad. Una comprensión clara de sus capacidades y limitaciones es imprescindible para cualquier DBA que gestione entornos con múltiples usuarios, distintos niveles de responsabilidad y necesidades operativas bien definidas.

No se trata de asignar permisos por intuición o costumbre, sino de diseñar una política de acceso coherente, auditable y alineada con la realidad operativa de cada empresa. Porque en administración de bases de datos, dar un permiso de más puede ser tan peligroso como no dar ninguno.

May

2025

10 cosas que debe tener tu DRP de SQL Server

Un buen Plan de Recuperación ante Desastres (DRP) en SQL Server no se improvisa con prisas ni se resuelve con un backup semanal en una carpeta compartida. Quien piense lo contrario probablemente también crea que los backups verificados se restauran solos por arte de magia. Aquí venimos a poner orden. Vamos a repasar diez elementos que deben estar presentes en cualquier DRP decente, serio y pensado por alguien que sabe lo que significa tener producción caída más de 15 minutos.

DRP Check 1: Inventario de instancias y bases de datos críticas

Antes de correr a hacer backups como si el mundo se acabara, hace falta saber qué estamos protegiendo. Un DRP sin inventario es como un GPS sin destino. Documentar todas las instancias SQL Server, su versión, configuración, bases de datos alojadas, y cuál de ellas es crítica es el primer paso. Sin eso, el resto del plan será un ejercicio de fe.

Esto incluye nombres, versiones, configuración regional, nivel de compatibilidad, y por supuesto, si estamos hablando de SQL Server On-Prem, en Azure, en máquinas virtuales o en una mezcla caótica digna de una pesadilla DevOps.

DRP Check 2. Estrategia de copias de seguridad (real y testada)

Esto no va de tener un script que haga BACKUP DATABASE, sino de tener un plan de backups bien definido, ajustado al SLA del negocio y validado con restauraciones periódicas. Porque sí, hacer backups sin probar restores es como llenar el depósito del coche sin saber si tienes motor.

Y recuerda debes incluir backups completos, diferenciales y de logs si la base está en FULL.

DRP Check 3. Plan de restauración documentado (y probado, otra vez)

Vale, ya tenemos backups. ¿Y ahora qué? Un DRP sin un procedimiento claro de restauración es solo un acto de fe. Hay que documentar cómo restaurar cada tipo de backup, en qué orden, en qué entorno, y cuánto tiempo se estima que llevará. No valen suposiciones.

¿Se han probado esas restauraciones en un entorno aislado? ¿Se ha medido el tiempo real? ¿Se ha verificado que la aplicación vuelve a levantar sin errores? Si la respuesta es no, el DRP es papel mojado.

DRP Check 4. Topología de alta disponibilidad y replicación

La disponibilidad no es solo cosa del DRP, pero forma parte de él. Un clúster de Always On, una replicación transaccional o un Log Shipping bien montado pueden ser la diferencia entre una caída de horas y una recuperación en minutos.

Aquí hay que documentar cómo están montadas esas soluciones, cómo se comportan ante fallos y, lo más importante, cómo se revierte o se conmutan sin pérdida de datos. Porque el botón “Failover” no es magia, y conviene saber qué pasa antes de pulsarlo.

DRP Check 5. Matriz de responsabilidad (quién hace qué y cuándo)

En medio del caos no hay tiempo para preguntar «¿quién se encarga de esto?». Un DRP debe tener definidos claramente los roles: quién inicia el protocolo, quién comunica a negocio, quién ejecuta los scripts, quién valida y quién da el OK final.

Y no, no vale con poner “El DBA” para todo. Porque el DBA también duerme (al menos en teoría) y puede que no esté disponible a las 3:00 de la mañana un festivo. Así que planifica relevos, turnos y contactos de emergencia. Y por supuesto, guarda esa información fuera del entorno afectado.

DRP Check 6. Procedimiento para activar el DRP

No todo fallo es un desastre. Un plan serio define umbrales: ¿cuándo se considera que hay que activar el DRP? ¿Cuánto tiempo puede estar caída una instancia sin que salten las alarmas? ¿Hay una ventana para intentos de recuperación antes de iniciar failover?

Este punto es crítico. Muchos planes fallan porque nadie sabe cuándo hay que usarlos. Y cuando se deciden, ya es tarde y el daño está hecho. Un buen DRP se activa con decisión, no con debates.

DRP Check 7. Infraestructura de recuperación (y entorno preconfigurado)

Recuperar una base de datos en un entorno que no existe es una broma de mal gusto. El DRP debe incluir un entorno de recuperación configurado con antelación: máquinas, redes, almacenamiento, seguridad… todo listo para levantar una instancia funcional.

Si estás en Azure o AWS, tener imágenes de máquinas o plantillas ARM listas para desplegar reduce el tiempo de recuperación drásticamente. Si estás en On-Prem, tener máquinas físicas o virtuales reservadas para contingencias no es un lujo, es prevención.

DRP Check 8. Automatismos y scripts listos para ejecutar

En medio del desastre, lo último que queremos es escribir scripts a mano o copiar/pegar desde un correo de 2017. El DRP debe contener los scripts ya preparados para tareas como restaurar backups, reconfigurar logins, recrear jobs, reiniciar endpoints y comprobar integridad.

Cuanto más automático esté todo, menos errores y más rapidez. Pero cuidado: automatizar sin entender es un atajo al desastre. Automatización sí, pero documentada, validada y revisada.

DRP Check 9. Validación post-recuperación

El DR no termina cuando el servidor levanta. Termina cuando la aplicación vuelve a funcionar, los usuarios acceden y nadie grita por Teams. El plan debe incluir validaciones técnicas (integridad, acceso, jobs funcionando, monitoreo operativo) y funcionales (consultas clave, flujos de negocio).

Aquí es donde muchos se relajan demasiado pronto. Recuperar una base sin comprobar que los índices no están corruptos o que el SQL Agent arranca, es como arreglar un coche y no probar que arranca. Todo debe quedar verificado y documentado.

DRP Check 10. Revisión y simulacros regulares

Por último, un DRP no es un PDF que se guarda en una carpeta y se olvida. Es un documento vivo que hay que revisar y probar. Idealmente, al menos una vez al año (y si el entorno cambia, con cada cambio relevante).

Los simulacros revelan errores, tiempos reales, dependencias ocultas y, sobre todo, preparan al equipo. No hay vergüenza en fallar en un simulacro. La vergüenza viene cuando el desastre es real y nadie sabe ni por dónde empezar. Y sí, si nunca has hecho un simulacro y crees que todo va a salir bien, te deseo la mejor de las suertes. La vas a necesitar.

Conclusión

Un DRP de SQL Server no es un archivo bonito con diagramas de PowerPoint. Es una estrategia detallada, técnica y validada que te permite dormir un poco más tranquilo (solo un poco). Tiene que estar alineado con el negocio, ejecutado por profesionales y probado con rigor.

Dejarlo para otro día es como ignorar un CHECKDB con errores porque “no ha fallado nada todavía”. Lo sabes tú, lo sabemos todos: el desastre no avisa. Pero sí se entrena. Así que más vale tener el plan listo y no necesitarlo, que necesitarlo y tener que improvisar.

May

2025

Introduccion a Service Broker

Hay funcionalidades de SQL Server que llevan años en la sombra, casi como reliquias de una época en la que creíamos que todo tenía que resolverse con triggers, cursores o, peor aún, con consultas agresivas cada 30 segundos. Entre esas joyas ignoradas, olvidadas o simplemente mal comprendidas, destaca Service Broker. No es nuevo, no es trendy y desde luego no tiene marketing detrás, pero cuando se entiende y se usa bien, hace cosas que ni Kafka ni RabbitMQ pueden soñar… al menos no sin invitar a medio equipo de infraestructura.

¿Qué es Service Broker y por qué sigue vivo?

Service Broker es el subsistema de mensajería nativo de SQL Server. Está ahí desde la versión 2005, y a diferencia de muchas promesas de aquella época, sigue funcionando sin necesidad de parches ni microservicios externos. La idea es sencilla: permitir que dos o más bases de datos se comuniquen de forma asíncrona, fiable, y con garantías de entrega, utilizando colas, mensajes y contratos definidos dentro del propio motor.

¿Parece demasiado bonito? Lo es, si lo usas bien. Pero claro, como todo en SQL Server, si lo activas sin entenderlo, puede acabar como aquel CLR que alguien dejó en producción y que ahora nadie se atreve a tocar.

Mensajes, contratos y colas: bienvenidos al lenguaje de Service Broker

La arquitectura de Service Broker se apoya en tres conceptos fundamentales: mensajes, contratos y colas.

Los mensajes son lo que uno espera: trozos de datos enviados de un punto a otro. Pueden llevar XML, texto, JSON, o lo que se te ocurra empaquetar mientras quepa en varbinary(max). Pero cuidado: si lo que mandas es basura, lo que recibes es basura asincrónica.

Los contratos definen qué tipos de mensajes se pueden intercambiar y quién puede enviarlos. Un contrato no es un capricho burocrático, es la única barrera entre un sistema robusto y un caos de mensajes huérfanos flotando en una cola sin dueño.

Las colas, por su parte, son objetos de base de datos donde se almacenan los mensajes. Pueden estar enlazadas a una tabla de activación, y de ahí lanzar procedimientos almacenados automáticamente cuando llega un mensaje. Y aquí es donde empiezan las posibilidades interesantes: procesamiento asíncrono, desacoplamiento lógico, incluso orquestación de tareas complejas sin necesidad de middleware externo.

Activación interna: el punto en el que Service Broker se vuelve interesante

Service Broker permite asociar una cola a un procedimiento almacenado. Cuando llegan mensajes nuevos, SQL Server puede lanzar automáticamente una instancia de ese procedimiento. Esto permite procesar eventos en tiempo real (bueno, en SQL-real) sin que el cliente tenga que esperar.

¿Significa esto que podemos hacer procesamiento paralelo dentro de SQL Server sin tocar SSIS, sin montar microservicios ni invocar APIs REST desde T-SQL? Exactamente. Con matices, claro. Esto no es Node.js, ni pretende serlo. Pero si lo que necesitas es procesar tareas, disparar workflows o mover datos entre bases, sin acoplar todo a una única transacción gigantesca, entonces estás en el lugar adecuado.

Un ejemplo real: procesar tareas sin freír el servidor

Supongamos que tenemos un sistema que necesita registrar operaciones de auditoría cada vez que un usuario modifica un registro crítico. Antes de que alguien proponga otro trigger que escriba directamente en la tabla de auditoría (y ralentice la operación principal), pensemos con más cabeza: ¿por qué no delegar esa escritura a un sistema asincrónico?

Con Service Broker, podemos:

Crear un mensaje con la información de auditoría.
Enviarlo a una cola específica.
Tener un procedimiento almacenado escuchando esa cola.
Procesar el mensaje y escribir la auditoría sin interferir con la transacción principal.

Esto no sólo mejora el rendimiento, sino que evita que un fallo en la auditoría reviente una operación de negocio. Sí, lo sabemos: no siempre se puede hacer, pero cuando se puede, es una diferencia de nivel.

Seguridad, rutas y conversación: lo que hay que saber de service Broker

Service Broker funciona bajo un modelo de «conversaciones» entre servicios. Sí, como las conversaciones de WhatsApp, pero con contratos y sin stickers. Estas conversaciones son bidireccionales y tienen estado, lo que permite enviar múltiples mensajes en ambos sentidos de forma controlada.

Para que todo esto funcione entre diferentes bases de datos o instancias, necesitamos definir servicios, rutas, y a veces, incluso certificados si vamos a cruzar servidores. Aquí es donde muchos tiran la toalla, porque no es trivial y la documentación oficial tiene ese encanto críptico tan característico de Microsoft cuando parece que no quiere que usemos algo.

Pero si superamos esta curva de aprendizaje pronunciada, podremos tener mensajería distribuida transaccional entre instancias SQL Server sin necesidad de colas externas, sin middleware y sin lag de 10 segundos.

¿Por qué no se usa más?

Primero, porque no está de moda. Service Broker no tiene un logo molón, ni una conferencia anual, ni camisetas con chistes de desarrolladores de colas. Pero eso no lo hace menos útil. Segundo, porque requiere entender T-SQL más allá del SELECT con JOIN, y eso ya elimina a cierto porcentaje de desarrolladores.

Y tercero, porque no se ha enseñado bien. Muchos lo han visto como «algo para entornos muy específicos», sin darse cuenta de que puede resolver problemas cotidianos: colas de trabajo, asincronía controlada, desacoplamiento entre componentes de una aplicación.

Cuándo usar Service Broker y cuándo no

No todo es un clavo, y Service Broker no es un martillo universal. Si necesitas alta escalabilidad, integración con sistemas heterogéneos o necesitas exponer eventos a sistemas no-SQL, probablemente debas mirar soluciones como Azure Service Bus, RabbitMQ o Kafka.

Pero si tu universo es SQL Server, si el cuello de botella está en las transacciones, y si quieres que los procesos se comuniquen entre sí dentro del mismo motor, entonces estás dejando pasar una oportunidad de oro si ignoras Service Broker.

Conclusión

Service Broker no es una bala de plata, ni pretende serlo. Pero es una de esas funcionalidades que, bien comprendidas, permiten diseñar soluciones limpias, escalables y robustas sin necesidad de inventarse una arquitectura de microservicios para cada cosa.

Y lo mejor es que ya está en tu SQL Server. Solo tienes que activarlo, entenderlo, y no cometer los errores de quienes pensaron que podían usarlo sin leer el manual. Porque sí, hay que cerrar las conversaciones, y no, no es opcional. Como dejar un BEGIN CONVERSATION sin END CONVERSATION: es como dejar una transacción abierta esperando que alguien más la cierre. O que venga un unicornio.

Abr

2025

Cumplir con la ISO 27001 en SQL Server

Adaptar una instancia de SQL Server para cumplir con ISO 27001 no es simplemente activar Transparent Data Encryption y dormir tranquilo. Si alguien te lo ha vendido así, que no te extrañe si el día de la auditoría tienes que improvisar explicaciones más rápido que un becario ante un DROP DATABASE en producción. En este artículo vamos a abordar cómo orientar la configuración y operación de SQL Server para alinearse de verdad con los requisitos de esta norma. Sin humo. Sin soluciones mágicas. Con criterio técnico.

Seguridad en serio: ISO 27001 aplicada a SQL Server

La ISO/IEC 27001 no es una checklist de parches ni una receta genérica para “estar seguros”. Es una norma internacional que define cómo establecer, implementar y mantener un Sistema de Gestión de Seguridad de la Información (SGSI). Y sí, eso implica tanto políticas como controles técnicos. Justo ahí es donde entra SQL Server: no vamos a “certificar” el motor como tal, sino a demostrar que su configuración forma parte de un sistema de seguridad coherente, mantenido y documentado.

Esto significa que no basta con que algo sea seguro. Tiene que serlo, parecerlo, estar documentado y poder demostrarse con evidencias. ¿Te suena familiar? Como cuando configuras xp_cmdshell bien restringido y luego alguien te pregunta por qué no está deshabilitado del todo.

Control de accesos: la piedra angular de la 27001

Si hay una sección que una auditoría va a mirar con lupa, es esta. Y con razón. La gestión de identidades y accesos (IAM) es una de las piedras angulares del SGSI. Aquí es donde SQL Server suele enseñar sus vergüenzas.

Hay que empezar por lo básico: el control estricto de quién accede, a qué y cómo. Eso implica eliminar cuentas de servicio genéricas y acabar con el uso de sa (y si alguien lo necesita “por si acaso”, que se compre una linterna y se prepare para picar en la mina). La autenticación integrada con Active Directory debe ser la norma, no la excepción, y si aún usamos SQL Login para aplicaciones, que al menos estén cifrados y restringidos por roles mínimos.

Es fundamental auditar permisos y revisar regularmente los roles. Y no, eso no se hace con un Excel que alguien actualizó “hace unos meses”. Hay que generar informes automáticos, versionados, y con trazabilidad. Si alguien se añade al rol db_owner y nadie se entera, no tenemos un SGSI, tenemos una partida de ruleta rusa.

Registro y trazabilidad: En la 27001 lo que no se audita no existe

ISO 27001 es bastante explícita en esto: todo acceso relevante y toda operación sensible debe poder ser rastreada. Aquí entra en juego SQL Server Audit, nuestro viejo amigo. Bien configurado, nos permite registrar accesos, cambios de permisos, ejecuciones de procedimientos críticos y cualquier otra acción que entre en la categoría de “esto podría ser un problema si lo hace el usuario equivocado”.

Importante: no vale con activar la auditoría. Hay que almacenarla de forma segura, revisar los logs con periodicidad definida y tener mecanismos de alerta ante anomalías. Un fichero .sqlaudit guardado en una carpeta que nadie mira es como un extintor de cartón en una vitrina de cristal: muy decorativo pero no vale de nada.

Si usas Extended Events para auditorías avanzadas, perfecto. Pero asegúrate de que no sea algo que sólo entiendes tu y otro DBA senior. La documentación debe existir y ser entendible por otros perfiles técnicos.

Cifrado y protección de datos: porque el disco no se protege solo

El cifrado es una parte clave del cumplimiento, pero también uno de los terrenos donde más se abusa del postureo técnico. Que sí, que activar TDE está bien, pero eso no convierte el sistema en “cumplidor”. Hay que ir más allá.

Hablamos de cifrar tanto en reposo como en tránsito. Para lo primero, TDE más Backup Encryption son un buen punto de partida. Pero si hay datos sensibles, necesitamos también Always Encrypted para proteger valores a nivel de columna. Y eso implica repensar aplicaciones y procedimientos. ¿Molesta? Sí. ¿Es necesario? También.

El tráfico por la red entre cliente y servidor debe ir cifrado con TLS. Nada de conexiones en texto plano, y mucho menos con certificados auto-firmados abandonados en un rincón desde 2012. Una revisión de certificados y políticas de cifrado debe formar parte de las tareas periódicas del equipo de DBA, no un apéndice olvidado.

Lo que dice la ISO 27001 de gestión de vulnerabilidades y actualizaciones

Poner los parches de seguridad no es opcional, por mucho que el jefe de proyecto diga que “no conviene tocar nada en producción” o esa frase que tanto hemos oído “si funciona no lo toques”. ISO 27001 exige un proceso definido de gestión de vulnerabilidades, y eso implica inventario, evaluación del impacto, planificación de despliegues y pruebas.

Aquí SQL Server se alinea bien si lo integramos en un ciclo de gestión de parches serio. No vale con instalar el último CU cada seis meses “cuando haya tiempo”. Debemos definir criterios de urgencia, ventanas de mantenimiento, y mecanismos de rollback (sí, backups y pruebas en entornos espejo).

Si alguien aún depende del mail de Microsoft para enterarse de un nuevo CVE, hay que revisar el proceso. Un SGSI que no tiene un canal automático de recepción y evaluación de alertas es como un antivirus sin actualizaciones.

Disponibilidad y recuperación: lo que nadie quiere probar

La norma también cubre la resiliencia del servicio y la capacidad de recuperación ante desastres. Aquí es donde SQL Server tiene mucho que ofrecer, pero sólo si lo usamos bien.

Necesitamos backups automáticos, verificados y documentados. ¿Y las restauraciones? También. No basta con tener copias: hay que probar que funcionan y registrar esas pruebas. Los planes de recuperación deben contemplar diferentes escenarios: pérdida parcial, fallo total, ransomware…

Además, si hay servicios críticos, hay que implementar HA: desde grupos de disponibilidad Always On, hasta clústeres de failover, pasando por réplicas geográficas si el contexto lo exige. Pero cuidado: ningún mecanismo de alta disponibilidad sustituye una buena política de respaldo. El que lo crea debería dejar de leer folletos de marketing.

Documentación y procedimientos: el arte de escribir sin florituras para la 27001

Todo lo anterior no sirve de nada si no está documentado. Y con documentado no nos referimos a un PDF lleno de obviedades técnicas que nadie ha revisado desde 2021.

Debemos tener procedimientos claros para el alta y baja de usuarios, cambios de permisos, mantenimiento programado, revisión de auditorías, gestión de incidencias, y un largo etcétera. Todo ello debe estar accesible, versionado y validado. No se trata de cumplir por cumplir, sino de poder demostrar que sabemos lo que hacemos, cómo y por qué.

Además, durante una auditoría, estos documentos son el salvavidas que puede evitar un informe lleno de “no conformidades”. Si todo el conocimiento está en la cabeza del DBA veterano que ahora trabaja en otra empresa, tenemos un problema. Y un problema de los gordos.

Cultura de seguridad: porque no todo es técnica en la ISO 27001

Aunque suene raro en un blog de DBAs, ISO 27001 también exige que la organización tenga una cultura de seguridad. Esto implica formación, concienciación y procesos que no dependan exclusivamente de las ganas del equipo técnico.

Desde el punto de vista de SQL Server, esto se traduce en revisar que los desarrolladores no guarden contraseñas en texto plano, que las aplicaciones no se conecten como sa, y que los cambios estructurales no se hagan directamente en producción “porque lo pide el jefe”. En resumen: sentido común, respaldado por normas internas.

Conclusión

Adaptar SQL Server para cumplir con ISO 27001 no es cuestión de marcar casillas, sino de asumir responsabilidades. Hay que proteger los datos, controlar accesos, auditar acciones, cifrar donde toca, aplicar parches sin miedo y documentar sin aburrir.

No se trata de ser paranoico, sino profesional. De tener un entorno donde, si mañana alguien pide un informe de seguridad, podamos sacarlo sin sudar. Y si hay una brecha, podamos demostrar que lo hicimos todo bien. Porque al final, eso es la seguridad real: no solo evitar el desastre, sino estar preparados para responder con firmeza si llega.

Como siempre, que nadie os venda soluciones milagrosas. La seguridad en SQL Server, como todo lo que merece la pena, se trabaja. Y si lo hacemos bien, no solo cumplimos ISO 27001: dormimos un poco más tranquilos.

Teoría BBDD

¿Qué es xp_cmdshell y por qué deberías limitar su uso?

¿Qué es xp_cmdshell?

¿Para qué se usa xp_cmdshell legítimamente?

La seguridad, el verdadero problema de xp_cmdshell

¿Se puede usar xp_cmdshell de forma segura?

Alternativas reales y razonables a xp_cmdshell

Auditar, controlar, eliminar

Conclusión

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes