Monitorar e controlar ações realizadas com funções assumidas - AWS Identity and Access Management

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.

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.

  1. 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.

  2. 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.

  3. Reveja o CloudTrail: reveja as informações de identidade-fonte para suas funções de teste nos logs do CloudTrail.

  4. 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.

  5. 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.

  6. 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ção AssumeRole* 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 a sts: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 chave aws:SourceIdentity estará presente na solicitação. A AWS não controla o valor da identidade-fonte nas chaves sts:SourceIdentity ou aws: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ção AssumeRole* 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ão sts: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 de identidades da Web 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 Sobre a federação baseada em 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) no AWS Security Blog.

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 de segurança que chama a operação AssumeRoleWithWebIdentity é autenticado usando federação de identidade da Web 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 de identidades da web para AWS Management Console acesso, consulte Sobre a federação de identidades da Web.

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 http://aws.amazon.com/source_identity 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 de identidade da Web e os usuários forem autenticados com AssumeRoleWithWebIdentity, sua política de confiança de função pode se assemelhar à seguinte.

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 obter mais informações, consulte

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": "123456789012" }, "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/Assumed_Role", "roleSessionName": "Test1", "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.