Quando um principal do RAM (usuário ou função) solicita acesso a um recurso da Alibaba Cloud, o RAM avalia todas as políticas aplicáveis para permitir ou negar a solicitação.
Princípios fundamentais
A avaliação de políticas segue dois princípios:
Negação por padrão: Os principais do RAM não têm permissões por padrão. A menos que uma política permita explicitamente a solicitação, ela será implicitamente negada.
A negação explícita prevalece sobre a permissão: Se alguma política contiver uma instrução
Denyexplícita, a solicitação será negada, independentemente de instruçõesAllowem outras políticas.
Fluxo de avaliação
O RAM avalia as políticas em uma ordem fixa. Se alguma etapa negar a solicitação, a avaliação será interrompida. A solicitação só será permitida se passar por todas as verificações de política aplicáveis.
A avaliação inclui as seguintes etapas:
Etapa 1: Avaliar políticas de controle do Resource Directory (se aplicável)
Se a conta for membro de um resource directory, o RAM avaliará as políticas de controle aplicáveis. Essas políticas funcionam como barreiras de proteção de permissões para a conta.
Caso a política de controle não permita a ação solicitada, a solicitação será negada e a avaliação será interrompida.
Se permitida, a avaliação prosseguirá para a próxima etapa.
Na ausência de políticas de controle, esta etapa será ignorada.
As políticas de controle se aplicam a todos os principais do RAM (usuários e funções) dentro de uma conta membro, mas não ao proprietário dessa conta nem aos principais na conta de gerenciamento do Resource Directory.
Etapa 2: Avaliar políticas de sessão de função do RAM (se aplicável)
Quando o principal for uma função do RAM assumida com uma política de sessão (como por meio da operação AssumeRole), o RAM avaliará essa política.
Se a política de sessão não permitir a ação solicitada, a solicitação será negada e a avaliação será interrompida.
Se permitida, a avaliação continuará.
Esta etapa será ignorada para solicitações de usuários do RAM e SSO federado, pois as políticas de sessão não se aplicam.
Etapa 3: Avaliar políticas baseadas em identidade e em recursos
O RAM avalia políticas baseadas em identidade (anexadas ao usuário ou à função do RAM solicitante) e políticas baseadas em recursos (anexadas ao recurso de destino).
-
Política baseada em identidade: O RAM avalia todas as políticas anexadas ao principal solicitante. Se alguma política negar explicitamente a solicitação, o resultado será uma negação explícita. Caso pelo menos uma política permita a solicitação, o resultado será uma permissão. Nos demais casos, o resultado será uma negação implícita.
NotaDurante o SSO iniciado pelo IdP, o usuário ainda não assumiu uma identidade; portanto, nenhuma política baseada em identidade será avaliada. Apenas a política de confiança da função do RAM será verificada.
Política baseada em recursos: Se o recurso de destino tiver uma política baseada em recursos (como uma política de bucket do OSS ou uma política de confiança de função do RAM), o RAM a avaliará com a mesma lógica: o resultado poderá ser uma permissão, uma negação explícita ou uma negação implícita. Caso não exista política baseada em recursos, esta verificação será ignorada.
Etapa 4: Determinar o resultado final
O RAM combina os resultados de todas as etapas anteriores para chegar a uma decisão final.
Se uma negação explícita ocorrer em qualquer etapa, a decisão final será DENY.
Se não houver negação explícita e pelo menos uma permissão for concedida (por uma política baseada em identidade ou em recursos), a decisão final será ALLOW.
Em todos os outros cenários (quando nenhuma política permitir explicitamente a solicitação), a decisão final será uma negação implícita.
Casos especiais de avaliação
Assunção de uma função do RAM: Assumir uma função do RAM é um caso especial que exige um
Allowtanto na política baseada em identidade do principal quanto na política de confiança da função. Para mais informações, consulte Como o RAM avalia políticas quando uma função é assumida.Object Storage Service (OSS): Para solicitações do OSS, as ACLs em buckets ou objetos são avaliadas após as políticas do RAM. Uma ACL pode negar uma solicitação mesmo que uma política do RAM a permita. Consulte Autorização do OSS.