Segunda parte de este curso de Azure DP-300 que os traigo en Español. Podéis encontrar la primera parte haciendo click aquí.
En esta ocasión trataremos todo lo que esté relacionado con la seguridad en los servidores y bases de datos SQL en Azure.
Azure role-based access control (Azure RBAC)
El sistema de roles consiste en una serie de roles que se pueden asignar a los objetos SQL Server que tengamos desplegados en nuestro Azure. Lo más importante que hay que entender es que estos permisos sólo afectan a los objetos SQL de Azure y no a los servicios SQL.
En la lista de abajo podéis ver todos los roles disponibles, siendo los más importantes los 3 primeros ya que el resto estas creados a partir de ellos.
Todos estos roles son comunes y están disponibles para casi todos los objetos de la familia Azure SQL. Aquí os dejo las excepciones:
- Managed Instances no disponen del rol SQL DB Contributor.
- Las máquinas virtuales SQL no disponen de los roles SQL «server» ya que los objetos SQL dentro de las máquinas virtuales no son accesibles por Azure.
Azure RBAC vs Autorización SQL
- Azure RBAC:
- Regula el control de los objetos dentro de la suscripción de Azure.
- Los privilegios de Azure RBAC sólo se pueden dar a cuentas dentro del active directory de Azure, usuarios, grupos o aplicaciones.
- No se tiene acceso al contenido dentro de los servicios SQL alojados en los objetos SQL de Azure.
- Autorización SQL:
- Aplicable a los usuarios dentro del active directory de Azure
Azure RBAC Scopes
En cuanto a cómo se heredan y hasta donde llegan los permisos de estos roles, en las siguientes imágenes podéis ver como afecta dependiendo del objeto SQL.
Controlar el acceso de red a los recursos SQL en Azure
Controlar el acceso de red a las bases de datos SQL en Azure
Las bases de datos SQL, como cualquier otro recursos en Azure, se encuentran distribuidas por regiones. Dentro de estas regiones también serán divididas mediante distintos nodos de clusters virtuales que estarán distribuidos a lo largo de toda la región.
Todas las conexiones que se hagan a esa región pasarán por una gateway mediante los endpoints públicos de Azure usando el puerto 1433. Cuando se hace un intento de conexión a una base de datos, esa conexión debe llegar primero al cluster que la almacena, y esto lo hará dependiendo de la política de conexión que se esté usando.
Estas son las 3 opciones disponibles:
- Proxy: Usando esta opción, la conexión llegará a la gateway que será usada de proxy para llegar más tarde al cluster correspondiente. Esta opción es más segura pero también más lenta.
- Redirección: Inicialmente la conexión llegará a la gateway, pero esta la redirigirá al cluster necesario sin necesidad que la conexión pase por ella. Tiene menos latencia pero es menos segura por lo que requiere de configuraciones extra.
- Default: Por defecto, las conexiones que llegan desde fuera de Azure usarán el método proxy, mientras que las que llegan de dentro de Azure usarán la redirección.
Por defecto, todas estas conexiones se están haciendo usando un endpoint público y permiten conexiones desde internet. Si quisiéramos restringir esto, tendríamos que crear un endpoint privado y configurar las reglas de firewall necesarias.
Controlar el acceso de red a las máquinas virtuales SQL de Azure
Aquí no hay mucho que contar. Se puede acceder al servidor conectándose por RDAP o SSH. Se puede elegir si el acceso a nivel de red puede ser público, privado o sólo a nivel de red interna.
El control de acceso a los servicios SQL se hará con reglas NSG teniendo en cuenta que el puerto por defecto es 1433, aunque este puerto se puede cambiar el configurar la VM.
Controlar el acceso de red a las Azure SQL Managed Instances
Por defecto la conexión pública a la instancia no está permitida, por lo que primero tendremos que acceder al servidor y usar las herramientas de SQL o establecer una conexión a través de una VPN o red virtual interna.
Las managed instances requieren de la configuración de una subnet que debe ser exclusiva para la instancia y que no permitirá otros recursos.
Active Directory de Azure (AAD)
La verdad que todo lo que se explica en esta sección es bastante intuitivo si has trabajado previamente con el AA de Windows ya que funciona de la misma manera.
Básicamente existen 3 formas de acceder a la instancia SQL:
- Usando un Login SQL.
- Usando un usuario del Active Directory de Windows (solo en máquinas virtuales SQL).
- Usando un usuario del Active Directory de Azure.
El funcionamiento es exactamente el mismo, puedes asignarle roles/permisos a usuarios del AA o también a grupos de usuarios. Si le asignas un rol/permiso a un grupo, todos los miembros de ese grupo tendrán ese permiso.
IMPORTANTE: Sólo se podrá usar el SSMS en las managed instances y en las VM de SQL, por lo que si queremos hacer gestiones en las bases de datos SQL en Azure tendremos que usar T-SQL (por desgracia).
Proteger datos SQL en Azure
Cómo en cualquier otro ámbito de la vida, proteger nuestros datos es algo bastante importante. A nivel de protección de datos en nuestro ámbito, estos serian los mejores métodos:
- Controlar el acceso a las redes de los servicios
- Usar autenticaciones seguras
- Usas los permisos de la forma más restrictiva posible
- Encriptar los datos tanto en tránsito como en el destino final
A continuación hablaremos sobre esto último, la encriptación en Azure.
Encriptación en tránsito en Azure
Esto se refiere a la encriptación de los datos en la red entre el cliente y la base de datos a la que están accediendo.
- TLS: Las bases de datos azure y las managed instances usan automáticamente encriptación TLS, pudiendo seleccionar una versión mínima de esta. Si se intenta realizar una conexión con una versión TLS inferior a la mínima, la conexión será rechazada.En las máquinas virtuales SQL los servicios TLS pueden ser usados pero no están configurados por defecto, por lo que deben ser configurados usando SQL Server Configuration Manager.
Encriptación en destino en Azure
- Always Encrypted (mitad tránsito mitad destino): Toda la encriptación ocurre en máquina del cliente por lo que los archivos ya viajan encriptados ,demás, también estarán encriptados en el destino final. Las keys se pueden guardar fuera de los servicios SQL y los administradores no podrán leer las columnas en texto plano.
- TDE (transparent data encryption): Encriptación a nivel del almacenamiento de la base de datos. Las páginas de datos son encriptadas en el almacenamiento y desencriptadas cuando se acceden a ellas usando database engine. Accesible para todos con los permisos correctos. Los backups de estas bases de datos también estarán encriptados, mientras que las exportaciones usando BACPAC no lo estarán.
- Dynamic Data Masking: Aunque no encripta los datos, aplica una máscara a los datos para los usuarios sin privilegios. Esto máscara funciona también con los resultados de exportaciones, querys y select into.
Todas las keys y certificados pueden ser almacenados usando el Azure Key Vault, que nos servirá como repositorio donde almacenarlas de forma segura. También podremos usar algunas funciones de encriptación usado el Azure Key Vault, como por el ejemplo la encriptación de los discos de almacenamiento.
Azure Defender
Azure defender es una función de seguridad gestionada por Azure que ofrece monitorización continua en búsqueda de vulnerabilidades en nuestros objetos SQL de Azure.
Debe ser activado a nivel de servidor o de instancia y afectará a todas las bases de datos dentro de la instancia o del servidor y los reportes se verán a nivel de cada base de datos.
El funcionamiento es simple, se comparará la configuración de la instancia con una serie de nombres basadas en las best practices de Microsoft y se generará un informe con las vulnerabilidades encontradas. Será necesario dar acceso a un almacenamiento donde guardar los reportes. También podremos escanear nuestros sistemas siempre que queramos.
Y con esto termina el curso de esta semana. La verdad que en gran parte me ha parecido un tostón infumable, no os voy a mentir.
Espero que a vosotros os haya podido servir de algo.