Este documento trata sobre la seguridad en SQL Server. Explica conceptos como la instalación y configuración segura, autenticación, autorización, encriptación de datos, enmascaramiento dinámico, auditoría, backups y buenas prácticas de desarrollo. También muestra demos de diferentes funcionalidades de seguridad en SQL Server.

1. Seguridad en SQL
Server
Rodrigo Corral González
ALM Team Lead & Software Architect
Microsoft Most Valuable Profesional (C++ y ALM)
rcorral@plainconcepts.com
@r_corral

2. 2
Introducción
Instalación y configuración
Autenticación
Autorización
Always encrypted
Row level security
Transparent data encryption
Dynamic data masking
Auditoria
Herramienta de evaluación de vulnerabilidades
Backups
Buenas prácticas de desarrollo
SQL Server Azure
Seguridad en
SQL Server

3. 3
Introducción

4. • Los datos son el activo más valioso.
• Nuestros datos son de valor para otros.
• Aunque los datos no tengan valor para otros estamos expuestos a secuestros.
• Nuestros datos están cada vez más expuestos: B2B, Internet…
• SQL Server es tan seguro o inseguro como cualquiera.
Introducción
4

5. 5
Instalación y configuración

6. • Seguridad física
– Protejer los Sistemas relacionados.
– Proteger acceso físico:
o Discos
o Backups
• Instalar en NTFS o ReFS
• No instalar en un controlador de dominio.
• Corre todos los servicios con un cuenta limitada
– Idealmente Network Service
– Usuario con bajos privilegios
– Nunca: LocalSystem, administrado local, administrador de dominio.
• Aplica los ultimos Service Pack y CUs
Instalación y configuración
6

7. • Modelo de autenticación
– Siempre es preferible autenticación integrada.
o Kerberos y NTLM.
o Kerberos permite delegación.
o Premite políticas de contraseña.
o Las aplicaciones no require almacenar contraseñas.
– Autenicación mixta
o Usar SSL para encryptar el tráfico de red.
o Usar passwords robustas.
o Nunca usar contraseñas vacias o en diccionario.
• Auditoria de Logins frecuente.
• Siempre tras un firewall.
• No permitir queries con conexiones ad hoc: OPENDATASET y OPENROWSET
Instalación y configuración
7

8. • Instala solo aquellas características que necesites.
• Activa solo aquellas características y servicios que necesites (p.e. SQL Server Browser).
• xp_cmdshell
– Por defecto desabilitado.
– No debes usarlo. No. Nunca.
– Se ejecuta con la cuenta configurada para el servicio de SQL Server.
– Por defecto solo sysadmin pueden usarlo.
– Otros pueden si se establecen credenciales con sp_xp_cmdshell_proxy_account
o ¡Ojo con que credenciales estableces!
• No permitas updates en las tablas de sistema.
• Facets y Policy Management
– Surface Area Configuration
– Server Security
– Facet: Vista de un conjunto de propiedades relacionadas.
– Conditions: Conjunto de reglas que deben cumplirse en una pólitica.
– Policies: Permite comprobar automáticamente o bajo demanda un seríe de condiciones.
• Elimina la cuenta SA.
• Cambia el puerto por defecto.
Instalación y configuración
8

9. 9
Demo: Definir una política para
evitar nombres de login
reveladores

10. 10
Autenticación

11. • La autenticación de SQL Server se basa en Logins.
• Hay diferentes tipos de Logins:
– Windows authentication.
o Usuarios o grupos de Windows
o Contraseña y políticas de contraseña controladas por Windows/Active Directory.
– SQL Server authentication
o Usuarios controlados por SQL Server.
o Contraseña y políticas de contraseña controladas SQL Server.
o ¿Cómo cambiar contraseñas?
– De cualquier login si tiene el privilegio CHANGE ANY LOGIN
– De su propio usuario especificando su antigua contraseña:
ALTER LOGIN LoginName WITH
PASSWORD=N’MyNewPassword’
OLD_PASSWORD=N’MyOldPassword'
Autenticación
11

12. 12
Demo: Crear un login

13. • SQL Server usa un esquema de autorización en dos niveles
– Logins: Usados para conectar a instacias de SQL Server y determinar permisos a
nivel de servidor.
– User: Usados para determinar los permisos en una determinada base de datos.
• La autenticación se hace a nivel de login, no de usuario.
• Cada usuario de base de datos esta mapeado a un login concreto.
• Un usuario puede tener permisos a nivel de servidor y no a nivel de base de datos.
• Podemos asignar permisos a nivel de servidor directamente a un login (no es recomendable
más que en casos excepcionales).
Autorización
13

14. • Los principals son entidades que pueden acceder a recursos de SQL Server.
• Principals a nivel de SQL Server
– SQL Server authentication Login
– Windows authentication login for a Windows user
– Windows authentication login for a Windows group
– Azure Active Directory authentication login for a AD user
– Azure Active Directory authentication login for a AD group
– Server Role
• Principals a nivel de base de datos:
– Database User
– Database Role
– Application Role
Principals
14

15. • Hay una serie de roles predefinidos a nivel del
servidor y de base de datos.
– Deberían se suficientes en la mayoría de
escenarios.
– Piénsalo bien antes de complicar tu
seguridad.
• Los roles pueden pertenecer a otros roles.
• Podemos asignar usuarios a roles.
• Podemos otorgar permisos sobre elementos
(securables) a los diferentes roles.
• Cada securable tiene diferentes permisos.
• Hay securables a nivel de servidor y a nivel de base
de datos.
• Si otorgamos un privilegio con WITH GRANT el
usuario puede otorgar ese privilegio a otros usuarios
(es algo a evitar).
• No podemos cambiar los permisos de los roles
predefinidos, solo quien pertenece a ellos.
Roles
15

16. Roles de servidor
16

17. Roles de base de datos
17

18. • Un rol de aplicación es un rol a nivel de base de datos.
• Los roles de aplicación identifican los permisos de una aplicación, con
independencia de que usuario se conecta.
• La aplicación se conecta con un usuario y su contraseña.
• La aplicación establece su rol ejecutando sp_setapprole con el nombre de
rol y la contraseña como parámetro.
• Los permisos desde ese momento seran los del rol de aplicación.
• Por defecto los permisos son los de guest.
• Simplifica la seguridad en muchas ocasiones.
• El acceso solo se puede lograr a través de la aplicación
Roles de aplicación
18

19. • Podemos hacer que nuestras sentencias SQL se ejecuten como otro usuario u
otro login.
– EXECUTE AS LOGIN = 'loginName';
– EXECUTE AS USER = 'userName’;
• Por defecto solo pueden hacer:
– SYSADMIN para todas la bases de datos.
– Miembros de db_owner en la base de datos que poseen.
• Típico uso:
– CREATE USER proxyUser WITHOUT LOGIN
– CREATE PROCEDURE [procName] WITH EXECUTE AS 'proxyUser' AS ...
Impersonación
19

20. 20
Demo: Usuarios y Roles

21. • Todo objeto de SQL Server tiene un owner.
• Por defecto es el onwer del esquema en que se crea.
• Si un usuario posee un objeto y borramos el usuario, debemos transferir la propiedad del objeto.
• Si el propietario de un objeto es un usuario ese objeto tendrá acceso a el resto de elementos de ese
usuario.
– Chained Ownership
• Ojito con esto, prevalece sobre DENY.
– Tabla y procedimiento almacenando con el mismo owner.
– Damos otro usuario U GRANT EXECUTE sobre el procedimiento que devuelve datos de una tabla.
– Denegamos lecturas sobre la tabla DENY READ al mismo usuario U.
– Como el procedimiento almacenado y la tabla tienen el mismo owner el usuario U ¡puede acceder
al los datos de la tabla pese al DENY READ!
• Si un usuario tiene permisos sobre un objeto y este objeto referencia otros con el mismo owner, solo se
comprueban los permisos sobre el primer objeto.
• Si el usuario es pertenece al rol SYSADMIN su schema por defecto es siempre dbo.
Owners
21

22. • Todos los objetos pertenecen a un schema.
• El schema por defecto es dbo.
• Los schemas como cualquier securable tienen un owner (usuario, rol de base de datos o rol
de aplicación).
• Podemos asignar un esquema por defecto a usuarios.
• Podemos crear nuestros propios esquemas.
– El owner por defecto será quien cree el esquema.
– Podemos asignar como owner de un esquema a un role o un usuario.
• Los esquemas se pueden usar únicamente como unidades lógicas.
• Podemos dar permisos sobre esquemas, una forma efectiva de dar permisos sobre todos
los objetos del esquema.
• Cuando creamos un objeto dentro de un esquema, el propietario será por defecto, el
propietario del esquema.
Schemas
22

23. 23
Demo: Owners y Schemas

24. 24
Always encryted

25. • Previene la revelación de datos sensibles.
• Encriptación de lado cliente mediante claves no reveladas al
lado servidor.
• Soporta consultas sobre datos encriptados: comparación, joins,
group by…
• Casi transparente a nivel de aplicación.
• Permite almacenar datos sensibles fuera de nuestros limites de
confianza (por ejemplo en SQL Azure)
• Los datos están a salvo de usuarios con altos privilegios.
Always encrypted
25

26. Aways encrypted: Cómo funciona
SQL Server or SQL Database
ADO .NET
Name
Wayne Jefferson
Name
0x19ca706fbd9a
Result SetResult Set
Client
Name SSN Country
0x19ca706fbd9a 0x7ff654ae6d USA
dbo.Customers
ciphertext
"SELECT Name FROM Customers WHERE SSN = @SSN",
0x7ff654ae6d
ciphertext
"SELECT Name FROM Customers WHERE SSN = @SSN",
"111-22-3333"
Los datos y sus claves nunca se ven en el
servidor.
trust boundary

27. • Randomized encryption
– Encrypt('123-45-6789') = 0x17cfd50a
– Otra vez: Encrypt('123-45-6789') = 0x9b1fcf32
– Permite obtener los datos encriptados pero no operaciones sobre ellos.
– Más segura.
– Por ejemplo para datos de un diagnóstico médico.
• Deterministic encryption
– Encrypt('123-45-6789') = 0x85a55d3f
– Otra vez: Encrypt('123-45-6789') = 0x85a55d3f
– Permite obtener los datos encriptados pero no operaciones sobre ellos.
– Por ejemplo WHERE, joins, distinct, group by
– Por ejemplo para el DNI del usuario.
Aways encrypted : Tipos de encriptación
27

28. Always encrypted: Gestión de claves
Security
Officer
Column
Encryption Key
(CEK)
Column
Master Key
(CMK)
Encrypted
CEK
CMK
1. Generar CEKs y CMK
2. Encriptar CEK
3. Almacenar CMK de manera segura
4. Subir la CEK a la DB
CMK Store:
• Certificate Store
• HSM
• Azure Key Vault
• …
Database
Encrypted
CEK

29. 29
Demo: Always encrypted

30. 30
Encriptación transparente de datos
Transparent Data Encryption (TDE)

31. • Encripta los datos antes de escribirlos en disco.
– Archivos de datos.
– Backups.
• Más selectivo que encriptar volúmenes enteros.
• La desencriptación es totalmente transparente.
• Impide restaurar backups en otro servidor para acceder a los datos salvo
que tengamos el certificado.
Transparent data encryption
31

32. Transparent data encryption en SQL Azure
32

33. Transparent data encryption en SQL Azure
33

34. 34
Demo: Transparent Data Encryption (TDE)

35. 35
Seguridad a nivel de filas
Row-Level Security (RLS)

36. • Funcion predicado:
– Función tabla-valor definida por el usuario que implementa la lógica de
seguridad.
– Puede ser compleja, e incluso incluir joins con otras tablas.
• Predicado de seguridad
– Aplica un predicado función automáticamente a un tabla.
– Dos tipos
o Predicados de filtro.
o Predicados de bloqueo.
• Política de seguridad:
– Colección de predicados para gestionar la seguridad RLS.
• Recomendaciónes:
– Crear un esquema separado para RLS.
– Evitar conversions de tipos en funciones de predicado.
– Evitar recursividad en funciones de predicado.
– Evite la lógica del predicado que dependa de opciones SET específicas
de la sesión.
– Evitar elementos no deterministas en funciones de predicado.
Row-Level Security: Conceptos
36

37. • Predicados de filtro
– Filtran en modo silencioso las filas disponibles para operaciones SELECT, UPDATE y DELETE.
– Si algo no cumple el predicado no aparece en la SELECT y no se puede modificar con UPDATE o DELETE.
– Nada te impide actualizar un registro de tal manera que deje de ser accesible para ti.
• Predicados de bloqueo
– Los predicados AFTER INSERT y AFTER UPDATE pueden impedir que los usuarios actualicen las filas con
valores que infrinjan el predicado.
– Los predicados BEFORE UPDATE pueden impedir que los usuarios actualicen las filas que actualmente
infrinjan el predicado.
– Los predicados BEFORE DELETE pueden bloquear las operaciones de eliminación.
Row-Level Security: Tipos de predicados
37

38. 38
Enmascaramiento dinámico de datos
Dynamic Data Masking (DDM)

39. • Evita exponer datos sensibles a usuarios no privilegiados.
• Ofuscación no encriptación.
• Es transparente para aplicaciones cliente.
• Se puede combinar con Always Encrypted pero no con Transparent
Data Encryption.
• Funciones predefinidas únicamente:
– default()
o default(string) = ‘XXXX’
o default(num) = 0
o default(date) = 01.01.1900 00:00:00.0000000
o default(binary) = (byte)0
– email(‘rcorral@plaincocnepts.com’) = rxxxxx@xxxxxx.com
– random(num, start, end) = randomNum[start,end]
– partial(string, prefix,[padding],suffix)
o partial(‘abracadabra’, 2,[*****],3) = ab*****bra
Dynamic Data Masking
39

40. • No evita actualizaciones sobre los datos enmascarados.
• Si el usuario no tiene privilegios de UNMASK:
– SELECT INTO o INSERT INTO copiará los datos enmascarados.
– DDM se aplica en operaciones de exportación e importación (ojo a la posible perdida de datos).
Dynamic Data Masking
40

41. 41
Demo: Dynamic Data Masking (DDM)

42. 42
Auditoria

43. • ¿Quién cambia que? ¿En que momento? ¿Qué datos había antes? ?Quien hace uso de privilegios?
• Típico escenario LOPD.
• Extended events (EX)
– Mas adecuados para otros tipos de auditoría.
• Triggers
– Problemas de rendimiento, bloqueos…
• Change tracking (CT)
– No está diseñado para auditoria sino para ETL.
– Puede servir en algunas escenarios.
– No da información completa.
• Change Data Capture
– Información más completa que CT.
– Mejor rendimiento que triggers.
– No diseñado para auditoria: no sabemos quien ni cuando se hicieron los cambios.
• SQL Server Audit
– Diseñado específicamente para auditoría.
– Basado en XE
– Loguea las queries ejecutadas contra los objetos monitorizados.
– Dos niveles: servidor y base de datos.
Auditoria
43

44. • ¿Quién hace uso de privilegios?
• C2 (Deprecado)
• Common Criteria Compliance
– Proporciona estadísticas de logins
o sys.dm_exec_sessions
Auditoria
44

45. • Tablas de historificación: System-Versioned Temporal Tables
Auditoria
45

46. 46
Demo: SQL Server Audit

47. 47
Demo: System-Versioned
Temporal Tables

48. 48
Demo: Herramienta de evaluación
de vulnerabilidades

49. 49
Backups

50. Backups
50
• Modo de recuperación
– Simple
– Full
– Bulk logged
• Tipos de copia
– Completa
– Diferencial
– De Log de transacciones
o Necesaria para poder recuperar
cualquier momento del tiempo.

51. 51
Buenas practicas de desarrollo

52. • Evita no parametrizar tus consultas.
– Rendimiento.
– Para evitar inyecciones SQL.
• Utiliza conexiones encriptadas.
– "[...];Encrypt=True;TrustServerCertificate=True“
• Fuerza las conexiones encriptadas.
Buenas prácticas de desarrolo
52

53. 53
SQL Azure

54. • Casi todo lo visto está soportado.
• La mayoría de cosas de manera mas simple.
• Auditing & Threat Detection.
• Vulnerability Assetment.
• Dynamic Data Masking.
• Transparent Data Encryption.
• Always Encrypted (desde SSMS).
• Autenticación contra AAD.
SQL Azure
54

55. 55
Demo: SQL Azure

56. 56
¿Preguntas?

57. ¡GRACIAS!
www.plainconcepts.com
@plainconcepts

58. www.plainconcepts.com
MADRID
Paseo de la Castellana 163, 10º
28046 Madrid. España
T. (+34) 91 5346 836
BILBAO
Calle Ledesma 10-bis 3º
48001 Bilbao. España
T. (+34) 94 6073 371
BARCELONA
Carrer Compte d’Urgell 240 4º 1A
08036 Barcelona. España
T. (+34) 93 7978 566
SEVILLA
Avenida de la innovación s/n
Edificio Renta Sevilla, 3º A
41020 Sevilla. España
DUBAI
Dubai Internet City. Building 1
73030 Dubai. EAU
T. (+971) 4 551 6653
LONDON
Impact Hub Kings Cross
24B York Way, N1 9AB
London. UK
SEATTLE
1511, Third Ave
Seattle WA 98101. USA
T. (+1) 206 708 1285