Conexión a la nube, Parte 3: La gobernabilidad y seguridad de la nube

Asegurar la aplicación HybridCloud

En la tercera y última parte de esta serie de tres partes sobre la construcción de una aplicación de nube híbrida, analizamos la gobernabilidad y seguridad de la computación en nube (cloud computing). Sobre la base del ejemplo de la aplicación HybridCloud de la parte 2, aprenderemos a agregar políticas de control de acceso para el servicio Amazon SQS (Simple Queue Service). Además, analizaremos en detalle cómo la aplicación HybridCloud se autentica a sí misma para los servicios de nube y cómo agregar una pista de auditoría de registro a S3 de Amazon (correspondiente a las tres “S” de los vocablos ingleses Service (servicio), Storage (almacenamiento), Simple (simple), Servicio Simple de Almacenamiento). Por último, veremos cómo las aplicaciones de Google utilizan OAuth y de qué manera los servicios de nube de Force.com requieren pruebas incorporadas para evitar ataques DoS (Denegación de Servicio) involuntarios.

Mark O'Neill, CTO, Vordel

Mark O'Neill is Director de Tecnología (CTO) de Vordel, compañía de redes de XML. Además, es autor del libro "Web Services Security" y co-autor de "Hardening Network Security", ambos publicados por McGraw-Hill/Osborne Media. En Vordel, Mark es responsable de supervisar el mapa de ruta de desarrollo de productos y además es consultor en la adopción táctica y estratégica de XML, servicios web y tecnologías de SOA para empresas y gobiernos de Global 2000 a nivel mundial. Posee un título en matemática y psicología de Trinity College Dublin y se graduó en programación de redes neurales en la Universidad de Oxford. Marks vive en Boston, Massachusetts.



04-08-2011

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.


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).

Siglas utilizadas con frecuencia

  • API: Interfaz de programación de aplicaciones
  • DSA: Algoritmo de firma digital
  • IP: Protocolo de Internet
  • IT: Tecnología informática
  • REST: Transferencia de estado representacional
  • SOA: Arquitectura orientada a servicios
  • SSL: Capa de protección segura
  • URI: Identificador universal de recursos
  • WSDL: Lenguaje de descripción de servicios web
  • XML: Lenguaje extensible de marcas

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.


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.


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.


¿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.


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.

¿Qué significa RSA?

Las letras "RSA" que integran el nombre del algoritmo de encriptado asimétrico RSA significan "Rivest, Shamir, Adleman", que son las personas que escribieron por primera vez sobre el algoritmo.

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 sector de almacenamiento, tal como se lo definió en Amazon S3, es sencillamente un contenedor de almacenamiento para archivos. Para definir el espacio que necesitará en Amazon S3, usted tendrá que crear un sector de almacenamiento y darle un nombre que será único en todo el sistema de Amazon.

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).

Listado 1. Examen de una política de Amazon SQS
                {"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.

Listado 2. Definición de políticas para controlar el acceso a la cola SQS
                "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.


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.


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.


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.


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

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Lotus, SOA y servicios web
ArticleID=412526
ArticleTitle=Conexión a la nube, Parte 3: La gobernabilidad y seguridad de la nube
publish-date=08042011