Acesso seguro à API com a MFA - AWS Identity and Access Management

Acesso seguro à API com a MFA

Com as políticas do IAM, você pode especificar quais operações de API um usuário tem permissão para chamar. Você pode adicionar mais segurança exigindo que os usuários se autentiquem com autenticação multifator (MFA) antes de permitir que eles executem ações particularmente confidenciais.

Por exemplo, você pode ter uma política que permita que um usuário execute as ações RunInstances, DescribeInstances e StopInstances do Amazon EC2. Mas você pode restringir uma ação destrutiva, tal como TerminateInstances e garantir que os usuários possam executar essa ação apenas se eles autenticarem com um dispositivo MFA da AWS.

Visão geral

A inclusão da proteção de MFA às operações de API envolve estas tarefas:

  1. O administrador configura um dispositivo MFA da AWS para cada usuário que precisa fazer solicitações de API que exigem autenticação de MFA. Para ter mais informações, consulte Código da autenticação multifator no IAM da AWS.

  2. O administrador cria políticas para os usuários que incluem um elemento Condition que verifica se o usuário autenticou com um dispositivo MFA da AWS.

  3. O usuário chama uma das operações de API do AWS STS que é compatível com os parâmetros de MFA: AssumeRole ou GetSessionToken. Como parte da chamada, o usuário inclui o identificador do dispositivo que está associado a ele. O usuário também inclui a time-based one-time password (TOTP – Senha de uso único baseada em tempo) que o dispositivo gera. Em qualquer um dos casos, o usuário recebe novamente credenciais de segurança temporárias que ele pode então usar para fazer solicitações adicionais para a AWS.

    nota

    A proteção de MFA para as operações de API de um serviço está disponível apenas se o serviço for compatível com credenciais de segurança temporárias. Para obter uma lista destes serviços, consulte Uso de credenciais de segurança temporárias para acessar a AWS.

Se a autorização falhar, a AWS retornará uma mensagem de erro "Acesso negado" (como para qualquer acesso não autorizado). Com políticas de API protegidas pela MFA em vigor, a AWS nega o acesso às operações de API especificadas nas políticas se o usuário tentar chamar uma operação da API sem uma autenticação MFA válida. A operação também é negada se o time stamp da solicitação para a operação de API estiver fora do intervalo permitido especificado na política. O usuário deve ser reautenticado com MFA através da solicitação de novas credenciais de segurança temporárias com um código de MFA e número de série do dispositivo.

Políticas do IAM com condições de MFA

Políticas com condições de MFA podem ser anexadas a:

  • Um usuário ou grupo do IAM

  • Um recurso como um bucket do Amazon S3, uma fila do Amazon SQS ou um tópico do Amazon SNS

  • A política de confiança de uma função do IAM que pode ser assumida por um usuário

Você pode usar uma condição de MFA em uma política para verificar as seguintes propriedades:

  • Existência: para verificar se o usuário fez a autenticação com MFA, verifique se a chave aws:MultiFactorAuthPresent é True em uma condição Bool. A chave só está presente quando o usuário realiza a autenticação com credenciais de curto prazo. As credenciais de longo prazo, como as chaves de acesso, não incluem essa chave.

  • Duração: se você deseja conceder acesso apenas em um período especificado após a autenticação com MFA, use um tipo de condição numérica para comparar o tempo da chave aws:MultiFactorAuthAge com um valor (por exemplo, 3.600 segundos). Observe que a chave aws:MultiFactorAuthAge não estará presente se a MFA não tiver sido usada.

O exemplo a seguir mostra a política de confiança de uma função do IAM que inclui uma condição de MFA para testar a existência de autenticação MFA. Com essa política, os usuários da Conta da AWS especificada no elemento Principal (substituir ACCOUNT-B-ID por um ID de Conta da AWS válido) podem assumir a perfil à que essa política está anexada. No entanto, esses usuários só podem assumir a função se eles forem autenticados usando a MFA.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "ACCOUNT-B-ID"}, "Action": "sts:AssumeRole", "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } }

Para obter mais informações sobre os tipos de condições para MFA, consulte Chaves de contexto de condição globais da AWS, Operadores de condição numéricos e Operador de condição para verificar a existência de chaves de condição .

Escolher entre GetSessionToken e AssumeRole

O AWS STS fornece duas operações de API que permitem que os usuários passem informações de MFA: GetSessionToken e AssumeRole. A operação de API que o usuário chama para obter credenciais de segurança temporárias depende de qual dos seguintes cenários se aplica.

Use GetSessionToken nos seguintes cenários:

  • Chame as operações de API que acessam recursos na mesma Conta da AWS que o usuário do IAM efetua a solicitação. Observe que credenciais temporárias de uma solicitação GetSessionToken poderão acessar operações de API do AWS STS e do IAM apenas se você incluir informações de MFA na solicitação de credenciais. Como credenciais temporárias retornadas por GetSessionToken incluem informações de MFA, você pode verificar a existência de MFA em operações de API individuais feitas pelas credenciais.

  • Acesso aos recursos protegidos com políticas baseadas em recursos que incluem uma condição de MFA.

O objetivo da operação GetSessionToken é autenticar o usuário que usa a MFA. Não é possível usar políticas para controlar as operações de autenticação.

Use AssumeRole nos seguintes cenários:

  • Chame as operações de API que acessam recursos na mesma ou em outra Conta da AWS. As chamadas de API podem incluir qualquer API do AWS STS ou do IAM. Observe que para proteger o acesso, você impõe a MFA no momento em que o usuário assume a função. As credenciais temporárias retornadas por AssumeRole não incluem informações de MFA no contexto, portanto não é possível verificar a existência de operações de API individuais quanto à MFA. É por isso que você deve usar GetSessionToken para restringir o acesso a recursos protegidos por políticas baseadas em recursos.

Detalhes sobre como implementar esses cenários são fornecidos posteriormente neste documento.

Pontos importantes sobre acesso à API protegido por MFA

É importante compreender os seguintes aspectos da proteção por MFA das operações de API:

  • A proteção por MFA está disponível apenas com credenciais de segurança temporárias, que devem ser obtidas com AssumeRole ou GetSessionToken.

  • Você não pode usar o acesso à API protegido por MFA com credenciais de Usuário raiz da conta da AWS.

  • Você não pode usar o acesso à API protegido por MFA com chaves de segurança U2F.

  • Usuários federados não podem ser atribuídos a um dispositivo com MFA para uso com os serviços da AWS, portanto eles não podem acessar os recursos da AWS controlados por MFA. (Consulte o próximo ponto.)

  • Outras operações de API do AWS STS que retornam credenciais temporárias não são compatíveis com MFA. Para AssumeRoleWithWebIdentity e AssumeRoleWithSAML, o usuário é autenticado por um provedor externo e a AWS não pode determinar se aquele provedor exigiu MFA. Para GetFederationToken, a MFA não é necessariamente associada a um usuário específico.

  • Da mesma forma, credenciais de longo prazo (chaves de acesso de usuário do IAM e chaves de acesso do usuário raiz) não podem ser usadas com o acesso à API protegido por MFA, pois elas não expiram.

  • AssumeRole e GetSessionToken também podem ser chamados sem informações de MFA. Neste caso, o chamador recebe as credenciais de segurança temporárias, mas as informações da sessão para essas credenciais temporárias não indicam que o usuário realizou autenticação com MFA.

  • Para estabelecer a proteção por MFA para operações de API, inclua condições de MFA nas políticas. Uma política deve incluir a chave de condição aws:MultiFactorAuthPresent para impor o uso de MFA. Para delegação entre contas, a política de confiança da função deve incluir a chave de condição.

  • Ao permitir que outra Conta da AWS acesse recursos em sua conta, a segurança dos seus recursos dependerá da configuração da conta confiável (a outra conta, não a sua). Isso ocorre mesmo quando você exige a autenticação multifator. Qualquer identidade na conta confiável que tenha permissão para criar dispositivos MFA virtuais pode construir uma solicitação de MFA para atender esta parte de sua política de confiança da função. Antes de permitir que membros de outra conta acessem seus recursos da AWS que exigem autenticação multifator, você deve garantir que o proprietário da conta confiável siga as melhores práticas de segurança. Por exemplo, a conta confiável deve restringir o acesso a operações de API confidenciais, como operações de API de gerenciamento de dispositivos MFA, a identidades confiáveis e específicas.

  • Se uma política inclui uma condição de MFA, uma solicitação é negada se os usuários não tiverem realizado autenticação por MFA ou se eles fornecerem um identificador de dispositivo MFA inválido ou TOTP inválida.

Cenário: Proteção por MFA para delegação entre contas

Nesse cenário, você deseja delegar acesso a usuários do IAM em outra conta, mas apenas se os usuários forem autenticados com um dispositivo com MFA da AWS. (Para obter mais informações sobre delegação entre contas, consulte Termos e conceitos das funções.

Imagine que você tenha a conta A (a conta de confiança que possui o recurso a ser acessado) com a usuária do IAM Anaya, que possui permissão de administrador. Ela quer conceder acesso ao usuário Richard na conta B (a conta confiável), mas quer ter certeza de que Richard é autenticado por MFA antes de assumir a função.

  1. Na conta de confiança A, Anaya cria uma função do IAM chamada CrossAccountRole e define a entidade de segurança na política de confiança da função para o ID de conta da conta B. A política de confiança concede permissão para a ação AssumeRole do AWS STS. Anaya também adiciona uma condição de MFA à política de confiança, como no exemplo a seguir.

    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "ACCOUNT-B-ID"}, "Action": "sts:AssumeRole", "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } }
  2. Anaya adiciona uma política de permissões à função que especifica o que a função tem permissão para fazer. A política de permissões para uma função com proteção por MFA não é diferente de qualquer outra política de permissões para funções. O exemplo a seguir mostra a política que Anaya adiciona à função; ela permite que um usuário que a esteja assumindo execute qualquer ação do Amazon DynamoDB na tabela Books na conta A. Essa política também permite a ação dynamodb:ListTables, que é necessária para executar ações no console.

    nota

    A política de permissões não inclui uma condição de MFA. É importante compreender que a autenticação por MFA é usada apenas para determinar se um usuário pode assumir a função. Assim que o usuário assume a função, nenhuma outra verificação de MFA é realizada.

    { "Version": "2012-10-17", "Statement": [ { "Sid": "TableActions", "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:*:ACCOUNT-A-ID:table/Books" }, { "Sid": "ListTables", "Effect": "Allow", "Action": "dynamodb:ListTables", "Resource": "*" } ] }
  3. Na conta confiável B, o administrador se certifica de que o usuário do IAM, Richard, esteja configurado com um dispositivo com MFA da AWS e de que ele saiba o ID do dispositivo. O ID do dispositivo será o número de série, se ele for um dispositivo MFA de hardware, ou o ARN do dispositivo, se ele for um dispositivo MFA virtual.

  4. Na conta B, o administrador anexa a seguinte política ao usuário Richard (ou a um grupo do qual ele seja membro) que permite que ele invoque a ação AssumeRole. O recurso é definido como o ARN da função que Anaya criou na etapa 1. Observe que esta política não contém uma condição de MFA.

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["sts:AssumeRole"], "Resource": ["arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole"] }] }
  5. Na conta B, Richard (ou um aplicativo que Richard está executando) chama AssumeRole. A chamada de API inclui o ARN da função a assumir (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), o ID do dispositivo MFA e a TOTP atual que Richard recebe de seu dispositivo.

    Quando Richard chama AssumeRole, a AWS determina se ele tem credenciais válidas, incluindo a exigência de MFA. Dessa forma, Richard assume a função com êxito e pode executar qualquer ação do DynamoDB na tabela chamada Books na conta A usando as credenciais temporárias da função.

    Para obter um exemplo de um programa que executa chamadas AssumeRole, consulte Chamar AssumeRole com autenticação MFA (Python).

Cenário: Proteção por MFA para acesso às operações da API na conta atual

Nesse cenário, você deve se certificar que um usuário na sua Conta da AWS pode acessar operações de API confidenciais apenas se ele for autenticado usando um dispositivo de MFA da AWS.

Imagine que você tem a conta A que contém um grupo de desenvolvedores que precisa trabalhar com instâncias do EC2. Desenvolvedores comuns podem trabalhar com as instâncias, mas não recebem permissões para as ações ec2:StopInstances ou ec2:TerminateInstances. Você deseja limitar essas ações privilegiadas “destrutivas” a apenas alguns usuários confiáveis, portanto você adiciona proteção por MFA à política que permite essas ações importantes do Amazon EC2.

Nesse cenário, um desses usuários confiáveis é o usuário Sofía. O usuário Anaya é um administrador na conta A.

  1. Anaya se certifica de que Sofía esteja configurada com um dispositivo com MFA da AWS e de que ela saiba o ID do dispositivo. O ID do dispositivo será o número de série, se ele for um dispositivo MFA de hardware, ou o ARN do dispositivo, se ele for um dispositivo MFA virtual.

  2. Anaya cria um grupo chamado EC2-Admins e adiciona o usuário Sofía ao grupo.

  3. Anaya anexa a seguinte política ao grupo EC2-Admins. Essa política concede aos usuários permissão para chamar as ações StopInstances e TerminateInstances do Amazon EC2 apenas se o usuário tiver se autenticado usando a MFA.

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "ec2:StopInstances", "ec2:TerminateInstances" ], "Resource": ["*"], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} }] }
  4. nota

    Para essa política entrar em vigor, os usuários devem primeiro sair e depois fazer login novamente.

    Se a usuária Sofía precisar interromper ou encerrar uma instância do Amazon EC2, ela (ou uma aplicação que ela esteja executando) chamará GetSessionToken. Essa operação de API transmite o ID do dispositivo MFA e a TOTP atual que Sofía recebeu de seu dispositivo.

  5. A usuária Sofía (ou uma aplicação que Sofía esteja usando) usa as credenciais temporárias fornecidas por GetSessionToken para chamar a ação StopInstances ou TerminateInstances do Amazon EC2.

    Para obter um exemplo de um programa que executa chamadas GetSessionToken, consulte Chamar GetSessionToken com autenticação MFA adiante neste documento.

Cenário: Proteção por MFA para recursos que têm políticas baseadas em recurso

Nesse cenário, você é o proprietário de um bucket do S3, de uma fila do SQS ou de um tópico do SNS. Você deseja ter certeza de que qualquer usuário de qualquer Conta da AWS que acessa o recurso seja autenticado por um dispositivo de MFA da AWS.

Este cenário ilustra uma maneira de fornecer proteção por MFA entre contas sem a exigência de que os usuários assumam uma função primeiro. Neste caso, o usuário pode acessar o recurso se atender a três condições: estar autenticado por MFA, ser capaz de obter credenciais de segurança temporárias do GetSessionToken, e ter uma conta de confiança da política do recurso.

Imagine que você está na conta A e cria um bucket do S3. Você deseja conceder acesso a este bucket para os usuários em várias Contas da AWS diferentes, mas somente se esses usuários forem autenticados com MFA.

Nesse cenário, o usuário Anaya é um administrador na conta A. O usuário Nikhil é um usuário do IAM na conta C.

  1. Na conta A, Anaya cria um bucket chamado Account-A-bucket.

  2. Anaya adiciona a política de bucket ao bucket. A política permite que qualquer usuário na conta A, B ou C execute as ações PutObject e DeleteObject do Amazon S3 no bucket. A política inclui uma condição de MFA.

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"AWS": [ "ACCOUNT-A-ID", "ACCOUNT-B-ID", "ACCOUNT-C-ID" ]}, "Action": [ "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} }] }
    nota

    O Amazon S3 oferece um recurso de exclusão de MFA para acesso à conta raiz (apenas). Você pode habilitar a exclusão de MFA do Amazon S3 ao definir o estado de versionamento do bucket. A exclusão de MFA do Amazon S3 não pode ser aplicada a um usuário do IAM e é gerenciada independentemente do acesso à API protegido por MFA. Um usuário do IAM com permissões para excluir um bucket não pode excluir um bucket com a exclusão de MFA do Amazon S3 habilitada. Para obter mais informações sobre a exclusão de MFA do Amazon S3, consulte Exclusão de MFA.

  3. Na conta C, um administrador se certifica de que o usuário Nikhil esteja configurado com um dispositivo com MFA da AWS e que ele saiba o ID do dispositivo. O ID do dispositivo será o número de série, se ele for um dispositivo MFA de hardware, ou o ARN do dispositivo, se ele for um dispositivo MFA virtual.

  4. Na conta C, Nikhil (ou um aplicativo que ele está executando) chama GetSessionToken. A chamada inclui o ID ou ARN do dispositivo de MFA e a TOTP atual que Nikhil recebe de seu dispositivo.

  5. Nikhil (ou uma aplicação que ele esteja usando) usa as credenciais temporárias retornadas por GetSessionToken para chamar a ação PutObject do Amazon S3 para carregar um arquivo para Account-A-bucket.

    Para obter um exemplo de um programa que executa chamadas GetSessionToken, consulte Chamar GetSessionToken com autenticação MFA adiante neste documento.

    nota

    As credenciais temporárias que AssumeRole retorna não funcionam neste caso. Embora o usuário possa fornecer informações de MFA para assumir uma função, as credenciais temporárias retornadas por AssumeRole não incluem as informações de MFA. Essas informações são necessárias para atender à condição de MFA na política.