> ## 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. # Solução de problemas de acesso > Descobrir por que uma solicitação foi negada, na ordem que a encontra mais rapidamente — e os casos em que o erro que você recebe não é o que você esperaria. Uma negação não diz quase nada por si só, deliberadamente: um erro que explicasse *qual* declaração recusou diria a um atacante como são suas políticas. Portanto, o diagnóstico é um processo de eliminação, e há uma ordem que encontra a resposta mais rapidamente do que a leitura de políticas de cima para baixo. ## Verificar o escopo antes de adicionar permissões A conta de serviço e os tokens de função pertencem a uma conta. Confirme se ele corresponde à conta solicitada. Alterar `X-Account-Id` não move a identidade; use uma troca AssumeRole explícita para outra conta. Cada pessoa, incluindo o proprietário da organização, precisa de uma função de conta atribuída. O console assume automaticamente a função efetiva única dessa conta. As políticas de espaço de trabalho pessoal não concedem operações de conta comuns. As ações da organização (`workspace:*`, `billing:*`, `quota:*` e `audit:*`) precisam de políticas da organização. As ações de serviço de conta precisam de políticas de conta. Um curinga no domínio errado é ineficaz. Uma sessão de função usa as próprias políticas de conta da função e as concessões da organização, não as permissões do principal de origem. Uma negação explícita correspondente vence no domínio avaliado. Sem uma permissão correspondente, o acesso é negado. Para um usuário, as políticas da organização incluem políticas de grupo. As contas de serviço nunca herdam políticas de grupo. Os recursos do IAM de conta contêm o identificador da conta. Os recursos de espaço de trabalho contêm o UUID da organização no caminho. Global significa um slot de região vazio; não significa um slot de conta vazio. Os CRNs de recursos usam nomes imutáveis para funções, contas de serviço e políticas. Principais de confiança vinculam identidades de máquina concretas a UUIDs imutáveis. Copie a identidade retornada apropriada em vez de adivinhar sua forma. Uma política de sessão só pode restringir permissões. Os limites da conta limitam as permissões da conta, enquanto os limites do usuário do Workspace limitam as permissões da organização. Nenhum dos domínios de política pode ser usado para ampliar o outro. Verifique as chaves de condição, os valores e se um recurso solicitado tem as tags que a política espera. Um valor ausente pode tornar uma permissão de correspondência ineficaz. ## Uma função atribuída não pode ser assumida Verifique os dois portões. O usuário precisa de uma atribuição direta ou de grupo para a função de destino e a confiança da função deve aceitar o CRN principal do usuário do Workspace. Para uma origem de máquina, substitua a verificação de atribuição por `iam:AssumeRole` na função de destino na política de conta de origem. Para a suposição de contas cruzadas, use o CRN de função completo da conta de destino. A confiança deve identificar a conta de origem e o principal de origem imutável corretamente. A assunção de função entre organizações não é suportada. ## A delegação da organização é negada Anexar uma política de organização requer permissão do Workspace na política e permissão do IAM para atualizar a função de destino ou a conta de serviço. Ambos devem ser mantidos pelo mesmo chamador. Um administrador de conta sem concessão de organização não pode conceder a si mesmo. A mesma proteção se aplica a alterações confidenciais em uma identidade que já possui subsídios da organização. Consulte [delegação da organização](/pt/workspace/permissions#delegating-organization-policies). ## Erros que podem ser enganosos Um recurso fora da sua organização ou conta selecionada pode retornar `404` para evitar confirmar sua existência. Verifique o escopo, bem como o UUID. O ponto final de revogação de sessão verifica `iam:RevokeSession`, em seguida, lê a sessão para sua resposta com `iam:GetSTSSession`. Concede-me ambos. Com apenas a primeira permissão, a revogação pode ter êxito antes que a leitura seja negada. O anexo de política gerenciada requer permissão de política e de recurso de destino. Uma concessão apenas em CRNs de política ou apenas em CRNs de identidade está incompleta. Consulte [Anexos do IAM](/pt/iam/permissions#attaching-and-detaching-require-both-resources) e [Permissões de espaço de trabalho](/pt/workspace/permissions). Operadores desconhecidos não correspondem a instruções allow. Para uma negação com ação e recurso correspondentes, um operador desconhecido falha fechado. Verifique a ortografia do operador quando uma negação for mais ampla do que o esperado. Um `503 SERVICE_UNAVAILABLE` durante uma troca de credenciais pode indicar uma falha temporária de dependência de plataforma. Tente novamente com backoff; rodar uma chave válida não corrige uma troca indisponível. ## Leituras de acesso e associação à coleção Uma lista de nível superior autoriza um CRN de coleção, não linhas individuais. Uma política em uma função não concede `ListRoles`. Listas de relacionamento, em vez disso, autorizam seu pai. Veja [listing](/pt/iam/permissions#listing-cannot-be-narrowed). O catálogo de regiões é público. A troca de tokens verifica as credenciais. Os seres humanos podem ler as organizações às quais pertencem através da associação; as máquinas precisam de `workspace:GetOrganization`. Essas verificações diferem das permissões de recursos de conta comuns. ## O que o log de auditoria mostra e não mostra O registro de auditoria registra mutações **bem-sucedidas** do IAM e do Workspace — quem anexou qual política a quem, quem criou uma função, quem removeu um usuário. Isso é o que você quer para uma revisão de acesso, e é consultável através de `GET /v1/audit-logs`. Autorização **negações não estão nele**. Uma solicitação recusada é registrada nos próprios logs do serviço, com a ação e o CRN do recurso que o serviço realmente solicitou, mas nada é exibido para você por meio da API. Então, "qual CRN minha política tinha que corresponder?" não pode ser respondida a partir do log de auditoria. Deriva-o em vez disso: as formas estão listadas em [resources](/pt/iam/permissions#policy-role-and-group-crns-use-immutable-names), e a página de permissões de cada serviço dá a sua própria. Os eventos de login são a exceção que registra falhas — um registro de dois fatores com falha ou uma chave de segurança removida são auditados de qualquer maneira, porque a falha é a metade interessante. ### Ler identidades de eventos Os logs de auditoria não têm página de console. Use a API para inspecionar as identidades de eventos e os rótulos retidos. O `crn` do evento identifica o próprio registro de auditoria, na organização autenticada. Seu segmento final é o `id` do evento. `actor_crn` e `resource_crn` identificam o ator e o alvo como eles estavam no momento do evento. Esses instantâneos não são alterados quando um nome é alterado ou um recurso é excluído. `actor_name`, `actor_email` e `resource_name` são rótulos opcionais retidos. Use-os para exibição, não para construir uma identidade. Eles podem permanecer disponíveis depois que o ator ou o alvo foi excluído; lidar com rótulos ausentes ou nulos. Por exemplo, uma resposta de API pode conter este registro de auditoria: ```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" } ``` Eventos históricos sem instantâneos de identidade retornam CRNs `null`. Um destino que não pôde ser resolvido a partir de dados de tempo de evento também tem um `resource_crn` nulo, como uma redefinição de senha para um endereço de e-mail desconhecido. Quando um UUID de destino é conhecido, ele é mantido em `details.resource_id`; não substitua esse UUID ou um rótulo de exibição por um CRN ausente. Um registro de API sem snapshots ou rótulos retidos pode ter esta aparência: ```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" } } ``` Esses exemplos mostram API JSON. A saída CLI JSON omite campos CRN nulos. Para um ator de função assumida, `actor_crn` identifica a função, como `crn:iam::production:role/deployer`. O opcional `details.actor_session_crn`, em forma de `crn:iam::production:sts-session/`, correlaciona o evento com sua chamada AssumeRole.