> ## 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. # IAM > Identidades de cuenta, sesiones de rol y cómo se evalúan los permisos. IAM administra roles, cuentas de servicio, directivas de cuenta y sesiones temporales. Cada uno pertenece a una cuenta. La API es global en `iam.basaltic.sh`: la misma identidad de cuenta puede funcionar en diferentes regiones, dentro de sus permisos. [Workspace](/es/workspace) administra organizaciones, personas, grupos y directivas de organización. Un extremo global no significa un recurso de toda la organización. Claves de acceso, directivas de confianza, roles asumidos e identidades de instancia. El formato del documento, las condiciones y los ejemplos de trabajo. Limitar los permisos de cuenta que puede recibir una cuenta de rol o de servicio. Acciones de IAM y los recursos que autorizan. Asignaciones de usuarios y grupos, seguidas de una asunción explícita de rol. Compruebe el alcance de la cuenta, el alcance de la política, la confianza y los límites de sesión. ## El modelo de identidad | Identidad de marca | Propiedad de la propiedad | Cómo se autentica | | - | - | - | | Usuario registrado | Membresía de la organización | Inicio de sesión personal; el trabajo de cuenta utiliza un rol asignado | | Cuenta de servicio | Cuenta de usuario | Clave de acceso intercambiada por un token al portador | | Función | Cuenta de usuario | No tiene credenciales propias; un llamador de confianza lo asume | | Papel asumido | Cuenta de destino | Token temporal al portador y credenciales S3 | Los grupos pertenecen a la organización y contienen solo usuarios. Las políticas de su organización se aplican a los miembros. Las asignaciones de roles de cuenta permiten a los miembros solicitar esos roles, sujetos a confianza. Las cuentas de servicio nunca se unen a grupos. Una sesión de rol utiliza los permisos del rol de destino. No combina los permisos del usuario de origen, la cuenta de servicio o el rol anterior con ellos. ## Nombres de recursos Las políticas identifican recursos con CRNs: ``` crn::::/ ``` ``` crn:storage:sa-saopaulo-1:my-account:volume/data crn:dns::my-account:zone/example.com crn:iam::my-account:role/deploy crn:iam::my-account:service-account/deploy-bot crn:workspace:::user/ ``` La región está vacía de servicios globales. Los CRN de IAM de cuenta contienen el identificador de cuenta. Los recursos de organización de espacio de trabajo dejan la ranura de cuenta vacía e incluyen el UUID de organización en la ruta de acceso al recurso. Las políticas de cuenta de sistema compartido usan `crn:iam:::policy/`. `*` es el único comodín. El diseño de dos puntos y barra se corresponde literalmente. Vea [resource references](/es/reference-resolution) para nombres, UUIDs y filtros de lista exactos. ## Cómo se autoriza una solicitud La credencial vincula primero al llamador a una organización y, para las credenciales de máquina y rol, a una cuenta. Un `X-Account-Id` diferente no puede mover una identidad a otra cuenta. Usa [AssumeRole](/es/iam/roles#assuming-a-role) para una transición explícita de cuenta. La acción elige el dominio de la política: * `workspace:*`, `billing:*`, `quota:*` y `audit:*` usan políticas de organización. * Las acciones de servicio de cuenta usan las directivas de cuenta de la cuenta de rol o de servicio. * La asignación de un rol de cuenta humano permite el intercambio de AssumeRole; las operaciones ordinarias de cuenta requieren la sesión de rol resultante. Dentro de ese dominio, una negación explícita gana. De lo contrario, se requiere un permiso. Una directiva de sesión opcional solo puede restringir el resultado. Los límites de permisos de cuenta limitan los permisos de la cuenta; el límite del espacio de trabajo de un usuario limita los permisos de su organización. Las directivas y los límites de cuenta no pueden conceder ni restringir una directiva de organización delegada por separado. Los propietarios de la organización usan concesiones explícitas de administrador de espacio de trabajo y roles de administrador de cuenta asignados. La propiedad nunca pasa por alto la evaluación de políticas. Los cambios de permisos deben preservar el acceso de administrador requerido del propietario; consulte [access\_account](/es/workspace/accounts#keeping-owner-access). Una directiva de cuenta que permite `*` sigue siendo una directiva de cuenta. No puede conceder facturación, administración de la organización u otras acciones de la organización. Delegarlos por separado a través de Workspace. ## Falling closed Vale la pena conocer dos comportamientos porque son deliberados y no accidentales: Si se establece un límite de permisos pero no se puede cargar el límite o su directiva, se deniega la solicitud. Un límite que existe pero no se puede leer podría estar limitando esta misma acción, por lo que la respuesta segura es no. Un operador de condición no reconocido nunca coincide. En una sentencia **allow** que significa que la sentencia se salta. En una sentencia **deny** se trata como una denegación dura cuando la acción y el recurso coinciden — de lo contrario, un error tipográfico en una barandilla la deshabilitaría silenciosamente.