Policy Simulator para las políticas de denegación te permite ver cómo un cambio en una política de denegación de IAMpodría afectar el acceso de una principal antes de que confirmes el cambio. Puedes usar Policy Simulator para asegurarte de que los cambios que realices no harán que una entidad pierda el acceso que necesita.
Esta función solo evalúa las políticas de denegación. Para obtener información sobre cómo simular otros tipos de políticas, consulta lo siguiente:
- Policy Simulator para las políticas de la organización
- Policy Simulator para las políticas de permisos
- Policy Simulator para las políticas de límite de acceso de las principales
Cómo funciona Policy Simulator para las políticas de denegación
Policy Simulator para las políticas de denegación te ayuda a determinar si un cambio en una política de denegación bloqueará el acceso que usan tus principales.
Cuando ejecutas una simulación para una política de denegación, Policy Simulator hace lo siguiente:
Recupera los registros de acceso de la organización que se generaron durante el período de repetición. El período de repetición es de 90 días.
Si la organización no existe desde hace más de 90 días, Policy Simulator recupera todos los registros de acceso desde que se creó la organización.
Determina qué registros de acceso son relevantes para la simulación. Los registros de acceso relevantes son todos los registros de acceso que representan el intento más reciente de una principal de usar un permiso para acceder a un recurso.
Para cada registro de acceso relevante, determina si las políticas de denegación actuales, junto con los cambios propuestos, permitirían el acceso intentado. Este proceso se denomina repetición de los intentos de acceso.
Para cada registro de acceso, compara el estado de acceso de la repetición con el estado de acceso de los registros de acceso. Luego, Policy Simulator informa cualquier intento de acceso histórico que no se haya bloqueado en el registro de acceso, pero que sí se haya bloqueado en la repetición. Estas diferencias, que se denominan cambios de acceso, muestran qué intentos de acceso se habrían bloqueado si la política de denegación simulada hubiera estado vigente en el momento del intento.
Período de repetición
El período de repetición es el período durante el cual Policy Simulator obtiene registros de acceso cuando ejecuta una simulación. Los registros de acceso que ocurren antes del primer día del período de repetición o después del último día del período de repetición no se incluyen en la simulación.
Por lo general, el último día del período de repetición es 1 día antes de la simulación. Sin embargo, en algunos casos, el último día del período de repetición puede ser hasta 10 días antes de la simulación. Los registros de acceso que ocurren después del último día del período de repetición no se incluyen en la simulación.
El período de repetición es de 90 días. Si la organización no existe desde hace más de 90 días, Policy Simulator recupera todos los intentos de acceso desde que se creó la organización.
La ventana de repetición también tiene coherencia eventual. Esto significa que, cuando ejecutas una simulación, algunos datos pueden ser más recientes que otros. Sin embargo, con el tiempo, todos los datos tendrán la misma antigüedad.
Resultados de Policy Simulator
Policy Simulator informa el impacto de un cambio propuesto en una política de denegación como una lista de cambios de acceso. Para las políticas de denegación, el único tipo de cambio de acceso que informa Policy Simulator es el cambio de acceso Acceso revocado.
Policy Simulator informa que se revoca el acceso si se cumplen las siguientes condiciones:
- El intento más reciente de la principal para acceder al recurso se realizó correctamente.
- Los cambios propuestos o cualquier otra política de denegación bloquean el acceso de la principal al recurso.
Para cada cambio de acceso, Policy Simulator también informa la siguiente información:
- La principal, el recurso y el permiso involucrados en el intento de acceso.
- La cantidad de días durante el período de repetición en los que la principal intentó usar el permiso para acceder al recurso. Este total incluye solo los intentos de acceso que tienen el mismo resultado que el intento de acceso más reciente.
- La fecha del intento de acceso más reciente.
Errores
Los siguientes errores pueden hacer que falle una simulación:
- Se superó la cantidad máxima de simulaciones simultáneas: El usuario ya tiene 10 simulaciones en curso, que es la cantidad máxima de simulaciones en curso que puede tener un usuario. Para resolverlo, espera a que se complete una de las simulaciones en curso y, luego, vuelve a ejecutar la simulación.
- Tiempo de espera agotado: La simulación tardó demasiado en ejecutarse y se agotó el tiempo de espera. Para resolverlo, vuelve a ejecutar la simulación.
- Construcción de simulación no válida: La política de denegación propuesta no es válida o contiene reglas de denegación no admitidas. Un ejemplo de una política no válida es una que contiene una expresión de condición no válida. Un ejemplo de una regla de denegación no admitida es una que usa identificadores principales de identidad de personal. Para resolverlo, corrige la política y vuelve a intentarlo.
- Permiso denegado: No tienes permiso para ejecutar una simulación. Para resolverlo, asegúrate de tener los roles necesarios y vuelve a intentarlo.
Tipos de principales admitidos
Policy Simulator para las políticas de denegación solo revisa los registros de acceso de los siguientes tipos de principales:
- Cuentas de Google Workspace
- Cuentas de servicio
- Conjuntos de principales de cuentas de servicio para proyectos, carpetas y organizaciones
- Agentes de servicio
- Conjuntos de principales de agentes de servicio para proyectos, carpetas y organizaciones
Cuando se simulan políticas de denegación, Policy Simulator no revisa los registros de acceso de ningún otro tipo de principal, incluidos los basados en identidades federadas en un grupo de identidades para cargas de trabajo. Como resultado, Policy Simulator no informa si los cambios propuestos en tus políticas o vinculaciones afectan el acceso de esas principales.
Simula los límites de acceso a las credenciales
Puedes usar los límites de acceso a las credenciales para reducir o restringir los permisos de IAM que puede usar una credencial de corta duración para acceder a los recursos de Cloud Storage. Para reducir los permisos, un usuario o una cuenta de servicio (el agente de tokens) define los permisos disponibles en un conjunto de recursos en un token de acceso reducido y, luego, proporciona el token de acceso a otro usuario o cuenta de servicio (el consumidor de tokens).
El agente de tokens debe tener un rol que incluya los permisos otorgados al consumidor de tokens con un token de acceso reducido. Si se deniega ese rol en el agente de tokens, también se quita el acceso del consumidor de tokens. Sin embargo, Policy Simulator no evalúa cómo los cambios en los permisos del agente de tokens afectan el acceso del consumidor de tokens.
Por ejemplo, considera un usuario al que se le otorgó el rol de lector de bucket heredado de Storage (roles/storage.legacyBucketReader) en un recurso con un token de acceso reducido creado con un límite de acceso a las credenciales.
Si simulas la denegación del rol de lector de bucket heredado de Storage en ese usuario, Policy Simulator no informa una pérdida de acceso.
Si simulas la denegación del rol de lector de bucket heredado de Storage en el agente de tokens, Policy Simulator no informa una pérdida de acceso para el usuario. Del mismo modo, si no se usa el acceso del agente de tokens en un plazo de 90 días, su acceso no se incluye en la simulación.
Para obtener más información, consulta Límites de acceso a las credenciales para Cloud Storage.
¿Qué sigue?
- Aprende a simular un cambio en una política de denegación.
- Explora otras herramientas de Policy Intelligence.