Llegamos a ustedes gracias a:



Columnas de opinión

Las dos grandes mentiras sobre seguridad en la nube

Por: Bernard Golden, CEO de la firma de consultoría HyperStratus

[21/06/2011] Encuesta tras encuesta demuestra que la seguridad es la mayor preocupación que tienen los potenciales usuarios con respecto a la nube pública. Aquí, por ejemplo, está una encuesta de abril del 2010, que indica que el 45% de los encuestados consideró que los riesgos del cloud computing son mayores que sus beneficios. CA y el instituto Ponemon realizaron una encuesta con resultados similares. Pero también encontraron que el despliegue se había producido a pesar de estas preocupaciones. Y se siguen publicando encuestas con resultados similares, indicando la desconfianza que persiste acerca de la seguridad.

La mayor parte de las preocupaciones expresadas acerca de la computación en nube se refieren a la variante pública. Los profesionales de TI en todo el mundo plantean constantemente las mismas preocupaciones sobre el uso de un proveedor de servicio de nube pública (CSP por sus siglas en inglés). Por ejemplo, dos semanas atrás -durante el Taiwan Cloud SIG- me preguntaron: "¿El cloud computing público es lo suficientemente seguro, y no debería utilizar una nube privada para evitar problemas de seguridad?" La gente en todas partes, al parecer, considera que los CSP públicos no son de fiar.
Sin embargo, enmarcar la discusión de seguridad en la nube bajo la premisa de la "nube pública es insegura y la nube privada es segura", indica una caracterización demasiado simplista. En pocas palabras, hay dos grandes mentiras (o, más caritativamente, dos malentendidos fundamentales) en ese punto de vista, que tienen su origen en los cambios radicales que trajo este nuevo modo de computación a los productos y prácticas de seguridad.
Servicio cloud, mentira # 1
La primera gran mentira es que la computación en nube privada es, por definición, segura solamente por el del hecho de que se implementa dentro de los límites del propio centro de datos de una empresa. Este malentendido surge del hecho de que la computación en nube tiene dos diferencias clave con la informática tradicional: la virtualización y el dinamismo.
La primera diferencia es que la base tecnológica de cloud computing se basa en la presencia de un hipervisor, que tiene el efecto de aislar la informática (y las amenazas de seguridad complementarias) de una de las herramientas tradicionales de seguridad: el examen de tráfico de la red para los paquetes inapropiados o maliciosos. Debido a que las máquinas virtuales que residen en el mismo servidor pueden comunicarse a través del tráfico dentro del hipervisor, los paquetes pueden ser enviados desde una máquina a otra sin tener que golpear a una red física, que es donde los aparatos de seguridad se suelen instalar para examinar el tráfico.
Fundamentalmente, esto significa que si una máquina virtual se ve comprometida, se puede enviar el tráfico peligroso a otra sin las típicas medidas de protección. En otras palabras, una aplicación insegura puede comunicar ataques a otra sin dar oportunidad a que las medidas de seguridad de la organización entren en juego. El hecho de que las aplicaciones de una organización residan dentro de una nube privada, no las protege contra este problema de seguridad.
Por supuesto, uno podría señalar que esta cuestión está presente con la virtualización en sí misma, sin involucrar ningún aspecto de la computación en la nube. Esta observación es correcta. La computación en nube representa el matrimonio de la virtualización con la automatización, y es en este segundo elemento de seguridad que emerge otro defecto de las nubes privadas.
Las aplicaciones de cloud computing se benefician de esta automatización para lograr agilidad y elasticidad -la capacidad de responder a las cambiantes condiciones de las aplicaciones al mover máquinas virtuales de forma rápida y haciendo girar las máquinas virtuales adicionales para gestionar cambios en los patrones de carga. Esto significa que los casos nuevos están en línea en unos pocos minutos sin ninguna interacción manual. Esto implica que cualquier instalación de software o configuración necesaria, también deben ser automatizados para que cuando la nueva instancia se una al grupo de aplicaciones existentes, pueda ser inmediatamente utilizada como un recurso.
También implica que cualquier software de seguridad requerido deberá, asimismo, instalarse y configurarse automáticamente sin la interacción humana. Desafortunadamente, muchas organizaciones confían en el personal de seguridad o los administradores de sistemas para instalar y configurar manualmente los componentes necesarios de seguridad -a menudo como un segundo paso después de que el resto de componentes de software de la máquina están instalados y configurados.
En otras palabras, muchas organizaciones tienen un desajuste entre sus prácticas de seguridad y la realidad de lo que requiere la nube. Suponiendo que una nube privada es, ipso facto, segura, no es correcto. Hasta que su seguridad y las prácticas de la infraestructura no se alineen con las instancias automatizadas, tendrá una vulnerabilidad.
Por otra parte, es fundamental alinearlos. De lo contrario, se enfrenta a la posibilidad de que la automatización de aplicaciones supere sus prácticas de seguridad, lo que no es una buena situación. Por supuesto, a uno no le gustaría estar en la posición de tratar de explicar por qué la nube privada supuestamente segura, terminó exponiendo una vulnerabilidad debido a que las características de automatización de la computación en la nube no se habían extendido por todas las partes de la infraestructura de software.
Así, la primera gran mentira sobre la computación en la nube es que las cloud privadas son intrínsecamente seguras. ¿Cuál es la segunda?
Seguridad en la nube, mentira # 2
La segunda mentira acerca de la seguridad de cloud computing se refiere a los supuestos acerca de la seguridad en la nube pública; específicamente, la hipótesis de que la seguridad en la nube pública reside únicamente en el CSP. La realidad es que esa seguridad en un mundo de servicios es una responsabilidad compartida entre el proveedor y el usuario, con el ex responsable de seguridad en la infraestructura a través del punto de interconexión entre la aplicación y el entorno de alojamiento, y el usuario responsable de la seguridad con respecto a interactuar con el medio ambiente, y sobre todo, dentro de la propia aplicación.
El no poder configurar la aplicación correctamente con respecto a la interfase de seguridad o no tomar las precauciones de seguridad al nivel de aplicación expone al usuario a cuestiones sobre las que ningún proveedor, posiblemente, pueda asumir responsabilidad.
Permítanme un ejemplo. Una empresa con la que trabajamos había colocado su aplicación principal en Amazon Web Services. Por desgracia, no había aplicado prácticas de seguridad apropiadas con respecto a cómo utilizar mecanismos de seguridad AWS, ni con simples cuestiones de diseño de aplicaciones.
Amazon ofrece lo que es, en efecto, una máquina virtual a nivel de servidor de seguridad (llamado un grupo de seguridad) que se configura para permitir que los paquetes accedan a puertos específicos. La mejor práctica con respecto a los grupos de seguridad es la partición, de modo que el acceso (de grano fino) a puerto esté disponible por máquina virtual. Esto asegura que solo el tráfico apropiado para ese tipo de máquina vaya a una instancia. Por ejemplo, los servidores web de las máquinas virtuales están configurados para permitir el tráfico en el puerto 80 de la instancia, mientras que las máquinas virtuales de bases de datos están configuradas para no permitir el tráfico en el puerto 80 de la instancia. Esto bloquea los ataques a las instancias de base (que contienen los datos esenciales de la aplicación) desde el exterior usando el tráfico de Internet.
Para construir una aplicación segura, se debe utilizar grupos de seguridad correctamente. Esta organización no lo había hecho. Utilizó un grupo de seguridad para todo el tráfico hacia todas las instancias, lo que significaba que cada tipo de instancia estaba expuesta a cualquier tipo de tráfico destinado a cualquier instancia. Claramente, un mal uso de los mecanismos de seguridad AWS.
En cuanto a la aplicación de la organización; había implementado prácticas de seguridad pobres. En lugar de dividir el código de aplicación entre los diferentes tipos de máquinas, había cargado todo el código de la aplicación en una sola instancia, lo que significó que la misma instancia que recibía el tráfico de su web corporativa, también de contenía códigos de algoritmos propietarios ejecutándose sobre ella.
Lo importante de esta situación: si esta organización asumía que toda la responsabilidad de la seguridad caía en la CSP (Amazon Web Services, en este caso), hubiera sido extremadamente negligente, porque no había tomado medidas importantes para abordar las cuestiones de seguridad para los asuntos en que la CSP no era responsable. Esto es lo que implica la responsabilidad compartida, ambas partes tienen que intensificar los aspectos de seguridad bajo su control, y no hacerlo significa que la aplicación no va a ser segura. Incluso si el CSP hace todo correctamente para partes de la aplicación de nubes bajo su control, si el propietario de la aplicación no implementa adecuadamente su seguridad, la aplicación va a ser insegura.
He estado en reuniones con personal de seguridad discutiendo sobre la seguridad pública CSP, quienes se negaron a considerar la responsabilidad de su empresa en estos ambientes, insistiendo en la reorientación de todos los temas de seguridad hacia las preocupaciones acerca de la responsabilidad del CSP.
Esto me pareció, francamente, imprudente, pues insinuaba la negativa a lidiar seriamente con el trabajo necesario para la creación de una CSP pública tan segura como sea posible. Era como si la actitud de toda la responsabilidad en seguridad recayera en la CSP, aislando a la persona de seguridad y, por extensión, a su empresa, de cualquier responsabilidad por las fallas de seguridad en una aplicación que se ejecuta en un entorno de CSP. No deja de sorprender que el individuo en cuestión fuera un firme defensor de las nubes privadas, afirmando su superior seguridad intrínseca.
La realidad es que las organizaciones están implementando cada vez más aplicaciones en entornos CSP públicos. Es vital que los grupos de seguridad den un paso adelante para garantizar que sus organizaciones tomen todas las medidas posibles para implementar aplicaciones que sean tan seguras como sea posible, y eso significa qué medidas tiene que tomar la organización al respecto.
La seguridad es, por así decirlo, el tercer carril de la computación en la nube. Es constantemente citada como una ventaja inherente de las nubes privadas y una carencia fundamental de las nubes públicas. En realidad, la verdad es mucho más ambigua de lo que implican estas afirmaciones. Afirmar las deficiencias de seguridad putativas de los entornos cloud públicos sin considerar seriamente la manera de mitigarlos, parece irresponsable y evidencia la creencia de que la afirmación implica el rechazo a la necesidad de seguir investigando en técnicas de mitigación.
Una aplicación de nube privada mal administrada y configurada puede ser muy vulnerable, y una aplicación de nube pública debidamente administrada y configurada puede lograr una muy buena seguridad. Enfrascar la situación como blanco y negro es simplista, y hace un flaco favor a la discusión.
En ambos ambientes es mucho más productivo consultar las medidas que deben adoptarse para lograr que una aplicación sea tan segura como sea posible, dentro de las limitaciones de tiempo, presupuesto y tolerancia al riesgo. La seguridad nunca es una cuestión de blanco o negro, sino más bien una cuestión de qué tan clara puede ser una sombra, teniendo en cuenta las particularidades de un entorno y aplicación específicos. No reconocer esto es un flaco favor al tema, y a cómo asegurar la infraestructura de la organización de la mejor manera posible.
CIO (US)
Bernard Golden es CEO de la firma de consultoría HyperStratus, que se especializa en la virtualización, el cloud computing y temas relacionados. Él es también el autor de "La virtualización para dummies", el libro más vendido sobre virtualización a la fecha.