Resource Access Management:Rastreamento e controle de acesso com SourceIdentity

Requisitos de formato

• O valor deve ter entre 2 e 64 caracteres.

• São permitidas letras, dígitos e os seguintes caracteres especiais: =, ,, ., @, - e _.

• Não utilize prefixos reservados pela Alibaba Cloud, como acs:, aliyun: ou alibabacloud:.

Ações

Exemplo de configuração de ação

Para permitir que uma identidade (usuário ou função RAM) defina SourceIdentity ao chamar AssumeRole, conceda a permissão sts:SetSourceIdentity tanto na política baseada em identidade do principal quanto na política de confiança da função de destino. Para isso, adicione sts:SetSourceIdentity ao bloco Action.

• Exemplo de política baseada em identidade (concedida ao chamador):

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/TARGET_ROLE"
      }
    ]
  }

• Exemplo de política de confiança (configurada na função a ser assumida):

  {
    "Statement": [
      {
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Effect": "Allow",
        "Principal": {
          "RAM": [
            "acs:ram::ACCOUNT_ID:root"
          ]
        }
      }
    ],
    "Version": "1"
  }

Configuração de ação para SSO de função

Ao assumir uma função chamando as operações AssumeRoleWithSAML ou AssumeRoleWithOIDC, conceda a permissão sts:SetSourceIdentity apenas na política de confiança da função de destino. A política a seguir é um exemplo para SSO baseado em função SAML:

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "saml:recipient": [
            "https://signin.aliyun.com/saml-role/sso"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "Federated": [
          "acs:ram::ACCOUNT_ID:saml-provider/PROVIDER_NAME"
        ]
      }
    }
  ],
  "Version": "1"
}

Chaves de condição

A diferença entre as chaves de condição sts:SourceIdentity e acs:SourceIdentity é a seguinte:

• sts:SourceIdentity corresponde ao atributo SourceIdentity na solicitação de assunção de função.

• acs:SourceIdentity corresponde ao atributo SourceIdentity presente na sessão de função (incluindo o token STS) após uma assunção bem-sucedida.

Para a assunção inicial de função, use a chave de condição sts:SourceIdentity nas suas políticas, incluindo políticas baseadas em identidade e políticas de confiança. Nessa etapa, ainda não existe uma sessão de função válida; portanto, usar a chave de condição acs:SourceIdentity causará falha na assunção.

Exemplo de controle de condição

Ao usar a chave de condição sts:SourceIdentity no bloco Condition de uma política, você exige a transmissão de um valor específico de SourceIdentity ao assumir uma função. Configure condições em um ou ambos os tipos de política a seguir:

• Definir uma condição em uma política baseada em identidade: Restringe a identidade a definir um valor específico de SourceIdentity ao assumir uma função específica.

• Definir uma condição em uma política de confiança: Restringe qualquer identidade a definir um valor específico de SourceIdentity ao assumir esta função.

Inclua também a ação sts:SetSourceIdentity no bloco Action da política para que a condição tenha efeito.

Suponha que exista uma função RAM com altos privilégios para o ambiente de produção chamada prod-role. Um administrador precisa implementar os seguintes controles:

1. Apenas os usuários RAM Alice e Bob podem assumir prod-role.

2. Ao assumir prod-role, é obrigatório definir SourceIdentity, e seu valor deve corresponder ao nome de usuário de quem está assumindo a função. Por exemplo, quando Alice assume a função, ela define o valor como alice ou alice@exampledomain.com.

Etapa 1: Configurar a política de confiança para prod-role

Esta política garante que apenas Alice e Bob possam assumir esta função e que a solicitação inclua um valor de SourceIdentity que comece com alice ou bob.

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": [
            "alice*",
            "bob*"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::ACCOUNT_ID:user/alice",
          "acs:ram::ACCOUNT_ID:user/bob"
        ]
      }
    }
  ],
  "Version": "1"
}

Etapa 2: Configurar políticas baseadas em identidade para os usuários Alice e Bob

As políticas a seguir concedem a Alice e Bob permissão para assumir prod-role e impõem que eles definam um SourceIdentity correspondente aos seus respectivos nomes de usuário na solicitação.

• Política baseada em identidade para Alice

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/prod-role",
        "Condition": {
          "StringLike": {
            "sts:SourceIdentity": [
              "alice*"
            ]
          }
        }
      }
    ]
  }

• Política baseada em identidade para Bob

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/prod-role",
        "Condition": {
          "StringLike": {
            "sts:SourceIdentity": [
              "bob*"
            ]
          }
        }
      }
    ]
  }

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "saml:recipient": [
            "https://signin.aliyun.com/saml-role/sso"
          ],
          "sts:SourceIdentity": [
            "employeeid-alice",
            "employeeid-bob"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "Federated": [
          "acs:ram::ACCOUNT_ID:saml-provider/PROVIDER_NAME"
        ]
      }
    }
  ],
  "Version": "1"
}

Cenário

Uma ferramenta de automação CI/CD, como o Jenkins, executa com uma função RAM chamada automation-role. Desenvolvedores como Alice e Bob podem assumir essa função.

Um desenvolvedor, como Alice, usa a ferramenta para implantar um aplicativo em um Bucket OSS no ambiente de produção. A ação de implantação exige assumir uma função com mais privilégios, deploy-role, que possui permissões de gravação no Bucket OSS.

Alice, Bob e automation-role pertencem à conta Alibaba Cloud A, enquanto deploy-role pertence à conta Alibaba Cloud B.

Requisito de negócio e fluxo de trabalho

O objetivo é permitir que automation-role assuma deploy-role apenas quando Alice for a chamadora original. Qualquer solicitação de outro usuário, como Bob, deve ser negada.

O fluxo de trabalho é o seguinte:

1. Alice chama a operação AssumeRole para assumir automation-role e define SourceIdentity como alice na solicitação.

2. Depois que automation-role obtém um token STS, ela chama novamente a operação AssumeRole para assumir deploy-role. O valor de SourceIdentity é transmitido automaticamente.

3. A política de confiança de deploy-role verifica se o SourceIdentity recebido é alice. Se a validação for aprovada, a assunção de função é permitida.

Etapas de configuração de política

Etapa 1: Modificar a política de confiança de deploy-role

Esta política permite solicitações de assunção apenas de automation-role na conta A, e somente se o valor de SourceIdentity for alice.

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "acs:SourceIdentity": [
            "alice"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::ACCOUNT_A_ID:role/automation-role"
        ]
      }
    }
  ],
  "Version": "1"
}

Etapa 2: Modificar as políticas de permissão e de confiança de automation-role

• Política baseada em identidade: Permite que a função automation-role assuma a função deploy-role na conta B.

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_B_ID:role/deploy-role"
      }
    ]
  }

• Política de confiança: Permite que Alice e Bob assumam automation-role.

  {
    "Statement": [
      {
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Effect": "Allow",
        "Principal": {
          "RAM": [
            "acs:ram::ACCOUNT_A_ID:user/alice",
            "acs:ram::ACCOUNT_A_ID:user/bob"
          ]
        }
      }
    ],
    "Version": "1"
  }

Etapa 3: Modificar as políticas baseadas em identidade para Alice e Bob

Permita que eles assumam a função automation-role e imponha a definição de um valor de SourceIdentity que corresponda exatamente ao nome de usuário de cada um.

• Política baseada em identidade para Alice

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_A_ID:role/automation-role",
        "Condition": {
          "StringEquals": {
            "sts:SourceIdentity": [
              "alice"
            ]
          }
        }
      }
    ]
  }

• Política baseada em identidade para Bob

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_A_ID:role/automation-role",
        "Condition": {
          "StringEquals": {
            "sts:SourceIdentity": [
              "bob"
            ]
          }
        }
      }
    ]
  }

Cenário 1: Problema na política baseada em identidade

Mensagem de erro:

{
  "RequestId": "AC9DDEC1-3E1F-50B8-A2D1-BAA155FD****",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. You should be authorized by RAM.",
  "AccessDeniedDetail": {
    "PolicyType": "AccountLevelIdentityBasedPolicy",
    "AuthAction": "sts:SetSourceIdentity",
    ...
  }
}

Causa:

• "PolicyType": "AccountLevelIdentityBasedPolicy" indica que o erro foi causado pela política baseada em identidade do chamador.

• "AuthAction": "sts:SetSourceIdentity" indica que falta permissão para a ação sts:SetSourceIdentity.

Solução: Solicite ao administrador que verifique a política baseada em identidade do chamador e garanta o seguinte:

1. A política inclui "Action": "sts:SetSourceIdentity".

2. O escopo de Resource da política inclui a função de destino que você está tentando assumir.

3. Se a política contiver uma Condition, confirme se o valor de SourceIdentity na sua solicitação atende à condição.

Cenário 2: Problema na política de confiança

Mensagem de erro:

{
  "RequestId": "ECC91EE1-0EB0-5E79-B3F5-E54FD8B9****",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. You should be authorized by RAM.",
  "AccessDeniedDetail": {
    "PolicyType": "AssumeRolePolicy",
    "AuthAction": "sts:SetSourceIdentity",
    ...
  }
}

Causa:

• "PolicyType": "AssumeRolePolicy" indica que o erro foi causado pela política de confiança da função de destino.

• "AuthAction": "sts:SetSourceIdentity" indica que a função de destino não confia na ação sts:SetSourceIdentity.

Solução: Solicite ao administrador que verifique a política de confiança da função de destino e garanta o seguinte:

1. A política inclui "Action": "sts:SetSourceIdentity".

2. Se a política contiver uma Condition, confirme se o valor de SourceIdentity na sua solicitação atende à condição.

Conselhos gerais para solução de problemas

1. Reduza o escopo: Se encontrar um problema de permissão ao definir SourceIdentity, tente remover o parâmetro SourceIdentity e assumir a função novamente. Se a ação for bem-sucedida, o problema provavelmente está nas configurações de permissão relacionadas a SourceIdentity.

2. Analise a mensagem de erro: Leia a seção AccessDeniedDetail da mensagem de erro, especialmente o campo PolicyType. Ele ajuda a determinar rapidamente se o problema está em uma política baseada em identidade ou em uma política de confiança.

3. Use ferramentas de diagnóstico: Se você tiver apenas o RequestId, utilize a ferramenta OpenAPI Explorer. Insira o RequestId e o sistema retornará informações diagnósticas detalhadas para ajudar a identificar o problema de permissão. Por exemplo:

   Um resultado de diagnóstico mostra um ErrorCode de NoPermission e um ErrorMessage de You are not authorized to do this action. You should be authorized by RAM.. A conclusão da verificação de permissão é Not authorized by identity-based policy (account-level) para a ação sts:SetSourceIdentity. A solução sugere conceder ao usuário RAM a política de sistema AliyunSTSAssumeRoleAccess, associada a sts:SetSourceIdentity, ou criar uma política personalizada.

4. Compare a política com a solicitação: Após localizar a política, verifique se as configurações de Resource e Condition correspondem aos parâmetros da sua solicitação de API, como o ARN da função de destino e o valor de SourceIdentity.

Para mais informações sobre solução de problemas de permissão, consulte Como solucionar erros de acesso negado.