> ## 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 conta, sessões de função e como as permissões são avaliadas. O IAM gerencia funções, contas de serviço, políticas de conta e sessões temporárias. Cada um pertence a uma conta. A API é global em `iam.basaltic.sh`: a mesma identidade de conta pode funcionar em várias regiões, dentro de suas permissões. [Workspace](/pt/workspace) gerencia organizações, pessoas, grupos e políticas organizacionais. Um endpoint global não significa um recurso de toda a organização. Chaves de acesso, políticas de confiança, funções assumidas e identidades de instância. O formato do documento, condições e exemplos trabalhados. Limite as permissões de conta que uma conta de função ou serviço pode receber. Ações do IAM e os recursos que elas autorizam. Atribuições de usuário e grupo, seguidas por uma assunção explícita de função. Verifique o escopo da conta, o escopo da política, a confiança e os limites de sessão. ## O modelo de identidade | Identidade e identidade | Propriedade e Gestão | Como ele autentica | | - | - | - | | Usuário registrado | Organização de associação | Login pessoal; o trabalho da conta usa uma função atribuída | | Conta de serviço | Conta de usuário | Chave de acesso trocada por um token de portador | | Função | Conta de usuário | Sem credenciais próprias; um chamador confiável assume isso | | Papel assumido | Target account | Token de portador temporário e credenciais S3 | Os grupos pertencem à organização e contêm apenas usuários. As políticas da organização se aplicam aos membros. As atribuições de funções de conta permitem que os membros solicitem essas funções, sujeitas a confiança. As contas de serviço nunca se juntam a grupos. Uma sessão de função usa as permissões da função de destino. Ele não combina as permissões do usuário de origem, da conta de serviço ou da função anterior com elas. ## Nomes de recursos As políticas identificam recursos com 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/ ``` A região está vazia para serviços globais. Os CRNs do IAM contêm o identificador da conta. Os recursos da organização de espaço de trabalho deixam o slot de conta vazio e incluem o UUID da organização no caminho do recurso. Políticas de conta de sistema compartilhado usam `crn:iam:::policy/`. `*` é o único curinga. O layout de dois pontos e barra é correspondido literalmente. Veja [resource references](/pt/reference-resolution) para nomes, UUIDs e filtros de lista exata. ## Como uma solicitação é autorizada A credencial primeiro vincula o chamador a uma organização e, para credenciais de máquina e função, a uma conta. Um `X-Account-Id` diferente não pode mover uma identidade para outra conta. Use [AssumeRole](/pt/iam/roles#assuming-a-role) para uma transição de conta explícita. A ação escolhe o domínio da política: * `workspace:*`, `billing:*`, `quota:*` e `audit:*` usam políticas de organização. * As ações de serviço de conta usam as políticas de conta da função ou conta de serviço. * A atribuição de função de conta de um humano permite a troca AssumeRole; operações de conta ordinárias requerem a sessão de função resultante. Dentro desse domínio, uma negação explícita vence. Caso contrário, é necessário um allow. Uma política de sessão opcional só pode restringir o resultado. Os limites de permissão de conta limitam as permissões da conta; o limite de espaço de trabalho de um usuário limita as permissões da organização. As políticas e limites de conta não podem conceder ou restringir uma política de organização delegada separadamente. Os proprietários da organização usam concessão explícita de administrador de espaço de trabalho e funções de administrador de conta atribuídas. A propriedade nunca ignora a avaliação da política. As alterações de permissão devem preservar o acesso de administrador necessário do proprietário; consulte [account access](/pt/workspace/accounts#keeping-owner-access). Uma política de conta que permite `*` ainda é uma política de conta. Não pode conceder faturação, administração da organização ou outras ações da organização. Delegar essas funções separadamente através do Workspace. ## Failing closed Dois comportamentos são dignos de conhecimento porque são deliberados e não acidentais: Se um limite de permissão for definido, mas o limite ou sua política não puderem ser carregados, a solicitação será negada. Um limite que existe, mas não pode ser lido, pode estar limitando essa ação, então a resposta segura é não. Um operador de condição não reconhecido nunca corresponde. Em uma instrução **allow** que significa que a instrução é ignorada. Em uma instrução **deny**, ela é tratada como uma negação dura quando a ação e o recurso coincidem — caso contrário, um erro de digitação em um guardrail silenciosamente a desabilitaria.