Skip to main content
Una negación no le dice casi nada por sí misma, deliberadamente: un error que explica qué declaración rechazó le diría a un atacante cómo se ven sus políticas. Así que el diagnóstico es un proceso de eliminación, y hay un orden que encuentra la respuesta más rápido que leer las políticas de arriba a abajo.

​
Comprobar el alcance antes de agregar permisos

1

Compruebe la cuenta de la credencial

Los tokens de cuenta de servicio y de rol pertenecen a una cuenta. Confirme que coincide con la cuenta solicitada. Cambiar X-Account-Id no mueve la identidad; use un intercambio explícito de AssumeRole para otra cuenta.Cada persona, incluido el propietario de la organización, necesita un rol de cuenta asignado. La consola asume automáticamente el rol único efectivo de esa cuenta. Las políticas de espacio de trabajo personal no conceden operaciones de cuenta ordinarias.
2

Compruebe el dominio de la política

Las acciones de organización (workspace:*, billing:*, quota:* y audit:*) necesitan políticas de organización. Las acciones de servicio de cuenta necesitan directivas de cuenta. Un comodín en el dominio equivocado es ineficaz.Una sesión de rol usa las directivas de cuenta y las concesiones de organización propias del rol, no los permisos del principal de origen.
3

Marque la casilla de denegación y permiso explícitos

Un deny explícito coincidente gana en el dominio evaluado. Sin un permiso coincidente, se deniega el acceso. Para un usuario, las directivas de organización incluyen directivas de grupo. Las cuentas de servicio nunca heredan directivas de grupo.
4

Compruebe el CRN del recurso

Los recursos de IAM de cuenta contienen el identificador de cuenta. Los recursos de espacio de trabajo contienen el UUID de la organización en la ruta. Global significa un espacio vacío en la región; no significa un espacio vacío en la cuenta.Los CRN de recursos usan nombres inmutables para roles, cuentas de servicio y directivas. Los principios de confianza vinculan identidades de máquina concretas a UUID inmutables. Copia la identidad devuelta apropiada en lugar de adivinar su forma.
5

Compruebe las condiciones, los límites y la política de sesión

Una directiva de sesión solo puede restringir permisos. Los límites de cuenta limitan los permisos de la cuenta, mientras que los límites de usuario de espacio de trabajo limitan los permisos de la organización. Ninguno de los dominios de políticas puede utilizarse para ampliar el otro.Compruebe las claves de condición, los valores y si un recurso solicitado tiene las etiquetas que espera la política. Un valor que falta puede hacer que una autorización que de otra manera coincidiría sea ineficaz.

​
No se puede asumir un rol asignado

Revise ambas puertas. El usuario necesita una asignación directa o de grupo para el rol de destino, y la confianza del rol debe aceptar su CRN principal de usuario de Workspace. Para un origen de máquina, reemplace la comprobación de asignación por iam:AssumeRole en el rol de destino en la directiva de cuenta de origen. Para la suposición de cuentas cruzadas, use el CRN de rol completo de la cuenta de destino. La confianza debe identificar correctamente la cuenta de origen y el principal de origen inmutable. No se admite la asunción de funciones entre organizaciones.

​
Se deniega la delegación de organización

Para adjuntar una directiva de organización, se requiere el permiso de Workspace en la directiva y el permiso de IAM para actualizar la cuenta de servicio o rol de destino. Ambos deben ser mantenidos por el mismo llamador. Un administrador de cuentas sin concesiones de organización no puede concederlas a sí mismo. La misma protección se aplica a los cambios sensibles a una identidad que ya lleva subvenciones de la organización. Consulte delegación de organización.

​
Errores que pueden ser engañosos

Un recurso fuera de su organización o cuenta seleccionada puede devolver 404 para evitar confirmar su existencia. Compruebe el ámbito, así como el UUID.
El punto final de revocación de sesión comprueba iam:RevokeSession, luego lee la sesión para su respuesta con iam:GetSTSSession. Concede las dos. Con solo el primer permiso, la revocación puede tener éxito antes de que se deniegue la lectura.
El adjunto de directiva administrada requiere permisos de directiva y de recurso de destino. Una concesión solo en CRN de política o solo en CRN de identidad es incompleta. Consulte Adjuntos de IAM y Permisos de espacio de trabajo.
Los operadores desconocidos no coinciden con las instrucciones allow. Para un deny con acción y recurso coincidentes, un operador desconocido falla cerrado. Compruebe la ortografía del operador cuando un deny es más amplio de lo esperado.
Un 503 SERVICE_UNAVAILABLE durante un intercambio de credenciales puede indicar un fallo temporal de dependencia de la plataforma. Vuelva a intentarlo con backoff; rotar una clave válida no corrige un intercambio no disponible.

​
Acceso a la colección y lecturas de membresía

Una lista de nivel superior autoriza un CRN de colección, no filas individuales. Una política en un rol no concede ListRoles. Las listas de relaciones en cambio autorizan a su padre. Vea listing. El catálogo de regiones es público. El intercambio de tokens verifica las credenciales. Los humanos pueden leer las organizaciones a las que pertenecen a través de la membresía; las máquinas necesitan workspace:GetOrganization. Estas comprobaciones difieren de los permisos de recursos de cuenta ordinarios.

​
Qué muestra y qué no muestra el registro de auditoría

El registro de auditoría registra las mutaciones de IAM y Workspace con éxito: quién adjuntó qué política a quién, quién creó un rol, quién eliminó a un usuario. Eso es lo que quieres para una revisión de acceso, y es consultable a través de GET /v1/audit-logs.
Autorización no hay denegaciones en ella. Una solicitud rechazada se registra en los propios registros del servicio, con la acción y el CRN de recurso que el servicio realmente solicitó, pero nada se muestra a través de la API.Así que “¿con qué CRN tuvo que coincidir mi póliza?” no se puede responder desde el registro de auditoría. Derivalo en su lugar: las formas se enumeran en resources, y la página de permisos de cada servicio da la suya propia.
Los eventos de inicio de sesión son la excepción que registra los errores: una inscripción de dos factores fallida o una clave de seguridad eliminada se auditan de cualquier manera, porque el error es la mitad interesante.

​
Leer identidades de eventos

Los registros de auditoría no tienen página de consola. Utilice la API para inspeccionar las identidades de eventos y las etiquetas retenidas. El crn del evento identifica el registro de auditoría en sí, en la organización autenticada. Su segmento final es el id del evento. actor_crn y resource_crn identifican al actor y al objetivo tal como estaban en el momento del evento. Estas instantáneas no cambian cuando se cambia un nombre o se elimina un recurso. actor_name, actor_email y resource_name son etiquetas retenidas opcionales. Úsalas para exhibición, no para construir una identidad. Pueden permanecer disponibles después de que el actor o el objetivo se haya eliminado; manejar etiquetas ausentes o nulas. Por ejemplo, una respuesta de API puede contener este registro de auditoría:
Los eventos históricos sin instantáneas de identidad devuelven CRNs null. Un objetivo que no se pudo resolver a partir de los datos de tiempo de evento también tiene un resource_crn nulo, como un restablecimiento de contraseña para una dirección de correo electrónico desconocida. Cuando se conoce un UUID de destino, se conserva en details.resource_id; no sustituya ese UUID o una etiqueta de visualización por un CRN que falta. Un registro de API sin instantáneas o etiquetas retenidas puede tener este aspecto:
Estos ejemplos muestran API JSON. La salida JSON de CLI omite los campos CRN nulos. Para un actor de rol asumido, actor_crn identifica el rol, como crn:iam::production:role/deployer. El opcional details.actor_session_crn, con forma de crn:iam::production:sts-session/<id>, correlaciona el evento con su llamada a AssumeRole.

​
Siguiente

Permisos

Cada acción, y el recurso cada uno se comprueba contra.

Escribir políticas

Condiciones, operadores y lo que hace una clave faltante.