![• 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](https://image.slidesharecdn.com/sqlserversecurity-180201204424/85/Seguridad-en-SQL-Server-19-320.jpg)
![• 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](https://image.slidesharecdn.com/sqlserversecurity-180201204424/85/Seguridad-en-SQL-Server-39-320.jpg)
![• 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](https://image.slidesharecdn.com/sqlserversecurity-180201204424/85/Seguridad-en-SQL-Server-52-320.jpg)
Subido porRodrigo Corral
Seguridad en SQL Server
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.
Más contenido relacionado
Similar a Seguridad en SQL Server
Seguridad en SQL Server
- 1. Seguridad en SQL Server RodrigoCorral 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 Alwaysencrypted 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.
- 4. • Los datosson 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.
- 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 deautenticació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 soloaquellas 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 unapolítica para evitar nombres de login reveladores
- 10.
- 11. • La autenticaciónde 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 unlogin
- 13. • SQL Serverusa 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 principalsson 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 unaserie 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.
- 17. Roles de basede datos 17
- 18. • Un rolde 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 hacerque 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 yRoles
- 21. • Todo objetode 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 losobjetos 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 ySchemas
- 24.
- 25. • Previene larevelació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ómofunciona 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ónde 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.
- 30. 30 Encriptación transparente dedatos Transparent Data Encryption (TDE)
- 31. • Encripta losdatos 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 encryptionen SQL Azure 32
- 33. Transparent data encryptionen SQL Azure 33
- 34. 34 Demo: Transparent DataEncryption (TDE)
- 35. 35 Seguridad a nivelde 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 defiltro – 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 dedatos Dynamic Data Masking (DDM)
- 39. • Evita exponerdatos 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 evitaactualizaciones 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 DataMasking (DDM)
- 42.
- 43. • ¿Quién cambiaque? ¿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 haceuso de privilegios? • C2 (Deprecado) • Common Criteria Compliance – Proporciona estadísticas de logins o sys.dm_exec_sessions Auditoria 44
- 45. • Tablas dehistorificación: System-Versioned Temporal Tables Auditoria 45
- 46. 46 Demo: SQL ServerAudit
- 47.
- 48. 48 Demo: Herramienta deevaluación de vulnerabilidades
- 49.
- 50. Backups 50 • Modo derecuperació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 dedesarrollo
- 52. • Evita noparametrizar 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.
- 54. • Casi todolo 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.
- 56.
- 57.
- 58. www.plainconcepts.com MADRID Paseo de laCastellana 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