Compartir a través de

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.

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.

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).

  • Last updated on