Prácticas recomendadas de seguridad para SQL Server

Se aplica a: SQL Server Azure SQL Database Azure SQL Managed Instance

En este artículo se proporciona información sobre los procedimientos recomendados y las directrices que ayudan a establecer la seguridad de SQL Server. Para una revisión completa de las características de seguridad de SQL Server, consulte Protección de SQL Server.

Para obtener procedimientos recomendados de seguridad de productos específicos, consulte Azure SQL Database y SQL Managed Instance y SQL Server en Azure Virtual Machines.

Información general

Una metodología de seguridad por capas proporciona una solución de defensa en profundidad al usar varias funcionalidades de seguridad destinadas a distintos ámbitos de seguridad. Las características de seguridad disponibles en SQL Server 2016 y mejoradas en versiones posteriores ayudan a contrarrestar las amenazas de seguridad y proporcionan aplicaciones de base de datos bien protegidas.

Azure cumple diversos reglamentos y estándares del sector que permiten compilar una solución compatible con SQL Server que se ejecuta en una máquina virtual. Para obtener información acerca del cumplimiento normativo de Azure, consulte Centro de confianza de Azure.

Protección en el nivel de columna

A menudo, las organizaciones necesitan proteger los datos en el nivel de columna, ya que los datos relativos a clientes, empleados, secretos comerciales, datos de productos, atención sanitaria, financiera y otros datos confidenciales se almacenan a menudo en bases de datos de SQL Server. Las columnas confidenciales suelen incluir números de identificación o del seguro social, números de teléfono móvil, nombre, nombre de familia, identificación de cuentas financieras y cualquier otro dato que se pueda considerarse como datos personales.

Los métodos y características mencionados en esta sección elevan el nivel de protección en el nivel de columna con una sobrecarga mínima y sin necesidad de realizar cambios exhaustivos en el código de la aplicación.

Use Always Encrypted para cifrar los datos en reposo y a través de la conexión. Las bibliotecas cliente solo descifran los datos cifrados en el nivel de cliente de la aplicación. Use el cifrado aleatorio sobre el determinista siempre que sea posible. Always Encrypted con enclaves seguros puede mejorar el rendimiento de las operaciones de comparación como BETWEEN, IN, LIKE, DISTINCT, Joins y más para escenarios de cifrado aleatorio.

Use Enmascaramiento dinámico de datos (DDM) para ofuscar los datos en el nivel de columna cuando Always Encrypted no es una opción disponible. Enmascaramiento dinámico de datos (DDM) no es compatible con Always Encrypted. Use Always Encrypted sobre el enmascaramiento dinámico de datos siempre que sea posible.

También puede conceder permisos GRANT en el nivel de columna a una tabla, vista o función con valores de tabla. Tenga en cuenta lo siguiente: Solo es posible conceder los permisos SELECT, REFERENCES y UPDATE para una columna. Un permiso DENY de nivel de tabla no tiene prioridad sobre uno GRANT de nivel de columna.

Protección en el nivel de fila

Seguridad de nivel de fila (RLS) permite usar el contexto de ejecución del usuario para controlar el acceso a las filas de una tabla de base de datos. RLS garantiza que los usuarios solo puedan ver el registro que les pertenece. Esto proporciona a la aplicación una seguridad de "nivel de registro" sin tener que realizar cambios significativos en la aplicación.

La lógica de negocios se encapsula dentro de funciones con valores de tabla controladas por una directiva de seguridad que activa y desactiva la funcionalidad de RLS. La directiva de seguridad también controla los predicados FILTER y BLOCK enlazados a las tablas con las que funciona RLS. Use Seguridad de nivel de fila (RLS) para limitar los registros que se devuelven al usuario que realiza la llamada. Use SESSION_CONTEXT (T-SQL) para los usuarios que se conectan a la base de datos a través de una aplicación de nivel intermedio donde los usuarios de la aplicación comparten la misma cuenta de SQL Server. Para obtener un rendimiento y una capacidad de administración óptimos, siga los procedimientos recomendados de seguridad de nivel de fila.

Encriptación de archivos

Cifrado de datos transparente (TDE) protege los datos en el nivel de archivo proporcionando cifrado en reposo a los archivos de base de datos. Cifrado de datos transparente (TDE) garantiza que los archivos de base de datos, los archivos de copia de seguridad y los archivos tempdb no se puedan adjuntar y leer sin los certificados adecuados que descifran los archivos de base de datos. Sin Cifrado de datos transparente (TDE), es posible que un atacante se haga con el control de los medios físicos (unidades o cintas de copia de seguridad) y restaure o adjunte la base de datos para leer el contenido. Cifrado de datos transparente (TDE) se admite para trabajar con todas las demás funcionalidades de seguridad de SQL Server. El cifrado de datos transparente (TDE) realiza el cifrado y descifrado de E/S en tiempo real de los datos y los archivos de registro. El cifrado TDE usa una clave de cifrado de base de datos (DEK) que se almacena en la base de datos de usuario. La clave de cifrado de base de datos también se puede proteger utilizando un certificado que se protege mediante la clave maestra de base de datos de la base de datos master.

Use TDE para proteger los datos en reposo, las copias de seguridad y tempdb.

Informes y auditoría

Para auditar SQL Server, cree una directiva de auditoría en el nivel de servidor o de base de datos. Una directiva de servidor se aplica a todas las bases de datos recién creadas en el servidor. Para simplificar, habilite la auditoría de nivel de servidor y permita que la auditoría de nivel de base de datos herede la propiedad de nivel de servidor para todas las bases de datos.

Audite tablas y columnas con datos confidenciales a los que se les han aplicado medidas de seguridad. Si una tabla o columna es lo suficientemente importante como para necesitar protección mediante una funcionalidad de seguridad, debe considerarse lo suficientemente importante como para auditarla. Es especialmente importante auditar y revisar periódicamente las tablas que contienen información confidencial, pero en las que no es posible aplicar las medidas de seguridad deseadas debido a algún tipo de limitación de la aplicación o la arquitectura.

Identidades y autenticación

SQL Server admite dos modos de autenticación, el modo de autenticación de Windows y el "modo de autenticación de SQL Server y Windows" (modo mixto).

Los inicios de sesión son distintos de los usuarios de base de datos. Primero, debe asignar inicios de sesión o grupos de Windows a usuarios o roles de base de datos en una operación independiente. A continuación, conceda permisos a usuarios, roles de servidor o roles de base de datos para acceder a objetos de base de datos.

SQL Server admite los siguientes tipos de inicios de sesión:

• Una cuenta de usuario local de Windows o una cuenta de dominio de Active Directory: SQL Server usa Windows para autenticar cuentas de usuario de Windows.
• Grupo de Windows: conceder acceso a un grupo de Windows otorga acceso a todos los inicios de sesión de usuario de Windows que son miembros del grupo. Al quitar un usuario de un grupo, se quitan los derechos del usuario que provenía del grupo. La pertenencia a grupos es la estrategia preferida.
• Inicio de sesión de SQL Server: SQL Server almacena el nombre de usuario y un hash de la contraseña en la base de datos master.
• Los usuarios de la base de datos independiente autentifican las conexiones de SQL Server en el nivel de la base de datos. Una base de datos independiente es una base de datos que está aislada de otras bases de datos y de la instancia de SQL Server (y de la base de datos master) que hospeda la base de datos. SQL Server admite usuarios de base de datos independientes para la autenticación de Windows y SQL Server.

Las siguientes recomendaciones y procedimientos recomendados ayudan a proteger las identidades y los métodos de autenticación:

• Use estrategias de seguridad basada en roles con privilegios mínimos para mejorar la administración de la seguridad.

  • Es habitual colocar usuarios de Active Directory en grupos de AD; los grupos de AD deben existir en roles de SQL Server y los roles de SQL Server deben tener los permisos mínimos necesarios para la aplicación.

• En Azure, use la seguridad con privilegios mínimos mediante el uso de controles de acceso basado en rol (RBAC)

• Elija la autenticación de Active Directory en lugar de la de SQL Server siempre que sea posible y, especialmente, elija Active Directory en vez de almacenar la seguridad en el nivel de aplicación o base de datos.

  • Si un usuario deja la empresa, es fácil deshabilitar la cuenta.
  • También es fácil quitar usuarios de grupos cuando los usuarios cambian de roles o abandonan la organización. La seguridad de grupo se considera un procedimiento recomendado.

• Use la autenticación multifactor en las cuentas que tienen acceso de nivel de equipo, incluidas las cuentas que usan RDP para iniciar sesión en la máquina. Esto ayuda a protegerse contra el robo o las pérdidas de credenciales, ya que la autenticación basada en contraseña de un solo factor es una forma más débil de autenticación con credenciales en riesgo de verse comprometidas o dadas por error.

• Requerir contraseñas seguras y complejas que no se puedan adivinar fácilmente y que no se utilicen para otras cuentas o propósitos. Actualice periódicamente las contraseñas y aplique directivas de Active Directory.

• Las cuentas de servicio administradas de grupo (sMSA) proporcionan administración automática de contraseñas, administración simplificada de nombres de entidad de seguridad de servicio (SPN) y la capacidad de delegar la administración a otros administradores.

  • Cuando se usa una gMSA como entidad de servicio, el sistema operativo Windows administra la contraseña de la cuenta en lugar de recurrir al administrador.
  • gMSA actualiza automáticamente las contraseñas de cuenta sin reiniciar los servicios.
  • gMSA reduce el nivel de superficie administrativa y mejora la separación de tareas.

• Minimice los derechos concedidos a la cuenta de AD de DBA. Considere la posibilidad de separar las tareas que limitan el acceso a la máquina virtual, la capacidad de iniciar sesión en el sistema operativo, la capacidad de modificar los registros de errores y auditorías y la capacidad de instalar aplicaciones o características.

• Considere la posibilidad de quitar cuentas de DBA del rol sysadmin y conceder CONTROL SERVER a cuentas de DBA en lugar de convertirlas en miembros del rol sysadmin. El rol de administrador del sistema no respeta DENY mientras que CONTROL SERVER sí.

Linaje de datos e integridad de datos

Mantener registros históricos de los cambios de datos a lo largo del tiempo puede ser beneficioso para abordar los cambios accidentales en los datos. También puede ser útil para la auditoría de cambios de aplicación y puede recuperar elementos de datos cuando un actor malintencionado ha introducido cambios de datos que no estaban autorizados.

• Use las tablas temporales para conservar las versiones de registros a lo largo del tiempo y para ver los datos tal y como han pasado en el período de vida del registro para proporcionar una vista histórica de los datos de la aplicación.
• Las tablas temporales se pueden usar para proporcionar una versión de la tabla actual en cualquier momento dado.

Evaluación y herramientas de evaluación de seguridad

Las siguientes herramientas de configuración y evaluación siguientes abordan la seguridad del área de superficie, identificar oportunidades de seguridad de datos y proporcionar una evaluación de procedimientos recomendados de la seguridad del entorno de SQL Server en el nivel de instancia.

• Configuración de área de superficie: se recomienda que habilite solo las características que necesita el entorno para minimizar el número de características que pueden ser atacadas por un usuario malintencionado.
• Evaluación de vulnerabilidades para SQL Server (SSMS): la evaluación de vulnerabilidades de SQL es una herramienta de SSMS v17.4+ que ayuda a detectar, realizar un seguimiento y corregir posibles vulnerabilidades de la base de datos. La evaluación de vulnerabilidades es una herramienta valiosa para mejorar la seguridad de la base de datos y se ejecuta en el nivel de base de datos, por base de datos.
• Clasificación y detección de datos de SQL (SSMS): es habitual que los DBA administren servidores y bases de datos y no sean conscientes de la confidencialidad de los datos contenidos en la base de datos. Clasificación y detección de datos agrega la capacidad de detectar, clasificar, etiquetar e informar sobre el nivel de confidencialidad de los datos. Clasificación detección de datos se admite a partir de SSMS 17.5.

Amenazas de SQL comunes

Ayuda a saber cuáles son algunas de las amenazas comunes que ponen en riesgo a SQL Server:

• Inyección de código SQL: es un ataque en el que se inserta código malintencionado en cadenas que posteriormente se pasan a una instancia de SQL Server para su ejecución.
  • El proceso de inyección consiste en finalizar una cadena de texto y anexar un nuevo comando. Como el comando insertado puede contener cadenas adicionales que se hayan anexado al mismo antes de su ejecución, el atacante pone fin a la cadena inyectada con una marca de comentario --.
  • SQL Server ejecutará cualquier consulta válida sintácticamente que se reciba.
• Tenga en cuenta los ataques de canal lateral, el malware y otras amenazas.

Inyección de código SQL

Para minimizar el riesgo de una inyección SQL, tenga en cuenta los siguientes elementos:

• Revise cualquier proceso SQL que construya instrucciones SQL para las vulnerabilidades de inyección.
• Construya instrucciones SQL generadas dinámicamente de forma parametrizada.
• Los desarrolladores y administradores de seguridad deben revisar todo el código que llama a EXECUTE, EXEC o sp_executesql.
• No permitir los siguientes caracteres de entrada:
  • ;: Delimitador de consultas
  • ': Delimitador de cadenas de datos de caracteres
  • --: Delimitador del comentario de una sola línea.
  • /* ... */: Delimitadores de comentarios.
  • xp_: Procedimientos almacenados extendidos del catálogo, como xp_cmdshell.
    • No se recomienda usar xp_cmdshell en ningún entorno de SQL Server. Use SQLCLR en su lugar o busque otras alternativas debido a los riesgos que xp_cmdshell puede introducir.
• Valide siempre las entradas del usuario y limpie las salidas de error de que se desbordan y exponen al atacante.

Riesgos de canal lateral

Para minimizar el riesgo de un ataque de canal lateral, tenga en cuenta lo siguiente:

• Asegúrese de que se aplican las revisiones más recientes de la aplicación y del sistema operativo.
• En el caso de las cargas de trabajo híbridas, asegúrese de que se aplican las revisiones de firmware más recientes para cualquier hardware local.
• En Azure, para cargas de trabajo y aplicaciones altamente confidenciales, puede agregar protección adicional contra ataques de canal lateral con máquinas virtuales aisladas, hosts dedicados o mediante el uso de máquinas virtuales de proceso confidencial, como las series DC y máquinas virtuales que usan los procesadores EPYC AMD de 3ª generación.

Amenazas de infraestructura

Tenga en cuenta las siguientes amenazas comunes de infraestructura:

• Acceso por fuerza bruta: el atacante intenta autenticarse con varias contraseñas en cuentas diferentes hasta que se encuentra una contraseña correcta.
• Difusión/Averiguación de contraseña: los atacantes prueban una contraseña diseñada cuidadosamente con todas las cuentas de usuario conocidas (una contraseña para muchas cuentas). Si se produce un error en la distribución inicial de contraseñas, lo intentan de nuevo, usando una contraseña diseñada cuidadosamente diferente, normalmente esperando una cantidad de tiempo establecida entre los intentos para evitar la detección.
• Los ataques de ransomware son un tipo de ataque dirigido en el que se usa malware para cifrar datos y archivos, lo que impide el acceso a contenido importante. Los atacantes intenta obtener dinero de las víctimas, normalmente en forma de criptomonedas, a cambio de la clave de descifrado. La mayoría de las virus ransomware comienzan con mensajes de correo electrónico con datos adjuntos que intentan instalar ransomware o sitios web que hospedan kits de vulnerabilidades que intentan usar vulnerabilidades en exploradores web y otro software para instalar ransomware.

Riesgos de contraseña

Dado que no quiere que los atacantes adivinen fácilmente nombres de cuenta o contraseñas, los pasos siguientes ayudan a reducir el riesgo de que se descubran contraseñas:

• Cree una cuenta de administrador local única que no se llame Administrador.
• Use contraseñas seguras complejas para todas sus cuentas. Para más información sobre cómo crear una contraseña segura, vea el artículo Crear una contraseña segura.
• De forma predeterminada, Azure selecciona la Autenticación de Windows durante la instalación de la máquina virtual de SQL Server. Por lo tanto, el inicio de sesión de SA está deshabilitado y el programa de instalación asigna una contraseña. Se recomienda no usar ni habilitar el inicio de sesión de SA. Si debe tener un inicio de sesión de SQL, use una de las estrategias siguientes:

  • Cree una cuenta de SQL con un nombre único que sea miembro de sysadmin. Puede hacerlo desde el portal si habilita Autenticación de SQL durante el aprovisionamiento.

    Sugerencia

    Si no habilita la autenticación de SQL durante el aprovisionamiento, debe cambiar manualmente el modo de autenticación a Modo de autenticación de Windows y SQL Server. Para obtener más información, consulte Cambiar el modo de autenticación del servidor.

  • Si tiene que usar el inicio de sesión de SA, habilite el inicio de sesión después del aprovisionamiento y asigne una nueva contraseña segura.

Riesgos de ransomware

Tenga en cuenta lo siguiente para minimizar los riesgos de ransomware:

• La mejor estrategia para protegerse contra ransomware es prestar especial atención a las vulnerabilidades de RDP y SSH. Además, tenga en cuenta las recomendaciones siguientes:
  • Usa firewalls y bloqueo de puertos
  • Asegurarse de que se aplican las actualizaciones de seguridad del sistema operativo y de la aplicación más recientes
  • Usar cuentas de servicio administradas de grupo (gMSA)
  • Limitar el acceso a las máquinas virtuales
  • Requerir acceso Just-In-Time (JIT) y Azure Bastion
  • Mejorar la seguridad del área de superficie evitando la instalación de herramientas como sysinternals y SSMS en el equipo local
  • Evitar instalar características de Windows, roles y habilitar servicios que no son necesarios
  • Además, debe haber una copia de seguridad completa normal programada que esté protegida por separado de una cuenta de administrador común para que no pueda eliminar copias de las bases de datos.

Contenido relacionado

• Proteger SQL Server
• Azure SQL Database y SQL Managed Instance
• SQL Server en máquinas virtuales de Azure