Seguridad de Azure para aplicaciones nativas en la nube
Sugerencia
Este contenido es un extracto del libro electrónico “Architecting Cloud Native .NET Applications for Azure” (Diseño de la arquitectura de aplicaciones .NET nativas en la nube para Azure), disponible en Documentos de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.
La protección de las aplicaciones nativas en la nube puede ser más fácil o más difícil que la de las aplicaciones tradicionales. Un inconveniente es la necesidad de proteger más aplicaciones más pequeñas y dedicar energía adicional a formar una infraestructura de seguridad. Debido a la heterogeneidad de los lenguajes y estilos de programación de la mayoría de las implementaciones de servicios, es necesario prestar atención a los boletines de seguridad de muchos proveedores diferentes.
La ventaja consiste en que los servicios más pequeños, cada uno con su propio almacén de datos, limitan el ámbito de un ataque. Si un atacante pone en peligro un sistema, al atacante le costará más saltar a otro sistema que en una aplicación monolítica. Los límites del proceso son sólidos. Además, si una base de datos queda expuesta, se limita el daño, ya que la base de datos contiene solo un subconjunto de datos y no es probable que contenga datos personales.
Modelado de amenazas
Independientemente de si las ventajas superan las desventajas de las aplicaciones nativas en la nube, es necesario adoptar la misma mentalidad de seguridad holística. La seguridad y el foco en la seguridad deben estar presentes en cada paso del desarrollo y de la historia de las operaciones. Al planear una aplicación, formule preguntas como:
- ¿Cuáles serían las consecuencias si se perdieran estos datos?
- ¿Cómo se puede reducir el daño si datos incorrectos se insertan en este servicio?
- ¿Quién debe tener acceso a estos datos?
- ¿Existen directivas de auditoría que se ocupan del proceso del desarrollo y las versiones?
Todas estas preguntas constituyen un proceso denominado modelado de amenazas. En este proceso se buscan respuestas a las preguntas de qué amenazas existen al sistema, qué probabilidades hay de que se produzcan y qué daño potencial suponen.
Después de establecer la lista de amenazas, tiene que decidir si merece la pena mitigarlas. Cuando una amenaza es muy improbable y resulta costosa planearla, no vale la pena gastar energía en ella. Por ejemplo, un actor de nivel de estado podría insertar cambios en el diseño de un proceso que usan millones de dispositivos. Ahora, en lugar de ejecutar un fragmento de código en el anillo 3, este código se ejecuta en el anillo 0. Este proceso permite una vulnerabilidad de seguridad que el hipervisor puede omitir y que puede ejecutar el código de ataque en las máquinas sin sistema operativo, lo que permite ataques en todas las máquinas virtuales que se ejecutan en ese hardware.
Es difícil detectar los procesadores modificados sin un microscopio ni conocimientos avanzados del diseño en silicio de ese procesador. Este escenario es poco verosímil y sería costoso mitigarlo, por lo que probablemente ningún modelo de amenaza recomendaría crear protección para protegerse de él.
Resulta más interesante crear protección frente a amenazas más probables como controles de accesos rotos que causan ataques de incremento de Id, en los que se sustituye Id=2 con Id=3 en la dirección URL, o ataques por inyección de código SQL. Es bastante sensato formar mitigaciones de estas amenazas y prevenir vulnerabilidades de seguridad embarazosos que socavan la reputación de la empresa.
Principio de privilegio mínimo
Una de las ideas esenciales de la seguridad informática es el principio de los privilegios mínimos (POLP). En realidad, es una idea fundamental en la mayoría de las formas de seguridad, ya sean digitales o físicas. En resumen, el principio establece que cualquier usuario o proceso debería contar con el menor número de derechos posibles para ejecutar una tarea.
Por ejemplo, piense que los cajeros de un banco rara vez tienen acceso a la caja fuerte. Por lo tanto, el empleado medio no puede abrir la caja fuerte. Para obtener acceso, tienen que escalar la solicitud por medio de un gerente del banco, que realiza comprobaciones de seguridad adicionales.
En un sistema informático, los derechos de un usuario a conectarse a una base datos constituyen un ejemplo excelente. En numerosos casos, existe una única cuenta de usuario que se usa tanto para crear la estructura de la base de datos como para ejecutar la aplicación. A excepción de casos extremos, la cuenta que ejecuta la aplicación no necesita la capacidad de actualizar la información del esquema. Debe haber varias cuentas que concedan distintos niveles de privilegio. La aplicación solo debería usar el nivel del permiso que proporciona acceso de lectura y escritura a los datos de las tablas. Este tipo de protección eliminaría ataques que tienen como objetivo quitar tablas de bases de datos o introducir desencadenadores malintencionados.
Recordar el principio de los privilegios mínimos es beneficioso para casi todas las partes involucradas en la creación de una aplicación nativa en la nube. Puede aplicarse al configurar firewalls, grupos de seguridad de red, roles y ámbito en control de acceso basado en roles (RBAC).
Pruebas de penetración
A medida que las aplicaciones se complican, el número de vectores de ataque aumenta a una velocidad de vértigo. Este modelado de amenazas tiene el defecto de que las mismas personas que crean el sistema suelen ejecutarlo. De la misma forma en la que a muchos desarrolladores les cuesta visualizar las interacciones de usuario y crean después interfaces de usuario inutilizables,la mayoría de los desarrolladores tienen problemas para ver todos los vectores de ataque. También es posible que los desarrolladores que crean el sistema no sean expertos en metodologías de ataques y pasen por alto algo crucial.
En las pruebas de penetración se introducen actores externos para intentar atacar el sistema. Estos atacantes pueden ser una empresa de consultoría externa u otros desarrolladores con buenos conocimientos de seguridad de otra parte de la empresa. Se les da carta blanca para intentar subvertir el sistema. Con frecuencia, encuentran vulnerabilidades de seguridad serias que necesitan revisarse. A veces, el vector del ataque es algo completamente inesperado como ataques de suplantación de identidad contra la dirección.
Azure sufre ataques constantes de un equipo de hackers dentro de Microsoft. A lo largo de los años, han sido los primeros en detectar docenas de ataques potencialmente catastróficos, que se cerraron antes de someterse a vulnerabilidades externas. Cuando más tentador sea el objetivo, más probabilidades hay de que actores externos intenten aprovecharse de las vulnerabilidades y hay pocos objetivos más atractivos que Azure en el mundo.
Supervisión
Si un atacante intenta penetrar en una aplicación, debería producirse una advertencia. Con frecuencia, los ataques pueden identificarse al examinar los registros de los servicios. Los ataques dejan signos reveladores que pueden detectarse antes de que se materialicen. Por ejemplo, un atacante que quiera adivinar una contraseña hará muchas solicitudes a un sistema de inicio de sesión. Si se supervisan los sistemas de inicio de sesión, se pueden detectar patrones extraños que no se corresponden con un patrón de acceso típico. La supervisión puede convertirse en una alerta que puede, a su vez, alertar a una persona de operaciones para activar algún tipo de contramedidas. Un sistema de supervisión de gran madurez puede incluso adoptar medidas ante estas desviaciones de forma proactiva al agregar reglas para bloquear solicitudes o limitar respuestas.
Protección de la compilación
A menudo se pasa por alto la seguridad en el proceso de compilación. La compilación debería ejecutar comprobaciones de seguridad, como examinar el código no seguro o credenciales protegidas. La compilación también tendría que estar segura. Si el servidor de compilación está en peligro, proporciona un vector fantástico para introducir código arbitrario en el producto.
Imagine un atacante que quiera robar las contraseñas de las personas que inician sesión en una aplicación web. Podrían introducir un paso de compilación que modificara el código desprotegido para reflejar una solicitud de inicio de sesión en otro servidor. La próxima vez que el código pasa por la compilación, se actualiza en silencio. El examen de vulnerabilidad del código fuente no detectaría esta vulnerabilidad, ya que se ejecuta antes de la compilación. De la misma forma, nadie lo vería en la revisión del código porque los pasos de compilación residen en el servidor de compilación. El código vulnerado pasaría a la fase de producción donde puede recopilar contraseñas. Probablemente no haya registro de auditoría del proceso de compilación o, como mínimo, no haya nadie supervisando la auditoría.
Este escenario es un claro ejemplo de como lo que parece un objetivo poco valorado puede usarse para penetrar en el sistema. Una vez que un atacante vulnera el perímetro del sistema, tiene la capacidad para empezar a buscar maneras para elevar sus permisos hasta un punto en el que pueden causar daños reales donde quieran.
Creación de código seguro
.NET Framework ya es un marco bastante seguro. Evita algunos de los problemas de los códigos no administrados, como salir de los extremos de las matrices. Se trabaja para corregir las vulnerabilidades de seguridad, a medida que se detectan. Mediante el Bug Bounty Program, (programa de recompensas por errores), se paga a los investigadores que encuentran problemas en el marco y los notifican, en lugar de aprovecharse de ellos.
Existen muchas maneras de proteger el código .NET. Las siguientes instrucciones, como el artículo Instrucciones de codificación segura, proporcionan medidas razonables para garantizar que el código sea seguro desde el principio. El proyecto OWASP top 10 es una guía valiosa para saber cómo crear código seguro.
El proceso de compilación es el lugar adecuado para que las herramientas de análisis detecten problemas en el código fuente antes de que entren en producción. La mayoría del proyecto tiene dependencias en otros paquetes. Una herramienta que puede examinar paquetes obsoletos detectará problemas de una compilación nocturna. Incluso al compilar imágenes de Docker, es útil comprobar y asegurarse de que la imagen base no presenta vulnerabilidades conocidas. También hay que comprobar que nadie ha vulnerado accidentalmente credenciales protegidas.
Seguridad integrada
Azure está pensado para encontrar el equilibro entre la facilidad del uso y la seguridad para la mayoría de los usuarios. Los distintos usuarios van a tener requisitos de seguridad diferentes, así que necesitan ajustar su enfoque para la seguridad en la nube. Microsoft publica grandes cantidades de información de seguridad en el Centro de confianza. Este recurso debería ser el primer paso para aquellos profesionales interesados en saber cómo funcionan las tecnologías integradas de mitigación de ataques.
En Azure Portal, Azure Advisor es un sistema que examina el entorno y sugiere recomendaciones de forma constante. Algunas de estas recomendaciones están pensadas para que los usuarios ahorren dinero, mientras que otras buscan identificar configuraciones potencialmente inseguras, como tener un contenedor de almacenamiento abierto al mundo y sin la protección de Virtual Network.
Infraestructura de red de Azure
En un entorno de implementación local, una gran cantidad de energía se destina a configurar redes. Configurar enrutadores y conmutadores es un trabajo complicado. Las redes permiten que determinados recursos se comuniquen con otros recursos y evitan acceso en algunos casos. Una regla de red frecuente consiste en restringir el acceso al entorno de producción del entorno de desarrollo en el caso remoto de que una pieza de código medio desarrollado se ejecute incorrectamente y elimine un conjunto de datos.
De forma rápida, la mayoría de los recursos de PaaS Azure solo tienen la configuración de red permisiva y básica. Por ejemplo, cualquiera en Internet puede acceder a un servicio de aplicación. Las nuevas instancias de SQL Server suelen estar restringidas, de modo que las partes externas no pueden acceder a ellas, pero se permiten los intervalos de direcciones IP que usa Azure. Por lo tanto, aunque el servidor SQL está protegido frente a amenazas externas, un atacante solo tiene que configurar una cabeza de puente de Azure desde el cual pueden iniciar ataques contras todas las instancias de SQL en Azure.
Por suerte, la mayoría de los recursos de Azure se pueden colocar en Virtual Network de Azure que permite un control de acceso específico. De forma parecida a la que en las redes locales establecen redes privadas que están protegidas del mundo más amplio, las redes virtuales son islas de direcciones IP privada que se encuentran en la red de Azure.
Figura 9-1. Una red virtual de Azure.
De la misma forma en la que las redes locales tienen un firewall que rige el acceso a la red, puedes establecer un firewall parecido en el límite de la red virtual. De forma predeterminada, todos los recursos de una red virtual todavía pueden comunicarse con Internet. Solo se trata de conexiones entrantes para las que se necesita alguna forma de excepción de firewall explícita.
Con la red establecida, los recursos internos como las cuentas de almacenamientos pueden configurarse para que solo permitan el acceso por recursos que están solo en Virtual Network. Este firewall proporciona un nivel extra de seguridad. Si se filtran las llaves para cuentas de almacenamiento, los atacantes no podrían conectarse para aprovechar las llaves filtradas. Este escenario ejemplifica también el principio de privilegios mínimos.
Los nodos de un clúster de Azure Kubernetes pueden participar en una red virtual, como otros recursos que son más nativos de Azure. La funcionalidad se denomina Azure Container Networking Interface, la interfaz de red de contenedor de Azure. En efecto, asigna una subred dentro de una red virtual en la que las máquinas virtuales y las imágenes de contenedores se asignan.
Siguiendo la ruta de acceso de ilustrar el principio de los privilegios mínimos, no todos los recursos dentro de Virtual Network necesitan comunicarse con todos los demás recursos. Por ejemplo, en una aplicación que ofrece una API web sobre la cuenta de almacenamiento y una base de datos SQL, es poco probable que la base de datos y la cuenta de almacenamiento necesiten comunicarse entre sí. Cualquier dato que se comparta entre ellas pasará por la aplicación web. Por lo tanto, un grupo de seguridad de red (NSG) podría usarse para denegar el tráfico entre los dos servicios.
Puede ser engorroso implementar una directiva que deniega una comunicación entre recursos, especialmente si viene de un fondo de uso de Azure sin restricciones de tráfico. En otras nubes se usa mucho más el concepto de grupos de seguridad de red. Por ejemplo, la directiva predeterminada de AWS dicta que los recursos no pueden comunicarse entre ellos hasta que las reglas de un grupo de seguridad de red no lo habilita. Aunque su desarrollo consume más tiempo, un entorno más restrictivo proporciona valores predeterminados más seguros. Usar prácticas de DevOps adecuadas, especialmente Azure Resource Manager o Terraform para administrar permisos puede facilitar el control de las reglas.
Virtual Network también puede ser útil al configurar comunicaciones entre recursos locales y en la nube. Se puede usar una red privada virtual para adjuntar sin contratiempos las dos redes juntas. Con este enfoque, es posible ejecutar una red virtual sin ningún tipo de puerta de enlace para escenarios donde todos los usuarios están en el sitio. Hay una serie de tecnologías que pueden usarse para establecer esta red. La forma más sencilla es usar una VPN de sitio a sitio que se puede establecer entre muchos enrutadores y Azure. El tráfico se cifra y se tuneliza a través de Internet con el mismo coste por byte que en cualquier otro tráfico. En escenarios donde es más conveniente más ancho de banda y más seguridad, Azure ofrece un servicio llamado Express Route que usa un circuito privado entre una red local y Azure. Resulta más costoso y difícil de establecer, pero es más seguro.
El control de acceso basado en rol para restringir el acceso a los recursos de Azure
RBAC es un sistema que proporciona una identidad a las aplicaciones que se ejecutan en Azure. Las aplicaciones pueden acceder a los recursos que usan esta identidad, en vez de o además de usar claves o contraseñas.
Entidades de seguridad
El primer componente en RBAC es una entidad de seguridad. Una entidad de seguridad puede ser usuario, un grupo, una entidad de servicio o una identidad administrada.
Figura 9-2. Diferentes tipos de entidades de seguridad.
- Usuario: cualquier usuario con una cuenta en Azure Active Directory es usuario.
- Grupo: una colección de usuarios de Azure Active Directory. Como miembro de un grupo, un usuario adopta los roles de un grupo, además de los suyos propios.
- Entidad de servicio: una identidad de seguridad en la que se ejecutan servicios o aplicaciones.
- Identidad administrada: una identidad de Azure Active Directory administrada por Azure. Las identidades administradas suelen usarse cuando se desarrollan aplicaciones en la nube para administrar las credenciales para la autenticación en los servicios de Azure.
La entidad de seguridad se puede aplicar a casi todos los recursos. Esto conlleva que sea posible asignar una entidad de seguridad a un contenedor que se ejecuta en Azure Kubernetes, lo que permite acceder a secretos almacenados en Key Vault. Una función de Azure podría obtener un permiso al permitirle comunicarse con una instancia de Active Directory para validar un JWT para un usuario que llama. Una vez habilitados los servicios con una entidad de servicio, se pueden administrar sus permisos de forma granular mediante roles y ámbitos.
Roles
Una entidad de seguridad puede obtener muchos roles o, como se suele decir, tocar muchos palos. Cada rol define una serie de permisos como «Read messages from Azure Service Bus endpoint» (leer mensajes del punto de conexión de Azure Service Bus). El conjunto de permisos efectivos de una entidad de seguridad es la combinación de todos los permisos asignados a todos los roles que tiene una entidad de seguridad. Azure tiene un gran número de roles integrados y los usuarios pueden definir sus propios roles.
Figura 9-3. Definiciones de roles RBAC.
También están integrados en Azure un alto número de roles de alto nivel como propietario, colaborador, lector o administrador de cuenta de usuario. Una entidad de seguridad con el rol de propietario puede acceder a todos los recursos y asignar permisos a otros. Un colaborador tiene el mismo nivel de acceso a todos los recursos, pero no pueden asignar permisos. Un lector solo puede ver recursos de Azure existentes y un administrador de cuenta de usuario puede administrar el acceso a los recursos de Azure.
Los roles integrados más granulares, como colaborador de zona DNS, tienen derechos limitados a un único servicio. Las entidades de seguridad pueden adoptar cualquier número de roles.
Ámbitos
Los roles se pueden aplicar a un conjunto restringido de recursos en Azure. Por ejemplo, al aplicar el ámbito a un ejemplo anterior de lectura de una cola de Service Bus, puede restringir el permiso a una única cola: «Leer mensajes del punto de conexión de Azure Service Busblah.servicebus.windows.net/queue1»
El ámbito puede restringirse como un único recurso o puede aplicarse a un grupo de recursos completo, una suscripción o incluso un grupo de administración.
Al probar si una entidad de seguridad tienen determinado permiso, se tiene en cuenta la combinación de rol y ámbito. Esta combinación proporciona un mecanismo de autorización eficaz.
Denegar
Anteriormente, solo se admitían reglas de «permitir» para RBAC. Con este comportamiento, era más complicado compilar algunos ámbitos. Por ejemplo, permitir el acceso de una entidad de seguridad a todas las cuentas de almacenamiento, a excepción de una, requería conceder explícitamente permisos a una lista de cuentas de almacenamiento. Cada vez que se creaba una cuenta de almacenamiento, tenía que agregarse a esta lista de cuentas. De este modo se agregaba una sobrecarga de administración que no era conveniente.
La denegación de reglas tiene prioridad sobre las reglas de permiso. Ahora que representa el mismo ámbito de «permitir todas menos uno» podría representarse como dos reglas «permitir todas» y «denegar esta específica». Las reglas de denegación no solo alivian la administración, sino que también dan cabida a los recursos que son extraseguros al denegar acceso a todo el mundo.
Comprobación de acceso
Como cabe imaginar, un número más amplio de roles y ámbitos puede dificultar el permiso efectivo de una entidad de servicio. Si, además, se apilan reglas solo sirve para aumentar la complejidad. Afortunadamente, hay una calculadora de permisos que pueden indicar los permisos efectivos para cualquier entidad de servicio. Se suele encontrar bajo la pestaña IAM en el portal, como se muestra en la figura 9-3.
Figura 9-4. Calculadora de permisos de un servicio de aplicaciones.
Protección de secretos
Las contraseñas y los certificados son un vector de ataque frecuente para atacantes. El hardware de descifrado de contraseñas pueden cometer un ataque violento e intentar adivinar miles de millones de contraseñas por segundo. Por lo tanto, es importante que las contraseñas que se usan para acceder a los recursos sean seguras y usen una gran variedad de caracteres. Se trata de contraseñas que son casi imposibles de recordar. Por suerte, no es necesario que un humano conozca realmente las contraseñas de Azure.
Muchos expertos en seguridad sugieren que el mejor enfoque consiste en un administrador de contraseñas para mantener las propias contraseñas. Aunque centraliza las contraseñas en una ubicación, también permite usar contraseñas muy complejas y asegurarse de que son únicas para cada cuenta. El mismo sistema existe en Azure: un almacén central para secretos.
Azure Key Vault
Azure Key Vault proporciona una ubicación centralizada para almacenar contraseñas para asuntos como bases de datos, claves de API y certificados. Una vez que se introduce un secreto en el almacén, no se muestra de nuevo y los comandos para extraerlo y verlo están pensados para resultar complicados. La información en la caja fuerte se protege por medio del cifrado de software o los módulos de seguridad de hardware validados por FIPS 140-2 nivel 2.
El acceso al almacén de claves se obtiene por medio de RBAC, lo que conlleva que cualquier usuario pueda acceder a la información del almacén. Imagine que una aplicación web quiere acceder a la cadena de conexión de la base se datos almacenada en Azure Key Vault. Para obtener el acceso, las aplicaciones necesitan ejecutar una entidad de servicio. Al asumir este rol, pueden leer los secretos de la caja fuerte. Hay una serie de configuraciones de seguridad distintas que pueden limitar aún más el acceso que una aplicación tiene al almacén para que no se puedan actualizar los secretos, solo leerlos.
El acceso al almacén de claves puede supervisarse para garantizar que únicamente las aplicaciones previstas accedan al almacén. Los registros se pueden integrar en Azure Monitor, al desbloquear la capacidad de configurar alertas ante situaciones inesperadas.
Kubernetes
En Kubernetes, hay un servicio parecido para mantener pequeños fragmentos de información secreta. Los secretos de Kubernetes pueden establecerse con el típico comando ejecutable kubectl.
Para crear un secreto, busque la versión base64 de los valores que se van a almacenar:
echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
A continuación, añádala a un archivo llamado secret.yml, por ejemplo, que se parece al siguiente ejemplo:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Por último, se puede cargar este archivo en Kubernetes al ejecutar el siguiente comando:
kubectl apply -f ./secret.yaml
Estos secretos se pueden montar en volúmenes o exponerse a procesos de contenedor por medio de variables de entorno. El enfoque de la aplicación Twelve-factor para compilar aplicaciones sugiere usar el denominador común más bajo para transmitir la configuración a una aplicación. Las variables de entorno son el denominador común más bajo, ya que se admiten independientemente del sistema operativo o la aplicación.
Otra opción consiste en acceder a los secretos en Azure Key Vault desde Kubernetes para poder usar los secretos integrados de Kubernetes. Asignar un rol RBAC al contenedor que busca cargar secretos es la forma más sencilla de conseguirlo. A continuación, la aplicación puede usar lar API de Azure Key Vault para tener acceso a los secretos. Sin embargo, este enfoque necesita modificar el código y no sigue el patrón de usar variables de entorno. En su lugar, se pueden insertar valores en un contenedor. En realidad, este enfoque es más seguro que usar directamente los secretos de Kubernetes, ya que los usuarios del clúster pueden tener acceso a ellos.
Cifrado en tránsito y en reposo
Mantener los datos seguros es importante, tanto si están en un disco o en tránsito entre varios servicios diferentes. Cifrar los datos en un formato que no se pueda leer fácilmente es la forma más eficaz de evitar la filtración de datos. En Azure se admite una amplia gama de opciones de cifrado.
En tránsito
Hay distintas maneras de cifrar el tráfico en la red en Azure. Se suele acceder a los servicios de Azure a través de conexiones que usan Seguridad de la capa de transporte (TLS). Por ejemplo, se necesitan conexiones TLS en todas las conexiones a las API de Azure. De igual forma, las conexiones a puntos de conexiones en el almacenamiento de Azure se pueden restringir para que solo funcionen por medio de conexiones cifradas TLS.
TLS es un protocolo complicado y saber que la conexión usa TLS no es garantía de seguridad. Por ejemplo, TLS 1.0 es habitualmente insegura y TLS 1.1 no es mucho mejor. Incluso en las versiones de TLS, existen varios valores de configuración que pueden facilitar el descifrado de conexiones. La línea de acción más recomendable es comprobar que los protocolos de la conexión del servidor están actualizados y configurados correctamente.
Un servicio externo, como SSL Server Test del laboratorio SSL, puede hacer esta comprobación. Una serie de pruebas del punto de conexión típico de Azure, en este caso un punto de conexión de Service Bus, genera una puntuación A casi perfecta.
Incluso servicios como la bases de datos de Azure SQL usan cifrado TLS para ocultar los datos. El cifrado de datos en tránsito mediante TLS resulta muy interesante porque ni siquiera Microsoft es capaz de escuchar la conexión entre ordenadores que ejecutan TLS. Esto debería tranquilizar a las empresas preocupadas de que sus datos puedan estar en riesgo por parte de Microsoft o incluso de entidades estatales con más recursos que el atacante típico.
Figura 9-5. Informe de laboratorios en el que se muestra una puntuación A para un punto de conexión de Service Bus.
Aunque este nivel de cifrado no será suficiente todo el tiempo, debería inspirar la confianza de que las conexiones TLS de Azure son bastante seguras. Azure seguirá progresando sus estándares en seguridad a medida que se mejora el cifrado. Es reconfortante saber que alguien estudia los estándares de seguridad y actualiza Azure a medida que mejoran.
En reposo
En cualquier aplicación, hay una serie de lugares donde los datos reposan en el disco. El propio código de la aplicación se carga desde un mecanismo de almacenamiento. La mayoría de las aplicaciones también usan algún tipo de base de datos como SQL Server, Cosmos DB o incluso Table Storage, que es increíblemente rentable. Todas esas bases de datos usan almacenamiento considerablemente cifrado para garantizar que nadie, aparte de las aplicaciones con permisos adecuados, pueda leer los datos. Incluso los operadores del sistema no pueden leer datos que se han cifrado. Por lo tanto, los clientes pueden tener la seguridad de que la información secreta permanece secreta.
Storage
Lo fundamental de gran parte de Azure es el motor de Azure Storage. Los discos de máquina virtual se montan encima de Azure Storage. Azure Kubernetes Service se ejecutan en máquinas virtuales que se hospedan en Azure Storage. Incluso las tecnologías sin servidor, como Azure Functions Apps y Azure Container Instances, agotan el disco que forma parte de Azure Storage.
Si Azure Storage está correctamente cifrado, proporciona una fundación para que se cifren la mayoría de lo demás. Azure Storage se cifra con FIPS 140-2 que es compatible con 256-bit AES. Esta tecnología de cifrado está muy bien valorada y ha sido objeto de análisis teóricos exhaustivos durante los últimos veinte años. En la actualidad, no hay ataques viables que permitan a alguien sin conocimientos de la clave leer los datos cifrados por AES.
De forma predeterminada, Microsoft administra las claves que se usan para cifrar Azure Storage. Existen protecciones considerables para asegurarse de que no se accede a estas claves de forma maliciosa. Sin embargo, los usuarios con requisitos de cifrado específicos también pueden proporcionar sus propias claves de almacenamiento que se gestionan en Azure Key Vault. Estas claves se pueden revocar en cualquier momento, lo que representaría eficazmente los contenidos de la cuenta de almacenamiento que las usa de forma inaccesible.
Las máquinas virtuales usan almacenamiento cifrado, pero es posible agregar otra capa de cifrado mediante tecnologías como BitLocker en Windows o DM-Crypt en Linux. Con estas tecnologías, incluso si se ha filtrado fuera del almacenamiento la imagen del disco, sería casi imposible leerla.
Azure SQL
Las bases de datos hospedadas en Azure SQL usan una tecnología denominada Cifrado de datos transparente (TDE) para garantizar que los datos permanecen cifrados. En las bases de datos SQL creadas recientemente está habilitada de forma predeterminado, pero en las bases de datos heredadas hay que habilitarla manualmente. TDE ejecuta el cifrado y el descifrado en tiempo real tanto de la base de datos como de las copias de seguridad y los registros de transacciones.
Los parámetros de cifrado se almacenan en la base de datos master y, al iniciarse, se leen en la memoria en las operaciones restantes. Por esta razón, la base de datos master debe permanecer sin cifrar. Microsoft administra la clave real. Sin embargo, los usuarios con requisitos de seguridad exactos pueden proporcionar su propia clave en Key Vault casi del mismo modo que en Azure Storage. El Key Vault ofrece servicios como la rotación y revocación de claves.
La parte «transparente» del TDS se explica por el hecho de que no hay cambios de clientes que hagan necesario usar una base de datos cifrada. Aunque este enfoque ofrece una seguridad sólida, si se filtra la contraseña de la base de datos, los usuarios pueden descifrar los datos. Existe otro enfoque que cifra columnas o tablas individuales en una base de datos. Con Always Encrypted se garantiza que en ningún momento los datos cifrado figuren como texto sin formato en la base de datos.
Para configurar este nivel de cifrado se requiere ejecutar mediante un asistente de SQL Server Management Studio para seleccionar el tipo de cifrado y en qué parte de Key Vault se van a almacenar las claves asociadas.
Figura 9-6. Selección de columnas de una tabla para cifrarlas mediante Always Encrypted.
Las aplicaciones cliente que leen información de esas columnas cifradas tienen que hacer excepciones para leer los datos cifrados. Las cadenas de conexiones tienen que actualizarse con Column Encryption Setting=Enabled y deben recuperarse las credenciales de cliente de la Key Vault. El cliente de SQL Server debe, a continuación, prepararse con las claves de cifrado de columna. Una vez hecho esto, en las acciones restantes se usan interfaces estándar para el cliente SQL. Es decir, las herramientas como Dapper y Entity Framework, basadas en SQL Client, seguirán funcionando sin cambios. Always Encrypted puede no estar disponible todavía para cada controlador de SQL Server en cada lenguaje.
TDE y Always Encrypted pueden usarse con claves específicas de cliente y el uso combinado de las dos garantiza que incluso los requisitos de cifrado más exactos sean compatibles.
Cosmos DB
Cosmos DB es la base de datos más reciente proporcionada por Microsoft en Azure. Se ha construido desde la base pensando en la seguridad y la criptografía. El cifrado AES-256bit es estándar en todas las bases de datos de Cosmos DB y no se puede deshabilitar. Junto con el requisito TLS 1.2 para la comunicación, se cifra la solución de almacenamiento completa.
Figura 9-7. El cifrado del flujo de datos con Cosmos DB.
Aunque Cosmos DB no proporciona claves de cifrado de cliente, el equipo ha trabajado duramente para garantizar que siga siendo compatible con PCI-DSS sin eso. Cosmos DB tampoco admite todavía ningún tipo de columna única parecido a Always Encrypted de Azure SQL.
Mantenimiento de la seguridad
Azure cuenta con todas las herramientas necesarias para liberar un producto altamente seguro. Sin embargo, una cadena es tan fuerte como su eslabón más débil. Si las aplicaciones implementadas basadas en Azure no se desarrollan sin una mentalidad de seguridad y auditorías de seguridad adecuadas, se convierten en el eslabón débil de la cadena. Hay herramientas de análisis estático excelentes, bibliotecas de cifrado y prácticas de seguridad que pueden usarse para garantizar que el software instalado en Azure sea tan seguro como Azure. Entre los ejemplos se incluyen herramientas de análisis estáticos, bibliotecas de cifrado y prácticas de seguridad.
