Blog de Amazon Web Services (AWS)

¿Cómo proteger el acceso entre cuentas usando MFA?

Por Shon Shah

 

En AWS usted puede añadir autenticación multifactorial (MFA) para acceso entre cuentas. En este blog post, mostraremos un caso de uso común, incluido un ejemplo de código, en el que se muestra cómo crear políticas que impongan MFA cuando usuarios de IAM de una cuenta de AWS realizan solicitudes programáticas a recursos en otra cuenta diferente.

Muchos de ustedes poseen y administran varias cuentas de AWS, por lo que con frecuencia se preguntan cómo simplificar la administración del acceso entre esas cuentas. Los roles de IAM proporcionan un mecanismo seguro y controlable para permitir el acceso entre cuentas. Los roles permiten el acceso entre cuentas sin compartir credenciales y sin necesidad de crear usuarios de IAM duplicados. Es posible, añadir otro nivel de protección para el acceso entre cuentas, exigiendo que los usuarios se autentiquen mediante un dispositivo MFA antes de asumir un rol .

Imagine que su empresa mantiene varias cuentas de AWS: de desarrollo, de pre-producción y de producción. Supongamos que desea centralizar la administración del acceso de todas estas cuentas “secundarias” mediante una única cuenta “principal” que contenga sus usuarios de IAM.

Veamos cómo configuraría esta relación principal-secundaria desde la perspectiva del control de acceso. El objetivo es permitir a los usuarios de IAM de la cuenta principal realizar acciones privilegiadas, como Amazon EC2 TerminateInstances y Amazon DynamoDB DeleteTable en las cuentas secundarias, pero solo si se han autenticado mediante MFA.

Hay tres pasos necesarios: establecer una relación de confianza entre las cuentas, configurar dispositivos de MFA para usuarios y realizar acciones privilegiadas. Vamos a profundizar en los detalles de cada una de ellas:

 

1. Establecer relación de confianza entre las cuentas

En este paso, las cuentas secundarias se convierten en cuentas “confiadas” y la cuenta principal se convierte en la cuenta de “confianza”.

Empecemos por la cuenta de Desarrollo. Se configurará para que confíe en la cuenta principal creando un rol, por ejemplo, PrivilegedActionsRole, rol para ejecutar acciones privilegiadas, y especificando la cuenta principal como la cuenta principal de confianza. A continuación, se configura el rol para que requiera MFA. Puede completar estos pasos mediante la consola de administración de AWS. Cambie a la consola de IAM, acceda al entorno de roles y a continuación, haga clic en Crear Rol, en Tipo de entidad de confianza seleccione Cuenta de AWS, luego, en Una cuenta de AWS, seleccione Otra cuenta de AWS e introduzca el ID de la cuenta principal, finalmente marque la casilla Requerir MFA , como se muestra en la siguiente figura.

Entre bastidores, el rol se configura con una política de confianza de roles que, en efecto, dice: “Confío en que los usuarios de IAM de la cuenta principal asumirán esa función, siempre y cuando el usuario esté autenticado mediante MFA”. La política de confianza de roles creada por el asistente se muestra a continuación.

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

Tenga en cuenta que el principal es definido con el ID de la cuenta principal y que la condición especifica la clave aws:MultiFactorAuthPresent. La condición comprueba si aws:MultiFactorAuthPresent es verdadero para validar que el usuario se autenticó con MFA la primera vez que inició sesión en la consola de administración de AWS o que proporcionó información de autenticación de MFA al llamar a la API AssumeRole desde la CLI de AWS o al utilizar alguno de los SDK de AWS. Si alguno de estos dos escenarios no se aplica, el usuario no podrá asumir el rol.

Es importante tener en cuenta que la condición de MFA solo se puede especificar en la política de confianza del rol (y no en la política de acceso al rol que se describe a continuación). Esta controla si el MFA es necesario o no para asumir la función.

El siguiente paso del asistente asigna una política de acceso al rol que determina los permisos otorgados al usuario que asume el rol correctamente. Continuando con nuestro ejemplo, la siguiente política otorga permiso para llamar a Amazon EC2 TerminateInstances y Amazon DynamoDB DeleteTable.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Action":["ec2:TerminateInstances","dynamodb:DeleteTable"],
      "Effect":"Allow",
      "Resource":"*"
    }
  ]
}

Repita estos pasos para las cuentas de pre-producción y producción.

Ahora pasemos a configurar la cuenta principal. Debe conceder permiso a los usuarios para que asuman las funciones creadas en las cuentas secundarias respectivas. Para ello, adjunte una política de usuario o grupo que conceda la acción AssumeRole y defina el recurso como el ARN (nombre del recurso de Amazon) de las funciones que creó en sus cuentas secundarias.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
       "arn:aws:iam::Development-Account-ID:role/PrivilegedActionsRole",
       "arn:aws:iam::Staging-Account-ID:role/PrivilegedActionsRole",
       "arn:aws:iam::Production-Account-ID:role/PrivilegedActionsRole",
     ]
    }
  ]
}

2. Configurar dispositivos MFA para los usuarios

En este paso, configurará los dispositivos de MFA para los usuarios de IAM en la cuenta principal, de modo que los usuarios puedan asumir los roles que creó en las cuentas secundarias. Puede configurar un hardware o dispositivo de MFA virtual mediante la consola de administración de AWS siguiendo los pasos que se describen en la documentación de IAM.

3. Realizar acciones privilegiadas

Con la configuración descrita anteriormente, los usuarios de la cuenta principal ahora pueden realizar acciones con los recursos de las cuentas secundarias. La siguiente figura muestra los tres pasos necesarios cuando los usuarios de la cuenta principal desean asumir el rol protegido con MFA para realizar acciones en los recursos de las cuentas secundarias. Estos pasos se pueden realizar mediante los SDK de AWS o usando la CLI de AWS.

 

 

Paso 1:  Autenticar usando el ID de la clave de acceso y la clave de acceso secreta.

Paso 2: Obtenga un código (Clave única basada en tiempo o TOTP) del dispositivo MFA. Pase el ID y el código del dispositivo MFA a la solicitud AssumeRole . Estos son los nuevos parámetros serialNumber y tokenCode. Estos parámetros se suman a los parámetros necesarios para que asuma el ARN del rol y un nombre de sesión. Si tiene éxito, obtenga sus credenciales de seguridad temporales.

Paso 3:  Use las credenciales de seguridad temporales para realizar acciones privilegiadas en la cuenta secundaria.

Ahora que hemos analizado toda la configuración, veamos un ejemplo de código. El siguiente programa de ejemplo, escrito usando el AWS SDK para Python (Boto), muestra cómo usted puede asumir un rol protegido por MFA pasando los parámetros de MFA a AssumeRole.  El código de ejemplo usa las credenciales de seguridad temporales de la respuesta AssumeRole para terminar una instancia en la cuenta confiada.

import boto
from boto.sts import STSConnection
from boto.ec2 import EC2Connection

# Role from the trusting account to assume
role_arn = "arn:aws:iam::ACCOUNT-NUMBER-WITHOUT-HYPHENS:role/ROLE-TO-ASSUME"
# String to identify the role session
role_session_name = "AssumeRoleSessionWithMFA"

# MFA device ID (serial number for hardware device or ARN for virtual device)
mfa_serial_number = "arn:aws:iam::ACCOUNT-NUMBER-WITHOUT-HYPHENS:mfa/MFA-DEVICE-ID"

# The calls to AssumeRole must be signed using the access key ID and
# secret access key of an IAM user. The IAM user credentials can be 
# in environment variables or in a configuration file and will be 
# discovered automatically by the STSConnection() function. For more 
# information, see the Python SDK documentation:
# http://boto.readthedocs.org/en/latest/boto_config_tut.html
print "nConnecting to Security Token Service..."
sts_connection = STSConnection()
print "Connection successful."

# Assume the role
print "nAssuming role", role_arn, "using MFA device", mfa_serial_number, "..."
# Prompt for MFA one-time-password
mfa_token = raw_input("Enter the MFA code: ")
role_session = sts_connection.assume_role(
    role_arn=role_arn,
    role_session_name=role_session_name,
    mfa_serial_number=mfa_serial_number,
    mfa_token=mfa_token
)
print "Assumed the role successfully."

# Use the role-provided temporary security credentials to connect to EC2
print "nConnecting to Elastic Compute Cloud service..."
ec2_connection = EC2Connection(
    aws_access_key_id=role_session.credentials.access_key,
    aws_secret_access_key=role_session.credentials.secret_key,
    security_token=role_session.credentials.session_token
)
print "Connection successful."

# Terminate instance
print "nTerminating EC2 instance..."
instance_id = raw_input("Enter id of the instance to teminate: ")
response = ec2_connection.terminate_instances(instance_id)
print response
print "Done."

Este es el resultado de un ejemplo de ejecución:

 

Screenshot showing the output from a sample run

 

En resumen, las funciones de IAM proporcionan un mecanismo seguro y controlable para simplificar la administración del acceso entre cuentas. Puede añadir otro nivel de protección forzando el uso de MFA para el acceso cruzado entre cuentas.  Para obtener información adicional sobre esta función, visite la sección Configuración del acceso a una API protegido por MFA en la Guía del usuario para IAM.

 

Este artículo fue traducido del Blog de AWS en Inglés.


Acerca del autor

Shon Shah

 

 

 

 

Revisores

Carolina Carneiro trabaja como Technical Trainer en AWS. Imparte capacitación en seguridad, Machine Learning, Arquitectura, Operación de Sistemas, entre otros.  Comenzó su viaje a la nube de AWS en 2020 formando parte del programa Tech U, un programa de formación en la nube de AWS.  Después de Tech U, comenzó su aventura en el equipo de Training and Certification LATAM, donde tuvo la oportunidad de profundizar en temas como Seguridad y Machine Learning.  En la actualidad, busca enseñar AWS de una manera accesible y participativa.

 

 

 

 

Ricardo Makino es actualmente arquitecto de soluciones en AWS ayudando a clientes gubernamentales en su viaje a la nube. Cuenta con más de 20 años de experiencia en TI, donde ha trabajado en el sector gubernamental, educativo y de investigación como administrador de redes y sistemas, analista de seguridad de la información, investigador de seguridad de la información y especialista en la nube, ha participado en diversos proyectos relacionados con tecnologías de orquestación de infraestructuras y plataformas, optimización de aplicaciones, migraciones, seguridad de redes y aplicaciones, entre otros.

 

 

 

 

Adrian Diaz se desempeña actualmente como Technical Account Manager, en su rol apoya a los clientes de Enterprise Support en su viaje a la nube de AWS, asegurando que sus entornos funcionen alineados con las mejores practicas en cuanto a rendimiento, seguridad, resiliencia, excelencia operativa y optimización de costos. Cuenta con más de 15 años de experiencia en TI, habiéndose desempeñado como administrador de sistemas e ingeniero de infraestructura, en donde ha participado de proyectos de networking, telefonía IP, virtualización, migración de centro de cómputos, entre otros.