Cenários de exemplo para uso de informações acessadas por último - AWS Identity and Access Management
Uso de informações para reduzir permissões para um grupo do IAMUso de informações para reduzir permissões para um usuário do IAMUso das informações antes de excluir recursos do IAMUso de informações antes de editar políticas do IAMOutros cenários do IAMUsar informações para refinar permissões para uma unidade organizacional

Cenários de exemplo para uso de informações acessadas por último

Você pode usar as informações do último acesso para tomar decisões sobre as permissões concedidas às entidades do IAM ou do AWS Organizations. Para ter mais informações, consulte Refinar permissões na AWS usando informações do último acesso.

nota

Antes de visualizar as informações de acesso para uma entidade ou política no IAM ou no AWS Organizations, é necessário entender o período do relatório, as entidades relatadas e os tipos de política avaliados para seus dados. Para obter mais detalhes, consulte Coisas para saber sobre as informações acessadas por último.

Cabe a você, como administrador, equilibrar a acessibilidade e o privilégio mínimo apropriado para a organização.

Uso de informações para reduzir permissões para um grupo do IAM

Você pode usar as informações do último acesso para reduzir permissões do grupo do IAM para incluir apenas os serviços de que os usuários precisam. Esse método é uma etapa importante em conceder menor privilégio em um nível de serviço.

Por exemplo, Paulo Santos é o administrador responsável por definir as permissões de usuário da AWS para Exemplo Corp. Esta empresa acabou de começar a usar a AWS, e a equipe de desenvolvimento de software ainda não definiu quais produtos da AWS serão usados. Paulo deseja dar à equipe permissão para acessar apenas os serviços de que precisam, mas como ainda não está definida, ele dá temporariamente a eles permissões de superusuário. Depois, ele usa as informações acessadas por último para reduzir as permissões do grupo.

Paulo cria uma política gerenciada chamada ExampleDevelopment usando o texto JSON a seguir. Em seguida, ele o anexa a um grupo chamado Development e adiciona todos os desenvolvedores ao grupo.

nota

Os usuários avançados do Paulo podem precisar de iam:CreateServiceLinkedRole permissões para usar alguns serviços e recursos. Ele entende que a adição dessa permissão permite que os usuários criem qualquer função vinculada a serviços. Ele aceita esse risco para seus usuários avançados.

{

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToAllServicesExceptPeopleManagement",
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Paulo opta por aguardar 90 dias até visualizar as informações acessadas por último para o grupo Development usando o AWS Management Console. Ele exibe a lista de serviços que os membros do grupo acessaram. Ele aprende que os usuários acessaram cinco serviços na última semana: AWS CloudTrail, Amazon CloudWatch Logs, Amazon EC2, AWS KMS e Amazon S3. Eles acessaram alguns outros serviços quando estavam avaliando inicialmente a AWS, mas não desde então.

Paulo decide reduzir as permissões de política para incluir apenas os cinco serviços e as ações necessárias do IAM e do Organizations. Ele edita a política ExampleDevelopment usando o texto JSON a seguir.

nota

Os usuários avançados do Paulo podem precisar de iam:CreateServiceLinkedRole permissões para usar alguns serviços e recursos. Ele entende que a adição dessa permissão permite que os usuários criem qualquer função vinculada a serviços. Ele aceita esse risco para seus usuários avançados.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessToListedServices",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "kms:*",
                "cloudtrail:*",
                "logs:*",
                "ec2:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RequiredIamAndOrgsActions",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Para reduzir ainda mais as permissões, Paulo pode exibir os eventos da conta no Event history (Histórico de eventos) da AWS CloudTrail. Lá ele pode exibir informações detalhadas que pode usar para reduzir as permissões da política a fim de incluir apenas as ações e os recursos de que os desenvolvedores precisam. Para obter mais informações, consulte Visualizar eventos do CloudTrail no console do CloudTrail no Guia do usuário do AWS CloudTrail.

Uso de informações para reduzir permissões para um usuário do IAM

Você pode usar informações do último acesso para reduzir as permissões de um usuário do IAM individual.

Por exemplo, Martha Rivera é a administradora de TI responsável por garantir que as pessoas na organização não tenham permissões da AWS em excesso. Como parte de uma verificação de segurança periódica, ela revisa as permissões de todos os usuários do IAM. Um desses usuários é um desenvolvedor de aplicativos chamado Nikhil Jayashankar que, anteriormente, assumiu a função de um engenheiro de segurança. Por causa da alteração feita em requisitos de trabalho, Nikhil é membro dos grupos app-dev e security-team. O grupo app-dev de seu novo trabalho concede permissões para vários serviços, incluindo Amazon EC2, Amazon EBS, Auto Scaling, Amazon S3, Route 53 e Elastic Transcoder. O grupo security-team de seu trabalho anterior concede permissões ao IAM e ao CloudTrail.

Como administradora, Martha inicia uma sessão no console do IAM e escolhe Usuários, o nome nikhilj e depois a guia Acessados recentemente.

Martha revisa a coluna Acessados recentemente e nota que Nikhil não acessou recentemente o IAM, o CloudTrail, o Route 53, o Amazon Elastic Transcoder e vários outros serviços da AWS. Nikhil acessou o Amazon S3. Martha escolhe S3 na lista de serviços e vê que Nikhil realizou algumas ações List do Amazon S3 nas últimas duas semanas. Dentro da empresa, Martha confirma que Nikhil não precisa mais acessar o IAM e o CloudTrail, porque ele não é mais membro da equipe de segurança interna.

Martha agora está pronta para agir sobre as informações de serviço e ação acessadas por último. No entanto, diferentemente do grupo no exemplo anterior, um usuário do IAM como nikhilj pode estar sujeito a várias políticas e ser membro de vários grupos. Martha deve prosseguir com cuidado para não interromper inadvertidamente o acesso para nikhilj ou outros membros do grupo. Além de aprender o acesso que Nikhil deve ter, ela deve determinar como ele está recebendo essas permissões.

Martha escolhe a guia Permissions (Permissões), em que ela exibe quais políticas estão anexadas diretamente a nikhilj e as anexadas de um grupo. Ela expande cada política e exibe o resumo da política para saber qual política dá acesso a serviços que Nikhil não está usando:

  • IAM: a política gerenciada pela AWS IAMFullAccess é anexada diretamente a nikhilj e anexada ao grupo security-team.

  • CloudTrail: a política gerenciada pela AWS AWSCloudTrailReadOnlyAccess é anexada ao grupo security-team.

  • Route 53: a política gerenciada pelo cliente App-Dev-Route53 é anexada ao grupo app-dev.

  • Elastic Transcoder: a política gerenciada pelo cliente App-Dev-ElasticTranscoder é anexada ao grupo app-dev.

Martha opta por remover a política gerenciada pela AWS IAMFullAccess anexada diretamente a nikhilj. Ela também remove a participação de Nikhil no grupo security-team. Essas duas ações removem o acesso desnecessário ao IAM e ao CloudTrail.

As permissões de Nikhil para acessar o Route 53 e o Elastic Transcoder são concedidas pelo grupo app-dev. Embora Nikhil não esteja usando esses serviços, outros membros do grupo podem estar. Martha analisa as informações do último acesso para o grupo app-dev e descobre que vários membros acessaram recentemente o Route 53 e o Amazon S3. Mas nenhum membro do grupo acessou o Elastic Transcoder no último ano. Ela remove a política gerenciada pelo cliente App-Dev-ElasticTranscoder do grupo.

Martha acaba revisando as informações acessadas por último para a política gerenciada pelo cliente App-Dev-ElasticTranscoder. Ela descobre que a política não está anexada a nenhuma outra identidade do IAM. Ela investiga dentro da empresa para garantir que a política não será necessária no futuro e, em seguida, ela a excluirá.

Uso das informações antes de excluir recursos do IAM

Você pode usar informações do último acesso antes de excluir um recurso do IAM para garantir que um determinado período tenha se passado desde a última vez em que alguém usou o recurso. Isso se aplica a usuários, grupos, funções e políticas. Para saber mais sobre essas ações, consulte os seguintes tópicos:

Uso de informações antes de editar políticas do IAM

Você pode revisar as informações do último acesso de uma identidade (usuário, grupo ou função) do IAM ou de uma política do IAM antes de editar uma política que afete esse recurso. Isso é importante porque você não deseja remover acesso para alguém que a esteja usando.

Por exemplo, Arnav Desai é desenvolvedor e administrador da AWS da Exemplo Corp. Quando sua equipe começou a usar a AWS, foi concedido a todos os desenvolvedores acesso de usuário avançado, o que permitiu a eles ter acesso total a todos os serviços, exceto o IAM e o Organizations. Como uma primeira etapa para conceder o menor privilégio, Arnav deseja usar a AWS CLI para revisar políticas gerenciadas na conta.

Para isso, Arnav primeiro lista as políticas de permissões gerenciadas pelo cliente na conta anexadas a uma identidade usando o seguinte comando:

aws iam list-policies --scope Local --only-attached --policy-usage-filter PermissionsPolicy

Na resposta, ele captura o ARN de cada política. Depois disso, Arnav gera um relatório de informações acessadas por último para cada política usando o comando a seguir.

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1

Nessa resposta, ele captura o ID do relatório gerado com base no campo JobId. Em seguida, Arnav sondará o comando a seguir até o campo JobStatus retornar um valor de COMPLETED ou FAILED. Se a tarefa falhar, ele vai capturar o erro.

aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9

Quando o trabalho tem um status COMPLETED, Arnav analisa o conteúdo da matriz ServicesLastAccessed formatada em JSON.

 "ServicesLastAccessed": [
        {
            "TotalAuthenticatedEntities": 1,
            "LastAuthenticated": 2018-11-01T21:24:33.222Z,
            "ServiceNamespace": "dynamodb",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/IAMExampleUser",
            "ServiceName": "Amazon DynamoDB"
        },

        {
            "TotalAuthenticatedEntities": 0,
            "ServiceNamespace": "ec2",
            "ServiceName": "Amazon EC2"
        },

        {
            "TotalAuthenticatedEntities": 3,
            "LastAuthenticated": 2018-08-25T15:29:51.156Z,
            "ServiceNamespace": "s3",
            "LastAuthenticatedEntity": "arn:aws:iam::123456789012:role/IAMExampleRole",
            "ServiceName": "Amazon S3"
        }
    ]

Com base nessas informações, Arnav descobre que a política ExamplePolicy1 permite acesso a três serviços, Amazon DynamoDB, Amazon S3 e Amazon EC2. O usuário do IAM chamado IAMExampleUser tentou acessar o DynamoDB pela última vez em 1.º de novembro e alguém usou a função IAMExampleRole para tentar acessar o Amazon S3 em 25 de agosto. Também existem mais duas entidades que tentaram acessar o Amazon S3 no último ano. No entanto, ninguém tentou acessar o Amazon EC2 no último ano.

Isso significa que o Arnav pode remover com segurança as ações do Amazon EC2 da política. Arnav deseja revisar o documento JSON atual da política. Primeiro, ele deve determinar o número da versão da política usando o comando a seguir.

aws iam list-policy-versions --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1

Na resposta, Arnav coleta o número da versão padrão atual da matriz Versions. Ele acaba usando esse número de versão (v2) para solicitar o documento de política JSON usando o comando a seguir.

aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --version-id v2

Arnav armazena o documento de política JSON retornado no campo Document da matriz PolicyVersion. No documento de política, Arnav procura ações com o namespace ec2. Se não houver ações de outros namespaces restantes na política, ele desanexará a política das identidades afetadas (usuários, grupos e funções). Depois disso, ele exclui a política. Nesse caso, a política inclui os serviços Amazon DynamoDB e Amazon S3. Portanto, Arnav remove as ações do Amazon EC2 do documento e salva suas alterações. Ele acaba usando o comando a seguir para atualizar a política usando a nova versão do documento e definir essa versão como a versão da política padrão.

aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --policy-document file://UpdatedPolicy.json --set-as-default

A política ExamplePolicy1 agora é atualizada para remover o acesso ao serviço do Amazon EC2 desnecessário.

Outros cenários do IAM

As informações sobre quando um recurso (usuário, grupo, função ou política) do IAM tentou acessar pela última vez um serviço podem ajudar quando você concluir qualquer uma das seguintes tarefas:

Usar informações para refinar permissões para uma unidade organizacional

Você pode usar informações acessadas por último para refinar as permissões para uma unidade organizacional (UO) no AWS Organizations.

Por exemplo, John Stiles é um administrador do AWS Organizations. Ele é responsável por garantir que as pessoas nas Contas da AWS da empresa não tenham permissões em excesso. Como parte de uma auditoria de segurança periódica, ele analisa as permissões da sua organização. A UO Development contém contas que são frequentemente usadas para testar novos serviços da AWS. John decide analisar periodicamente o relatório de serviços que não foram acessados em mais de 180 dias. Depois disso, ele remove as permissões de acesso dos membros da UO a esses serviços.

John faz login no console do IAM usando as credenciais de sua conta de gerenciamento. No console do IAM, ele localiza os dados do Organizations para a UO Development. Ele analisa a tabela Service access report (Relatório de acesso ao serviço) e vê dois serviços da AWS que não foram acessados em mais de 180 dias (o período preferencial). Ele lembra-se de adicionar permissões para que as equipes de desenvolvimento acessem o Amazon Lex e o AWS Database Migration Service. John entra em contato com as equipes de desenvolvimento e confirma que eles não têm mais a necessidade de testar esses serviços.

John agora está pronto para agir com base nas informações acessadas por último. Ele escolhe Edit in AWS Organizations (Editar no AWS Organizations) e lembra-se de que a SCP está anexada a várias entidades. Ele escolhe Continue (Continuar). No AWS Organizations, ele analisa os destinos para saber a quais entidades do Organizations a SCP está anexada. Todas as entidades estão na UO Development.

John decide negar acesso às ações do Amazon Lex e do AWS Database Migration Service na SCP NewServiceTest. Essa ação remove o acesso desnecessário aos serviços.