Tareas y funciones de seguridad
Los servicios de SQL Server y Azure SQL son conocidos por la importancia que dan a la seguridad, específicamente por ser de clase empresarial. En esta unidad, conocerá las diversas funcionalidades de seguridad relacionadas con la seguridad de red y la administración de acceso. En las unidades siguientes, encontrará ejemplos prácticos de algunas de estas funcionalidades.
Seguridad de red
La primera capa de seguridad implica la red. Las funcionalidades y tareas de red difieren entre Azure SQL Database y Azure SQL Managed Instance. Para obtener información sobre las funcionalidades de red de Azure SQL Managed Instance, consulte Arquitectura de conectividad para Azure SQL Managed Instance.
Seguridad de la red de Azure SQL Database
Al proteger la red para Azure SQL Database, dispone de cuatro opciones principales:
- Permitir el acceso a servicios de Azure
- Uso de reglas de firewall
- Usar reglas de red virtual
- Usar Azure Private Link
Además de estas opciones principales, tiene la oportunidad de bloquear todo el acceso público (solo con Azure Private Link) y la opción de imponer una versión mínima de Seguridad de la capa de transporte (TLS). El método menos seguro, pero el más fácil de configurar, es permitir el acceso a los servicios de Azure. El método más seguro es usar Private Link. En las secciones siguientes se tratarán las funcionalidades de cada opción, así como la configuración y el mantenimiento de cada una.
Permitir el acceso a servicios de Azure
Durante la implementación de Azure SQL Database, tiene la opción de establecer Permitir que los servicios y recursos de Azure accedan a este servidor en Sí. Si elige esta opción, está permitiendo que cualquier recurso de cualquier región o suscripción tenga posibilidad de acceder al recurso. Esta opción facilita la puesta en marcha y la conexión de Azure SQL Database con otros servicios, como Azure Virtual Machines, Azure App Service o incluso Azure Cloud Shell, ya que permite que todo lo que pase por Azure tenga posibilidad de conectarse.
Pero, al permitir el acceso a servicios de Azure, no se permite que nada fuera de Azure (por ejemplo, su entorno local) tenga acceso.
La configuración más segura consiste en establecer Permitir que los servicios y recursos de Azure accedan a este servidor en No, lo que bloquea todas las conexiones y redes, aparte de las que agregó explícitamente con las distintas opciones que se indican a continuación en las secciones siguientes.
Reglas de firewall
La siguiente opción que tiene es aplicar reglas de firewall. Los resultados podrían ser similares a los de Permitir que los servicios y recursos de Azure accedan a este servidor, salvo que, para cada servicio (en la imagen siguiente, una máquina virtual [VM]) tendrá que agregar una regla de firewall única para permitir que se conecte. Las reglas de firewall también habilitan el entorno local para conectar al recurso de Azure SQL Database porque en él se pueden agregar reglas para máquinas y aplicaciones.
Para obtener conectividad en Azure, también puede permitir el acceso a los servicios de Azure y, después, agregar reglas de firewall solo para la conectividad local. Como se ha mencionado anteriormente, Permitir que los servicios y recursos de Azure accedan a este servidor no es tan seguro, ya que permite todo el tráfico de Azure. Se recomienda usar reglas de firewall exclusivamente.
Echemos un vistazo al ejemplo anterior con las reglas del firewall configuradas. Desde una herramienta compatible con Transact-SQL (T-SQL), como SQL Server Management Studio (SSMS), puede ejecutar la siguiente consulta desde su máquina virtual de Azure en la red virtual SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
El resultado sería 174.17.218.16. Esta es la IP pública de la máquina virtual de Azure. Aunque estamos usamos reglas de firewall, todas las conexiones que se establecen son públicas.
Reglas de red virtual
Si solo desea usar reglas de firewall, puede resultar complicada la configuración. El uso único de reglas de firewall significa que tiene que especificar un intervalo de direcciones IP para todas las conexiones, que a veces pueden incluir direcciones IP dinámicas. Una alternativa mucho más sencilla es usar reglas de red virtual para establecer y administrar el acceso desde redes específicas que contengan máquinas virtuales u otros servicios que tengan que acceder a los datos.
Si configura el acceso desde una red virtual con una regla de red virtual, todos los recursos de esa red virtual pueden acceder al servidor lógico de Azure SQL Database. Esto puede simplificar el desafío de configurar el acceso a todas las direcciones IP estáticas y dinámicas que tengan que acceder a los datos. Con las reglas de red virtual, puede especificar una o varias redes virtuales, que abarcan todos los recursos que contienen. También puede empezar a aprovechar las tecnologías de red virtual para conectar redes tanto entre regiones de Azure como en el entorno local.
En este ejemplo, puede ejecutar la misma consulta que en la sección anterior desde su máquina virtual de Azure en la red virtual SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
El resultado sería ahora 10.0.0.2, la dirección IP privada de la máquina virtual de Azure. Este resultado le acerca un paso más a la creación de conexiones privadas con el servidor lógico de Azure SQL Database, ya que ahora los recursos se conectan a través de la red virtual.
Otra estrategia común para analizar la conexión es examinar la jerarquía del Sistema de nombres de dominio (DNS). En la misma máquina virtual de Azure, puede ejecutar el siguiente comando en un símbolo del sistema:
nslookup aw-server.database.windows.net
Con este comando, puede obtener detalles relacionados con la infraestructura de DNS. Los resultados serán similares a los siguientes:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 174.17.218.16
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
En la respuesta no autoritativa hay algunas cosas importantes que se deben examinar:
- Nombre: El punto de conexión que comienza con
cr2forma parte de la jerarquía de DNS público. Sin entrar demasiado en la jerarquía, digamos quecr2es el anillo de control 2 y luego hay varios "segmentos" de datos por debajo. - Dirección: La dirección IP que se devuelve aquí debe coincidir con la dirección IP pública de la máquina virtual de Azure. Aunque una herramienta como el salto final de SSMS podría pasar a través de la dirección IP privada de la máquina virtual, la dirección IP pública de la máquina virtual todavía se está usando para conectarse en cierta capacidad.
- Alias: Los alias son diversos puntos dentro de la jerarquía de DNS, en este caso, el "segmento" de datos específico y el punto de conexión al que se conecta.
Nota:
En el bloque de salida anterior, Dirección: 168.63.129.16 es una dirección IP pública virtual que se usa para facilitar un canal de comunicación a los recursos de la plataforma Azure. Esto se aplica a todas las regiones y todas las nubes nacionales, y no cambiará.
Aunque la conexión a través de SSMS llega a través de la dirección IP privada de la máquina virtual de Azure, sigue conectándose en última instancia a través de un punto de conexión público.
Private Link en una Azure SQL Database
Ha visto cómo configurar la red más segura mediante el uso de la base de datos en Azure SQL Database con el punto de conexión público. Este método de protección de una base de datos en SQL Database se ha usado durante años. Pero en 2019, Azure comenzó a moverse hacia un concepto de vínculo privado, que se parece más a la forma en que se implementa Azure SQL Managed Instance. Azure Private Link le permite conectarse a su base de datos en SQL Database y a varias otras ofertas de plataforma como servicio (PaaS) mediante un punto de conexión privado. Esto significa que tiene una dirección IP privada dentro de una red virtual específica.
En el ejemplo anterior, observará que la infraestructura de red general no ha cambiado y todavía puede aplicar las estrategias de conectividad de red virtual de las reglas de red virtual. Aunque no tendrá que crear reglas de red virtual. Los recursos que necesitan conectarse al servidor de base de datos deben tener acceso a la red virtual en la que reside el punto de conexión. En el ejemplo, el punto de conexión es SQLDBVNet-EUS. Solo tienen acceso las conexiones que pasan por el punto de conexión privado, las demás conexiones (por ejemplo, de Internet) se deniegan.
Siguiendo con este ejemplo, en la máquina virtual de Azure en la red virtual SQLDBVNet-EUS, podría volver a ejecutar el siguiente comando T-SQL:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
El resultado sería ahora 10.0.0.2, que es la dirección IP privada de la máquina virtual de Azure en este ejemplo. Al agregar acceso desde una red virtual, parecerá que las conexiones a Azure SQL Database de la máquina virtual proceden de la dirección IP privada de la máquina virtual. Se trata del mismo resultado que obtuvo con las reglas de red virtual.
Pero es posible que quiera usar el símbolo del sistema para ver la jerarquía de DNS mediante el comando siguiente:
nslookup aw-server.database.windows.net
Si usa el comando anterior, los resultados serán ligeramente diferentes con el punto de conexión privado configurado:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
En la respuesta no autoritativa hay algunas cosas importantes que se deben examinar:
- Nombre: Tenga en cuenta que ya no señala a la jerarquía de DNS público, solo al DNS de Private Link. Esto significa que se revela menos información sobre el servidor de bases de datos.
- Direcciones: En el caso de las reglas de red virtual, la dirección devuelta es la dirección IP pública de la máquina virtual, pero ahora debería ser una o varias direcciones IP privadas en la jerarquía de Private Link (una es el punto de conexión privado de la instancia de Azure SQL Database).
- Alias: Igual que en el campo Nombre, no hay nada relacionado con la jerarquía de DNS, salvo que todavía puede conectarse al nombre del servidor (por ejemplo,
aw-server.database.windows.net).
Es posible que si se está conectando al punto de conexión privado se pregunte: ¿por qué sigue usando el mismo nombre de servidor? En el back-end, cuando solo se usa el método de Private Link de conexión a Azure SQL Database (es decir, sin reglas de firewall ni de red virtual), la información se procesa de la siguiente manera:
aw-server.database.windows.net- Resuelto por servicio en
aw-server.privatelink.database.net- Resuelto por servicio en
10.0.0.5(la dirección IP del punto de conexión privado)
- Resuelto por servicio en
- Resuelto por servicio en
Además, el servicio le impedirá conectarse directamente con cualquier cosa que no sea aw-server.database.windows.net.
Administración de acceso
Una vez que haya finalizado el acceso a la red, la siguiente capa que debe tener en cuenta es la administración del acceso.
Control de acceso basado en roles.
Todos los tipos de operaciones de Azure para Azure SQL Database se controlan a través del control de acceso basado en roles (RBAC). Actualmente, RBAC está desacoplado de la seguridad de Azure SQL, pero se puede considerar como derechos de seguridad fuera de su base datos de SQL Database con un ámbito que incluye la suscripción, el grupo de recursos y el recurso. Estos derechos se aplicarán a las operaciones en Azure Portal, la CLI de Azure y Azure PowerShell. RBAC permite la separación de tareas entre la implementación, la administración y el uso.
Hay roles integrados disponibles para reducir la necesidad de roles RBAC de nivel superior, como propietario o colaborador. De hecho, puede usar estos roles para que determinadas personas implementen recursos de Azure SQL (o administren directivas de seguridad), pero conceder a otros usuarios acceso real para usar o administrar la base de datos. Por ejemplo, un colaborador de SQL Server podría implementar un servidor y asignar un usuario para que sea el administrador del servidor y las bases de datos. Entre los roles integrados para Azure SQL Database encontramos los siguientes:
- Colaborador de SQL Database: puede crear y administrar bases de datos, pero no acceder a la base de datos (por ejemplo, no puede conectarse y leer datos).
- Administrador de seguridad de SQL: puede administrar las directivas de seguridad de las bases de datos y las instancias (como la auditoría), pero no acceder a ellas
- Colaborador de SQL Server: puede administrar servidores y bases de datos, pero no acceder a ellos.
Autenticación
Durante la implementación de un servidor lógico de Azure SQL Database, es posible especificar el Método de autenticación siguiente:
- Uso exclusivo de la autenticación de Microsoft Entra
- Uso de la autenticación de SQL y la autenticación de Microsoft Entra
- Usar la autenticación de SQL
El administrador del servidor debe establecerse durante la implementación. En el caso de las bases de datos de Azure SQL Database, el administrador del servidor es una entidad de seguridad de nivel de servidor para el servidor lógico de Azure SQL Database.
Si va a migrar una carga de trabajo que requiere autenticación de Windows o la organización usa Microsoft Entra ID, puede usar Microsoft Entra ID. Puede asignar un administrador del servidor de Microsoft Entra mediante las herramientas de la línea de comandos o del portal.
La autenticación solo de Microsoft Entra es la opción predeterminada al configurar un nuevo servidor. Se han introducido inicios de sesión de servidor para permitir entidades de seguridad de servidor de Microsoft Entra, que son inicios de sesión en la base de datos virtual master de una SQL Database. Es posible crear inicios de sesión de Microsoft Entra desde usuarios, grupos y entidades de servicio de Microsoft Entra. Al usar la autenticación solo de Microsoft Entra, se pueden crear inicios de sesión de autenticación de SQL y los inicios de sesión existentes permanecerán. Sin embargo, solo los inicios de sesión de autenticación de Microsoft Entra y los usuarios pueden conectarse al servidor lógico. Para obtener más información sobre la autenticación solo de Microsoft Entra, consulte Autenticación solo de Microsoft Entra con Azure SQL.
En función de cómo haya configurado la organización la instancia de Microsoft Entra, puede conectarse a ella mediante cualquiera de los tres métodos siguientes (por ejemplo, en SSMS):
Microsoft Entra ID: integrado: Método no interactivo que puede usar si ha iniciado sesión en Windows con sus credenciales de Microsoft Entra desde un dominio federado.
Microsoft Entra ID: contraseña: Método no interactivo que permite conectar con un nombre de entidad de seguridad de Microsoft Entra mediante el dominio administrado por Microsoft Entra ID. En la documentación:
Esto puede aplicarse a usuarios de Microsoft Entra nativos o federados. Un usuario nativo se crea explícitamente en Microsoft Entra ID y se autentica con el nombre de usuario y la contraseña, mientras que un usuario federado es un usuario de Windows cuyo dominio está federado con Microsoft Entra ID. El último método (mediante nombre de usuario y contraseña) se puede usar cuando un usuario quiere usar sus credenciales de Windows, pero su máquina local no está unida al dominio (por ejemplo: mediante un acceso remoto). En este caso, un usuario de Windows puede indicar su cuenta de dominio y su contraseña, y puede autenticarse en SQL Database o en Azure Synapse Analytics (anteriormente SQL DW) mediante credenciales federadas.
Microsoft Entra ID: universal con autenticación multifactor (MFA): Método interactivo que protege el acceso a los datos a la vez que se satisface la demanda de la organización de un proceso de inicio de sesión único con la autenticación multifactor de Microsoft Entra.
En el caso de Azure SQL Database, hay algunos matices. Puede tener inicios de sesión que existan en la base de datos virtual master, los usuarios de la base de datos e incluso los usuarios de base de datos independientes para las cuentas de Microsoft Entra (recomendado). Aunque el administrador del servidor para Azure SQL Database tiene en esencia derechos de sysadmin, puede crear administradores más limitados mediante roles de nivel de base de datos o servidor. Hay dos roles de nivel de base de datos disponibles para SQL Database que solo existen en la base de datos virtual master:
- loginmanager: Un rol de nivel de base de datos que permite a los miembros crear inicios de sesión para el servidor de bases de datos
- dbmanager: Un rol de nivel de base de datos que permite a los miembros crear y eliminar bases de datos para el servidor de bases de datos
A continuación encontrará una lista de roles de nivel de servidor en Azure SQL Database:
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Por último, cuando establece y configura la autenticación y la autorización, puede seguir cuatro instrucciones:
- Implementar con un administrador del servidor
- Crear otros administradores según sea necesario
- Los administradores pueden crear usuarios
- Conceder acceso de la misma manera que lo haría en SQL Server
Otras funcionalidades
Después de empezar a trabajar con algunas de las funcionalidades de autenticación y red, más adelante en el módulo examinará otras funcionalidades (y sus tareas relacionadas) de protección, supervisión, registro y auditoría de datos.