Tutorial sobre las características de seguridad de SQL Server en Linux

Se aplica a:SQL Server en Linux

Si es usuario de Linux y no está familiarizado con SQL Server, las secciones siguientes le guiarán por algunas tareas de seguridad. Estas tareas no son exclusivas ni específicas de Linux, pero te dan una idea de áreas a investigar más a fondo. Cada ejemplo enlaza con la documentación detallada de esa área.

Los ejemplos de código de este artículo usan la base de datos de ejemplo de AdventureWorks2025 o AdventureWorksDW2025, que puede descargar de la página principal de Ejemplos de Microsoft SQL Server y proyectos de comunidad.

Creación de un inicio de sesión y un usuario de base de datos

Concede acceso a otros a SQL Server creando un inicio de sesión en la master base de datos con la CREATE LOGIN sentencia. Por ejemplo:

CREATE LOGIN Larry
    WITH PASSWORD = '<password>';

Caution

La contraseña debe seguir la directiva de contraseña predeterminada de SQL Server. De forma predeterminada, la contraseña debe tener al menos ocho caracteres y contener caracteres de tres de los siguientes cuatro conjuntos: mayúsculas, minúsculas, dígitos en base 10 y símbolos. Las contraseñas pueden tener hasta 128 caracteres. Use contraseñas lo más largas y complejas posible.

Las cuentas de inicio de sesión pueden conectarse a SQL Server y tener acceso a la base de datos master con permisos limitados. Para conectarse a una base de datos de usuario, un inicio de sesión necesita una identidad correspondiente en el nivel de base de datos, denominado usuario de base de datos. Los usuarios son específicos para cada base de datos, por lo que debes crearlos por separado en cada base de datos para poder acceder a ellos.

El siguiente ejemplo cambia a la AdventureWorks2025 base de datos y luego utiliza la CREATE USER instrucción para crear un usuario llamado Larry que se asigna al inicio de sesión llamado Larry. Aunque el inicio de sesión y el usuario están relacionados (mapeados entre sí), son objetos diferentes. El inicio de sesión es una entidad de seguridad de nivel de servidor. El usuario es un elemento principal de nivel de base de datos.

USE AdventureWorks2025;
GO

CREATE USER Larry;
GO

• Una cuenta de administrador de SQL Server puede conectarse a cualquier base de datos y crear más inicios de sesión y usuarios.
• Cuando creas una base de datos, te conviertes en el propietario de la base de datos y puedes conectarte a esa base de datos. Los propietarios de bases de datos pueden crear más usuarios.

Más adelante, puede autorizar otras credenciales de acceso para crear más credenciales de acceso concediéndoles el permiso ALTER ANY LOGIN. En una base de datos, se puede autorizar a otros usuarios para que creen más usuarios mediante la concesión del permiso ALTER ANY USER. Por ejemplo:

GRANT ALTER ANY LOGIN TO Larry;
GO

USE AdventureWorks2025;
GO

GRANT ALTER ANY USER TO Jerry;
GO

Ahora el inicio de sesión Larry puede crear más accesos y el usuario Jerry puede crear más usuarios.

Concesión de acceso con privilegios mínimos

Los administradores y propietarios de bases de datos suelen ser los primeros usuarios en conectarse a una base de datos de usuarios. Estas cuentas tienen todos los permisos en la base de datos. No uses estas cuentas para tareas que requieren menos permisos.

Cuando acabas de empezar, puedes asignar algunas categorías generales de permisos con los roles fijos de base de datos integrados. Por ejemplo, el rol fijo de base de datos db_datareader puede leer todas las tablas de la base de datos, pero no puede hacer cambios. Concede la membresía en un rol fijo de base de datos con la ALTER ROLE declaración. El siguiente ejemplo añade al usuario Jerry al rol de base de datos fija db_datareader .

USE AdventureWorks2025;
GO

ALTER ROLE db_datareader ADD MEMBER Jerry;

Para obtener una lista con los roles fijos de base de datos, vea Roles de nivel de base de datos.

Más tarde, cuando estés listo para configurar un acceso más preciso a tus datos (muy recomendable), crea tus propios roles de base de datos definidos por el usuario con la CREATE ROLE sentencia. Después, asigne permisos pormenorizados específicos a los roles personalizados.

Por ejemplo, las siguientes sentencias crean un rol de base de datos llamado Sales, otorgan al Sales grupo la capacidad de leer, actualizar y eliminar filas de la Orders tabla, y luego añadir al usuario Jerry al Sales rol.

CREATE ROLE Sales;

GRANT SELECT ON OBJECT::Orders TO Sales;
GRANT UPDATE ON OBJECT::Orders TO Sales;
GRANT DELETE ON OBJECT::Orders TO Sales;

ALTER ROLE Sales ADD MEMBER Jerry;

Para obtener más información sobre el sistema de permisos, consulte Introducción a los permisos del motor de base de datos.

Configurar la seguridad a nivel de fila

La seguridad a nivel de fila te permite restringir el acceso a filas en una base de datos según el usuario que ejecute una consulta. Esta función es útil para situaciones como garantizar que los clientes solo puedan acceder a sus propios datos o que los trabajadores solo puedan acceder a los datos de su departamento.

Los siguientes pasos explican cómo configurar a dos usuarios con acceso diferente a nivel de fila a la Sales.SalesOrderHeader tabla.

Crea dos cuentas de usuario para probar la seguridad a nivel de fila:

USE AdventureWorks2025;
GO

CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;

Conceda acceso de lectura en la tabla Sales.SalesOrderHeader a los dos usuarios:

GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;

Cree un esquema y una función con valores de tabla insertada. La función se devuelve 1 cuando una fila de la SalesPersonID columna coincide con el ID de un SalesPerson inicio de sesión, o cuando el usuario que ejecuta la consulta es el Manager usuario.

CREATE SCHEMA Security;
GO

CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
    SELECT 1 AS fn_securitypredicate_result
    WHERE ('SalesPerson' + CAST (@SalesPersonId AS VARCHAR (16)) = USER_NAME())
          OR (USER_NAME() = 'Manager')

Para crear una directiva de seguridad, agregue la función como un filtro y un predicado de bloqueo en la tabla:

CREATE SECURITY POLICY SalesFilter
    ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader,
    ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader
    WITH (STATE = ON);

Ejecuta las siguientes sentencias para consultar la SalesOrderHeader tabla como cada usuario. Compruebe que SalesPerson280 solo ve las 95 filas de sus propias ventas y que Manager puede ver todas las filas de la tabla.

EXECUTE AS USER = 'SalesPerson280';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

EXECUTE AS USER = 'Manager';

SELECT *
FROM Sales.SalesOrderHeader;

REVERT;

Modifica la política de seguridad para desactivarlo. Ahora los dos usuarios pueden acceder a todas las filas.

ALTER SECURITY POLICY SalesFilter
    WITH (STATE = OFF);

Habilitación del enmascaramiento dinámico de datos

El enmascaramiento dinámico de datos permite limitar la exposición de datos confidenciales a los usuarios de una aplicación mediante la enmascaramiento total o parcial de determinadas columnas.

Use una instrucción ALTER TABLE para agregar una función de enmascaramiento a la columna EmailAddress de la tabla Person.EmailAddress:

USE AdventureWorks2025;
GO

ALTER TABLE Person.EmailAddress
    ALTER COLUMN EmailAddress
        ADD MASKED WITH (FUNCTION = 'email()');

Crea un nuevo usuario TestUser con SELECT permiso en la tabla y luego ejecuta una consulta para TestUser ver los datos enmascarados:

CREATE USER TestUser WITHOUT LOGIN;

GRANT SELECT
    ON Person.EmailAddress TO TestUser;

EXECUTE AS USER = 'TestUser';

SELECT EmailAddressID,
       EmailAddress
FROM Person.EmailAddress;

REVERT;

Compruebe que la función de enmascaramiento cambia la dirección de correo electrónico del primer registro de:

EmailAddressID	Dirección de correo electrónico
1	ken0@adventure-works.com

en

EmailAddressID	Dirección de correo electrónico
1	kXXX@XXXX.com

Activación del cifrado de datos transparente

Un atacante puede robar archivos de base de datos de tu disco duro. Esto puede ocurrir si un atacante obtiene acceso elevado al sistema, si un empleado se queda con los archivos o si alguien roba el ordenador que los almacena.

El Cifrado de datos transparente (TDE) cifra los archivos de datos a medida que se almacenan en el disco duro. La master base de datos del Motor de base de datos de SQL Server tiene la clave de cifrado, de modo que el Motor de base de datos puede manipular los datos. Los archivos de base de datos no se pueden leer sin acceder a la clave. Los administradores de alto nivel pueden gestionar, hacer copias de seguridad y recrear la clave, de modo que solo las personas seleccionadas pueden mover la base de datos. Cuando activas TDE, SQL Server también cifra automáticamente la tempdb base de datos.

Dado que el Motor de base de datos puede leer los datos, TDE no protege contra accesos no autorizados por parte de administradores informáticos que pueden leer memoria directamente o acceder a SQL Server a través de una cuenta de administrador.

Configuración de TDE

• Cree una clave maestra
• Cree u obtenga un certificado protegido por la clave maestra
• Crea una clave de cifrado de base de datos y protégela con el certificado
• Configure la base de datos para que utilice el cifrado

Para configurar TDE se necesita el permiso CONTROL en la base de datos master y el permiso CONTROL en la base de datos de usuario. Normalmente, un administrador es el que configura TDE.

El siguiente ejemplo ilustra cómo cifrar y descifrar la AdventureWorks2025 base de datos con un certificado nombrado MyServerCert instalado en el servidor.

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My Database Encryption Key Certificate';
GO

USE AdventureWorks2025;
GO

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION ON;

Para quitar el TDE, ejecute el siguiente comando:

ALTER DATABASE AdventureWorks2025
    SET ENCRYPTION OFF;

SQL Server programa las operaciones de cifrado y descifrado en hilos en segundo plano. Puedes ver el estado de estas operaciones con las vistas de catálogo y las vistas de gestión dinámica en la lista que aparece más adelante en este artículo.

Advertencia

La clave de cifrado de la base de datos también cifra archivos de copia de seguridad de bases de datos que tienen TDE activado. Como consecuencia, al restaurar estas copias de seguridad debe estar disponible el certificado que protege la clave de cifrado de la base de datos. Además de hacer copias de seguridad de la base de datos, debes respaldar los certificados del servidor para evitar la pérdida de datos. Resultados de pérdida de datos si el certificado ya no está disponible. Para obtener más información, consulte SQL Server Certificates and Asymmetric Keys.

Para obtener más información sobre TDE, consulte Cifrado de datos transparente (TDE).

Configuración del cifrado de copia de seguridad

SQL Server puede cifrar datos mientras se crea una copia de seguridad. Al especificar el algoritmo y el sistema de cifrado (un certificado o una clave asimétrica) al crear una copia de seguridad, puede crear un archivo de copia de seguridad cifrado.

Advertencia

Siempre haz una copia de seguridad del certificado o clave asimétrica, y preferiblemente en una ubicación diferente a la del archivo de copia de seguridad que cifra. Sin el certificado o la clave asimétrica, no puede restaurar la copia de seguridad, lo que deja inutilizable el archivo de copia de seguridad.

En el ejemplo siguiente se crea un certificado y después una copia de seguridad protegida por el certificado.

USE master;
GO

CREATE CERTIFICATE BackupEncryptCert
    WITH SUBJECT = 'Database backups';
GO

BACKUP DATABASE [AdventureWorks2025]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2025.bak'
WITH COMPRESSION,
    ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
    STATS = 10;
GO

Para más información, consulte Cifrado de copia de seguridad.

Contenido relacionado

• Seguridad para el motor de base de datos de SQL Server y Azure SQL Database