Responsabilidad compartida y reglas de los proveedores

En la nube, el proveedor protege la infraestructura sobre la que corre todo: los centros de datos, el hipervisor, el hardware. El cliente protege lo que él configura encima: quién entra, qué reglas de red pone, qué datos sube y si el almacenamiento es público o no. Esa frontera se mueve según el modelo. En una máquina virtual (IaaS) el cliente también parchea el sistema operativo. En un servicio administrado (PaaS) el proveedor parchea el motor, pero la configuración de acceso sigue siendo del cliente. En un servicio completo (SaaS) casi todo es del proveedor, y por eso casi nada de él se prueba sin su permiso.

Para un pentester esto decide a quién va dirigido cada hallazgo. Un bucket abierto no es un fallo de la nube: es una configuración del cliente.

El cliente de Yarumo entregó una matriz con un responsable por cada control. Casi todas las filas son correctas, y un auditor las repasa una a una con la regla de la tarea anterior. Si una configuración del cliente figura como del proveedor, ese control no tiene dueño: nadie lo revisa porque cada parte cree que es de la otra.

Abre la matriz y localiza la fila en la que el control es configuración del cliente pero la matriz lo asigna al proveedor.

La autorización del cliente cubre sus cuentas, pero cada proveedor pone además sus propias reglas, y ninguna de las dos cosas sustituye a la otra. Las tres políticas coinciden en lo esencial: no se hacen ataques de denegación de servicio, que son los que tumban el servicio para todos los clientes que comparten la infraestructura. Una prueba así no se reformula ni se pide con otras palabras: se retira del plan.

El equipo de Yarumo propuso siete pruebas. Lee el plan junto al archivo de las reglas y busca la que ninguna de las tres nubes permite.

La política de AWS permite probar sin aprobación previa los servicios de su lista permitida, y la de Azure se apoya en el consentimiento del titular de los activos. La de Oracle es distinta: pide avisar antes de empezar, sin pedir permiso ni esperar respuesta. Son tres maneras de decir lo mismo desde puntos distintos, y por eso un buen plan de pruebas lleva una tabla de notificaciones. Las reglas cambian con el tiempo: el resumen del encargo lleva fecha y la regla se vuelve a leer en la fuente antes de cada trabajo.

Cuando el cliente ya firmó la autorización y falta un aviso a un proveedor, la prueba sobre esa cuenta espera.

La tabla de notificaciones de la autorización dice, por cada proveedor, si hace falta avisar y si el aviso ya salió. Cruza las dos columnas: hay una cuenta que todavía no se puede revisar.