> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Solución de problemas de acceso > Descubrir por qué se denegó una solicitud, en el orden que se encuentra más rápido, y los casos en los que el error que recibe no es el que esperaría. 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 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. 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. 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. 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. 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](/es/workspace/permissions#delegating-organization-policies). ## 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](/es/iam/permissions#attaching-and-detaching-require-both-resources) y [Permisos de espacio de trabajo](/es/workspace/permissions). 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](/es/iam/permissions#listing-cannot-be-narrowed). 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](/es/iam/permissions#policy-role-and-group-crns-use-immutable-names), 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: ```json theme={null} { "id": "550e8400-e29b-41d4-a716-446655440000", "crn": "crn:audit:::log/550e8400-e29b-41d4-a716-446655440000", "timestamp": "2026-09-26T09:30:00Z", "actor_crn": "crn:workspace:::organization/990e8400-e29b-41d4-a716-446655440000/user/660e8400-e29b-41d4-a716-446655440000", "actor_name": "Alex Rivera", "actor_email": "alex@example.com", "action": "iam:CreatePolicy", "status": "success", "resource_crn": "crn:iam::production:policy/read-only", "resource_name": "read-only" } ``` 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: ```json theme={null} { "id": "770e8400-e29b-41d4-a716-446655440000", "crn": "crn:audit:::log/770e8400-e29b-41d4-a716-446655440000", "timestamp": "2026-01-15T09:30:00Z", "actor_crn": null, "resource_crn": null, "action": "iam.policy.create", "status": "success", "details": { "resource_id": "880e8400-e29b-41d4-a716-446655440000" } } ``` 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/`, correlaciona el evento con su llamada a AssumeRole.