«Solo lectura» es una afirmación hasta que alguien la comprueba: cómo Skyline verifica las credenciales antes de escanear

Lo primero que pregunta cualquiera antes de apuntar una herramienta externa a su nube es "¿qué puede hacer ahí dentro?". La respuesta honesta en la mayoría de herramientas de inventario es: lo que pueda hacer la credencial que le has dado. Piden acceso de solo lectura, documentan que solo llaman a APIs de lectura y dejan el resto a tu buena fe.

No basta, y por un motivo que nos encontramos una y otra vez en los diagnósticos: la credencial que un equipo cree que es de solo lectura muchas veces no lo es. Alguien adjuntó ReadOnlyAccess y dejó además una política inline de una migración. Alguien reutilizó un rol de automatización existente porque crear uno nuevo requería un ticket. Alguien pegó sus propias claves porque era más rápido. En tres de los últimos diez proyectos, la credencial "de solo lectura" que nos entregaron podía escribir.

Así que Skyline no se fía de la afirmación. Antes de la primera llamada de inventario, le pregunta al proveedor qué puede hacer realmente esa credencial, y se niega a escanear si la respuesta incluye escrituras.

Preguntar al proveedor en lugar de preguntar al usuario

Cada nube tiene una API que evalúa una política sin ejecutar nada. Skyline usa la que corresponde a cada proveedor:

• AWS — iam:SimulatePrincipalPolicy, que evalúa una lista de acciones contra el conjunto efectivo de políticas del principal en una sola llamada. Está incluida en ReadOnlyAccess, así que una credencial realmente de solo lectura siempre puede ejecutarla.
• Google Cloud — testIamPermissions sobre el proyecto, la carpeta o la organización del alcance, que devuelve el subconjunto de permisos sondeados que el llamante tiene de verdad.
• Azure — la lista Microsoft.Authorization/permissions de la suscripción, que devuelve las acciones y no-acciones efectivas de los roles asignados.
• Oracle Cloud — las políticas efectivas de la tenancy para los compartimentos del alcance.

Ninguna de estas llamadas cambia nada. Es el proveedor respondiendo a una pregunta hipotética sobre su propio modelo de autorización, que es una fuente de verdad bastante mejor que una persona describiendo el rol que cree haber creado.

Qué sondeamos

Sondear todas las acciones de escritura de AWS sería absurdo, e innecesario. Lo que importa es un conjunto representativo: si una credencial puede hacer cualquiera de estas, no es de solo lectura y lo demás da bastante igual. Skyline sondea unas cuarenta acciones agrupadas por lo que le permitirían hacer a un atacante:

• Escalada de privilegios — iam:CreateAccessKey, iam:AttachRolePolicy, iam:PutUserPolicy, iam:PassRole, iam:UpdateAssumeRolePolicy. Una credencial que pueda cualquiera de estas es, con pasos intermedios, una credencial de administrador.
• Ejecución de código — ec2:RunInstances, lambda:UpdateFunctionCode, ecs:RunTask, ssm:SendCommand, ssm:StartSession. Convierten el acceso de lectura en una shell.
• Manipulación y destrucción de datos — s3:PutObject, s3:PutBucketPolicy, rds:ModifyDBInstance, dynamodb:DeleteTable, kms:ScheduleKeyDeletion.
• Evasión de auditoría — cloudtrail:StopLogging, cloudtrail:DeleteTrail. Todo lo que pueda apagar el registro de lo que ha hecho merece categoría propia.

La lista está deliberadamente sesgada hacia permisos peligrosos y no hacia permisos frecuentes. s3:PutObject sobre un único bucket de logs es motivo suficiente para parar; iam:PassRole también, que parece inofensivo en una revisión de políticas y es la vía de escalada más fiable de AWS.

Las credenciales de root se rechazan de entrada

Un caso especial que conviene decir claro: si la identidad resuelve al root de la cuenta, Skyline para antes de sondear nada. Root siempre tiene permisos de escritura, y no hace falta ninguna simulación para saberlo. El error te dice que crees un rol con ReadOnlyAccess y vuelvas con ese.

Esto pilla a más gente de la que debería. Las claves de root siguen siendo la forma más rápida de sacar un escaneo un viernes por la tarde, y la forma más rápida de entregar a un tercero las llaves de toda la cuenta.

Cuando la propia verificación no es posible

Hay un caso límite que nos costó decidir. Algunas políticas estrictamente de solo lectura no incluyen el permiso necesario para hacer la verificación. ViewOnlyAccess de AWS, por ejemplo, no concede iam:SimulatePrincipalPolicy. Una implementación ingenua rechazaría las credenciales más restrictivas del mercado, que es justo lo contrario de lo que se busca.

Por eso la regla es asimétrica:

• Escrituras demostradas — se rechaza el escaneo y se indica qué acciones han salido permitidas.
• Solo lectura demostrada — se escanea.
• No se puede determinar — se escanea, con una advertencia que llega hasta el informe, para que quien lo lea sepa que en esa ejecución la garantía no quedó establecida.

Negarse a trabajar cuando no puedes demostrar que es seguro suena riguroso, pero en la práctica empuja a la gente a credenciales más amplias para que la herramienta deje de protestar. Una herramienta que hace incómodo el camino seguro acaba sorteada.

La versión sin credenciales

La versión más fuerte de esta garantía es no necesitar la credencial. Skyline lee ficheros .tf, carpetas de proyecto completas y el JSON de terraform plan, y construye el mismo mapa, los mismos hallazgos de seguridad y la misma estimación de coste solo con el código. Sin rol, sin claves, sin nada que revocar después.

Para una primera mirada suele ser la opción correcta, y es la que proponemos cuando el equipo de seguridad de un cliente es razonablemente reacio a emitir nada para una herramienta externa. El escaneo en vivo añade lo que el código no puede saber —recursos creados a mano, deriva, gasto real del export de facturación, catorce días de métricas de CPU—, pero es una mejora, no un requisito.

Qué llevarte de aquí para tus propias herramientas

El patrón va más allá de nuestra herramienta y es barato de implementar:

1. Verifica el permiso, no lo documentes. Todas las nubes grandes tienen una API de simulación de políticas. Una llamada antes de empezar es la diferencia entre una promesa y un control.
2. Sondea consecuencias, no cobertura. Cuarenta acciones bien elegidas entre escalada, ejecución, manipulación y evasión de auditoría valen más que mil exhaustivas.
3. Falla abierto con advertencia cuando no puedas verificar, y cerrado cuando sí. Si no, entrenas a la gente para conceder de más.
4. Haz del camino sin credenciales una función de primera, no un modo degradado.

Si quieres el informe sin la discusión sobre credenciales, prueba Skyline primero sobre una carpeta de Terraform. Y si este es el tipo de razonamiento que quieres aplicado a tu propio modelo de accesos, de eso va nuestro trabajo de seguridad.