Mejorar la gran teoría unificada de la gobernanza del cloud

Hace poco más de un año escribí la gran teoría unificada de la gobernanza del cloud. Es un concepto con el que llevo trabajando unos 5 o 6 años para intentar sintetizar la causa raíz de las dificultades que tienen las empresas al adaptarse al cloud. Sí, el título es algo egocéntrico, pero fui analista de Gartner, así que, ¿qué le vamos a hacer?

Como toda buena teoría (eso espero), la sigo desarrollando con el tiempo a medida que trabajo con más empresas y hablo con más personas. La he usado muchísimo en los últimos dos años en mis conferencias y capacitaciones, sobre todo porque me han involucrado en más escenarios de gobernanza. Una y otra vez, los principales problemas que encuentro no son tanto técnicos, sino organizativos. Sí, la seguridad en el cloud tiene MUCHAS complejidades técnicas, y pueden derivar, y derivan, en brechas de seguridad, pero según mi experiencia los problemas de gobernanza pesan mucho más que los técnicos.

Una buena gobernanza no puede parchear un día cero, pero una mala gobernanza significa que el atacante nunca necesita uno.

El núcleo de la teoría no ha cambiado realmente, solo sigo buscando mejores maneras de explicarla. También decidí recortarla un poco. Así es como la presento actualmente en mis diapositivas:

• El cloud descentraliza las operaciones y la infraestructura
• Pero el cloud unifica todas las interfaces administrativas
• Y pone todos los portales administrativos y recursos en Internet, protegidos con un nombre de usuario y una contraseña

Si volvemos a la versión anterior, los cambios son pequeños pero también grandes:

• Todas las funciones administrativas y de gestión están unificadas en una sola interfaz de usuario que está en Internet.
• Protegida con un nombre de usuario, una contraseña y, quizás, MFA.
• La tecnología evoluciona más rápido que la gobernanza.

Sigo usando lo de “sin puntos de control ni guardianes” en mi charla, pero descubrí que es una forma más larga de decir “descentralizado”. La cuestión fundamental es el control independiente de toda la pila fuera de la infraestructura centralizada. Que un equipo de desarrollo o de aplicaciones pueda construir y gestionar toda su propia infraestructura en su propio entorno con solo una tarjeta de crédito. Ahora bien, sí existen algunas dependencias y controles, especialmente en el plano de datos o cuando hay que conectarse de nuevo a las redes, pero eso no cambia el punto principal.

Intentar recentralizarlo todo por completo rara vez va a funcionar.

Luego, no cambié realmente la unificación de las interfaces administrativas. Para ampliar: descentralizamos toda la infraestructura y el control a nivel de implementación, pero todo el mundo, en todo el planeta, usa la misma consola web y los mismos endpoints de API.

Los atacantes tienen una sola puerta de entrada hacia infinitos objetivos.

Después tomé el subpunto de la primera versión y lo convertí en el punto 3. Todos estos portales administrativos están en Internet y, de forma predeterminada, usan poco más que un nombre de usuario y una contraseña. Todos los recursos también están a una configuración de distancia de quedar expuestos en Internet; basta con preguntarle a todos esos buckets de S3 y clústeres de ElasticSearch.

Realmente es así de simple. Los equipos gestionan sus propias cosas de forma independiente. Todos, en todo el mundo, usan los mismos portales web y endpoints de API. Y cualquier idiota con las credenciales correctas puede hurgar en la trastienda de su “centro de datos”.

Ahora viene la parte increíble: todo esto ya estaba planteado en 2011 en NIST 800-145, las 2 páginas de la definición de cloud computing del NIST. Allí se definieron las cinco características esenciales del cloud computing:

• Autoservicio bajo demanda
• Amplio acceso a la red
• Agrupación de recursos
• Elasticidad rápida
• Servicio medido

Si tomamos los tres primeros puntos, tenemos:

• Los equipos gestionan sus propias cosas
• Todo está en Internet
• Y todo se basa en grupos colectivos de recursos

Bien, ¿y qué significa todo esto y qué hacemos?

Aceptarlo.

Ese es el primer paso. Comprender el problema y usarlo como lente para diseñar nuestras soluciones. Como escribí recientemente en mi publicación sobre autorización robusta:

Porque no están acostumbrados a que todo esté (potencialmente) en Internet. Todo el plano de gestión está en Internet, así que si un atacante obtiene credenciales, no se lo puede detener con un firewall ni cerrando el acceso a un servidor.

Empiece por ahí. Acepte la realidad de base. ¿Qué podemos hacer para reducir ese riesgo? ¿Para reducir esos ataques? Creo que la decisión de mayor impacto es centrarse en IAM y en la intersección entre la gobernanza y IAM. ¿Quién gestiona los permisos? ¿Y el acceso? ¿Qué controles de seguridad pueden prevenir, detectar y corregir los ataques relacionados con IAM? ¿Cuáles son sus procesos en torno a IAM? ¿Conocen sus equipos de respuesta a incidentes los detalles más profundos de IAM del proveedor o los proveedores de cloud que utiliza? ¿Usa JIT/autorización robusta? ¿Cómo gestiona IAM para contratistas y servicios externos?

Empiece por su gobernanza y sus procesos de IAM. Después elija y use tecnologías que los respalden. Esta es la forma más eficaz de mejorar la seguridad de su cloud. Espero de verdad no ser la primera persona en decírselo.