En esta sección se explica cómo usar Cloud Identity para gestionar las identidades que usan tus empleados para acceder a los servicios de Google Cloud.
Proveedor de identidades externo como fuente de información veraz
Te recomendamos que federes tu cuenta de Cloud Identity con tu proveedor de identidades. La federación te ayuda a asegurarte de que tus procesos de gestión de cuentas se apliquen a Google Cloud y a otros servicios de Google.
Si no tienes ningún proveedor de identidades, puedes crear cuentas de usuario directamente en Cloud Identity.
En el siguiente diagrama se muestra una vista general de la federación de identidades y el inicio de sesión único (SSO). Usa Microsoft Active Directory, ubicado en el entorno local, como proveedor de identidades de ejemplo.
En este diagrama se describen las siguientes prácticas recomendadas:
- Las identidades de los usuarios se gestionan en un dominio de Active Directory que se encuentra en el entorno local y está federado con Cloud Identity. Active Directory usa Google Cloud Directory Sync para aprovisionar identidades en Cloud Identity.
- Los usuarios que intenten iniciar sesión en los servicios de Google se redirigirán al proveedor de identidades externo para usar el inicio de sesión único con SAML y autenticarse con sus credenciales. No se sincroniza ninguna contraseña con Cloud Identity.
En la siguiente tabla se incluyen enlaces a guías de configuración de proveedores de identidades.
| Proveedor de identidades | Asesoramiento |
|---|---|
| Active Directory | |
| Microsoft Entra ID (antes Azure AD) | |
| Otros proveedores de identidades externos (por ejemplo, Ping u Okta) |
Te recomendamos que apliques la autenticación multifactor en tu proveedor de identidades con un mecanismo resistente al phishing, como una llave de seguridad Titan.
La configuración recomendada de Cloud Identity no se automatiza mediante el código de Terraform de este plano. Consulta los controles administrativos de Cloud Identity para ver la configuración de seguridad recomendada que debes configurar además de desplegar el código de Terraform.
Grupos para el control de acceso
Un principal es una identidad a la que se le puede conceder acceso a un recurso. Entre los principales se incluyen cuentas de Google de usuarios, grupos de Google, cuentas de Google Workspace, dominios de Cloud Identity y cuentas de servicio. Algunos servicios también te permiten conceder acceso a todos los usuarios que se autentiquen con una cuenta de Google o a todos los usuarios de Internet. Para que un principal pueda interactuar con los servicios de Google Cloud , debes asignarle roles en Gestión de Identidades y Accesos (IAM).
Para gestionar los roles de IAM a gran escala, te recomendamos que asignes usuarios a grupos en función de sus funciones y requisitos de acceso, y que luego concedas roles de IAM a esos grupos. Debes añadir usuarios a los grupos mediante los procesos de tu proveedor de identidades para crear grupos y añadir miembros.
No recomendamos asignar roles de gestión de identidades y accesos a usuarios concretos, ya que las asignaciones individuales pueden aumentar la complejidad de la gestión y la auditoría de roles.
El blueprint configura grupos y roles para que tengan acceso de solo lectura a los recursos de la base. Te recomendamos que implementes todos los recursos de la blueprint a través de la canalización de la base y que no concedas roles a los usuarios ni a los grupos para modificar los recursos de la base fuera de la canalización.
En la siguiente tabla se muestran los grupos que se configuran mediante el plano para ver los recursos de la base.
| Nombre | Descripción | Roles | Ámbito |
|---|---|---|---|
grp-gcp-org-admin@example.com | Administradores con muchos privilegios que pueden conceder roles de gestión de identidades y accesos a nivel de organización. Pueden acceder a cualquier otro rol. No se recomienda usar este privilegio a diario. | Administrador de la organización | organización |
grp-gcp-billing-admin@example.com |
Administradores con muchos privilegios que pueden modificar la cuenta de facturación de Cloud. No se recomienda usar este privilegio a diario. | Administrador de cuentas de facturación | organización |
grp-gcp-billing-viewer@example.com | El equipo responsable de ver y analizar el gasto de todos los proyectos. | Lector de cuenta de facturación | organización |
| Usuario de BigQuery | proyecto de facturación | ||
grp-gcp-audit-viewer@example.com |
El equipo responsable de auditar los registros relacionados con la seguridad. | proyecto de registro | |
grp-gcp-security-reviewer@example.com |
El equipo responsable de revisar la seguridad en la nube. | Revisor de seguridad | organización |
grp-gcp-network-viewer@example.com |
El equipo responsable de ver y mantener las configuraciones de red. | Lector de red de Compute | organización |
grp-gcp-scc-admin@example.com |
El equipo responsable de configurar Security Command Center. | Editor de administración del centro de seguridad | organización |
grp-gcp-secrets-admin@example.com |
El equipo responsable de gestionar, almacenar y auditar las credenciales y otros secretos que utilizan las aplicaciones. | Administrador de Secret Manager | proyectos de secretos |
grp-gcp-kms-admin@example.com |
El equipo responsable de aplicar la gestión de claves de cifrado para cumplir los requisitos. | Lector de Cloud KMS | kms projects |
A medida que creas tus propias cargas de trabajo sobre la base, creas grupos adicionales y asignas roles de gestión de identidades y accesos en función de los requisitos de acceso de cada carga de trabajo.
Te recomendamos encarecidamente que evites los roles básicos (como Propietario, Editor o Lector) y que utilices roles predefinidos. Los roles básicos son demasiado permisivos y suponen un riesgo de seguridad. Los roles Propietario y Editor pueden provocar una elevación de privilegios y un movimiento lateral, y el rol Lector incluye acceso para leer todos los datos. Para consultar las prácticas recomendadas sobre los roles de gestión de identidades y accesos, consulta el artículo Usar la gestión de identidades y accesos de forma segura.
Cuentas de superadministrador
Los usuarios de Cloud Identity que tengan la cuenta de superadministrador pueden omitir la configuración de SSO de la organización y autenticarse directamente en Cloud Identity. Esta excepción se ha diseñado para que el superadministrador pueda seguir accediendo a la consola de Cloud Identity en caso de que se produzca un error de configuración o una interrupción del SSO. Sin embargo, esto significa que debes tomar medidas de protección adicionales para las cuentas de superadministrador.
Para proteger tus cuentas de superadministrador, te recomendamos que siempre apliques la verificación en dos pasos con llaves de seguridad en Cloud Identity. Para obtener más información, consulta el artículo Prácticas recomendadas de seguridad para proteger cuentas de administrador.
Problemas con cuentas de usuario personales
Si no utilizabas Cloud Identity ni Google Workspace antes de incorporar Google Cloud, es posible que los empleados de tu organización ya estén usando cuentas de consumidor asociadas a sus identidades de correo corporativas para acceder a otros servicios de Google, como Google Marketing Platform o YouTube. Las cuentas de consumidor son propiedad de los usuarios que las han creado, que también son quienes las gestionan. Como esas cuentas no están bajo el control de tu organización y pueden incluir datos personales y de empresa, debes decidir cómo consolidarlas con otras cuentas de empresa.
Te recomendamos que consolides las cuentas de usuario de consumidor que ya tengas como parte del proceso de incorporación a Google Cloud. Si aún no usas Google Workspace en todas tus cuentas de usuario, te recomendamos que bloquees el acceso a las cuentas de consumidor.
Controles administrativos de Cloud Identity
Cloud Identity tiene varios controles administrativos que no se automatizan con código de Terraform en el blueprint. Te recomendamos que apliques cada uno de estos controles de seguridad de las prácticas recomendadas al principio del proceso de creación de tu base.
| Control | Descripción |
|---|---|
| Implementar la verificación en dos pasos | Las cuentas de usuario pueden verse vulneradas mediante phishing, ingeniería social, ataques de pulverización de contraseñas u otras amenazas. La verificación en dos pasos ayuda a mitigar estas amenazas. Te recomendamos que apliques la verificación en dos pasos en todas las cuentas de usuario de tu organización con un mecanismo resistente al phishing, como las llaves de seguridad Titan u otras llaves basadas en los estándares FIDO U2F (CTAP1) resistentes al phishing. |
| Configurar la duración de las sesiones de los servicios deGoogle Cloud | Los tokens de OAuth persistentes en las estaciones de trabajo de los desarrolladores pueden suponer un riesgo de seguridad si se exponen. Te recomendamos que definas una política de reautenticación para que se requiera la autenticación cada 16 horas con una llave de seguridad. |
| Configurar la duración de las sesiones de los servicios de Google | (Solo para clientes de Google Workspace)
Las sesiones web persistentes en otros servicios de Google pueden suponer un riesgo para la seguridad si se exponen. Te recomendamos que apliques una duración máxima de sesión web y que la ajustes a los controles de duración de sesión de tu proveedor de SSO. |
| Compartir datos de Cloud Identity con los servicios de Google Cloud | Los registros de auditoría de actividad de administrador de Google Workspace o Cloud Identity se suelen gestionar y consultar en la consola de administración, por separado de los registros de tu entorno de Google Cloud . Estos registros contienen información relevante para tu entorno, como eventos de inicio de sesión de usuarios. Google Cloud Te recomendamos que compartas los registros de auditoría de Cloud Identity en tu entorno deGoogle Cloud para gestionar de forma centralizada los registros de todas las fuentes. |
| Configurar la verificación posterior al SSO | El plan de trabajo presupone que has configurado el SSO con tu proveedor de identidades externo. Te recomendamos que habilites una capa de control adicional basada en el análisis de riesgo de inicio de sesión de Google. Después de aplicar este ajuste, es posible que los usuarios vean verificaciones de identidad basadas en riesgo adicionales al iniciar sesión si Google considera que el inicio de sesión de un usuario es sospechoso. |
| Solucionar problemas con cuentas de usuario de consumidor | Los usuarios que tengan una dirección de correo válida en tu dominio, pero no una cuenta de Google, pueden registrarse para obtener cuentas de consumidor no gestionadas. Estas cuentas pueden contener datos corporativos, pero no están controladas por los procesos de gestión del ciclo de vida de tu cuenta. Le recomendamos que tome medidas para asegurarse de que todas las cuentas de usuario sean cuentas gestionadas. |
| Inhabilitar la recuperación de cuentas de superadministrador | La recuperación automática de las cuentas de superadministrador está desactivada de forma predeterminada para todos los clientes nuevos (los clientes actuales pueden tener activado este ajuste). Desactivar este ajuste ayuda a mitigar el riesgo de que un teléfono o un correo electrónico vulnerados, o un ataque de ingeniería social, permitan a un atacante obtener privilegios de superadministrador en tu entorno. Planifica un proceso interno para que un superadministrador pueda ponerse en contacto con otro superadministrador de tu organización si ha perdido el acceso a su cuenta. Además, asegúrate de que todos los superadministradores conozcan el proceso de recuperación con asistencia. |
| Aplicar y supervisar los requisitos de las contraseñas de los usuarios | En la mayoría de los casos, las contraseñas de los usuarios se gestionan a través de tu proveedor de identidades externo, pero las cuentas de superadministrador omiten el SSO y deben usar una contraseña para iniciar sesión en Cloud Identity. Inhabilita la reutilización de contraseñas y monitoriza la seguridad de las contraseñas de los usuarios que las utilicen para iniciar sesión en Cloud Identity, especialmente en las cuentas de superadministrador. |
| Definir políticas sobre el uso de grupos que se apliquen a toda una organización | De forma predeterminada, las cuentas de usuario externas se pueden añadir a grupos en Cloud Identity. Te recomendamos que configures los ajustes de uso compartido para que los propietarios de grupos no puedan añadir miembros externos. Ten en cuenta que esta restricción no se aplica a la cuenta de superadministrador ni a otros administradores delegados con permisos de administrador de Grupos. Como la federación de tu proveedor de identidades se ejecuta con privilegios de administrador, los ajustes para compartir grupos no se aplican a esta sincronización de grupos. Te recomendamos que revises los controles del proveedor de identidades y del mecanismo de sincronización para asegurarte de que los miembros que no pertenecen al dominio no se añadan a los grupos o de que apliques restricciones de grupo. |
Siguientes pasos
- Consulta información sobre la estructura de la organización (el siguiente documento de esta serie).