Cloud

May

2025

Nuevo driver oficial de Microsoft para SQL Server en Python

Sí, después de años de conectar Python a SQL Server con herramientas que parecían salidas de un laboratorio de Frankenstein (pyodbc, te estamos mirando), Microsoft se ha decidido a hacer lo que muchos llevábamos años pidiendo: un driver oficial, moderno y diseñado para funcionar sin depender de ODBC ni de contorsiones a lo MacGyver.

Y lo mejor: es open source, cumple el estándar DB API 2.0, y apunta a convertirse en el nuevo camino recomendado para integrar Python con SQL Server, Azure SQL Database y Azure SQL Managed Instance.

Adiós (por fin) al infierno de pyodbc en python

Durante años, la opción más común (porque no había otra) para conectar Python con SQL Server era pyodbc. Un proyecto comunitario que, para qué negarlo, ha hecho lo que ha podido. Pero que lleva años dependiendo de compilaciones difíciles, bindings a ODBC que no encajan bien en todos los sistemas, y documentación escrita con la misma pasión que una hoja de Excel vacía.

Instalar pyodbc en un entorno moderno de Docker o en Alpine Linux es una forma de tortura que debería estar regulada por la ONU. Y si encima necesitas autenticación integrada con Azure AD, entonces directamente entras en territorio de rituales esotéricos.

Por eso este movimiento de Microsoft no es menor. Es un cambio de paradigma: el reconocimiento oficial de que el stack Python merece un driver real, propio y moderno.

¿Dónde está la trampa? Tranquilos, ahora lo vemos.

Un driver para python nuevo y propio, sin ODBC y sin sobresaltos

El nuevo driver se llama mssql-python. No se basa en ODBC, ni depende de componentes externos como msodbcsql o FreeTDS. Utiliza algo que Microsoft ha bautizado como Direct Database Connectivity (DDBC), que en esencia permite hablar directamente con SQL Server a través del protocolo TDS sin intermediarios, drivers del sistema ni DLLs que haya que compilar con cada luna nueva.

Esto es un salto técnico importante. ODBC ha sido históricamente la forma “oficial” de conectar con SQL Server, pero en Python eso ha traído más dolores de cabeza que soluciones. Compilaciones fallidas, incompatibilidades con Alpine, dependencias externas y errores crípticos eran el pan de cada día. Con mssql-python, ese ecosistema de dolor empieza a tener alternativa.

Estado actual del proyecto driver python: alfa, pero con fundamentos

No todo es champagne todavía. Este driver está en fase alfa. Microsoft lo ha publicado para recoger feedback y validar los fundamentos básicos: conexión, ejecución de consultas, gestión de transacciones y autenticación, incluyendo Microsoft Entra ID (el antiguo Azure AD, para los que aún no han pasado por el rebranding de turno).

¿Se puede usar en producción? No. ¿Se puede probar? Sí. ¿Está en PyPI? También:

pip install mssql-python

Y por una vez, no hay que instalar controladores de sistema ni configurar ficheros .ini. Funciona directamente desde Python con una cadena de conexión estilo:

import mssql_python

connection = mssql_python.connect(
   SERVER=localhost;DATABASE=TestDB;UID=sa;PWD=PasswordSuperSegura123!;Encrypt=yes;"
)
cursor = connection.cursor()
cursor.execute("SELECT TOP 10 * FROM customers")
rows = cursor.fetchall()
for row in rows:
    print(row)
connection.close()

Más sencillo imposible. Bueno, sí: cuando añadan soporte para async nativo. Pero ya llegará.

Cumplir con DB API 2.0 desde python, por fin algo estándar

El driver está diseñado para cumplir de forma estricta la especificación DB API 2.0. Para quien no lo sepa (o lo haya borrado de su memoria por razones de salud mental), esto significa que se respetan los contratos mínimos esperables en un driver Python serio:

Conexiones y cursores como objetos nativos.
commit y rollback para transacciones explícitas.
Sustitución de parámetros segura (nada de concatenar strings como si fuera PHP en 2005).
Manejadores de errores consistentes y previsibles.

Y esto, en resumen, significa compatibilidad real con librerías Python estándar, sin tener que escribir adaptadores caseros como hacíamos con pyodbc.

¿Y qué hay de la autenticación, el talón de Aquiles de los drivers para python?

Aquí es donde el driver empieza a mostrar músculo. Desde el inicio, mssql-python da soporte para Microsoft Entra ID, en todas sus variantes modernas: usuario/contraseña (la clásica), identidad administrada (tanto de sistema como de usuario), autenticación interactiva y, por supuesto, autenticación integrada en entornos federados (Windows domain join).

Esto lo convierte en una pieza muy prometedora para entornos cloud híbridos o deployments sobre Azure. No más hacks con msal, ni configuraciones imposibles para autenticar desde un contenedor.

Eso sí: el soporte completo para Linux y macOS está en camino. De momento, solo funciona en Windows. Así que si tu entorno de trabajo está en Docker sobre Alpine, o si eres de los que creen que conda es una religión, tendrás que esperar (o probar en WSL si no tienes miedo).

¿Qué no tiene todavía este driver de python?

Seamos justos: esto acaba de empezar. El driver está en su infancia, y aunque los cimientos son sólidos, todavía faltan cositas. No hay soporte para async (aunque está en el roadmap), tampoco integración directa con pandas o DataFrames (uff eso ya empieza a picar), carga masiva tipo bcp, pooling de conexiones configurable ni soporte multiplataforma completo.

Así que no tires pyodbc a la papelera todavía. Pero sí es momento de empezar a jugar con este nuevo driver y plantearse seriamente mover futuras integraciones hacia él.

¿Y el código? ¿Dónde está?

Todo el proyecto está en GitHub, bajo licencia MIT. Eso sí, las DLLs internas (las que hacen la magia de hablar con SQL Server) están cubiertas por licencia propietaria de Microsoft, aunque incluidas en el paquete.

El resto del driver puede auditarse, modificarse y contribuirse sin problemas. Y de hecho, Microsoft está activamente pidiendo feedback de la comunidad. Si detectas errores, incoherencias o tienes sugerencias, hay mecanismos claros de contribución y un bot de CLA que automatiza el papeleo.

Conclusión

Microsoft ha dado un paso importante (y muy necesario) con mssql-python. Por primera vez en años, tenemos un driver para Python específicamente diseñado para SQL Server, sin ODBC, sin complicaciones y con estándares modernos.

Aún está verde, sí. Pero si esto evoluciona como promete, podríamos estar ante el reemplazo natural de pyodbc en entornos Python. Con mejor experiencia, menos dependencias externas y soporte directo para autenticación empresarial, este driver tiene todos los ingredientes para convertirse en un estándar real.

La pelota está en el tejado de Microsoft. Ahora toca ver si cumplen lo que han empezado.

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

SQL Server bajo metodologías Agile: ¿Sprint o esguince?

Desde hace unos años, las palabras scrum, sprint y kanban se pasean por los pasillos del departamento de IT como si fueran las nuevas religiones del desarrollo. Todo es Agile. Todo es iterativo. Todo es colaborativo. Pero cuando uno trabaja con SQL Server, especialmente desde el lado de administración o desarrollo de bases de datos, la pregunta no es si Agile tiene sentido. La pregunta es si sobreviviremos al intento de aplicarlo.

Spoiler: se puede trabajar bien con Agile en entornos de SQL Server. Pero también se puede hacer tan mal que acabas con más deuda técnica que un país en default. Vamos a hablar de cómo aplicar principios Agile sin romper el modelo de datos, sin convertir cada sprint en un festival de migraciones mal versionadas, y sin sacrificar la estabilidad en nombre de una falsa “velocidad”.

¿Qué pinta una base de datos en un sprint Agile?

Uno de los grandes malentendidos cuando se mete a SQL Server dentro de un equipo Agile es asumir que los cambios en base de datos son iguales que tocar código. Spoiler: no lo son. El código es fácil de versionar, reversible y aislado. La base de datos es persistente, compartida y en producción suele ser más vieja que muchos de los devs que la usan.

A pesar de eso, en muchos equipos se nos pide trabajar “por historias”, entregar cambios “al final de cada sprint” y hacer despliegues “continuos”. ¿Y qué podría salir mal cuando cada dos semanas hay que versionar un esquema que afecta a 7 aplicaciones, 3 procesos ETL y un cubo de SSAS?

Por eso, el primer paso para aplicar Agile en SQL Server es entender que no somos iguales. No somos un microservicio. No podemos borrar y volver a compilar la base de datos en cada commit. Tenemos otra naturaleza y, por tanto, otras prácticas.

La trampa de las historias de usuario para bases de datos

Otra joya del enfoque Agile mal entendido: escribir historias de usuario para tareas de base de datos. “Como usuario quiero que el sistema guarde más información sobre los pedidos”. Y con eso se supone que debemos deducir que toca añadir 4 columnas, migrar millones de registros históricos, modificar 5 procedimientos almacenados y rezar para que el index seek sobreviva. Todo eso en 3 días.

En SQL, una historia mal escrita puede implicar semanas de refactor. O peor aún, puede parecer sencilla hasta que en QA revientan los tiempos de respuesta por culpa de una tabla sin estadísticas actualizadas.

¿Queremos usar historias de usuario? Perfecto. Pero que estén escritas por alguien que entienda el impacto en la base de datos. Y si no lo saben, que pregunten. A tiempo.

CI/CD y versionado de bases de datos: entre la teoría y el desastre

Uno de los pilares del Agile moderno es el uso de pipelines de integración y entrega continua. Maravilloso concepto. En teoría, cada cambio va versionado, probado, y desplegado automáticamente. En la práctica, cuando metemos SQL Server en la ecuación, muchos pipelines acaban con más condicionales que un CASE mal diseñado.

La verdad es que versionar correctamente una base de datos requiere herramientas específicas. No vale con subir scripts sueltos a un repositorio. Hablamos de herramientas como Flyway, Redgate SQL Source Control o SSDT bien utilizado. Y no, tirar un CREATE OR ALTER al azar en cada commit no es CI/CD. Es suicidio asistido.

Lo que necesitamos es definir una estrategia clara:

¿Vamos a usar enfoque basado en estado (state-based) o en migraciones (migration-based)? ¿Qué herramientas usamos para validar los cambios? ¿Cómo se testea una migración antes de tocar producción? ¿Quién revisa los PRs de cambios en la base de datos? Si nadie puede responder a eso, entonces lo que tenemos no es Agile. Es una bomba de relojería.

¿Sprint o esguince?: ritmo sostenible vs parche continuo

La obsesión por cerrar historias en cada sprint lleva, muchas veces, a decisiones absurdas sobre el modelo de datos. Esquemas pensados “para salir del paso”, duplicación de columnas por no refactorizar a tiempo, cambios acumulativos que nadie documenta… Y claro, luego llegan los sprints de “deuda técnica”, que suenan muy bien pero rara vez se priorizan. Porque claro, refactorizar un varchar(1000) a varchar(255) no tiene glamour. Pero mantenerlo durante años, eso sí que duele.

Un equipo Agile que no entiende la evolución del modelo de datos acabará creando un monstruo. Cada sprint mete una columna. Nadie borra nada. Y cuando miras el esquema tres meses después, parece un museo de decisiones mal tomadas. Peor aún: decisiones que nadie recuerda por qué se tomaron.

Si queremos trabajar bien, hay que introducir prácticas de diseño evolutivo del esquema. Sí, eso también existe. Y sí, también requiere tests, control de versiones y una cultura de refactor continuo. Pero sobre todo requiere que alguien se haga responsable del estado de la base de datos. Porque si todo es de todos, ya sabemos cómo acaba: en el limbo del SELECT *.

Testing y QA Agile en bases de datos: ese gran olvidado

El testing en SQL Server no es opcional, pero tampoco es trivial. Y en metodologías Agile, donde todo debe estar probado y listo para producción cada dos semanas, esto se convierte en un reto constante.

¿Se hacen pruebas de rendimiento cuando se añaden índices? ¿Hay scripts de rollback para cada migración? ¿Los procedimientos almacenados se testean con entradas límite? ¿Tenemos pruebas automatizadas que validen integridad referencial y resultados esperados?

Si la respuesta es “no”, estamos corriendo cada sprint con los cordones desatados. Un paso en falso y nos vamos de cabeza. Agile no significa mover deprisa, significa moverse bien, con ciclos de mejora continua. Y eso implica pruebas, aunque a veces piquen más que el DBCC CHECKDB.

Comunicación y ownership: el verdadero Agile en SQL

Más allá de herramientas y pipelines, lo que más influye en el éxito de una metodología Agile aplicada a SQL Server es la comunicación. Si los DBA, desarrolladores y analistas no están en el mismo canal, cada cambio será una batalla campal.

El modelo Agile bien llevado implica ownership compartido: el esquema de la base de datos no es territorio sagrado del DBA, pero tampoco puede ser tocado por cualquiera que sepa escribir ALTER TABLE. Hay que definir reglas, establecer responsables y fomentar el trabajo conjunto. Si eso no existe, el resto es teatro.

Ah, y no olvidemos lo esencial: si un cambio en la base de datos requiere más esfuerzo que el resto del sprint, no es que el DBA sea lento. Es que la historia está mal dimensionada. O mal entendida. O ambas.

Conclusión

Agile no es una metodología mágica. No convierte scripts en código limpio, ni convierte un modelo relacional en un playground de experimentos. Lo que sí hace, si se aplica con cabeza, es fomentar ciclos de mejora, colaboración y visibilidad. Pero si se aplica mal, acaba siendo solo una excusa para pedir resultados imposibles en tiempos ridículos.

SQL Server puede trabajar perfectamente bajo Agile. Pero no como el resto del código. Necesita prácticas específicas, herramientas adecuadas, y sobre todo, respeto por su complejidad. Porque esto no es un sprint. Y desde luego, si no lo hacemos bien, acabaremos en esguince.

Y no, no hay daily stand-up que arregle una base de datos destrozada por sprints sin control. Solo rollback.

May

2025

SQL Server 2025: IA dentro del motor, T-SQL como interfaz para modelos, y SSMS 21

Por fin tenemos motivos sólidos para decir que esta versión no es otra iteración sin alma. SQL Server 2025 no se limita a una lista de mejoras de rendimiento, ni a tres nuevos tipos de índice que nadie usará hasta dentro de tres años. Aquí estamos ante un cambio de paradigma: el motor se vuelve semánticamente inteligente, el T-SQL habla con modelos de IA, y SSMS deja de vivir anclado en 2012. Todo esto sin que tengamos que reescribir la mitad de nuestra lógica de negocio. Milagro.

Buscando con IA, sin sacar los datos de la base

Hasta ahora, hacer vector search implicaba montar un servicio aparte, duplicar datos, sincronizar embeddings y cruzar los dedos para que todo estuviera alineado. Bien, pues eso se ha acabado. SQL Server 2025 incorpora búsqueda vectorial directamente en el motor, usando como base el algoritmo DiskANN (Disk Approximate Nearest Neighbor) para encontrar similitudes de forma eficiente.

Y no solo eso: el motor genera embeddings y fragmenta texto (chunking) como parte de T-SQL. Nada de pipelines raros ni servicios auxiliares. El motor habla semánticamente, y por fin podemos dejar de fingir que los LIKE ‘%palabra%’ son soluciones de búsqueda.

Imagina buscar documentos similares, tickets de soporte parecidos o patrones repetidos en logs… sin tener que montar un Frankenstein con Python, Redis y una esperanza. Aquí, directamente desde SQL Server.

T-SQL como orquestador de modelos

Otra joya que han metido: los modelos de IA se definen y consumen desde T-SQL, y se accede a ellos mediante REST. Esto permite conectar con Azure OpenAI, Azure AI Foundry, Ollama, HuggingFace o cualquier servicio que hable HTTP.

Pero la parte realmente interesante es que puedes probar distintos modelos sin cambiar el código T-SQL, simplemente apuntando a otro endpoint. Es decir: pruebas, evalúas, decides… y el código sigue funcionando como si nada. Esto convierte a SQL Server en un auténtico hub de orquestación para IA aplicada a los datos.

Sí, a esto lo han llamado “AI integration”, pero no es humo de marketing: esto es infraestructura real para desarrolladores y DBAs que no tienen tiempo para montar castillos de arena en cada nuevo proyecto.

RAG con sentido: integración nativa con LangChain y Semantic Kernel

Otra novedad clave: SQL Server 2025 incluye soporte nativo para patrones de RAG (Retrieval-Augmented Generation). Lo que antes requería montar conectores desde LangChain, ahora se hace con integración directa. Embeddings, índices vectoriales, chunking… todo desde el motor. LangChain y Semantic Kernel pueden consumir directamente los datos sin malabares.

Esto significa que puedes montar aplicaciones conversacionales, asistentes internos o flujos inteligentes que consulten tus datos empresariales sin tener que exportarlos a ninguna otra base. Tus datos siguen seguros, tu rendimiento también, y tu aplicación parece inteligente.

SSMS 21: Git, Copilot y 64 bits… y no es broma

SQL Server Management Studio 21 ha salido del túnel del tiempo. Basado en Visual Studio 2022, ahora es una aplicación nativa de 64 bits (ya era hora), con actualizaciones automáticas (gracias, por fin) y soporte directo para Git.

Y lo mejor: Copilot ya está integrado (en preview). Lo puedes instalar como workload adicional, y te ayuda a:

Escribir y corregir T-SQL con lenguaje natural.
Generar scripts de mantenimiento.
Explicar consultas y sugerir optimizaciones.
Administrar configuraciones complejas con algo de contexto real.

¿Sustituye a un DBA con criterio? Ni de lejos. Pero es una ayuda decente que, usada con cabeza, puede acelerar muchas tareas del día a día. O al menos, evitar que tengamos que explicar por enésima vez qué hace un LEFT JOIN.

Python, JSON y expresiones regulares: tres cosas que ya no dan vergüenza

Se ha anunciado también un nuevo driver Python open source, desde cero, eficiente, moderno y mantenido por Microsoft. Olvida los hacks sobre ODBC: esto es serio, y se instala con pip install.

Y sí, JSON ahora se soporta de forma nativa en T-SQL. Ya era hora. Por fin podemos trabajar con documentos sin castings ni funciones intermedias. Lo mismo con RegEx: expresiones regulares nativas, sin tener que invocar CLR ni enviar los datos a PowerShell.

Esto desbloquea muchos escenarios de enriquecimiento de datos, validación y transformación dinámica, sin salir del entorno SQL.

Change Event Streaming: eventos sin CDC (ni drama)

Una joya más: Change Event Streaming permite emitir eventos directamente desde el transaction log a Azure Event Hubs, sin usar CDC. Esto no solo reduce la sobrecarga de I/O, sino que habilita arquitecturas reactivas mucho más limpias.

Puedes montar sistemas en tiempo real, agentes inteligentes que reaccionan a eventos de negocio, y todo con trazabilidad real. Y sin romperte la cabeza con triggers que nadie quiere mantener.

Rendimiento, disponibilidad y seguridad: seguimos afinando el motor

SQL Server 2025 incluye más de 50 mejoras en el motor, muchas de ellas en HADR, Columnstore, y procesamiento inteligente. Entre ellas:

Optimized Locking con TID Locking y Lock After Qualification, para reducir consumo de memoria y minimizar bloqueos.
Query Store disponible en secundarios de solo lectura, algo que llevábamos pidiendo años.
Mejoras en Intelligent Query Processing que aportan rendimiento sin tocar el código (veremos si los milagros existen o no).
Compatibilidad total con Microsoft Entra ID, para usar identidades gestionadas de forma segura y sin líos.

Y sí, sigue siendo la base de datos más segura según NIST. Ya no hace falta decirlo, pero está bien recordarlo por si alguien pregunta.

Fabric y la analítica sin ETL (casi)

SQL Server 2025 soportará database mirroring en Microsoft Fabric, permitiendo que los datos operacionales estén disponibles para análisis en tiempo casi real sin mover una sola tabla. No es exactamente magia, pero se le parece. Un puente directo entre operaciones y analítica, sin romper nada.

Developer Edition Standard: pruebas con realismo

Una novedad muy práctica: nueva Developer Edition Standard, gratuita pero limitada a las capacidades de la edición Standard. Ideal para probar comportamientos y validar configuraciones sin necesidad de recurrir a hacks ni entornos de “prueba/producción camuflada”.

Conclusión

SQL Server 2025 no es un service pack disfrazado. Es un cambio real, tanto en cómo usamos el motor como en cómo lo extendemos. La IA no es un complemento, es parte del core. Y eso nos obliga a entenderla, usarla y evaluarla con el mismo rigor con el que optimizamos un índice o afinamos una transacción.

Copilot ayuda, pero no sustituye. Las búsquedas vectoriales abren un nuevo paradigma, pero siguen requiriendo estructura y lógica de negocio. Y SSMS 21… bueno, al menos ya no se siente como una aplicación de otra década.

¿Vamos a activar todo esto en producción mañana? No. ¿Vale la pena empezar a probarlo y adaptarse? Sin duda. Y si queréis ver ejemplos reales, scripts de prueba y escenarios que no salen en las demos de marketing, os espero por aquí. Como siempre, alguien tiene que hacer las pruebas que importan.

May

2025

Versiones de SQL Server en Amazon AWS

Cuando hablamos de SQL Server en AWS, lo primero que debemos hacer es dejar atrás esa idea ingenua de que “en la nube todo es más fácil”. No, no lo es. Solo es diferente, y en muchos casos, más complejo. Porque cuando mezclamos la gestión de SQL Server con la selva de servicios de AWS, las posibilidades se multiplican… junto con los puntos de fallo. Así que vamos a desgranar, con precisión quirúrgica y sin evangelismos nublados por el marketing, qué opciones reales tenemos cuando queremos desplegar SQL Server en Amazon Web Services.

SQL Server en AWS: más allá del “lift and shift”

Hay dos grandes formas de ejecutar SQL Server en AWS: usar máquinas virtuales (EC2) o servicios gestionados (principalmente RDS). Y sí, hay matices, capas y excepciones, pero si no entendemos esta dicotomía básica, mejor volvemos a estudiar para el examen de certificación.

En esencia, EC2 nos da el control total (y la responsabilidad completa). RDS nos quita dolores de cabeza, pero también libertad. ¿Queremos hacer magia negra con xp_cmdshell, afinar a mano el maxdop, o aplicar un Service Pack que aún no ha salido oficialmente? Entonces EC2. ¿Preferimos que AWS se encargue de los backups, los parches y la alta disponibilidad con solo marcar unas casillas? RDS es nuestro nuevo amigo.

Amazon AWS EC2 con SQL Server: libertad para vivir al límite

Al desplegar SQL Server en instancias EC2, estamos hablando de IaaS de libro. Tú eliges el sistema operativo (Windows, claro, porque hablamos de SQL Server), tú instalas SQL Server, tú configuras todo. También tú lo rompes y lo arreglas.

La ventaja evidente es que puedes usar cualquier edición de SQL Server: Express, Web, Standard o Enterprise. Puedes traer tu propia licencia (BYOL, Bring Your Own License) o usar las licencias incluidas en la AMI (Amazon Machine Image) oficial con licencia de pago por uso.

Esta opción brilla en entornos que necesitan configuraciones exóticas o donde el cumplimiento normativo exige control absoluto sobre el sistema. También en arquitecturas donde SQL Server no está solo, sino embebido en un sistema complejo que se despliega como un todo.

¿El coste? Altísimo si no controlamos los recursos. Sí, puedes tener una r6i.16xlarge para presumir, pero luego no te quejes cuando el informe mensual de AWS te haga llorar más que un RAISERROR con severidad 25.

Amazon AWS RDS para SQL Server: el camino del zen (limitado)

RDS (Relational Database Service) ofrece SQL Server como servicio gestionado. Lo eliges desde la consola, eliges la edición, el tamaño, las opciones de almacenamiento, y listo: tienes una instancia SQL Server “as a service”.

Aquí puedes elegir entre las ediciones Web, Standard y Enterprise. Express solo está disponible en RDS para desarrollo y pruebas muy básicas. Las versiones van desde SQL Server 2012 hasta 2022, aunque las más antiguas ya huelen a rancio y deberían estar fuera de toda conversación seria.

AWS se encarga del parcheo, los backups automáticos, la monitorización con CloudWatch, la alta disponibilidad con Multi-AZ, y hasta de restaurarte una base de datos si te la cargas (dentro del periodo de retención). Muy cómodo, sí. Pero el precio de esa comodidad es la limitación.

Por ejemplo, no puedes usar funciones como FILESTREAM, SQL Server Agent personalizado, CLR Unsafe, xp_cmdshell, ni muchos otros elementos avanzados. Tampoco puedes instalar software adicional en el sistema operativo ni afinar el motor a nivel de sistema. ¿Es suficiente para la mayoría de los casos de uso? Sí. ¿Es frustrante cuando necesitas hacer algo fuera del guión? También.

¿Qué ediciones están disponibles en AWS y cuándo usarlas?

Aquí es donde las diferencias entre EC2 y RDS se hacen más evidentes. En EC2 puedes instalar lo que quieras, como si estuvieras en tu CPD de toda la vida. RDS, en cambio, restringe la elección a ediciones licenciadas por AWS.

SQL Server Express: limitada hasta el absurdo. Solo útil en pruebas o en ese ERP vintage que aún cabe en 10 GB. Está disponible en EC2 y en RDS.
SQL Server Web Edition: solo para aplicaciones web y bajo ciertas condiciones. Más barata que Standard, pero con muchas limitaciones. Solo disponible en RDS si tu contrato lo permite.
SQL Server Standard: el caballo de batalla. Lo suficientemente potente para la mayoría de workloads OLTP, con soporte de hasta 128 GB de RAM y sin las florituras de Enterprise. Disponible tanto en EC2 como en RDS.
SQL Server Enterprise: para cuando ya no hablamos de bases de datos, sino de feudos de datos. Requiere justificar su coste, pero habilita funciones como Always On, compresión de datos, particionamiento, y el Query Store decente (no el recortado de Standard). También disponible en ambas opciones.

Versiones disponibles en AWS: sí, también hay letra pequeña

En RDS, las versiones disponibles van desde SQL Server 2012 hasta 2022 (según la región y el tipo de instancia). Pero no siempre están todas. Hay regiones donde 2022 aún no está disponible o donde ciertas ediciones se ofrecen solo en ciertas clases de instancias. Y no esperes instalar CUs al día siguiente de su publicación: AWS sigue su propio calendario de validación, lo cual está bien si valoramos la estabilidad… y menos bien si necesitamos esa CU concreta para resolver un bug que nos está friendo en producción.

En EC2, como tú te lo guisas, tú decides qué versión instalar. Pero no te olvides de los ciclos de soporte. Instalar SQL Server 2016 en 2025 es como llevar un Nokia 3310 a una reunión de arquitectura cloud: nostálgico, pero absurdo.

Y si hablamos de costes… prepara la cartera

Ni EC2 ni RDS son baratos si no se diseñan con cabeza. RDS tiene costes predecibles, pero no siempre bajos. EC2 puede salir caro si dejamos las instancias encendidas todo el mes sin monitorizar nada. Y el coste de las licencias es otra historia. SQL Server no es barato, y Amazon lo sabe.

En RDS pagamos licencia por hora. En EC2 podemos traer nuestras licencias con Software Assurance, lo cual puede ahorrar bastante en escenarios Enterprise. Pero si lo haces mal, puedes terminar pagando el doble por rendimiento inferior. La arquitectura importa, y mucho.

¿Y qué pasa con la alta disponibilidad en AWS?

En EC2, la alta disponibilidad te la montas tú: con Always On Availability Groups, con failover clustering, o con lo que prefieras… y se te ocurra mantener. En RDS, basta con activar la opción Multi-AZ y dejar que AWS haga el trabajo sucio. Pero no confundamos Multi-AZ con Always On: RDS usa su propio sistema de replicación bajo el capó, que no es transparente ni configurable.

Si necesitas un AG real con réplicas legibles, bienvenido a EC2. Y prepárate para montar la infraestructura necesaria: subredes, listeners, quórum, test de failover, etc. ¿Merece la pena? Depende de lo que estés dispuesto a sacrificar por la comodidad.

Te recomiendo ver la sesión de Francisco Amat sobre este tema para llevar tu alta disponibilidad al siguiente nivel.

Conclusión

No hay una única respuesta correcta a la pregunta “¿cómo desplegamos SQL Server en AWS?”. Hay decisiones técnicas, estratégicas y económicas que tomar. EC2 es más flexible, pero también más arriesgado. RDS es más cómodo, pero impone más restricciones.

La elección depende del tipo de carga, del nivel de control que necesitamos, de los costes que estamos dispuestos a asumir y, por supuesto, de cuántos fuegos queremos apagar a las tres de la madrugada.

Así que no, no es cuestión de levantar una base de datos “en la nube” y seguir con nuestra vida. Es cuestión de entender cada opción, sus límites y sus consecuencias. Porque en AWS, igual que en la vida, cada elección tiene su precio. Y a veces, ese precio se mide en IOPS… o en dignidad.

¿Quieres rendimiento extremo, fine-tuning y llorar en modo sysadmin? EC2. ¿Prefieres comodidad, escalabilidad rápida y vivir con algunas restricciones? RDS. Tú decides. Pero decide con conocimiento, no con fe ciega en el marketing cloud.

May

2025

¿Qué puede aportar ITIL a la administración de SQL Server?

Solo pronunciar la palabra ITIL en una reunión técnica ya provoca dos reacciones inmediatas: o la mirada perdida del que recuerda noches eternas rellenando formularios, o el entusiasmo contenido del que cree que un diagrama de flujo puede resolver cualquier crisis. Ni tanto, ni tan poco. ITIL no es el enemigo, pero tampoco es la salvación definitiva. Y en el mundo de SQL Server, si sabemos adaptar sus principios con criterio, puede marcar la diferencia entre sobrevivir y gestionar con cabeza.

Sí, ITIL nació en un entorno más orientado a servicios IT generales, con vocación de biblioteca pesada y burocracia estructurada. Pero entre tanta sigla y proceso hay ideas útiles, aplicables a nuestro día a día como DBAs. El truco está en no convertirlo en un ministerio de tickets que nadie entiende, sino en un marco de trabajo razonable que nos ayude a ser menos reactivos y más estratégicos.

Vamos a bajar ITIL al barro del SQL Server. Y a hacerlo sin perder el alma en el intento.

Incidencias, problemas en ITIL: el arte de no confundir las cosas

Una de las primeras cosas que ITIL pone sobre la mesa —y que en el mundo DBA muchas veces ignoramos por pereza o costumbre— es la diferencia entre una incidencia y un problema. Parece menor, pero no lo es.

Una incidencia es un evento que interrumpe un servicio o reduce su calidad. Ejemplo: el job de backups ha fallado esta noche. Salta alerta, lo reejecutamos, y listo. Un problema, en cambio, es la causa raíz de una o más incidencias. Si ese job falla cada martes a las 2:00 porque coincide con una tarea de antivirus que bloquea el acceso al disco, eso es un problema.

Y aquí viene la parte divertida: si tratamos cada incidencia como un caso aislado, nos convertimos en técnicos de soporte en bucle, reiniciando servicios y ejecutando scripts hasta la eternidad. Pero si aplicamos la gestión de problemas de ITIL con cabeza, empezamos a ver patrones, causas reales y soluciones permanentes.

En resumen: no todo lo que rompe un proceso requiere abrir un post-mortem. Pero tampoco todo lo que se resuelve fácil está realmente arreglado.

Gestión de cambios en ITIL: ni todos los cambios necesitan CAB ni todo vale en producción

¿Has hecho un cambio menor en una base de datos y se ha caído media aplicación? Bienvenido al club. La gestión de cambios de ITIL no es solo para empresas con equipos de 200 personas y reuniones semanales de CAB (Change Advisory Board) donde nadie sabe qué se está aprobando. También tiene su lugar en entornos más pequeños y técnicos, si la aplicamos con lógica.

La clave está en clasificar los cambios. Un cambio estándar (como añadir una columna no crítica en una tabla interna) no necesita tres aprobaciones y un PowerPoint. Pero un cambio significativo (como migrar índices a un nuevo filegroup, o modificar la lógica de un procedimiento que usan 40 aplicaciones) sí debe planificarse, testearse y validarse. No por gusto, sino porque sabemos lo que puede pasar si no lo hacemos.

¿Necesitamos herramientas carísimas para esto? No. Un control de versiones decente, documentación clara y una mínima validación con otro DBA ya marcan la diferencia. Lo que no se puede seguir haciendo es modificar objetos en producción directamente “porque era urgente”. ITIL no lo permite, y nuestra salud mental tampoco.

SLAs en ITIL: prometer menos, cumplir más

Uno de los capítulos más ignorados de ITIL en entornos de administración de bases de datos es el de los SLA. Y no por falta de interés, sino porque muchos creen que los SLAs son cosas que firman los proveedores con sus clientes, no algo que debamos aplicar en un equipo interno de IT. Error.

Tener acuerdos de nivel de servicio realistas nos permite dejar de correr detrás de expectativas imposibles. Si el SLA dice que las restauraciones completas deben estar disponibles en 1 hora y tú sabes que el backup de 1,2 TB tarda 3 horas en copiarse por red… tenemos un problema. Y no es técnico, es de expectativas mal gestionadas.

Definir SLAs internos para cosas como tiempos de recuperación, respuestas a tickets críticos o disponibilidad de entornos de desarrollo nos da aire. Y, sobre todo, nos da un marco para decir “esto no es un fallo nuestro, es un riesgo aceptado”.

Por cierto, si tu jefe quiere un SLA del 99,999% pero no quiere gastar en alta disponibilidad… enséñale el coste real del «cinco nueves» y deja que saque la calculadora.

Cómo aplicar ITIL sin acabar atrapado en una burocracia kafkiana

La gran crítica a ITIL (y no sin razón) es que si se aplica sin cabeza, se convierte en un monstruo de procesos que matan la agilidad. Pero se puede hacer de forma sensata.

Para la gestión de incidencias, basta con tener un sistema de seguimiento que no sea una libreta o el correo de soporte. Un sistema sencillo, con prioridad real (no todo es “crítico”), histórico y cierre con causa anotada. Un Excel bien estructurado ya es mejor que el caos.

Para la gestión de problemas, necesitamos tiempo y foco. Una revisión semanal o mensual de incidencias repetidas, análisis de tendencias y propuestas de mejora. Nada de reuniones eternas, sino una hora técnica bien aprovechada.

Y para la gestión de cambios, un flujo simple: idea → validación técnica → test → ejecución → revisión. Si podemos automatizar despliegues, mejor. Si no, al menos que haya trazabilidad. Lo importante es que nadie toque sin avisar ni se entere el lunes por los logs de errores.

¿Hay herramientas que nos ayuden?

La buena noticia es que muchas de estas prácticas pueden integrarse en herramientas que ya usamos: Azure DevOps, Jira, ServiceNow, incluso PowerShell con Git. No necesitas montar un ITSM completo si estás en un entorno más técnico o ágil, pero sí necesitas orden, visibilidad y un mínimo de formalidad.

ITIL no va de rellenar formularios absurdos. Va de saber qué pasa, por qué pasa y qué se está haciendo para evitar que vuelva a pasar. En SQL Server, eso se traduce en menos emergencias y más control. Y eso, amigos, se agradece.

Conclusión

ITIL no es una religión, ni una cárcel de procesos. Es una caja de herramientas. Usada con criterio, puede ayudarnos a distinguir entre apagar fuegos y rediseñar el sistema contra incendios.

Como DBAs, podemos ignorarla y seguir a salto de mata, o podemos aplicar sus principios sin convertirnos en burócratas. Si lo hacemos bien, el resultado es menos caos, menos sorpresas y más tiempo para lo que realmente importa: anticiparnos a los problemas antes de que sean noticias en la monitorización.

Y si encima podemos justificar nuestras decisiones con un marco reconocido, mejor que mejor. Aunque nunca llegues a decir que «sigues ITIL», si aplicas sus principios con cabeza, se va a notar. Y eso, en esta profesión, ya es mucho.

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.

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.

Cloud

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes