WINDOWS AZURE™ INTRODUCCIÓN A LA SEGURIDAD

Información General
Windows Azure es una plataforma de informática en nube que ha sido diseñada para proporcionar un host escalable y confiable para aplicaciones de Windows en funcionamiento en la nube.

El entorno de nube por diseño proporciona escalabilidad, confiabilidad y disponibilidad –pero al mismo tiempo, también debe proporcionar garantías de que hospedar aplicaciones y guardar datos en la nube es seguro.

Dudas acerca de la seguridad, la privacidad, la confiabilidad y el control operacional encabezan la lista de barreras potenciales al uso de soluciones de informática en nube. Por consiguiente, Windows Azure usa una matriz de controles de seguridad y de directivas de privacidad para asegurar la máxima seguridad para datos y aplicaciones.

La seguridad es un sujeto multidimensional, que comprende la seguridad física, la seguridad de la red, la seguridad del host, la seguridad de las aplicaciones, y la seguridad de los datos. Para establecer una solución segura, se deben tener en cuenta todas estas dimensiones.

Así como el proveedor de nube es responsable de la máquina y del sistema operativo, también responde por la seguridad, lo cual significa que el proveedor de nube debe manejar los dominios de la seguridad física, la seguridad de la red y la seguridad del host.

Windows Azure es una plataforma PaaS, que se utiliza para el hospedaje de aplicaciones. Así, se libera al cliente de la necesidad de hacerle mantenimiento a la máquina, a la red y a l sistema operativo. El cliente es responsable únicamente de la aplicación.

Este documento describe cómo Windows Azure utiliza una amplia gama de controles de seguridad para cumplir con sus responsabilidades como un proveedor PaaS y para proporcionar tecnologías de seguridad que ayuden a sus clientes a asegurar sus aplicaciones y datos en la nube.

¿Qué es la seguridad?
La seguridad es la habilidad de proteger algo (por ejemplo, el software), de cualquier peligro o amenaza.

Es imposible lograr la seguridad total; solo se puede procurar hacer lo mejor posible para obtener una seguridad máxima. El aspecto más importante de la seguridad es que es un tema de todo o nada: si un dominio de seguridad permanence desprotegido, todos los controles de seguridad que se implementaron en otros dominios pierden valor.

En el campo del software, el problema de seguridad comúnmente se divide en los siguientes dominios:

• Seguridad física: Quién tiene acceso físico a los servidores? Quién puede implementar revisiones e instrumentos en los servidores? Si una persona no autorizada puede accede a los servidores e implementar instrumentos en él, esa persona es dueña y la seguridad ha fallado.
• Seguridad de red: Qué tan protegida está la comunicación entre el servidor y la aplicación? Si una persona no autorizada pude olfatear los datos o ejecutar un ataque de tipo “Man in the middle” o algún otro ataque de redes (como DDoS), esa persona se ha adueñado del servidor y la seguridad ha fallado.
• Seguridad de host: Qué tan protegido y actualizado está el sistema operativo? Revisiones de seguridad proporcionan una mitigación de riesgos para brechas a la seguridad descubiertas recientemente. Si el sistema operativo no es revisado con regularidad, aún es susceptible a este tipo de ataques. Qué tan aislado está el host? Un host puede tener influencia sobre otro? Si una persona no autorizada posee un host vecino y puede usarlo para ejercer influencia sobre un host, esa persona es dueña del servidor y la seguridad ha fallado. El host tiene funciones y/o instrumentos innecesarios que pueden ser utilizados por una persona no autorizada para montar un ataque? En la medida en que se instale un mayor número de funciones y herramientas en el host, asimismo se amplía la superficie expuesta a ataques.
• Seguridad de aplicaciones: Cómo maneja una aplicación los temas de Por seguridad? Sólo la aplicación conoce sus asuntos y los escenarios de uso; es por consiguiente la aplicación la que está al mando, y nadie debería tener la facultad de usar las capacidades legítimas de la aplicación para montar un ataque. Por ejemplo, si una persona no autorizada puede usar la aplicación para tener acceso a la base de datos, esa persona es dueña del servidor y la seguridad ha fallado.
• Seguridad de datos: ¿Qué tan bien protegidos están los datos de un acceso no autorizado? Los datos están cifrados? Qué tan aislada está la base de datos? Si una persona no autorizada puede tener acceso a los datos, esa persona es dueña del servidor y la seguridad ha fallado.
• Seguridad humana y organizacional: Las personas deben usar la aplicación; de lo contrario, la aplicación es inútil. Por consiguiente, por diseño, estas personas deben tener acceso a los datos y tener la posibilidad de ejecutar los escenarios de uso.
Si una persona no autorizada puede manipular a las personas para obtener acceso a los datos o para ejecutar escenarios de uso maliciosos, esa persona es dueña del servidor y la seguridad ha fallado. ISO 27002 (previamente 17799) es un ejemplo de estándar que maneja los aspectos humanos y organizacionales de seguridad de IT.

La Plataforma como un Modelo de seguridad de servicio
Las soluciones de informática en nube se pueden dividir en tres categorías principales:

Infraestructura como servicio (IaaS):
El proveedor de servicios proporciona máquinas virtuales que funcionan en un centro de datos compartido como un servicio. Los clientes instalan y ejecutan sus aplicaciones en estos equipos como si estuvieran ubicados en el centro de datos del cliente.

Plataforma como servicio (PaaS):
El proveedor de servicios proporciona un entorno en el que puede ejecutar aplicaciones.

Software como servicio (SaaS):
El proveedor de servicios proporciona una aplicación en funcionamiento en la nube que ejecuta las transacciones de negocios del cliente.

En el caso de software local tradicional, toda la responsabilidad recae sobre el dueño del software. En Infraestructura como servicio (IaaS), el proveedor es responsable por la infraestructura física, pero todo, desde el sistema operativo en adelante, está bajo la responsabilidad del dueño. En Plataforma como servicio (PaaS), el dueño es responsable únicamente de la aplicación. En Software como servicio (SaaS), el cliente únicamente usa la aplicación y no tiene ninguna responsabilidad. Ver la Figura 1.

Estas responsabilidades incluyen problemas de seguridad. En PaaS, el proveedor en nube tiene que proporcionar los controles de seguridad en todos los casos, incluyendo el dominio de las aplicaciones. La seguridad de aplicaciones representa la frontera entre la responsabilidad del cliente y la responsabilidad del proveedor.

Windows Azure es una clásica solución tipo PaaS. Este document describe cómo Microsoft cumple con sus obligaciones como proveedor PaaS.

Asegurar el Centro de datos
La seguridad física es el dominio más fundamental de la seguridad. Si el servidor en el que la aplicación se encuentra no está protegido físicamente, obviamente no está seguro.

Windows Azure se ejecuta en centros de datos distribuidos geográficamente, que comparten espacio y utilidades con otros Servicios de Microsoft en Línea. Los centros de data de Microsoft están asegurados “24/7” (veinticuatro horas al día, siete días a la semana), y emplean varias medidas para proteger las operaciones de fallas de energía, de intrusiones físicas y de interrupciones de la red. Estos centros de datos cumplen con estándares de la industria para la seguridad física y para la confiabilidad, y son manejados, supervisados y administrados por personal de operaciones de Microsoft.

Microsoft utiliza mecanismos de acceso estándares en la industria para proteger tanto la infraestructura física de Windows Azure como las instalaciones de los centros de datos. El acceso se limita a un muy reducido número de personal de operaciones y se autentica usando sistemas de acceso de última generación, con control biométrico.

La importancia del cumplimiento de los reglamentos ha aumentado dramáticamente con la proliferación de estándares globales tales como ISO 27001 y Safe Harbor, entre muchos otros. Certificaciones confiables de terceros proporciona un mecanismo bien establecido para demostrar la protección de los datos del cliente sin por ello conceder excesivo acceso a equipos de auditores independientes que podrían amenazar la integridad de la plataforma global.

Windows Azure opera en la infraestructura de Microsoft Global Foundation Services (GFS), partes de la cual están certificadas por ISO 27001. ISO 27001 es reconocido a nivel mundial como uno de los mejores estándares internacionales de manejo de seguridad de la información. Adicionalmente, Microsoft Corporation es signatario de Safe Harbor y está comprometido con cumplir con todas sus obligaciones bajo los reglamentos estipulados por el Safe Harbor Framework.

Aunque la responsabilidad del cumplimiento de las leyes, los reglamentos, y los requerimientos de la industria permanece como responsabilidad de los clientes de Windows Azure, Microsoft está comprometido a ayudar a sus clientes a lograr el cumplimiento con todos los otros estándares requeridos.

Para más información sobre la seguridad que proporciona Microsoft Global Foundation Services (GVS), por favor visite:

http://www.globalfoundationservices.com

Asegurar la red
El segundo dominio de seguridad que está bajo la responsabilidad del proveedor de nube es el de la red. Las redes de Windows Azure están diseñadas para mitigar el riesgo tanto de ataques que se originen del internet como de aquellos ataques provenientes del interior del centro de datos por nodos maliciosos implementados como roles de Azure.

Cada Rol de Azure se implementa en un equipo virtual separado (por ejemplo, un invitado VM), aislado del Internet y de otras partes de la infraestructura de Windows Azure con el uso de VLANS. Los VLANs dividen la red de tal manera que no es posible la comunicación entre VLANs sin pasar por un enrutador (router), lo cual previene que un nodo comprometido pueda falsificar tráfico por fuera de su VLAn excepto a otros nodos en su VLAN, además de que le prohíbe “escuchar” tráfico que no va desde o hacia su VLAN.

Hay tres VLANs en funcionamiento. Los Azure Role VMs se implementan al VLAN principal, mientras que los nodos de Fabric Controller (FC) responsables de implementar nuevos roles y de supervisar los nodos existentes funcionan en un VLAN separado. Un dispositivo VLAN contiene la red confiable y otros dispositivos de infraestructura. La comunicación es permitida del FC VLAN al VLAN principal, pero esta comunicación se debe iniciar desde el FC VLAN y no se podrá iniciar desde el VLAN principal. La comunicación también está bloqueada desde el VLAN al dispositivo VLAN. Esto asegura que aún si un nodo implementando código del cliente está comprometido, no podrá atacar nodos en el FC o en dispositivos VLAN.

La comunicación con el invitado VM se asegura usando tres capas o niveles de protección más: filtrado de paquetes, un firewall de IP tradicional, y comunicación segura.

Filtrado de paquetes
El hipervisor funciona directamente sobre el hardware y divide un nodo en un número variable de VMs. Cada nodo también tiene una máquina “raíz” virtual, que implementa el sistema operativo del host sobre sistemas controlados por hipervisores.

El hipervisor y la raíz del sistema operativo proporcionan filtros de paquetes para la red, que aseguran que invitados VMs no confiables no puedan generar tráfico de identidad suplantada, recibir tráfico no dirigido a ellos, dirigir tráfico hacia extremos de infraestructura protegidos, ni enviar o recibir tráfico de difusión inapropiado.

Firewalls de IP
En la definición de servicio es posible definir extremos para que Azure Roles los exponga. La definición del extremo contiene el protocolo y el puerto a ser utilizando, y así actúa como unas reglas de firewall simple para el invitado VM. Los extremos se pueden definir para aceptar conexiones del internet o de roles que pertenezcan a la misma aplicación. Conexiones entre instancias de Roles de diferentes aplicaciones se consideran conexiones de internet. El FC aprovisiona los VMs que estén implementando roles de Azure, y por consiguiente sabe cuáles direcciones de IP pertenecen a cuáles roles.

Para hacer respetar la política de firewall que permita la comunicación interna, sólo el FC puede configurar el Fabric Agent (FC) con la lista de las direcciones IP de los roles a ser usados por los filtros de paquete, lo cual solo permite la comunicación al interior de la aplicación para legitimar direcciones legítimas de IP.

Azure Connect permite emular un VLAN que contenga roles de Azure en servidores locales. Un escenario común es la creación de un recurso compartido de archivos en un rol de Azure o el uso de Escritorio remoto para supervisar el estado de un rol específico. Profesionales de IT pueden supervisar roles específicos al utilizar Escritorio remoto de la misma manera en que pueden manejar servidores locales. Instalar herramientas en el VM remoto también es un requerimiento común de IT, que se logra usando un recurso compartido de archivos y el VM del rol.

De manera predeterminada, todos estos protocolos están bloqueados por el firewall VM de invitado. Clientes deben fijar las reglas de firewall de manera explícita para permitir tal comunicación adentro del VM.
Comunicación segura
Existen distintos tipos de canales con los cuales los roles de Windows Azure se pueden proteger:

• De cliente a Rol: Los roles apoyan el enlace de SSL con el uso de un certificado, generado por el cliente, que se carga a la configuración en el portal.
• SMAPI: Service Management API (Administración de Servicios API) funciona sobre REST y se debe proteger con autenticación mutua SSL con el uso de un certificado autofirmado que se carga a la configuración de suscripción en el portal.
• Interna: Toda la comunicación entre componentes internos de Windows Azure está protegida con SSL. En la mayoría de casos, los certificados de SSL son autofirmados. Las excepciones son certificados para los controladores de fábrica y certificados para conexiones que se pueden acceder de fuera de la red de Windows Azure (tales como el Servicio de almacenamiento).
• Del rol a SQL Azure. El SQL Azure puede forzar el cifrado SSL con todas las conexiones del cliente, lo cual asegura los datos sobre de la transferencia.
• Cuando se define la conexión de cadena a SQL Azure, los programadores deben usar los parámetros de Encrypt=True y de TrustServerCertificate.

Asegurar el host
El tercer dominio de seguridad que está bajo la responsabilidad del proveedor de la nube es el de Host y el Sistema Operativo (OS).

La virtualización es una de las tecnologías impulsoras detrás de la habilidad de servicios de nube de rápidamente escalar o desescalar (scale up or down), según la necesidad. Sin embargo, sí requiere de una administración seria y reflexiva, ya que las barreras previamente “duras” entre sistemas se virtualizan y posiblemente se pueden exponer a nuevos ataques vectores.

En Windows Azure cada Rol se ejecuta dentro de su propia virtual machine (VM) o máquina virtual. Cada máquina virtual tiene 1, 2, 4 u 8 CPUs virtuales y se le asignan hasta 14 GM de memoria. Las VMs ejecutan una versión especial de Windows Server 2008 o de Windows Server 2008 R2 al que se le instala un servidor específico de OS software (IIS, .NET, framework, etc.), dependiendo del Rol. A la VM además se le da un número muy limitado de controladores de dispositivo.

No hay almacenamiento de larga duración en nodos individuales de programación. No se garantiza que datos escritos en los discos locales persistan a través de la instalación y desinstalación de las máquinas virtuales. Cualquier dato que requiera durabilidad debe almacenarse en los servicios de almacenamiento de Azure Storage.

Windows Azure utiliza su propio hipervisor, una capa o nivel de virtualización desarrollada por Microsoft y que se construye tomando en cuenta las lecciones aprendidas porHyper-V. Funciona directamente sobre el hardware y divide el nodo en un número variable de máquinas virtuales (VMs). Cada nodo también tiene una máquina virtual de “raíz”, que ejecuta el sistema operativo del host en sistemas controlados por hipervisor. Azure usa una versión desmontada o simple de Windows Server que incluye sólo aquellos componentes que son necesarias para hospedar VMs , como el agente Fabric Controller. Esto se hace tanto para mejorar rendimiento como para reducir la superficie expuesta a ataques.

Una barrera crítica es el aislamiento de la VM raíz de las VMs invitadas y las VMs invitadas una de otra. Esta barrera la maneja el hipervisor y el OS raíz. La pareja del hipervisor y el OS raíz pondera décadas de experiencia de Microsoft en temas de seguridad de sistema operativo, así como aprendizaje más reciente del Hyper-V de Microsoft, para proporcionar un fuerte aislamiento de VMs invitadas.

Windows Azure revisa el Hard Drive Virtual (VHD) que regularmente contiene el sistema operativo. El cliente puede sin embargo pedir usar una versión específica del sistema operativo si una o varias revisiones interfiere con la aplicación del cliente.

Los clientes esperan que sus aplicaciones estén protegidas de cambios no autorizados. El mecanismo principal de protección de la integridad para datos de clientes recae sobre el diseño de la VM en sí. Cada VM está conectada con tres VHDs locales:
• El D: la unidad de disco D contiene una de varias versiones del sistema operativo del invitado, seleccionable por parte del cliente, todas de las cuales se mantienen actualizadas con las revisiones respectivas.
• El E: la unidad de disco E contiene una imagen que construye el FC basado en el paquete que el cliente proporciona.
• El C: la unidad de disco C contiene información de configuración, archivos de paginación y otros tipos de almacenamiento.

Este diseño preserva estrictamente la integridad del sistema operativo subyacente y las aplicaciones del cliente.

Seguridad de Aplicaciones
La Seguridad de Aplicaciones representa la barrera entre las responsabilidades de seguridad del proveedor de nube PaaS y aquellas del cliente.

Las aplicaciones que se hospedan en entornos de nube se consideran aplicaciones web y por consiguiente deben cumplir con los reglamentos de mejores prácticas de seguridad de aplicaciones web.

El diseño y la implementación de aplicaciones web debe tomar en cuenta los siguientes temas.
• Validación de entrada: se deben validar todas las entradas que transgredan las barreras de la confianza.
Una buena validación puede mitigar un alto porcentaje de ataques presentes y futuros. Esta validación generalmente es simple y barata pero muy efectiva.
Existen dos estrategias principales que se usan para ejecutar la validación: la “Lista blanca” y la “Lista negra”. La validación de lista blanca define un patrón de entradas válidas; todas las entradas que siguen el patrón se permiten, mientras que otras entradas se rechazan. Cuando tales patrones no se pueden definir, en su lugar se puede crear una lista negra de entradas defectuosas. Si se detectan entradas defectuosas, éstas se rechazan.
• Autenticación: identifique el usuario. Casi todas las aplicaciones web necesitan saber quién origino la solicitud.
• Autorización: verifique los permisos concedidos al usuario y verifique que sólo las puedan ejecutar aquellas personas con los permisos relevantes. Si se solicita una operación y el usuario no tiene los permisos requeridos, se debe negar la solicitud.
• Administración de configuración: Proteja información confidencial que pueda aparecer en la configuración de la aplicación, tal como las cadenas de conexión o las reglas de negocio. La administración de cambios de aplicación (i.e., nuevas versiones) es un proceso de alto riesgo que se debe manejar con sumo cuidado.
• Información confidencial: identifique y asigne información confidencial a políticas de seguridad.
• Administración de sesiones: Proteja el estado (i.e., información almacenada a través de una sesión de una ejecución de proceso de negocio).
• Criptografía: Utilice algoritmos criptográficos confiables. Controle claves de cifrado.
• Manipulación de parámetros: proteja intercambio de parámetros entre distintos módulos de la aplicación (ej., parámetros de http intercambiados entre páginas web).
• Administración de excepciones: corrija y registre todas las excepciones. Las excepciones contienen información confidencial sobre la aplicación. Dicha información es crítica para cualquier persona que esté intentando montar un ataque, mientras que el usuario final generalmente no necesita esa información o no necesita ser expuesto a tal información.
• Auditoria y registro: identifique situaciones anormales comparándolas a estados normales de aplicación.
Si un problema surge, es importante rastrearlo, y sin auditoría y registro esto es imposible. Los administradores deben saber tan pronto como posible si algo anda mal y si la aplicación puede estar expuesta a algún tipo de ataque. Para que esto ocurra, las situaciones anormales deben ser identificables inmediatamente. La auditoría y el registro proporcionan la información de base para la evaluación del estado de la aplicación.

Más información sobre seguridad de aplicaciones web se puede encontrar en el Security Guide, en MSDN, el White Paper en Security Best Practices For Developing Windows Azure Applications, y en the Open Web Application Security Project.

Confianza parcial
Uno de los principios más básicos para escribir código seguro es “run with least privilege” (ejecutar con el privilegio mínimo). Hablando en términos prácticos, esto quiere decir que el código de la aplicación nunca debe tener más permisos de los que realmente necesita. Windows Azure por consiguiente proporciona dos niveles de directiva de seguridad de acceso al código (CAS) bajo los cuales los roles se pueden ejecutar: plena confianza y confianza parcial.

Bajo confianza parcial, las siguientes restricciones aplican:
• No se permiten llamadas a código nativo.
• No se permite acceso a bibliotecas y recursos nativos.
• No se permite acceso a Diagnósticos de Windows Azure via la Librería administrada por Windows Azure.
• El acceso a lectura de sistema de archivo se otorga para el directorio de aplicación y para almacenes locales nombrados. El Acceso de Escritura y el acceso Append sólo se otorga a almacenes locales nombrados.
• No se otorga permiso de acceso al registro.
• Acceso solamente a las variables de entorno TEMP y TMP.
• No se otorga permiso de acceso al Registro de eventos.

Confianza plena se requiere en los siguientes escenarios:

• Uso de FastCGI o de PHP
• Migración de servicios tradicionales web a la nube
• Invocación de roles y generación de subprocesos (nativos o administrados)
• Llamadas a bibliotecas nativas vía P/Invoke

Si no se requiere ninguno de los anteriores, es recomendable utilizar el nivel de confianza parcial de Windows Azure. Esta opción minimiza la superficie de ataque del rol en cuestión.

Security Development Lifecycle (Ciclo de vida del desarrollo de Seguridad)
El desarrollo seguro debe comenzar tan temprano como posible y debe continuar a través del ciclo de vida del software.

Los grupos de desarrollo internos de Microsoft usan el Security Development Lifecycle (SDL), que traduce “Ciclo de vida del desarrollo de seguridad”, para lograr la seguridad máxima para todos sus productos. El SDL se usa para lidiar sistemáticamente con las amenazas de seguridad que pueden estar inherentes en el producto de software. El SDL es un grupo de procesos y herramientas diseñado para minimizar el número y la severidad de las vulnerabilidades en productos de software. El SDL abarca educación de personal de desarrollo, procesos seguros de desarrollo, y la responsabilidad de individuos y de equipos de producto, todas las anteriores para la construcción constante de software más seguro cada vez.

El SDL trata amenazas de seguridad en todo el proceso de desarrollo por medios que incluyen la modelización de amenazas durante el proceso de diseño; la adhesión a las mejores prácticas de desarrollo y a los estándares de seguridad de código durante la codificación; y el requerimiento de varias herramientas para la evaluación y la comprobación antes de la implementación. Estos chequeos proactivos durante el desarrollo hacen que el software sea menos vulnerable a posibles amenazas después de su implementación, y el SDL proporciona una metodología estructurada y coherente para su aplicación. Estas metodologías, que reciben el apoyo de un comité ejecutivo de seguridad, han ayudado a Microsoft a desarrollar software más seguro.

Windows Azure en sí no es ninguna excepción, pues el programa integra en su totalidad los parámetros de SDL. Microsoft requiere que el SDL se cumpla para cualquier software desarrollado por Microsoft implementado en Windows Azure. Microsoft recomienda que las aplicaciones del cliente que se implementen en Windows Azure también se desarrollen de acuerdo al SDL.

Identidad
Tal como se describió anteriormente, la autenticación y la autorización son desafíos básicos que cualquier aplicación segura debe tratar. Ambos temas requieren que las aplicaciones procesen la identidad. Existen dos tipos básicos de administración de identidad: basada en roles y basada en notificaciones.

En la administración de identidad basada en roles, la aplicación está encargada. El usuario suministra sus credenciales, que la aplicación utiliza para a ejecutar la autenticación. La identidad del usuario luego se mapea a los grupos, y los permisos se otorgan de acuerdo a la membrecía de grupo. La autorización basada en roles es popular, y la mayoría de aplicaciones tradicionales la usan para manejar identidades. Típicas tecnologías de autorización basada en roles son Windows Identity (e.g., Domain Join; Kerberos), ASP.NET, proveedores de suscripciones, y SQL.

En la administración de identidad basada en notificaciones, en cambio, la autenticación se ejecuta por fuera de los límites de la aplicación. Las aplicaciones establecen relaciones de confianza con Security Token Services (STSs). Los usuarios se autentican usando un STS y reciben un token que contiene una recopilación de claims, o notificaciones (i.e., piezas de información sobre el usuario). El token se firma y opcionalmente se cifra usando la clave pública de la aplicación.

Cuando una aplicación recibe un token, el usuario ya ha sido autenticado; lo único que tiene que hacer es abrir el token y procesar la información contenida de acuerdo a sus necesidades. La identidad basada en notificaciones permite una federación sofisticada y escenarios de delegación. La confianza se puede establecer entre diferentes STSs: un cliente puede autenticar comprobando la identidad contra su STS local y enviar el token que recibe al STS de confianza de la aplicación. Este STS hará un mapeo de las notificaciones en el token recibido y las usará para crear un nuevo token, que se le proporcionará a la aplicación.

Típicas tecnologías de autorización basadas en notificaciones son ADFS 2.0, WIF y Azure AppFabric Access Control Service (ACS).

Windows Azure tiene compatibilidad tanto con autorización basada en roles como con la autorización basada en notificaciones.
La autorización basada en roles típicamente se usa en los siguientes escenarios:
• Migración a la nube de una aplicación existente que use autorización basada en roles.
• Escenarios simples en los que no se requieran ni federación y delegación
• Administración de identidad sencilla que pueda ser manejada por la aplicación.

La identidad basada en notificaciones es más sencilla y más ágil. Factoring authentication out of your applications presenta muchos beneficios para programadores, profesionales de IT y usuarios. Dicho de manera sencilla hay menos cuentas para que todos manejen, y la centralización de autenticación que resulta hace que sea más fácil hacer un upgrade a métodos más fuertes de autenticación a medida que estos aparecen, e incluso a federar la identidad con otras plataformas y organizaciones.

Construir un STS no es una tarea sencilla, pero afortunadamente Azure AppFabric (parte de la plataforma de Windows Azure) introduce un STS escalable, confiable y sencillo, que puede usarse tanto en la nube como en aplicaciones locales.

Seguridad de datos
Windows Azure proporciona una infraestructura de almacenamiento de manera paralela a sus servicios de hosting que ejecutan código. Tres principales infraestructuras de datos se suministran en la plataforma de Windows Azure: Windows Azure Storage, SQL Azure, y el caché de Azure AppFabric.

Los clientes únicamente estarán dispuestos a almacenar datos en la nube si están confiados de que la nube es segura y privada. Por eso no es sorprendente que todas las tecnologías de almacenamiento contienen una amplia gama de controles para la implementación de control de acceso a datos ni que dichas tecnologías cumplen con las políticas de GFS para la conservación de políticas de privacidad.

Control de acceso
Windows Azure Storage tiene un modelo simple de control de acceso. Cada suscripción a Windows Azure puede crear una o más Storage Accounts (Cuentas de almacenamiento). Cada Cuenta de almacenamiento tiene una única clave secreta que se usa para controlar el acceso a todos sus datos. La información almacenada en tablas y colas de Windows Azure es accesible únicamente por medio de la autenticación de Azure Storage con la presentación de la clave secreta.

En contraste, los Blobs tienen una política más sofisticada de acceso a datos. La información almacenada en blobs puede que deba ser accesible al público en general. Ejemplos comunes son archivos de medios, tales como imágenes y películas que deben ser directamente accesibles desde un explorador. Los contenedores o envases de blob por lo tanto pueden marcarse como “públicos”, lo cual permite acceso a todos sus blobs sin la necesidad de presentar una llave.

En un escenario más restringido, los blobs se pueden hacer accesibles por un período limitado de tiempo y con un grupo específico de permisos de accesos, sin la necesidad de una clave. En estos casos es posible crear una Shared Access Signature (SAS), o Firma de acceso compartido. Las SAS son direcciones URL de blob especiales que contienen información de acceso de datos tal como duración y permisos concedidos. Los URLs se firman con la clave de la cuenta de almacenamiento. Estos URLs se supone deben ser distribuidos únicamente a los usuarios que deben tener acceso. Solicitudes de blob utilizando el URL normal serán negadas, pero usando una SAS es posible acceder al blob durante un período predeterminado de tiempo.

Es posible restringir el escenario un poco más mediante la creación de una referencia de una SAS a una Container-Level Access Policy (Directiva de acceso de nivel de contenedor). Una directiva de acceso de nivel de contenedor se puede modificar o revocar en cualquier momento, lo cual proporciona mayor flexibilidad y control sobre los permisos otorgados.

Integridad, disponibilidad y confiabilidad de datos
La disponibilidad y la confiabilidad de los datos son preocupaciones principales de clientes con respecto al almacenamiento de datos en su nube. Los clientes deben estar seguros de que sus datos siempre estarán inmediatamente disponibles y que fallas de hardware nunca causaran una pérdida de sus datos.

Datos almacenados en todos los Servicios de almacenamiento de Windows Azure se replican en tres nodos físicamente separados en la misma región geográfica para facilitar alta disponibilidad y para minimizar el impacto de fallas de hardware.

Todas las operaciones de almacenamiento, incluyendo delete (eliminación), están diseñados para ser coherentes al instante. La ejecución exitosa de una operación de delete remueve todas las referencias al ítem de datos asociado, y no se puede volver a acceder vía las APIs de almacenamiento. Todas las copias del ítem de datos eliminado después se recopilan en la basura. Todos los bits físicos serán sobrescritos cuando el bloqueo de almacenamiento asociado sea reutilizado para almacenar otros datos

Windows Azure se ejecuta bajo las mismas políticas y principios de seguridad que gobiernan todos los centros de datos de Microsoft. Global Foundation Services (GFS) proporciona la infraestructura de la nube para estos servicios enfocándose en la adherencia a varios estándares regulatorios, estatutarios, y de industria. La política de eliminación es sólo un ejemplo de varias políticas de integridad y de privacidad con las cuales cumple la infraestructura de Azure.
Criptografía

El cifrado de datos en almacenamiento y en tránsito puede ser útil para clientes de Windows Azure para que se ajusten a las mejores prácticas para asegurar la confidencialidad y la integridad de los datos.

Actualmente no existe compatibilidad para cifrado nativo ni en Windows Azure Storage ni en SQL Azure. Datos en Windows Azure Storage se almacenan como texto no cifrado, y no existe una opción para cifrar los datos de otro modo que a través del desarrollo de un código propio de cifrado. El framework o marco de .Net proporciona la totalidad de API necesario para crear código para cifrar los datos del cliente. SQL Azure actualmente no tiene compatibilidad con la característica de Transparent Data Encryption disponible en el Servidor Microsoft SQL.

Para datos que se acceden solo por servicios hospedados por Windows Azure, ésta no es una preocupación principal. El cifrado de datos en un servicio hospedado requiere que todas las instancias del servicio tengan acceso a las claves de cifrado, y si un servicio escoge cifrar datos éstas llaves deben almacenarse en certificados mantenidos en el almacén de certificados de Windows Azure. Sin embargo, las políticas de seguridad que han implementado los centros de datos de Microsoft ayudan a asegurar que los atacantes no puedan obtener acceso físico a los equipos que estén implementando servicios de Azure o a los discos que implementan almacenamiento de Azure. En consecuencia, las políticas de destrucción de datos eliminan la posibilidad de que los datos se tornen accesibles de manera inadvertida, a otros suscriptores de Azure.

Por lo tanto, en la medida en que un servicio implemente un nivel apropiado de seguridad de transporte (es decir, SSL), la única manera viable en que un atacante podría obtener acceso a los datos sería si obtuviese o robase los detalles de Windows Live ID utilizados por la suscripción de Azure o el Certificado de Administración utilizado para administrar los servicios hospedados. Un atacante tal tendría en todo acceso al almacén de certificado y por consiguiente los medios de descifrar los datos, de tal manera que el cifrado en este escenario sería poco provechoso.

El cifrado es valioso si usted está accediendo a datos localizados en almacenamiento de Azure desde aplicaciones ejecutadas en computadores por fuera del entorno Azure, en lugar de ser ejecutadas desde servicios hospedados en Azure. En este escenario, usuarios diferentes que implementen estas aplicaciones pueden tener que mantener confidencialidad unos de otros. Usted puede cifrar datos al interior de una aplicación del cliente, por ejemplo, usando una clave privada de AES, conocida sólo por el usuario, que se genera en un equipo del cliente o en otro lugar dentro de la empresa. La carga cifrada luego se carga al almacenamiento de Azure. Los datos los puede descifrar únicamente el usuario proporcionando esta clave (que se puede almacenar en el perfil del usuario usando DPAPI). Otros usuarios pueden generar sus propias claves privadas, y estas claves no se deben revelar. Una aplicación del cliente, tal como un explorador web, que trate de leer los datos cifrados directamente de almacenamiento Azure sin proporcionar la clave apropiada no podrá descifrar los datos.

Conclusión
La seguridad es una de las principales preocupaciones de los clientes cuando están considerando hospedar aplicaciones en la nube.

Windows Azure es una clásica solución PaaS, y como tal se encarga de todos los dominios de seguridad bajo la responsabilidad del proveedor de nube. PaaS se usa para hospedar y ejecutar aplicaciones del cliente, y como tal no puede ser responsable por el código del cliente. Los clientes deben implementar las mejores prácticas de seguridad en sus propias aplicaciones. En conjunción con los atributos de seguridad que la infraestructura provee, es posible crear una ejecución de aplicaciones segura en la nube.

Algunos aspectos de soluciones de seguridad que el proveedor de nube provee son de hecho mejores que aquellos obtenibles en un entorno local. Por ejemplo, la seguridad física de los centros de datos de Windows Azure es probablemente mayor que la suya propia. La protección de red de Windows Azure, el Host Isolation (Aislamiento de host) y el endurecimiento del sistema operativo son todos más seguros que aquellos que se encuentran en el hospedaje tradicional. Por consiguiente, hospedar su aplicación en la nube probablemente mejora su seguridad.


Hasta la próxima

Fuente: Material de Microsoft para el MVA