Seguridad en la nube: dentro del modelo de responsabilidad compartida

En el último gran error de seguridad en la nube, Capital One sufrió una violación de datos, que afectó a 100 millones de personas en los Estados Unidos y 6 millones en Canadá. No era solo Capital One atrapado con los pantalones de seguridad bajados. Ahora sabemos que el hacker Paige A. Thompson robó terabytes de datos de más de treinta compañías, instituciones educativas y otras entidades ".

Como dijo la presunta atacante de las configuraciones de AWS, "Amigo, muchas personas lo están haciendo mal".

¿Solo otro día de compañías que ensucian su seguridad? No, este es diferente. Primero, ya sabemos mucho sobre lo que sucedió. Sabemos que Capital One depende en gran medida de Amazon Web Services (AWS). y el ataque se realizó contra datos guardados en Amazon Simple Storage Service (S3). Pero, en lugar de un ataque a un S3 sin ninguna seguridad, este ataque funcionó gracias a un error de configuración del firewall.

En resumen, estas infracciones no se debieron a errores de seguridad criminalmente estúpidos. Parecen haberse hecho porque las compañías simplemente hicieron un mal trabajo al mantener su seguridad.

Miremos más de cerca. La configuración incorrecta del Firewall de aplicaciones web ModSecurity (WAF) de Capital One permitió al atacante, un ex empleado de AWS, engañar al firewall para que transmita solicitudes a un recurso de fondo de AWS clave. Armado con esto, el hacker usó un Ataque de falsificación de solicitud del lado del servidor (SSRF) para engañar al firewall para que deje entrar al atacante.

Veremos mucho más de este tipo de ataque. Como Evan Johnson, gerente del equipo de seguridad de productos de Cloudflare, escribió: "El problema es común y conocido, pero difícil de prevenir y no tiene mitigaciones integradas en la plataforma de AWS".

Entonces, claramente parte de la culpa puede recaer en la tienda de AWS. Pero, como dijo la presunta atacante de las configuraciones de AWS, "Amigo, muchas personas lo están haciendo mal". Ella dijo esto después de prácticamente intentar abrir las puertas de cientos de compañías para encontrarlas, que estaban desbloqueadas. Quizás Gartner estaba haciendo algo cuando predijeron, "el 95% de las fallas de seguridad en la nube serán culpa del cliente".

Sin embargo, algunas personas, como el senador Ron Wyden, están poniendo gran parte de la responsabilidad de esta violación en AWS. No tan rapido.

Sí, AWS tiene algunas explicaciones que hacer, pero el verdadero problema es que si tiene malas prácticas de seguridad, se quemará. Cuanto más grande es la nube, más grande es la quemadura.

Esta violación no fue, como señaló el experto en seguridad Brian Krebs, causada por una "falla de 'día cero' previamente desconocida o un ataque 'interno'", sino por ataques bien conocidos que utilizan errores bien conocidos.

Pero, ¿quién tiene realmente la culpa en este conjunto de desastres de seguridad? ¿Es el proveedor de la nube o la empresa que usa la nube? La respuesta es ambas.

Modelo de responsabilidad compartida para la seguridad en la nube

Los clientes y los proveedores de la nube están a cargo de diferentes partes de la pila de la nube. Este concepto se llama Modelo de Responsabilidad Compartida (SRM). Una forma rápida de pensar en este modelo es que los proveedores de la nube son responsables de la seguridad de la nube, y los usuarios de la nube son responsables de la seguridad en la nube.

Tanto AWS como Microsoft Azure respaldan explícitamente este modelo. Pero, todas las nubes públicas lo usan en una medida u otra. Es la base de las formas tecnológicas y contractuales que actualmente manejamos con la seguridad en la nube.

En el nivel más básico, significa que usted está a cargo de todo lo que está por encima del nivel del hipervisor. Eso incluye el sistema operativo invitado, el software de su aplicación, el cortafuegos de la instancia de la nube y el cifrado de datos tanto en tránsito como en reposo. El proveedor de la nube se encarga del sistema operativo host, la capa de virtualización y la seguridad física de sus instalaciones.

Por supuesto, en el mundo real, nunca es tan simple.

Un vistazo al último fiasco de seguridad.

AWS afirma: "La seguridad y el cumplimiento es una responsabilidad compartida entre AWS y el cliente. Este modelo compartido puede ayudar a aliviar la carga operativa del cliente a medida que AWS opera, administra y controla los componentes desde el sistema operativo host y la capa de virtualización hasta la seguridad física de las instalaciones en las que opera el servicio. El cliente asume la responsabilidad y la administración del sistema operativo invitado (incluidas las actualizaciones y parches de seguridad), otro software de aplicación asociado, así como la configuración del firewall del grupo de seguridad proporcionado por AWS ".

Es ese último momento donde las cosas salieron mal para Capital One. Sí, parece que no habían configurado su firewall correctamente. Sin embargo, AWS facilita el acceso a las credenciales temporales del rol de AWS Identity and Access Management (IAM). Armado con estas credenciales temporales, es relativamente fácil hacer un ataque SSRF.

Johnson afirma que hay varias formas de reducir el uso de credenciales temporales. Netflix también ha demostrado que puede detectar el uso de credenciales de seguridad temporales en sus nubes de AWS. Entonces, sí, AWS puede hacer un mejor trabajo al bloquear sus firewalls, pero, una vez más, Capital One puede configurar el firewall en primer lugar. En resumen, todo es bastante desordenado.

Eso no es sorprendente. Como señala KirkpatrickPrice, los requisitos de seguridad en la nube "como un espectro. Los clientes del servicio en la nube combinan todos los requisitos reglamentarios, industriales y comerciales (GDPR, PCI DSS, contratos, etc.) que se aplican a su organización y la suma es igual a todos los requisitos de seguridad específicos de esa organización. Estos requisitos de seguridad ayudarán a garantizar que los datos sean confidenciales, tengan integridad y estén disponibles.

En un extremo del espectro de requisitos de seguridad están los proveedores de servicios en la nube y en el otro los clientes de servicios en la nube. El proveedor es responsable de algunos de estos requisitos de seguridad, y el cliente es responsable del resto, pero ambas partes deben cumplirlo. Los proveedores de servicios en la nube y los clientes de servicios en la nube tienen la obligación de proteger los datos ".

Pero, ¿dónde trazas la línea entre quién está a cargo de qué? Eso tampoco es fácil. No hay un tamaño de seguridad único para todas las soluciones en la nube. Por ejemplo, si usa una suite ofimática sSoftware-as-a-service (SaaS), como GSuite de Google, claramente, Google y usted no, están a cargo del software. Si está ejecutando su propia aplicación en una Plataforma como servicio (PaaS), sin embargo, se responsabiliza tanto de cómo se ejecuta ese programa.

Si observa de cerca, verá que AWS tiene tres SRM diferentes. Estos son servicios de infraestructura; servicios de contenedores; y servicios abstractos. Azure y otros servicios de nube pública tienen configuraciones de políticas de seguridad similares.

La infraestructura incluye servicios informáticos como EC2 y servicios de soporte como Elastic Block Store (EBS), escalado automático y redes privadas virtuales (VPC). Con este modelo, instala y configura sus sistemas operativos y plataformas en la nube de AWS tal como lo haría en las instalaciones o en su propio centro de datos. Además de esto, instala sus aplicaciones. En última instancia, sus datos residen y son administrados por sus propias aplicaciones.

A pesar del nombre, los servicios de contenedores en este contexto tienen poco que ver con Docker y tecnologías similares que se te ocurren cuando piensas en contenedores. En cambio, estos son servicios que normalmente ejecuta en Amazon EC2 u otras instancias de infraestructura separadas, pero a veces no administra el sistema operativo o la capa de plataforma.

AWS proporciona servicios administrados, pero usted es responsable de configurar y administrar los controles de red, como las reglas de firewall, y de administrar la identidad a nivel de plataforma y la administración de acceso por separado de IAM. Los ejemplos de servicios de contenedor incluyen Amazon Relational Database Services (Amazon RDS), Amazon Elastic Map Reduce (Amazon EMR) y AWS Elastic Beanstalk.

Aquí, AWS administra la infraestructura subyacente y los servicios básicos, el sistema operativo y la plataforma de aplicaciones. Por ejemplo, con Amazon RDS, AWS administra todas las capas del contenedor, incluida la plataforma de base de datos Oracle. Pero, mientras que la plataforma AWS proporciona herramientas de copia de seguridad y recuperación de datos; es su trabajo cuidar la continuidad de su negocio y la política de recuperación ante desastres. También eres responsable de los datos y de las reglas del firewall. Entonces, aunque Amazon RDS proporciona el software de firewall, es su trabajo administrar el firewall.

Los servicios abstraídos son almacenamiento de alto nivel, bases de datos y servicios de mensajería. Incluyen Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB y Amazon Simple Email Service. Estos resumen la plataforma o capa de gestión en la que puede construir y operar aplicaciones en la nube. Lo haces usando sus API de AWS. AWS administra los componentes de servicio subyacentes o el sistema operativo.

Aquí, su trabajo de seguridad es administrar sus datos mediante el uso de herramientas de IAM para aplicar permisos de estilo de Lista de control de acceso (ACL) a recursos individuales a nivel de plataforma, o permisos de identidad de usuario o responsabilidad de usuario a nivel de usuario / grupo de IAM.

Veamos un ejemplo específico simple. Amazon clasifica Amazon Elastic Compute Cloud (Amazon EC2) como una nube de Infraestructura como Servicio (IaaS). Con él, usted es responsable de administrar el sistema operativo invitado (incluidas las actualizaciones y parches de seguridad), cualquier software de aplicación o utilidades que haya instalado en las instancias y la configuración del firewall proporcionado por AWS de cada instancia, también conocido como un grupo de seguridad. Pero, con Amazon S3 "AWS opera la capa de infraestructura, el sistema operativo y las plataformas, y los clientes acceden a los puntos finales para almacenar y recuperar datos. Los clientes son responsables de administrar sus datos (incluidas las opciones de cifrado), clasificar sus activos y usar IAM herramientas para aplicar los permisos apropiados ".

Obtener el punto? Ambos son IaaSes pero tienen reglas diferentes.

La moraleja de la historia es que debe observar cuidadosamente cada acuerdo de servicio de SRM en la nube, y me refiero a todos. Aún así, si bien debe ver exactamente qué es qué con cada servicio que utiliza y quién es responsable de cada uno, el concepto básico no es demasiado complicado. El proveedor de la nube es responsable de la seguridad de la nube, y usted es responsable de la seguridad en la nube

Más complejidad en la nube por delante

La informática nativa de la nube ha enturbiado lo que hay en los SRM. Por ejemplo, AWS ahora ofrece AWS Lambda. Este es un enfoque en la nube sin servidor que le permite ejecutar código sin aprovisionar ni administrar servidores. Entonces, sin un servidor per se, ¿quién se responsabiliza por el, bueno, el servidor?

Según Amazon, con Lambda "AWS administra la infraestructura subyacente y los servicios básicos, el sistema operativo y la plataforma de aplicación. Usted es responsable de la seguridad de su código, el almacenamiento y la accesibilidad de datos confidenciales, y la gestión de identidad y acceso (IAM ) al servicio Lambda y dentro de su función ".

Esto deja preguntas abiertas. Por ejemplo, dado que está utilizando Lambda para ejecutar su código, ¿dónde termina la responsabilidad de su código y comienza la de Lambda?

Como Gadi Naor CTO y cofundador de Alcide, una compañía de plataforma de seguridad nativa de la nube de pila completa, observó, "usar una arquitectura sin servidor significa que las organizaciones tienen nuevos puntos ciegos, simplemente porque ya no tienen acceso al sistema operativo de la arquitectura, evitando que agreguen firewalls, prevención de intrusiones basadas en host o herramientas de protección de la carga de trabajo en estas cargas de trabajo ".

Este es sólo el comienzo. Por ejemplo, Kuberrnetes permite que la nube híbrida se ejecute en varias nubes a la vez. Entonces, si está ejecutando un programa que se extiende entre la nueva nube IBM basada en Red Hat y AWS, ¿quién está a cargo de asegurar todo el proyecto? ¿Quién tiene la culpa cuando algo sale mal? Y, por último pero nunca menos importante, ¿quién paga cuando los usuarios finales demandan?

Buenas preguntas, ¿no? Todavía no tenemos buenas respuestas para este nuevo mundo complejo en la nube al que estamos entrando.

¿Entonces que puedes hacer? Primero, asegúrese de comprender sus necesidades de seguridad en la nube. No puede elegir un proveedor de servicios en la nube y elaborar un acuerdo de seguridad en la nube, hasta que sepa lo que funciona para usted. Estos no son solo problemas tecnológicos. También son asuntos legales de los que preocuparse.

Armado con esta información, está listo para resolver sus acuerdos de seguridad con su proveedor de la nube. Esto debe especificarse en su acuerdo de nivel de servicio.

Finalmente, no importa lo que haya en los contratos, usted y su personal de seguridad deben asegurarse de que sus datos y servicios basados ​​en la nube sean lo más seguros posible. Después de todo, son sus datos, su trabajo, y es a usted a quien sus clientes y accionistas verán primero si algo sale mal.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *