Compartir a través de

Características de seguridad de Azure SQL Database

  • Artículo

Azure SQL Database ofrece un servicio de base de datos relacional en Azure. Para proteger los datos de los clientes y proporcionar características sólidas de seguridad que los clientes esperan de un servicio de base de datos relacional, SQL Database tiene sus propios conjuntos de funcionalidades de seguridad. Estas funcionalidades se basan en los controles que se heredan de Azure.

Funcionalidades de seguridad

Uso del protocolo TDS

Azure SQL Database solo admite el protocolo de flujo TDS, que requiere que la base de datos sea accesible solo a través del puerto predeterminado de TCP/1433.

Firewall de Azure SQL Database

Para ayudar a proteger los datos de los clientes, Azure SQL Database incluye una función de cortafuegos que, por defecto, impide todo acceso a SQL Database.

Firewall de Azure SQL Database

El firewall de puerta de enlace puede limitar las direcciones, lo que permite que los clientes tengan control pormenorizado sobre intervalos específicos de direcciones IP aceptables. El firewall otorga acceso según la dirección IP de origen de cada solicitud.

Los clientes pueden configurar el firewall desde un portal de administración o mediante programación con la API REST de Azure SQL Database Management. El firewall de puerta de enlace de Azure SQL Database impide, de forma predeterminada, todo acceso de los clientes a Azure SQL Database. Los clientes deben configurar el acceso mediante listas de control de acceso (ACL) para permitir conexiones de Azure SQL Database por protocolos, números de puertos y direcciones de Internet de origen y destino.

DoSGuard

DosGuard, un servicio de puerta de enlace de SQL Database, reduce los ataques por denegación de servicio (DoS). DoSGuard realiza un seguimiento activo de inicios de sesión erróneos desde direcciones IP. Si se producen varios inicios de sesión fallidos desde una dirección IP en un periodo de tiempo, se bloquea el acceso de la dirección IP a cualquier recurso del servicio durante un periodo de tiempo predefinido.

Además, la puerta de enlace de Azure SQL Database realiza los siguiente:

  • Negociaciones de capacidad de canal seguro para implementar conexiones cifradas validadas por TDS FIPS 140-2 al conectarse a los servidores de bases de datos.
  • Inspección de paquetes TDS con estado al aceptar conexiones de los clientes. La puerta de enlace valida la información de conexión. La puerta de enlace valida la información de conexión y pasa los paquetes TDS al servidor físico adecuado según el nombre de la base de datos especificado en la cadena de conexión.

El principio general de seguridad de red de la oferta de Azure SQL Database es permitir únicamente la conexión y la comunicación necesarias para que el servicio funcione. Todos los otros puertos, protocolos y conexiones se bloquean de manera predeterminada. Las redes de área local virtual (VLAN) y las ACL se usan para restringir las comunicaciones de red por protocolos, números de puerto y redes de origen y destino.

Los mecanismos aprobados para implementar las ACL basadas en red incluyen: ACL en enrutadores y equilibradores de carga. Estos mecanismos son gestionados por las redes de Azure, el cortafuegos de la máquina virtual invitada y las reglas del cortafuegos de la puerta de enlace de Azure SQL Database configuradas por el cliente.

Segregación de datos y aislamiento de clientes

La red de producción de Azure está estructurada de modo que los componentes del sistema accesibles públicamente estén separados de los recursos internos. Existen límites físicos y lógicos entre los servidores web, lo que proporciona acceso a Azure Portal orientado al público y la infraestructura virtual subyacente de Azure, donde residen las instancias de las aplicaciones de los clientes y los datos de los clientes.

Toda la información accesible públicamente se administra dentro de la red de producción de Azure. La red de producción es:

  • Sujeto a mecanismos de autenticación en dos fases y protección de límites
  • Usa el firewall y el conjunto de características de seguridad descritos en la sección anterior
  • Usa funciones de aislamiento de datos indicadas en las secciones siguientes

Sistemas no autorizados y aislamiento de FC

Puesto que el controlador de tejido (FC) es el orquestador central del tejido de Azure, existen controles importantes para mitigar las amenazas, sobre todo desde los FA potencialmente comprometidos dentro de las aplicaciones de los clientes. La FC no reconoce ningún hardware cuya información de dispositivo (por ejemplo, la dirección MAC) no esté precargada en la FC. Los servidores DHCP en FC tienen listas configuradas de direcciones MAC de los nodos que están dispuestas a arrancar. Incluso si se conectan sistemas no autorizados, no se incorporan al inventario del tejido y, por lo tanto, no se conectan ni están autorizados para comunicarse con ningún sistema en el inventario del tejido. Esto reduce el riesgo de que sistemas no autorizados se comuniquen con el FC y obtengan acceso a la VLAN y Azure.

Aislamiento de VLAN

La red de producción de Azure se divide lógicamente en tres redes VLAN principales:

  • La red VLAN principal: interconecta nodos de cliente que no son de confianza.
  • La red VLAN FC: contiene controladores de tejido (FC) de confianza y sistemas auxiliares.
  • La red VLAN de dispositivo: contiene dispositivos de red y otra infraestructura de confianza.

Filtrado de paquetes

El IPFilter y los firewalls de software implementados en el sistema operativo raíz y el sistema operativo invitado de los nodos aplican restricciones de conectividad y evitan el tráfico no autorizado entre las máquinas virtuales.

Hipervisor, sistema operativo raíz y máquinas virtuales invitadas

El hipervisor y el SO raíz gestionan el aislamiento del SO raíz de las máquinas virtuales invitadas y de las máquinas virtuales invitadas entre sí.

Tipos de reglas en firewalls

Una regla se define como:

{IP de Src, puerto de Src, IP de destino, puerto de destino, protocolo de destino, entrada/salida, con estado/sin estado, tiempo de espera de flujo con estado}.

Los paquetes de carácter inactivo síncrono (SYN) solo pueden entrar o salir si alguna de las reglas lo permite. Para TCP, Azure usa reglas sin estado, donde el principio es que solo permite que todos los paquetes que no sean SYN entren o salgan de la máquina virtual. La premisa de seguridad es que cualquier pila de hosts es resistente a ignorar un paquete no SYN si no ha visto un paquete SYN previamente. El propio protocolo TCP es con estado y, en combinación con la regla sin estado basada en SYN, logra un comportamiento general de una implementación con estado.

Para el Protocolo de datagramas de usuario (UDP), Azure usa una regla con estado. Cada vez que un paquete UDP coincide con una regla, se crea un flujo inverso en la otra dirección. Este flujo tiene un tiempo de espera integrado.

Los clientes son responsables de configurar sus propios firewalls además de lo que ofrece Azure. Aquí los clientes pueden definir las reglas para el tráfico entrante y saliente.

Administración de la configuración de producción

Los equipos de operaciones respectivos en Azure y Azure SQL Database se encargan del mantenimiento de las configuraciones de seguridad estándar. Todos los cambios de configuración en los sistemas de producción se documentan y registran a través de un sistema de seguimiento central. Los cambios de hardware y software se registran a través del sistema de seguimiento central. Los cambios de red relacionados con ACL se registran mediante un servicio de administración de ACL.

Todos los cambios de configuración en Azure se desarrollan y prueban en el entorno de ensayo y, más adelante, se implementan en el entorno de producción. Las compilaciones de software se revisan como parte de las pruebas. Las comprobaciones de seguridad y privacidad se revisan como parte de los criterios de la lista de comprobación de entrada. El equipo de implementación correspondiente implementa los cambios en intervalos programados. El personal del equipo de implementación correspondiente revisa y aprueba las versiones antes de implementarlas en producción.

Los cambios se supervisan para comprobar que sean correctos. En un escenario de error, el cambio se revierte a su estado anterior o se implementa una revisión para corregir el error con la aprobación del personal designado. Source Depot, Git, TFS, Master Data Services (MDS), Runners, supervisión de seguridad de Azure, el FC y la plataforma de WinFabric se usan para administrar, aplicar y comprobar de manera centralizada las opciones de configuración en el entorno virtual de Azure.

De forma similar, los cambios de hardware y de red cuentan con pasos de validación establecidos para evaluar el cumplimiento de los requisitos de compilación. Las versiones se revisan y autorizan a través de un comité de evaluación de cambios (CAB) coordinado de los respectivos grupos a través de la pila.

Pasos siguientes

Para más información sobre lo que hace Microsoft para proteger la infraestructura de Azure, consulte: