Asegurar un grupo de SQL dedicado (anteriormente SQL DW) en Azure Synapse Analytics

Este artículo le guiará a través de los aspectos básicos de la protección del grupo de SQL dedicado (anteriormente SQL DW). En concreto, este artículo le ayudará a empezar a trabajar con recursos para limitar el acceso, proteger los datos y las actividades de supervisión mediante un grupo de SQL dedicado (anteriormente SQL DW).

Seguridad de la conexión

Seguridad de conexión hace referencia a cómo restringir y proteger las conexiones a la base de datos mediante reglas de firewall y cifrado de conexión.

Tanto el servidor SQL lógico como sus bases de datos usan reglas de firewall para rechazar los intentos de conexión de direcciones IP que no se han aprobado explícitamente. Para permitir conexiones desde la dirección IP pública de la aplicación o de la máquina cliente, primero debe crear una regla de firewall de nivel de servidor mediante Azure Portal, la API REST o PowerShell.

Como procedimiento recomendado, debe restringir los intervalos de direcciones IP permitidos a través del firewall de nivel de servidor tanto como sea posible. Para acceder a su grupo de SQL dedicado (anteriormente SQL DW) desde su equipo local, asegúrese de que el firewall de su red y de su equipo local permitan la comunicación saliente en el puerto TCP 1433.

El grupo SQL dedicado (anteriormente SQL DW) usa reglas de firewall de IP a nivel de servidor. No admite reglas de firewall IP a nivel de base de datos. Para más información, consulte Reglas de firewall de Azure SQL Database.

Las conexiones al grupo de SQL dedicado (anteriormente SQL DW) se cifran de forma predeterminada. Se omite la modificación de la configuración de conexión para deshabilitar el cifrado.

Autenticación

La autenticación hace referencia a cómo demostrar su identidad al conectarse a la base de datos. El grupo de SQL dedicado (anteriormente SQL DW) admite actualmente la autenticación de SQL Server con un nombre de usuario y una contraseña, y con el identificador de Entra de Microsoft.

Al crear el servidor para la base de datos, especificó un inicio de sesión de "administrador del servidor" con un nombre de usuario y una contraseña. Con estas credenciales, puede autenticarse en cualquier base de datos de ese servidor como propietario de la base de datos o "dbo" mediante la autenticación de SQL Server.

Sin embargo, como procedimiento recomendado, los usuarios de la organización deben usar una cuenta diferente para autenticarse. De este modo, puede limitar los permisos concedidos a la aplicación y reducir los riesgos de actividad malintencionada en caso de que el código de la aplicación sea vulnerable a un ataque por inyección de CÓDIGO SQL.

Para crear un usuario autenticado de SQL Server, conéctese a la base de datos maestra en el servidor con el inicio de sesión de administrador del servidor y cree un nuevo inicio de sesión de servidor. También es recomendable crear un usuario en la base de datos maestra. La creación de un usuario en la base de datos maestra permite que un usuario inicie sesión con herramientas como SSMS sin especificar un nombre de base de datos. También les permite usar el explorador de objetos para ver todas las bases de datos de un servidor.

-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

A continuación, conéctese al grupo de SQL dedicado (anteriormente SQL DW) con el inicio de sesión de administrador del servidor y cree un usuario de base de datos basado en el inicio de sesión del servidor que creó.

-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Para conceder a un usuario permiso para realizar operaciones adicionales, como crear cuentas de inicio de sesión o crear nuevas bases de datos, asignar al usuario a los roles Loginmanager y dbmanager en la base de datos maestra.

Para más información sobre estos roles adicionales y la autenticación en una instancia de SQL Database, consulte Administración de bases de datos e inicios de sesión en Azure SQL Database. Para obtener más información sobre cómo conectarse mediante el identificador de Entra de Microsoft, consulte Conexión mediante la autenticación de Microsoft Entra.

Authorization

La autorización hace referencia a lo que puede hacer dentro de una base de datos una vez autenticado y conectado. Los privilegios de autorización se determinan mediante la pertenencia a roles y los permisos. Como procedimiento recomendado, debe conceder a los usuarios los privilegios mínimos necesarios. Para administrar roles, puede usar los siguientes procedimientos almacenados:

EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data

La cuenta de administrador del servidor con la que se conecta es miembro de db_owner, que tiene autoridad para hacer cualquier cosa dentro de la base de datos. Guarde esta cuenta para implementar actualizaciones de esquema y otras operaciones de administración. Use la cuenta "ApplicationUser" con permisos más limitados para conectarse desde la aplicación a la base de datos con los privilegios mínimos necesarios para la aplicación.

Hay maneras de limitar aún más lo que un usuario puede hacer en la base de datos:

• Los permisos granulares permiten controlar qué operaciones puede realizar en columnas individuales, tablas, vistas, esquemas, procedimientos y otros objetos de la base de datos. Use permisos granulares para tener el máximo control y conceder los permisos mínimos necesarios.
• Los roles de base de datos distintos de db_datareader y db_datawriter se pueden usar para crear cuentas de usuario de aplicaciones más eficaces o cuentas de administración menos eficaces. Los roles fijos de base de datos integrados proporcionan una manera fácil de conceder permisos, pero pueden dar lugar a que se concedan más permisos de los necesarios.
• Los procedimientos almacenados se pueden usar para limitar las acciones que se pueden realizar en la base de datos.

En el ejemplo siguiente se concede acceso de lectura a un esquema definido por el usuario.

--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser

La administración de bases de datos y servidores desde Azure Portal o mediante la API de Azure Resource Manager se controla mediante las asignaciones de roles de la cuenta de usuario del portal. Para más información, consulte Asignación de roles de Azure mediante Azure Portal.

Seguridad a nivel de fila

Row-Level Seguridad permite controlar el acceso a las filas de una tabla de base de datos en función de las características del usuario que ejecuta una consulta (por ejemplo, pertenencia a grupos o contexto de ejecución). Use Row-Level Security para implementar conceptos de seguridad personalizados basados en etiquetas. Para más información, consulte Seguridad de nivel de fila.

Encryption

Cifrado de datos transparente (TDE) ayuda a protegerse contra la amenaza de actividad malintencionada mediante el cifrado y el descifrado de los datos en reposo. Al cifrar la base de datos, las copias de seguridad asociadas y los archivos de registro de transacciones se cifran sin necesidad de realizar cambios en las aplicaciones. TDE cifra el almacenamiento de una base de datos completa mediante el uso de una clave simétrica denominada clave de cifrado de base de datos.

En SQL Database, la clave de cifrado de la base de datos está protegida por un certificado de servidor integrado. El certificado de servidor integrado es único para cada servidor. Microsoft rota automáticamente estos certificados al menos cada 90 días. El algoritmo de cifrado utilizado es AES-256. Para obtener una descripción general de TDE, consulte Cifrado de datos transparente.

Puede cifrar la base de datos mediante Azure Portal o T-SQL.

Cifrado de datos transparente (cifrado en reposo) con claves administradas por el cliente

Si necesitas un mayor control sobre las claves de cifrado, Cifrado de datos transparente para Azure Synapse Analytics soporta claves gestionadas por el cliente (CMK). Esta CMK está asociada al servidor lógico y encapsula las claves de cifrado de base de datos para todas las bases de datos de ese servidor. Mediante la administración de CMK, puede controlar la rotación de claves, la revocación y la auditoría, lo que suele ser necesario para las directivas de seguridad estrictas o de cumplimiento.

Seguridad de la capa de transporte (cifrado en tránsito)

Azure Synapse Analytics protege los datos de los clientes cifrando datos en movimiento con Transport Layer Security (TLS). Azure Synapse Analytics siempre aplica conexiones cifradas TLS para asegurar que todos los datos estén cifrados en tránsito entre el cliente y el servidor.

Específicamente, Azure Synapse Analytics establece la bandera ForceEncryption de configuración en Yes. Los clientes y drivers deben soportar conexiones cifradas para conectarse a este servicio. La versión más baja del protocolo TDS que puede conectarse es TDS 7.1.

Como procedimiento recomendado, si tiene controladores SQL compatibles con TDS 8.0, use cifrado estricto de conexión.

Si los controladores no admiten TDS 8.0, use el cifrado obligatorio y no confíe en el certificado de servidor. Por ejemplo, al usar el controlador ADO.NET, use Encrypt=True y TrustServerCertificate=False en la cadena de conexión para lograrlo. La cadena de conexión que obtiene de Azure Portal ya está configurada con estos valores.

Evite establecer el parámetro TrustServerCertificate en True en entornos de producción. TrustServerCertificate=True es demasiado permisivo y no protege contra ataques de tipo man-in-the-middle. En su lugar, si el cliente espera un nombre de dominio diferente en el certificado de servidor, use el HostNameInCertificate parámetro para proporcionar el nombre de dominio correcto para la validación.

Pasos siguientes

Para más información y ejemplos sobre cómo conectarse al almacenamiento con distintos protocolos, consulte Conexión al grupo de SQL dedicado (anteriormente SQL DW).