ciberseguridad

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.

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!

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.

Abr

2025

Técnicas de Recuperación ante Desastres (DR) en Always On (AG)

Cuando hablamos de alta disponibilidad en SQL Server, hay un elefante en la sala que muchos prefieren ignorar: la recuperación ante desastres (DR) no es lo mismo que la alta disponibilidad. Y sí, podemos tener un Always On Availability Group en producción, funcionando como un reloj suizo, con réplicas síncronas, listeners con balanceadores bonitos y monitorización con colores llamativos y alertas inmediatas… pero si mañana se prende fuego el CPD o se rompe el clúster de Windows, más nos vale tener algo más que buenas intenciones.

Always On no evita el 100% de los desastres

Empecemos por desmontar un mito recurrente: “Tengo Always On, no necesito backups”. Esta frase existe. La hemos oído. Nos ha dolido. Tener un Availability Group distribuido con tres réplicas no es un sustituto de una estrategia de backup coherente. Es como decir que no hace falta cinturón de seguridad porque llevas airbag. A nivel técnico, los AG están pensados para disponibilidad, no para recuperación. Y desde luego, no protegen contra errores humanos, corrupción lógica ni DROP DATABASE ejecutados por ese usuario avanzado al que le dieron permisos “para que pueda trabajar tranquilo”.

Así que, antes de emocionarnos con réplicas distribuidas y latencias internacionales, empecemos con lo básico.

Los backups si nos salvan ante desastres

Los backups siguen siendo la base de cualquier estrategia de recuperación ante desastres, incluso (y especialmente) cuando usamos Always On. No hay excusa. Y sí, sabemos que hay quien piensa que como tiene tres réplicas en tres regiones, puede dormir tranquilo. Hasta que se borra un dato en la base de datos primaria, y esa operación se replica con precisión quirúrgica a las secundarias. Una especie de ransomware lento y sin rescate.

En un entorno con AG, es fundamental tener claro dónde y cómo hacemos los backups. Idealmente, deberíamos delegar las copias a las réplicas secundarias para liberar carga de la primaria. SQL Server lo permite desde hace varias versiones, y con una correcta configuración de las preferencias de backup, podemos establecer qué réplica se encargará de cada tipo de backup: full, log o copy-only.

Pero cuidado, porque no todas las réplicas valen para todo. Las copias completas deben realizarse en una réplica con acceso legible a la base de datos, y los logs solo en réplicas sincronizadas que reciban todas las transacciones. Además, asegúrate de que el software de backup (si usas uno) es compatible con AG y respeta las preferencias de backup configuradas en el clúster. Hay soluciones “enterprise” que, sorprendentemente, no lo hacen.

Y por si acaso recuerda: sí, seguimos necesitando restaurar las copias de vez en cuando para comprobar que funcionan. Testear la restauración no es una opción, es parte del proceso. ¿Tienes backups diarios? Genial. ¿Los has restaurado alguna vez? Porque si no lo has hecho, lo que tienes son archivos que ocupan espacio, no un plan de recuperación.

AG distribuidos: la aspiración de los ya experimentados en desastres

Si nos tomamos en serio la continuidad de negocio, y el presupuesto lo permite, debemos hablar de Availability Groups distribuidos. Esto no es simplemente una extensión de AGs tradicionales, sino una arquitectura pensada para verdaderas estrategias de recuperación ante desastres geográficamente dispersas. Aquí no estamos hablando de movernos de Madrid a Barcelona, sino de poder perder el centro de datos entero en Frankfurt y que el negocio siga operando desde Dublín sin sudar tinta.

Un AG distribuido se compone de dos (o más) AG independientes que se sincronizan entre sí mediante un listener y una réplica que actúa como puente. Esto implica una configuración más compleja, pero aporta una flexibilidad enorme. Cada lado del AG distribuido puede tener su propio clúster de Windows, su propio quorum, su propia lógica de failover, y no dependen directamente del otro para estar operativos. Es decir, si se rompe todo el AG primario, el secundario puede levantar cabeza por sí mismo, sin necesidad de consultar a nadie. Autonomía total, como un buen DBA cansado de justificarle al jefe por qué no es culpa suya.

Pero no es magia ni es todo tan bonito. Los AG distribuidos no hacen failover automático. Necesitan intervención manual o scripts muy bien preparados, monitorizados y probados. Y además, la sincronización es asíncrona, por lo que hablamos de cierta pérdida de datos en caso de desastre. Aceptarlo o no dependerá del negocio y de su tolerancia al RPO.

Consideraciones adicionales: DR de verdad

¿Todo configurado, AG distribuido listo, backups funcionando? Perfecto. Ahora hablemos de lo que realmente se rompe cuando todo lo demás funciona: la red y el DNS. Porque puedes tener la mejor estrategia del mundo, pero si el listener de SQL no resuelve correctamente en la región de DR, o si el firewall bloquea el puerto de sincronización, todo tu diseño se convierte en una bonita maqueta de PowerPoint.

La recuperación ante desastres es un proceso que debe contemplar todos los componentes, y eso incluye:

Que los clientes puedan conectarse automáticamente al entorno de DR sin intervención manual (o con la mínima posible).
Que los certificados estén correctamente instalados en todos los nodos si estamos usando encriptación.
Que los endpoints estén accesibles, los firewalls configurados y los balanceadores preparados para redirigir tráfico.
Que el almacenamiento de backups esté accesible desde ambos lados del AG (o, al menos, replicado adecuadamente).
Y más cosas específicas de tu arquitectura que solo tu sabes…

Un test de DR que no valida los nombres DNS, las ACL de red y la resolución de nombres es como una auditoría de seguridad en la que solo se revisan los colores del logo.

Automatización: scripts o muerte

La recuperación ante desastres no debería depender del pulso de una persona que lleva 20 horas despierto. Por eso, automatizar el proceso de failover y recuperación es obligatorio. No deseable. No recomendable. Obligatorio. Y no, no hablo de automatización genérica. Hablo de scripts personalizados para tu entorno, que validen el estado de las réplicas, que ejecuten el ALTER AVAILABILITY GROUP … FAILOVER cuando toque, y que actualicen rutas, registros DNS o configuraciones post-failover si es necesario.

¿Y la documentación? Sí, también es importante. Porque cuando suena el teléfono a las 4 de la mañana, necesitas saber qué hacer y no improvisar con algo que has visto en Stack Overflow o con lo que te ha dicho Chat GPT.

Conclusión

Always On es una herramienta potentísima para mantener la disponibilidad de nuestras bases de datos, pero no sustituye una estrategia de recuperación ante desastres (DR) bien pensada, bien ejecutada y bien documentada. Los backups siguen siendo sagrados. Los AG distribuidos son una bendición si se usan bien. Y los entornos sin pruebas de restauración o sin scripts de failover son simplemente apuestas disfrazadas de arquitectura.

Que un sistema esté “disponible” no significa que esté “protegido”. Y si no lo tenemos claro antes de la caída, lo aprenderemos después. Y no será barato.

¿Recomendación final? Probemos los escenarios de desastre antes de que lo sean. Porque el caos no avisa, pero nosotros sí podemos estar preparados.

Abr

2025

Usar siempre dbo en SQL Server: ventajas, riesgos y buenas prácticas

Después de analizar cómo funciona la propiedad db_chainig y los riesgos de activar cross db ownership chaining a nivel de instancia, nos queda un tema que está en el centro de todo: el uso del usuario y esquema dbo de forma sistemática. Es una práctica habitual, cómoda y hasta cierto punto tradicional en SQL Server, pero que conviene revisar con detalle cuando hablamos de seguridad, despliegues controlados y gobernanza de datos.

¿Realmente es buena idea que todo pertenezca a dbo? ¿Qué consecuencias tiene a medio y largo plazo? ¿Dónde está el equilibrio entre comodidad y control?

Qué es dbo y por qué se usa tanto

El usuario dbo (database owner) es un usuario especial en cada base de datos de SQL Server. Está vinculado al propietario real de la base de datos y tiene todos los privilegios dentro de ella. Cuando creamos objetos sin especificar un esquema, y el usuario con el que trabajamos está asignado como dbo, los objetos se crean bajo ese esquema por defecto.

Esto significa que en la mayoría de los entornos, a menos que se especifique lo contrario, todos los procedimientos, tablas, vistas y funciones acaban siendo del esquema dbo y perteneciendo al usuario dbo.

Esta práctica tiene una ventaja clara: evita problemas de permisos y simplifica el acceso a los objetos, sobre todo en proyectos donde no se quiere dedicar tiempo a gestionar esquemas ni propietarios. En resume, es una forma de trabajar directa y suele «funcionar a la primera». Pero también tiene implicaciones importantes que no se deben ignorar.

Seguridad: encadenamiento de propietarios dbo y permisos no deseados

Cuando todos los objetos son propiedad de dbo, es muy fácil que se establezcan cadenas de confianza sin querer. Esto es justo lo que habilita la propiedad db_chainig cuando está activa, y lo que se multiplica peligrosamente si además se activa cross db ownership chaining a nivel de instancia.

Al compartir el mismo propietario, los objetos pueden acceder entre sí sin que se comprueben los permisos del usuario que ejecuta la operación. Esto puede ser deseable en ciertos diseños bien controlados, pero también abre la puerta a que procedimientos maliciosos o mal diseñados escapen a la lógica de seguridad prevista, sobre todo cuando hay múltiples bases de datos con el mismo esquema y propietario.

Además, si todos los objetos son de dbo, resulta más difícil aplicar políticas de control por esquema o restringir accesos según áreas funcionales, ya que todo está en el mismo «cajón».

Mantenimiento y legibilidad: lo que hoy parece fácil con dbo, mañana es un dolor

Usar siempre dbo dificulta la organización lógica de los objetos. Cuando una base de datos empieza a crecer, no hay forma rápida de agrupar o identificar objetos por módulo funcional, equipo responsable o ciclo de vida.

Tampoco ayuda en tareas como generar scripts de despliegue por módulos, aplicar permisos diferenciados según esquema, monitorizar la actividad por subsistemas o delegar administración de partes concretas de la base de datos.

Todo eso requiere una separación explícita por esquemas o, al menos, una política clara de nomenclatura y propiedad. Si todo está bajo dbo, estas tareas se convierten en búsquedas manuales y excepciones constantes.

Auditoría y trazabilidad: todos los caminos llevan a dbo

Desde el punto de vista de la auditoría, tener todos los objetos bajo dbo borra cualquier pista sobre quién creó o modificó qué. El seguimiento de cambios se vuelve opaco, y las herramientas de trazado o revisión de permisos no pueden distinguir entre distintos propietarios lógicos. Esto se agrava si además usamos usuarios compartidos o impersonificación (EXECUTE AS), donde es muy difícil reconstruir el contexto original de ejecución.

Cuando una base de datos es pequeña y la usa un solo equipo, esto puede parecer un problema menor. Pero en sistemas colaborativos, auditados o con cumplimiento normativo, no tener separación de propietarios o esquemas puede ser un problema serio.

Despliegue controlado: lo que no se define, se rompe

Si trabajamos con plantillas de despliegue, versionado de bases de datos o pipelines CI/CD, usar siempre dbo limita la capacidad de definir entornos reproducibles y con permisos granulados. No se puede diferenciar entre objetos internos, públicos, temporales o propios de cada equipo.

Además, algunos errores de despliegue tienen que ver precisamente con suposiciones implícitas sobre el esquema o el propietario: si un script no especifica dbo y el usuario por defecto cambia, el objeto puede terminar en otro esquema, provocando errores sutiles y difíciles de detectar.

¿Cuándo sí tiene sentido usar dbo?

No todo es negativo. Hay escenarios donde usar exclusivamente dbo puede ser razonable. Por ejemplo en bases de datos monolíticas mantenidas por un solo equipo, en proyectos personales o experimentales donde no hay requisitos de seguridad ni mantenimiento a largo plazo o en aplicaciones donde toda la lógica de negocio está encapsulada y no se expone acceso directo a las tablas.

En estos casos, usar dbo reduce fricción y permite concentrarse en el desarrollo funcional. Pero, incluso en estos casos, conviene tener claro que estamos asumiendo una simplificación consciente, no una buena práctica general.

Buenas prácticas recomendadas: ¿dbo si o no?

Si queremos mantener un equilibrio entre simplicidad y control, podemos aplicar algunas de estas pautas.

La primera sería no usar dbo y usar esquemas distintos para separar áreas funcionales, como ventas, compras, auditoria, etc. Especialmente debemos evitar crear objetos como dbo si el usuario final no debe tener control total. En estos casos asignar esquemas a roles o usuarios concretos, y establecer políticas de permisos basadas en ellos es clave. Además, definir el esquema siempre de forma explícita en scripts y objetos programables es imprescindible para que, si un usuario tiene otro esquema por defecto, todo siga funcionando. Por último documenta siempre la política de propiedad y esquema como parte del diseño de cada base de datos.

Con estas simples recomendaciones podrás mantener la claridad y la organización incluso en proyectos con muchos objetos o múltiples desarrolladores.

Conclusión

Usar dbo para todo es cómodo, pero a menudo es una señal de diseño descuidado o sin política de seguridad clara. Aunque puede parecer una solución rápida, a largo plazo complica el mantenimiento, debilita el control de accesos y dificulta la trazabilidad.

En bases de datos pequeñas o entornos cerrados, puede no suponer un problema. Pero si trabajamos en entornos colaborativos, con ciclos de vida largos, requisitos de auditoría o despliegues automatizados, separar esquemas y propietarios deja de ser una opción y se convierte en una necesidad.

No se trata de demonizar dbo, sino de dejar de usarlo como valor por defecto para todo. Definir y respetar una estructura clara es una de las formas más efectivas de asegurar calidad y sostenibilidad en nuestras bases de datos.

Abr

2025

Cross DB Ownership Chaining en SQL Server

En el artículo anterior vimos cómo la propiedad db_chainig permite que el encadenamiento de propietarios funcione entre objetos ubicados en bases de datos distintas, siempre que esta opción esté activada en ambas bases de datos y se cumplan ciertos requisitos. Pero hay un aspecto que no abordamos en profundidad: qué ocurre cuando esta configuración se aplica no solo a nivel de base de datos, sino también a nivel de instancia, utilizando la opción cross db ownership chaining. Este ajuste tiene un comportamiento más agresivo y, en la mayoría de los entornos, representa una mala práctica de seguridad que conviene evitar.

¿Qué hace exactamente cross db ownership chaining?

Mientras que la propiedad db_chainig se puede activar o desactivar de forma individual en cada base de datos, la opción cross db ownership chaining es una configuración de instancia que fuerza la activación del encadenamiento de propietarios entre todas las bases de datos de la instancia, sin posibilidad de excluir ninguna.

Activarla equivale, a efectos prácticos, a establecer db_chainig = ON para todas las bases de datos, aunque no lo hayamos hecho explícitamente. Esto significa que cualquier procedimiento, vista, función u otros objetos en una base de datos que comparta propietario con una tabla en otra podrá acceder a ella sin que el usuario tenga permisos explícitos. Y lo más preocupante: este comportamiento se extiende automáticamente a cualquier base de datos nueva que se cree en la instancia.

Cómo activar y desactivar cross db ownership chaining

Podemos consultar el estado actual de la opción con:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'cross db ownership chaining';

Si devuelve valor 1, la opción está activada. Para desactivarla (que es lo recomendable en la mayoría de casos):

EXEC sp_configure 'cross db ownership chaining', 0;
RECONFIGURE;

Esta configuración requiere nivel de sysadmin, ya que afecta directamente a la seguridad global del motor.

Implicaciones de seguridad

El principal riesgo de mantener esta opción activa es que se rompen los límites de seguridad entre bases de datos. En lugar de tener compartimentos estancos, con cross db ownership chaining se permite el acceso entre objetos de distintas bases de datos con solo compartir el mismo propietario. Esto debilita el aislamiento lógico que SQL Server garantiza por defecto.

Imaginemos una instancia donde convivieran varias bases de datos de distintos departamentos, proyectos o incluso clientes. Si todas ellas utilizan el esquema y usuario dbo, y se activa cross db ownership chaining, cualquier procedimiento mal diseñado o malicioso podría acceder a tablas fuera de su alcance original sin necesidad de permisos explícitos. Este escenario rompe cualquier principio de defensa en profundidad.

Además, si se utilizan funciones como EXECUTE AS, se complica todavía más el análisis de los permisos efectivos, y pueden aparecer brechas difíciles de detectar hasta que ya es tarde.

¿Hay algún caso donde activarla tenga sentido?

La única situación razonable para activar cross db ownership chaining es en entornos completamente controlados, con una única aplicación propietaria desplegada en la instancia, donde todas las bases de datos forman parte de la misma solución y no hay usuarios externos ni terceros ejecutando código dinámico o creando objetos.

Incluso en ese caso, sigue siendo preferible activar db_chainig solo en las bases de datos que lo necesiten, en lugar de aplicar un cambio de instancia que afectará a todo lo que esté ejecutándose ahora y en el futuro.

También puede tener cierta justificación en entornos de desarrollo o pruebas rápidas, donde se valore más la agilidad que la seguridad. Pero ahí conviene recordar que muchas veces lo que se prueba en desarrollo acaba en producción… y con ello los errores de configuración.

Buenas prácticas y recomendaciones

Para mantener la seguridad y el control en nuestras instancias de SQL Server, las pautas más recomendables respecto a esta configuración son claras: “Mantener cross db ownership chaining desactivado por defecto”. Siempre es más recomendable activar db_chainig solo en las bases de datos que lo requieran y siempre de forma explícita y documentada. En cualquier caso, además te recomiendo evitar el uso masivo del propietario dbo en todas las bases de datos, especialmente en entornos con múltiples aplicaciones o proyectos y revisar regularmente qué bases de datos tienen esta propiedad activada y por qué. Tampoco está de más aplicar control de cambios y auditoría cuando se modifiquen opciones de instancia.

Además, en cualquier revisión de seguridad o auditoría formal, tener esta opción activada puede ser motivo de alerta o incluso de no conformidad con normativas como ISO 27001, PCI-DSS o el Esquema Nacional de Seguridad (ENS).

Conclusión

La opción cross db ownership chaining es uno de esos ajustes que, a simple vista, puede parecer útil para evitar errores de permisos durante el desarrollo, pero que en producción representa una puerta abierta a problemas de seguridad difíciles de rastrear. Es una opción de legado que hoy en día solo deberíamos tocar si entendemos perfectamente sus implicaciones.

Si en tu entorno necesitas acceso cruzado entre bases de datos, activa db_chainig solo donde sea estrictamente necesario. Y si lo que quieres es encapsular accesos sin exponer tablas directamente, plantéate usar certificados para firmar procedimientos y mantener un modelo de permisos más seguro y robusto.

Abr

2025

Cómo actúa db_chainig en SQL Server

En su día publicamos un artículo donde analizábamos en profundidad los riesgos de activar la propiedad db_chainig en nuestras bases de datos: db_chainig: una configuración de seguridad peligrosa. Allí abordamos su impacto en la superficie de ataque de una instancia de SQL Server, especialmente cuando se activa de forma global o sin tener un control estricto de propietarios y permisos.

Hoy retomamos el tema con un enfoque diferente. Vamos a mostrar una demo práctica que responde a una duda concreta planteada por un integrante de la comunidad de Telegram “SQL Server Español”, y que nos permite ver de forma clara cómo se comporta esta propiedad cuando varios objetos en distintas bases de datos se relacionan entre sí. Aprovecharé además para precisar algunos matices técnicos que suelen pasar desapercibidos, sobre todo cuando intentamos aplicar el modelo de encapsulación de acceso sin otorgar permisos directos.

Recordatorio: qué es db_chainig y por qué nos debe importar

Como ya explicamos en el artículo de hace meses, db_chainig es una propiedad que habilita el encadenamiento de propietarios entre bases de datos distintas. Cuando está desactivada (valor por defecto), SQL Server impide que un objeto de una base de datos acceda a otro en una base diferente, aunque ambos compartan el mismo propietario y aunque el encadenamiento funcionase sin problema dentro de una única base de datos.

Este comportamiento se introdujo por motivos de seguridad, y su activación requiere un análisis muy cuidadoso. No obstante, existen escenarios legítimos donde permitir este acceso cruzado puede simplificar la arquitectura, como cuando separamos lógica de negocio y almacenamiento físico en distintas bases de datos bajo el mismo control.

La demo: ejemplo de acceso cruzado encapsulado entre bases de datos

Para mostrar cómo se comporta realmente esta propiedad en un escenario típico, he preparado una demo que tenéis disponible aquí.

El entorno consiste en dos bases de datos una con una vista de una tabla de la otra base de datos (podríamos llevarlo al mundo real como una base de datos donde residen los procedimientos que encapsulan la lógica de acceso) y otra base de datos con una tabla (que sería la base de datos donde se encuentran las tablas con los datos reales)

Creamos un usuario solo con privilegios explícitos sobre la base de datos con la vista e intentamos seleccionar la vista que, recordad, lee una tabla de la otra base de datos.

En un primer lugar obtenemos un error porque el usuario no existe en la otra base de datos pero si lo creamos, sin permisos, claro, nos encontramos con otro error porque el usuario no puede acceder a la tabla.

Hay que recordar que la vista filtra los datos de la tabla por lo que en ningún caso queremos dar al usuario permisos explícitos sobre la tabla, solo debe consultar la información a través de la vista.

Con db_chainig desactivado, la ejecución falla con un error de permisos, incluso si ambos objetos tienen el mismo propietario (dbo). Al activar la propiedad en ambas bases de datos el procedimiento funciona sin que el usuario tenga permisos directos sobre la tabla. Esto demuestra cómo SQL Server evalúa las cadenas de confianza solo si dicha propiedad está activa.

Consideraciones clave sobre propietarios y contexto de ejecución

Uno de los matices más importantes que se observa en la demo es que el encadenamiento entre bases de datos solo se permite si los objetos involucrados tienen el mismo propietario y si la propiedad db_chainig está activa en ambas bases de datos.

Otro detalle importante es que el contexto de ejecución no ha cambiado mediante EXECUTE AS o similar, lo que invalidaría la cadena de confianza.

Esto significa que no basta con activar la propiedad en una sola base de datos. Además, hay que evitar que el procedimiento se ejecute en un contexto que no sea el del usuario propietario de ambos objetos. Este tipo de situaciones no siempre son evidentes y pueden complicar el diagnóstico cuando un procedimiento aparentemente correcto lanza un error de acceso denegado.

Seguridad frente a conveniencia: ¿cuándo tiene sentido usar db_chainig?

Tal y como ya señalamos en el artículo anterior, activar db_chainig a nivel de instancia es algo que deberíamos evitar en la mayoría de escenarios, sobre todo si trabajamos en un entorno multi-tenant o con bases de datos de aplicaciones distintas.

Sin embargo, si tenemos un entorno controlado, donde todas las bases de datos son desplegadas por nosotros, los objetos comparten propietario y los accesos están bien encapsulados, db_chainig puede ser una herramienta útil para simplificar la gestión de permisos y mantener el modelo de mínima exposición.

En ese contexto, lo importante es no relajarse: hay que documentar cada caso en el que se activa, asegurarse de que no hay EXECUTE AS, revisar periódicamente los propietarios de los objetos y evitar cualquier modificación que pueda romper la cadena de confianza sin darnos cuenta.

Alternativas a db_chaining: firma con certificados

Para aquellos entornos donde la seguridad es prioritaria, pero aún así necesitamos encapsular accesos entre bases de datos, lo más recomendable es firmar los procedimientos almacenados con certificados. Esta técnica, algo más compleja de implementar, permite simular una elevación de permisos perfectamente controlada y auditable, sin necesidad de alterar propiedades globales ni confiar en la coherencia del dbo.

Si todavía no has trabajado con este enfoque, te recomiendo investigar cómo funciona la creación de certificados, usuarios basados en certificado y firma de procedimientos. Puedes consultar el artículo que publiqué sobre el tema la semana pasada.

Conclusión

Con esta demo he querido complementar el análisis previo sobre db_chainig, esta vez desde un enfoque más práctico. El comportamiento por defecto protege nuestras bases de datos, pero hay casos reales donde su activación puede facilitar una arquitectura limpia y modular.

Eso sí, hay que entender muy bien sus implicaciones, probarlo a fondo y asegurarnos de que el entorno cumple con los requisitos de seguridad y propiedad para que el encadenamiento funcione sin sorpresas. Y si no queremos depender de esta propiedad, las firmas con certificados siguen siendo la alternativa más elegante y segura.

Abr

2025

Firmar procedimientos almacenados con certificados

Una política de permisos mínimos para usuarios (y roles) es fundamental para la seguridad de nuestros datos. Sin embargo, a menudo nos enfrentamos al dilema de cómo hacerlo sin sacrificar funcionalidad ni exponer en exceso nuestros objetos. Como decía, la necesidad de implementar un principio de privilegios mínimos es esencial en entornos seguros y controlados, especialmente en bases de datos con múltiples aplicaciones o equipos interactuando. Una técnica muy potente y poco utilizada en SQL Server es la firma de procedimientos almacenados con certificados. Hoy vamos a explorar cómo funciona y por qué puede marcar una diferencia importante en nuestras estrategias de seguridad.

Delegación segura con certificados

Cuando se habla de conceder permisos a través de procedimientos almacenados, una de las primeras aproximaciones suele ser el uso de EXECUTE AS. Aunque funcional, esta técnica presenta inconvenientes, especialmente cuando entra en juego el “chaining” de ejecución o cuando queremos evitar tener que gestionar contextos de ejecución elevados.

Ahí es donde entran los certificados. Firmar procedimientos almacenados nos permite encapsular permisos de forma precisa y segura sin cambiar el contexto de ejecución, sin depender de impersonaciones y sin debilitar el modelo de seguridad de la base de datos.

¿Cómo funciona la firma con certificados?

El procedimiento se basa en tres pasos fundamentales: creación del certificado, firma del procedimiento y asignación del permiso requerido a un login asociado al certificado. Cada uno de estos pasos es determinante para conseguir una delegación limpia y controlada.

Partimos de una situación donde un procedimiento necesita acceder a un objeto (por ejemplo, una tabla o vista), pero el usuario que lo ejecuta no tiene permiso directo sobre ese objeto. Esto normalmente no sería un problema salvo que el procedimiento y el objeto sean de un propietario distinto o que la consulta desde el procedimiento se ejecute en otro contexto de seguridad diferente, por ejemplo por usar sp_executesql. En estos casos, si firmamos el procedimiento con un certificado y asociamos el certificado a un login o usuario que sí tenga ese permiso, el procedimiento se ejecutará con esos privilegios, pero sin necesidad de cambiar el contexto de ejecución del usuario.

Caso práctico detallado

Supongamos que queremos que ciertos usuarios puedan ejecutar un procedimiento llamado usp_ObtenerVentasPrivadas, que accede a una tabla sensible como VentasPrivadas, pero sin darles acceso directo a dicha tabla. El procedimiento sería como el siguiente:

CREATE PROCEDURE dbo.usp_ObtenerVentasPrivadas
AS
BEGIN
   SELECT * FROM dbo.VentasPrivadas;
END;
GO

Tal como está, cualquier usuario que tenga permiso de ejecución sobre usp_ObtenerVentasPrivadas podrá acceder a VentasPrivadas, pero sin tener acceso directo a ella ni posibilidad de usarla fuera de este procedimiento. Esto es porque el contexto de ejecución sigue siendo el del usuario original al no tener código dinámico y al pertenecer la tabla y el procedimiento al mismo esquema (con el mismo owner del esquema).

Cuando la cosa se complica

Pero, ¿qué pasa si cambiamos el contexto de ejecución o tenemos distinto owner? Aquí es donde entran en juego los certificados.

Yo para la demo que os pongo lo he simplificado y ejecuto una consulta simple pero, pongamos que tenemos un procedimiento que genera SQL dinámico y lo ejecuta con sp_executesql. Este sería el ejemplo que podeis reproducir vosotros mismos.

-- ============================================
-- DEMO: Firmar procedimientos con certificado
-- ============================================

-- Crear base de datos de prueba
USE master
GO
IF DB_ID('DemoCertificados') IS NOT NULL
BEGIN
    ALTER DATABASE DemoCertificados SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE DemoCertificados;
END;
GO

CREATE DATABASE DemoCertificados;
GO

USE DemoCertificados;
GO

-- ========================
-- Limpieza previa (por si ya existe algo)
-- ========================
IF EXISTS (SELECT * FROM sys.database_principals WHERE name = 'UsuarioLimitado')
    DROP USER UsuarioLimitado;
IF EXISTS (SELECT * FROM sys.database_principals WHERE name = 'UsuarioCertSeguridad')
    DROP USER UsuarioCertSeguridad;
IF EXISTS (SELECT * FROM sys.certificates WHERE name = 'CertSeguridad')
    DROP CERTIFICATE CertSeguridad;
IF EXISTS (SELECT * FROM sys.objects WHERE name = 'usp_VerSeguridad')
    DROP PROCEDURE dbo.usp_VerSeguridad;
IF OBJECT_ID('dbo.Seguridad') IS NOT NULL
    DROP TABLE dbo.Seguridad;
GO

-- ========================
-- Crear tabla de ejemplo
-- ========================
CREATE TABLE dbo.Seguridad (
   Id INT PRIMARY KEY,
   InfoPrivada NVARCHAR(100)
);

-- ========================
-- Insertar datos de ejemplo
-- ========================

INSERT INTO dbo.Seguridad (Id, InfoPrivada)
VALUES (1, 'Datos internos'), (2, 'Contenido sensible');
GO

-- ========================
-- Crear usuario sin login (para simplificar la demo)
-- ========================
CREATE USER UsuarioLimitado WITHOUT LOGIN;
GO

-- ========================
-- Crear procedimiento con SQL dinámico
-- ========================
CREATE PROCEDURE dbo.usp_VerSeguridad
AS
BEGIN
    DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM dbo.Seguridad';
    EXEC sp_executesql @sql;
END;
GO

GRANT EXECUTE ON dbo.usp_VerSeguridad TO UsuarioLimitado;
GO

-- ========================
-- Comprobación sin firma (debería fallar)
-- ========================
PRINT '--- Prueba SIN firma (esperado: error de permisos) ---';
EXECUTE AS USER = 'UsuarioLimitado';
BEGIN TRY
    EXEC dbo.usp_VerSeguridad;
END TRY
BEGIN CATCH
    PRINT ERROR_MESSAGE();
END CATCH
REVERT;
GO

-- ========================
-- Crear certificado y usuario asociado
-- ========================
CREATE CERTIFICATE CertSeguridad
   ENCRYPTION BY PASSWORD = 'UnPasswordSegurísimo!'
   WITH SUBJECT = 'Certificado para lectura controlada';
GO

CREATE USER UsuarioCertSeguridad FOR CERTIFICATE CertSeguridad;
GRANT SELECT ON dbo.Seguridad TO UsuarioCertSeguridad;
GO

-- ========================
-- Firmar el procedimiento con el certificado
-- ========================
ADD SIGNATURE TO OBJECT::dbo.usp_VerSeguridad
BY CERTIFICATE CertSeguridad
WITH PASSWORD = 'UnPasswordSegurísimo!';
GO

-- ========================
-- Comprobación con firma (debería funcionar)
-- ========================
PRINT '--- Prueba CON firma (esperado: acceso concedido) ---';
EXECUTE AS USER = 'UsuarioLimitado';
BEGIN TRY
    EXEC dbo.usp_VerSeguridad;
END TRY
BEGIN CATCH
    PRINT ERROR_MESSAGE();
END CATCH
REVERT;
GO

-- ========================
-- FIN DE LA DEMO
-- ========================

Como veis, si probamos a ejecutar el procedimiento almacenado con el usuario limitado va a dar error porque no tiene permisos sobre la tabla. Sin embargo, cuando creamos un certificado, lo asociamos a un usuario que tiene permisos sobre la tabla y firmamos el procedimiento con ese usuario ya podemos ejecutar sin error el procedimiento con el usuario limitado.

Ventajas clave de usar certificados

Una de las principales ventajas frente a EXECUTE AS es que el certificado no interfiere con el contexto de ejecución. Esto significa que si dentro del procedimiento hay llamadas a otros objetos que usan permisos del usuario original, todo seguirá funcionando correctamente. Además, los certificados son inmunes a problemas comunes como la pérdida de contexto entre bases de datos, lo que resulta útil en entornos distribuidos.

Otra ventaja es la auditabilidad. Como los permisos no se conceden directamente a los usuarios finales, sino que se encapsulan dentro de procedimientos firmados, es más sencillo identificar los puntos de entrada permitidos y realizar auditorías.

También se evita el problema clásico de los permisos residuales. Si un usuario necesita ejecutar varios procedimientos que requieren distintos permisos, no es necesario concederle un permiso amplio ni crear roles intermedios complejos. Firmamos cada procedimiento con los permisos justos que requiere, y el acceso queda perfectamente delimitado.

Consideraciones de los certificados a tener en cuenta

La firma de procedimientos con certificados no está exenta de ciertas limitaciones. Para empezar, no podemos firmar procedimientos encriptados ni CLR. Además, si un procedimiento se modifica, se pierde la firma y hay que volver a aplicarla.

En cuanto a la gestión de certificados, conviene centralizar su creación y almacenamiento de forma segura. El uso de contraseñas fuertes y una política clara de mantenimiento y renovación de certificados es fundamental para evitar riesgos.

Por último, es importante evitar el uso excesivo de esta técnica, especialmente si se convierte en la única forma de delegación. En bases de datos muy grandes o con cientos de procedimientos, puede ser más conveniente crear roles bien definidos y controlar el acceso de forma más clásica. La clave está en encontrar el equilibrio adecuado.

Comportamiento de DENY

Otra consideración muy importante que debemos tener en cuenta es que el uso de DENY no puede ser sobrepasado por una firma de certificado. Si el usuario que ejecuta el procedimiento tiene un DENY explícito sobre el objeto que se consulta dentro del procedimiento, nada podrá permitirle el acceso, por mucho que el certificado tenga ese GRANT.

Esto tiene dos consecuencias prácticas. La primera es que si queremos controlar el acceso mediante firmas, no debemos usar DENY. Sencillamente basta con no conceder permisos. Por otro lado, si existe un DENY, servirá como veto absoluto, incluso para accesos indirectos a través de procedimientos firmados.

Conclusión

Firmar procedimientos almacenados con certificados es una herramienta extremadamente útil y robusta para aplicar el principio de privilegios mínimos de forma segura y mantenible. Nos permite conceder permisos de forma encapsulada, sin necesidad de impersonaciones ni contextos elevados, y facilita una delegación precisa del acceso.

Es una técnica que deberíamos tener siempre en nuestro arsenal cuando diseñamos la arquitectura de seguridad de una base de datos SQL Server. En combinación con otras prácticas como el uso de roles, vistas seguras y auditoría de permisos, puede contribuir a sistemas mucho más sólidos, trazables y mantenibles.

ciberseguridad

Técnicas de Recuperación ante Desastres (DR) en Always On (AG)

Always On no evita el 100% de los desastres

Los backups si nos salvan ante desastres

AG distribuidos: la aspiración de los ya experimentados en desastres

Consideraciones adicionales: DR de verdad

Automatización: scripts o muerte

Conclusión

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes