Punto NET Soluciones SRL

Punto NET Soluciones SRL
Servicios Corporativos de Ciberseguridad - IT - DBA

lunes, 26 de septiembre de 2011

Si no ajustas las contraseñas, estas "Morto"- Gusano Morto

Introducción
Hace unos días que estamos haciendo seguimiento al comportamiento de algunas alertas de los IPS (Intrusion Prevention Service) que poseen algunas compañías, que por cuestiones de negocio, han publicado los servicios de RDP (Remote Desktop Protocol) ha Internet.
Los IPS han evidenciado intentos de conexión masiva de direcciones IP (Internet Protocol) de diferentes lugares siendo muy masivos los intentos de conexión.
Analizando,los intentos de conexión, se corresponde al comportamiento de un nuevo gusano llamado Morto que ha comenzado a circular en Internet en los último días, que intenta infectar máquinas a través de RDP. El comportamiento del gusano se evidencia por que el mismo genera una gran cantidad de tráfico RDP de salida en redes que tienen las máquinas infectadas, y Morto es capaz de poner en peligro tanto a los servidores y estaciones de trabajo Windows que poseen este protocolo habilitado.

Escenarios WAN
Si el escenario es por la publicación a Internet del RDP, vamos a ver en los IPS una cantidad importante de intentos de conexión con direcciones de IP falsificadas (Spoofing). Una manera de mitigar este tipo de intentos de conexión es cambiando la configuración del escenario WAN:

1) No publicar el servicio de RDP, permitiendo el acceso al mismo mediante conexiones de VPN (IPSec, SSL o PPTP).
2) Ajustar y mantener actualizado su plataforma de IPS, con generación de alertas al referente de seguridad de la compañía.
3) Definir de donde pueden acceder al RDP.
4) Administrar usuarios con contraseñas complejas, definiendo horarios de acceso por parte del usuario.

Escenario LAN
Normalmente este tipo de protocolo, en la red LAN está diposnible tanto para acceder a un servidor como para tomar control remoto de una PC o Desktop. La manera de evitar un problema en la red es:

1) Ajustar muy bien los antimalware para que detecten y denieguen este tipo de conexiones masivas. Es importante que el software detecte el gusano en el desktop.
2) Configurar los firewall de los servidores, permitiendo que solo los equipos autorizados utilicen el puerto RDP, siempre que sea necesario por el desktop cliente. Esto significa, no permitir conexiones masivas de todas las PC de la red, es más bien, definir quienes deben acceder a este protocolo y permitir el acceso.
3) Utilizar una solución de NAC que permita mandar a cuarentena un equipo con comportamiento anómalo.
4) Utilizar contraseñas complejas en los usuarios que necesitan acceder a un servicio de Terminal Server.

Estadísticas y Comportamiento
Según el MMPC (Microsoft Malware Protection Center), el gusano ya está en mas de 87 paises y el sistema operativo más afectado es XP.También hemos descubierto que Morto intenta vulnerar la cuenta administrador mediante la fuerza bruta a conexiones RDP con su ataque de diccionario simple.
Inicialmente las pruebas de conectividad de la máquina afectada Internet, tratando de conectarse a una dirección IP 74.125.71.104. Si este intento no tiene éxito, entonces los reintentos a través de direcciones IP en la subred del ordenador afectado, y tratando de conectarse a las máquinas que se hayan empleado los siguientes nombres de usuario:

1
actuser
adm
admin
admin2
administrator
aspnet
backup
computer
console
david
guest
john
owner
root
server
sql
support
support_388945a0
sys
test2
test3
user
user1
user5

Es importante recordar que este malware no se aprovecha de una vulnerabilidad en Remote Desktop Protocol, sino que se basa en contraseñas débiles (se puede ver las contraseñas utilizadas por Morto en la enciclopedia de Microsoft). Si no lo ha hecho, verificar si estos nombres de usuario se están utilizando en su entorno y cambiar las contraseñas asociadas a las que son fuertes (y definitivamente no en la lista de contraseñas). Incluso los ordenadores que han sido limpiados de esta amenaza puede ser afectados si las contraseñas no se cambian y el equipo sigue sin protección.

Cuando el gusano detecta una clave (protocolo RDP permite el acceso), se conecta al sistema remoto y empieza el proceso de intento de reproducirse. El malware se compone de un instalador y una biblioteca de enlace dinámico (DLL). El archivo DLL tiene el mismo nombre que uno utilizado por el Regedit y contiene información de configuración cifrada para descargar y ejecutar al menos tres componentes adicionales.

Moraleja
El secreto es cumplir con las buenas prácticas. En este caso, la utilización de una buena contraseña (definimos buena contraseña cuando cumple con los niveles de fortaleza recomendados) fortalezerá el sistema.
Si tiene dudas si la contraseña que Usted utiliza es compleja o cumple con dicha característica, puede visitar este sitio y al transcribir la contraseña, le indicará el nivel de fortaleza.
Si no ajustas las contraseñas, estas "Morto".

Resumiendo
Este gusano lo que intenta es robar la contraseña de usuarios, utilizando el viejo y conocido sistema de Fuerza Bruta. No es una vulnerabilidad del protocolo RDP, es más bien, un mal seteo de las contraseñas de usuarios de la red. Ovbiamente, si Usted publica su RDP a Internet, los ajustes deben ser inmediatos, ya que allí un desconocido puede lograr el acceso a su red.

Hasta la próxima.
Fuente: Microsoft

domingo, 18 de septiembre de 2011

Actualizaciones plataforma Microsoft - SEPTIEMBRE 2011

Este mes contamos con los siguientes boletines:

1) MS11-070: Una vulnerabilidad en WINS podría permitir la elevación de privilegios (2571621)
Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en Servicio de nombres Internet de Windows (WINS). La vulnerabilidad podría permitir la elevación de privilegios si un usuario recibe un paquete de réplica de WINS especialmente diseñado en un sistema afectado que ejecuta el servicio WINS. Para aprovechar esta vulnerabilidad, un atacante debe de tener unas credenciales de inicio de sesión válidas y ser capaz de iniciar una sesión local.

2) MS11-071: Una vulnerabilidad en los componentes de Windows podría permitir la ejecución remota de código (2570947)
Esta actualización de seguridad resuelve una vulnerabilidad que se ha divulgado públicamente en Microsoft Windows. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo de formato de texto enriquecido (.rtf), un archivo de texto (.txt) o un documento de Word (.doc) legítimo que se encuentre en el mismo directorio de red que un archivo de biblioteca de vínculos dinámicos (DLL) especialmente diseñado. Un intruso que aprovechara esta vulnerabilidad podría conseguir el mismo nivel de derechos de usuario que el usuario local. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

3) MS11-072: Vulnerabilidades en Microsoft Excel podrían permitir la ejecución remota de código (2587505)
Esta actualización de seguridad resuelve cinco vulnerabilidades de las que se ha informado de forma privada en Microsoft Office. Las vulnerabilidades podrían permitir la ejecución remota de código si un usuario abre un archivo de Excel especialmente diseñado. Un intruso que aprovechara cualquiera de estas vulnerabilidades podría conseguir el mismo nivel de derechos de usuario que el usuario que ha iniciado sesión. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos. La instalación y configuración de Validación de documento de Office (OFV) para prevenir la apertura de archivos sospechosos bloquea las vías de ataque para aprovechar las vulnerabilidades descritas en CVE-2011-1986 y CVE-2011-1987.

4) MS11-073: Vulnerabilidades en Microsoft Office podrían permitir la ejecución remota de código (2587634)
Esta actualización de seguridad resuelve dos vulnerabilidades de las que se ha informado de forma privada en Microsoft Office Visio. Las vulnerabilidades podrían permitir la ejecución remota de código si un usuario abre un archivo de Office especialmente diseñado o si un usuario abre un archivo de Office legítimo que se encuentre en el mismo directorio de red que un archivo de biblioteca especialmente diseñado. Un intruso que aprovechara cualquiera de las vulnerabilidades podría conseguir el mismo nivel de derechos de usuario que el usuario que ha iniciado sesión. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

5) MS11-074: Vulnerabilidades en Microsoft SharePoint podrían permitir la elevación de privilegios (2451858)
Esta actualización de seguridad resuelve cinco vulnerabilidades de las que se ha informado de forma privada y una vulnerabilidad de la que se ha informado de forma pública en Microsoft SharePoint y Windows SharePoint Services. Las vulnerabilidades más graves podrían permitir la elevación de privilegios si un usuario hace clic en una dirección URL especialmente diseñada o visita un sitio web especialmente diseñado. En las vulnerabilidades más graves, los usuarios de Internet Explorer 8 e Internet Explorer 9 que exploren un sitio de SharePoint en la zona Internet están menos expuestos porque, de forma predeterminada, el filtro XSS en Internet Explorer 8 e Internet Explorer 9 contribuye a bloquear los ataques en la zona Internet. No obstante, el filtro XSS en Internet Explorer 8 e Internet Explorer 9 no está habilitado de forma predeterminada en la zona Intranet.

Hasta la próxima.
Fuente: Microsoft

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

Información General de Windows Azure Security

Les adjunto el presente artículo, cuya autoría es de David Tesar y es propiedad de Microsoft y sirve como contenido para cursar la carreras del MVA (Microsoft Virtual Academy).

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 1

Aislamiento 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 3
SSL
La 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.

A continuación ponemos un video explicativo sobre Seguridad General de Window Azure.



Hasta la próxima.
Fuente: Microsoft.

IDENTIDAD EN LA NUBE

Información general
La identidad es uno de los desafíos centrales que la mayoría de aplicaciones de nube deben enfrentar. Las aplicaciones de nube están distribuidas por diseño, pero todos los nodos deben ser compatibles con el mismo reconocimiento de identidad. Quién es el usuario? Qué permisos se deben otorgar?
Las preocupaciones de clientes sobre seguridad, privacidad y control operacional encabezan la lista de los límites potenciales al uso de soluciones de nube. Clientes que estén considerando cargar sus aplicaciones a la nube deben tener garantías de que el modelo de identidad que se implementa en la nube es coherente con sus requisitos y necesidades.
Hay distintas maneras de construir compatibilidad con identidad in una aplicación. El entorno de nube permite el uso de escenarios sofisticados tales como la colaboración, la mediación y el inicio de sesión único o “single sign-on” (SSO). En tales escenarios, la compatibilidad con identidad tradicional puede ser difícil de implementar.

Este artículo describe la infraestructura que la plataforma de Windows Azure proporciona y que ofrece Windows Azure Appfabric para permitir implementación de seguridad sencilla pero segura en estos escenarios.

Qué es identidad?
Antes de describer las tecnologías y la arquitectura de identidad es importante definer la identidad.

La definición de “identidad” del diccionario es:

Todo aquello que hace que una entidad sea definible y reconocible, en términos de posesión una serie de cualidades o características que la distingan de otras entidades.

Para los propósitos de aplicaciones software, esta definición se traduce en “la colección de información que describe una entidad para distinguirla de otras”.

La identidad es, entonces, una colección de información. Esa información puede tener un nombre, una fecha de nacimiento, una dirección, una identificación de empleo, un número de seguridad social (Social Security Number), etc. Es importante notar que las entidades (es decir, las personas), pueden usar información de identidad distinta en contextos distintos. Por ejemplo, la información de identidad personal de una persona (como se escribiría en Facebook), puede ser muy diferente de la información de identidad profesional (como se escribiría en Active Directory en la oficina).

Existen tres escenarios de uso principales que tienen que ver con la identidad:
Autenticación: El proceso de probar una identidad. Una entidad (usuario) usa credenciales (piezas relevantes de información) para comprobar su identidad ante la aplicación.
Autorización: El proceso de conceder permisos a una identidad y de implementar políticas que permitan a las entidades ejecutar tareas únicamente si han obtenido los permisos relevantes.
Consulta de identidad: El proceso de consultar o buscar información de identidad para el uso general de la aplicación.

Tecnologías de identidad
Existen muchas tecnologías diferentes para construir compatibilidad con identidad en las aplicaciones. Como se describirá a continuación, algunas tecnologías utilizan administración basada en roles, mientras que otras se basan en un enfoque basado en notificaciones.

Las tecnologías de identidad se pueden dividir en tres categorías principales:

Almacenes de identidad (Proveedores):
Estas tecnologías son responsables de almacenar un diccionario de información de identidades. Los almacenes de identidad manejan toda la información que describe a las entidades y sus relaciones con otras entidades en el dominio. El resultado es una serie complicada de información que debería en todo caso ser fácil de consultar con el uso de los interfaces del almacén de identidad. Ejemplos: Active Directory, ADFS, SQL.

Selectores de identidad:
Estas tecnologías son las responsables de seleccionar un almacén de identidad y un método de autenticación. Los usuarios se pueden registrar en uno o varios almacenes de identidad (ej., Windows Live ID, Facebook, etc.) Los protocolos de autenticación utilizan selectores de identidad para permitirles a los usuarios escoger el almacén de identidad ante el cual quieren recibir autenticación. Ejemplo: Cardspace 2.0

Marcos de autenticación y de autorización:
Estas tecnologías son las responsables de autenticar las solicitudes y de hacer respetar (enforce) las políticas de acceso. Esto incluye el proceso de comprobar credenciales cotejando la información de los almacenes de identidad, creando tokens de seguridad válidos que contengan la información requerida por la aplicación para identificar a la identidad y sus permisos , y de establecer “porteros” (gatekeepers) que otorguen permisos a solicitudes válidas y nieguen el acceso a solicitudes no autorizadas
Ejemplos: ASP.NET Forms authentication, Kerberos, WIF, OpenID
Windows Azure es compatible con estos tres tipos de tecnologías de identidad, lo que le permite a los clientes fácilmente migrar aplicaciones a la nube. Por ejemplo, es posible unirse al dominio de aplicaciones de la nube y usar Windows Identity basado en roles, o bien, también es posible usar ADFS 2.0 con ACS y autenticar con el uso de identidad basada en notificaciones.

Identidad basada en roles
La identidad basada en roles es el enfoque tradicional que usan las aplicaciones para la administración de identidad. Las entidades se dividen en grupos (roles) y los permisos se conceden de acuerdo a pertenencia en los grupos.

La identidad basada en roles es apropiada para escenarios sencillos: el usuario suministra sus credenciales (ej. un nombre de usuario y una contraseña); el marco de autenticación comprueba las credenciales en un almacén de identidades (ej. Base de datos SQL) y asigna el usuario a un grupo de roles y establece un contexto de seguridad en el que se ejecutará la aplicación (ej., Principal). La aplicación luego puede revisar de manera activa si el usuario en ejecución “IsInRole” antes de ejecutar operaciones sensibles permitidas únicamente a un grupo específico de miembros).

Los marcos de autenticación basada en roles generalmente proporcionan la infraestructura con la cual asignar grupos a permisos, y hacen cumplir y respetar la política de seguridad al permitir únicamente a aquellos usuarios a quienes se les concedieron los permisos requeridos, acceso a recursos confidenciales. Esto libera a la aplicación de tener que revisar activamente los permisos del usuario antes de cada acción.

La sencillez es una ventaja principal de la seguridad basada en roles. En algunos casos, sin embargo, estos escenarios sencillos simplemente fallan. Qué pasa si una aplicación necesita más información sobre el usuario que la que provee en un marco de autenticación? Qué pasa si los usuarios que maneja un socio necesitan acceso a la aplicación? Los marcos basados en roles no se diseñaron para la federación de identidades entre distintos proveedores de identidad.

- Implementación de identidad basada en roles en Azure
La mayoría de aplicaciones web hoy en día utilizan identidad basada en roles. La mayoría de usuarios, al considerar hospedar sus aplicaciones existentes en la nube, no aceptarían tener que cambiar su enfoque y tecnología de identidad. Por eso Windows Azure permite a los usuarios continuar el uso de su marco existente de identidad en la nube.
Cuando Kerberos (Windows Identity) se utiliza como el marco de autenticación, los roles en funcionamiento en la nube deben conectarse al Centro de distribución de Kerberos, o Kerberos Distribution Center (KDC). Sin embargo, el KDC y el controlador de dominio o domain controller (DC) nunca están expuestos a la web. Afortunadamente, Azure Connect permite establecer un VLN entre roles en ejecución en la nube y aquellos que están en los servidores locales. De esta manera, es posible establecer conexión entre Azure Roles y el controlador de dominio. Tales roles automáticamente se suscribirán al dominio y podrán usar sus identidades.
La aplicación ASP.NET introdujo proveedores de pertenencia, rol y perfil en el año 2005. Desde entonces, muchas aplicaciones web han usado su infraestructura sencilla pero ponderosa para administrar sus identidades. Las pertenencias definen a los usuarios, los roles asignan usuarios a grupos, y los perfiles guardan información arbitraria que pertenece a los usuarios.
ASP.NET define esquemas de bases de datos requeridos por los proveedores predeterminados. Este esquema se puede implementar como una base de datos separado o se puede combinar con la existente. En la configuración de la aplicación (ej. web.config), los proveedores se definen y se adjuntan a la base de datos mediante el uso de una cadena de conexión. Los proveedores usan ADO.NET para acceder los datos (TDS sobre puerto 1433). La conexión a SQL Azure es compatible con TDS, y así proporcionar una cadena de conexión a SQL Azure es completamente transparente para los proveedores. Una aplicación ASP.NET puede funcionar como un web rol y usar una base de datos implementada en SQL Azure para almacenar los datos del proveedor. Durante la migración de una aplicación a la nube, por lo tanto, todo lo que usted tiene que hacer es cargar la base de datos existente a SQL Azure y actualizar las cadenas de conexión. Si la información de identidad debe permanecer en las instalaciones locales (on-premises) es posible usar Azure Connect y apuntar cadenas de conexión al servidor que esté hospedando la base de datos.
El hecho de que todos los métodos de autenticación que son compatibles con ASP.NET (tales como autenticación Windows y autenticación de formas) aún son compatibles con Windows Azure remueve uno de los obstáculos más serios a la migración de aplicaciones.

Identidad basada en notificaciones
La administración de identidades es un nuevo enfoque del manejo de identidades. Fue diseñada para resolver algunos problemas y preocupaciones que despertó el enfoque de identidad basada en roles descritos anteriormente.
En el enfoque basado en notificaciones, un usuario presenta su identidad a la aplicación mediante el uso de un token que contiene una serie de claims o notificaciones. Una notificación podría ser el nombre del usuario; otra notificación podría ser una dirección de correo electrónico. La autenticación no la implementa la aplicación. Los usuarios autentican comprobando con un sistema externo de identidad conocido como un security token device (STS), que les proporciona tokens a los usuarios para que le entreguen a la aplicación. La aplicación puede después, de manera segura, usar la información que se encuentra en el token debido a la relación de confianza que se ha establecido entre el STS y la aplicación. Para cada solicitud que hace el usuario, el STS está configurado para darle a la aplicación todo lo que necesita saber acerca del usuario, además de la garantía criptográfica de que los datos de identidad recibidos en realidad proviene de una fuente de confianza.
Sacar la autenticación de las aplicaciones lleva a muchos beneficios para desarrolladores, profesionales de IT, y usuarios. Dicho de manera simple, hay menos cuentas de usuarios para que todas las personas 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 evolucionan, e incluso la identidad federada con otras plataformas y organizaciones.
En una solución basada en notificaciones, por lo tanto, la aplicación no necesita conectarse a ningún directorio de empresa en particular para buscar los detalles de la identidad de los usuarios. En cambio, la solicitud de los usuarios llega con todos los detalles de identificación que necesita la aplicación para hacer su trabajo. Para el momento en que llega el usuario con todas estas notificaciones, ya ha sido autenticado, y la aplicación puede seguir con sus asuntos sin preocuparse por administrar o buscar cuentas de usuario. El resultado es una aplicación más sencilla con menos código de infraestructura.
La unión con un nuevo asociado es sencilla en un escenario basado en notificaciones. La autenticación a través de un STS puede ser transitiva; si un socio tiene un STS que no es de confianza de la aplicación, pero se puede establecer la confianza entre este STS y otro STS que es de confianza de la aplicación, entonces los usuarios del asociado pueden proporcionar el STS de la aplicación con un token que han recibido de su propio proceso de autenticación, usando el token para adquirir otro token que después se puede utilizar para llamar a la aplicación.

- Escenario básico
El escenario básico identidad basada en notificaciones es relativamente sencillo.


Figura 1

La aplicación y el STS establecen una relación de confianza con el intercambio de claves criptográficas. (1).
La aplicación expone una política que define una lista de notificaciones que necesita y los STS de confianza que pueden producir dichas notificaciones.
Luego de recuperar esta política (2), el cliente contacta el STS (3), solicita las notificaciones requeridas por la aplicación. El STS autentica al usuario y le devuelve un token de seguridad que contiene todas las notificaciones.
El cliente luego hace la solicitud a la aplicación (4), enviando el token de seguridad con la solicitud del servicio. La aplicación valida el token y usa las notificaciones para hacerle una revisión al cliente y formular la respuesta.

- La Federación
Con el enfoque basado en notificaciones, la federación es sencilla de implementar porque la aplicación se desacopla de la administración de identidad y de los almacenes de identidad. Lo único que la aplicación necesita es un token de un STS de confianza; no necesita saber de qué manera el cliente suministró su identidad al STS y recibió el token. La federación es útil, por consiguiente, cuando una aplicación necesita proporcionar servicio a clientes que estén por fuera de su dominio natural. Esto podría surgir, por ejemplo, cuando un servicio interno disponible a los empleados de una compañía se extiende y debe servir a los empleados de un asociado también, cuyas identidades se administran por fuera de la compañía. Esta situación está ilustrada en la Figura 2.

Figura 2

En este ejemplo, la Administración de Contoso ha emitido órdenes administrativas al departamento de IT para permitir a los empleados de su asociado, Fabrikam, el uso de una aplicación que hasta el momento sólo ha estado disponible para empleados de Contoso. La política de servicio es muy sencilla: se presenta el token creada por el STS de Contoso, y se proveerá el servicio. Los empleados de Contoso pueden con facilidad recibir el token y usar el servicio, pero los empleados de Fabrikam no tienen la habilidad de usar el STS de Contoso. Por lo tanto, en lugar de incorporar una relación directa con el STS de Fabrikam a la aplicación, los empleados de Fabrikam pueden usar los tokens que han recibido del STS de Fabrikam para que el STS de Contoso les de un token basado en el hecho de que confía en el STS de Fabrikam.
Los empleados seran autenticados en el STS local de la organización (1), recibirán un token (2), y lo presentarán ante el STS de Contoso (3).
Cuando se ha establecido la confianza entre dos STS, las reglas de asignación de notificaciones se definieron. Usando estas reglas, el STS de Contoso asigna las notificaciones suministradas por el STS de Fabrikam y las utiliza para crear un token válido para la aplicación (4).
Luego de recibir el token producido por el STS de Contoso, los empleados de Fabrikam pueden enviarlo a al aplicación para recibir el servicio (5).

- Interoperabilidad
Los protocolos que ejecutan aplicaciones distribuidas deben estar estandarizadas para permitir la colaboración entre distintas tecnologías y plataformas. El grupo más popular de estándares relativas a servicios web se llama WS-*, y contiene estándares tales como WS- Security, WS-Federation y WS-Trust.
Es vital que el STS sea interoperable con todos los diferentes tipos de usuarios y usuarios de confianza que usarán sus servicios. Varios estándares de WS-* se usan en el escenario descrito anteriormente. La política se recupera usando http GET y la política en sí misma se estructura de acuerdo a las especificaciones de WS-Security, WS-Federation y WS-Trust. El STS expone los extremos que implementan la especificación de WS-Trust, que describe como hacer la solicitud y la recepción de tokens de seguridad. La mayoría de STS emiten tokens de SAML (Security Assertion Markup Language). SAML es un vocabulario XML reconocido por la industria que se puede usar para representar notificaciones de una manera interoperable.

SAML, con WS-Federation y WS-Trust standards, define todos los detalles alrededor de la autorización basada en notificaciones:
• Los escenarios de casos de autorización basada en notificaciones
• Los protocolos de comunicación
• Los jugadores y sus tareas en los protocolos
• La estructura de los metadatos expuestos por cada uno de los usuarios.

La adherencia a los estándares permite la comunicación con otros STS que estén en plataformas completamente distintas y permite inicio de sesión único en muchas aplicaciones, sin importar el tipo de plataforma.
El desarrollador se libra de tener que manejar todos los detalles de estándares de SAML y WS-*, porque WIF y ACS (descrito más adelante), hacen todo el trabajo pesado y proporcionan interfaces sencillas y modelos de objetos a ser usadas por el desarrollador.

- Escalabilidad y disponibilidad
El STS es un elemento principal en soluciones basadas en notificaciones. Si el STS está abajo (down) o no está disponible, los usuarios no podrán recibir tokens y por lo tanto no se les permitirá el uso de la aplicación. Adicionalmente, un STS individual probablemente se utilizará para servir a múltiples aplicaciones con distintas cargas de trabajo al mismo tiempo. Por esto, el STS debe estar diseñado para ser escalable y disponible en todo momento, y debería poder manejar picos impredecibles en la demanda. La nube es un entorno natural para hospedar este tipo de aplicación.
No es por lo tanto sorprendente que uno de los servicios proporcionado por la plataforma de Windows Azure es un STS. Este STS se llama Access Control Service (Servicio de Control de Acceso)

Access Control Service (ACS)
Windows Azure AppFabric Access Control Service (ACS) 2.0 es un servicio hospedado que proporciona autenticación federada y de autorización manejada por reglas basada en notificaciones para aplicaciones de Winddows Azure. Al desempeñar el rol de un recurso de STS que puede recibir notificaciones de usuarios externos y las transforma en notificaciones que la aplicación puede utilizar, ACS 2.0 les permite a los usuarios lograr una externalización real de las políticas de autorización, y de esta manera ofrece la oportunidad de desacoplar las aplicaciones para la mayoría de la lógica de autorización, al hospedar esa lógica (en la forma de reglas de transformación de notificaciones) en el ACS en sí.

ACS 2.0 les permite a los desarrolladores construir aplicaciones y servicios que acepten tanto identidades empresariales (a través de la integración con Active Directory Federation Services 2.0), y una amplia gama de identidades web (a través de la compatibilidad con identidades de Windows Live ID, OpenID, Google, Yahoo y Facebook) con el uso de un único código de base. ACS 2.0. proporciona compatibilidad con los formatos de token de SAML 1.1, SAML 2.) y Simple Web Token (SWT), y está plenamente integrado con el marco de Windows Identity Foundation (WIF).

Como se describió anteriormente, un STS es un servicio necesario para todas las aplicaciones basadas en notificaciones. Acces Control Service es un STS confiable, escalable y disponible que ofrece Azure para el uso de todas las aplicaciones basadas en notificaciones ejecutadas por clientes de Azure.
Access Control Service tiene un portal simple que es accesible desde el portal principal de Azure. Para crear un sTS, lo único que usted tiene que hacer es abrir un espacio de nombres en AppFabric y habilitar Access Control La configuración del STS consta de tres pasos principales:

Paso 1: Configurar proveedores de identidad.
Establezca la confianza con proveedores de identidad (STS) que emitirán tokens de entrada. Una vez establecida la confianza, el aCS puede procesar tokens que se originen de estos STS y asignar notificaciones de entrada a notificaciones de salida.
El ACS viene con una lisa de proveedores de identidad que ya son de la confianza de Azure, tales como Google, Yahoo y Windows Live ID. Usted puede seleccionar entre estos o establecer confianza con ACS y su propio ADFS 2.0 u otros STS predeterminados.

Paso 2: Establecer confianza con una aplicación de relying party (RP), o usuario de confianza.
En ACS, una aplicación de usuario de confianza es sólo una proyección de la aplicación al sistema. La RP define los URLs para la aplicación, la preferencia de formato de token, el tiempo de expiración del token, las opciones de firma del token, y las opciones de cifrado del token.

Paso 3: Definir reglas de asignación.
Defina las reglas de asignación que definen cómo ACS emitirá tokens a su aplicación de acuerdo a las notificaciones de entrada proporcionadas por los proveedores de identidad.

Después de la configuración, el portal proporciona una sección de Aplication Integration (Integración de la aplicación), que incluye toda la información necesaria para agregar una referencia STS (usando WIF) al ACS. Generalmente todo lo que usted necesita es el extremo de metadatos expuesto por el ACS.

Windows Identity Foundation
WIF es un marco para la implementación de aplicaciones para notificaciones. Puede ser utilizado en cualquier aplicación web, servicio web, aplicación de nube, o aplicación local.
WIF fue diseñada para facilitar la interacción con notificaciones al proporcionar un API simple y herramientas que unificarán y simplificarán aplicaciones para notificaciones. Está construido sobre el plumbing (la fontanería o las instalaciones sanitarias) de WCF y utiliza a cabalidad su sencillez y extensibilidad. WIF también implementa todos los estándares relacionados de
WS-* y SAML. WIF liberando al desarrollador de tener que manejar sus detalles. ,
WIF ofrece una variedad de otras posibilidades además: un API simple para administración de tokens y de notificaciones, una clase base para la construcción de un STS personalizado, ASP.NET HttpModules para procesamiento de tokens al interior del la canalización http de aplicaciones basadas en la red, y mucho más.
Con WIF, desarrollador está escudado de todo el trabajo pesado criptográfico requerido para implementar protocolos basados en notificaciones. WIF descifra el token de seguridad presentado por el cliente, valida su virma, valida cualquier clave de prueba, destruye el token en una serie de notificaciones, y los presenta al desarrollador a través de un modelo de objetos fácil de consumir.
WIF está plenamente integrado con Visual Studio 2010. Proporciona las herramientas necesarias para integrar compatibilidad con notificaciones en las aplicaciones web existentes a través de tan sólo unos pocos clics del mouse. WIF es la tecnología recomendada para integrar Azure AppFabric ACS en su aplicación.

Conclusión
Casi todas las aplicaciones deben manejar la identidad, que es un pilar principal en la aplicación de la seguridad. Windows Azure es compatible tanto con el enfoque de la identidad basada en notificaciones como con el enfoque la identidad basada en roles. La administración de la identidad no es un tema sencillo. La mayoría de los desarrolladores no son expertos en seguridad, y se sentirán incómodos al ser asignados las tareas de autenticar, autorizar, y personalizar experiencias para los usuarios.

La identidad basada en notificaciones saca la administración de la identidad fuera de los límites de la aplicación, liberando al desarrollador y al profesional IT de esa pesada carga de responsabilidad. Produce tokens que contienen información sobre el usuario en la forma de notificaciones. De estos tokens, la aplicación recibe toda la información que necesita sobre el usuario, y esta información se adjunta a la solicitud de servicio.
Crear un STS no es sencillo. Un STS debe ser escalable, confiable y disponible. Windows Azure APPFabric por eso ofrece una STS tal como un servicio: escalable, confianza y disponible por diseño, porque se ejecuta en una nube de Windows Azure.


Hasta la próxima.
Fuente: Microsoft.