El caso
¿Quién borró la carpeta de facturas? El registro solo mostraba una cuenta de servicio.
Un lunes por la mañana, la tienda de Isaac descubrió que faltaban archivos de facturas en el almacenamiento. El equipo necesitaba saber quién lo había hecho, y desde dónde. Sin un registro de las acciones, la respuesta era una suposición.
Este post parte de Seguridad y responsabilidad compartida en la nube, que explica quién responde por qué y los conceptos de identidad y rol. También depende de la jerarquía de recursos, porque los permisos siguen el árbol de carpetas y proyectos.
El problema
Demasiado permiso y poco registro
Cuando todos tienen acceso de administrador al proyecto, cualquier error puede borrar todo, y nadie sabe quién hizo qué. El problema no es solo el permiso excesivo: también es no tener un registro confiable de las acciones.
Políticas de IAM
Quién puede hacer qué, y dónde
En Google Cloud, el IAM funciona con una política (IAM policy) asociada a un recurso. La política es una lista de vínculos: un miembro (usuario, grupo o cuenta de servicio) recibe un rol en ese recurso.
Las políticas se heredan de arriba hacia abajo. Un rol dado en la carpeta vale para todos los proyectos dentro de ella, y un rol dado en el proyecto vale para todos sus recursos. Por eso, dar acceso en el nivel más alto puede abrir más de lo que se pretendía.
Roles
Tres tipos de rol
Básicos (basic roles)
Owner, Editor y Viewer. Son demasiado amplios para producción: un Editor puede cambiar casi todo en el proyecto.
Predefinidos (predefined roles)
Creados para cada servicio, con los permisos de una tarea. Por ejemplo, un rol que solo lee objetos de Cloud Storage.
Personalizados (custom roles)
Tú armas el rol con los permisos exactos. Da más control, pero exige mantenimiento cuando el servicio cambia.
En la tienda, el equipo de atención recibe un rol predefinido de lectura en el bucket de las facturas, y nada más.
Cuentas de servicio
Identidad para aplicaciones
Una aplicación no es una persona, así que no usa un inicio de sesión de usuario. En Google Cloud, recibe una cuenta de servicio (service account), una identidad propia que recibe roles como cualquier miembro.
El error más común es descargar una clave de la cuenta de servicio y pegarla en el código. La clave puede filtrarse, y no caduca sola. El camino recomendado es asociar la cuenta de servicio al recurso que ejecuta la aplicación, sin clave en el código.
Cifrado y claves
Los datos ya llegan cifrados
Google Cloud cifra los datos en reposo por defecto, sin configuración tuya. Quien necesita controlar las claves puede usar Cloud KMS para crear y rotar claves propias (CMEK, customer-managed encryption keys), y definir quién puede usarlas.
Registros de auditoría
Quién hizo qué, y cuándo
Los Cloud Audit Logs registran acciones sobre los recursos. Los registros de actividad administrativa (quién creó, cambió o borró algo) ya vienen activados y no tienen costo extra. Los registros de acceso a datos son opcionales en la mayoría de los servicios (BigQuery es la excepción), pueden generar costos y deben activarse a propósito.
La tienda ya tenía los registros de acceso a datos activados en el bucket de las facturas. Por eso, el equipo pudo ver que el borrado vino de la cuenta de servicio del sistema de facturación, de madrugada, y corrigió el permiso de esa cuenta.
Términos clave
Cinco términos para fijar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
Un sistema de pedidos solo necesita leer facturas de un bucket. ¿Cuál es la forma más adecuada de dar el acceso?
02
El equipo necesita saber qué cuenta borró un archivo de un bucket la semana pasada. ¿Qué recurso responde eso?
03
La tienda quiere controlar las claves que cifran sus datos, y no solo usar el cifrado por defecto. ¿Qué recurso debe usar?
En cualquier examen de nube, la pregunta de seguridad suele ser la misma: quién tiene acceso, con qué rol, en qué nivel, y cómo se sabe lo que se hizo. En Google Cloud, la respuesta pasa por la política de IAM, la cuenta de servicio y los registros de auditoría.