Skip to main content
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

1

Verifique a conta da credencial

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.
2

Verifique o domínio da política

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.
3

Verifique explicitamente negar e permitir

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.
4

Verifique o CRN do recurso

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.
5

Verificar condições, limites e política de sessão

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.

​
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 e Permissões de espaço de trabalho.
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. 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, 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:
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:
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/<id>, correlaciona o evento com sua chamada AssumeRole.

​
Próximo

Permissões

Cada ação, e o recurso cada um é verificado contra.

Escrever políticas

Condições, operadores e o que uma chave ausente faz.