En esta sección, se presenta cómo usar Cloud Identity para administrar las identidades que usan tus empleados a fin de acceder a los servicios de Google Cloud.
Proveedor de identidad externo como fuente de información
Recomendamos federar tu cuenta de Cloud Identity con tu proveedor de identidad existente. La federación te ayuda a garantizar que los procesos de administración de cuentas existentes se apliquen a Google Cloud y a otros servicios de Google.
Si no tienes un proveedor de identidad existente, puedes crear cuentas de usuario directamente en Cloud Identity.
En el siguiente diagrama, se muestra una vista de alto nivel de la federación de identidades y el inicio de sesión único (SSO). Usa Microsoft Active Directory, ubicado en el entorno local, como el proveedor de identidad de ejemplo.
En este diagrama, se describen las prácticas recomendadas siguientes:
- Las identidades de usuario se administran en un dominio de Active Directory ubicado en el entorno local y se federan en Cloud Identity. Active Directory usa Google Cloud Directory Sync para aprovisionar identidades a Cloud Identity.
- A los usuarios que intentan acceder a los servicios de Google se los redirecciona al proveedor de identidad externo para el inicio de sesión único con SAML, con sus credenciales existentes a fin de autenticarse. No hay contraseñas sincronizadas con Cloud Identity.
En la siguiente tabla, se proporcionan vínculos a la guía de configuración para los proveedores de identidad.
| Proveedor de identidad | Orientación |
|---|---|
| Active Directory | |
| Microsoft Entra ID (anteriormente Azure AD) | |
| Otros proveedores de identidad externos (por ejemplo, Okta o Ping) |
Te recomendamos que apliques la autenticación de varios factores en tu proveedor de identidad con un mecanismo resistente a la suplantación de identidad (phishing) como una llave de seguridad Titan.
La configuración recomendada para Cloud Identity no está automatizada a través del código de Terraform en este plano. Consulta Controles administrativos de Cloud Identity para obtener la configuración de seguridad recomendada que debes configurar, además de implementar el código de Terraform.
Grupos para el control de acceso
Una principal es una identidad a la que se le puede otorgar acceso a un recurso. Las principales incluyen Cuentas de Google para usuarios, Grupos de Google, cuentas de Google Workspace, dominios de Cloud Identity y cuentas de servicio. Algunos servicios también te permiten otorgar acceso a todos los usuarios que se autentican con una Cuenta de Google o a todos los usuarios de Internet. Para que una principal interactúe con los servicios de Google Cloud, debes otorgarles funciones en la administración de identidades y accesos (IAM).
Para administrar 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, luego, les otorgues roles de IAM a esos grupos. Debes agregar usuarios a grupos mediante los procesos en tu proveedor de identidad existente para la creación y membresía de grupos.
No recomendamos otorgar roles de IAM a usuarios individuales, ya que las asignaciones individuales pueden aumentar la complejidad de la administración y la auditoría de los roles.
El plano configura los grupos y los roles para el acceso de solo lectura a los recursos base. Recomendamos que implementes todos los recursos del plano a través de la canalización de base y que no otorgues funciones a los usuarios a grupos para modificar los recursos de base fuera de la canalización.
En la siguiente tabla, se muestran los grupos que configura el plano para ver los recursos de la base.
| Nombre | Descripción | Roles | Alcance |
|---|---|---|---|
grp-gcp-org-admin@example.com |
Administradores con muchos privilegios que pueden otorgar roles de IAM a nivel de la organización. Pueden acceder a cualquier otro rol. No se recomienda este privilegio para el uso 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 este privilegio para el uso diario. | Administrador de cuenta de facturación | organización |
grp-gcp-billing-viewer@example.com |
El equipo responsable de ver y analizar los gastos en todos los proyectos. | Visualizador de cuentas 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-monitoring-users@example.com |
El equipo responsable de supervisar las métricas de rendimiento de la aplicación. | Visualizador de Monitoring | proyecto de supervisión |
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 la configuración de red. | Visualizador de la red de Compute | organización |
grp-gcp-scc-admin@example.com |
El equipo responsable de configurar Security Command Center. | Editor administrador del centro de seguridad | organización |
grp-gcp-secrets-admin@example.com |
El equipo responsable de administrar, almacenar y auditar las credenciales y otros secretos que usan las aplicaciones. | Administrador de Secret Manager | proyectos de Secrets |
grp-gcp-kms-admin@example.com |
El equipo responsable de aplicar la administración de claves de encriptación para cumplir con los requisitos de cumplimiento. | Visualizador de Cloud KMS | proyectos de KMS |
A medida que compilas tus propias cargas de trabajo sobre la base, creas grupos adicionales y otorgas roles de IAM basados en los requisitos de acceso para cada carga de trabajo.
Te recomendamos que evites los roles básicos (como propietario, editor o visualizador) y uses roles predefinidos. Los roles básicos son demasiado permisivos e implican un posible riesgo de seguridad. Los roles Propietario y Editor pueden generar una elevación de privilegios y un movimiento lateral, y el rol Visualizador incluye acceso para leer todos los datos. Para obtener prácticas recomendadas sobre los roles de IAM, consulta Usa IAM de forma segura.
Cuentas de administrador avanzado
Los usuarios de Cloud Identity con la cuenta de administrador avanzado omiten la configuración de SSO de la organización y se autentican directamente en Cloud Identity. Esta excepción es por diseño, de modo que el administrador avanzado aún puede acceder a la consola de Cloud Identity en caso de una configuración incorrecta o interrupción del SSO. Sin embargo, significa que debes considerar una protección adicional para las cuentas de administrador avanzado.
Para proteger tus cuentas de administrador avanzado, recomendamos que siempre apliques la verificación en 2 pasos con llaves de seguridad en Cloud Identity. Si deseas obtener más información, consulta Prácticas recomendadas de seguridad para las cuentas de administrador.
Problemas con cuentas de usuario personales
Si no usaste Cloud Identity o Google Workspace antes de incorporarte a Google Cloud, es posible que los empleados de tu organización ya usen cuentas personales asociados con sus identidades de correo electrónico corporativas para acceder a otros servicios de Google, como Google Marketing Platform o YouTube. Las cuentas personales son cuentas que pertenecen completamente a las personas que las crearon y son administradas por ellas. Debido a que esas cuentas no están bajo el control de tu organización y pueden incluir datos personales y corporativos, debes decidir cómo consolidar estas cuentas con otras cuentas corporativas.
Te recomendamos que consolides las cuentas de usuario personales existentes como parte de la integración en Google Cloud. Si aún no usas Google Workspace para todas tus cuentas de usuario, te recomendamos bloquear la creación de cuentas personales nuevas.
Controles administrativos de Cloud Identity
Cloud Identity tiene varios controles administrativos que no están automatizados por el código de Terraform en el plano. Te recomendamos que apliques cada uno de estos controles de seguridad de las prácticas recomendadas al comienzo de la creación de tu base.
| Control | Descripción |
|---|---|
| Implementa la verificación en 2 pasos | Las cuentas de usuario pueden verse comprometidas mediante la suplantación de identidad (phishing), la ingeniería social, el robo de contraseñas o varias otras amenazas. La verificación en 2 pasos ayuda a mitigar estas amenazas. Te recomendamos que apliques la verificación en 2 pasos a todas las cuentas de usuario de tu organización con un mecanismo resistente a la suplantación de identidad (phishing) como las llaves de seguridad Titan u otras llaves que se basen en estándares FIDO U2F (CTAP1) resistentes a la suplantación de identidad (phishing). |
| Establece la duración de la sesión para los servicios de Google Cloud | Los tokens de OAuth persistentes en estaciones de trabajo para desarrolladores pueden ser un riesgo de seguridad si se exponen. Te recomendamos que establezcas una política de reautenticación para requerir la autenticación cada 16 horas mediante una llave de seguridad. |
| Establece la duración de la sesión para los servicios de Google | (Solo para clientes de Google Workspace)
Las sesiones web persistentes en otros servicios de Google pueden ser un riesgo de seguridad si se exponen. Recomendamos que apliques una duración máxima de sesión web y la alinees con los controles de duración de sesión en tu proveedor de SSO. |
| Comparte datos de Cloud Identity con los servicios de Google Cloud | Por lo general, los registros de auditoría de actividad del administrador de Google Workspace o Cloud Identity se administran y ven en la Consola del administrador, por separado de los registros en tu entorno de Google Cloud. Estos registros contienen información relevante para tu entorno de Google Cloud, como los eventos de acceso del usuario. Te recomendamos que compartas los registros de auditoría de Cloud Identity con tu entorno de Google Cloud para administrar de forma centralizada los registros de todas las fuentes. |
| Cómo configurar la verificación posterior al SSO | En el plano, se supone que configuraste el SSO con el proveedor de identidad externo. Te recomendamos que habilites una capa de control adicional según el análisis de riesgos de acceso de Google. Después de aplicar esta configuración, es posible que los usuarios vean desafíos de acceso adicionales basados en el riesgo durante el acceso si Google considera que el acceso de los usuarios es sospechoso. |
| Soluciona problemas con las cuentas de usuario personales | Los usuarios con una dirección de correo electrónico válida en tu dominio, pero sin una Cuenta de Google, pueden registrarse para obtener cuentas personales no administradas. Estas cuentas pueden contener datos corporativos, pero no los controlan tus procesos de administración del ciclo de vida de las cuentas. Te recomendamos que tomes medidas para garantizar que todas las cuentas de usuario sean cuentas administradas. |
| Inhabilita la recuperación de cuentas para administradores avanzados | La recuperación automática de la cuenta de administrador avanzado está desactivada de forma predeterminada para todos los clientes nuevos (es posible que los clientes existentes tengan esta configuración activada). Desactivar esta configuración ayuda a mitigar el riesgo de que un teléfono vulnerado, un correo electrónico vulnerado o un ataque de ingeniería social puedan permitir que un atacante obtenga privilegios de administrador avanzado en tu entorno. Planificar un proceso interno para que un administrador avanzado se comunique con otro administrador avanzado de tu organización si perdió el acceso a su cuenta y asegurarte de que todos los administradores avanzados estén familiarizados con el proceso para la recuperación con ayuda del equipo de asistencia. |
| Aplica y supervisa los requisitos de contraseña para los usuarios | En la mayoría de los casos, las contraseñas de los usuarios se administran a través de tu proveedor de identidad externo, pero las cuentas de administrador avanzado omiten el SSO y deben usar una contraseña para acceder a Cloud Identity. Inhabilita la reutilización de contraseñas y supervisa la seguridad de las contraseñas de cualquier usuario que use una contraseña para acceder a Cloud Identity, en especial, las cuentas de administrador avanzado. |
| Establece políticas para toda la organización a fin de usar grupos | De forma predeterminada, las cuentas de usuario externas se pueden agregar a los grupos en Cloud Identity. Te recomendamos establecer una configuración de uso compartido para que los propietarios de grupos no puedan agregar miembros externos. Ten en cuenta que esta restricción no se aplica a la cuenta de administrador avanzado ni a otros administradores delegados con permisos de administrador de Grupos. Debido a que la federación de tu proveedor de identidad se ejecuta con privilegios de administrador, la configuración de uso compartido de grupos no se aplica a esta sincronización de grupo. Te recomendamos que revises los controles en el proveedor de identidad y el mecanismo de sincronización para asegurarte de que los miembros que no son de dominio se agreguen a grupos o que apliques restricciones de grupo. |
Próximos pasos
- Lee sobre la estructura de la organización (siguiente documento de esta serie).