Servicios en la nube: mitigar riesgos, mantener la disponibilidad

Mantener la disponibilidad en un entorno en la nube mediante la política de seguridad del servicio en la nube

Los organismos gubernamentales y las empresas demandan servicios en la nube para proporcionar una mejor seguridad con el fin de garantizar una disponibilidad operacional continua. Para que esto se haga realidad, necesitan formular una política de servicio en la nube sobre la mitigación del riesgo. Obtenga más información sobre la seguridad del servicio en la nube y cómo mitigar los riesgos de los servicios en la nube para garantizar la disponibilidad del tiempo de funcionamiento y la seguridad en un entorno en la nube.

Judith M. Myerson, Arquitecta e ingeniera en sistemas, IBM

Judith M. Myerson es una arquitecta e ingeniera en sistemas. Sus áreas de interés incluyen sistemas en toda la empresa, tecnologías de middleware, tecnologías de base de datos, computación en nube, políticas de umbral, industrias, gestión de red, seguridad, tecnologías de RFID, gestión de presentación y gestión de proyectos.



24-12-2012

Las políticas de seguridad del servicio en la nube se centran en diferentes aspectos de la seguridad en la nube, según el esquema modelo de envío al que se refiera — SaaS, PaaS o IaaS:

  • La política del Software como Servicio (SaaS) se centra en la administración del acceso a una aplicación rentada para los consumidores, ya sean individuos particulares, empresas u organismos gubernamentales. Debería tratar los riesgos de mitigación de las aplicaciones SaaS que son vulnerables a un ataque por una aplicación maligna que distribuye recursos de instancias maliciosas. Por ejemplo, las horas laborales designadas en las que la aplicación permite a los asistentes dentales autorizados descargar los registros dentales podrían cambiarse de forma maliciosa a primera hora del día según la conveniencia de los piratas informáticos.
  • La política de la Plataforma como un Servicio (PaaS) se centra en la protección de datos y en la gestión del acceso a las aplicaciones en un ciclo comercial completo creado y alojados por proveedores independientes de software, inicios de sesión o unidades de grandes empresas. La política debería tratar la mitigación de los riesgos de la PaaS utilizada como centros de Comando y Control con el propósito de dirigir las operaciones de un botnet para el uso en la instalación de aplicaciones maliciosas, es decir, para generar confusiones en los registros dentales.
  • La política de la Infraestructura como un Servicio (IaaS) se centra en la administración de máquinas virtuales, en la protección de datos y en la gestión del acceso a la infraestructura de estos recursos informáticos tradicionales que se encuentran de forma subyacente en las máquinas virtuales en el entorno de la nube. Esta política debería tratar el marco de gobernabilidad sobre los riesgos de mitigación para las máquinas virtuales. IaaS se ha utilizado como centros de Comando y Control para dirigir operaciones de un botnet para el uso en actualizaciones maliciosas de la infraestructura dentro y a través de las máquinas virtuales.

Este artículo abarca a grandes rasgos los aspectos importantes de cuestiones sobre la seguridad del servicio en la nube y describe la mitigación de los riesgos que son parte de un programa de evaluación de riesgos.

Seguridad de los servicios en la nube

La seguridad del servicio en la nube puede verse amenazada por:

  • Un hypervisor deficiente
  • Políticas faltantes del umbral
  • Equilibrio de carga hinchada
  • Criptografía insegura

Analicemos cada una con más detalles

Hypervisor deficiente

Todos los tipos de servicios en la nube se ejecutan en máquinas virtuales sobre un hypervisor subyacente que permite a varios sistemas operativos compartir un solo host de hardware. Acceden a ellos partes de diferentes niveles de confiabilidad: usuarios, inquilinos o administradores del la nube. Por ejemplo, un inquilino podría tener un acuerdo de licencia de 1000 usuarios para acceder a ciertos software como servicios.

Cuando un hypervisor es deficiente o está comprometido, todos los recursos de las instancias y las colas de solicitud de datos están comprometidas. Pueden impactar de forma maliciosa en las políticas de umbral [leer más] que se utilizan para supervisar el consumo de recursos de instancia y las colas de solicitud de datos durante los aumentos en la demanda para la carga de trabajo. Los controles de las redes virtuales internas que se utilizan para comunicarse entre las máquinas virtuales no son lo suficientemente visibles como para hacer cumplir las políticas de seguridad. Las tareas para los controles de la red y de la seguridad de las máquinas virtuales podrían no estar bien separadas.

Un pirata informático podría convertirse en un usuario muy privilegiado con los controles administrativos y salir de una máquina virtual y, luego, ejecutar programas maliciosos en el hypervisor. Por ejemplo, podría acceder a archivos del directorio y a recursos de instancias de re asignación maliciosa a otra máquina virtual. Puede causar la falla en los mecanismos que separan el almacenamiento, la memoria, el enrutamiento y la reputación entre los mismos inquilinos en la misma máquina virtual.

El pirata informático puede robar información sensible de datos residuales provenientes de recursos de instancias re distribuidas y que no se purgaron dentro de una máquina virtual. El pirata informático puede utilizar un hypervisor deficiente para identificar los vecinos de una máquina virtual en buenas condiciones y supervisar su actividad. Puede entrar en la máquina virtual de un vecino y agregar un código malicioso a las aplicaciones PaaS.

Políticas faltantes del umbral

Un usuario final debería evaluar la política de seguridad de un proveedor de servicios antes de entablar una relación. Necesita comparar la postura de seguridad de la computación en la nube con un entorno físico y asegurarse de que no falten en la política de seguridad el recurso de instancia, el usuario y las políticas del umbral de solicitud de datos.

Una política de umbral de recursos es útil para la supervisión de cómo se consumen recursos de instancias adicionales durante los aumentos de las demandas para las cargas de trabajo. Una política de umbral del usuario controla cuántos usuarios están conectados de forma concurrente y cuántos no en un tipo de servicio en la nube y si alcanzan la cantidad máxima de usuarios como se lo especifica en la licencia.

Existen riesgos si no se establecen estas políticas:

  • Sin una política de umbral de recursos, no sabe si los recursos de instancias alcanzaron de forma maliciosas la capacidad completa e hicieron que su proveedor de servicios en la nube corte el servicio sin advertencias previas.
  • Sin una política de umbral del usuario, no sabe si el número de usuarios concurrentes está alcanzando el máximo y cuántos usuarios no cerraron sesión cuando terminen con el servicio en la nube. Los piratas informáticos pueden identificar a esos usuarios.
  • Sin una política de umbral de solicitud de datos, no conoce el tamaño de la cola de las solicitudes de datos. Los piratas informáticos pueden desbordar las colas con solicitudes de datos maliciosos (como solicitudes inyectadas de SQL)

Equilibrio de carga hinchada

El equilibrio de la carga se utiliza para distribuir los recursos de instancias y las solicitudes de datos. Por ejemplo, cada recurso de instancia debería cargarse hasta en un 50 por ciento de su capacidad, entonces si falla una instancia, las que están en buenas condiciones toman el control de las transacciones comerciales de la instancia fallida de recursos.

Cada cola debería cargarse con solicitudes de datos de hasta un 50 por ciento de la capacidad de la cola, entonces cuando una cola falla, las que están en buenas condiciones toman el control de las solicitudes de datos destinadas originalmente para la cola fallida.

Cuando el equilibrio de carga de los recursos de instancias presenta deficiencias maliciosas por parte de una aplicación de malware en una máquina virtual, puede causar un desbordamiento de esos recursos con transacciones maliciosas que cubran cada recurso hasta el 100 por ciento de su capacidad.

Es imposible trasladar las transacciones comerciales desde las instancias de recursos fallidas a las que están en buenas condiciones. El equilibrio de carga excedido no puede utilizarse para implementar mecanismos de sistemas de recuperación de fallos, como un recurso de instancia o la redundancia de compartir la carga.

Criptografía insegura

Se necesita algún tipo de cifrado para proteger la confidencialidad y la integridad de los datos. Incluso si los datos no son sensibles ni personales, deberían asegurarse con criptografía cuando se los traslada o manipula en la nube.

Los piratas informáticos pueden tomar ventaja de los avances en el criptoanálisis o en los recursos de instancias maliciosas para volver inseguros los algoritmos criptográficos. Pueden investigar las deficiencias en un algoritmo criptográfico antes de modificarlo de forma maliciosa para convertir un cifrado fuerte en uno débil.

Los piratas informáticos pueden ir más allá al descubrir la última versión de los algoritmos criptográficos y luego en sus propias máquinas desarrollar una ingeniería inversa para saber cómo funcionan los algoritmos.


Mitigación de los riesgos para los servicios en la nube

Puede mitigar los riesgos de forma rentable al aplicar controles de seguridad para disminuir las probabilidades de que puedan explotarse las vulnerabilidades del bien y derivar en la implementación de amenazas.

Antes de que intente mitigar los riesgos, necesita identificar los bienes a ser protegidos. La evaluación de riesgos más simple consiste en lo siguiente:

  1. Identificar los bienes
  2. Analizar los riesgos
  3. Aplicar contramedidas de seguridad
  4. Realizar evaluaciones de incidentes o de posejecución

Un concepto clave que hay que recordar es que puede retornar a través de los pasos en cualquier etapa para incorporar las variables que se agregaron más tarde o que no conocía.

Comience con la identificación de los bienes — el hardware, el software, los componentes de red, el personal, los usuarios, la documentación, las instalaciones; esos y otros bienes que formen parte directa del tipo de servicio en la nube. Cuando los identifique, intente mitigar los riesgos y descubra que ha excluido determinados bienes, puede regresar al primer paso para actualizar el inventario de activos y luego repetir el segundo paso.

Si, durante el tercer paso del análisis de las contramedidas de seguridad, descubre que no se trataron ciertos riesgos, puede regresar al segundo paso para incluirlos y para determinar el potencial perdido y las probabilidades de cada riesgo de que una amenaza explotaría las vulnerabilidades. Puede regresar al primer paso desde el tercero para actualizar un inventario de activos para protegerlo.

En el cuarto paso, vuelve a evaluar de forma periódica el programa de evaluación de riesgos sobre su impacto en los nuevos riesgos, los controles rentables de seguridad, las tecnologías emergentes de infraestructura y las nuevas legislaciones.

Analicemos cada paso con más detalle.

Paso 1: Identificar los bienes

Tanto el consumidor de la nube como el proveedor necesitan identificar los bienes de hardware y software, y estimar el costo para remplazar cada bien. Deberían mantener y actualizar con frecuencia un inventario de activos que pueda cambiar como resultado de la reestructuración de la organización, más tecnologías eficientes en el consumo de energía y nuevas legislaciones sobre exportaciones de la privacidad de los datos a través de los límites de las jurisdicciones.

La cantidad de bienes de hardware y de software que un usuario necesita identificar cuando alquila un servicio de un proveedor de SaaS es mucho más inferior que cuando un consumidor tiene más control al utilizar el modelo de la PaaS y, en mayor medida, la IaaS.

Ahora, analicemos los bienes que necesitan identificarse para cada tipo de servicio en la nube.

Bienes del SaaS
Dado que el único control que tiene el consumidor en la nube es el acceso a la aplicación desde su escritorio, computadora portátil o un dispositivo móvil, los bienes que necesita identificar son sistemas operativos de dispositivos móviles, aplicaciones y programas predeterminados. Por este motivo, es importante limitar su inventario de bienes de dispositivos a programas y aplicaciones para utilizarlos con SaaS. No es una buena idea mezclar los programas para uso personal (como juegos descargados) con programas a los que necesita acceder SaaS en el mismo dispositivo.

Como mínimo, un proveedor en la nube debería controlar los siguientes bienes:

  • Sistemas operativos
  • Hardware
  • Infraestructura de redes
  • Aplicaciones de gestión de acceso
  • Recursos de instancias
  • Actualizaciones de la aplicación del SaaS y parches

El consumidor no es responsable de identificarlos.

Bienes de la PaaS
Los bienes que necesita identificar el consumidor en la nube son los que puede controlar: Todas las aplicaciones que se encuentran en un ciclo de vida comercial completo para la plataforma (por ejemplo, hojas de cálculo, procesadores de texto, copias de seguridad, facturación y procesamiento de nóminas).

Como mínimo, un proveedor en la nube debería controlar los siguientes bienes en una configuración de la PaaS:

  • Sistema operativo
  • Hardware
  • Infraestructura de redes
  • Recursos de instancias

El consumidor en la nube no es responsable de identificar los bienes.

Bienes de la IaaS
Los bienes que necesita identificar el consumidor en la nube son los que puede controlar: Los sistemas operativos, los equipos de red y las aplicaciones implementadas a nivel virtual de la máquina. El consumidor puede aumentar o disminuir la cantidad de recursos de instancias y servidores virtuales o bloques de áreas de almacenamiento.

El consumidor en la nube no puede controlar la infraestructura y los componentes subyacentes. El proveedor necesita identificar esos activos.

Paso 2: Analizar los riesgos

Un riesgo es el potencial de pérdidas o la probabilidad de que una amenaza explote las vulnerabilidades de un servicio en la nube. Si no se encuentran vigentes contramedidas rentables, el servicio en la nube es susceptible a las vulnerabilidades que podrían lanzar una amenaza si se las explota.

El potencial de pérdidas de riesgos para los bienes depende del impacto de un riesgo para cada bien (es decir, entre ninguno o cero para los bienes de documentación que siempre se encuentran disponibles para los usuarios y una alta calificación de 0,96 para los bienes de los recursos de instancias en el entorno en la nube sin las contramedidas adecuadas). El potencial de pérdidas de riesgos para los activos también depende de cuán frecuente pueda realizarse la amenaza en un marco de tiempo de un año.

Cómo pueden explotarse las vulnerabilidades
Analicemos un ejemplo simple de cómo pueden explotarse de forma colectiva las siguientes vulnerabilidades por un pirata informático para lanzar un ataque contra los bienes de los recursos de instancias. Las vulnerabilidades son las siguientes:

  • El módulo del umbral que falta de la aplicación
  • Los datos residuales dentro de los recursos de instancias
  • Los controles de red insuficientes en redes virtualizadas
  • La supervisión inadecuada del usuario privilegiado

Una buena aplicación se divide en módulos que interactúan entre sí para realizar una tarea o secuencia de tareas; esto hace que sea más fácil para un desarrollador agregar un módulo a una aplicación al volver a utilizar el módulo existente o al agregar otros nuevos. Cuando a una aplicación le falta un módulo del umbral — establecido por debajo de la capacidad máxima de los recursos de instancia y otro nivel para las solicitudes de datos — el consumidor y el proveedor no tienen forma de saber si los recursos de instancias o las solicitudes de datos alcanzaron la capacidad máxima. No saben si e pirata informático creó la máquina virtual maliciosas en el mismo servidor físico que aloja las máquinas virtuales que están en buenas condiciones hasta que es demasiado tarde (por ejemplo, hasta que tiene lugar una negación del ataque del servicio). El pirata informático logra esto al desbordar los vecinos maliciosos de la máquina virtual con recursos de instancias maliciosas y con colas de solicitud de datos maliciosos. Atrae a la víctima para que aumente la cantidad de máquinas virtuales hasta que alcanzan la capacidad máxima del servidor físico.

Los datos residuales tienen lugar cuando los recursos de instancias previamente distribuidos no se purgan de los datos en su totalidad antes de que se los vuelva a distribuir para el mismo usuario o para uno diferente. Los recursos de instancias incluyen memoria, caché, procesos, sesiones, umbrales y recursos de almacenamiento. El pirata informático busca recursos de instancias interiores para obtener información personal de una víctima.

Los controles de red insuficientes en redes virtualizadas tienen lugar cuando los controles de seguridad que funcionan a nivel de la red podrían no funcionar en una infraestructura de red de la IaaS. Esto limita el acceso del administrador autorizado a la infraestructura. El pirata informático toma ventajas del hecho de que el administrador de la IaaS no pueda aplicar los controles estándar, como por ejemplo la zonificación de redes basadas en IP en redes virtualizadas. Los proveedores de la IaaS podrían no permitir el escaneo de la vulnerabilidad basada en la red dado que no tienen forma de distinguir los escaneos redes inocuos desde la actividad de ataque. También hay insuficientes controles para distinguir el tráfico en las redes reales desde las redes virtualizadas (por ejemplo, la comunicación entre dos o más máquinas virtuales por sobre el hypervisor en el mismo servidor).

La supervisión inadecuada del usuario privilegiado tiene lugar cuando el proveedor supervisa de forma inapropiada las actividades maliciosas realizadas por un pirata informático que accedió a las máquinas virtuales desde el hypervisor como un usuario privilegiado con controles administrativos de acceso. Por ejemplo, un pirata informático con este acceso puede crear recursos de instancias maliciosas y colas de solicitudes de datos sin que el proveedor se dé cuenta de lo que está haciendo. Otro ejemplo consiste en reasignar de forma maliciosa los recursos de instancias desde un recurso de instancia en buenas condiciones desde una máquina virtual como recursos de instancias maliciosas a otra máquina virtual.

Una clasificación potencial de la seriedad de los ataques
Por supuesto que tiene que desarrollar su propio sistema o potencial de clasificación de pérdidas de los diferentes tipos de ataques, pero yo clasifico el potencial de pérdidas de los ataques en el orden de prioridad siguiente:

  • Cómo puede ingresar un pirata informático
  • Qué está buscando
  • Qué herramientas tiene

Por ejemplo, un pirata informático puede ingresar como un usuario privilegiado con los controles de acceso administrativo y realizar actividades maliciosas que un administrador del sistema legítimo no puede notar inicialmente. El pirata informático también puede ingresar al enviar inyecciones SQL para encontrar los nombres de los archivos y puede buscar los datos residuales en esos archivos.

Una vez que ingresó en una máquina virtual, puede usar una herramienta del pirata informático para lanzar la actividad maliciosa de ataque del escaneo de la red actuando como escaneos inocuos de red. La actividad de ataque puede incluir la lista de los módulos dentro de cada aplicación. Si el pirata informático descubre que la aplicación no contiene los módulos del umbral, puede utilizar o crear una herramienta con el fin de diseñar recursos de instancias hasta que alcance la capacidad máxima.

Paso 3: Aplicar contramedidas de seguridad

El paso siguiente en la evaluación de riesgos es relativamente sencillo en concepto, como muchas cosas, un poco más difícil en la vida real — para descubrir si las contramedidas para mitigar los riesgos son rentables, entonces los beneficios son superiores que los costos de implementación de las contramedidas. La probabilidad de los riesgos que amenaza atacará, las vulnerabilidades disminuyen y el ROI aumenta.

El punto siguiente es importante: Si se considera que una contramedida es rentable, los riesgos residuales se mantienen y estos riesgos no pueden mitigarse. Necesita aprender a vivir con ellos y a no gastar más dinero en ellos. Este es uno de los conceptos más duros para alcanzar la evaluación/mitigación de riesgos: Que algunos riesgos son demasiado costosos como para mitigar los beneficios que proporciona.

Sin embargo, si existen muchos riesgos residuales y demasiado pocas contramedidas rentables, debería repetir los pasos de la evaluación de riesgos por varios motivos:

  • Si este es uno de sus primeros intentos en la mitigación/evaluación de los riesgos, probablemente desee repetir el ejercicio algunas veces para pulir sus habilidades en la identificación de activos, el análisis y el conocimiento de los riesgos y la determinación del alcance total y la profundidad de las contramedidas potenciales y las diversas maneras en las que se las aplica.
  • También desea mantenerse alerta por las nuevas contramedidas y las tecnologías de infraestructura en la nube que proporcionan más beneficios que su costo.
  • De forma alternativa, debería considerar comprar seguros para transferir algunos riesgos residuales si es que es más barato que implementar una contramedida.

Algunos ejemplos de contramedidas que mencioné en este artículo incluyen:

  • Garantizar los recursos de instancias, el usuario y las políticas de umbral de la solicitud de datos que se encuentran vigentes.
  • Purgamiento de datos residuales desde recursos de instancias antes de su re distribución.
  • Implementación de planes para mecanismos de recuperación de fallas, la continuidad comercial y la recuperación ante desastres.
  • Supervisión de usuarios privilegiados; control del trasfondo y de las actividades de registro de estos usuarios y las condiciones del los servidores físicos de supervisión y otros componentes de la infraestructura.
  • Educación de los consumidores y de los proveedores sobre los beneficios de la mitigación de riesgos y las contramedidas.

Paso 4: Conducir evaluaciones posteriores

Mientras que la evaluación de los riesgos debería realizarse de forma periódica cada tres años, los riesgos podrían necesitar volver a evaluarse con más frecuencia si se producen las condiciones siguientes:

  • Surgimiento de nuevas tecnologías de servicio en la nube que pueden impactar en el software, el hardware y en los bienes de la red.
  • Surgimiento de nuevas vulnerabilidades y amenazas.
  • Nuevas contramedidas disponibles que pueden mitigar de forma efectiva los riesgos anteriormente categorizados como residuales.
  • Se concibe un enfoque de mitigación de riesgos.
  • Fuertes impactos que resultan de cambios organizacionales (como fusión) de los bienes en todas las categorías.
  • Cambios notorios en la legislación y en las normativas de cumplimiento en las diversas jurisdicciones.

De hecho, si está a cargo del manejo de la evaluación y la mitigación de riesgos para los servicios en la nube de su organización, probablemente, debería buscar una vez por semana en el flujo de datos información sobre estas condiciones. Considerar establecer una fuente de noticias para nuevas amenazas y vulnerabilidades.


En conclusión

La mitigación de los riesgos para los servicios en la nube mientras se mantiene una alta disponibilidad de tiempo de funcionamiento requiere de una planificación de riesgos proactiva con el propósito de resolver las cuestiones de qué bienes identificar para cada tipo de nube, qué riesgos hay que analizar, qué contramedidas son rentables y qué hay que evaluar después de que se mitigan los riesgos. Su equipo de desarrolladores, usuarios y analistas comerciales necesitan trabajar juntos para reducir el riesgo residual para los servicios de la nube. El equipo descubrirá que resolver las cuestiones hará mucho más fáciles sus trabajo de mitigación de riesgos para los servicios en la nube.

Recursos

Aprender

Obtener los productos y tecnologías

  • Vea las imágenes de productos disponibles en IBM Smart Business Development and Test en la nube de IBM Cloud.

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=Cloud computing, SOA y servicios web
ArticleID=853046
ArticleTitle=Servicios en la nube: mitigar riesgos, mantener la disponibilidad
publish-date=12242012