Monitorar e controlar ações realizadas com funções assumidas
Uma função do IAM é um objeto no IAM ao qual são atribuídas permissões. Ao assumir essa função usando uma identidade do IAM ou uma identidade de fora da AWS, você recebe uma sessão com as permissões atribuídas à função.
Quando você executa ações na AWS, as informações sobre sua sessão podem ser registradas no AWS CloudTrail para o administrador da conta monitorar. Os administradores podem configurar funções para exigir que as identidades passem uma string personalizada que identifica a pessoa ou a aplicação que está executando ações na AWS. Essas informações de identidade são armazenadas como a identidade-fonte no AWS CloudTrail. Quando o administrador revisa a atividade no CloudTrail, ele pode visualizar as informações de identidade-fonte para determinar quem ou o que executou ações com sessões de funções assumidas.
Depois que uma identidade-fonte é definida, ela estará presente em solicitações para qualquer ação da AWS realizada durante a sessão de função. O valor definido persiste quando uma função é usada para assumir outra função por meio da AWS CLI ou da API da AWS, o que é conhecido como encadeamento de funções. O valor definido não pode ser alterado durante a sessão da função. Os administradores podem configurar permissões detalhadas com base na presença ou no valor da identidade-fonte para controlar ainda mais as ações da AWS que são tomadas com funções compartilhadas. Você pode decidir se o atributo de identidade-fonte pode ser usado, se é necessário e qual valor pode ser usado.
A maneira como você usa a identidade-fonte difere do nome da sessão de função e das etiquetas de sessão de uma maneira importante. O valor da identidade-fonte não pode ser alterado depois de definido, e ele persiste para quaisquer ações adicionais realizadas com a sessão de função. Veja como você pode usar etiquetas de sessão e nome de sessão de função:
-
Etiquetas de sessão: você também pode passar etiquetas de sessão ao assumir uma função ou federar um usuário. As etiquetas de sessão estão presentes quando uma função é assumida. Você pode ainda definir políticas que usam chaves de condição de tag para conceder permissões aos seus principais com base nas tags. Em seguida, você pode usar o CloudTrail para visualizar as solicitações feitas para assumir funções ou federar usuários. Para saber mais sobre tags de sessão, consulte Passar tags de sessão no AWS STS.
-
Nome da sessão de função: você pode usar a chave de condição
sts:RoleSessionName
em uma política de confiança de função para exigir que seus usuários forneçam um nome de sessão específico quando assumirem uma função. O nome da sessão de função pode ser usado para diferenciar sessões de função quando uma função é usada por diferentes entidades de segurança. Para saber mais sobre o nome da sessão de função, consulte sts:RoleSessionName.
Recomendamos que você use a identidade-fonte quando quiser controlar a identidade que assume uma função. A identidade-fonte também é útil para mineração de logs do CloudTrail para determinar quem usou a função para executar ações.
Tópicos
- Configuração para usar a identidade-fonte
- O que é preciso saber sobre a identidade-fonte
- Permissões necessárias para definir a identidade-fonte
- Especificação de uma identidade-fonte ao assumir uma função
- Uso da identidade-fonte com AssumeRole
- Uso da identidade-fonte com AssumeRoleWithSAML
- Uso da identidade-fonte com AssumeRoleWithWebIdentity
- Controlar o acesso usando informações de identidade-fonte
- Visualização de uma identidade-fonte no CloudTrail
Configuração para usar a identidade-fonte
A maneira que você configura para usar a identidade-fonte depende do método usado quando suas funções são assumidas. Por exemplo, seus usuários do IAM podem assumir funções diretamente usando a operação AssumeRole
. Se você tiver identidades empresariais, também conhecidas como identidades do quadro de funcionários, elas poderão acessar seus recursos da AWS usando AssumeRoleWithSAML
. Se os usuários finais acessarem suas aplicações móveis ou Web, eles poderão fazer isso usando AssumeRoleWithWebIdentity
. Veja a seguir uma visão geral do fluxo de trabalho de alto nível para ajudar você a entender como configurar para uso as informações de identidade-fonte em seu ambiente existente.
-
Configure usuários e funções de teste: usando um ambiente de pré-produção, configure usuários e funções de teste e configure suas respectivas políticas para permitir a definição de uma identidade-fonte.
Se você usar um provedor de identidade (IdP) para suas identidades federadas, configure seu IdP para passar um atributo de usuário de sua escolha para a identidade-fonte na asserção ou no token.
-
Assuma a função: teste assumindo funções e passando uma identidade-fonte com os usuários e funções que você configurou para teste.
-
Reveja o CloudTrail: reveja as informações de identidade-fonte para suas funções de teste nos logs do CloudTrail.
-
Treine seus usuários: depois de testar em seu ambiente de pré-produção, certifique-se de que seus usuários saibam como transmitir as informações de identidade-fonte, se necessário. Defina um prazo para quando você exigirá que seus usuários forneçam uma identidade-fonte em seu ambiente de produção.
-
Configure políticas de produção: configure as políticas para o ambiente de produção e, em seguida, adicione-as aos usuários e funções de produção.
-
Monitore a atividade: monitore sua atividade de função de produção usando logs do CloudTrail.
O que é preciso saber sobre a identidade-fonte
Lembre-se do seguinte ao trabalhar com a identidade-fonte.
-
As políticas de confiança para todas as funções conectadas a um provedor de identidade (IdP) devem ter a permissão
sts:SetSourceIdentity
. Para funções que não têm essa permissão na política de confiança de função, a operaçãoAssumeRole*
falhará. Se não quiser atualizar a política de confiança de função para cada função, você pode usar uma instância do IdP separada para passar a identidade-fonte. Em seguida, adicione asts:SetSourceIdentity
permissão apenas às funções que estiverem conectadas ao IdP separado. -
Quando uma identidade define uma identidade-fonte, a chave
sts:SourceIdentity
fica presente na solicitação. Para ações subsequentes realizadas durante a sessão de função, a chaveaws:SourceIdentity
estará presente na solicitação. A AWS não controla o valor da identidade-fonte nas chavessts:SourceIdentity
ouaws:SourceIdentity
. Se você optar por exigir uma identidade-fonte, deverá escolher um atributo que deseja que seus usuários ou o IdP forneçam. Por motivos de segurança, você deve garantir que pode controlar como esses valores são fornecidos. -
O valor da identidade-fonte deve ter entre 2 e 64 caracteres, pode conter apenas caracteres alfanuméricos, sublinhados e os seguintes caracteres: . , + = @ - (hífen). Você não pode usar um valor que comece com o texto
aws:
. Este prefixo está reservado para uso interno da AWS. -
As informações de identidade-fonte não são capturadas pelo CloudTrail quando um produto da AWS ou uma função vinculada ao serviço executa uma ação em nome de uma identidade do quadro de funcionários ou federada.
Importante
Você não pode alternar para uma função no AWS Management Console ue exija que uma identidade-fonte seja definida quando a função for assumida. Para assumir essa função, você pode usar a AWS CLI ou a API da AWS para chamar a operação AssumeRole
e especificar o parâmetro da identidade-fonte.
Permissões necessárias para definir a identidade-fonte
Além da ação que corresponde à operação da API, é necessário ter a seguinte ação somente com permissão em sua política:
sts:SetSourceIdentity
-
Para especificar uma identidade-fonte, as entidades de segurança (usuários e funções do IAM) devem ter permissões para
sts:SetSourceIdentity
. Como administrador, você pode configurar isso na política de confiança da função e na política de permissões da entidade de segurança. -
Quando você assume uma função com outra função, chamada de encadeamento de funções, as permissões para
sts:SetSourceIdentity
são necessárias na política de permissões da entidade de segurança que está assumindo a função e na política de confiança da função de destino. Caso contrário, a operação de assumir função falhará. -
Ao usar a identidade-fonte, as políticas de confiança de função para todas as funções conectadas a um IdP devem ter a permissão
sts:SetSourceIdentity
. A operaçãoAssumeRole*
falhará para qualquer função conectada a um IdP sem essa permissão. Se você não quiser atualizar a política de confiança de função para cada função, use uma instância de IdP separada para passar a identidade-fonte e adicionar a permissãosts:SetSourceIdentity
apenas às funções que estão conectadas ao IdP separado. -
Para definir uma identidade-fonte entre os limites da conta, você deve incluir a permissão
sts:SetSourceIdentity
em dois lugares. Ela deve estar na política de permissões da entidade de segurança na conta originadora e na política de confiança da função na conta de destino. Talvez seja necessário fazer isso, por exemplo, quando uma função for usada para assumir uma função em outra conta com oencadeamento de funções.
Como administrador da conta, imagine que você deseja permitir que o usuário do IAM DevUser
em sua conta assuma a Developer_Role
na mesma conta. Mas você deseja permitir essa ação somente se o usuário tiver definido a identidade-fonte como seu próprio nome de usuário do IAM. Você pode anexar a política a seguir ao usuário do IAM.
exemplo Exemplo de política baseada em identidade anexada ao DevUser
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::
123456789012
:role/Developer_Role
" }, { "Sid": "SetAwsUserNameAsSourceIdentity", "Effect": "Allow", "Action": "sts:SetSourceIdentity", "Resource": "arn:aws:iam::123456789012
:role/Developer_Role
", "Condition": { "StringLike": { "sts:SourceIdentity": "${aws:username}" } } } ] }
Para impor os valores de identidade-fonte aceitáveis, você pode configurar a política de confiança de função a seguir. A política fornece ao usuário do IAM DevUser
permissões para assumir a função e definir uma identidade-fonte. A chave de condição sts:SourceIdentity
define o valor da identidade-fonte aceitável.
exemplo Exemplo de política de confiança de função para identidade-fonte
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowDevUserAssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
123456789012
:user/DevUser
" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "sts:SourceIdentity": "DevUser
" } } } ] }
Usando as credenciais DevUser
do usuário do IAM, o usuário tenta assumir a função DeveloperRole
usando a solicitação da AWS CLI a seguir.
exemplo Exemplo de solicitação da CLI AssumeRole
aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \
Quando a AWS avalia a solicitação, o contexto da solicitação contém a sts:SourceIdentity
de DevUser
.
Especificação de uma identidade-fonte ao assumir uma função
Você pode especificar uma identidade-fonte ao usar uma das operações da API AssumeRole*
do AWS STS para obter credenciais de segurança temporárias para uma função. A operação de API que você usa difere dependendo do seu caso de uso. Por exemplo, se você usar funções do IAM para dar aos usuários do IAM acesso aos recursos da AWS quais eles normalmente não têm acesso, você poderá usar a operação AssumeRole
. Se você usar a federação de identidade empresarial para gerenciar os usuários do quadro de funcionários, poderá usar a operação AssumeRoleWithSAML
. Se você usar a federação OIDC para permitir que os usuários finais acessem suas aplicações móveis ou Web, use a operação AssumeRoleWithWebIdentity
. As seções a seguir explicam como usar a identidade-fonte em cada operação. Para saber mais sobre cenários comuns de credenciais temporárias, consulte Cenários comuns para credenciais temporárias.
Uso da identidade-fonte com AssumeRole
A operação AssumeRole
retorna um conjunto de credenciais temporárias que você pode usar para acessar recursos da AWS. Você pode usar o usuário do IAM ou credenciais de função para chamar AssumeRole
. Para passar a identidade-fonte enquanto assume uma função, use a opção -–source-identity
da AWS CLI ou o parâmetro SourceIdentity
da API da AWS. O exemplo a seguir mostra como especificar a identidade-fonte usando a AWS CLI.
exemplo Exemplo de solicitação da CLI AssumeRole
aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/developer \ --role-session-name Audit \ --source-identity Admin \
Uso da identidade-fonte com AssumeRoleWithSAML
A entidade de segurança que chama a operação AssumeRoleWithSAML
é autenticada usando a federação baseada em SAML. Essa operação retorna um conjunto de credenciais temporárias que você pode usar para acessar os recursos da AWS. Para obter mais informações sobre como usar a federação baseada em SAML para acesso ao AWS Management Console, consulte Habilitar o acesso de usuários federados SAML 2.0 ao AWS Management Console. Para obter detalhes sobre acesso à AWS CLI ou à API da AWS, consulte Federação SAML 2.0. Para obter um tutorial sobre como configurar a federação do SAML para seus usuários do Active Directory, consulte AWS Federated Authentication with Active Directory Federation Services (ADFS)
Como administrador, você pode permitir que os membros do diretório da empresa se agrupem na AWS usando a operação AssumeRoleWithSAML
da AWS STS. Para isso, é necessário concluir as seguintes tarefas:
Para definir um atributo SAML para a identidade-fonte, inclua o elemento Attribute
com o atributo Name
definido como https://aws.amazon.com/SAML/Attributes/SourceIdentity
. Use o elemento AttributeValue
para especificar o valor da identidade-fonte. Por exemplo, suponha que você deseja passar o seguinte atributo de identidade como a identidade-fonte.
SourceIdentity:DiegoRamirez
Para passar esse atributo, inclua o seguinte elemento em sua declaração SAML.
exemplo Exemplo de trecho de uma declaração SAML
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity"> <AttributeValue>DiegoRamirez</AttributeValue> </Attribute>
Uso da identidade-fonte com AssumeRoleWithWebIdentity
A entidade principal que chama a operação AssumeRoleWithWebIdentity
é autenticada usando federação compatível com o OpenID Connect (OIDC). Essa operação retorna um conjunto de credenciais temporárias que você pode usar para acessar os recursos da AWS. Para obter mais informações sobre como usar a federação OIDC para acesso ao AWS Management Console, consulte Federação OIDC.
Para passar a identidade-fonte do OpenID Connect (OIDC), é necessário incluir a identidade-fonte no JSON Web Token (JWT). Inclua a identidade-fonte no namespace https://aws.amazon.com/
no token ao enviar a solicitação AssumeRoleWithWebIdentity
. Para saber mais sobre tokens e reivindicações OIDC, consulte Usar tokens com grupos de usuários no Guia do desenvolvedor Amazon Cognito.
Por exemplo, o JWT decodificado a seguir é um token usado para chamar AssumeRoleWithWebIdentity
com a identidade-fonteAdmin
.
exemplo Exemplo de JSON Web Token decodificado
{ "sub": "johndoe", "aud": "ac_oic_client", "jti": "ZYUCeRMQVtqHypVPWAN3VB", "iss": "https://xyz.com", "iat": 1566583294, "exp": 1566583354, "auth_time": 1566583292, "https://aws.amazon.com/source_identity":"Admin" }
Controlar o acesso usando informações de identidade-fonte
Quando uma identidade-fonte é definida inicialmente, a chave sts:SourceIdentity fica presente na solicitação. Depois que uma identidade-fonte for definida, a chave aws:SourceIdentity estará presente em todas as solicitações subsequentes feitas durante a sessão de função. Como administrador, você pode escrever políticas que concedem autorização condicional para realizar ações da AWS com base na existência ou no valor do atributo de identidade-fonte.
Imagine que você deseja exigir que seus desenvolvedores definam uma identidade-fonte para assumir uma função crítica que tenha permissão para gravar em um recurso crítico de produção da AWS. Imagine também que você conceda acesso da AWS às identidades do quadro de funcionários usando AssumeRoleWithSAML
. Você deseja que apenas os desenvolvedores sênior Saanvi e Diego tenham acesso à função, portanto, você cria a seguinte política de confiança para a função.
exemplo Exemplo de política de confiança de função para identidade-fonte (SAML)
{ "Version": "2012-10-17", "Statement": [ { "Sid": "SAMLProviderAssumeRoleWithSAML", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::
111122223333
:saml-provider/name-of-identity-provider" }, "Action": [ "sts:AssumeRoleWithSAML" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } }, { "Sid": "SetSourceIdentitySrEngs", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333
:saml-provider/name-of-identity-provider" }, "Action": [ "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] }
A política de confiança possui uma condição para sts:SourceIdentity
que requer uma identidade-fonte definida como Saanvi ou Diego para assumir a função crítica.
Como alternativa, se você usar um provedor OIDC para federação e os usuários forem autenticados com AssumeRoleWithWebIdentity
, sua política de confiança de perfil poderá ser semelhante à mostrada a seguir.
exemplo Exemplo de política de confiança de função para identidade-fonte (provedor OIDC)
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::
111122223333
:oidc-provider/server.example.com
" }, "Action": [ "sts:AssumeRoleWithWebIdentity", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "server.example.com
:aud": "oidc-audience-id
" }, "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] }
Requisitos de encadeamento de funções e entre contas
Imagine que você deseja permitir que os usuários que assumiram a CriticalRole
assumam uma CriticalRole_2
em outra conta. As credenciais da sessão de função que foram obtidas para assumir CriticalRole
são usadas para encadear funções para uma segunda função, CriticalRole_2
, em outra conta. A função está sendo assumida além dos limites de uma conta. Portanto, a permissão sts:SetSourceIdentity
deve ser concedida na política de permissões em CriticalRole
e na política de confiança de função em CriticalRole_2
.
exemplo Exemplo de política de permissões em CriticalRole
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::
222222222222
:role/CriticalRole_2" } ] }
Para proteger a definição de identidade-fonte além do limite da conta, a seguinte política de confiança de função confia apenas na entidade de segurança da função de CriticalRole
para definir a identidade-fonte.
exemplo Exemplo de política de confiança de função em CriticalRole_2
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
111111111111
:role/CriticalRole" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "aws:SourceIdentity": ["Saanvi","Diego"] } } } ] }
O usuário faz a seguinte chamada usando credenciais de sessão de função obtidas assumindo a CriticalRole. A identidade-fonte foi definida durante a suposição de CriticalRole, portanto, ela não precisa ser explicitamente definida novamente. Se o usuário tentar definir uma identidade-fonte diferente do valor definido quando CriticalRole
foi assumida, a solicitação de assumir função será negada.
exemplo Exemplo de solicitação da CLI AssumeRole
aws sts assume-role \ --role-arn arn:aws:iam::
222222222222
:role/CriticalRole_2 \ --role-session-name Audit \
Quando a entidade de segurança de chamada assume a função, a identidade-fonte na solicitação persiste desde a primeira sessão de função assumida. Portanto, as chaves aws:SourceIdentity
e sts:SourceIdentity
estão presentes no contexto da solicitação.
Visualização de uma identidade-fonte no CloudTrail
Você pode usar o CloudTrail para visualizar as solicitações feitas para assumir funções ou federar usuários. Você também pode visualizar as solicitações de função ou do usuário para realizar ações na AWS. O arquivo de log do CloudTrail inclui informações sobre a identidade-fonte definida para a função assumida ou a sessão de usuário federado. Para ter mais informações, consulte Registro em log de chamadas de API do IAM e do AWS STS com o AWS CloudTrail.
Por exemplo, suponha que um usuário faça uma solicitção AssumeRole
ao AWS STS e defina uma identidade-fonte. Você pode encontrar as informações de sourceIdentity
na chave requestParameters
em seu log do CloudTrail.
exemplo Exemplo de seção requestParameters em um log do AWS CloudTrail
"eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "111122223333" }, "eventTime": "2020-04-02T18:20:53Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.64", "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86", "requestParameters": { "roleArn": "arn:aws:iam::123456789012:role/DevRole", "roleSessionName": "Dev1", "sourceIdentity": "
source-identity-value-set
" }
Se o usuário usar a sessão de função assumida para executar uma ação, as informações da identidade-fonte estarão presentes na chave userIdentity
no log do CloudTrail.
exemplo Exemplo de chave userIdentity em um log do AWS CloudTrail
{ "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1", "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAJ45Q7YFFAREXAMPLE", "arn": "arn:aws:iam::123456789012:role/DevRole", "accountId": "123456789012", "userName": "DevRole" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-02-21T23:46:28Z" }, "sourceIdentity": "source-identity-value-present" } } }
Para ver exemplos de eventos de API do AWS STS em logs do CloudTrail, consulte Exemplo de eventos de API do IAM no log do CloudTrail. Para obter mais detalhes sobre as informações contidas nos arquivos de log do CloudTrail, consulte Referência de evento do CloudTrail no Guia do usuário do AWS CloudTrail.