En este documento, se describen las prácticas recomendadas, las situaciones y los procedimientos para revocar el acceso de un usuario a un proyecto de Google Cloud . Debido a que cada empresa tiene políticas y cargas de trabajo diferentes, te recomendamos que uses este documento para crear tus propias políticas y procedimientos que te permitan revocar el acceso de manera coherente y oportuna.
Cuando un empleado abandona tu empresa, finaliza tu relación con un contratista o un colaborador se traslada a otros proyectos, debes realizar algunas acciones para revocar por completo el acceso innecesario a tus recursos de la nube.
Algunos de estos procesos son opcionales. Debes determinar cuál de estos pasos ejecutar, según tus necesidades de seguridad, productos en uso y confianza en la persona cuyo acceso se está revocando.
Prácticas recomendadas para configurar tu proyecto
Puedes mejorar la capacidad de tu proyecto para revocar los accesos de usuarios con eficacia si tomas decisiones inteligentes en el momento de la configuración.
Federa cuentas de usuario con tu proveedor de identidad existente
Cuando federas cuentas de usuario con tu proveedor de identidad existente, asegúrate de propagar los eventos de suspensión y eliminación de usuarios. Con la propagación, cuando suspendes o quitas una cuenta de usuario de tu proveedor de identidad, el usuario también pierde el acceso a los recursos de Google Cloud .
Para obtener más información, consulta Prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.
Para obtener más prácticas recomendadas relacionadas con la identidad, consulta Prácticas recomendadas para planificar cuentas y organizaciones.
Para obtener información sobre la federación de identidades de personal, consulta Federación de identidades de personal.
Considera usar Grupos de Google para administrar el acceso a los recursos del proyecto
Los Grupos de Google te permiten organizar usuarios en función de su membresía del equipo, los requisitos de acceso y otros criterios. Después de crear Grupos de Google, puedes asignar acceso a los Google Cloud proyectos y recursos según la membresía del grupo. Cuando un usuario se transfiere a otro equipo o función laboral, puedes mover la cuenta de usuario a otro grupo, lo que quita automáticamente el acceso que otorgaron las políticas de permisos al grupo anterior.
El uso de Grupos de Google no es adecuado en todas las circunstancias. Por ejemplo, no debes usar grupos que se basen solo en la estructura de organización de tu empresa para administrar el acceso. Para conocer las prácticas recomendadas sobre el uso de grupos, consulta Prácticas recomendadas para usar Grupos de Google.
Para obtener más información, consulta Administra grupos en la Google Cloud consola y Crea un grupo en tu organización.
Usa Acceso al SO
Usa el Acceso al SO en lugar de las claves SSH basadas en metadatos para que las claves autorizadas del usuario se vinculen a su identidad de Google. Cuando quitas una cuenta de usuario, las claves autorizadas y el acceso a las VMs se revocan automáticamente. Para obtener más información, consulta Usa el Acceso al SO para garantizar una evaluación de acceso continua en función de las políticas de IAM.
Para ver las instrucciones, consulta Configura el Acceso al SO.
Restringe el acceso desde cuentas de usuario externo
No se puede otorgar acceso externo al proyecto porque no puedes controlar el ciclo de vida de estas cuentas de usuario. Para restringir usuarios externos, usa la restricción de lista iam.allowedPolicyMemberDomains.
Para ver las instrucciones, consulta Restringe identidades por dominio.
Usa proxies de autenticación con bases de datos
Los proxies de autenticación te permiten conectar el ciclo de vida de las credenciales de la base de datos al ciclo de vida de una identidad de Google. Cuando suspendes o borras una cuenta de usuario en Cloud Identity o Google Workspace, se revoca automáticamente el acceso a las bases de datos.
Para obtener más información, consulta Proxy de autenticación de Cloud SQL y Proxy de autenticación de AlloyDB para PostgreSQL.
Prepárate para la rotación de credenciales
Diseña tus proyectos y recursos para permitir una rotación sin interrupciones de las credenciales a nivel del proyecto. Estos son secretos vinculados con el proyecto en sí, como claves de cuenta de servicio, secretos del cliente OAuth y secretos específicos de la aplicación, como contraseñas de administrador de la base de datos. Para obtener más información, consulta Cómo controlar las credencialesGoogle Cloud vulneradas.
Restringe las claves de API
Cuando crees y administres claves de API, restringe el conjunto de sitios web, direcciones IP y aplicaciones que pueden usarlas. Con una cuenta de usuario con roles como Visualizador o Administrador de claves de API se pueden ver las claves de API de tu proyecto, por lo que cualquier clave sin restricción debe rotar o borrarse para revocar el acceso de facturación. Para obtener más información, consulta Protege una clave de API.
Supervisa los permisos de acceso
Hacer un seguimiento cuidadoso del acceso ayuda a mitigar los posibles abusos de acceso. Puedes usar el recomendador de roles de IAM para hacer un seguimiento del uso de roles y ayudar a aplicar el principio de privilegio mínimo. Además, las funciones de Administración de derechos de infraestructura de nube (CIEM) de Security Command Center te permiten administrar qué identidades tienen acceso a qué recursos en tus implementaciones y mitigar las posibles vulnerabilidades que se generan a partir de configuraciones incorrectas.
Usa el acceso uniforme a nivel de bucket para Cloud Storage
El acceso uniforme a nivel de bucket te permite usar solo IAM para administrar los permisos de tus buckets de Cloud Storage. Usa el acceso uniforme a nivel de bucket junto con otras opciones de control de acceso para definir con mayor precisión quién puede acceder al contenido de tus buckets.
Prácticas recomendadas adicionales
Además de las prácticas recomendadas que se describen en este documento, revisa las siguientes prácticas recomendadas:
- Prácticas recomendadas para trabajar con cuentas de servicio
- Decide la seguridad de tu Google Cloud zona de destino
- Verifica cada intento de acceso de forma explícita
Situaciones para revocar el acceso a Google Cloud proyectos
Si implementaste las prácticas recomendadas que se enumeran en Prácticas recomendadas para configurar tu proyecto, en la siguiente tabla se resume cómo puedes revocar el acceso.
| Situación | Revoca opciones de acceso |
|---|---|
| Un empleado abandona tu empresa. | Si configuras la federación entre Cloud Identity o Google Workspace con aprovisionamiento automático de usuarios, la revocación de acceso puede ocurrir automáticamente. Si no seguiste las prácticas recomendadas y otorgaste a las identidades de usuario externas acceso a tus recursos, debes quitar de forma manual las identidades de tus proyectos y recursos. |
| Un empleado cambia su cargo. | Quitas al empleado del grupo de equipo. |
| Finalizó un contrato. | Si configuras la federación entre Cloud Identity o Google Workspace con aprovisionamiento automático de usuarios, la revocación de acceso puede ocurrir automáticamente. Si no seguiste las prácticas recomendadas y otorgaste a las identidades de usuario externas acceso a tus recursos, debes quitar de forma manual las identidades de tus proyectos y recursos. |
| Se vulneró la seguridad de una cuenta. | Para obtener instrucciones, consulta Cómo manejar credencialesGoogle Cloud vulneradas. |
Revocar el acceso
Si tomaste buenas decisiones en la configuración del proyecto, los siguientes procesos serán una manera eficiente de revocar el acceso de una persona.
Para determinar a qué recursos tiene acceso una persona, usa el Analizador de políticas. Para obtener instrucciones, consulta Analiza las políticas de IAM.
Borra la cuenta de usuario de tu proveedor de identidad
Si el usuario abandona tu organización y federaste Cloud Identity o Google Workspace con tu proveedor de identidad, con el aprovisionamiento automático de usuarios, la revocación de acceso puede ocurrir automáticamente.
Para obtener información sobre cómo borrar usuarios de la federación de identidades de personal, consulta Borra los usuarios de la federación de identidades de personal y sus datos.
Asigna la cuenta a otro grupo
Si el usuario cambia los roles, quita la cuenta de usuario de sus Grupos de Google actuales. Si federaste Cloud Identity o Google Workspace con tu proveedor de identidad para administrar la membresía del grupo, la revocación de acceso puede ocurrir automáticamente.
Para obtener más información, consulta Visualiza y edita los detalles de los grupos.
Quita la cuenta de usuario de las políticas de permisos de IAM
Para quitar una cuenta de usuario de las políticas de permisos a nivel del proyecto, haz lo siguiente:
En la Google Cloud consola, ve a la página Permisos de IAM.
Selecciona el proyecto del cual deseas quitar una cuenta de usuario.
Haz clic en la casilla de verificación junto a la fila que contiene la cuenta de usuario que deseas quitar de la lista de miembros y, luego, haz clic en Quitar.
Para verificar otras ubicaciones en las que se puede establecer la política de permisos, incluidas las carpetas, la organización o los recursos individuales, consulta Cómo verificar que se quitaron los permisos.
Rota las credenciales del proyecto
Rota las claves de la cuenta de servicio
Si usas claves de cuenta de servicio para autenticarte en una cuenta de servicio, debes rotar las claves. Además, considera si la persona puede haber tenido acceso a claves de cuenta de servicio en algún lugar fuera de las herramientas de Google Cloud, como el repositorio de código fuente o las configuraciones de la aplicación.
En la consola de Google Cloud , ve a la página Credenciales de API.
Haz clic en el nombre de la cuenta de servicio que deseas modificar.
En la pestaña Clave, haz clic en Agregar clave.
Haga clic en Crear clave nueva.
Elige el Tipo de clave que deseas crear. En la mayoría de las situaciones, se recomienda JSON, pero P12 está disponible para la compatibilidad con versiones anteriores con código que depende de él.
Haz clic en Crear. Un archivo que contiene la clave nueva se descargará automáticamente a través de tu navegador. Implementa esta clave en cualquier aplicación que la necesite.
Después de confirmar que la clave nueva funciona como se esperaba, regresa a la página de credenciales y borra la clave anterior asociada a esa cuenta de servicio.
Rota los secretos de ID de cliente de OAuth
Los secretos de ID de cliente de OAuth no proporcionan ningún acceso directo a tu proyecto. Sin embargo, si un atacante conoce el secreto de ID de cliente de OAuth, puede falsificar tu aplicación y solicitar acceso a las Cuentas de Google de tus usuarios desde una aplicación maliciosa.
Es posible que debas rotar los secretos del ID de cliente de OAuth si la persona cuyo acceso se revocó tuvo acceso al secreto, incluso en el repositorio de código fuente, en la configuración de la aplicación o en las funciones de IAM.
En la consola de Google Cloud , ve a la página Credenciales de API.
Haz clic en el nombre del ID de cliente de OAuth 2.0 que deseas modificar.
En la página de ID de cliente, haz clic en Restablecer secreto.
Haz clic en Restablecer en el diálogo de confirmación para revocar inmediatamente el secreto anterior y configurar uno nuevo. Ten en cuenta que todos los usuarios activos deberán volver a autenticarse tras su siguiente solicitud.
Implementa el nuevo secreto en todas las aplicaciones que lo necesiten.
Rota las claves de API
Las claves de API no dan acceso a tu proyecto o tus datos de usuarios, pero controlan a quién le factura Google las solicitudes a la API. Con una cuenta de usuario con funciones como Visualizador o Administrador de claves de API se pueden ver las claves de API de tu proyecto. Si tienes alguna clave no restringida, debes borrarlas o volver a generarlas cuando revocas el acceso de una persona a tu proyecto.
En la consola de Google Cloud , ve a la página Credenciales de API.
Haz clic en el nombre de la clave de API que deseas modificar.
Haz clic en Volver a generar clave.
Un diálogo mostrará la clave creada recientemente. Implementa esta clave en cualquier aplicación que use la clave que deseas reemplazar.
Después de confirmar que tus aplicaciones funcionan como se esperaba con la clave nueva, regresa a la página de credenciales y borra la clave sin restricciones anterior.
Revoca el acceso a las VM
Si la persona cuyo acceso estás revocando no tiene acceso a ninguna de las VMs de tu proyecto, puedes omitir este paso.
Quita todas las Llaves SSH al nivel de proyecto a las que tuvo acceso la persona.
En cada VM a la que la persona tenía acceso con SSH, quita todas las claves de nivel de instancia.
Quita la cuenta de la persona de todas las VM a las que tenían acceso.
Verifica si hay aplicaciones sospechosas que pueda haber instalado la persona para proporcionar un acceso por puerta trasera a la VM. Si tienes dudas acerca de la seguridad de algún código que se ejecuta en la VM, recréala y vuelve a implementar las aplicaciones que necesitas desde la fuente.
Verifica que la configuración de firewall de la VM no se haya cambiado en comparación con tu configuración planificada o esperada.
Si creas VM nuevas desde imágenes base personalizadas, verifica que las imágenes de base no hayan sido modificadas de algún modo que pudiera comprometer la seguridad de las VMs nuevas.
Cómo revocar el acceso a las bases de datos
Si tu proyecto no usa recursos de Cloud SQL ni de AlloyDB para PostgreSQL, puedes omitir este paso.
Para revocar el acceso a una base de datos de Cloud SQL, completa lo siguiente:
En la consola de Google Cloud , ve a la página Instancias de SQL.
Haz clic en el ID de instancia de la base de datos a la que deseas revocar el acceso.
En el menú de la izquierda, haz clic en Conexiones.
Confirma que la lista de direcciones IP en Redes autorizadas y la lista de aplicaciones en autorización de App Engine coincidan con lo esperado. Si la persona cuyo acceso estás tratando de revocar tiene acceso a las redes o aplicaciones detalladas aquí, pueden acceder a esta base de datos.
En el menú de la izquierda, haz clic en Usuarios.
Borra o cambia la contraseña de las cuentas de usuario a las que tenía acceso la persona. Asegúrate de actualizar las aplicaciones que dependan de esas cuentas de usuario.
Para revocar el acceso a una base de datos de AlloyDB para PostgreSQL, consulta Cómo quitar un usuario o una cuenta de servicio de IAM de un clúster.
Vuelve a implementar App Engine
De forma predeterminada, las aplicaciones de App Engine tienen acceso a una cuenta de servicio que es un editor del proyecto asociado. Los controladores de solicitudes de App Engine pueden crear VMs nuevas y leer o modificar datos en Cloud Storage. Alguien con la capacidad de implementar código en App Engine podría usar esta cuenta de servicio para abrir una puerta trasera a tu proyecto. Si te preocupa la integridad del código de las aplicaciones implementadas, recomendamos volver a implementarlas (incluidos los módulos) con una confirmación correcta conocida desde tu sistema de control de versión.
Verifica que se hayan quitado los permisos
Puedes verificar los permisos a nivel de la organización, del proyecto o con Policy Analyzer.
Para encontrar los recursos a los que un usuario en particular podría tener acceso a nivel de la organización, usa el método search-all-iam-policies en Google Cloud CLI. Por ejemplo, para determinar si un usuario tiene acceso a tus recursos, ejecuta lo siguiente:
gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'
Aquí:
ORGANIZATION_IDes el número de tu organización.IDENTITYes la identidad del usuario, como una dirección de correo electrónico.
Para verificar los permisos de un proyecto, consulta Permisos que tiene una principal en un proyecto.
Para verificar los permisos con el Analizador de políticas, consulta Determina a qué recursos puede acceder un principal.
¿Qué sigue?
Consulta Cómo controlar las credenciales Google Cloudvulneradas.
Obtén más información sobre las Prácticas recomendadas para mitigar los tokens de OAuth vulnerados en Google Cloud CLI.
Crea una política de denegación para especificar a qué permisos ya no puede acceder el usuario.