El auditor pide la política SecurityAudit para AWS, ¿hasta qué punto es seguro este acceso?

SecurityAudit no tiene permiso para descargar objetos de almacenamiento, así que no pueden extraer datos de clientes. Lo que sí permite es leer configuraciones de funciones o datos de inicio de servidor. Si dejaste contraseñas en texto plano en el código o en los scripts de userdata de las instancias, el auditor las verá. Revisa y limpia eso primero.

Es obligatorio meter la condición de External ID al crear el rol. Además, pon una restricción por IP de origen en la relación de confianza para que solo entren desde la VPN o las oficinas de la auditora. A las dos semanas borras el rol con un clic y listo.

¿Van a usar alguna herramienta de escaneo automático o lo van a revisar todo a mano desde la consola? Si van a conectar herramientas cloud de terceros, ¿les pediste por escrito el número de cuenta de la auditora y la política de External ID que utilizarán?

Nosotros definimos un rol similar para una auditoría de cumplimiento. La auditoría duró 12 días. Apenas terminó el proceso borramos el rol de IAM y consultamos la sesión del auditor a través de los logs de auditoría; hicieron cerca de 14.200 llamadas a la API de solo lectura en total. No hubo ningún intento de descarga de datos.

ni se te ocurra crear un usuario iam y darlle access keys. dsp esos keys quedan olvidados por ahi. creen un rol nomas, pongan external id, y cuando terminen borren el rol y listo.

Las empresas de auditoría lo quieren todo servido, pero no están obligados a dar un rol directamente en la cuenta de producción. Muchas empresas extraen ellas mismas los informes de configuración y los resultados de seguridad con herramientas de línea de comandos y los entregan como archivos. ¿Por qué le iban a dar acceso completo en vivo a toda la cuenta?

En el acuerdo de confidencialidad firmado antes de iniciar la auditoría, se debe asumir el compromiso explícito de cómo se procesarán los datos de configuración, cuántos días después se destruirán los logs guardados en la caché de las herramientas de auditoría y que no se compartirán con terceros.

En resumen: SecurityAudit accede a la configuración, no a los datos, por lo que es una solicitud estándar. Aún así, den permisos a través del rol añadiendo External ID, restricción de IP y límite de tiempo, y el día que termine la auditoría borren el rol y revisen los logs del sistema.

Tiene razón. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Espero que le sea útil.

Exacto, y encima no es tan conocido. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.

A nosotros también nos pasa.

Hay algo que no entiendo. Cuanto más difícil sea revertir una decisión más despacio debéis tomarla.

Lo dejo como nota, por si sirve.

hay que ir paso a paso.. y al tomar decisiones, escribe también el peor escenario no solo el mejor.

por supuesto cambia si tu situación es diferente.

Estoy de acuerdo. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

Eso es todo, disculpa si me he extendido demasiado.

Me han quedado claras las dudas, gracias. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

correcto pero la verdad si regañas las fallsas alarmas nadie volverá a reportar.

yo seguiría por ese camino.

Yo pasé por esto, déjenme contarlo. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

lo escribo para que no cometan el mismo error pero el tiempo que tardas en detectar un problema determina directamente su coste.

yo seeguiría por ese camino.