Seguridad de Azure para aplicaciones nativas en la nube

Las aplicaciones nativas de la nube pueden ser más fáciles y difíciles de proteger que las aplicaciones tradicionales. A la desventaja, debe proteger aplicaciones más pequeñas y dedicar más energía a crear la infraestructura de seguridad. La naturaleza heterogénea de los lenguajes de programación y los estilos en la mayoría de las implementaciones de servicios también significa que debe prestar más atención a los boletines de seguridad de muchos proveedores diferentes.

Por otro lado, 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, es probable que sea más difícil que el atacante realice el salto a otro sistema que en una aplicación monolítica. Los límites de proceso son límites seguros. Además, si se expone una copia de seguridad de base de datos, el daño es más limitado, ya que esa base de datos solo contiene un subconjunto de datos y es poco probable que contenga datos personales.

Modelado de amenazas

Independientemente de si las ventajas superan las desventajas de las aplicaciones nativas de la nube, se debe seguir la misma mentalidad de seguridad holística. La seguridad y el enfoque a la seguridad deben formar parte de cada paso del proceso de desarrollo y operaciones. Al planear una aplicación, haga preguntas como:

• ¿Cuál sería el impacto de estos datos que se pierden?
• ¿Cómo podemos limitar el daño de los datos incorrectos que se insertan en este servicio?
• ¿Quién debe tener acceso a estos datos?
• ¿Existen directivas de auditoría en torno al proceso de desarrollo y versión?

Todas estas preguntas forman parte de un proceso denominado modelado de amenazas. Este proceso intenta responder a la pregunta de qué amenazas hay en el sistema, la probabilidad de que las amenazas sean y el posible daño de ellas.

Una vez establecida la lista de amenazas, debe decidir si merece la pena mitigarlas. A veces, una amenaza es tan poco probable y costosa de planear para que no valga la pena gastar energía en ella. Por ejemplo, algunos actores de nivel de estado podrían insertar cambios en el diseño de un proceso que usan millones de dispositivos. Ahora, en lugar de ejecutar un determinado fragmento de código en el anillo 3, ese código se ejecuta en el anillo 0. Este proceso permite una vulnerabilidad de seguridad que puede omitir el hipervisor y 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.

Los procesadores modificados son difíciles de detectar sin un microscopio y conocimientos avanzados sobre el diseño de silicio de ese procesador. Es poco probable que este escenario se produzca y sea costoso mitigarlo, por lo que probablemente ningún modelo de amenazas recomendaría crear protección contra vulnerabilidades de seguridad.

Las amenazas más probables, como los controles de acceso rotos que permiten ataques de incremento (reemplazando Id por Id=2 en la dirección URL) o la inyección SQL, son más atractivas para desarrollar protecciones. Las mitigaciones de estas amenazas son bastante razonables para crear y evitar agujeros de seguridad embarazosos que manchan la reputación de la empresa.

Principio de privilegio mínimo

Una de las ideas fundamentales en la seguridad informática es el principio de privilegios mínimos (POLP). En realidad es una idea fundamental en la mayoría de las formas de seguridad, ya sea digital o física. En resumen, el principio es que cualquier usuario o proceso debe tener el menor número de derechos posibles para ejecutar su tarea.

Por ejemplo, piense en los tellers de un banco: acceder a la caja fuerte es una actividad poco común. Por lo tanto, el cajero promedio no puede abrir la caja fuerte. Para obtener acceso, deben escalar su solicitud a través de un administrador bancario, que realiza comprobaciones de seguridad adicionales.

En un sistema informático, un ejemplo fantástico es los derechos de un usuario que se conecta a una base de datos. En muchos casos, hay una única cuenta de usuario que se usa para compilar la estructura de la base de datos y ejecutar la aplicación. Excepto en 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 proporcionen distintos niveles de privilegios. La aplicación solo debe usar el nivel de permiso que concede acceso de lectura y escritura a los datos de las tablas. Este tipo de protección eliminaría los ataques destinados a quitar tablas de base de datos o introducir desencadenadores malintencionados.

Casi todas las partes de la creación de una aplicación nativa de la nube pueden beneficiarse de recordar el principio de privilegios mínimos. Puede encontrarlo en acción al configurar firewalls, grupos de seguridad de red, roles y ámbitos en el control de acceso basado en roles (RBAC).

Pruebas de penetración

A medida que las aplicaciones se complican más el número de vectores de ataque aumenta a una velocidad alarmante. El modelado de amenazas es defectuoso en que tiende a ser ejecutado por las mismas personas que compilan el sistema. De la misma manera que muchos desarrolladores tienen problemas para visualizar las interacciones del usuario y, a continuación, crear interfaces de usuario no utilizables, la mayoría de los desarrolladores tienen dificultades para ver cada vector de ataque. También es posible que los desarrolladores que compilan el sistema no estén bien versados en metodologías de ataque y pierdan algo crucial.

Las pruebas de penetración o las "pruebas de lápiz" implican incorporar 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, encontrarán amplios agujeros de seguridad que deben revisarse. A veces, el vector de ataque será algo totalmente inesperado, como aprovechar un ataque de suplantación de identidad contra el CEO.

Azure en sí está experimentando constantemente ataques de un equipo de hackers dentro de Microsoft. A lo largo de los años, han sido los primeros en encontrar docenas de vectores de ataque potencialmente catastróficos, cerrandolos antes de que se puedan aprovechar externamente. Cuanto más tentador sea un objetivo, más probable es que los actores externos intenten aprovecharlo y que haya pocos destinos en el mundo más tentadores que Azure.

Monitorización

Si un atacante intenta penetrar una aplicación, debería haber alguna advertencia. Con frecuencia, los ataques se pueden detectar examinando los registros de los servicios. Los ataques dejan señales reveladoras que se pueden detectar antes de que tengan éxito. Por ejemplo, un atacante que intenta adivinar una contraseña realizará muchas solicitudes a un sistema de inicio de sesión. La supervisión en torno al sistema de inicio de sesión puede detectar patrones extraños que están fuera de línea con el patrón de acceso típico. Esta supervisión se puede convertir en una alerta que, a su vez, puede alertar a una persona de operaciones para activar algún tipo de contramedida. Un sistema de supervisión muy maduro puede incluso tomar medidas en función de estas desviaciones agregando reglas de forma proactiva para bloquear las solicitudes o limitar las respuestas.

Protección de la compilación

Un lugar donde a menudo se pasa por alto la seguridad está en torno al proceso de compilación. No solo se deben ejecutar comprobaciones de seguridad durante la compilación, como el análisis de código inseguro o las credenciales registradas, sino que la propia compilación debe ser segura. Si el servidor de compilación está en peligro, proporciona un vector fantástico para introducir código arbitrario en el producto.

Imagine que un atacante busca robar las contraseñas de las personas que inician sesión en una aplicación web. Podrían introducir una etapa de construcción que modifique el código extraído para redirigir cualquier solicitud de inicio de sesión hacia otro servidor. La próxima vez que el código pase por la compilación, se actualiza de forma silenciosa. El examen de vulnerabilidades de código fuente no detectará esta vulnerabilidad, ya que se ejecuta antes de la compilación. De igual manera, nadie se dará cuenta en una revisión de código porque las etapas de construcción residen en el servidor de compilación. El código vulnerado irá a producción donde puede recopilar contraseñas. Probablemente no haya ningún registro de auditoría de los cambios en el proceso de construcción, o al menos nadie está supervisando dicha auditoría.

Este escenario es un ejemplo perfecto de un objetivo aparentemente de bajo valor que se puede usar para penetrar en el sistema. Una vez que un atacante infringe el perímetro del sistema, puede empezar a trabajar en la búsqueda de formas de elevar sus permisos hasta el punto de que puedan causar daños reales en cualquier lugar que les guste.

Creación de código seguro

.NET Framework ya es un marco bastante seguro. Evita algunos de los riesgos del código no administrado, como salirse de los límites de las matrices. El trabajo se realiza activamente para corregir los agujeros de seguridad a medida que se detectan. Incluso hay un programa de recompensas por errores que paga a los investigadores para encontrar problemas en el marco y notificarlos en lugar de aprovecharlos.

Hay muchas maneras de proteger el código de .NET. Las instrucciones siguientes, como las directrices de codificación segura para el artículo de .NET , son un paso razonable que se debe seguir para asegurarse de que el código es seguro desde cero. El OWASP top 10 es otra guía inestimable para crear código seguro.

El proceso de compilación es un buen lugar para poner herramientas de examen para detectar problemas en el código fuente antes de convertirlos en producción. La mayoría de los proyectos tienen dependencias en algunos otros paquetes. Una herramienta que puede buscar paquetes obsoletos detectará problemas en una compilación nocturna. Incluso al compilar imágenes de Docker, resulta útil comprobar y asegurarse de que la imagen base no tiene vulnerabilidades conocidas. Otra cosa que hay que comprobar es que nadie ha comprobado accidentalmente las credenciales.

Seguridad integrada

Azure está diseñado para equilibrar la facilidad de uso y la seguridad de la mayoría de los usuarios. Los distintos usuarios tendrán requisitos de seguridad diferentes, por lo que deben ajustar su enfoque a la seguridad en la nube. Microsoft publica una gran cantidad de información de seguridad en el Centro de confianza. Este recurso debe ser la primera parada para aquellos profesionales interesados en comprender cómo funcionan las tecnologías integradas de mitigación de ataques.

En Azure Portal, Azure Advisor es un sistema que examina constantemente un entorno y realiza recomendaciones. Algunas de estas recomendaciones están diseñadas para ahorrar dinero a los usuarios, pero otras están diseñadas para identificar configuraciones potencialmente no seguras, como tener un contenedor de almacenamiento abierto al mundo y no protegidos por una red virtual.

Infraestructura de red de Azure

En un entorno de implementación local, una gran cantidad de energía se dedica a configurar redes. La configuración de enrutadores, conmutadores y cosas por el estilo es complicada. Las redes permiten que determinados recursos hablen con otros recursos y eviten el acceso en algunos casos. Una regla de red frecuente es restringir el acceso al entorno de producción desde el entorno de desarrollo en caso de que un fragmento de código parcialmente desarrollado falle y borre una cantidad de datos.

De fábrica, la mayoría de los recursos de PaaS de Azure solo tienen la configuración de red más básica y permisiva. Por ejemplo, cualquier usuario de Internet puede acceder a un servicio de aplicaciones. Las nuevas instancias de SQL Server suelen estar restringidas, de modo que las partes externas no puedan acceder a ellas, pero se permiten los intervalos de direcciones IP usados por Azure en sí. Por lo tanto, aunque SQL Server está protegido frente a amenazas externas, un atacante solo necesita configurar una cabeza de puente de Azure desde donde pueden iniciar ataques contra todas las instancias de SQL en Azure.

Afortunadamente, la mayoría de los recursos de Azure se pueden colocar en una instancia de Azure Virtual Network que permite un control de acceso específico. De forma similar a la forma en que las redes locales establecen redes privadas que están protegidas del mundo más amplio, las redes virtuales son islas de direcciones IP privadas que se encuentran dentro de la red de Azure.

Figura 9-1. Una red virtual en Azure.

De la misma manera que las redes locales tienen un firewall que rige el acceso a la red, puede establecer un firewall similar 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 son conexiones entrantes que requieren alguna forma de excepción de firewall explícita.

Con la red establecida, los recursos internos, como las cuentas de almacenamiento, solo se pueden configurar para permitir el acceso por los recursos que también están en la red virtual. Este firewall proporciona un nivel adicional de seguridad, si se filtran las claves de esa cuenta de almacenamiento, los atacantes no podrían conectarse a ella para aprovechar las claves filtradas. Este escenario es otro ejemplo del principio de privilegios mínimos.

Los nodos de un clúster de Azure Kubernetes pueden participar en una red virtual igual que otros recursos que son más nativos de Azure. Esta funcionalidad se denomina Interfaz de red de contenedor de Azure. De hecho, asigna una subred dentro de la red virtual en la que se asignan las máquinas virtuales y las imágenes de contenedor.

Continuando con la ilustración del principio de privilegios mínimos, no todos los recursos de una Red Virtual necesitan comunicarse con cada uno de los demás recursos. Por ejemplo, en una aplicación que proporciona una API web a través de una 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 uso compartido de datos entre ellos pasará por la aplicación web. Por lo tanto, se podría usar un grupo de seguridad de red (NSG) para denegar el tráfico entre los dos servicios.

Una directiva de prohibir la comunicación entre recursos puede ser molesta para implementar, especialmente cuando se proviene de un contexto de Azure sin restricciones de tráfico. En otras nubes, el concepto de grupos de seguridad de red es mucho más frecuente. Por ejemplo, la directiva predeterminada en AWS es que los recursos no se pueden comunicar entre sí hasta que las reglas de un NSG lo habiliten. Aunque es más lento desarrollar esto, un entorno más restrictivo proporciona un valor predeterminado más seguro. El uso de procedimientos adecuados de DevOps, especialmente el uso de Azure Resource Manager o Terraform para administrar permisos puede facilitar el control de las reglas.

Las redes virtuales también pueden ser útiles al configurar la comunicación entre recursos locales y en la nube. Se puede usar una red privada virtual para conectar sin problemas las dos redes. Este enfoque permite ejecutar una red virtual sin ningún tipo de puerta de enlace para escenarios en los que todos los usuarios están en el sitio. Hay una serie de tecnologías que se pueden usar para establecer esta red. Lo más sencillo 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 costo por byte que cualquier otro tráfico. En escenarios en los que es deseable más ancho de banda o más seguridad, Azure ofrece un servicio denominado ExpressRoute que usa un circuito privado entre una red local y Azure. Es más costoso y difícil de establecer, pero también más seguro.

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 mediante esta identidad en lugar de o además de usar claves o contraseñas.

Entidades de seguridad

El primer componente de RBAC es una entidad de seguridad. Una entidad de seguridad puede ser un usuario, un grupo, una entidad de servicio o una identidad administrada.

Figura 9-2. Diferentes tipos de entidades de seguridad.

• Usuario: cualquier usuario que tenga una cuenta en Azure Active Directory es un usuario.
• Grupo: colección de usuarios de Azure Active Directory. Como miembro de un grupo, un usuario asume los roles de ese grupo además de los suyos propios.
• Entidad de servicio: una identidad de seguridad bajo la cual se ejecutan servicios o aplicaciones.
• Identidad administrada: una identidad de Azure Active Directory administrada por Azure. Las identidades administradas se suelen usar al desarrollar aplicaciones en la nube que administran las credenciales para autenticarse en los servicios de Azure.

La entidad de seguridad se puede aplicar a casi cualquier recurso. Este aspecto significa que es posible asignar una entidad de seguridad a un contenedor que se ejecuta en Azure Kubernetes, lo que le permite acceder a secretos almacenados en Key Vault. Una función de Azure podría asumir un permiso que le permita 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, sus permisos se pueden administrar de forma granular mediante roles y ámbitos.

Funciones

Una entidad de seguridad puede asumir muchos roles o, con una analogía más sartorial, llevar muchos sombreros. Cada rol define una serie de permisos, como "Leer mensajes del punto de conexión de Azure Service Bus". El conjunto de permisos efectivo 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 de RBAC.

Azure tiene integrados varios roles de alto nivel, como propietario, colaborador, lector y administrador de cuentas de usuario. Con el rol de Propietario, una entidad de seguridad 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 puede asignar permisos. Un lector solo puede ver los recursos de Azure existentes y un administrador de cuentas de usuario puede administrar el acceso a los recursos de Azure.

Los roles integrados más pormenorizados, como colaborador de zona DNS , tienen derechos limitados a un único servicio. Las entidades de seguridad pueden asumir cualquier número de roles.

Ámbitos

Los roles se pueden aplicar a un conjunto restringido de recursos dentro de Azure. Por ejemplo, al aplicar el ámbito al ejemplo anterior de lectura desde una cola de Service Bus, puede restringir el permiso a una sola cola: "Leer mensajes desde el punto de conexión de Azure Service Bus blah.servicebus.windows.net/queue1".

El ámbito puede ser tan estrecho como un único recurso o se puede aplicar a todo un grupo de recursos, una suscripción o incluso un grupo de administración.

Al probar si una entidad de seguridad tiene ciertos permisos, se tiene en cuenta la combinación de rol y ámbito. Esta combinación proporciona un mecanismo de autorización eficaz.

Negar

Anteriormente, solo se permitían reglas "permitidas" para el Control de Acceso Basado en Roles (RBAC). Este comportamiento hizo que algunos ámbitos se complicaran de construir. Por ejemplo, permitir que una entidad de seguridad acceda a todas las cuentas de almacenamiento, excepto a una, requería conceder un permiso explícito a un número potencialmente interminable de cuentas de almacenamiento. Cada vez que se creó una nueva cuenta de almacenamiento, tendría que agregarse a esta lista de cuentas. Esto agregó una sobrecarga de administración que ciertamente no era deseable.

Las reglas de denegación tienen prioridad sobre las reglas de permiso. Ahora, la representación del mismo ámbito de “permitir todo menos uno” podría describirse como dos reglas: “permitir todo” y “denegar a este específico”. Las reglas de denegación no solo facilitan la administración, sino que permiten recursos que son más seguros al denegar el acceso a todos.

Comprobación del acceso

Como puede imaginar, tener un gran número de roles y ámbitos puede hacer que averiguar los permisos efectivos de un principal de servicio sea bastante difícil. Apilar reglas de denegación sobre eso solo sirve para aumentar la complejidad. Afortunadamente, hay una calculadora de permisos que permite visualizar los permisos efectivos para cualquier principal de servicio. Normalmente se encuentra en la pestaña IAM del portal, como se muestra en la figura 9-3.

Figura 9-4. Calculadora de permisos para un servicio de aplicaciones.

Protección de secretos

Las contraseñas y los certificados son un vector de ataque común para los atacantes. El hardware de descifrado de contraseñas puede realizar un ataque por fuerza bruta 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, con una gran variedad de caracteres. Estas contraseñas son exactamente el tipo de contraseñas casi imposibles de recordar. Afortunadamente, las contraseñas de Azure no necesitan ser conocidas por ningún usuario.

Muchos expertos en seguridad sugieren que usar un administrador de contraseñas para mantener sus propias contraseñas es el mejor enfoque. 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 cosas como bases de datos, claves de API y certificados. Una vez que se introduce un secreto en la Bóveda, nunca se muestra de nuevo, y los comandos para extraerlo y verlo son intencionadamente complicados. La información de la caja fuerte está protegida mediante el cifrado de software o los módulos de seguridad de hardware validados FIPS 140-2 Nivel 2.

El acceso a la bóveda de claves se proporciona a través de los RBACs, lo que significa que no cualquier usuario puede acceder a la información de la bóveda. Supongamos que una aplicación web desea acceder a la cadena de conexión de base de datos almacenada en Azure Key Vault. Para obtener acceso, las aplicaciones necesitan ejecutarse a través de una entidad de servicio. Bajo este rol asumido, pueden leer los secretos de la caja fuerte. Hay varias configuraciones de seguridad diferentes que pueden limitar aún más el acceso que una aplicación tiene al almacén, de modo que no pueda actualizar secretos sino que solo pueda leerlos.

Se puede supervisar el acceso a la bóveda de claves para asegurarse de que solo las aplicaciones esperadas accedan a la bóveda. Los registros se pueden integrar de nuevo en Azure Monitor, lo que permite configurar alertas cuando se encuentran condiciones inesperadas.

Kubernetes

En Kubernetes, hay un servicio similar para mantener pequeños fragmentos de información secreta. Los secretos de Kubernetes se pueden establecer a través del archivo ejecutable típico kubectl .

Crear un secreto es tan sencillo como buscar 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, agregarlo a un archivo de secretos denominado secret.yml que, por ejemplo, es similar al ejemplo siguiente:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Por último, este archivo se puede cargar en Kubernetes mediante la ejecución del siguiente comando:

kubectl apply -f ./secret.yaml

Estos secretos se pueden integrar en volúmenes o exponerse a procesos del contenedor a través de variables de entorno. El enfoque de la aplicación Doce factores para construir 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.

Una alternativa a usar los secretos integrados de Kubernetes es acceder a los secretos de Azure Key Vault desde Kubernetes. La manera más sencilla de hacerlo es asignar un rol de RBAC al contenedor que busca cargar secretos. Después, la aplicación puede usar las API de Azure Key Vault para acceder a los secretos. Sin embargo, este enfoque requiere modificaciones en el código y no sigue el patrón de uso de variables de entorno. En su lugar, es posible insertar valores en un contenedor. Este enfoque es realmente más seguro que usar los secretos de Kubernetes directamente, ya que los usuarios del clúster pueden acceder a ellos.

Cifrado en tránsito y en reposo

Mantener los datos seguros es importante si está en disco o transitando entre varios servicios diferentes. La manera más eficaz de evitar que los datos se filtren es cifrarlos en un formato que otros usuarios no puedan leer fácilmente. Azure admite una amplia gama de opciones de cifrado.

En tránsito

Hay varias maneras de cifrar el tráfico en la red en Azure. Normalmente, el acceso a los servicios de Azure se realiza a través de conexiones que usan seguridad de la capa de transporte (TLS). Por ejemplo, todas las conexiones a las API de Azure requieren conexiones TLS. Del mismo modo, las conexiones a extremos en Azure Storage se pueden restringir para que funcionen solo a través de conexiones cifradas TLS.

TLS es un protocolo complicado y simplemente sabe que la conexión usa TLS no es suficiente para garantizar la seguridad. Por ejemplo, TLS 1.0 es crónicamente inseguro y TLS 1.1 no es mucho mejor. Incluso dentro de las versiones de TLS, hay varias opciones de configuración que pueden facilitar el descifrado de las conexiones. El mejor curso de acción es comprobar y ver si la conexión del servidor usa up-to-date y protocolos bien configurados.

Esta comprobación se puede realizar mediante un servicio externo, como la prueba de servidor SSL de los laboratorios SSL. Una ejecución de prueba en un punto de conexión típico de Azure, en este caso, un punto de conexión de Service Bus produce una puntuación casi perfecta de A.

Incluso los servicios como las bases de datos de Azure SQL usan el cifrado TLS para mantener ocultos los datos. La parte interesante sobre el cifrado de los datos en tránsito mediante TLS es que no es posible, incluso para Microsoft, escuchar la conexión entre ordenadores que ejecutan TLS. Esto debe proporcionar tranquilidad a las empresas preocupadas por que sus datos puedan estar en riesgo, ya sea por parte de la propia Microsoft o incluso por un actor estatal con más recursos que el atacante estándar.

Figura 9-5. Informe de SSL Labs que muestra una calificación de A para un punto de conexión de Service Bus.

Aunque este nivel de cifrado no va a ser suficiente durante todo el tiempo, debe inspirar la confianza de que las conexiones TLS de Azure son bastante seguras. Azure seguirá evolucionando sus estándares de seguridad a medida que mejora el cifrado. Es agradable saber que hay alguien que observa 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 se encuentran en el disco. El propio código de aplicación se carga desde algún 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 el increíblemente rentable Table Storage. Todas estas bases de datos usan almacenamiento muy cifrado para asegurarse de que nadie que no sea las aplicaciones con permisos adecuados pueda leer los datos. Incluso los operadores del sistema no pueden leer datos cifrados. Por lo tanto, los clientes pueden permanecer seguros de que su información secreta permanece secreta.

Almacenamiento

La base de gran parte de Azure es el motor de Azure Storage. Los discos de máquina virtual se montan sobre Azure Storage. Azure Kubernetes Service se ejecuta en máquinas virtuales que, por sí mismas, se hospedan en Azure Storage. Incluso las tecnologías sin servidor, como Azure Functions Apps y Azure Container Instances, se ejecutan sin disco que forma parte de Azure Storage.

Si Azure Storage está bien cifrado, proporciona una base para que prácticamente todo lo demás también se cifre. Azure Storage se cifra con AES de 256 bits compatibles con FIPS 140-2. Esta es una tecnología de cifrado bien considerada que ha sido objeto de un amplio examen académico en los últimos 20 años. En la actualidad, no hay ningún ataque práctico conocido que permitiría a alguien sin conocimiento de la clave leer los datos cifrados por AES.

De forma predeterminada, Microsoft administra las claves que se usan para cifrar Azure Storage. Existen amplias protecciones para asegurarse de evitar el acceso malintencionado a estas claves. Sin embargo, los usuarios con requisitos de cifrado concretos también pueden proporcionar sus propias claves de almacenamiento que se administran en Azure Key Vault. Estas claves se pueden revocar en cualquier momento, lo que haría que el contenido de la cuenta de almacenamiento sea inaccesible al utilizar dichas claves.

Las máquinas virtuales usan almacenamiento cifrado, pero es posible proporcionar otra capa de cifrado mediante tecnologías como BitLocker en Windows o DM-Crypt en Linux. Estas tecnologías significan que incluso si la imagen de disco se ha filtrado del almacenamiento, 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 asegurarse de que los datos permanecen cifrados. Está habilitado de forma predeterminada en todas las bases de datos SQL recién creadas, pero debe habilitarse manualmente para las bases de datos heredadas. TDE ejecuta el cifrado en tiempo real y el descifrado de no solo la base de datos, sino también las copias de seguridad y los registros de transacciones.

Los parámetros de cifrado se almacenan en la master base de datos y, al iniciarse, se leen en memoria para las operaciones restantes. Esto significa que la master base de datos 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 de la misma manera que para Azure Storage. Key Vault proporciona servicios como rotación y revocación de claves.

La parte "Transparente" de TDS procede del hecho de que no hay cambios de cliente necesarios para usar una base de datos cifrada. Aunque este enfoque proporciona una buena seguridad, la pérdida de la contraseña de la base de datos es suficiente para que los usuarios puedan descifrar los datos. Hay otro enfoque que cifra columnas o tablas individuales en una base de datos. Always Encrypted garantiza que, en ningún momento, los datos cifrados aparezcan en texto sin formato dentro de la base de datos.

La configuración de este nivel de cifrado requiere ejecutarse mediante un asistente en SQL Server Management Studio para seleccionar el tipo de cifrado y dónde en Key Vault almacenar las claves asociadas.

Figura 9-6. Selección de columnas en una tabla que se va a cifrar mediante Always Encrypted.

Las aplicaciones cliente que leen información de estas columnas cifradas deben realizar asignaciones especiales para leer datos cifrados. Las cadenas de conexión deben actualizarse con Column Encryption Setting=Enabled y las credenciales de cliente deben recuperarse de Key Vault. Después, el cliente de SQL Server debe estar preparado con las claves de cifrado de las columnas. Una vez hecho esto, las acciones restantes usan las interfaces estándar para el cliente SQL. Es decir, las herramientas como Dapper y Entity Framework, que se basan en sql Client, seguirán funcionando sin cambios. Always Encrypted puede que aún no esté disponible para todos los controladores de SQL Server en todos los lenguajes.

La combinación de TDE y Always Encrypted, ambas que se pueden usar con claves específicas del cliente, garantizan que se admita incluso los requisitos de cifrado más exactos.

Cosmos DB

Cosmos DB es la base de datos más reciente proporcionada por Microsoft en Azure. Se ha construido desde cero con seguridad y criptografía en mente. El cifrado AES-256bit es estándar para 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 toda la solución de almacenamiento.

Figura 9-7. Flujo de cifrado de datos en Cosmos DB.

Aunque Cosmos DB no proporciona claves de cifrado de cliente, el equipo ha realizado un trabajo significativo para asegurarse de que sigue siendo PCI-DSS compatible sin eso. Cosmos DB tampoco admite ningún tipo de cifrado de columna única similar a Always Encrypted de Azure SQL todavía.

Mantener la seguridad

Azure tiene todas las herramientas necesarias para liberar un producto altamente seguro. Sin embargo, una cadena solo es tan fuerte como su vínculo más débil. Si las aplicaciones implementadas encima de Azure no se desarrollan con una mentalidad de seguridad adecuada y auditorías de seguridad adecuadas, se convierten en el vínculo débil de la cadena. Hay muchas herramientas de análisis estáticos excelentes, bibliotecas de cifrado y prácticas de seguridad que se pueden usar para garantizar que el software instalado en Azure sea tan seguro como Azure. Algunos ejemplos son las herramientas de análisis estático y las bibliotecas de cifrado.