Seguridad en aplicaciones desplegadas en Windows Azure


Política de seguridad en aplicaciones en Microsoft.Windows.Azure

Recientemente un compañero de IT me ha preguntado por los sistemas de seguridad que implementamos en las plataformas que hemos desarrollado sobre Azure. Bien, había algunos que yo ya tenía claro, pero para acabar de clarificarlo todo, he decidido investigar un poco, recopilar información de diferentes fuentes y plasmarlo en este artículo. Espero que este resumen le sirva a alguien más.

Para establecer que una solución es segura, se deben tener en cuenta diferentes niveles de seguridad. En los que son responsabilidad del proveedor no me voy a extender mucho, pues ya hay mucha literatura al respecto en internet:

Seguridad física

Responsabilidad de Microsoft Windows Azure.

Centros de datos Microsoft Global Foundation Services (GFS) con ISO 27001.

Implementación de Safe Harbor Framework para garantizar la transmisión y custodia de los datos entre U.S.A. y la U.E. (con apartado especial para U.S.A. y Suiza).

Seguridad de la red

Responsabilidad de Microsoft Windows Azure.

Sistema diseñado sobre la base del Hypervisor de Hyper-V.

Arquitectura triple de aislamiento para cada VM de otras VM’s y de elementos que procedan de Internet. Una VLAN con las VM. Otra VLAN con los nodos de FC (Fabric Controller) que se encargan de crear nuevos roles y supervisar los existentes. La tercera se encarga de los dispositivos de red y otros elementos de infraestructura.

Esta arquitectura asegura que si el código que se está ejecutando en una VM compromete la seguridad, este compromiso no se va a transmitir a los nodos de FC ni a los dispositivos de red.

Además de esta protección interna, se añaden tres elementos de filtrado:

                Filtrado de Paquetes

El hypervisor implementa un filtro de paquetes para evitar Spoffing y tráfico no autorizado hacia las VM’s.

                Canales SSL

Todas las comunicaciones en Azure se producen mediante un canal seguro.

Entre el desarrollador y el entorno para despliegue de aplicaciones.

Entre la aplicación y SQL Azure para ejecución de consultas.

Entre la aplicación y el BlobStorage para guardar y recuperar archivos.

Entre la aplicación y el TableStorage para guardar y recuperar registros.

Entre el cliente y la aplicación (siempre y cuando no especifiquemos un EndPoint no seguro por ejemplo por el puerto 80).

                Firewalls de IP

Superficie de ataque minimizada en SQL Azure al seleccionar específicamente las IP desde las que se permite acceder a los datos.

Al definir EndPoints en los Roles de Azure, automáticamente se generan las reglas que se configuran en los Firewalls de dichos roles.

Seguridad del host

Responsabilidad de Microsoft Windows Azure.

Entorno completamente virtualizado. Dicha virtualización es, en parte, responsable de la capacidad de escalado horizontal rápido tanto hacia arriba como hacia abajo. No existe el almacenamiento persistente en nodos de este tipo.

El hipervisor de Windows.Azure hereda directamente del Hypervisor de Hyper-V usando únicamente los elementos imprescindibles de Windows Server para ser capaz de hospedar VM’s, como el Fabric Controller. Es una manera también de reducir la superficie posible de ataque.

Otra barrera crítica es el aislamiento de la VM raíz de las VM’s invitadas y las VM’s invitadas unas de otras. Esta barrera la maneja el hipervisor y el SO raíz.

Azure revisa automáticamente el VHD(disco virtual) que contiene el sistema operativo y lo mantiene actualizado.

El diseño de las máquinas virtuales es otro mecanismo mediante el cual poder controlar la integridad de la aplicación. Cada VM está conectada a tres VHD:

D: Versiones de SO invitado. Mantenidas actualizadas por el sistema.

E: Imagen construida por el FC basado en el paquete de la aplicación subido por el cliente.

C: Configuración, archivos de paginación y otros tipos de almacenamiento.

Seguridad de las aplicaciones

Responsabilidad del desarrollador.

Para asegurar nuestras aplicaciones, podemos utilizar diversas técnicas, algunas o todas a la vez. Un ejemplo serían las siguientes:

Ejecución de aplicaciones en Modo PARTIAL TRUST

En modo FullTrust, la aplicación tendrá acceso a:

Ejecución en modo no-administrador

Ejecución de Código Nativo

Variables de Entorno

P/ Invoke

Registro

Sistema de archivos

Sin embargo, si ejecutamos la aplicación en modo Partial Trust:

Ejecución en modo no-administrador

Acceso parcial al sistema de archivo (TEMP)

Espacio de nombres

Usar un nombre personalizado para guardar este nombre en las cookies (p.ej. midominio.com) . No usar nunca un nombre tipo <nombreapp>.cloudapp.net.

GateKeeper

El GateKeeper se implementa en un WebRole que recibe las peticiones desde internet. Este WebRole se comunica con el KeyMaster que es un WorkerRole que sólo permite comunicaciones internas dentro de Azure, por lo que está aislado del exterior. El KeyMaster recibe peticiones del WebRole, en quien confía, y traslada las peticiones del WebRole al sistema de almacenamiento a través de SSL.

XSS (Cross Side Scripting)

Aparentemente, si usamos el framework MVC3, la protección contra XSS parece bastante robusta.

Llegados a este punto, será perfectamente comprensible que separemos absolutamente el código <script> de nuestro renderizado Html en ficheros diferentes.

Session Hijacking

Aun así, si un atacante pudiera orquestar un ataque XSS, lo siguiente que haría sería intentar tomar control de la cuenta de usuario.

HttpOnly Flag

Si en la creación de la cookie de autenticación, añadimos este flag, ningún código en Javascript será capaz de usar la cookie y, por tanto, inyectarnos código.

Además, si añadimos al formulario el helper Html.AntiForgeryToken(), haremos que la cookie contenga el mismo valor aleatorio que el campo renderizado. Una vez hecho esto, podemos decorar nuestros actions de [HttpPost] además con [ValidateAntiForgeryToken].

Ataques DDOS

En Web.Config, estos valores evitarán algún tipo de estos ataques. Se puede consultar en esta documentación para lo que sirve cada uno.

<httpRuntime

enableHeaderChecking = “True”

executionTimeout = “60”

maxQueryStringLength = “2048”

maxRequestLength = “4096”

maxUrlLength = “260”

/>

Seguridad de los datos

Responsabilidad de Microsoft Windows Azure y del desarrollador.

Autenticación SQL

Se provee el usuario en cada conexión y se obliga a autentificar cada 60 minutos.

Bloqueo de IP Nativo en el Firewall de SQL Azure

SQL Azure nos proporciona de manera nativa un Firewall en el que, si queremos acceder desde fuera de Azure tendremos que añadir nuestras IP. Bien, esto no es excesivamente seguro y, para reducir la superficie posible de ataque, podemos eliminar incluso el acceso desde dentro de Azure y habilitar únicamente la ip que corresponda con nuestros WebRoles.

Inyección SQL

Partimos de la base de que estamos usando un ORM. En mi caso EF. Si queremos evitar que nos inyecten código SQL es sencillo. En el caso de EntityFramework, sólo existe la posibilidad de que juntemos el resultado de un editor con el contenido de un Command Text de Entity. Si evitamos esto, será difícil que nos cojan desprevenidos.

Evitar devolver IQueryable

Bueno, además de no devolver IQUERYABLE, intentar devolver un IENUMERABLE (con .ToList()) de EXCLUSIVAMENTE lo que se va a renderizar.  Linq permite el método Take y el operador Limit para limitar el tamaño del resultado. Esto, además de hacer que la página se renderice más deprisa, evita que se pueda iterar sobre el objeto devuelto.

(…)

Bueno, aquí me paro por hoy, ampliaré más información en  breve.

(…)

Google
Visita mi perfil en Google Plus

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s