Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Seguridad en SQL Server

2,998 views

Published on

Presentación sobre la seguridad en SQL Server:
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

Published in: Software
  • Be the first to comment

Seguridad en SQL Server

  1. 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. 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. 3 Introducción
  4. 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. 5 Instalación y configuración
  6. 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. 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. 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. 9 Demo: Definir una política para evitar nombres de login reveladores
  10. 10. 10 Autenticación
  11. 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. 12 Demo: Crear un login
  13. 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. 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. 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. 16. Roles de servidor 16
  17. 17. Roles de base de datos 17
  18. 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. 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. 20 Demo: Usuarios y Roles
  21. 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. 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. 23 Demo: Owners y Schemas
  24. 24. 24 Always encryted
  25. 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. 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. 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. 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. 29 Demo: Always encrypted
  30. 30. 30 Encriptación transparente de datos Transparent Data Encryption (TDE)
  31. 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. 32. Transparent data encryption en SQL Azure 32
  33. 33. Transparent data encryption en SQL Azure 33
  34. 34. 34 Demo: Transparent Data Encryption (TDE)
  35. 35. 35 Seguridad a nivel de filas Row-Level Security (RLS)
  36. 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. 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. 38 Enmascaramiento dinámico de datos Dynamic Data Masking (DDM)
  39. 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. 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. 41 Demo: Dynamic Data Masking (DDM)
  42. 42. 42 Auditoria
  43. 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. 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. 45. • Tablas de historificación: System-Versioned Temporal Tables Auditoria 45
  46. 46. 46 Demo: SQL Server Audit
  47. 47. 47 Demo: System-Versioned Temporal Tables
  48. 48. 48 Demo: Herramienta de evaluación de vulnerabilidades
  49. 49. 49 Backups
  50. 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. 51 Buenas practicas de desarrollo
  52. 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. 53 SQL Azure
  54. 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. 55 Demo: SQL Azure
  56. 56. 56 ¿Preguntas?
  57. 57. ¡GRACIAS! www.plainconcepts.com @plainconcepts
  58. 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

×