Configuración del acceso a una API protegido por MFA

Con las políticas de IAM, puede especificar qué operaciones de API puede llamar un usuario. En algunos casos, es posible que quiera añadir más seguridad y exigir a los usuarios que se autentiquen mediante la autenticación multifactor (MFA) de AWS para permitirles llevar a cabo acciones especialmente confidenciales.

Por ejemplo, es posible que tenga una política que permita a un usuario realizar las acciones de Amazon EC2 RunInstances, DescribeInstances y de StopInstances. Sin embargo, es posible que quiera restringir una acción destructiva, como TerminateInstances y asegurarse de que los usuarios solo pueden realizar esta acción si se autentican mediante un dispositivo MFA de AWS.

Información general

Para agregar la protección de MFA a las operaciones de API es preciso realizar estas tareas:

1. El administrador configura un dispositivo de MFA de AWS para cada usuario que necesite realizar solicitudes de API que requieran una autenticación MFA. Este proceso se describe en Habilitación de dispositivos MFA para usuarios en AWS.

2. El administrador crea políticas para los usuarios que contienen un elemento Condition que comprueba si el usuario se ha autenticado con un dispositivo MFA de AWS.

3. El usuario llama a una de las operaciones de la API de AWS STS que admiten los parámetros de MFA AssumeRole o GetSessionToken, según la situación de la protección de MFA, tal y como se explica más adelante. Dentro de la llamada, el usuario incluye el identificador del dispositivo que está asociado al usuario. El usuario también incluye la contraseña de un solo uso basada en el tiempo (TOTP) que el dispositivo genera. En cualquier caso, el usuario obtiene credenciales de seguridad temporales que puede utilizar para realizar solicitudes adicionales a AWS.

   nota

   La protección de MFA para las operaciones de API de un servicio solo está disponible si el servicio es compatible con las credenciales de seguridad temporales. Para obtener una lista de estos servicios, consulte Uso de credenciales de seguridad temporales para acceder a AWS.

Si se produce un error en la autorización, AWS devuelve un mensaje de error de acceso denegado (al igual que con cualquier otro acceso no autorizado). Con las políticas de API protegidas mediante MFA, AWS deniega el acceso a las operaciones de API especificadas en las políticas si el usuario intenta llamar a una operación de API sin una autenticación MFA válida. La operación también se deniega si la marca temporal de la solicitud de la operación API no entra en el rango especificado en la política. Debe volver a autenticarse al usuario en MFA solicitando nuevas credenciales de seguridad temporales con un código de MFA y el número de serie del dispositivo.

Políticas de IAM con condiciones de MFA

Las políticas con condiciones de MFA se pueden asociar a los elementos siguientes:

• Un usuario o grupo de IAM

• Un recurso, como un bucket de Amazon S3, una cola de Amazon SQS o un tema de Amazon SNS

• La política de confianza de un rol de IAM que un usuario puede asumir

Puede utilizar una condición de MFA de una política para comprobar las propiedades siguientes:

• Existencia: para simplemente verificar que el usuario se autenticó realmente con MFA, compruebe que la clave aws:MultiFactorAuthPresent sea True en una condición Bool. La clave solo está presente cuando el usuario se autentica con credenciales a corto plazo. Las credenciales a largo plazo, como, por ejemplo, las claves de acceso, no contienen esta clave.

• Duración: si quiere conceder acceso únicamente dentro de un periodo determinado de tiempo después de la autenticación MFA, utilice un tipo de condición numérica para comparar la edad de la clave aws:MultiFactorAuthAge con un valor (por ejemplo, 3600 segundos). Tenga en cuenta que la clave aws:MultiFactorAuthAge no está presente si no se ha utilizado la MFA.

El siguiente ejemplo muestra la política de confianza de un rol de IAM que contiene una condición MFA para probar la existencia de la autenticación MFA. Con esta política, los usuarios de la cuenta de Cuenta de AWS especificada en el elemento Principal (sustituir ACCOUNT-B-ID por un ID de cuenta de Cuenta de AWS válido) pueden asumir la función a la que esta política está asociada. Sin embargo, tales usuarios solo puede asumir la función si el usuario está autenticado con MFA.

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

Para obtener más información sobre los tipos de condición para MFA, consulte Claves de contexto de condición globales de AWS, Operadores de condición numérica y Operador de condición para comprobar la existencia de claves de condición .

Elegir entre GetSessionToken y AssumeRole

AWS STS proporciona dos operaciones de la API que permiten a los usuarios transmitir información de MFA: GetSessionToken y AssumeRole. La operación de API a la que el usuario llama para obtener credenciales de seguridad temporales depende de la situación a la que la API se aplique.

Utilice GetSessionToken en las situaciones siguientes:

• Llamadas a operaciones de API que tienen acceso a los recursos en la misma cuenta de Cuenta de AWS que el usuario de IAM que realiza la solicitud. Tenga en cuenta que las credenciales temporales de una solicitud GetSessionToken pueden obtener acceso a IAM y a las operaciones de la API de AWS STS y solo si contienen información de MFA en la solicitud de credenciales. Dado que las credenciales temporales devueltas por GetSessionToken contienen información de MFA, puede buscar la presencia de MFA en llamadas a las operaciones de API realizadas por las credenciales.

• El acceso a recursos que están protegidos con políticas basadas en recursos que contienen una condición de MFA.

La finalidad de la operación GetSessionToken es autenticar al usuario mediante MFA. No se pueden utilizar políticas para controlar las operaciones de autenticación.

Utilice AssumeRole en las situaciones siguientes:

• Llamadas a operaciones de API que obtienen acceso a los recursos que están en la misma cuenta de Cuenta de AWS o en otra. Las llamadas a la API pueden incluir cualquier API de IAM o AWS STS. Tenga en cuenta que, para proteger el acceso, aplicar MFA en el momento en que el usuario asume el rol. Las credenciales temporales devueltas por AssumeRole no contienen información de MFA en el contexto, por lo que no puede buscar la presencia de MFA en operaciones de API individuales. Por ello debe utilizar GetSessionToken para restringir el acceso a los recursos protegidos por políticas basadas en recursos.

Más adelante, se proporciona información detallada sobre cómo implementar estas situaciones.

Información importante sobre el acceso mediante API protegido por MFA

Es importante comprender los siguientes aspectos de la protección de operaciones de API con MFA:

• La protección con MFA solo está disponible con credenciales de seguridad temporales, las cuales deben obtenerse con AssumeRole o GetSessionToken.

• No puede utilizar el acceso a API protegido por MFA con las credenciales de usuario Usuario raíz de la cuenta de AWS.

• No puede utilizar el acceso a API protegido por MFA con las llaves de seguridad U2F.

• A los usuarios federados no se les puede asignar un dispositivo MFA para utilizarlo con servicios de AWS, por lo que no pueden obtener acceso a recursos de AWS controlados por MFA. (véase el punto siguiente).

• Las demás operaciones de API de AWS STS que devuelven credenciales temporales no admiten MFA. En AssumeRoleWithWebIdentity y AssumeRoleWithSAML, un proveedor externo autentica al usuario y AWS no puede determinar si ese proveedor exige una MFA. En GetFederationToken, MFA no está obligatoriamente asociado a un usuario concreto.

• Del mismo modo, las credenciales a largo plazo (claves de acceso de usuario de IAM y claves de acceso de usuario raíz) no se pueden utilizar con el acceso mediante API protegido por MFA, ya que no caducan.

• También se puede llamar a AssumeRole y GetSessionToken sin información de MFA. En este caso, el intermediario obtiene credenciales de seguridad temporales, pero la información de la sesión para dichas credenciales temporales no indica si el usuario se autenticó con MFA.

• Para establecer una protección de MFA para las operaciones de API, agregue condiciones de MFA a las políticas. Una política debe incluir la clave de condición aws:MultiFactorAuthPresent para aplicar el uso de MFA. Para la delegación entre cuentas, la política de confianza de la función debe incluir la clave de condición.

• Cuando se permite que otra cuenta de Cuenta de AWS obtenga acceso a los recursos de su cuenta, la seguridad de los recursos dependerá de la configuración de la cuenta de confianza; es decir, de la otra cuenta (no de la suya). Esto es válido aunque se exija la autenticación multifactor. Cualquier identidad de la cuenta de confianza que tenga permiso para crear dispositivos MFA virtuales puede crear una notificación de MFA que respete la parte de la política de confianza de su rol. Antes de permitir que los miembros de otra cuenta obtengan acceso a sus recursos de AWS que requieren autenticación multifactor, debe asegurarse de que el propietario de la cuenta de confianza aplique las prácticas recomendadas de seguridad. Por ejemplo, la cuenta de confianza debe restringir exclusivamente a identidades concretas y de confianza el acceso a las operaciones de API confidenciales, tales como las operaciones de API de administración de dispositivos MFA.

• Si una política contiene una condición de MFA, se deniega una solicitud si los usuarios de esta no se han autenticado con MFA o si proporcionan un identificador de dispositivo MFA no válido o una TOTP no válida.

Situación: protección de MFA para la delegación entre cuentas

En este caso, quiere delegar el acceso de usuarios de IAM a otra cuenta, pero solo si dichos usuarios se autentican con un dispositivo MFA de AWS. Para obtener más información acerca de la delegación entre cuentas, consulte Términos y conceptos de roles.

Supongamos que tiene una cuenta A (la cuenta que confía y es propietaria del recurso al que debe accederse) con la usuaria de IAM Anaya, que tiene permiso de administrador. Alice quiere conceder acceso al usuario Richard de la cuenta B (la cuenta de confianza), pero antes quiere asegurarse de que Richard se autentica con MFA antes de asumir el rol.

1. En la cuenta que confía A, Anaya crea un rol de IAM denominado CrossAccountRole y establece la entidad principal de la política de confianza del rol en el ID de la cuenta B. La política de confianza concede permiso a la acción AWS STS AssumeRole. Anaya también añade una condición de MFA a la política de confianza, como la del siguiente ejemplo.

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

2. Anaya añade una política de permisos al rol que especifica lo que le permite hacer la función. La política de permisos de un rol con protección de MFA no es diferente de cualquier otra política de permisos de rol. En el siguiente ejemplo, se muestra la política que Anaya agrega al rol; permite al usuario que la asume realizar cualquier acción de Amazon DynamoDB en la tabla Books de la cuenta A. Esta política también permite la acción dynamodb:ListTables, que es necesaria para llevar a cabo acciones en la consola.

   nota

   La política de permisos no incluye una condición de MFA. Es importante comprender que la autenticación MFA solo se usa para determinar si un usuario puede asumir el rol. Una vez que el usuario haya asumido el rol, no se realizarán más verificaciones de MFA.

   {
       "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. En la cuenta de confianza B, el administrador se asegura de que el usuario de IAM Richard se haya configurado con un dispositivo MFA de AWS y de que conozca el ID del dispositivo. El ID de dispositivo es el número de serie si se trata de un dispositivo MFA físico, o bien el ARN si se trata de un dispositivo MFA virtual.

4. En la cuenta B, el administrador asocia la siguiente política al usuario Richard (o a un grupo del que sea miembro) que le permita llamar a la acción AssumeRole. El recurso se establece en el ARN del rol que Anaya creó en el paso 1. Observe que esta política no contiene una condición de MFA.

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Action": ["sts:AssumeRole"],
       "Resource": ["arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole"]
     }]
   }

5. En la cuenta B, Richard (o una aplicación que Richard esté ejecutando) llama a AssumeRole. La llamada a la API contiene el ARN del rol que se asumirá (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), el ID del dispositivo de MFA, y la TOTP actual que Richard obtiene de su dispositivo.

   Cuando Richard llama a AssumeRole, AWS determina si tiene credenciales válidas, incluido la exigencia de MFA. En caso afirmativo, Richard asume el rol efectivamente y puede realizar cualquier acción de DynamoDB de la tabla denominada Books de la cuenta A con las credenciales temporales del rol.

   Si desea ver un ejemplo de un programa que llame a AssumeRole, consulte Llamada a AssumeRole con autenticación MFA.

Situación: protección de MFA para el acceso a operaciones de API de la cuenta actual

En este caso, debe asegurarse de que un usuario de su cuenta de Cuenta de AWS pueda obtener acceso a operaciones de la API confidenciales solamente cuando el usuario se haya autenticado con un dispositivo MFA de AWS.

Supongamos que tiene una cuenta A que contiene un grupo de desarrolladores que necesitan trabajar con instancias EC2. Los desarrolladores normales pueden trabajar con las instancias, pero no se les conceden permisos para las acciones ec2:StopInstances o ec2:TerminateInstances. Usted quiere limitar estas acciones privilegiadas "destructivas" solo a unos cuantos usuarios de confianza, por lo que añade protección de MFA a la política que permite estas acciones de Amazon EC2 de gran importancia.

En este escenario, uno de los usuarios de confianza es Sofía. La usuaria Anaya es administradora de la cuenta A.

1. Anaya se asegura de que Sofía esté configurada con un dispositivo MFA de AWS y de que Sofía conozca el ID del dispositivo. El ID de dispositivo es el número de serie si se trata de un dispositivo MFA físico, o bien el ARN si se trata de un dispositivo MFA virtual.

2. Anaya crea un grupo denominado EC2-Admins y añade a la usuario Sofía al grupo.

3. Anaya asocia la siguiente política al grupo EC2-Admins. Esta política concede a los usuarios permiso para llamar a las acciones de Amazon EC2 StopInstances y TerminateInstances solo si el usuario se ha autenticado con MFA.

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

4. nota

   Para que esta política surta efecto, antes los usuarios deben cerrar la sesión e iniciarla de nuevo.

   Si el usuario Sofía tiene que detener o terminar una instancia de Amazon EC2, ella (o una aplicación que esté ejecutando) llamará a GetSessionToken. Esta operación de API transmite el ID del dispositivo MFA y la TOTP actual que Sofía obtiene de su dispositivo.

5. La usuaria Sofía (o una aplicación que Sofía esté usando) utiliza las credenciales temporales que ofrece GetSessionToken para llamar a la acción de Amazon EC2 StopInstances o la acción de TerminateInstances.

   Si desea ver un ejemplo de un programa que llame a GetSessionToken, consulte Llamada a GetSessionToken con autenticación MFA, más adelante en el documento.

Situación: protección de MFA para recursos que tienen políticas basadas en recursos

En este caso, es usted propietario de un bucket de S3, una cola de SQS o un tema de SNS. Quiere asegurarse de que todos los usuarios de todas las cuentas de Cuenta de AWS que tengan acceso al recurso se autentiquen mediante un dispositivo MFA de AWS.

Esta situación ilustra una forma de proporcionar una protección MFA entre cuentas en la que no se exija al usuario que asuma primero un rol. En este caso, el usuario puede obtener acceso al recursos si se cumplen tres condiciones. el usuario debe estar autenticado por MFA, debe poder obtener credenciales de seguridad temporales de GetSessionToken y debe pertenecer a una cuenta que sea de confianza para la política del recurso.

Supongamos que está en la cuenta A y que crea un bucket de S3. Quiere conceder acceso a este bucket a usuarios que están en varias cuentas de Cuentas de AWS, pero solo si dichos usuarios están autenticados con MFA.

En este escenario, la usuaria Anaya es administradora de la cuenta A. El usuario Nikhil es un usuario de IAM de la cuenta C.

1. En la cuenta A, Anaya crea un bucket denominado Account-A-bucket.

2. Anaya añade la política de bucket al bucket. La política permite a todos los usuarios de la cuenta A, la cuenta B o la cuenta C las acciones de Amazon S3 PutObject y de DeleteObject en el bucket. La política contiene una condición 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

   Amazon S3 tiene una función de eliminación de MFA para el acceso de cuenta raíz (solo). Puede habilitar la eliminación de MFA de Amazon S3 cuando establezca el estado de control de versiones del bucket. La eliminación de MFA de Amazon S3 no se puede aplicar a un usuario de IAM y se administra de forma independiente del acceso mediante API protegido por MFA. Un usuario de IAM con permisos para eliminar un bucket no puede eliminar un bucket si la eliminación de MFA de Amazon S3 está habilitada. Para obtener más información acerca de la eliminación de MFA de Amazon S3, consulte Eliminación de MFA.

3. En la cuenta de confianza C, un administrador se asegura de que el usuario Nikhil se haya configurado con un dispositivo MFA de AWS y de que conozca el ID del dispositivo. El ID de dispositivo es el número de serie si se trata de un dispositivo MFA físico, o bien el ARN si se trata de un dispositivo MFA virtual.

4. En la cuenta C, Nikhil (o una aplicación que esté ejecutando) llama a GetSessionToken. La llamada contiene el ID o el ARN del dispositivo de MFA y la TOTP actual que Nikhil obtiene de su dispositivo.

5. Nikhil (o una aplicación que esté utilizando) utiliza las credenciales temporales devueltas por GetSessionToken para llamar a la acción PutObject Amazon S3 para cargar un archivo en Account-A-bucket.

   Si desea ver un ejemplo de un programa que llame a GetSessionToken, consulte Llamada a GetSessionToken con autenticación MFA, más adelante en el documento.

   nota

   Las credenciales temporales que AssumeRole devuelve no funcionarán en este caso. Aunque el usuario puede proporcionar información de MFA para asumir un rol, las credenciales temporales devueltas por AssumeRole no contienen la información de MFA. Esa información se requiere para cumplir la condición de MFA de la política.