Información general
Las aplicaciones de nube se distribuyen por diseño. Asegurar la red externa que conecta la nube con la red interna adentro de la fábrica de Azure claramente es un componente crítico de seguridad de la plataforma. En el hospedaje tradicional, los clientes usan firewalls (servidores de seguridad) y otras configuraciones de red para proteger sus aplicaciones, sus datos y su infraestructura. Windows Azure cambia esa realidad porque en entornos de PaaS el cliente está escudado de casi toda la responsabilidad sobre la seguridad de red. Microsoft, como proveedor de nube, es responsable de la protección de la red sobre la cual se ejecuta la nube.
Los clientes que implementan sus datos y aplicaciones en Windows Azure deben estar seguros de que ataques de red tales como sniffing (olfateo) y ataques de tipo “man in the middle” están absolutamente mitigados dentro de los límites de la nube.
Este documento describe las medidas de seguridad empleadas por Windows Azure en la capa de redes.
Arquitectura de red
Windows Azure contiene cuatro tipos de nodos principales: nodos de Fabric Controller, nodos de cómputo, nodos de almacenamiento y nodos de infraestructura.
El Fabric Controller (FC) es el kernel del sistema operativo de Windows Azure. El FC automatiza casi todo, al aprovisionar, almacenar, enviar, supervisar y comandar las máquinas virtuales (VMs) y los servidores físicos que componen Azure. El FC está diseñado para satisfacer solicitudes y políticas de usuario y para optimizar y simplificar la implementación.
Aislamiento
El tejido de red de Windows Azure contiene tres diferentes redes aisladas:
• El VLAN principal – interconecta nodos de cliente no de confianza
• El VLAN FC – contiene FCs de confianza y sistemas de apoyo
• El VLAN de dispositivo – contiene red de confianza y otros dispositivos de infraestructura.
Los VLANs se utilizan para aislar los FCs, los nodos de cómputo y los demás dispositivos. Los VLANs dividen una red de tal manera que no es posible la comunicación entre VLANs sin que pasen por un enrutador, que previene que un nodo comprometido falsifique tráfico de fuera de su VLAN excepto a otros nodos en su VLAN, además de que se le impide eavesdropping (escuchar) el tráfico que no se origina en o se dirige a sus VLANs.
Se permite la comunicación del VLAN FC al VLAN principal, pero la comunicación no puede ser iniciada del VLAN principal al VLAN FC. La comunicación también está bloqueada del VLAN principal al dispositivo VLAN. Esto asegura que si un nodo que está implementando código del cliente está comprometido, no puede atacar nodos ni en el FC ni en VLANs de dispositivo.
La Figura 1 describe las diferentes redes aisladas implementadas en Windows Azure.
Figura 1Aislamiento de Fabric Controllers
Como el orquestador principal de gran parte del tejido de Windows Azure, controles significativos están se han implementado para mitigar las amenazas a los FCs, especialmente de Fabric Agents (FA) potencialmente comprometidos dentro de las aplicaciones del cliente. Comunicación de FC a FA es unidireccional: el FA implementa un servicio protegido por SSL que se accede del FC y responde únicamente a solicitudes. El FA no puede iniciar conexiones al FC o a otros nodos internos privilegiados. El FC analiza (parses) fuertemente todas las respuestas como si fueran comunicaciones no confiables. Adicionalmente, los FCs y los dispositivos incapaces de implementar SSL están en VLANs separadas, que limitan la exposición de sus interfaces de autenticación a un nodo comprometido que hospeda VMs.
Administración remota de Fabric Controllers
Los Fabric Controllers tienen un API accesible al RPC que acepta comandos de SMAPI y de administradores de Windows Azure. Decisiones de nivel de política son exigidos por SMAPI en el nivel de la aplicación, que únicamente generará solicitudes concernientes a los recursos del cliente, basándose en la identidad autenticada del cliente. Los FCs hacen finer-grained Access-control decisions, como corresponde a su rol de facilidad de administración de aprovisionamiento central de bajo nivel. Las conexiones a FCs se hacen vía SSL, en el que el cliente se autentica con un certificado de cliente y la certificate fingerprint (huella de certificado) determina si un llamante tiene el nivel de acceso apropiado para hacer una solicitud determinada.
Mitigación de la Denegación de Servicio o DOS
Windows Azure tiene las conexiones más amplias al internet disponibles en la industria. Los conectores se distribuyen alrededor del globo terráqueo, y así es improbable que alguien pueda lograr producir suficiente tráfico malicioso para inundar estas conexiones y cortar a Azur de la red pública.
Si una aplicación individual es atacada, es posible spin girar temporalmente varias nuevas instancias de cálculo hasta que el ataque pase, lo cual típicamente es mitigación suficiente ya que la mayoría de ataques de denegación de servicio no duran mucho tiempo. Microsoft está considerando maneras de identificar tráfico malicioso y de no bloquearlo mientras entra el tejido Azure, pero este tipo de protección aún no ha sido implementada.
Ataques de denegación de servicio que se originen al interior del tejido son parcialmente manejados por la infraestructura. Windows Azure no detecta ni bloquea tráfico malicioso, pero sí se asegura de que todos los VMs en ejecución reciban los recursos por los que pagaron. Un VM malicioso implementado en el tejido no puede consumir recursos ilimitados y causar colapso a sus vecinos, efectivamente mitigando un ataque de denegación de acceso interno.
Arquitectura de Nodos Azure
Los roles de Windows Azure se ejecutan adentro de las máquinas virtuales (VMs) implementadas en los nodos del centro.
Entre muchas otras ventajas, la virtualización permite el aislamiento completo entre los distintos códigos de cliente. Al interior de Azure, cada nodo que se conecta a extremos adentro de Windows Azure se implementa con un servidor de seguridad (firewall) que previene que suplante (impersonating) direcciones IP. Cuando dos nodos están hablando adentro de Azure, no necesitan cifrado para garantizar la identidad del otro porque las direcciones de IP son comprobadas por la red misma.
Cada máquina virtual (VM) tiene 1, 2, 4 u 8 CPUs virtuales, y se le asignan hasta 14 GB de memoria. Las VMs ejecutan una versión especial de Windows Server 2008 o 2008 R2, con un servidor específico de software de operador de servicio instalado (IIS, .NET framework, etc.), dependiendo del rol de la VM. El sistema operativo tiene un número muy limitado de drivers de dispositivo.
Windows Firewall está habilitado en cada VM. Los únicos puertos abiertos y directamente direccionables (interna o externamente) en una VM de Windows Azure son aquellos explícitamente definidos en el archivo de Service Definition (Servicio de Definición file) configurado por el cliente.
El hipervisor se ejecuta directamente sobe el hardware y divide el nodo en un número variable de máquinas virtuales (VMs). El número de VMs implementado en cada nodo depende del número de CPUs que las VMs requieren. No hay ninguna situación en la que las VMs requieran más CPUs que las que realidad existan en el cuadro.
Cada nodo también tiene una máquina virtual de “raíz”, que ejecuta el sistema operativo de host en sistemas controlados por hipervisor. Azure usa una versión simplificada de Windows Server que incluyen únicamente aquellos componentes necesarios para hospedar VMs. Esto se hace tanto para mejorar el rendimiento como para reducir la superficie expuesta a ataques.
El hipervisor y el VM de raíz aseguran que todas las VMs obtengan una porción justa de los recursos disponibles. Esto previene una situación en la que un Rol malicioso consuma todos los recursos en el cuatro, poniendo a las otras VMs en un estado de colapso.
La Figura2 demuestra cómo el acceso de datos es filtrado por el VM de raíz y fluye a través de todo el hipervisor. Todo acceso a la red y al disco por parte de los VMs es mediado por el sistema operativo de raíz.
Figura 2
El conmutador de red virtual del hipervisor filtra todo el tráfico de y hacia las máquinas virtuales, y también previene ataques basados en sniffers contra otras VMS en el mismo host. Filtros adicionales están instalados para bloquear la difusión y el tráfico de multidifusión, con la excepción de lo que sea necesario para mantener las concesiones DHCP.
Filtrado de paquetes
El hipervisor y el sistema operativo de raíz proveen la red de filtros de paquete que aseguran que VMs no de confianza no puedan generar tráfico de identidad suplantada (spoofed traffick”) no directamente direccionado a ellos, yque no puedan dirigir tráfico a extremos protegidos de la infraestructura, y de que no puedan enviar o recibir tráfico de difusión inapropiada. Nodos de almacenamiento sólo ejecutan código y configuración provistos por Winsows Azure, y así el control de acceso se ajusta para permitir únicamente el acceso de cliente, de aplicación y de administración legítimos.
Acceso de clientes a las VMs se limita a través del filtrado de paquetes en equilibradores de carga y en la raíz del OS. En particular, la depuración remota, Servicios de Terminal remotos, y el acceso remoto los recursos compartidos de archivos no se permiten de manera predeterminada. Microsoft está haciendo planes para permitirle a sus clientes habilitar estos protocolos como una opción explícita in el futura.
Microsoft permite a sus clientes especificar si las conexiones de internet se aceptan (incluyendo instancias de rol de distintas aplicaciones) y de instancias de rol dentro de la misma aplicación. Las conexiones entre instancias de rol de distintas aplicaciones se consideran como reglas de conexiones y de conectividad al internet que son cumulativas; por ejemplo, si instancias de rol A y B pertenecen a distintas aplicaciones, la A únicamente puede abrir una conexión a la B si A puede abrir conexiones al internet y B puede aceptar conexiones al internet.
El FC traduce la lista de roles en una lista de instancias de rol, y de ahí a una lista de direcciones IP. Esta lista de direcciones IP la usa el FA para programar los filtros de paquete a sólo permitir comunicación al interior de la aplicación y hacia dichas direcciones IP. Esto les permite comunicarse con el internet y enviar tráfico a cualquier rol con visibilidad desde el internet a través de sus VIPs.
Firewalls (servidores de seguridad) incorporados
Comunicación con Windows Azure viaje a través de un número de firewalls (servidores de seguridad).
- Firewall de VM invitada:
Además de filtraje de paquetes mejorado, que bloque el tráfico no autorizado, Windows Firewall está habilitado en cada VM. Los únicos puertos abiertos y directamente direccionables (Interna o externa) de tráfico de red entrante en una VM de Windows Azure son extremos definidos explícitamente en el archivo de Definición de servicio. Este archivo define los extremos tanto externos como internos:
• Un extremo externo puede recibir tráfico entrante del internet.
• Un rol de web no puede tener más de un extremo HTTP y un extremos HTTPS. Un rol trabajador puede tener cualquier número de extremos de HTTP, HTTPS y TCP.
• Un extremo interno está disponible sólo para otras instancias de rol en funcionamiento dentro del servicio; no está disponible para clientes por fuera del servicio.
• Un rol web puede tener un único extremo interno HTTP. Un rol de trabajador puede tener cualquier número de extremos internos de http o de TCP.
Visual Studio proporciona un recuadro sencillo para definir las reglas de firewall de la VM invitada. Windows Azure Connect permite la comunicación entre VMs que estén ejecutando roles específicos. Si se hace un ensayo de ejecutar protocoles de comunicación común y simple, tal como el ping o el uso compartido de archivos, el ensayo fracasará, sin embargo, porque la solicitud está bloqueada por el firewall de la VM. Es posible crear reglas de firewall que habiliten la comunicación sobre protocolos requeridos al usar tareas de inicio o al conectarse a la instancia a través del escritorio remoto.
- Firewall de la VM host
Como se describió anteriormente, el firewall de la VM host habilita la comunicación únicamente con direcciones legítimas de IP adentro de la fábrica, y realiza filtraje de paquetes sobre todo el tráfico.
Es posible habilitar o desactivar la conexión de roles de Windows Azure haciendo clic en “Permitir otros servicios de Windows Azure acceder al servidor” en las configuraciones de reglas de firewall.
Firewall para clientes (client firewall)
Éste es el firewall que se ejecuta en la máquina de cliente o al frente de la red corporativa. En ocasiones se debe configurar para habilitar su comunicación con artefactos de Windows Azure. Un ejemplo común es SQL Azure.
SQL Azure utiliza el protocolo TDS (i.e., puerto 1433) en la exacta misma manera en que lo hace en bases de datos locales, así que tecnologías de acceso a datos como ADO.NET y EF lo pueden usar de manera transparente. Para comunicarse con SQL Azure, el firewall local debe estar configurado para permitir conexiones TCP salientes sobre el puerto TCP/1433 y a recibir tráfico que se origine en el puerto 1433.
Otro ejemplo común es el bus del servicio de AppFabric. Los canales TCP al AppFabric retransmiten el uso bidireccional del puerto TCP 828 y del puerto TCP 808 de salida. El firewall local debe estar configurado para permitir esto.
Windows Azure Connect
Windows Azure Connect es un servicio de Windows Azure que crea una red segura para roles de Windows Azure. Windows Azure Connects proporciona una sencilla interfaz de usuario para configurar conexiones, protegidas por IPsec, entre roles funcionando en Winsows Azure y en computadores o máquinas virtuales (VMs) en la red organizacional local. Luego de configurar estas conexiones, instancias de rol en Windows Azure usan direcciones de IP (IP addressing) como las de otros recursos locales en red, en lugar de tener que usar alguna forma de dirección IP virtual.
Windows Azure Connect crea una red virtual segura al conectar directamente todos los sistemas habilitados para la conexión, sean éstos instancias de rol de Windows Azure o servidores locales. Todo el tráfico Connect está asegurado de extremo a extremo por IPsec. El agente Connect de Windows Azure implementado en cada equipo local establece una política de IPsec que exige autenticación mutua basada en certificados para todas las comunicaciones entre sistemas habilitados para Connect. El IPsec también asegura que el tráfico se firme y se cifre para propósitos de integridad y confidencialidad, y exige que únicamente los sistemas en los roles y grupos de extremo apropiados puedan comunicarse con el host. Los certificados digitales son aprovisionados por el servicio de Windows Azure Connect en sí.
La Figura 3 muestra cómo Windows Azure Connect conecta roles de Azure en servidores no-locales.
Figura 3La comunicación a través de un canal seguro se recomienda en escenarios de cliente-a-fábrica. Existen distintos canales SSL que se pueden establecer con Windows Azure:
• Clientes <-> Roles de web y trabajadores
• Clientes <-> Extremos de almacenamiento; SQL Azure; Caché de AppFabric
• Roles <-> Roles sobre extremos internos
• Roles <-> Extremos de almacenamiento; SQL Azure; Caché de AppFabric
En general, la comunicación adentro del centro de datos se considera segura, así que un cana extra de SSL para este propósito es innecesaria.
Canales SSL requiere de un certificado X.509 como su “cryptographic seed”, o criptografía base. Certificados X.509 contienen la clave pública y los metadatos utilizados para intercambiar claves criptográficas que cifran el tráfico, y para comprobar la integridad de los datos enviados a través del canal. Los certificados X.509 los puede manufacturar una autoridad de certificado (CA) de confianza, que pueden validarse a lo largo de su utilización. Esto asegura que el certificado contenga claves válidas y que en realidad pertenezca a la entidad a la cual está adscrito.
Con el uso del portal de administración, el programador puede cargar certificados X.509 a cada rol y a la suscripción general. Los certificados implementados a roles se usan para establecer canales SSL con el cliente. Los certificados implementados a la suscripción se usan para la administración API de Azure
El canal SSL que se usa para administración usa autenticación mutua. Tanto el cliente como Azure se autentican mutuamente con el uso del certificado de entidad del otro.
Autenticación mutua de SSL para tráfico de control interno
Todas las comunicaciones entre componentes internos de Windows Azure están protegidos con SSL. En la mayoría de los casos, los certificados de SSL se autofirman. Existen dos excepciones: los certificados para conexiones que se pueden acceder desde fuera de la red de Windows Azure (incluyendo el servicio de almacenamiento) y los fabric controllers (FC). Los FC tienen certificados expedidos por la Autoridad de certificados (CA) de Microsoft, que se encadena de regreso a una CA raíz de confianza. Esto permite que claves públicas de FC se puedan roll over con facilidad. Adicionalmente, las herramientas de programación de Microsoft utilizan las claves públicas FC para cifrar nuevas imágenes de aplicación suministradas por programadores para proteger todos los secretos incrustados.
Administración de certificados y de claves privadas
Para disminuir el riesgo de exponer los certificados y las claves privadas a programadores y administradores, éstas se instalan a través de un mecanismo separado del código que los utiliza. Los certificados y las claves privadas se cargan vía SMAPI o vía el Portal de Windows Azure como archivos de PKCS12(PFX) protegidos en tránsito por SSL. Estos archivos pueden estar protegidos por contraseña, pero si es el caso, la contraseña se debe incluir en el mismo mensaje. SMAPI quita la protección de contraseña si necesario y cifra el blob PKCS12 SMAPI en su totalidad usando la clave pública de SMAPI. El blob luego se almacena en el almacén secreto en el FC, con un corto nombre de certificado y la clave pública como metadatos.
Los datos de configuración asociados con cada rol especifican los certificados que deben hacerse disponibles para ese rol. Cuando se crea una instancia de rol en una VM, el FC recupera el certificado apropiado, descifra el blob PKCS12, lo re-cifra usando la llave pública de transporte del FA, y lo envía al FA en el nodo. El FA en el nodo lo envía al GA en la VM que está creando la instancia de rol, y después el GA lo descifra y lo instala en el almacén de certificado de sistema operativo con una bandera que indica que la clave privada puede ser utilizada pero no exportada. Después de la instalación, todas las copias temporales de certificados y claves se destruyen. Si se requiere la reinstalación, los certificados deben ser repackaged por el FC.
Seguridad WCF
WCF es la tecnología más común para la implementación de servicios Web utilizando el marco .NET. Es completamente compatible con Windows Azure. Los roles pueden estar expuestos a los clientes como servicios WCF y como ASP.NET aplicaciones web.
WCF cuenta con un modelo de seguridad poderoso y extensible. Puede establecer canales seguros (similares a SSL) y activar autenticación y autorización con el uso de casi cualquier tecnología relevante.
WCF también está estandarizada. Implementa los estándares de seguridad de WS-*, así que también es interoperable con las principales plataformas de servicio de web.
Windows Azure expone varios de sus artefactos, tales como AppFabric Cache y el Servicio de Control de acceso AppFabric, como servicios WCF. Cuando se utiliza el bus de servicio de AppFabric para interconectar aplicaciones o cuando se esté autenticando usuarios con AppFabric ACS, el modelo de seguridad WCF se usa para asegurar el canal.
Cuando se esté exponiendo un servicio de web WCF, usted tiene la libertad de escoger entre seguridad de mensaje WCF y seguridad de transporte WCF (es decir, SSL) para proteger su tráfico.
Conclusión
Las redes son un dominio de seguridad principal, pero es también uno de los dominios que está bajo la responsabilidad del proveedor de nube PaaS. Microsoft implementa seguridad de redes para proteger sus redes internas y para asegurar canales externos conectados a la nube. Redes seguras permiten a Microsoft logar el aislamiento entre distintos componentes de la nube y mitigar las amenazas que se originan de nodos maliciosos implementados hacia la nube Microsoft está comprometido con la protección de sus redes de ataques tanto internos como externos.
El modelo de seguridad WCF es plenamente compatible con Windows Azure y se puede usar en el esfuerzo conjunto de proteger la comunicación con su aplicación.
Aplicaciones en ejecución en la nube de Windows Azure por lo tanto gozan de la mejor protección de redes disponible en el mercado. Mover su aplicación a la nube probablemente fortalecerá su seguridad de redes a comparación con las alternativas locales comunes.
No hay comentarios.:
Publicar un comentario