Introducción

La gobernabilidad de la nube implica aplicar políticas para utilizar los servicios de nube. Puede ser útil pensar en la gobernabilidad de la nube analizando su opuesto, el caos gratuito para todos, en el cual una organización utiliza los servicios de nube sin tener la supervisión instaurada. Para evitar este caos, aplique políticas para el uso de los servicios de nube para controlar la fuga de información privada a la nube y el uso excesivo de los servicios de nube (porque, después de todo, hay que pagarlos). Si la gobernabilidad y seguridad funcionan, podrá utilizar la computación en nube con confianza y de manera segura.

Volver arriba

Lecciones de la gobernabilidad de SOA

Gobernabilidad Es una palabra que cobró relevancia con la adopción de la arquitectura SOA. En el mundo de SOA, la gobernabilidad está dividida en tiempo de diseño (definición de políticas para los servicios web) y tiempo de ejecución (en realidad, la aplicación de esas políticas al tráfico en tiempo real).

Casi siempre se accede a las plataformas de nubes, como a los servicios de una arquitectura SOA, utilizando las API de servicios web, y, por lo tanto, deberían estar dentro del mismo encabezado que la gobernabilidad de SOA. Como mínimo, usted puede utilizar los principios en los que se basa la gobernabilidad de SOA.

A menudo, la gobernabilidad de SOA depende de la presencia de un registro. Es un lugar central al que puede dirigirse el usuario para ver los servicios de la plataforma SOA y las políticas aplicables a esos servicios. La política WS estándar, así como la especificación WS-Attachment complementaria, permite asignar una política a un servicio en una arquitectura SOA. En realidad, el servicio contiene un “indicador” para su política. El registro administra la relación entre los servicios y las políticas.

Otra función importante de los productos de gobernabilidad de SOA es la gestión del ciclo de vida de los servicios. Esto se refiere a la capacidad para controlar y realizar un seguimiento de los cambios al servicio, y colocar los controles sobre los que pueden realizar estos cambios. Una vez instaurada esta facilidad, una organización puede determinar quién creó el servicio, quién lo modificó y cuándo se produjeron los cambios.

¿Está resuelta la gobernabilidad de la nube gracias a la existencia de la gobernabilidad de SOA? No. Los servicios enviados hacia y desde los servicios de nube generalmente no son SOAP (Protocolo simple de acceso a objetos) y los servicios con frecuencia no están definidos por WSDL, que son dos de los estándares utilizados en la gobernabilidad de SOA en la mayoría de los casos. Esto significa que importar los servicios a un registro de gobernabilidad de SOA no es una tarea directa. Los servicios web utilizados por la computación en nube omiten a SOAP y WSDL y utilizan, en cambio, servicios livianos del estilo REST que son más populares entre los desarrolladores debido a su relativa simplicidad.

Las máquinas virtuales son otro aspecto nuevo de la computación en nube que la diferencia de SOA. Además de utilizar los servicios web, la computación en nube utiliza también máquinas virtuales. Podemos considerar que el entorno Amazon Elastic Compute Cloud (EC2) es una clase de entorno hosting virtual y no un conjunto de servicios. La Gobernabilidad del entorno Amazon EC2 puede considerarse, entonces, como un ejemplo de gobernabilidad de máquinas virtuales. En especial, la implementación de las máquinas virtuales puede derivar con facilidad en caos porque la organización termina teniendo muchas máquinas virtuales con ligeras diferencias entre sí no registradas. Tal como saben muchos usuarios de VMware o Citrix Xen, puede ser difícil mantener el seguimiento de las máquinas virtuales incluso para un usuario individual. Es sencillo imaginar cómo se multiplicaría este problema en el caso de una organización y cómo aumentaría aún más si las máquinas virtuales estuvieran alojadas en el servicio de nube de un tercero.

No obstante, la gobernabilidad de las máquinas virtuales (VM, por sus siglas en inglés) se superpone en algunos casos con los beneficios de “la gobernabilidad del ciclo de vida” de la gobernabilidad de SOA. En el mundo de la nube Amazon EC2, una VM es una instancia de una Amazon Machine Image (AMI). Es importante contar con una capacidad que haga cumplir normas como que sólo determinados usuarios pueden implementar imágenes AMI específicas. A un nivel más detallado, es muy importante contar con la capacidad para controlar quién reinicia una VM, quién suma capacidad al entorno de VM existente y quién elimina las instancias de máquina virtual existentes.

El último punto de la lista, eliminar las instancias de Amazon AMI, es particularmente importante porque las organizaciones pagan por utilizar estas instancias. El precio se basa en el uso (cuando la imagen se está ejecutando) y el tráfico de datos. Sin un sistema de gobernabilidad de nube en funcionamiento, la ejecución no deseada de instancias AMI de las máquinas puede proliferar y generar un costo innecesario. Sin embargo, lo opuesto también es cierto: sin una solución de gobernabilidad de la nube, es posible que algunas instancias AMI útiles puedan eliminarse por error. La gestión del ciclo de vida de las instancias AMI evita los problemas de las instancias encubiertas, del mismo modo que la gobernabilidad de SOA resolvió los servicios encubiertos que tienden a proliferar en organizaciones sin marco de gobernabilidad instaurado.

Volver arriba

Es un proceso y no un producto

Con frecuencia se dice que la gobernabilidad de SOA es un proceso y no un producto. La gobernabilidad de la nube se rige también por esta regla. La capacidad para aplicar las reglas de gobernabilidad depende de que los desarrolladores sean concientes de que se ha instaurado el marco de la gobernabilidad. Por ejemplo, si se implementa un registro de gobernabilidad de SOA, el desarrollador debe saber que aquí se registrarán los servicios web (en especial, sus definiciones de WSDL). Sin este registro, el servicio web queda fuera de la imagen del radar. Al igual que con la gobernabilidad de SOA, algo similar sucede con la gobernabilidad de la nube si no se le pide al desarrollador que registre su uso de los servicios de nube en su propia organización.

En el mundo de la gobernabilidad de SOA, además de la gobernabilidad de tiempo de diseño provista por el registro, hay una gobernabilidad de tiempo de ejecución por la cual se aplican las normas configuradas en el registro. Este punto de cumplimiento y aplicación para los servicios generalmente adopta la forma de agente incrustado o intermediario de red como una puerta de enlace XML.

Las herramientas de la gobernabilidad de SOA intercambian — el registro y el punto de cumplimiento del tiempo de ejecución como la falta de tara de agente o puerta de enlace XML — del mundo de la computación en nube. Esto significa que no hay un punto central para que un usuario de un servicio de computación en nube pueda ver todos los servicios y políticas asociadas. Y, aunque se cumplen las políticas del lado de la computación en nube de la conexión (por el proveedor mismo del servicio de nube), no se cumplen del lado del cliente. Éste es un desafío clave para la gobernabilidad de la computación en nube.

Volver arriba

Nubes encubiertas

En muchos sentidos, la computación en nube se parece a los primeros tiempos de los servicios web. Los desarrolladores decidían de manera individual considerar esta nueva tecnología para los proyectos, seguir adelante y usarla. Y todo esto pasaba inadvertido para la gerencia corporativa de TI. Luego, en una instancia tardía, se solía agregar un marco de gobernabilidad. En la actualidad, la mayoría de las organizaciones se encuentran en la etapa pre-gobernabilidad en lo que se refiere a la computación en nube. No es inusual que un desarrollador se interese por una imagen AMI para un proyecto, aunque el prototipo inicial contemple el uso de su tarjeta de crédito y su cuenta personal de Amazon.

Volver arriba

¿Está la gobernabilidad del lado del cliente — ausente sin aviso?

Un proveedor de servicios de nube generalmente no tiene que comunicar con anticipación a los clientes el tiempo que el servicio estará inactivo. Además, cuando se produce la interrupción del servicio por causas imprevistas, el proveedor del servicio de la nube no tiene la obligación de comunicar este hecho a los usuarios del servicio de nube. Para monitorear el tiempo de respuesta y la disponibilidad de los servicios de nube, se requiere un componente del lado del cliente. Este componente (por ejemplo, una puerta de enlace XML) monitorea la conexión con la plataforma de la nube. Si la conexión es lenta, entonces la puerta de enlace XML emite un alerta o toma una medida correctiva como el uso de respuesta de su caché. Si se utiliza el caché de esta manera, es posible mitigar los efectos de la interrupción del servicio de nube.

La puerta de enlace XML en el cliente también puede escanear los datos destinados a la nube en busca de fugas de información privada o sensible para la empresa. Además, habría que encriptar, o encriptar selectivamente, los datos antes de enviárselos al proveedor de nube. Por ejemplo, una puerta de enlace XML podría garantizar que los datos que ingresan al proveedor de computación en nube están desidentificados para que sea imposible asociar la información privada con los datos.

Las puertas de enlace XML, como la Edición XML Gateway Cloud de Vordel, filtran el tráfico que se envía a las plataformas de nube y aplican las políticas para acceder a los servicios de nube. Al hacerlo, las puertas de enlace XML brindan una vía de acceso al lado del cliente para los servicios de nube.

Volver arriba

Aplicar controles a la aplicación HybridCloud

En la Parte 2 de esta serie, usted comenzó a crear la aplicación HybridCloud que utilizó los servicios web de Amazon. Para poner la seguridad y gobernabilidad de la nube en perspectiva, ahora analizaremos cómo los servicios web de Amazon autentican esta aplicación y cómo se aplican políticas a su uso.

Las claves de Amazon

La aplicación HybridCloud utiliza el servicio de nube Amazon SQS. SQS, al igual que los servicios web de Amazon (AWS), requiere el uso de un ID de clave de acceso y una clave secreta asociada. Vimos las claves de Amazon que se utilizan dentro del código Java HybridCloud™ mediante una codificación no parametrizable de estas claves en la aplicación que está utilizando la nube Amazon SQS. Pero, ¿qué son estas claves? Examinémoslas en detalle.

Los lectores familiarizados con la Infraestructura de Clave Pública (PKI) podrían suponer que estas dos claves son, en realidad, claves públicas y privadas que están vinculadas en un par asimétrico de claves, como las claves utilizadas por los algoritmos RSA o DSA para el encriptado y las firmas digitales. Sin embargo, no son claves públicas y privadas clásicas. El ID de la clave de acceso se utiliza como identificador y su función es identificar la parte que accede al servicio AWS. Es similar en concepto al nombre de usuario y puede ser enviada en solicitudes no encriptadas. De hecho, cuando se utiliza el servicio de nube Amazon S3 para el almacenamiento online, el ID de clave de acceso forma parte de la URL. Si a un usuario se le asignó el ID de clave de acceso "12456789", entonces la URL utilizada para recuperar un archivo almacenado en el sector de almacenamiento del usuario para los archivos guardados en Amazon S3 será: https://s3.amazonaws.com/123456789- bucketname/filekey.

El ID de clave de acceso es claramente visible en la URL, lo que significa que también se almacenará en los registros de la infraestructura de redes, que enruta los pedidos al sector de almacenamiento de Amazon S3 para acceder al archivo. Por lo tanto, cualquier router o proxy tendrá acceso al ID de clave de acceso. No es útil para la autenticación porque es muy fácil descubrirlo. En realidad se utiliza a los fines de la identificación y no de la autenticación.

En cambio, para la autenticación se utiliza la Clave de Acceso Secreta. El cliente no la envía al servicio de AWS, sino que se utiliza para crear una forma de firma digital que se emplea, a su vez, para brindar una prueba de posesión de la clave de acceso secreta. Esta prueba de posesión es similar al método de encriptado utilizado por el protocolo SSL Handshake para probar que un cliente es, de hecho, el titular de una clave privada sin tener que enviarla. El hecho de que un cliente pueda utilizar la clave indica que dicha clave está bajo el control de ese cliente.

En el caso de un par de claves pública y privada (PKI), hay una relación matemática entre las claves en cuestión. Los datos encriptados utilizando la clave privada pueden desencriptarse utilizando la clave pública correspondiente. Esto es la base de las firmas digitales basadas en PKI. Sólo el titular de la clave puede crear la firma mientras que cualquier persona con acceso a la clave pública (generalmente tomada de un Certificado X.509) puede validar la firma.

La clave de acceso secreta en el modelo de servicios web de Amazon no tiene estas características. Por el contrario, se la podría considerar como un secreto compartido entre Amazon.com y el desarrollador que utiliza los recursos de AWS, como los servicios de nube. No debe compartirse con otros que podrían utilizarla para acceder a los servicios de nube de Amazon. Dado que el uso de los servicios de nube se factura al desarrollador, es vital que la clave de acceso secreta no caiga en las manos equivocadas. De lo contrario, se podría acumular una abultada cuenta a pagar. Si usted sospecha que un tercero accedió a una clave de acceso secreta, puede generar una nueva clave online.

En su aplicación HybridCloud, las claves tenían códigos no parametrizables en la aplicación misma. Sin embargo, a menos que utilice un obfuscador de Java, un atacante podría realizar una ingeniería inversa de la aplicación, y descubrir, de este modo, las claves. Ésta es una buena razón para usar un obfuscador Java (vea Recursos).

Políticas para la aplicación HybridCloud

En la Parte 2 de esta serie, usted vio que la aplicación HybridCloud envía datos de rayos X a Amazon SQS. Como las imágenes de rayos X son claramente datos médicos privados, es necesario escanear estos datos enviados al servicio de Amazon SQS para encontrar los datos privados en el lado del cliente. Una vez que los datos llegan a Amazon SQS, ya es demasiado tarde. Ésta es otra razón por la que se recomienda usar una puerta de enlace local para conectarse a los recursos de computación en nube.

Otra consideración de seguridad para la aplicación HybridCloud es restringir el acceso al servicio de Amazon SQS, de manera tal que sólo los clientes confiables puedan acceder al servicio. Esta funcionalidad se logra utilizando una política de Amazon SQS. Las políticas de Amazon SQS se encuentran definidas en la Notación de Objetos de Javascript (JSON).

Ahora analicemos algunas políticas de Amazon SQS que usted podría emplear en su aplicación HybridCloud (si desea conocer los detalles y el código fuente de la aplicación, consulte la Parte 2 de esta serie).

En primer lugar, esta política especifica que sólo un desarrollador con el siguiente número de cuenta de servicios web de Amazon 1234567890 puede acceder a la Cola (Queue), que es propiedad de un desarrollador con el recurso URI /987654321/queue 1(vea Listado 1).

                {"Version": "2008-10-17", "Id":
                12345678901234567890 "Statement": 
                { "Sid":"Queue1_SendMessage", 
                "Effect": "Allow",
                "Principal": { "AWS": "1234567890" }, 
                "Action": "SQS:SendMessage", "Resource":
                "/987654321/queue1" } }

Ahora analicemos la política en detalle. Lo primero que ve es la información sobre la versión. En este momento, el único valor válido para ese campo es 2008-10-17 Luego, ve el ID para su regla. Debe ser un identificador globalmente único dentro de los servicios web de Amazon. "Instrucción" es la política real. Aquí puede ver que el Recurso es la cola Amazon SQS. Usted está especificando que un"Mandante"en particular (en este caso, un determinado usuario AWS) puede acceder a una cola en particular y sólo ese mandante puede acceder a la cola.

Además, usted puede definir políticas para controlar el acceso a nuestra cola SQS sobre la base de la fecha, hora y dirección de IP de origen, como en el Listado 2.

                "Condition" : [{ "DateGreaterThan" : { "AWS:CurrentTime" :
                "2009-04-10T09:00:00Z" } "DateLessThan": { "AWS:CurrentTime" :
                "2009-04-10T17:30:00Z" } "IpAddress" : { "AWS:SourceIp" : 
                ["4.3.2.1/24"] } }]

En este caso, la política codificada dice que un cliente sólo puede acceder a la queue entre las 9:00 de la mañana y las 17:30 del día 10 de abril de 2009 y desde un rango de direcciones IP determinado.

Puede utilizar las funciones Agregar permiso y Eliminar permiso para establecer y eliminar determinados derechos de acceso para cada cola.

Sin duda, las políticas de Amazon SQS funcionan en el proveedor del servicio de nube. Sin embargo, si los datos enviados al proveedor de nube deben encriptarse o escanearse antes del envío, entonces el dispositivo de la puerta de enlace XML del lado del cliente es una herramienta ideal para esta tarea.

Ahora que usted sabe cómo restringir el acceso al servicio Amazon SQS para su aplicación HybridCloud, analice brevemente las soluciones de seguridad para la nube de Amazon, Google, y Salesforce.

Volver arriba

Amazon S3

Amazon S3 (Simple Storage Service) es un servicio de nube que se utiliza para el almacenamiento online. Se utiliza como una facilidad de almacenamiento back-end por medio de sitios web como el sitio para compartir fotos SmugMug (vea Recursos para encontrar un vínculo). Por supuesto, también puede utilizarse para los datos corporativos privados. Los datos que usted almacena en Amazon S3 podrían ser sensibles, dependiendo del contexto. Si sus datos son privados, entonces tiene sentido encriptarlos utilizando una puerta de enlace XML antes de enviarlos al servicio Amazon SQS. Además, es necesario seguir de cerca la forma de acceder a los datos desde Amazon SQS. Más allá de las cuestiones de privacidad, usted querrá seguramente rastrear el uso de Amazon S3 porque los usos se facturan. Nadie quiere sorprenderse con una factura abultada y quedarse sin una auditoría total del uso que derivó en esa factura. Por todas estas razones, es importante activar el logging para el servicio Amazon S3.

Una forma sencilla de activar el logging para un sector de almacenamiento de Amazon S3 es utilizando las aplicaciones Cloudberry Explorer para activar el logging para una instancia de S3 (vea Recursos si desea más información). Cloudberry Explorer brinda de manera efectiva un front-end de interfaz gráfica de usuario (GUI) a Amazon S3. En Cloudberry Explorer, basta con seleccionar el sector de almacenamiento y hacer clic en el botón Logging de la barra de herramientas. Luego, marque la casilla de verificación Use logging. Elija el sector de almacenamiento que contendrá sus archivos de registro seccionándolo desde el menú desplegable. En nuestro ejemplo es cloudberry.log. Los registros se escriben realmente en el servicio de nube de Amazon. Los archivos de registro deben ingresarse en un sector de almacenamiento de la misma zona geográfica (es decir, las aplicaciones de Estados Unidos deben escribir a registros de Estados Unidos). Los archivos de registro se agregarán a las facturas mensuales porque utilizan el almacenamiento Amazon S3. Sin embargo, éste es un precio (literalmente) bajo por tener una pista de auditoría de usuarios que han accedido a su servicio de almacenamiento Amazon S3.

Volver arriba

Google Apps

Google brinda una herramienta llamada Google Secure Data Connector (SDC) que conecta las aplicaciones Java del lado del cliente con el servicio de nube Google Apps. Brinda un vínculo encriptado entre una red local y Google Apps. Se utiliza, en especial, para poder conectar las aplicaciones Google Apps (alojadas en Google) a la red local. Su diseño permite garantizar que sólo Google Apps se pueda conectar a través de esta conexión. Además, proporciona filtros que definen qué gadgets de Google Apps pueden acceder a qué sistemas internos, de forma similar a las reglas de los firewalls pero a nivel de la aplicación. Además de controlar a qué aplicaciones se puede acceder, usted puede agregar un control a nivel del usuario que permite a la organización controlar qué personas acceden y a qué servicio de Google Apps se accede.

El marco de identidad para Google Apps SDS utiliza OAuth. Por ejemplo, los servicios de Google Apps alojados pueden identificarse a sí mismos (e identificar a sus usuarios) frente a las aplicaciones locales que usan OAuth. En la actualidad, OAuth todavía no está ampliamente implementado. Sin embargo, el aval de Amazon a OAuth podría modificar esta situación.

Volver arriba

Force.com: Salvaguardas y “pruebas sobre la marcha”

Tal como vio en la Parte 1 de esta serie, el servicio de nube Force.com de SalesForce utiliza un lenguaje de programación llamado Apex. Force.com obliga a que el código Apex alojado en su plataforma de nube incluya “asserts” para garantizar que el código se esté comportando como se requiere. Debe cubrir al menos el 75%, y preferentemente el 100%, de las clases Apex del desarrollador. Esta medida evita los ataques DoS (denegación de servicio) involuntarios a todo el sistema. Por ejemplo, un código que podría estar en un circuito infinito, o utilizar de algún otro modo una cantidad excesiva de recursos, debe estar contenido dentro de un código de prueba que detecte esas eventualidades. Otra medida de seguridad de Force.com es la imposición de límites (llamados gobernadores) que hacen cumplir las normas relativas a métricas como profundidad de la pila y tamaño de la cadena.

Aunque otros proveedores de nube no tengan reglas de prueba similares a las de Force.com, es una buena idea respetar sus recomendaciones aunque usted no utilice a Force.com como plataforma de nube. Además de protegerse de los ataques DoS, también podrá asegurarse de que no lo sorprenda una facturación inesperada por uso de parte del proveedor de nube.

Volver arriba

Resumen

Ya se han instaurado iniciativas como Cloud Security Alliance para abordar el tema de la seguridad de la nube. En la actualidad, proveedores como Amazon, Google, y Force.com están a la vanguardia a nivel de los proveedores del servicio. Sin embargo, no todos están convencidos: se solicitó a la Comisión Federal de Comercio que investigue los riesgos relacionados con la computación en nube debido a los problemas percibidos en la administración de los datos. A medida que se desarrolle el conocimiento sobre la seguridad y gobernabilidad de la nube, seguramente las ofertas de seguridad y gobernabilidad de la nube crecerán aún más.

Recursos

Aprender

• Conexión a la nube, Parte 1: Potenciar la nube en las aplicaciones: cómo aprovechar el modelo híbrido (Mark O'Neill, developerWorks, abril de 2009): analice todo lo que ponen a su disposición los proveedores de Computación en Nube (Amazon, Google, Force.com, y Microsoft Azure) por medio de un ejemplo de una aplicación corporativa típica que utiliza una cola JMS.
  
  
• Conexión a la nube, Parte 2: Entender el modelo híbrido de nube: cómo tirar los datos de la queue JMS a la cola SQS de Amazon (Mark O'Neill, developerWorks, abril de 2009): vincule una aplicación Java corporativa a las plataformas de Computación en Nube y analice cómo la aplicación puede potenciar la nube por medio de las API de XML, SOAP, y REST.
  
  
• Potenciar los servicios web de Amazon para la integración de aplicaciones de la compañía: mensajería de XML con Amazon SQS (Brian Stewart, developerWorks, junio de 2009): combine los servicios web de Amazon y XML para integrar las aplicaciones de la empresa. Construya una aplicación de muestra flexible y escalable para todas las plataformas y agnóstica en términos de tecnología. Incluya amplias muestras de códigos en C# y lenguaje Java.
  
  
• La Cloud Security Alliance: explore esta organización sin fines de lucro creada para alentar el uso de las mejores prácticas en la provisión de una garantía de seguridad dentro de la computación en nube.
  
  
• El almacenamiento se simplifica con Amazon S3: ingrese a la nube con el Servicio de Almacenamiento Simple de Amazon (Andrew Glover, developerWorks, abril de 2009): aprenda a utilizar la biblioteca JetS3t de código abierto para potenciar el servicio de nube Amazon S3 para almacenar y recuperar datos.
  
  
• wervicios web de Amazon: Consulte más información sobre los servicios web de Amazon y computación en nube.
  
  
• La computación en nube y los servicios web de Amazon (Prabhakar Chaganti, developerWorks, julio de 2008): aprenda a construir sistemas de escala Web con esta guía paso por paso para el uso de los servicios web de Amazon.
  
  
• Las nubes privadas toman forma: conozca las nubes híbridas en este artículo de Information Week.
  
  
• Puerta de enlace XML de Vordel, Edición de la nube: conozca esta puerta de enlace con conectores a las colas JMS más conectores pre-desarrollados a los servicios de nube.
  
  
• developerWorks Cloud Computing Resource Center: descubra los productos IBM que están disponibles para la plataforma EC2 de Amazon.
  
  
• Obfuscadores Java de código abierto: pruebe este compresor de archivos y obsfucador clase Java para archivos JAR más pequeños a los que es más difícil aplicar ingeniería inversa.
  
  
• Blog de Google App Engine: visite un gran lugar para seguir su desarrollo.
  
  
• Navegar por el laberinto de la computación en nube (Brett McLaughlin, developerWorks, marzo de 2009): tome una decisión informada sobre la mejor plataforma de computación en nube para sus requerimientos de aplicaciones específicos.
  
  
• Conexión del iPhone de Apple a las ofertas de computación en nube de Google (Noah Gift y Jonathan Saggau, developerWorks, enero de 2009): infórmese sobre la forma en que es posible acceder a la nube a través de dispositivos móviles.
  
  
• Integración de los datos con Salesforce CRM utilizando IBM InfoSphere Information Server (Jon Deng y Jeff J. Li, developerWorks, julio de 2008): descubra cómo Salesforce logra que los datos sean accesibles para sus aplicaciones.
  
  
• Certificación XML de IBM: descubra cómo puede convertirse en desarrollador certificado de IBM en XML y otras tecnologías relacionadas.
  
  
• Biblioteca técnica de XML: visite la zona XML de developerWorks y encuentre una amplia variedad de artículos técnicos y consejos, instructivos, normas y libros rojos de IBM.
  
  
• Eventos técnicos y webcasts de developerWorks: manténgase actualizado en tecnología con estas sesiones.
  
  
• Postcasts de developerWorks: escuche entrevistas y debates interesantes para los desarrolladores de software.
  
  

Obtener los productos y tecnologías

• Cloudberry Explorer: pruebe un cliente de Windows®gratuito para Amazon S3.
  
  
• SmugMug: visite el sitio Web para compartir fotografías que utiliza Amazon S3 como facilidad de almacenamiento back-end.
  
  
• Versiones de evaluación de los productos IBM: Descargue o explore las pruebas online de SOA Sandbox de IBM y maneje las herramientas de desarrollo de aplicaciones y productos middleware de DB2®, Lotus®, Rational®, Tivoli®, y WebSphere®.
  
  

Comentar

• Participar en el foro de debate.
  
  
• Foro de discusión de la zona XML: participe en cualquiera de las numerosas discusiones relacionadas con XML.
  
  
• Blogs de developerWorks: analice estos blogs y sea parte de lacomunidad de developerWorks.
  
  

Sobre el autor

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Introducción
• Lecciones de la gobernabilidad de SOA
• Es un proceso y no un producto
• Nubes encubiertas
• ¿Está la gobernabilidad del lado del cliente ausente sin aviso?
• Aplicar controles a la aplicación HybridCloud
• Amazon S3
• Google Apps
• Force.com: Salvaguardas y “pruebas sobre la marcha”
• Resumen
• Recursos
• Sobre el autor
• Comentarios