sábado, 18 de agosto de 2012

Haciendo una conexión segura a Windows Azure con WAC–Windows Azure Connect – Parte 1

En el post pasado, vimos que una de las formas más simples, económicas y seguras de exponer servicio al mundo exterior era utilizando la nube con lo que se conoce como Frame Relay. Ahora bien, la pregunta que surge es ¿Cómo hago mi conexión desde mi servidor de servicios hasta el servicio WCF en Azure? La respuesta es Azure Connect.

Windows Azure Connect es un componente de la plataforma Azure que permite crear conexiones entre computadoras ( o VMs ) dentro de la empresa y los roles de Windows Azure ( VMs al fin y al cabo ). Azure Connect (AC) crea una conexión segura IPSec desde el cliente hacia el servidor utilizando “agentes”, que en realidad son componentes de software en cada extremo que se encargan de administrar la conexión. La siguiente figura nos muestra esta funcionalidad.

image

Azure connect no solamente me va a permitir hacer “relay services” desde Azure hacia mis servicios WCF, si no también me facilita la posibilidad de acceder recursos desde la nube que están en mi “data center” tales como bases de datos, folders y archivos e impresoras. Igualmente, los roles de azure pueden incorporarse al active directory local utilizando AC.

Utilizando Azure connect podemos migrar aplicaciones a la nube y permitir que estas puedan seguir accediendo o interconectándose con otras aplicaciones dentro de la empresa ya sea utilizando arquitectura punto a punto, EAI o SOA.

En el próximo post vamos a implementar una conexión vía Azure connect desde Azure hacia una aplicación local.

Etiquetas de Technorati: ,

martes, 17 de julio de 2012

Service Relay: Exponer servicios desde mi empresa de forma segura

Normalmente las empresas tiene sitios web y servicios web para consumo interno que aunque deberían tener un esquema de seguridad, en muchos de los casos corren totalmente inseguros. Por otro lado, es común que las empresas tenga sitio web en donde el usuario pueda ver información de la empresa; estos comúnmente hosteados en datacenters de pago o en servicios de hosting en otros países como USA o Australia donde el costo es muy muy bajo –> alrededor de $5 al mes en su versión más básica.

Sin embargo, existe un escenario que siempre genera miedo entre las personas que componen un departamento de TI –> Necesitamos publicar nuestros servicios Web que acceden nuestros sistemas “core” de negocio, ya que requerimos que otros socios de negocio puedan consumirlos. Con ese escenario, aparecen diversas recomendaciones y soluciones – algunas efectivas otras no tanto – en donde por lo general hay que invertir una gran cantidad de dinero y esfuerzo.

Las soluciones varían en rango en temas tales como:

  • Uso de una DMZ
  • Uso del https
  • Uso de certificados digitales para autenticar el servicio o para evitar tampering del mensaje.
  • Poner varios servidores para evitar que el usuario ingrese directamente a los servicios y por ende a las capas inferiores

Todo esto sin duda puede ser efectivo [al menos retrasar el ataque] o disminuir la superficie de ataque, con lo cual vamos creando condiciones más incómodas para los posibles “hackers”. ¿Y a que viene todo esto y como lo relaciono con la nube?

Pues bien, resulta que Windows Azure tiene un componente que es muy relevante en estos ( y muchos otros ) escenarios. Este componente se llama el Service Bus. Este service bus nos permite exponer servicios utilizando una técnica conocida como “service relay”, en donde podemos exponer contratos de servicios en la nube que de forma privada consumen servicios que exponemos desde nuestra plataforma local, con lo cual obtenemos un nivel extra de aislamiento y además, estamos pasandole el primer nivel de protección a Windows Azure. En la siguiente figura se puede ver este escenario.

image

En este escenario, exponemos los servicios a través de Windows Azure y su Bus obteniendo así un nivel de abstracción que nos va a permitir asegurar el ingreso de consumidores a nuestros servicios ya que estos los podemos autenticar en la nube y autorizar de forma local. Igualmente, vamos a tener una conexión segura desde nuestra organización hasta la nube –> azure –> permitiendo no solo una conexión https si no también estableciendo que rango de dirección pueden interconectarse para exponer la implementación de los servicios. Con este escenario, lo que estamos pretendiendo es que para que un “hacker” pueda llegar a nuestro servidor, primero tenga que violentar la seguridad que vamos a establecer en el bus de Azure, con lo cuál no solo aumentamos la seguridad si no también reducimos costos ya que estamos trasladando parte del esfuerzo requerido a la nube. A este proceso de intermediación se le conoce como Service Relay.

viernes, 27 de enero de 2012

El rol de máquina virtual–> VM Rol

En este post vamos a tratar el rol de máquina virtual. Este rol permite implementar imágenes de Windows Server 2008 R2 en Windows Azure. Este rol funciona a partir de una máquina virtual creada en Windows server siendo luego cargada al ambiente de Windows Azure. En realidad este tipo de rol lo que hace es ejecutar la imagen de Disco Duro Virtual ( VHD ) en donde fue creado o instalado el sistema operativo.

Características del rol de VM

Las principales características de este rol son:

  • El sistema operativo de la máquina virtual se puede configurar y se le puede dar mantenimiento.
  • Se pueden utilizar los servicios del sistema operativo dentro del rol.
  • La máquina virtual puede pertenecer a un dominio de active directory y trabajarse a través del Azure Connect. Es importante destacar que un rol VM no puede ser un controlador de dominio de Active Directory –> esto por que no hay tráfico UDP.
  • Se pueden ejecutar tareas programadas.

Consideraciones

Al tener nosotros la posibilidad de crear la máquina virtual de primera se nos presenta la idea de poner aplicaciones que no se pueden tener en Azure o que hay que pagar extra para tenerlos en Azure tales como SharePoint Server o SQL Server. Sin embargo, todas las instancias de los roles – no solo el de VM – deben de ejecutarse en un ambiente sin estado, lo que significa que no deben de depender en los datos almacenados en el sistema operativo; todo esto para permitir que varias instancias idénticas puedan estar disponibles para darle robustez a la aplicación. Por lo tanto aplicaciones como SharePoint o SQL server no se soportan en este rol ya que son aplicaciones que manejan un estado.

¿Es este un rol de la plataforma PAAS de Azure?

Cuando uno analiza el objetivo de este rol surge la pregunta respecto a su este rol realmente pertenece a una oferta PAAS o a una oferta IAAS. Desde mi punto de vista este rol no es una oferta PAAS, es una oferta IAAS; esto principalmente porque de acuerdo a lo que se establece para delimitar estas ofertas, en realidad el creador de la máquina virtual tiene control absoluto sobre el sistema operativo y sus peculiaridades, algo que no debería suceder en una plataforma PAAS. Estos delimitadores los pueden ver en este post.

Etiquetas de Technorati: ,,