Identity, Access Management and Compliance

Resumen

En un entorno de nube moderna, la identidad reemplaza al perímetro de red como principal mecanismo de control de acceso. Mientras el modelo tradicional on-premises confiaba en la ubicación física o de red para decidir si una persona o sistema podía acceder a un recurso, la nube distribuye recursos entre regiones, dispositivos y entornos híbridos, y la única pregunta que importa es: quién (o qué) está intentando acceder, y tiene derecho a hacerlo. Este desplazamiento del perímetro hacia la identidad es el eje conceptual de este tema, y explica por qué Identity and Access Management (IAM) es la pieza central de la seguridad en Google Cloud.

El tema estructura el ciclo completo de control de acceso en tres fases que siempre aparecen juntas: autenticación (quién eres, verificación de identidad), autorización (qué puedes hacer, una vez verificada la identidad) y auditoría (qué hiciste, registro de la actividad para evidencia y respuesta). Un control de acceso completo requiere las tres; la ausencia de cualquiera las deja un vacío que el examen explota como pregunta de escenario. La autenticación se refuerza con dos factores o two-step verification (2SV); la autorización se modela con roles y permisos; la auditoría se sostiene con logs y herramientas de revisión.

IAM en Google Cloud aplica este ciclo a través de una jerarquía de recursos (organización, carpetas, proyectos, recursos), roles con conjuntos de permisos específicos, y bindings que asignan roles a miembros (usuarios, grupos, service accounts, dominios). El principio de menor privilegio (least privilege) exige otorgar el mínimo necesario para la tarea, y revisar periódicamente esos privilegios para eliminar los que ya no se justifican. Los grupos simplifican la gestión de permisos para personas; las service accounts gestionan el acceso de máquinas y aplicaciones, y son una fuente frecuente de riesgo cuando se crean en exceso o con privilegios heredados.

Conviene subrayar por qué este tema se estudia junto al cumplimiento (compliance), y no solo junto a la seguridad técnica. En la mayoría de los marcos de cumplimiento aplicables a organizaciones reguladas, la gestión de identidad y acceso es un control explícito: segregación de funciones, mínimo privilegio, revisión periódica de accesos y trazabilidad de acciones. Un programa de cumplimiento que no puede demostrar quién accedió a qué y con qué autorización está incompleto, independientemente de la calidad de sus controles de red o de cifrado. Por eso, en este tema, la dimensión de compliance no es un apéndice: es la razón por la que la gestión de identidad se documenta, se revisa y se reporta.

Para un líder de negocio, este tema no es solo técnico: define quién puede ver datos sensibles, quién puede aprobar transacciones críticas, y cómo se demuestra ante un auditor que esos accesos son correctos y están vigentes. La capacidad de responder con evidencia a preguntas de auditoría sobre identidad y acceso es, en sectores regulados, un requisito contractual y regulatorio, no un lujo de madurez operativa.

Un ejemplo cotidiano ilustra la relevancia de negocio: cuando un empleado cambia de rol dentro de la empresa, la gestión de su identidad determina si mantiene acceso a datos de su antiguo equipo (riesgo de confidencialidad y de cumplimiento) o si pierde ese acceso de forma automática y verificable (control que el auditor espera ver). Cuando un proveedor externo necesita acceso temporal a un proyecto, la gestión de identidad determina si ese acceso expira automáticamente o permanece indefinidamente después de finalizar el contrato. Estas situaciones no son excepcionales: ocurren cada día en toda organización, y su manejo correcto es lo que separa un programa de identidad maduro de una colección de cuentas dispersas.

El orden de estudio del tema sigue esa misma lógica: primero las tres fases del control de acceso (autenticación, autorización, auditoría), luego el refuerzo de la autenticación con 2SV, después el modelo de autorización de Google Cloud (jerarquía, roles, permisos), el principio que gobierna su asignación (least privilege), y finalmente las dos categorías de identidades que lo ejecutan en la práctica (grupos para personas, service accounts para máquinas). Cada pieza depende de la anterior: sin autenticación robusta, la autorización se aplica sobre identidades poco fiables; sin least privilege, la jerarquía de roles produce excesos; sin auditoría, nada de lo anterior es demostrable ante un tercero.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Explicar la relación entre autenticación, autorización y auditoría, y por qué las tres son necesarias para un control de acceso completo y auditable.
Describir el papel de two-step verification (2SV) y otros factores de autenticación en la reducción del riesgo de compromiso de cuentas.
Explicar los beneficios de IAM para la organización: control granular, revisión de accesos, separación de funciones y evidencia auditable.
Describir la jerarquía de recursos de Google Cloud (organización, carpetas, proyectos) y cómo IAM se aplica en cada nivel.
Definir los conceptos de roles y permisos, y diferenciar entre roles básicos, predefinidos y personalizados.
Aplicar el principio de least privilege en la asignación de roles, identificando permisos excesivos y riesgos asociados.
Explicar el uso y la gestión de grupos para administrar accesos de usuarios de forma eficiente y consistente.
Describir el ciclo de vida y los riesgos de las service accounts, y las prácticas para gestionarlas con least privilege.
Reconocer las herramientas de auditoría de identidad y acceso en Google Cloud, incluyendo los logs de administración de IAM.
Anticipar los errores más frecuentes en la gestión de identidad y acceso en entornos cloud, y articular las respuestas correctas.

Contenido Principal

Subtema 1: Autenticación, autorización y auditoría: el ciclo del control de acceso

Todo control de acceso se sostiene sobre tres preguntas que se responden en orden. Autenticación (authentication): ¿quién eres? Verifica la identidad mediante algo que sabes (contraseña), algo que tienes (dispositivo de seguridad, código de un móvil), o algo que eres (biometría). Autorización (authorization): ¿qué puedes hacer? Una vez verificada la identidad, determina qué recursos y acciones están permitidos. Auditoría (auditing): ¿qué hiciste? Registra las acciones realizadas para evidencia, detección de anomalías y respuesta a incidentes.

La relación entre las tres es secuencial y acumulativa. La autenticación sin autorización es un sistema que verifica identidad pero no controla acceso; la autorización sin auditoría es un sistema que controla acceso pero no puede demostrar su uso ni detectar abusos; la auditoría sin autenticación es inútil, porque no se sabe a quién atribuir las acciones. El examen presenta con frecuencia escenarios donde falta una de las tres, y pide identificar el vacío de control resultante.

Fase	Pregunta	Mecanismo típico	Falla si falta
Autenticación	¿Quién eres?	Contraseña + 2SV, clave de seguridad, SSO federado	Credenciales robadas o adivinadas permiten acceso
Autorización	¿Qué puedes hacer?	Roles, permisos, políticas de acceso	Acceso no limitado, exfiltración o modificación indebida
Auditoría	¿Qué hiciste?	Audit logs, revisión de accesos, alertas	Sin evidencia, no hay detección ni capacidad de respuesta

La relación práctica entre las tres fases se puede ilustrar con un caso típico de negocio. Un analista financiero se autentica con contraseña y 2SV en su portátil corporativo (autenticación); su pertenencia al grupo "finanzas-analisis" le otorga un rol de lectura sobre las tablas de reporting pero no sobre las tablas maestras de nómina (autorización); y cada consulta que ejecuta queda registrada con marca temporal, identidad y tabla consultada en los logs de administración de datos (auditoría). Si la organización necesita responder a la pregunta "¿accedió alguien externo a datos de nómina la semana pasada?", solo puede hacerlo porque las tres fases operaron y dejaron evidencia. Retirar cualquiera de ellas rompe la capacidad de respuesta completa.

En la práctica, la autorización se resuelve con políticas: en Google Cloud, un binding asigna un rol (conjunto de permisos) a un miembro (usuario, grupo, service account, dominio) sobre un recurso de la jerarquía. Un permiso es el derecho más bajo (por ejemplo, storage.objects.get); un rol es un empaquetado de permisos (por ejemplo, roles/storage.objectViewer); y la política de IAM es el conjunto de bindings aplicables a un recurso. Este vocabulario es el que el examen espera, y aparece en casi todas las preguntas de este subtema.

La auditoría, a menudo la fase más descuidada en las conversaciones iniciales de seguridad, es la que sostiene la confianza demostrable. Sin registros de actividad, la organización no puede responder a tres preguntas básicas tras un incidente: qué identidad accedió, qué hizo exactamente y cuándo. Los audit logs de Google Cloud capturan eventos de administración (quién cambió políticas y configuraciones) y eventos de datos (accesos a buckets, tablas y otros recursos sensibles), y su retención y consulta habilitan tanto la respuesta a incidentes como la evidencia periódica para auditoría.

La auditoría cumple además una función disuasoria: saber que las acciones quedan registradas y son revisables modera el uso indebido de privilegios legítimos y facilita la detección de patrones anómalos (accesos fuera del horario, descargas masivas, cambios de política realizados por identidades inusuales). Efecto disuasorio y evidencia no son fines distintos: ambos se apoyan en el mismo requisito de que la actividad quede registrada de forma atribuible e inmutable.

Un punto que une las tres fases con el negocio es la trazabilidad. En procesos con requisitos de segregación de funciones —quien aprueba no ejecuta, quien ejecuta no audita—, la combinación de autenticación fuerte, autorización granular y auditoría inmutable es lo que permite demostrar que una transacción fue autorizada por la persona correcta y ejecutada por otra distinta. Ese control no es verificable con ninguna de las fases por separado.

Subtema 2: Two-step verification (2SV) y autenticación reforzada

Una sola capa de autenticación (una contraseña) es frágil: las contraseñas se filtran, se reutilizan, se phishingan y se fuerzan por fuerza bruta. El two-step verification (2SV), también conocido como autenticación de dos factores (2FA), añade un segundo factor independiente después de la contraseña, de modo que el compromiso de la contraseña por sí solo no basta para acceder.

El valor de negocio del 2SV es alto y directo: los ataques de credential stuffing y phishing automatizado se neutralizan en gran medida cuando el segundo factor es necesario, porque el atacante tendría que también comprometer el dispositivo o el canal del segundo factor. En entornos corporativos, esto se traduce en menos incidentes por acceso no autorizado, menos coste de recuperación de cuentas, y una evidencia ante auditoría de que la organización aplica controles de autenticación reforzada.

El 2SV también cambia la economía del ataque para el agresor. Mientras que un volumen masivo de contraseñas filtradas puede probarse de forma automatizada contra un servicio, la exigencia de un segundo factor desalienta ese ataque a escala porque cada intento requiere un factor adicional que no se puede automatizar tan fácilmente. Para el negocio, esto significa que una inversión modesta en 2SV reduce de forma desproporcionada el riesgo de compromiso de cuentas, especialmente frente a amenazas automatizadas de bajo coste para el atacante.

En Google Cloud y en el ecosistema Google, el 2SV se configura a nivel de organización o de cuenta, y puede aplicarse selectivamente por grupo o por rol. Para usuarios administradores y cuentas con privilegios elevados, el 2SV debe ser obligatorio, no opcional: son las cuentas de mayor impacto si se comprometen. Los métodos de segundo factor incluyen códigos de aplicaciones autenticadoras, llaves de seguridad FIDO (incluyendo passkeys), y códigos de un solo uso.

La decisión de negocio sobre cuánto exigir de la autenticación se razona por el nivel de riesgo de la cuenta, no por el número de usuarios. Un patrón habitual es aplicar 2SV diferencial: obligatorio y con factor resistente al phishing (llave FIDO) para administradores y para acceso a producción; obligatorio pero con factor más cómodo (aplicación autenticadora) para el resto de la plantilla; y revisión reforzada para cuentas de servicio con privilegios de escritura. Este enfoque proporcional evita que la fricción de seguridad paralice a la organización sin dejar huecos en las cuentas de mayor impacto.

Para un responsable de negocio, el indicador que resume la calidad del control de autenticación no es "cuántos usuarios tienen 2SV", sino "qué proporción de cuentas con privilegios de administración lo tienen, y con qué factor". La primera cifra puede sonar satisfactoria con una adopción amplia pero incompleta en las cuentas críticas; la segunda expone exactamente dónde queda el riesgo si una contraseña se filtra.

Conviene distinguir también entre 2SV y SSO (single sign-on). El SSO centraliza la autenticación en un único proveedor de identidad, de modo que el usuario se autentica una vez y accede a múltiples aplicaciones sin repetir credenciales. El SSO reduce la fatiga de contraseñas y el número de credenciales que el usuario debe recordar (y que un atacante puede phishingar), pero no sustituye al 2SV: un SSO comprometido abre todas las aplicaciones federadas, por lo que la protección del punto de autenticación central con 2SV resistente al phishing es incluso más crítica que en un entorno sin federación. En la práctica, la arquitectura de identidad moderna combina ambos: SSO para la experiencia y la gobernanza, 2SV para la resistencia al compromiso de la cuenta.

Una distinción importante para el examen: 2SV se refiere a dos pasos o dos factores de autenticación, no necesariamente a dos canales del mismo tipo (como dos contraseñas). El valor está en la independencia de los factores: algo que sabes + algo que tienes, o algo que tienes + algo que eres. La duplicación de factores del mismo tipo no aporta la misma resistencia al ataque.

Para el líder de negocio, la decisión de política sobre 2SV se razona en términos de riesgo y de fricción operativa. Exigir 2SV a toda la plantilla sin excepción es simple de comunicar pero puede introducir fricción donde el riesgo es bajo; eximirla para "usuarios comunes" crea un hueco explotable mediante phishing dirigido a cuentas menos vigiladas. La recomendación madura es una política por defecto con 2SV obligatorio, excepciones mínimas y justificadas, y refuerzo adicional (llaves FIDO o passkeys) para las cuentas de mayor privilegio. Documentar la excepción es tan importante como aplicarla: ante un auditor, una excepción sin justificación registrada se lee como una ausencia de control.

Ejemplo Práctico

Verificar el estado de las cuentas de servicio y los bindings de IAM en un proyecto permite identificar riesgos de acceso excesivo sin necesidad de herramientas externas. La revisión de identidad no requiere un producto especializado: comienza con consultas de lectura que cualquiera con los permisos adecuados puede ejecutar.

gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role, bindings.members)"

Esta consulta lista cada rol asignado y los miembros que lo poseen. Un rol de propietario (roles/owner) asignado a una cuenta de servicio o a un grupo grande es un hallazgo de riesgo: el rol de propietario incluye permisos de administración completa, y su asignación a identidades de máquina o a colectivos amplios viola least privilege. Revisar periódicamente esta tabla es una de las acciones de higiene de identidad con mayor retorno.

Inspeccionar las service accounts del proyecto permite identificar identidades de máquina y su estado:

gcloud iam service-accounts list \
  --format="table(email, disabled, displayName)"

Aquí conviene buscar dos señales: cuentas de servicio habilitadas que no se usan (superficie de ataque que se puede retirar) y cuentas con nombres genéricos o heredadas de migraciones anteriores, cuyo propósito real ya nadie conoce. Consultar los permisos concretos de un rol antes de asignarlo evita sorpresas:

gcloud iam roles describe roles/storage.objectViewer

Este tipo de inspección de lectura es la base de una revisión de accesos: primero se recopila qué identidades existen y qué poseen, después se contrasta con la función de negocio esperada de cada una, y solo entonces se decide qué corregir. Sin inventario previo, cualquier revisión es subjetiva y no supera una auditoría.

Para gestionar la membresía de grupos y centralizar el acceso, la consola y la CLI permiten añadir o retirar miembros de un grupo de forma controlada:

gcloud identity groups members add \
  --group-email=GROUP_EMAIL \
  --member-email=USER_EMAIL

La operación inversa (remove) revoca el acceso heredado por el grupo de inmediato, lo que convierte a los grupos en el mecanismo más rápido para responder a una salida del equipo o a un cambio de rol.

Subtema 3: Roles y permisos en la jerarquía de Google Cloud

La jerarquía de recursos de Google Cloud determina dónde se aplican las políticas de IAM. En orden descendente: la organización (raíz de todos los recursos), las carpetas (unidades de agrupación por unidad de negocio o entorno), los proyectos (unidades de aislamiento, permisos y facturación), y los recursos individuales (instancias, buckets, bases de datos). Las políticas de IAM se heredan hacia abajo en esta jerarquía, de modo que un binding en la organización afecta a todos los recursos dentro de ella, y un binding en un proyecto afecta a todos los recursos de ese proyecto.

Los roles se clasifican en tres categorías:

Roles básicos (Basic): roles/owner, roles/editor, roles/viewer. Son los más antiguos y amplios; roles/owner otorga control total, y su uso generalizado se considera una mala práctica porque viola least privilege. Google Cloud recomienda migrar hacia roles predefinidos o personalizados más granulares.
Roles predefinidos (Predefined): empaquetados por servicio (por ejemplo, roles/storage.admin, roles/bigquery.dataViewer), con permisos diseñados para tareas comunes. Son el punto de partida recomendado para la mayoría de los casos de uso, porque equilibran granularidad y simplicidad de gestión.
Roles personalizados (Custom): creados por la organización con conjuntos de permisos específicos, cuando ni los básicos ni los predefinidos encajan con el principio de least privilege. Aportan granularidad máxima, pero añaden coste de mantenimiento y requieren disciplina para evitar la proliferación de roles ad-hoc.

Una distinción que el examen explota es la relación entre permiso, rol y política. El permiso es atómico y específico de un servicio (por ejemplo, publicar o leer objetos de almacenamiento); el rol agrupa permisos en una unidad reutilizable diseñada alrededor de una tarea; y la política de IAM es el documento que, aplicado a un recurso de la jerarquía, declara qué miembros tienen qué roles. Confundir los niveles lleva a errores de interpretación típicos: asignar un permiso cuando debería asignarse un rol, o modificar una política pensando que se cambia un rol. En el examen, casi todas las preguntas de IAM se formulan en estos tres términos, y la respuesta correcta depende de identificar en qué nivel está el problema.

Tipo de rol	Granularidad	Facilidad de gestión	Riesgo principal	Cuándo usarlo
Básico (owner/editor/viewer)	Muy amplia	Alta	Exceso de privilegios	Evitarlo salvo para casos de administración temporal
Predefinido	Media-alta	Alta	A veces más permisos que los necesarios	Punto de partida para la mayoría de tareas
Personalizado	Ajustada	Media	Proliferación y mantenimiento	Cuando least privilege lo exige explícitamente

La autorización efectiva en un recurso depende de la combinación de políticas en toda la jerarquía. Esto tiene una consecuencia práctica importante: un permiso concedido a nivel de organización puede ser heredado por un proyecto donde no se esperaba, y un permiso denegado explícitamente en un nivel inferior puede anular una concesión superior. Entender esta superposición es clave para razonar correctamente en preguntas de escenario sobre accesos inesperados.

Un escenario frecuente en el examen es el siguiente: un administrador de proyecto cree que sus usuarios solo tienen acceso dentro de ese proyecto, pero una política concedida en la carpeta o en la organización les otorga permisos adicionales sobre otros recursos. La respuesta correcta siempre apunta a revisar la jerarquía completa y a reasignar permisos en el nivel correcto, no a asumir que el nivel del proyecto es el único que cuenta. Otro escenario habitual es el de un usuario que conserva acceso tras cambiar de equipo: aquí el fallo no es técnico, sino de proceso —no se revisó la membresía de grupos ni los bindings individuales cuando cambió la función—, y la respuesta correcta insiste en la revisión periódica de accesos como control.

También conviene retener la distinción entre política de IAM (quién tiene qué rol sobre un recurso de la jerarquía) y política organizacional (organizational policy): la primera controla acceso; la segunda impone restricciones de configuración a nivel de organización o carpeta (por ejemplo, prohibir la creación de buckets públicos, o restringir regiones permitidas). Ambas son controles de gobierno, pero responden a preguntas distintas: la política de IAM pregunta "quién puede hacer esto", y la política organizacional pregunta "qué está permitido configurar aquí". El examen las contrasta para comprobar que se distingue el control de acceso del control de configuración.

Una tercera distinción relevante es la que separa identidad administrada por Google Cloud de identidad federada desde un proveedor externo. En muchos entornos corporativos, los usuarios existen primero en un directorio corporativo (por ejemplo, un IdP de la organización) y se federan hacia Google Cloud. Eso centraliza la gestión de credenciales y permite aplicar las políticas de 2SV y de baja de empleado en el directorio de origen, pero añade un punto de configuración crítico: si la federación se configura con confianza amplia o sin controles en el proveedor de origen, un compromiso allí se traslada directamente a los recursos de la nube. El modelo correcto exige que la federación herede los controles de autenticación del directorio corporativo, no que los relaje.

Subtema 4: Principio de menor privilegio (least privilege)

El principio de least privilege establece que una identidad (persona, grupo o service account) debe tener únicamente los permisos necesarios para realizar su función, y nada más. Es el principio más citado y el menos aplicado de la seguridad cloud, porque la comodidad de asignar roles amplios (owner, editor) choca con el coste de mantener permisos granulares.

Las consecuencias de no aplicar least privilege son concretas. Un usuario con roles/editor en un proyecto donde solo necesita leer datos puede modificar o eliminar recursos por error o por intención. Una service account con permisos de administración sobre una carpeta entera amplía el impacto potencial de un compromiso de sus claves. Cada permiso excesivo es un incremento de la superficie de ataque y del riesgo de movimiento lateral si una identidad se ve comprometida.

La aplicación práctica de least privilege combina tres hábitos:

Asignar el rol predefinido más específico que cubra la tarea, en lugar de recurrir a roles básicos amplios.
Revisar periódicamente los bindings (revisión de accesos o access review) y retirar permisos que ya no corresponden a la función actual de cada miembro.
Usar roles personalizados o condicionales cuando la función requiera menos de lo que un rol predefinido otorga, o cuando el acceso deba limitarse por contexto (por ejemplo, solo desde la red corporativa).

Un error frecuente al aplicar least privilege es confundirlo con la minimización de usuarios: least privilege no se trata de tener menos personas con acceso, sino de que cada persona (o service account) tenga exactamente los permisos que su función requiere. Pueden existir diez usuarios con acceso correcto y mínimo, y ser más seguro que dos usuarios con permisos de propietario sobre recursos que no gestionan. La métrica que interesa al riesgo es la distribución de privilegios por identidad, no la cantidad de identidades con acceso.

Otro error es tratar least privilege como un estado que se alcanza una vez. En entornos dinámicos —nuevos servicios, nuevos equipos, cambios de rol—, los privilegios se acumulan de forma natural con el tiempo (privilege creep). La respuesta no es frenar el cambio de negocio, sino institucionalizar la revisión: cuando alguien cambia de función, se revisan sus bindings; cuando un proyecto se archiva, se retiran sus accesos; cuando una service account deja de usarse, se deshabilita. Least privilege es un hábito de operación, no un documento de diseño.

El examen valora la capacidad de reconocer cuándo una configuración viola least privilege y de proponer la respuesta correcta: reducir el rol a uno más específico, separar funciones en distintas identidades, o condicionar el acceso al contexto necesario.

Más allá del examen, least privilege tiene una consecuencia de negocio directa sobre el coste del incidente. Cuando una identidad se compromete, el daño posible es proporcional a los permisos que esa identidad posee: una cuenta con permisos de lectura sobre un conjunto acotado de recursos limita el alcance de la exfiltración; una cuenta con permisos de administración sobre la organización completa convierte un incidente aislado en un compromiso transversal. Por eso, en la evaluación de riesgo, el número de identidades con privilegios elevados es un indicador de primer orden, y su reducción sostenida en el tiempo es un objetivo de programa.

Aplicar least privilege también afecta a la velocidad del negocio, no solo a la seguridad. Permisos excesivos acortan el camino en el corto plazo (nadie espera aprobación para ejecutar una acción), pero generan deuda de riesgo que se paga después en auditorías, en incidentes o en la revisión costosa que hay que hacer cuando un proyecto crece y nadie recuerda por qué ciertas identidades tienen ciertos accesos. El equilibrio recomendado es conceder rápido permisos granulares y específicos, y revisar de forma periódica y automatizable; conceder amplio y revisar poco es la combinación que produce los hallazgos de auditoría más frecuentes.

Subtema 5: Grupos y service accounts

Los grupos son colecciones de usuarios (y a veces de otras identidades) que se tratan como una unidad a la hora de asignar roles. Su valor es la eficiencia y la consistencia: en lugar de asignar un rol a cada usuario de un equipo, se asigna una vez al grupo, y la membresía del grupo se gestiona de forma centralizada. Cuando alguien se une al equipo, recibe acceso por pertenencia al grupo; cuando se va, se retira del grupo y pierde el acceso sin necesidad de revocar cada binding individual. En sectores regulados, los grupos también son el mecanismo habitual para gestionar acceso temporal o por proyecto, y su revisión periódica es un control de auditoría rutinario.

Los grupos presentan además una ventaja de auditoría: la membresía de un grupo es una única fuente de verdad consultable, de modo que responder a la pregunta "¿quiénes pueden ver los datos de este proyecto?" se reduce a listar los grupos con bindings sobre el proyecto y sus miembros, en lugar de reconstruir el acceso identidad por identidad. Para un auditor, esa centralización reduce el tiempo de la revisión y aumenta la confianza en el resultado; para el negocio, reduce el coste operativo de la gobernanza de accesos.

La disciplina de grupos exige, sin embargo, dos hábitos que a menudo se descuidan. El primero es la revisión de membresías: un grupo que acumula miembros sin revisión termina convirtiéndose en un canal de acceso heredado que nadie cuestiona, y un miembro que dejó el equipo pero no se retiró del grupo conserva privilegios indefinidamente. El segundo es el diseño de los grupos: nombrarlos y estructurarlos según la función de negocio (equipo, proyecto, nivel de criticidad) en lugar de según la herramienta o la fecha de creación, de modo que su significado sea evidente cuando un auditor o un nuevo responsable los revise. Un grupo llamado por su función se auto-documenta; uno llamado por su origen obliga a preguntar qué representa.

Las service accounts son identidades para máquinas y aplicaciones, no para personas. Una aplicación que necesita leer de un bucket, un job de procesamiento que escribe en una base de datos, o un clúster de GKE que despliega recursos, todo ello se autentica con una service account y sus claves o tokens. El riesgo particular de las service accounts es que operan de forma no interactiva: no hay un humano que confirme un segundo factor, y sus claves, si se filtran, permiten acceso automatizado y difícil de detectar. Por ello, las buenas prácticas incluyen: asignar la función más específica posible a cada service account, rotar claves periódicamente, evitar claves de larga duración cuando el entorno soporte identidades de corta duración (como Workload Identity en GKE), y revisar qué service accounts existen y cuáles están realmente en uso.

La distinción entre identidad humana e identidad de máquina tiene una consecuencia de gobierno importante: los controles de autenticación aplicados a personas (2SV, revisión de contraseñas, formación de concienciación) no protegen directamente a las service accounts. Proteger estas últimas exige controles distintos —rotación de claves, permisos mínimos, identidades de corta duración, monitoreo de uso—. Un programa de identidad maduro trata ambas categorías con el mismo rigor, pero con instrumentos diferentes; confundirlas deja un flanco que el examen y los auditores exploran con frecuencia.

Un patrón de riesgo habitual con service accounts es el exceso de herencia: una aplicación creada para una tarea pequeña recibe, por inercia, el rol de propietario del proyecto porque "así funciona siempre". Transcurridos meses, esa service account sigue con privilegios completos aunque su función original solo necesitara escritura en una tabla concreta. La revisión debe contrastar los permisos reales con la función esperada de cada service account, y reasignar el rol mínimo. Un segundo patrón es la service account huérfana: creada para un script o una migración puntual que ya no existe, permanece habilitada con sus claves vigentes. Retirar identidades sin uso activo es una de las acciones más simples y de mayor retorno en una revisión de identidad.

Existe además una dimensión de coste y de operación que el líder de negocio debe conocer: cada identidad de máquina añade superficie a gestionar —claves por rotar, permisos por revisar, logging que revisar—, y su proliferación sin gobernanza termina convirtiéndose en deuda operativa. Un estándar interno que defina un patrón de service account por tipo de aplicación (lectura, escritura, despliegue), con roles predefinidos aprobados y una convención de nombres clara, reduce tanto el riesgo como el coste de la revisión posterior. La disciplina temprana en la creación ahorra el rediseño tardío.

Señal en service accounts	Riesgo asociado	Respuesta recomendada
Rol de propietario o editor heredado	Impacto amplio si la clave se filtra	Reasignar al rol predefinido más específico
Claves de larga duración sin rotación	Compromiso silencioso y duradero	Rotar claves y migrar a identidades de corta duración
Cuenta creada sin uso activo desde hace meses	Superficie de ataque innecesaria	Deshabilitar o eliminar tras verificar
Mismo patrón de permisos en decenas de cuentas	Propagación de un error de diseño	Estándar de roles por caso de uso y revisión centralizada

Tipo de identidad	Para quién	Autenticación	Riesgo principal	Control recomendado
Usuario individual	Personas	Contraseña + 2SV	Robo de credenciales humanas	2SV obligatoria, revisión de accesos
Grupo	Colecciones de personas	Membresía del grupo	Membresías obsoletas	Revisión periódica de membresía
Service account	Aplicaciones y máquinas	Claves o tokens	Claves filtradas, privilegios heredados	Least privilege, rotación, Workload Identity
Cuenta de federación	Usuarios externos o de otro IdP	Federación de identidad	Configuración de confianza	Políticas de federación estrictas

Como síntesis del tema, la gestión de identidad y acceso es el control primario de la seguridad en la nube: mientras el perímetro físico pierde relevancia, la identidad y su gobernanza pasan a ser el punto donde se decide quién entra, qué hace y cómo se demuestra. Un líder que domina el ciclo autenticación-autorización-auditoría, el modelo de roles de Google Cloud y el principio de least privilege puede evaluar la madurez de la identidad de su organización, entender los hallazgos de un auditor, y priorizar inversiones en identidad con criterio de riesgo de negocio, no solo de consejo técnico.

El ciclo de vida completo de una identidad en la nube se puede resumir en cuatro etapas, y cada una tiene su control característico:

Etapa del ciclo de vida	Pregunta de control	Control típico	Riesgo si se omite
Alta (provisioning)	¿Esta identidad debe existir y con qué rol?	Aprobación, asignación de rol mínimo, alta en grupo	Creación innecesaria o con privilegios excesivos
Uso operativo	¿Sigue usándose con la función actual?	2SV, logs de actividad, revisión de accesos	Acceso no supervisado o uso indebido
Cambio de función	¿Los permisos siguen correspondiendo?	Revisión al cambiar de equipo, reasignación de grupo	Acumulación de privilegios (privilege creep)
Baja (deprovisioning)	¿Se revocó todo el acceso al salir?	Baja del grupo, deshabilitación de cuenta, eliminación de claves	Cuentas huérfanas explotables indefinidamente

Esta tabla conecta directamente con la exigencia de auditoría: un auditor no solo pregunta "¿qué permisos tienen los usuarios?", sino "¿cómo demuestran que revisan y retiran los accesos que ya no se necesitan?". La respuesta madura no es una herramienta, sino el hábito documentado de revisión periódica, con evidencia de qué se revisó, qué se decidió y qué se corrigió.

Temas relacionados: Security and Trust Principles in Google Cloud, Encryption, Key Management and Data Protection, Network Security, VPC and Perimeter Defense, Compliance, Data Sovereignty and Data Residency.

Errores Comunes

Error: Confundir autenticación con autorización, o tratarlas como sinónimos. → Solución: Autenticación verifica identidad (¿quién eres?); autorización determina permisos (¿qué puedes hacer?). Un sistema puede autenticar correctamente a un usuario y aun así otorgarle acceso demasiado amplio si la autorización está mal configurada. El examen evalúa esta distinción con preguntas de escenario donde una identidad accede legítimamente pero realiza acciones no permitidas.
Error: Asignar roles básicos como roles/owner o roles/editor de forma generalizada por comodidad. → Solución: Usar roles predefinidos específicos por servicio, y recurrir a roles personalizados solo cuando la granularidad lo justifica. Los roles básicos amplían la superficie de ataque y violan least privilege; su uso debe restringirse a escenarios temporales de administración, no a la operación diaria.
Error: Crear service accounts por defecto para cada aplicación o script, con permisos heredados de proyectos o carpetas. → Solución: Asignar a cada service account únicamente la función más específica necesaria para su tarea, evitar claves de larga duración cuando el entorno soporte identidades de corta duración, y revisar periódicamente qué service accounts existen y cuáles se pueden eliminar. Cada service account sin uso activo es riesgo residual que debe retirarse.
Error: Instalar 2SV solo en cuentas de usuario humanas y no en cuentas administradoras o de servicio con privilegios elevados. → Solución: Exigir autenticación reforzada (2SV o equivalente) para todas las cuentas con privilegios de administración, incluidas las cuentas de servicio cuando su uso lo permite, y para el acceso a proyectos de producción. El 2SV más efectivo es el que cubre el acceso de mayor impacto, no el de mayor número de usuarios.
Error: Confiar en que la política de IAM visible en un recurso es toda la autorización efectiva, ignorando la herencia desde niveles superiores de la jerarquía. → Solución: Recordar que las políticas de IAM se heredan hacia abajo en la jerarquía (organización → carpetas → proyectos → recursos) y que la autorización efectiva resulta de la combinación de bindings en todos los niveles aplicables. Un permiso concedido en la carpeta se aplica a todos sus proyectos; un examen o una revisión de acceso que solo inspeccione el nivel del proyecto puede pasar por alto concesiones heredadas. La verificación correcta revisa la jerarquía completa, no un solo nivel.

Puntos para el Examen

Los puntos siguientes recogen las ideas que con más frecuencia determinan la respuesta correcta en las preguntas de este dominio. Conviene no solo memorizarlos, sino poder aplicarlos a un escenario descrito, porque así se formulan casi todas las preguntas de IAM en el examen.

🎯 Punto clave 1: Autenticación, autorización y auditoría son las tres fases del control de acceso y siempre se evalúan juntas. La autenticación verifica identidad; la autorización determina permisos; la auditoría registra actividad para evidencia y respuesta. Una pregunta de escenario casi siempre busca identificar cuál de las tres falta.

🎯 Punto clave 2: El two-step verification (2SV) añade un segundo factor independiente a la contraseña, y su valor de negocio está en neutralizar el compromiso de credenciales por phishing o credential stuffing. Debe aplicarse prioritariamente a cuentas con privilegios elevados, no solo a usuarios comunes.

🎯 Punto clave 3: IAM se aplica sobre una jerarquía (organización → carpetas → proyectos → recursos) con herencia de políticas hacia abajo. Los roles pueden ser básicos (amplios, a evitar), predefinidos (punto de partida recomendado) o personalizados (granularidad máxima). Entender la herencia y la superposición de políticas es clave para razonar sobre accesos inesperados.

🎯 Punto clave 4: Least privilege es el principio de otorgar el mínimo necesario. Reconocer una configuración que lo viola (roles amplios, service accounts con permisos heredados, grupos con membresías obsoletas) y proponer la corrección (rol más específico, revisión de accesos, condicionamiento) es una pregunta frecuente y de alto valor.

🎯 Punto clave 5: Los grupos gestionan accesos de personas de forma eficiente; las service accounts gestionan accesos de aplicaciones y máquinas. Las service accounts son una fuente particular de riesgo por su operación no interactiva y sus claves automatizadas, y requieren least privilege, rotación y revisión periódica, igual que las cuentas humanas.

Recursos Externos

IAM documentation en Google Cloud — Referencia completa de identidad y acceso, incluyendo roles, permisos, políticas y mejores prácticas, con ejemplos de política y guías por servicio.
Understanding roles — Explicación detallada de roles básicos, predefinidos y personalizados, y cómo se combinan en la jerarquía.
IAM best practices — Guía de prácticas recomendadas, incluyendo least privilege, revisión de accesos y gestión de service accounts.
Service accounts — Documentación sobre identidades de máquina, claves, rotación y uso con Workload Identity.
Cloud Identity — Plataforma de identidad gestionada para usuarios, grupos y dispositivos, incluyendo configuración de 2SV y federación.

Autoevaluación Rápida

Las preguntas siguientes reproducen el tipo de razonamiento que el examen evalúa: partir de un escenario concreto, identificar la fase o el principio involucrado, y justificar la respuesta correcta con el lenguaje preciso del dominio.

Pregunta: Un usuario se autentica correctamente con su contraseña, pero no tiene el permiso necesario para leer un bucket de almacenamiento. ¿Qué fase del control de acceso ha fallado, o está funcionando correctamente? Respuesta: La autenticación ha funcionado correctamente: la identidad se verificó con la contraseña. La autorización también está funcionando, en el sentido de que el usuario no tiene el permiso para ese bucket, y el sistema lo deniega correctamente. No hay fallo: el sistema está actuando según lo configurado. Si el usuario debería tener acceso, la corrección es de autorización (asignar el rol apropiado sobre el bucket o su jerarquía), no de autenticación.
Pregunta: ¿Por qué el 2SV se considera un control de autenticación, y no de autorización? Respuesta: Porque el 2SV refuerza la verificación de identidad (¿quién eres?) al exigir un segundo factor además de la contraseña; no modifica qué recursos o acciones el usuario puede realizar (eso es autorización). Su valor está en reducir el riesgo de que una identidad sea suplantada, no en limitar el alcance de una identidad ya verificada.
Pregunta: Un equipo de análisis de datos necesita leer tablas en BigQuery pero no modificarlas ni administrar el proyecto. ¿Qué rol y configuración se recomienda, y qué error se debe evitar? Respuesta: Asignar un rol predefinido de lectura específica para BigQuery a nivel de proyecto o de las tablas relevantes (por ejemplo, roles/bigquery.dataViewer), idealmente a través de un grupo que represente al equipo. El error a evitar es asignar roles/editor o roles/owner por comodidad, o un rol de administración de BigQuery que incluya permisos de escritura y administración innecesarios. Se aplica least privilege: el mínimo necesario para la tarea de lectura.
Pregunta: ¿Cuál es el riesgo principal de una service account con permisos de propietario en una carpeta, y cómo se mitiga? Respuesta: El riesgo es que un compromiso de sus claves o de la aplicación que la usa otorgue control total sobre todos los proyectos y recursos de esa carpeta, amplificando el impacto de un incidente. La mitigación es aplicar least privilege: reasignar a la service account un rol predefinido o personalizado que cubra únicamente las operaciones necesarias, rotar claves periódicamente, preferir identidades de corta duración (como Workload Identity) sobre claves de larga duración, y revisar periódicamente las service accounts activas para retirar las que ya no se usan.
Pregunta: ¿Por qué los grupos son preferibles a la asignación individual de roles cuando se gestiona un equipo de 20 personas? Respuesta: Porque los grupos centralizan la gestión de acceso: el rol se asigna una vez al grupo, y la membresía del grupo se gestiona de forma individual. Cuando alguien se une al equipo, se añade al grupo y hereda el acceso; cuando se va, se retira del grupo y pierde el acceso de inmediato, sin necesidad de revisar y revocar cada binding individual. Esto reduce el riesgo de accesos huérfanos tras una salida, y facilita la revisión periódica de accesos que exigen los auditores. Un punto adicional que conviene tener presente en la conversación con dirección: con grupos, la respuesta a "¿quién puede ver estos datos?" se centraliza en la membresía de pocos grupos, lo que reduce el tiempo de auditoría y la probabilidad de que un acceso individual pase desapercibido.