Quando um principal tenta assumir uma função do Resource Access Management (RAM), o serviço avalia um conjunto de políticas para permitir ou negar a solicitação. Este tópico explica a lógica de avaliação específica da ação sts:AssumeRole.
Assumir uma função do RAM é uma ação especial que exige verificação simultânea de dois conjuntos de permissões:
Permissões do principal: O principal (usuário do RAM ou outra função) que tenta assumir a função deve ter uma política baseada em identidade que conceda permissão para chamar a ação
sts:AssumeRolena função de destino.Política de confiança da função: A função a ser assumida deve ter uma política de confiança (política baseada em recurso) que especifique o solicitante como principal confiável.
Ambas as condições devem ser atendidas para que a solicitação tenha êxito. O processo de avaliação está ilustrado abaixo.
A avaliação de políticas ao assumir uma função do RAM segue a lógica padrão, com uma exceção fundamental: a etapa de combinação de decisões (Etapa 4).
Se você já conhece o processo padrão, revise apenas a Etapa 4 deste tópico. Para obter uma visão completa das regras padrão, consulte Como o RAM avalia políticas.
Etapa 1: Avaliar políticas de controle do Resource Directory (se aplicável)
Se a conta for membro de um resource directory, o RAM avalia as políticas de controle aplicáveis. Essas políticas atuam como barreiras de permissão para a conta.
Se a política de controle não permitir a ação solicitada, a solicitação será negada e a avaliação interrompida.
Se permitida, a avaliação prossegue para a próxima etapa.
Se não houver 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) em 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 da função do RAM (se aplicável)
Se o principal for uma função do RAM assumida com uma política de sessão (por exemplo, via operação AssumeRole), o RAM avalia 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 interrompida.
Se permitida, a avaliação prossegue.
Esta etapa é ignorada em solicitações de usuários do RAM e SSO federado, pois políticas de sessão não se aplicam.
Etapa 3: Avaliar políticas baseadas em identidade e baseadas em recurso
O RAM avalia políticas baseadas em identidade (anexadas ao usuário ou função do RAM solicitante) e políticas baseadas em recurso (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 é uma negação explícita. Se pelo menos uma política permitir a solicitação, o resultado é uma permissão. Caso contrário, ocorre 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 é avaliada. Apenas a política de confiança da função do RAM é verificada.
Política baseada em recurso: Se o recurso de destino tiver uma política baseada em recurso (como uma política de bucket do OSS ou uma política de confiança de função do RAM), o RAM a avalia com a mesma lógica: o resultado é uma permissão, uma negação explícita ou uma negação implícita. Se não houver política baseada em recurso, esta verificação é ignorada.
Etapa 4: Combinar decisões e determinar o resultado final
Por fim, o RAM combina os resultados da Etapa 3 para tomar a decisão final. A lógica para assumir uma função é mais restritiva do que para outras ações:
A solicitação é PERMITIDA somente se ambas (a política baseada em identidade e a política de confiança da função do RAM) resultarem em
Allow.Em todos os outros casos, inclusive se qualquer uma das políticas resultar em negação implícita ou explícita, a solicitação é NEGADA.