En esta página se recomiendan prácticas recomendadas de seguridad que debes tener en cuenta al usar la gestión de identidades y accesos.
Esta página está dirigida a usuarios que tienen experiencia con IAM. Si acabas de empezar a usar Gestión de identidades y accesos, estas instrucciones no te enseñarán a usarlo. En su lugar, los usuarios nuevos deben empezar con la guía de inicio rápido de Gestión de identidades y accesos.
Mínimos privilegios
|
❑
Los roles básicos incluyen miles de permisos en todos los Google Cloud servicios. En entornos de producción, no concedas roles básicos a menos que no haya ninguna alternativa. En su lugar, concede los roles predefinidos o roles personalizados más limitados que se ajusten a tus necesidades.
Si necesitas sustituir un rol básico, puedes usar las recomendaciones de roles para determinar qué roles debes asignar. También puedes usar el Simulador de políticas para asegurarte de que el cambio de rol no afecte al acceso de la entidad de seguridad. Puede ser adecuado asignar roles básicos cuando quieras conceder permisos más amplios para un proyecto. Por ejemplo, puedes asignar roles básicos para usarlos en entornos de prueba o desarrollo. |
|
❑
Trata cada componente de tu aplicación como un límite de confianza independiente. Si tienes varios servicios que requieren permisos diferentes, crea una cuenta de servicio independiente para cada uno de ellos y, a continuación, concede solo los permisos necesarios a cada cuenta de servicio.
|
|
❑
Recuerda que las políticas de permiso de los recursos secundarios se heredan de las políticas de permiso de sus recursos superiores. Por ejemplo, si la política de permiso de un proyecto concede a un usuario la capacidad de administrar instancias de máquinas virtuales (VMs) de Compute Engine, el usuario podrá administrar cualquier VM de Compute Engine de ese proyecto, independientemente de la política de permiso que hayas definido en cada VM.
|
|
❑
Concede roles con el menor permiso necesario. Por ejemplo, si un usuario solo necesita acceso para publicar temas de Pub/Sub, concédele el rol Publisher para ese tema.
|
|
❑
Especifica qué principales pueden actuar como cuentas de servicio.
Los usuarios a los que se les haya asignado el rol Usuario de cuenta de servicio en una cuenta de servicio pueden acceder a todos los recursos a los que tenga acceso la cuenta de servicio. Por lo tanto, ten cuidado al conceder el rol Usuario de cuenta de servicio a un usuario.
|
|
❑
Especifica quién tiene acceso para crear y gestionar cuentas de servicio en tu proyecto.
|
|
❑
Si asignas los roles predefinidos Administrador de IAM de proyecto y Administrador de IAM de carpeta, se podrá modificar las políticas de permiso sin permitir el acceso directo de lectura, escritura y administración a todos los recursos.
Si asignas el rol Propietario ( roles/owner) a una entidad, esta podrá acceder a casi todos los recursos y modificarlos, incluidas las políticas de permiso. Este nivel de privilegio puede ser arriesgado. Asigna el rol de propietario solo cuando se requiera un acceso (casi) universal.
|
|
❑
Usa enlaces de roles condicionales para que el acceso caduque automáticamente y plantéate conceder acceso elevado temporal.
|
Cuentas de servicio
|
❑
Adopta prácticas recomendadas para trabajar con cuentas de servicio. Asegúrate de que las cuentas de servicio tengan privilegios limitados y protégete frente a posibles amenazas de seguridad.
|
|
❑
No elimines las cuentas de servicio que estén usando las instancias en ejecución. Si no has cambiado a una cuenta de servicio alternativa, es posible que se produzcan errores en toda la aplicación o en algunas partes de ella.
|
|
❑
Usa el nombre visible de una cuenta de servicio para saber para qué se usa y qué permisos necesita.
|
Claves de cuenta de servicio
|
❑
Evita usar claves de cuentas de servicio si hay otra opción disponible.
Las claves de las cuentas de servicio suponen un riesgo para la seguridad si no se gestionan adecuadamente. Siempre que sea posible, deberías
elegir una alternativa más segura a las claves de cuentas de servicio. Si debes autenticarte con una clave de cuenta de servicio, eres responsable de la seguridad de la clave privada y de otras operaciones descritas en las
prácticas recomendadas para gestionar las claves de cuentas de servicio.
Si no puedes crear una clave de cuenta de servicio, es posible que la creación de claves de cuenta de servicio esté inhabilitada en tu organización. Para obtener más información, consulta el artículo sobre
gestionar recursos de organización seguros de forma predeterminada.
Si has obtenido la clave de cuenta de servicio de una fuente externa, debes validarla antes de usarla. Para obtener más información, consulta los requisitos de seguridad de las credenciales de fuentes externas. |
|
❑
Rota las claves de tu cuenta de servicio con la API de cuentas de servicio de IAM.
Para rotar una clave, puedes crear una nueva, cambiar las aplicaciones para que usen la nueva clave, inhabilitar la antigua y, a continuación, eliminarla cuando tengas la certeza de que ya no es necesaria.
|
|
❑
Implementa procesos para gestionar las claves de las cuentas de servicio gestionadas por los usuarios.
|
|
❑
No confundas las claves de cifrado con las claves de cuentas de servicio. Las claves de encriptado se suelen usar para encriptar datos, mientras que las claves de cuentas de servicio se usan para acceder de forma segura a las APIs. Google Cloud
|
|
❑
No incluyas las claves de cuentas de servicio en el código fuente ni las dejes en el directorio Descargas.
|
Auditoría
|
❑
Usa los registros de Registro de auditoría de Cloud para auditar periódicamente los cambios en tu política de permisos.
|
|
❑
Exporta los registros de auditoría a Cloud Storage para almacenarlos durante largos periodos.
|
|
❑
Audita quién tiene la capacidad de cambiar tus políticas de permiso en tus proyectos.
|
|
❑
Gestionar el acceso a los registros con
roles de Logging.
|
|
❑
Aplica las mismas políticas de acceso al recurso que usas para enrutar los registros que al Explorador de registros. Google Cloud
|
|
❑
Usa los registros de auditoría de Cloud para auditar periódicamente el acceso a las claves de cuentas de servicio.
|
Gestión de políticas
|
❑
Si una entidad necesita acceder a todos los proyectos de tu organización, concédele roles a nivel de organización.
|
|
❑
Siempre que sea posible, concede roles a grupos en vez de a usuarios individuales. Es más fácil actualizar los miembros de un grupo que los principales de tus políticas de permiso.
|