Compartir a través de


Consejos prácticos para crear aplicaciones seguras

Cuando se trata de soluciones en la nube, es muy importante para los arquitectos y desarrolladores de software poder anticiparse a las amenazas en tiempo de diseño, más aún que en el caso de desarrollar aplicaciones que vayan a ser desplegadas en servidores corporativos. En este punto se ofrecerán algunas consideraciones a tener en cuenta para intentar mitigar algunas posibles amenazas para las aplicaciones que de desplieguen en la nube.

El abanico de posibles amenazas de un servicio basado en la nube es sustancialmente diferente de los tradicionales servicios  desplegados en un servidor corporativo en términos de técnicas de mitigación y tecnologías. Las amenazas también varían dramáticamente entre los proveedores de nube.

Los puntos clave a tener en cuenta son:

  • Los desarrolladores deben relacionar los tradicionales requisitos de seguridad de las soluciones tradicionales con los requisitos de las aplicaciones desplegadas en Windows Azure. Cualquier amenaza deberá ser mitigada por la aplicación o servicio.
  • Comprender los requisitos de seguridad del servicio que se diseña o se migra, sobre todo en el contexto de la autenticación, autorización y auditoría. Lo servicios de la plataforma que ofrecen estas características (Windows Identity Foundation, Windows Azure AppFabric Servicio de Control de Acceso y diagnóstico de Windows Azure) y la forma de utilizarlo por parte de los desarrolladores es sustancialmente diferente de las previstas en una implementación empresarial on-premise (Kerberos, Active Directory, los registros de sucesos de Windows).
  • Aprovechar los servicios de Windows Azure Platform para construir aplicaciones más seguras.

Es necesario resaltar, que aunque la plataforma ofrezca servicios para poder mejorar la seguridad de las aplicaciones desplegadas en la nube, el desarrollador sigue siendo el responsable de crear código de buena calidad y de ser responsable de seguir las recomendaciones de seguridad para el desarrollo de aplicaciones y protegiéndose de las posibles amenazas; validar las entradas, incluir restricciones en la entrada de valores etc...

Consideraciones en la configuración del espacio de nombres

En este punto se detallan algunas consideraciones a tener en cuenta en la configuración de aplicaciones a desplegar en la nube.

Evitar usar nombres como <servicename>.cloudapp.net. Es conveniente utilizar un nombre personalizado para el nombre del dominio en lugar del nombre del servicio.

El espacio de nombres cloudapp.net se comparte entre todos los clientes de Windows Azure Platform mientras que un espacio tradicional, como microsoft.com, es controlado únicamente por la empresa propietario del dominio. Esto significa que el espacio de nombre cloudapp.net ofrece menos nivel de confianza que un espacio de nombres tradicional debido a que un cliente de Windows Azure no tiene por qué confiar automáticamente en el resto de clientes de ese espacio de nombres. No debe crearse código que requiere añadir el espacio de nombres "cloudapp.net" en la lista de sitios de confianza del navegador web.

Nunca utilizar cookies con el espacio de nombres cloudapp.net. En su lugar es mejor utilizar un subdominio, por ejemplo miaplicacion.cloudapp.net. El espacio de nombres es común para todos los clientes de Windows Azure.

Para la mayoría de contenidos, sólo se permite la interacción con contenido dentro de mismo dominio. Desde una página que está contenida dentro de un dominio puede accederse sin problemas al contenido de otra página que está dentro del mismo dominio, empleando scripting.

El modelo de objetos DHTML permite a través de document.domain chequear y configurar dicha restricción. Sólo páginas  con la misma configuración de las propiedades de dominio pueden interaccionar entre ellas. Además de la configuración, el protocolo empleado debe ser el mismo. Por ejemplo, desde HTTP no puede acceder a contenido que está en HTTPS.

Este funcionamiento es importante tenerlo en cuenta si en algún momento se modifica y se amplia el acceso a document.domain, ya que una mala configuración puede dejar abierta la posibilidad de que cualquier aplicación de Windows Azure pueda acceder al contenido de la aplicación. IIS 7 debe acceso por defecto a todo el subdominio.

Seguridad de los datos

Cuando se diseña la relación entre un Web Role y Windows Azure Storage el uso de firmas de acceso compartido (Shared Access Signatures) es una herramienta potente que permite securizar el acceso al contenido del storage y de ofrecer acceso sólo a aquellas aplicaciones que deban tenerlo. Si el contenido de Windows Azure Storage no se securiza convenientemente éste será de acceso público. Cualquier aplicación o cliente, ya esté en la nube o en otra ubicación.

Las firmas de acceso compartido representan un token de seguridad que ofrece permisos de acceso a contenedores y blobs de Windows Azure Storage que son de acceso privado. Los contenedores y blobs de acceso público son accesible por cualquier aplicación o cliente, ya esté en la nube o en cualquier otra ubicación.

Si la información no debe ser pública, es conveniente establecer correctamente la seguridad de acceso a los datos empleando estas claves que actúan como token de seguridad. Es necesario poder conocer la firma para poder acceder al contenido.

La aplicación que crea el contenido es la responsable de establecer la información de seguridad y de distribuir convenientemente el token de seguridad a los clientes que necesiten acceso a la información. Si un token se ve comprometido es posible cambiar dicho token e invalidar el existente.

Por este motivo, es conveniente diseñar correctamente la política de seguridad de acceso a los datos albergados en Windows Azure Storage y de proteger aquel contenido que sea de especial relevancia.

Es conveniente generar token de seguridad (Shared Access Signatures) lo más restrictivas posibles y si es posible, que dispongan de un período corto de vida.

Es conveniente emplear siempre comunicación HTTPS para intentar evitar que las firmas se vean comprometidas.

Y por último, es importante recordar que estos tokens de seguridad deben usarse únicamente para acceder de manera temporal al contenido privado de los blobs y que es una práctica poco recomendada emplear siempre los mismos tokens.

Windows Azure Table ofrece un entorno para almacenar información estructura no-SQL, por lo que no es vulnerable a las amenazas de SQL Injection típicas de los sistemas SQL. La aplicaciones que empleen SQL Azure como sistema de almacenamiento sí que deberán tener en cuenta las mismas amenazas que podría haber en una aplicación que emplee SQL Server.

Las peticiones a las tablas del storage puede hacer por HTTP GET o HTTP POST. Es conveniente tener en cuenta que estas peticiones podrían llegar a ser modificadas de manera malintencionada, haciendo modificaciones en las información enviada en la petición HTTP. Por este motivo es conveniente no incluir información sobre los nombres de contenedores, blogs, identificativos o nombre de tablas.

Almacenamiento de información secreta

Durante la realización de este contenido la plataforma Windows Azure no dispone de un soporte para Data Protection API (DPAPI) para poder encriptar la información almacenada en Windows Azure Storage.

Si por ejemplo se desea encriptar un blob, debe ser la aplicación que suba el blob al contenedor la encargada de encriptar la información antes de subir la información a Windows Azure Storage, empleando algunas de las técnicas que puedan existir actualmente.

Los desarrolladores deben preocuparse de no almacenar las claves privadas en Windows Azure Storage, ya que éstas podrían ser accesibles por terceros.

Auditoría y registro de sucesos

En Windows Azure no se dispone de acceso a recursos locales del sistema de archivos ni al log de eventos de Windows.

El acceso local al disco de una instancia de Windows Azure debe considerarse siempre como un acceso temporal y no persistente y no debería emplearse nada más que para almacenar ficheros temporales o a modo de caché.

Esta situación plantea la necesidad de tener un mecanismo diferente a los tradicionales para escribir las trazas de la aplicación. Algo que permita detectar y diagnosticar comportamientos anómalos de la aplicación cuando ésta se encuentra desplegada en la plataforma Windows Azure.

El SDK de Windows Azure proporciona un 'trace listener' especialmente diseñado para ser utilizado en aplicaciones en la nube. Este listener está implementado en la clase DiagnosticsMonitorTraceListener del namespace Microsoft.WindowsAzure.Diagnostics y deriva de la clase TraceListener del framework de .Net. Trabajar con este listener es, por tanto, idéntico a trabajar con cualquier otro trace listener de .Net.

Como el almacenamiento local no es  posible existe la posibilidad de almacenar las trazas de la aplicación en el almacenamiento de Window Azure.

Windows Azure no soporta actualmente la opción de encriptar el contenido de las tablas de Windows Azure, por lo que es importante que el desarrollador no escriba información sensible en la información de diagnóstico, ya que esta se almacenará en el Windows Azure Storage.

El desarrollador podrá elegir entre HTTP o HTTPS. La recomendación por defecto es emplear HTTPS, aunque debe tenerse en cuenta que el rendimiento ofrecido por este protocolo es menor que el ofrecido por HTTP, consideración que debe tenerse en cuenta si la cantidad de información que se escribe es alta.

Patrón de seguridad de diseño seguro "Gatekeeper"

 Gatekeeper es un patrón de diseño que define la forma de acceder a un sistema de almacenamiento con el objetivo de minimizar el área de ataque. El acceso al almacenamiento sólo puede accederse de forma privada y a través de canales privados, no pudiéndose hacer desde aplicaciones externas.

Si una aplicación externa desea acceder a la información debe acceder a través de un rol que actúa como "broker". El punto de entrada a la información es rol que actúa como broker y que residen en otra máquina virtual.


Figura 1.- Patrón GateKeeper

El GateKeeper es un web role que recibe las peticiones que vienen desde Internet, peticiones que son potencialmente peligrosas y en las cuáles el GateKeeper no puede confiar. El GateKeeper se implementa en código manejado y funciona con Partial Trust. La configuración de este rol no debe contener ninguna información secreta ni clave de acceso a ningún recurso.

El KeyMaster es un worker role que sólo permite comunicaciones internas dentro de Windows Azure, que por tanto, no puede recibir peticiones desde Internet. El KeyMaster recibe las peticiones que el GateKeeper le realiza a través de HTTPS y es capaz de interactuar con el sistema de almacenamiento para atender las peticiones del GateKeeper.

El KeyMaster confía en las peticiones del GateKeeper y en su configuración dispone de la información necesaria para conectarse al sistema de almacenamiento.