SQL Server

Aquí encontraras todos nuestros post relacionados con SQL Server desde cero hasta un nivel avanzado. Desde infraestructura hasta modelado de datos.

NULL, un dato especial que debemos saber tratar

Cuando hablamos de datos, uno de los conceptos más interesantes y a menudo malinterpretados es el tratamiento del valor NULL. Nosotros, como DBAs, debemos comprender en profundidad cómo manejar estos valores especiales para asegurar la integridad y eficiencia de nuestras bases de datos. En este artículo, quiero profundizar en cómo SQL Server y las bases de datos SQL de Azure tratan los valores nulos, sus implicaciones y las mejores prácticas para su gestión. Por último compararemos este comportamiento con otros sistemas de gestión de bases de datos (SGBD) como PostgreSQL, MySQL y Oracle.

¿Qué significa NULL?

En el estándar SQL, NULL representa un valor desconocido o no aplicable. A diferencia de otros lenguajes de programación o de fórmulas, NULL no es igual a cero ni a una cadena vacía, en resumen, es simplemente la ausencia de un valor. Esta distinción es crucial, debemos interiorizarla y no olvidarla jamás, hazle un hueco en tu cerebro junto al recuerdo del gol de Iniesta en el minuto 116 de la final del Mundial de Sudáfrica 2010. Y no digo esto porque si, este comportamiento afecta a la forma en que las consultas se construyen y ejecutan. En entornos como SQL Server y Azure SQL, manejar correctamente los valores nulos puede marcar la diferencia entre una base de datos coherente y una llena de inconsistencias.

Tratamiento del valor NULL en SQL Server y Azure SQL

Lo primero que debemos recordar es que NULL no representa ningún valor y como tal no se va a comportar como un valor típico. En SQL Server, cualquier comparación lógica con NULL (por ejemplo, =, <, >, etc.) dará como resultado otro NULL. Esto se debe a que, al ser un valor desconocido, no se puede determinar con certeza si es igual o diferente a otro valor. Tenemos que pensar en que a la lógica de verdadero o falso (sí o no) se le va a sumar una tercera posibilidad, desconocido. Desconocido no es ni verdadero ni falso, ni sí ni no. Por esta razón, debemos utilizar el operador IS NULL o IS NOT NULL para verificar su existencia.

Efectos de NULL en las consultas

Cuando escribimos consultas, el manejo de los nulos es crucial. Vamos a verlo con un ejemplo, supongamos que tenemos una tabla Empleados y queremos encontrar a los que no tienen un jefe asignado. Podriamos pensar que esta consulta va a funcionar:

Sin embargo, esta consulta no devolverá ningún resultado, porque JefeID = NULL siempre es falso. La consulta correcta es:

Funciones de manejo de NULL

Para poder salvar estas limitaciones SQL Server y Azure SQL ofrecen varias funciones para tratar los valores nulos de manera efectiva. Algunas de las más útiles incluyen:

ISNULL(): Esta función reemplaza NULL con un valor especificado. Por ejemplo, para mostrar «N/A» en lugar de NULL en un campo de teléfono, usaríamos:

COALESCE(): Hemos visto que ISNULL() es una función que acepta dos valores y devuelve el primero que no sea NULL. Coalesce es igual, pero acepta múltiples argumentos y devuelve el primero que no sea NULL. Esto es especialmente útil cuando trabajamos con varias columnas que podrían contener valores nulos:

Tratamiento de NULL en funciones agregadas

Las funciones agregadas como SUM(), AVG(), MAX(), y MIN() directamente ignoran los valores nulos en sus cálculos. Esto es importante para evitar resultados inesperados. Por ejemplo, si queremos calcular el salario promedio de nuestros empleados, SQL Server excluirá automáticamente los valores nulos de la columna y podremos hacer esta consulta simple sin miedo a errores o resultados inesperados:

Tratamiento de NULL en Dynamic Data Masking (DDM)

DDM nos permite enmascarar la información sensible de nuestra base de datos y, en ocasiones, la propia ausencia de información es sensible en sí. Sin embargo, y esto es algo mejorable a mi parecer, DDM no nos permite ocultar valores NULL sensibles en nuestras tablas. Es decir, DDM solo enmascara datos conocidos, mostrando un valor NULL real a los usuarios sin privilegios igual que a los que sí tienen permiso de desenmascarar.

Implicaciones de NULL en índices y claves

Al definir índices y claves, debemos tener en cuenta cómo los valores nulos afectan a estas estructuras. Por ejemplo, en SQL Server, un índice único permite múltiples valores nulos, lo cual puede ser útil pero también peligroso si no se entiende y maneja correctamente. Veamos ahora 

Claves Primarias

Las claves primarias (PK) no admiten valores nulos. Esto es lógico, una clave primaria debe identificar de manera única cada fila en una tabla, y un valor nulo, al ser desconocido, no puede cumplir con esta restricción de unicidad. Por lo tanto, al diseñar nuestras tablas, debemos asegurarnos de que las columnas definidas como clave primaria siempre contengan valores no nulos. Realmente, SQL Server hará esto por nosotros y solo nos dejará definir como campos clave de una PK aquellas columnas definidas como NOT NULL, es decir, que no admiten valores nulos. 

En el ejemplo anterior, EmpleadoID no puede contener valores nulos, garantizando así la unicidad y la identificabilidad de cada registro. Gracias a esa restricción podemos definir la columna como clave primaria.

Claves Foráneas

Las claves foráneas (FK), por el contrario, sí pueden admitir valores nulos. Un valor nulo en una clave foránea indica que no hay una relación con la tabla referenciada. Esto puede ser útil para representar situaciones donde una relación no es obligatoria. Por ejemplo, si un empleado no tiene un jefe designado, el campo JefeID puede ser NULL.

En este caso, JefeID puede ser nulo, lo que indica que un empleado no tiene jefe.

Mejores prácticas para manejar NULL

Para mantener la integridad y eficiencia de nuestras bases de datos, debemos seguir algunas mejores prácticas en el uso y control de nulos. Siempre que sea posible, definiremos valores por defecto en nuestras columnas para evitar NULL. Por ejemplo, en lugar de permitir NULL en una columna de estado, podríamos definir «Desconocido» como valor por defecto. Los valores por defecto son aquellos que se van a poner en nuestra base de datos cuando insertamos un registro y no especificamos manualmente otra cosa. Por ejemplo:

No solo los nulos pueden ser un problema, también es posible que un dato técnicamente válido no tenga sentido de negocio. Para estos casos podemos utilizar restricciones CHECK y NOT NULL para asegurarnos de que nuestras columnas contengan siempre valores válidos. Por ejemplo, la siguiente restricción se asegura de que el salario de un empleado siempre sea un número mayor que 0. Como hemos visto antes, esta restricción también invalidará los valores NULL de forma intrínseca.

Por último, debemos documentar claramente cuándo y por qué permitimos nulos en nuestras tablas y asegurarnos de que todos los desarrolladores sigan las mismas buenas prácticas a la hora de crear tablas.

Comparación con otros SGBD

Como este tema es importante vamos a ver el comportamiento de NULL cuando trabajamos con otros de los principales motores de base de datos presentes en el mercado.

  • PostgreSQL maneja los valores nulos de manera similar a SQL Server. Al igual que en SQL Server, las comparaciones directas con NULL siempre devuelven NULL, y se utilizan IS NULL y IS NOT NULL para verificar la existencia de valores NULL. PostgreSQL también soporta funciones como COALESCE() y NULLIF() para manejar NULL. Una diferencia notable es que PostgreSQL permite definir restricciones más avanzadas usando expresiones booleanas, lo que puede ser útil para controles más complejos sobre los valores NULL.
  • MySQL, el manejo de nulos es también bastante similar. Las comparaciones directas con NULL resultan en NULL, y se usan IS NULL y IS NOT NULL para las verificaciones. MySQL proporciona las funciones IFNULL() y COALESCE() para manejar valores NULL. Un aspecto distintivo de MySQL es que, en ciertos modos de SQL, puede comportarse de manera más laxa con los valores nulos en índices únicos, permitiendo múltiples entradas NULL, lo cual es similar a SQL Server.
  • Oracle maneja los nulos de manera muy coherente con el estándar SQL. Las comparaciones con NULL devuelven NULL, y se utilizan IS NULL y IS NOT NULL. Oracle también ofrece funciones como NVL() (que es equivalente a ISNULL() en SQL Server) y COALESCE(). Una característica única de Oracle es su uso de NULLS FIRST y NULLS LAST en las cláusulas ORDER BY, permitiendo un control más granular sobre el orden de los valores NULL en los resultados de las consultas.

Comparación con DAX

Ya hemos hablado de DAX (Data Analysis Expressions) en el blog. DAX es un lenguaje de fórmulas utilizado en Power BI, Analysis Services y Power Pivot para realizar cálculos y consultas de datos. DAX tiene su propia forma de manejar valores nulos, conocida como BLANK. En DAX, el equivalente de NULL es BLANK. El manejo de valores BLANK en DAX difiere de los NULL en SQL en varios aspectos clave

Comparaciones

En DAX, una comparación directa con BLANK no devuelve BLANK. En lugar de eso, BLANK es tratado como 0 (cero) en comparaciones numéricas y como una cadena vacía en comparaciones de texto. Por ejemplo:

Funciones de manejo de BLANK

DAX proporciona varias funciones para manejar valores BLANK, incluyendo BLANK(), ISBLANK(), y COALESCE(). La función COALESCE() en DAX es similar a su homóloga en SQL, devolviendo el primer valor que no sea BLANK.

Impacto en cálculos agregados

Las funciones agregadas en DAX, como SUM(), AVERAGE(), MAX(), y MIN(), manejan los valores BLANK de manera similar a SQL, ignorándolos en los cálculos. Sin embargo, es importante saber que en DAX, un BLANK en una medida puede tener implicaciones diferentes dependiendo del contexto del cálculo. Supongamos que tenemos una tabla de ventas en Power BI y queremos calcular el total de ventas, tratando los valores nulos en la columna Cantidad como ceros:

En este ejemplo, la función SUMX recorre cada fila en la tabla Ventas y utiliza COALESCE para tratar los valores BLANK en la columna Cantidad como 0.

Diferencias clave DAX vs SQL

Como hemos visto el tratamiento de los valores nulos en DAX difiere del de SQL. Podríamos resumir las diferencias así:

  • Manejo en comparaciones: Mientras que en SQL, NULL no se puede comparar directamente y cualquier comparación devuelve NULL, en DAX el valor BLANK se trata como 0 o una cadena vacía, dependiendo del contexto.
  • Funciones específicas: DAX tiene funciones específicas para trabajar con BLANK, y estas funciones son esenciales para manejar datos en contextos de análisis y cálculos complejos.
  • Contexto de cálculo: En DAX, el contexto de cálculo puede afectar cómo se manejan los valores BLANK, especialmente en modelos de datos complejos donde se utilizan múltiples tablas y relaciones.

Conclusión

El manejo de valores nulos es una característica fundamental  cuando trabajamos con datos, ya sea en SQL Server, Azure SQL, otros SGBD como PostgreSQL, MySQL y Oracle o con herramientas de BI como Power BI. Aunque las diferencias en el comportamiento son sutiles, cada SGBD ofrece herramientas y funciones específicas para tratar con valores NULL de manera eficiente. 

Comprender estas diferencias y mejores prácticas es imprescindible para diseñar y gestionar nuestras bases de datos de manera más efectiva, asegurando la integridad y eficiencia de nuestros sistemas. 

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!

Publicado por Roberto Carrancio en Cloud, Power BI, SQL Server, 0 comentarios

Servidores SQL administrándose solos con políticas

Amigo DBA, vete de vacaciones tranquilo. Crea políticas (directivas) para que tus servidores SQL Server se administren por si solos. En este video te muestro las políticas que yo tengo en mis servidores y como crear las tuyas personalizadas.

Gracias a las políticas de SQL Server vamos a poder exigir el cumplimiento de las directivas que nosotros definamos para que todo siga funcionando como debería en nuestra ausencia. Podremos elegir entre evaluar cada una de las políticas a petición o bajo demanda y su comportamiento, por ejemplo, si van a dejar un log o a prevenir el cambio directamente.

Una vez creadas tus políticas podrás exportarlas e importarlas en el resto de tus servidores para no tener que repetir el trabajo. Esto último te lo muestro en el artículo de la semana pasada que puedes encontrar aquí. No esperes más y toma el control de tus servidores. Usa estas políticas para mantener la coherencia en tus esquemas, asegurar el cumplimiento de normativas internas o automatizar tus tareas.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si quieres ver más videos como este puedes encontrarlos todos aquí. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, Videos, 0 comentarios

Políticas de SQL. Creando servidores Autoadministrados

Una de las mejores características de un buen profesional es que siempre busca formas de hacer su trabajo más eficiente y efectivo. Los administradores de base de datos no estamos exentos de esta norma y, una de las herramientas que tenemos a nuestra disposición para lograr esto es el uso de políticas en SQL Server. Si no habías oído hablar antes de esto no te preocupes, es una opción de SQL Server a menudo subestimada pero al final de este artículo vas a poder ver su gran potencial. Durante las próximas líneas explicaremos cómo las políticas pueden facilitarnos la vida a la hora de gestionar nuestras bases de datos, garantizando tanto el cumplimiento de normas como la eficiencia y el buen rendimiento.

Imaginemos un escenario donde gestionamos múltiples instancias de SQL Server, cada una con sus propias configuraciones, niveles de seguridad y requisitos de rendimiento. No es dificil verdad, es nuestro pan de cada día. Sabrás entonces que mantener la coherencia y el cumplimiento normativo en un entorno así puede ser una tarea exigente. Pues bien, aquí es donde las políticas de administración de SQL Server entran en juego y nos permiten definir, aplicar y automatizar reglas y directrices de una manera estructurada y eficiente.

¿Qué son las Políticas en SQL Server?

Las políticas en SQL Server son un componente del Policy-Based Management (PBM), introducido por primera vez en SQL Server 2008. Esta funcionalidad nos permite definir reglas y condiciones para nuestros servidores y bases de datos, asegurando que cumplan con ciertos estándares de configuración y rendimiento. En términos simples, una política es un conjunto de reglas que se aplican a los objetos de SQL Server para garantizar que se comporten de una manera específica. Estas reglas pueden abarcar desde la configuración del servidor hasta el diseño de la base de datos, y pueden ayudarnos a mantener un alto nivel de calidad y consistencia en nuestras bases de datos.

Por ejemplo, podríamos crear una política que fuerce a que todas las tablas tengan una PK (clave primaria). Esta política se aplicaría a todas las bases de datos en el servidor, y cualquier usuario intente crear una tabla sin PK recibiría un bonito error.

Otra política común es obligar a que todas las bases de datos tengan copias de seguridad regulares. Esta política la podremos configurar para verificar que se haya realizado un backup en las últimas 24 horas, y si no es así, que genere una alerta (que nos envía un correo) para que nosotros como administradores de la base de datos tomemos medidas.

Las políticas también nos pueden ser útiles para mantener la seguridad de nuestras bases de datos. Podríamos tener una política que fuerce a que todas las conexiones al servidor se realicen a través de una conexión segura, o que todas las contraseñas cumplan con ciertos requisitos de complejidad

Componentes Clave de una Política

Antes de ver cómo tenemos que hacer para crear una política personalizada tenemos que tener claros una serie de conceptos que vamos a necesitar. En concreto vamos a estar trabajando con condiciones, facetas y modos de evaluación además de las propias políticas. Veamos que son cada uno de ellos.

  • Condición (Condition): Una condición es un conjunto de expresiones que definen un estado deseado o un comportamiento que queremos comprobar. Por ejemplo, podríamos tener una condición que verifique si la recuperación de base de datos está configurada como «FULL».
  • Facetas (Facets): Las facetas son conjuntos predefinidos de propiedades de los objetos de SQL Server. Por ejemplo, hay facetas para bases de datos, servidores, procedimientos almacenados, entre otros. Cada faceta contiene varias propiedades que podemos utilizar en nuestras condiciones.
  • Política (Policy): Una política combina una condición con una faceta y define cómo y cuándo se debe evaluar esta combinación. Las políticas pueden ser evaluadas bajo demanda, de forma programada o en respuesta a eventos específicos.
  • Modo de Evaluación (Evaluation Mode): Este define cuándo y cómo se evaluará una política. Existen varios modos, incluyendo «On Demand», «On Schedule», «On Change – Prevent» y «On Change – Log Only».

Creando y Administrando Políticas

Para implementar políticas en SQL Server, utilizamos la característica de Administración Basada en Políticas (PBM, por sus siglas en inglés). Como ya hemos visto, PBM nos permite definir políticas, verificar su cumplimiento y aplicarlas automáticamente. Lo primero que deberemos hacer es definir una condición. Una vez que hayamos definido una condición, ya podremos crear una política que utilice esa condición. Por último definiremos su modo de evaluación.

Paso 1: Definir una Condición

El primer paso para crear una política es definir una condición. Supongamos que queremos asegurarnos de que todas nuestras bases de datos estén en modo de recuperación FULL. Para ello, primero definimos una condición:

Abrimos SQL Server Management Studio (SSMS) y navegamos hasta «Management» -> «Policy Management». Hacemos clic derecho en «Conditions» y seleccionamos «New Condition». Le damos un nombre a nuestra condición, por ejemplo, «Database Recovery Full». En «Facet», seleccionamos «Database». En «Expression», añadimos una nueva condición: @RecoveryModel = ‘FULL’.

Paso 2: Crear la Política

Con la condición definida, procedemos a crear la política que la usará:

Hacemos clic derecho en «Policies» y seleccionamos «New Policy». Le damos un nombre, como «Ensure Full Recovery Mode». Asignamos la condición «Database Recovery Full» que creamos anteriormente. En «Against Targets», especificamos los objetos a los que se aplicará esta política, en este caso, todas las bases de datos. Elegimos el modo de evaluación. Para este ejemplo, seleccionamos «On Change – Log Only» para registrar cualquier incumplimiento sin impedir cambios.

Paso 3: Evaluar y Aplicar la Política

Una vez creada la política, podemos evaluarla inmediatamente:

Hacemos clic derecho en la política y seleccionamos «Evaluate». SQL Server nos mostrará todas las bases de datos que no cumplen con la política. Podemos tomar acciones correctivas directamente desde el cuadro de diálogo de evaluación si es necesario.

Paso Extra: Exporta tus políticas

Cuando ya tengas todas tus políticas creadas en uno de tus servidores, no es necesario que las recrees en el resto, simplemente podemos exportarlas y volverlas a importar en tantos servidores como queramos. Para ello solo tendremos que dar clic derecho sobre nuestra política y dar a exportar. Para importar haremos clic derecho sobre la carpeta políticas en nuestro SSMS y le daremos a importar política.

Beneficios del Uso de Políticas

Como venimos comentando, las políticas nos permiten estandarizar configuraciones y prácticas en todas nuestras instancias de SQL Server. De esta manera vamos a lograr asegurar el cumplimiento de normas corporativas y regulatorias. Esto es especialmente importante en entornos que deben cumplir estándares y leyes como GDPR, HIPAA o SOX.

Además, al definir políticas que se evalúan automáticamente, podemos reducir nuestra carga de trabajo y minimizar el riesgo de errores humanos. Por ejemplo, podemos programar evaluaciones periódicas para asegurar que todas nuestras configuraciones de seguridad y rendimiento se mantengan conforme a las políticas definidas.

Pero esto no es todo, las políticas también nos ayudan a identificar y corregir problemas potenciales antes de que se conviertan en problemas mayores. Al tener visibilidad continua de cómo se comportan nuestros servidores y bases de datos en relación con nuestras políticas, podemos ser proactivos en la gestión y el mantenimiento.

Conclusión

El uso de políticas para administrar SQL Server es una práctica que nos permite mantener el control y la coherencia en nuestros entornos de bases de datos. Al definir y aplicar políticas claras, podemos asegurar el cumplimiento normativo, automatizar tareas administrativas y mantener un alto nivel de rendimiento y seguridad. En resumen, las políticas no solo simplifican la administración de SQL Server, sino que también nos permiten ser más eficientes en nuestro trabajo como DBAs. Así que, no esperes más. Pruébalo y considera aprovechar el poder de las políticas para facilitarte la vida.

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!

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario

SQL Ledger en video

Ya hablamos en este blog de la funcionalidad Ledger o Libro de Contabilidad de las bases de datos SQL aquí. Por eso, hoy he decidido dedicarle un vídeo para que podáis verlo en acción y comprobar como de útil puede ser para vosotros.

La función ledger o «libro de contabilidad» en SQL Server y Azure SQL registra operaciones de datos, incluyendo detalles del usuario, fecha, hora y tipo de operación. Cada registro está enlazado criptográficamente al anterior, creando una cadena inalterable. Cada registro tiene una firma digital, lo que previene modificaciones sin rastro. Esto permite auditar y verificar la historia de los datos, detectar manipulaciones y cumplir con normativas de seguridad. En Azure SQL, se ofrece un servicio adicional, Azure SQL Ledger, que añade una capa de seguridad almacenando los hashes del libro de contabilidad en un servicio externo basado en blockchain. Esto lo hace especialmente útil en entornos donde, por su criticidad, tenemos que llevar un control exhaustivo de los cambios realizados en los datos.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si quieres ver más videos como este puedes encontrarlos todos aquí. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, SQL Server, Videos, 0 comentarios

DB_CHAINING: Una configuración de seguridad peligrosa

Continuamos con el tema del pasado lunes donde hablábamos de la configuración trustworthy de SQL Server. Una configuración de seguridad con unos riesgos de seguridad añadidos que es muy importante que conozcamos. Como os decía antes de irme por las ramas, hoy continuamos con ese tema y es el turno de la opción de configuración db_chaining, una configuración también de seguridad que nos va a permitir simplificar mucho los permisos, no sin riesgos claro. Quédate hasta el final que te voy a contar todos los secretos.

¿Qué es DB_Chaining?

DB_Chaining es una opción de configuración en SQL Server que, cuando está habilitada, permite a los objetos de una base de datos acceder a los objetos de otra base de datos que tienen el mismo propietario. Esto puede ser útil en situaciones donde las bases de datos necesitan compartir información, pero también plantea ciertos riesgos de seguridad que deben ser considerados cuidadosamente.

Normalmente, si un usuario tiene permiso para ejecutar un procedimiento almacenado, y ese procedimiento tiene referencias a otros objetos en la base de datos, el usuario necesita tener permisos para esos objetos también. Esto es el comportamiento por defecto de SQL Server y las bases de datos de Azure SQL ya que db_chaining por defecto está deshabilitado. Sin embargo, cuando DB_Chaining está habilitado, SQL Server trata las cadenas de propiedad de los objetos de la base de datos de manera diferente.Si el procedimiento almacenado y el objeto al que hace referencia tienen el mismo propietario, SQL Server permite que el procedimiento acceda al objeto sin comprobar los permisos del usuario para ese objeto.

db_chaining

Esto que acabamos de ver puede ser útil en situaciones donde se desea simplificar la administración de permisos. Por ejemplo, si tienes varias bases de datos que necesitan compartir información, puedes tener procedimientos almacenados en una base de datos que leen o escriben en tablas en otra base de datos. Sin DB_Chaining, tendrías que dar a los usuarios permisos para las tablas en ambas bases de datos. Con DB_Chaining, puedes dar a los usuarios permisos para ejecutar los procedimientos almacenados, y los procedimientos pueden acceder a las tablas sin que los usuarios tengan permisos directos para ellas. 

Consideraciones de Seguridad

Aunque DB_Chaining puede ser útil, también plantea riesgos de seguridad. Cuando DB_Chaining está habilitado, un usuario que tiene permiso para ejecutar un procedimiento almacenado puede potencialmente acceder a cualquier objeto en la base de datos que tenga el mismo propietario que el procedimiento. Si no se gestiona correctamente, esto podría permitir a los usuarios acceder a información a la que no deberían tener acceso.

Por lo tanto, antes de habilitar DB_Chaining, es importante entender completamente sus implicaciones de seguridad y asegurarse de que todas las bases de datos y objetos estén correctamente asegurados. Además, y esto es recomendación personal más que buenas prácticas, no os recomiendo habilitarlo para bases de datos donde los usuarios tengan permisos de control (para crear modificar los objetos) ya que podrían crear una vista para leer datos que no deberían o, peor aún, un procedimiento almacenado para editar los datos.

Conclusión

La configuración de DB_Chaining en SQL Server es una herramienta poderosa que puede simplificar la administración de permisos y facilitar el intercambio de información entre bases de datos. Sin embargo, también plantea riesgos de seguridad que deben ser cuidadosamente considerados y gestionados. Como siempre, la clave para usar DB_Chaining de manera efectiva y segura es entender completamente cómo funciona y seguir las mejores prácticas de seguridad de la información.

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!

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario

MERGE: Una instrucción para dominar a todas (T-SQL Avanzado)

Hoy os he creado un video tutorial detallado sobre cómo usar la función MERGE en T-SQL. He intentado que el video sea una buena herramienta tanto para los principiantes que buscáis entender los fundamentos de MERGE, como para profesionales de SQL que deseen refrescar sus conocimientos.

En este video, desgloso los conceptos fundamentales de la función MERGE y te muestro cómo puedes utilizarla para combinar datos de dos tablas en SQL Server. Aprenderás a realizar operaciones de inserción, actualización y eliminación en una sola instrucción, lo que te permitirá manejar tus datos de manera más eficiente.

Merge

Casos de uso de MERGE

Además de enseñarte cómo usar MERGE, déjame contarte algunos escenarios comunes en los que la función MERGE puede serte especialmente útil. Principalmente la vas a usar para sincronización de tablas (como hemos visto en el video), actualización de datos basada en condiciones específicas o la combinación de datos de múltiples fuentes. Al entender estos casos de uso, podrás ver el verdadero poder de MERGE y cómo puede facilitar tu trabajo con SQL Server con un código más limpio y más eficiente.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si quieres ver más videos como este puedes encontrarlos todos aquí. 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 al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, Videos, 1 comentario

TRUSTWORTHY: La opción que no debes habilitar

Como DBAs de SQL Server tenemos que ser verdaderos expertos en las configuraciones de las bases y datos y comprender a la perfección todas las implicaciones de cada una de estas opciones configurables. Una de las opciones con las que más cuidado hay que tener es la propiedad TRUSTWORTHY (confiable en nuestro idioma). Si lleváis tiempo en esto de la administración de bases de datos es probable que en varias ocasiones os hayáis visto envueltos en debates sobre el uso de esta opción. Trustworthy es una configuración de la base de datos que afecta directamente a la seguridad, sobre todo en lo que a ejecución de código se refiere. Su configuración es clave en el comportamiento de todos los objetos de base de datos que se ejecuten con “WITH EXECUTE AS” y en los componentes CLR marcados como EXTERNAL_ACCESS o UNSAFE.

¿Para qué sirve Trustworthy?

Ahora que ya sabemos que trustworthy es una configuración de base de datos vamos a ver qué es lo que hace. Cuando habilitamos esta configuración (por defecto está deshabilitada) lo que estamos haciendo es decirle a SQL Server que confíe en los objetos de esa base de datos en lo que a seguridad (autenticación y autorización) se refiere. Como hemos visto, esto afecta a los objetos (funciones y procedimientos) que usan EXECUTE AS y a los módulos CLR. Veamos uno a uno estos casos.

Objetos con EXECUTE AS

Cuando trustworthy está habilitado, los módulos T-SQL que usen la opción execute as podrán ejecutarse impersonándose con cualquier otro usuario. Si estos otros usuarios tienen asociado un login con permisos elevados o con usuarios con permisos sobre otras bases de datos vamos a poder acceder a todas las funcionalidades que tendría ese login.

Por ejemplo, imaginad que tenemos dos bases de datos: ventas y contabilidad. Tenemos tres usuarios: vendedor, contable y gerente. Supongamos que el usuario vendedor tiene sólo acceso a ventas, el usuario contable tiene sólo acceso a contabilidad y el usuario gerente tiene acceso a las dos bases de datos. Gracias a tener la propiedad trustworthy habilitada el usuario vendedor va a poder actuar bajo el contexto de seguridad del usuario Gerente y así acceder a datos de contabilidad con sus mismos permisos. Lo mismo para el usuario contable en la otra base de datos.

Módulos CLR

Para las integraciones de CLR (Common Language Runtime) la propiedad trustworthy va a permitir ejecutar ensamblados marcados como EXTERNAL ACCESS o UNSAFE y, gracias a ello, acceder a recursos externos del sistema o de la red que de otra manera no estarían permitidos en este contexto de seguridad.

El peligro de trustworthy

Ahora es cuando viene la historia de terror. Tener trustworthy habilitado en nuestra base de datos puede ser un vector para una escalada de privilegios. Os lo voy a demostrar. Para esta demo vamos a crear una base de datos llamada TrustyDB y vamos a habilitar la opción trustworthy. Vamos a crear un login llamado LoginTrusty. Después pondremos como propietario de nuestra base de datos al usuario “sa”, esto es una buena práctica. Por último vamos a crear un usuario UsurioTrusty para nuestro LoginTrusty y darle permisos de db_owner sobre la base de datos.

En este momento nuestro login tiene un usuario con permisos de db_owner sobre la base de datos pero no tiene permisos elevados a nivel de servidor. Tampoco es el propietario de la base de datos. Sin embargo, gracias a la propiedad trustworthy va a poder crear un procedimiento almacenado que se ejecute bajo el contexto de seguridad del propietario de la base de datos (recordad que es el sa) y añadirse al rol de servidor sysadmin.

Acabamos de ver un ejemplo en el que un usuario ha logrado escalar privilegios hasta convertirse en sysadmin. Este es uno de los problemas de habilitar trustworthy junto con el que ya habíamos comentado antes de acceder a datos de otras bases de datos sobre las que no tienes permisos. Otros problemas están relacionados con el uso de CLR ya que va a permitir acceder a información contenida en el sistema operativo (fuera del servidor de base de datos) o incluso de la red, interacciones que no estarían permitidas sin esta propiedad. La propiedad de trustworthy está pensada para eludir medidas de seguridad como la forma de módulos CLR o el uso de certificados para la elevación de privilegios controlada sobre todo en entornos de prueba o desarrollo. 

Buenas prácticas con Trustworthy

Como has podido ver, habilitar trustworthy conlleva un riesgo alto de seguridad por lo que la primera recomendación sería habilitarlo con precaución y sólo cuando sea imprescindible. Revisa muy bien los requisitos de cada escenario y determina si es o no necesario habilitarlo. Intenta una alternativa siempre que sea posible, por ejemplo para el caso de CLR la firma de código y uso de certificados te permitirá una gestión más segura de los permisos. Si no te queda más remedio que habilitar trustworthy refuerza tus controles de acceso, sigue una política de permisos mínimos para los usuarios y habilita auditorías para detectar cambios en los permisos y así como acceso a datos críticos.

Como activar Trustworthy

Realmente ya lo hemos visto en el ejemplo de arriba, podemos activar la propiedad trustworthy en las bases de datos que necesitemos con el siguiente código:

Una cosa importante que debemos tener muy en cuenta es que esta propiedad no solo está desactivada por defecto para todas las bases de datos sino que SQL Server no puede confiar en una base de datos nueva por defecto. Por este motivo, aunque tengamos la propiedad habilitada siempre que restauremos la base de datos desde un backup o separemos y adjuntemos (detach y attach) la base de datos con trustworthy habilitado esta propiedad va a estar deshabilitada y tendremos que ser nosotros quien la habilite manualmente. Esto va a pasar, sea el mismo servidor o uno distinto.

Conclusión

En resumen, habilitar la configuración de trustworthy puede ser indispensable para algunas funcionalidades de nuestro proyecto, pero si no es nuestro caso debemos evitar su uso para evitar riesgos de seguridad innecesarios. Ahora que ya comprendes su funcionamiento y los riesgos de habilitarlo seguro que te lo vas a pensar dos veces antes de concederles esa petición al usuario que te pide habilitarlo. Si no te queda más remedio recuerda las buenas prácticas y las precauciones que hemos visto en este artículo.

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!

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario