El auditor del cliente nos pide crear un 'rol de auditoría de seguridad de AWS' en nuestra cuenta cloud: ¿cuántos permisos deberíamos darle?

La distinción más crítica es la diferencia entre ReadOnlyAccess y SecurityAudit. Si das ReadOnlyAccess, el auditor puede descargarse archivos de tus buckets de almacenamiento y curiosear demasiado en los metadatos de las bases de datos. Un auditor de seguridad solo necesita la política SecurityAudit y, si acaso, un par de paneles de monitorización limitados.

Para crear un rol de auditoría seguro, no te saltes estos tres pasos: 1) Añade a la trust policy del rol una condición con un ExternalId que no sea predecible. 2) Ajusta la duración máxima de sesión (MaxSessionDuration) del rol a una hora. 3) Limita el acceso a su bloque de IPs añadiendo una restricción de dirección IP en la política del recurso.

Son muy pocos los estándares de auditoría que exigen a un auditor externo entrar directamente a la cuenta de AWS en producción. La mayoría de las veces basta con reportes de configuración y volcados de datos. ¿Le has preguntado por escrito al auditor por qué no les sirve solo con los reportes de configuración antes de dar acceso a la cuenta?

Corrección: recordaba mal la cifra, era un poco más baja.

Antes de configurar cualquier acceso, hay que firmar un acuerdo de confidencialidad (NDA) bilateral con la empresa auditora. En ese contrato deben detallarse claramente el alcance de la auditoría, los recursos a los que se va a acceder y la responsabilidad sobre los registros de sesión. No se debe compartir ningún permiso de la cuenta sin tener la base legal bien atada.

El año pasado pasamos por dos auditorías parecidas. Activamos el rol solo para una ventana de 72 horas y limitamos la sesión a 3 horas. El auditor solo ejecutó 42 consultas a la API en total e hizo su trabajo. En cuanto terminó el plazo eliminamos el rol y no tuvimos ningún problema.

la primera vez es normal que a uno le entren los nervios y pero no te agobies: si le dices al auditor del cliente que «por política interna no facilitamos usuarios de consola directos y configuramos un rol de auditoría con ID externo», vas a proyectar una imagen súper profesional.

cuando crees el rol filtra en cloudtrail por el nombre del rol del auditor y ve mirando de vez en cuando a ver q hace. si ves q se mete en servicios q no vienen a cuento le preguntas enseguida.

No pierdas tiempo: crea un nuevo rol en el panel de IAM, elige como tipo «otra cuenta de AWS», mete el número de cuenta del cliente, marca la casilla de ID externo, vincúlale únicamente el permiso de SecurityAudit y guarda.

Voy a contar mi experiencia. Lo importante no es la cifra, sino en qué se basa esa cifra.

También me gustaría saber si alguien lo hace de otra manera.

Si lo ves como un proceso, el panorama cambia. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Eso es todo, disculpa si me he extendido demasiado.

Esto también tiene su parte de medición. Un informe de escaneo automático no es lo mismo que una prueba de penetración.

También me gustaría saber si alguien lo hace de otra manera.

Tiene razón.

Si vas por ahí, resuelve esto desde el principio. Que todo el mundo haga algo no significa que sea lo correcto.

Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan. También me gustaría saber si alguien lo hace de otra manera.

Tienes razón, yo también pasé por lo mismo. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Después de vivir eso mi perspectiva cambió. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

Un informe de escaneo automático no es lo mismo que una prueba de penetración. Comprobado por experiencia.

No sabía eso.

Me pasó lo mismo.

Voy a detallar un poco el aspecto técnico. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Por supuesto, cambia si tu situación es diferente.