Ao tentar assumir uma função do Resource Access Management (RAM), o RAM avalia políticas para permitir ou negar a solicitação. Este tópico explica a lógica de avaliação aplicada especificamente à ação sts:AssumeRole.
Assumir uma função do RAM é uma ação especial que exige a verificação simultânea de dois conjuntos de permissões:
Permissões da entidade principal: a entidade que tenta assumir a função (um usuário do RAM ou outra função) deve possuir uma política baseada em identidade que autorize a chamada da ação
sts:AssumeRolena função de destino.Política de confiança da função: a função a ser assumida deve conter uma política de confiança (política baseada em recurso) que especifique o solicitante como entidade principal confiável.
Atenda a ambas as condições para que a solicitação tenha êxito. O diagrama a seguir ilustra o processo de avaliação.
A avaliação de políticas ao assumir uma função do RAM segue a lógica padrão, com uma exceção importante: a etapa de combinação de decisões (Etapa 4).
Se você já conhece o processo padrão, consulte apenas a Etapa 4 deste tópico. Para uma visão geral completa das regras padrão, confira 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 funcionam como diretrizes de permissão para a conta.
Se a política de controle não autorizar a ação solicitada, o RAM nega a solicitação e encerra a avaliação.
Se a ação for permitida, a verificação avança para a próxima etapa.
Caso não haja políticas de controle, ignore esta etapa.
As políticas de controle abrangem todas as entidades principais do RAM (usuários e funções) em uma conta membro, mas não se aplicam ao proprietário da conta nem a entidades principais na conta de gerenciamento do Resource Directory.
Etapa 2: Avaliar políticas de sessão da função do RAM (se aplicável)
Quando a entidade principal é uma função do RAM assumida com uma política de sessão (por exemplo, por meio da operação AssumeRole), o RAM avalia essa política.
Se a política de sessão não autorizar a ação solicitada, o RAM nega a solicitação e encerra a avaliação.
Se a ação for permitida, a avaliação prossegue.
Ignore esta etapa para solicitações de usuários do RAM e SSO federado, pois as políticas de sessão não se aplicam nesses cenários.
Etapa 3: Avaliar políticas baseadas em identidade e baseadas em recurso
O RAM avalia as políticas baseadas em identidade (vinculadas ao usuário ou função do RAM solicitante) e as políticas baseadas em recurso (vinculadas ao recurso de destino).
-
Política baseada em identidade: o RAM avalia todas as políticas vinculadas à entidade principal solicitante. Se alguma política negar explicitamente a solicitação, o resultado será uma negação explícita. Se pelo menos uma política permitir a solicitação, o resultado será uma permissão. Caso contrário, o resultado será uma negação implícita.
NotaDurante o SSO iniciado pelo IdP, o usuário ainda não possui uma identidade assumida, portanto, nenhuma política baseada em identidade é avaliada. O RAM verifica apenas a política de confiança da função.
Política baseada em recurso: se o recurso de destino possuir 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 será permissão, negação explícita ou negação implícita. Caso não haja política baseada em recurso, ignore esta verificação.
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 rigorosa do que a aplicada a outras ações:
A solicitação só será PERMITIDA se ambas as políticas (baseada em identidade e de confiança da função do RAM) resultarem em
Allow.Em todos os outros casos, inclusive se alguma política resultar em negação implícita ou explícita, a solicitação será NEGADA.