Ciberseguridad en entornos cloud
Introducción a cloud computing
En muchos ámbitos de nuestra vida personal y profesional nos hemos acostumbrado a contratar un servicio en lugar de a adquirir un producto, es decir, a ser consumidores o suscriptores en lugar de propietarios. Esta evolución también se ha producido en el sector tecnológico a través de un nuevo paradigma: el cloud computing (o computación en la nube).
Este paradigma ha permitido, por fin, a todo tipo de empresas tecnológicas convertirse en proveedoras de servicios TIC que permiten a sus clientes consumir estos servicios como lo hacen con otros suministros tradicionales (la luz, el agua o el gas, por poner sólo algunos ejemplos). Por este motivo se habla en ocasiones del utility computing. Esto ha sido posible gracias a la combinación de tecnologías y paradigmas que ya existían como el Grid Computing, SOA (Service Oriented Architecture) o la virtualización. Es decir, el nuevo paradigma no es tanto una revolución como una evolución posibilitada por esta combinación de tecnologías y por la industrialización de las TIC, que permiten a un proveedor aprovechar la economía de escala ofertando a sus clientes precios competitivos gracias a la compartición de los recursos que el paradigma permite realizar.
La definición que proporciona NIST (National Institute of Standards and Technology del US Department of Commerce) es quizás una de las más completas y extendidas. Según este organismo, cloud computing es un modelo que permite acceso remoto, según nuestras necesidades y bajo demanda, y a través de una red de comunicaciones, a un conjunto compartido de recursos de cómputo configurables (redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser reservados y liberados de manera rápida con un mínimo esfuerzo e intervención por parte del proveedor. Todas las definiciones alternativas redundan en los mismos términos y conceptos, que se pueden resumir en:
- Disponibilidad de recursos masivos que se emplean bajo demanda, el modelo es de pago por uso, sin compromisos a largo plazo ni obligación de realizar predicciones acerca del uso de la infraestructura.
- Capacidad de que clientes heterogéneos realicen accesos remotos, ubicuos y dinámicos a través de la red. Los mecanismos de acceso a la infraestructura virtualizada deben ser estándares y transparentes al usuario.
- Agrupación de recursos y utilización en modo multi-tenant. Es decir, el proveedor suele centralizar en un número reducido de sedes todos sus recursos para facilitar su gestión y tiene que estar preparado para que diferentes usuarios hagan uso de los mismos recursos en un momento dado sin que esto sea en perjuicio del rendimiento que observen y de manera que sea transparente para ellos (de nuevo incidimos en el concepto de infraestructura virtualizada).
- Elasticidad y dinamismo, los recursos deben poder reservarse y liberarse según las necesidades de los clientes en cada momento. De hecho, para el cliente debe ser como si pudiera escalar hasta cantidades de recursos prácticamente ilimitadas y prácticamente en tiempo real. Además, esta característica también debe entenderse como una incorporación casi automática de nuevas tecnologías, los proveedores deben ofrecer a sus clientes siempre las últimas innovaciones.
- Servicios proporcionados como suministros y por lo tanto, monitorizados, controlados y cuantificados de manera rigurosa, manteniendo políticas de información y de privacidad adecuadas.
¿Qué cambia en un contexto cloud?
Muchas organizaciones no cambian de paradigma o lo están haciendo muy lentamente porque les asusta la indefinición que suele percibirse en los entornos cloud, la pérdida de control sobre sus activos y la deslocalización de estos. La mayor parte de estudios y encuestas identifican como mayor preocupación en la transición a un contexto cloud la ciberseguridad. Y esto en casi todos los roles de una organización, no sólo en los técnicos. Pero ¿hasta qué punto esta preocupación está justificada en la actualidad?
La evolución de las soluciones propietarias o in-house a los entornos cloud exige una actualización en la manera de trabajar en ciberseguridad, similar a la que se tuvo que hacer al pasar del modelo local o centralizado al modelo cliente-servidor. En esta evolución, la colaboración entre el cliente y el proveedor es esencial para el cumplimiento de las políticas y procedimientos definidos por el cliente, así como para el cumplimiento de las normativas, legislaciones y regulaciones que puedan afectarle en función de las naciones en las que opere o de su sector de actividad. Todo esto está muy relacionado con la gobernanza y la definición y monitorización de la SLA (Service Level Agreement) con el que el cliente y el proveedor acuerdan, mediante relación contractual, los términos de prestación del servicio a diferentes niveles.
Por poner sólo algunos ejemplos relacionados con la seguridad, el cliente y el proveedor deben: a) definir claramente las fronteras para los datos (hay que tener en cuenta que los proveedores tecnológicos suelen tener sus centros de datos repartidos prácticamente por toda la geografía del planeta y que existen normativas y regulaciones muy rigurosas con la ubicación de los datos); b) dejar claros desde el principio todos los aspectos relacionados con la propiedad intelectual; c) definir conjuntamente los procedimientos para responder ante incidentes; d) acordar los procedimientos para obtener evidencias digitales; y e) realizar auditorías o deben hacer visibles sus relaciones con terceros (auditores, intermediarios, otros proveedores) y cómo pueden afectar éstas a la ciberseguridad.
La importancia que los aspectos relacionados con la ciberseguridad están cobrando en las SLAs actuales está haciendo que la comunidad valore si es necesario definir un Privacy Level Agreement o un Security Level Agreement específico. Pero todavía no hay una conclusión clara respecto a este tema.
Responsabilidad del cliente vs responsabilidad del proveedor
Clasifica las siguientes defensas y contramedidas típicamente utilizadas en entornos cloud en función de si crees que son responsabilidad del cliente, del proveedor o de ambos (o bien porque se trate de una responsabilidad compartida o bien porque pueda serlo de los dos y se deba aclarar en la SLA quién la asume). Como siempre, tienes cinco oportunidades.
- Utilización de Trusted Operating Systems o Trusted Hypervisors que garanticen el correcto aislamiento entre los recursos contratados por los distintos clientes.
- Definición de políticas que certifiquen la fuente u origen fiable de las virtual appliances que se despliegan en las máquinas contratadas a través de IaaS o en las plataformas contratadas a través de PaaS.
- Utilización de protocolos seguros para el acceso a la red y encriptación de los datos en tránsito.
- Fortificación de los dispositivos o terminales de acceso a los recursos contratados por el cliente.
- Utilización de tecnologías seguras para el almacenamiento de los datos en los recursos contratados por los clientes (encriptación de los datos almacenados).
- Mejora de las capacidades de monitorización, y de prevención y detección de intrusos en las redes virtuales que comunican los recursos contratados por los clientes.
- Diseño de interfaces de acceso o APIs seguras.
- Utilización de esquemas IAAA fuertes y con sistemas de autenticación multi-factor.
- Aplicación de las mejores prácticas propuestas en la norma ISO/IEC 27017.
- Establecimiento de planes de gestión de incidentes.
Riesgos y amenazas en entornos cloud
La preocupación por la ciberseguridad en entornos cloud ha hecho que desde el año 2008 se intenten clasificar los riesgos, amenazas y vulnerabilidades específicos del paradigma para intentar también proponer soluciones, defensas y contramedidas particulares que generen confianza en los potenciales clientes. El problema es que no hay una propuesta estándar, aunque cada vez existe un acuerdo mayor en los aspectos más importantes.
Vamos a centrarnos en un par de análisis que se encuentran entre los más aceptados en la actualidad. Según el análisis de riesgos específicos para cloud computing que realizó ENISA en el año 2009, los 10 riesgos más importantes son los que se muestran en la siguiente figura (no están ordenados por importancia o criticidad).
Más recientemente, la Cloud Security Alliance (CSA) ha identificado en su lista The Notorious Nine las nueve amenazas más importantes en entornos cloud.
Como puedes observar, a pesar de que han pasado cuatro años entre un análisis y el otro, los riesgos y amenazas que más preocupan son prácticamente los mismos.
Un primer grupo tiene que ver con aspectos legales, organizativos y estratégicos. Preocupa todo lo relacionado con la externalización, como la cautividad de un proveedor específico (que puede quebrar, fusionarse con otro, cambiar las condiciones de prestación del servicio, etc.), la oscuridad, entendida como falta de información que permita alinear la tecnología con los objetivos estratégicos (es decir, la dificultad en la gobernanza), la pérdida de disponibilidad (sin tener la oportunidad de intervenir en los planes de gestión de incidentes del proveedor o en sus planes de continuidad del servicio) o la imposibilidad de garantizar que se cumplen ciertas normativas y regulaciones. Pensemos en el típico ejemplo de empresa que opera en España, y por lo tanto está obligada a cumplir con la LOPD, que utiliza un sistema CRM de un proveedor estadounidense con centros de datos repartidos por los cinco continentes.
El segundo grupo es el que incluye a los riesgos puramente tecnológicos, es decir, aquellos que pueden afectar a la confidencialidad, integridad, disponibilidad y control de acceso por vulnerabilidades de las tecnologías y modelos que subyacen al paradigma. En este caso, preocupan especialmente los atacantes internos que trabajen para los proveedores y las vulnerabilidades específicas de las interfaces y APIs de acceso así como de las tecnologías de virtualización. Estos dos últimos aspectos aumentan la superficie de exposición de los activos y por una mala gestión del acceso a través de tecnologías estándar y de Internet o del multi-tenancy (es decir, por un fallo en el aislamiento entre los usuarios que están utilizando los mismos recursos físicos) pueden permitir materializar amenazas graves.
En este contexto, cabe destacar que los patrones de ataque que más se observan en la actualidad ya los conoces: son las inyecciones de comandos y código, los forgeries y los diferentes secuestros de sesión y/o cuenta debidos a los esquemas IAAA débiles, normalmente basados, todavía en la actualidad, en un único factor de autenticación (par nombre de usuario-contraseña).
Esquemas IAAA para entornos cloud
Analizando lo estudiado en la pantalla anterior, la seguridad en entornos cloud debe estar soportada en la actualidad por cuatro pilares básicos: la utilización de protocolos de red seguros, la encriptación de datos a diferentes niveles, la definición de políticas y procedimientos adecuados para el paradigma y el uso de esquemas IAAA fuertes. Y en cada uno de estos cuatro aspectos las dos partes, proveedor y cliente deben cumplir con su papel correctamente. Vamos a centrarnos a continuación en el último tipo de contramedida, los esquemas IAAA, que es el único que no hemos estudiado todavía en el MOOC.
Como has podido ver, existen soluciones federadas para resolver el problema de IAAA en entornos cloud de manera sencilla y flexible para los usuarios (incluso permitiéndoles asociar su identidad a su número de teléfono, ya que cada vez más se accede a los servicios cloud desde dispositivos móviles), pero también segura. Esta seguridad se basa principalmente en la autenticación multi-factor, que además de basarse en algo que se conoce (nombre de usuario y contraseña) se basa en algo que se posee (algún tipo de token o smart card, la SIM del teléfono) e incluso en algo que es (aprovechando las capacidades biométricas de estos dispositivos móviles, que permiten escanear la huella dactilar, reconocer la cara o capturar una firma, por ejemplo). Sin embargo, la adopción de estos esquemas está siendo lenta, por lo que no te debe extrañar encontrarte con que todavía hoy en día muchos proveedores a distintos niveles (tanto IaaS como PaaS o SaaS) se basan todavía en un par usuario-contraseña sobre https o como mucho en la utilización de HMAC (recuerda, Hash Message Authentication Code, es decir, autenticación basada en criptografía de clave privada o simétrica).
No hay comentarios:
Publicar un comentario