Curso DBA Senior – C2 – Seguridad real en entornos modernos

---

¿Por qué hablar de seguridad más allá del GRANT y el REVOKE?

Porque hoy no basta con que una base de datos funcione: debe proteger los datos que guarda y registrar cómo se accede a ellos.
La seguridad no es solo para evitar que alguien haga un DROP TABLE. Es para:

• Respetar la privacidad de usuarios y clientes
• Cumplir normativas (como habeas data, GDPR o ISO)
• Proteger datos sensibles de fugas internas o externas
• Tener control sobre accesos, auditorías y privilegios reales
• Prevenir errores accidentales de administradores o sistemas conectados

Este capítulo te da herramientas para administrar con responsabilidad, diseñar con criterios sólidos y generar entornos confiables.

Temas que abordaremos en este capítulo:

• 2.1 Roles, permisos y separación de funciones
  ¿Quién puede hacer qué? ¿Qué pasa si todos son “sa”?
• 2.2 Auditoría de bases de datos y trazabilidad real
  Cómo registrar qué consulta quién, cuándo y desde dónde.
• 2.3 Cifrado de datos: TDE vs Always Encrypted
  Qué se cifra, dónde, cómo y quién tiene las llaves.
• 2.4 Seguridad en entornos cloud (con Azure Defender y buenas prácticas)
  Porque moverlo a la nube no lo hace automáticamente más seguro.

Ejemplo para pensar

Imagina que trabajas en una empresa donde todos los desarrolladores tienen acceso total a producción.
¿Qué podría salir mal?
¿Cómo detectarías si alguien accedió a la tabla de clientes y copió todos los correos?

Consejos antes de entrar a los subtemas

• La seguridad se diseña, no se improvisa.
• Tener permisos por defecto o roles mal usados es más común de lo que crees.
• No necesitas implementar todo a la vez, pero sí saber qué está en riesgo si no lo haces.

---

2.1 – Roles, permisos y separación de funciones

Quién puede hacer qué, y por qué eso no debería ser al azar

¿Por qué no todos deberían ser “admin”?

Cuando una base de datos está mal administrada, suele tener dos extremos peligrosos:

• Usuarios con demasiados privilegios (riesgo de borrados, filtraciones o cambios accidentales).
• Usuarios con pocos permisos que no pueden trabajar y dependen de soporte para todo.

La clave está en definir roles claros, con permisos alineados a lo que cada perfil necesita. Y, sobre todo, en que los accesos tengan intención, no improvisación.

¿Qué son los roles en una base de datos?

Son agrupaciones de permisos. En lugar de asignar permisos uno a uno a cada usuario, se asignan a un rol, y los usuarios se agregan al rol correspondiente.

Ventajas:

• Menos errores manuales
• Fácil mantenimiento
• Cumplimiento más claro (auditoría, normativas)
• Separación de funciones más sólida

Tipos de roles en SQL Server

Roles de servidor (nivel instancia)

Controlan acciones generales en todo el servidor:

• sysadmin: acceso total (evítalo si no es indispensable)
• securityadmin: gestiona usuarios y roles
• dbcreator, diskadmin, etc.: cada uno con un foco específico

Roles de base de datos

Controlan acciones dentro de una base específica:

• db_owner: todo dentro de la base
• db_datareader: puede leer todas las tablas
• db_datawriter: puede insertar, actualizar y eliminar
• db_ddladmin: puede modificar estructura (crear tablas, etc.)
• También puedes crear roles personalizados

Buenas prácticas para asignar permisos

Recomendación	¿Por qué?
Usa roles, no permisos directos	Más fácil de mantener y auditar
Aplica el principio de mínimo privilegio	El usuario solo debe poder hacer lo que necesita
Separa ambientes (dev, test, prod)	Previene errores en producción
Documenta roles y asignaciones	Permite saber por qué alguien tiene acceso

Cómo asignar un usuario a un rol en SQL Server

1. Crear un nuevo rol personalizado:

CREATE ROLE reportes_ventas;

2. Asignar permisos al rol:

GRANT SELECT ON Ventas TO reportes_ventas;

3. Agregar un usuario al rol:

EXEC sp_addrolemember 'reportes_ventas', 'usuario_jose';

Desafío práctico guiado

Objetivo: crear un esquema de roles y verificar que los permisos funcionen correctamente.

Paso a paso:

1. Crea dos usuarios de prueba:

CREATE LOGIN usuario_lectura WITH PASSWORD = 'Prueba123!';
CREATE USER usuario_lectura FOR LOGIN usuario_lectura;

2. Crea un rol personalizado de solo lectura:

CREATE ROLE solo_lectura;
GRANT SELECT ON Clientes TO solo_lectura;

3. Asigna el usuario al rol:

EXEC sp_addrolemember 'solo_lectura', 'usuario_lectura';

4. Verifica los permisos:

• Intenta hacer un SELECT desde ese usuario (funciona)
• Intenta un INSERT o DELETE (falla)

¿Qué deberías haber notado?

• Es fácil perder control si todo el mundo tiene permisos sueltos.
• Los roles permiten una administración más clara y segura.
• Asignar lo justo es parte de construir sistemas confiables.

Pregunta para reflexión o conversación

¿Tienes algún sistema donde los roles no están definidos claramente? ¿Cómo afectaría eso en caso de un error o auditoría?

---

2.2 – Auditoría de bases de datos y trazabilidad real

Saber quién hizo qué, cuándo, y desde dónde… sin depender de la memoria

¿Por qué auditar una base de datos?

Porque tarde o temprano alguien preguntará:

• ¿Quién consultó esta tabla?
• ¿Quién borró este registro?
• ¿Desde qué equipo entraron a modificar esa factura?

Y si no tienes auditoría activa, no podrás responder con certeza.

Auditar no es vigilar: es proteger, rastrear y respaldar decisiones.
Además, muchas normas (como ISO 27001, GDPR, Sarbanes-Oxley) exigen trazabilidad en sistemas que manejan información sensible o crítica.

¿Qué tipo de acciones puedes auditar?

• Accesos y logins
• Lectura, inserción, modificación o eliminación de datos
• Cambios en estructuras (tablas, índices, procedimientos)
• Ejecución de comandos específicos
• Actividad por IP, aplicación o usuario

Opciones de auditoría en SQL Server

1. Auditoría nativa (SQL Server Audit)

Disponible en ediciones Enterprise (y algunas funcionalidades limitadas en Standard).

Permite:

• Registrar eventos a nivel de servidor o base
• Guardar auditoría en archivos, Application Log o Security Log
• Definir qué se audita y con qué nivel de detalle

Ejemplo básico de creación:

-- Crear auditoría
CREATE SERVER AUDIT AuditoriaGeneral
TO FILE (FILEPATH = 'C:\\Auditorias\\');

-- Activar auditoría
ALTER SERVER AUDIT AuditoriaGeneral WITH (STATE = ON);

-- Crear especificación: registrar SELECT sobre tabla Clientes
CREATE SERVER AUDIT SPECIFICATION AuditarSelectClientes
FOR SERVER AUDIT AuditoriaGeneral
ADD (SCHEMA_OBJECT_ACCESS_GROUP);

2. Triggers de auditoría personalizada

• Puedes crear triggers AFTER INSERT, UPDATE, DELETE para registrar cambios en tablas sensibles.
• Guardan información en una tabla de log, con usuario, hora y acción.

Ejemplo básico:

CREATE TRIGGER tr_auditar_clientes
ON Clientes
AFTER UPDATE
AS
BEGIN
  INSERT INTO LogCambiosClientes (ID, Fecha, Usuario)
  SELECT ID, GETDATE(), SYSTEM_USER
  FROM inserted;
END;

Ideal para control fino de operaciones en tablas críticas.

3. Extended Events y Profiler (avanzado)

• Permiten capturar eventos a nivel de servidor o base.
• Más ligeros y configurables que SQL Trace o Profiler clásico.
• Útiles para auditoría de rendimiento, trazas personalizadas o análisis profundo.

Buenas prácticas de auditoría

Acción	Motivo
Registrar cambios en tablas sensibles	Protege contra errores o fraudes
No auditar todo “por si acaso”	Impacta rendimiento y genera ruido
Guardar auditorías en espacio separado	Evita que se llene el disco productivo
Revisar y depurar logs con regularidad	Aporta a la gestión activa, no solo reactiva

Desafío práctico guiado

Objetivo: implementar una auditoría personalizada para registrar cambios en una tabla.

Paso a paso:

1. Crea una tabla de log:

CREATE TABLE LogCambiosClientes (
  ID INT,
  Fecha DATETIME,
  Usuario NVARCHAR(100)
);

2. Crea un trigger sobre Clientes:

CREATE TRIGGER tr_log_update_clientes
ON Clientes
AFTER UPDATE
AS
BEGIN
  INSERT INTO LogCambiosClientes (ID, Fecha, Usuario)
  SELECT ID, GETDATE(), SYSTEM_USER
  FROM inserted;
END;

3. Actualiza algún cliente:

UPDATE Clientes SET Ciudad = 'Cali' WHERE ID = 1;

4. Consulta el log:

SELECT * FROM LogCambiosClientes;

¿Qué deberías haber notado?

• La auditoría no depende solo del servidor: tú decides qué registrar.
• Triggers bien pensados pueden dar trazabilidad sin necesidad de licencias enterprise.
• Si algo cambia y no lo ves, no puedes protegerlo.

Pregunta para reflexión o conversación

¿Tienes alguna tabla en tu sistema que debería estar auditada hoy mismo? ¿Cómo sabrías si alguien modificó un dato clave sin autorización?

---

2.3 – Cifrado de datos: TDE vs Always Encrypted

Protección real más allá del servidor y del usuario

¿Por qué cifrar los datos?

Porque hay datos que no basta con proteger por permisos.

• ¿Qué pasa si alguien copia el archivo .mdf y lo monta en otro servidor?
• ¿Y si un administrador del sistema accede al servidor y lee todo?
• ¿Qué haces si por normatividad debes garantizar que los datos personales o financieros estén cifrados?

Cifrar es hacer ilegible la información para quien no tiene la llave, incluso si logra acceder físicamente al archivo.

Tipos de cifrado en SQL Server

SQL Server tiene varias formas de cifrar datos. Aquí nos centraremos en las dos más potentes y comunes:

1. Transparent Data Encryption (TDE)

Cifra toda la base de datos en reposo

• El archivo .mdf, .ldf y backups quedan cifrados.
• Pero los datos siguen siendo legibles desde SQL Server por cualquier usuario con permisos de lectura.
• El cifrado y descifrado ocurre automáticamente al leer/escribir en disco.

¿Cuándo usarlo?

• Cuando quieres proteger contra robos de archivos o discos.
• Ideal para cumplimiento normativo general (como ISO, GDPR, etc.).

Cómo activar TDE (simplificado):

-- Crear la clave maestra
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ClaveFuerte123!';

-- Crear el certificado que se usará
CREATE CERTIFICATE CertificadoTDE
WITH SUBJECT = 'Cifrado TDE';

-- Crear la clave de cifrado de la base
USE MiBaseDeDatos;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE CertificadoTDE;

-- Activar TDE
ALTER DATABASE MiBaseDeDatos
SET ENCRYPTION ON;

2. Always Encrypted

Cifra columnas específicas de forma que ni el motor de SQL puede leer los valores

• Los datos se cifran desde la aplicación cliente, no desde el servidor.
• SQL Server no puede ver el contenido, solo campos cifrados.
• El cliente tiene la clave y hace el descifrado.

¿Cuándo usarlo?

• Cuando necesitas cifrado end-to-end, incluso frente a administradores del servidor.
• Para columnas sensibles: números de tarjeta, documentos, salarios, etc.

Requiere: SQL Server 2016+, conexión desde aplicación compatible (ADO.NET, ODBC, etc.).

Comparación rápida entre TDE y Always Encrypted:

Característica	TDE	Always Encrypted
¿Cifra todo?	Sí (archivos y backups)	No (solo columnas específicas)
¿El motor puede leerlo?	Sí	No
¿Protege contra admin del servidor?	No	Sí
¿Afecta rendimiento?	Mínimo	Depende del uso y la app
¿Desde dónde se aplica?	Desde SQL Server	Desde la aplicación cliente

Desafío práctico guiado (con TDE)

Objetivo: activar el cifrado transparente en una base de prueba

1. Crea una base de prueba:

CREATE DATABASE CifradoDemo;

2. Crea una clave maestra y un certificado:

USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ClaveSegura123!';
CREATE CERTIFICATE MiCertificado
WITH SUBJECT = 'Certificado para TDE';

3. Activa TDE en la base:

USE CifradoDemo;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MiCertificado;

ALTER DATABASE CifradoDemo SET ENCRYPTION ON;

4. Verifica el estado:

SELECT name, is_encrypted
FROM sys.databases;

¿Qué deberías haber notado?

• TDE es sencillo de activar, pero no reemplaza buenas prácticas de permisos.
• Always Encrypted ofrece un nivel más alto de protección, pero requiere preparación técnica y de aplicación.
• Ambas técnicas tienen su lugar. El valor está en usarlas con intención.

Pregunta para reflexión o conversación

¿Tienes datos sensibles en tus bases? ¿Sabes si están cifrados o no? ¿Y si alguien copia un backup, puede leer todo?

---

2.4 – Seguridad en la nube: Azure Defender y buenas prácticas

Porque moverlo a la nube no lo hace automáticamente más seguro

¿Por qué seguir hablando de seguridad en la nube?

Muchas organizaciones migran a la nube esperando que “todo esté más protegido por defecto”. Y aunque los proveedores como Microsoft Azure ofrecen seguridad de infraestructura, la responsabilidad de proteger tus datos sigue siendo compartida:

Azure protege la nube, tú proteges lo que haces dentro de ella.

Amenazas comunes en entornos cloud mal configurados

• Bases de datos públicas sin autenticación fuerte
• Cadenas de conexión filtradas en código fuente
• Roles de acceso excesivos o no segmentados
• Backups almacenados sin cifrado
• Despliegues automáticos con credenciales de administrador

Buenas prácticas para proteger tus bases de datos en Azure

Práctica	¿Por qué es clave?
Usa autenticación multifactor (MFA)	Reduce riesgo por robo de contraseñas
Activa Azure Defender for SQL	Detecta ataques en tiempo real
Habilita auditoría y alertas	Te avisa si algo inusual ocurre
Segmenta accesos por rol	Minimiza el impacto de errores o filtraciones
Usa Always Encrypted para datos sensibles	Ni siquiera Azure puede ver la información
Configura redes privadas (VNet, firewall)	Bloquea accesos externos no autorizados

¿Qué es Microsoft Defender for SQL?

Es una herramienta integrada en Azure que permite:

• Monitorear actividad sospechosa en bases de datos SQL (PaaS o IaaS)
• Detectar inyecciones SQL, accesos inusuales, exfiltración de datos
• Generar alertas en tiempo real y recomendaciones para mitigar riesgos

Activación rápida:

• Ir a la base de datos en el portal de Azure
• Sección “Microsoft Defender for SQL” > Activar
• Configurar alertas y destinos (correo, equipos de seguridad, etc.)

Otras capas importantes de seguridad en Azure

1. Azure Key Vault

• Guarda claves, certificados y secretos en un almacén seguro
• Evita que las apps guarden contraseñas o tokens en código
• Integración directa con TDE, Always Encrypted y aplicaciones

2. Firewalls y endpoints privados

• Asegura que solo ciertas IP o redes puedan acceder a la base
• Puedes bloquear todo acceso público y enrutar vía VNet

3. Azure Policy + Blueprints

• Establece reglas automáticas para cumplir requisitos de seguridad y auditoría
• Ideal para entornos corporativos con regulaciones

Desafío práctico guiado

Objetivo: reforzar la seguridad de tu base SQL en Azure

1. Ingresa al portal de Azure
2. Ve a tu base de datos SQL
3. Activa estas configuraciones, en orden:

• Azure Defender for SQL
• Auditoría (Audit logs hacia un almacenamiento seguro)
• Firewall con reglas de IP permitidas
• Evaluación de vulnerabilidades (Security Center)

4. Revisa los reportes sugeridos. ¿Hay vulnerabilidades activas? ¿Cuántos intentos de conexión no autorizados hubo?

¿Qué deberías haber notado?

• Azure tiene herramientas de seguridad potentes, pero muchas están desactivadas por defecto
• La seguridad real se construye activamente: analizando, segmentando, monitoreando
• Ser DBA en la nube implica pensar como administrador, arquitecto y guardián de datos

Pregunta para reflexión o conversación

¿Tienes alguna base expuesta más de lo necesario? ¿Quién tiene hoy permisos sobre tus datos en la nube?

---

¿Te gustó lo que encontraste aquí?

Si este contenido te fue útil o te inspiró, considera apoyar esta iniciativa.
Aquí sigo, creando recursos que aporten claridad, estructura y propósito en tu camino.

♥️ Hey sí, ¡quiero apoyar esto!

---

---

---

---