Protección de sus claves de acceso en AWS

Por Maria Ane Dias , Arquitecta de Soluciones Especialista en Seguridad en AWS y
Daniel Garcia, Especialista en Seguridad en AWS

En AWS, la seguridad es prioridad máxima. Tenemos un modelo de responsabilidad compartida con los clientes: AWS es responsable de proteger la infraestructura que ejecuta todos los servicios ofrecidos en la nube de AWS. Esta infraestructura consiste en hardware, software, redes e instalaciones que ejecutan nuestros servicios en la nube. Los clientes son responsables de la seguridad de sus aplicaciones y datos en AWS.

La responsabilidad del cliente vendrá determinada por los servicios en la nube de AWS que seleccione. Esto determina la cantidad de operaciones de configuración que el cliente debe realizar como parte de sus responsabilidades de seguridad. Por ejemplo, los clientes que implementan una instancia de Amazon EC2 son responsables de administrar el sistema operativo invitado (que incluye actualizaciones de seguridad y parches), cualquier software de utilidad o aplicación instalados por el cliente en las instancias y la configuración del firewall proporcionada por AWS (llamado grupo de seguridad) en cada instancia. Para servicios como Amazon Simple Storage Service (Amazon S3) y Amazon DynamoDB, AWS opera la capa de infraestructura, el sistema operativo y las plataformas, y los clientes acceden a los endpoints para almacenar y recuperar datos. Los clientes son responsables de administrar sus datos (lo que incluye opciones de cifrado), clasificar los activos y utilizar las herramientas de administración de identidad y acceso para aplicar los permisos adecuados.

Según el informe de Checkpoint de 2022, en 2021 hubo un aumento del 50% en los ataques totales por semana a las redes corporativas en comparación con 2020, y los sectores de la educación y la investigación sufrieron un promedio de 1,605 ataques cada semana durante el año. El informe de Checkpoint de 2019 ya señalaba que el acceso no autorizado (42%) y las interfaces inseguras (42%) estaban empatados en primer lugar como las mayores vulnerabilidades de seguridad en la nube.

AWS ofrece el servicio Identity and Access Management (IAM) sin costo adicional, que controla la autenticación y la autorización de las llamadas a la API de los distintos servicios. La autenticación de IAM utiliza un proceso de firma digital que a menudo procesa 500 millones de llamadas a la API por segundo, realizadas a nuestros diferentes endpoints públicos de los servicios.

IAM es responsable de 2 procesos: la autenticación mediante la identificación del propietario de la credencial y la validación de la firma digital incluida en las llamadas a la API; si la autorización tiene éxito, IAM verificará la autorización de la llamada basándose en los permisos de acceso asociados a las credenciales presentadas, y en las políticas de acceso de los recursos y las cuentas de AWS involucrados.

El proceso de firma digital puede utilizar credenciales temporales o permanentes que se componen de:

1. Access Key ID
2. Secret Access Key
3. Secret Access Token (si son credenciales temporales)

Las Access Keys permanentes son generadas por el servicio de IAM y AWS las entrega al usuario solo en el momento de su creación. Estas claves de acceso caducan solo cuando el propietario o el administrador del sistema realizan una acción proactiva para desactivarlas o eliminarlas.

Las credenciales temporales, a su vez, se generan y proporcionan a través de una llamada a la API del servicio STS (Secure Token Service) y tienen una caducidad estándar de 1 hora que se puede configurar (un mínimo de 15 minutos y un máximo de 12 horas). Al transcurrir este período de validez establecido en la creación de las credenciales, estas ya no generan autenticaciones exitosas.

Una vez que se generan las credenciales y se comparten con el solicitante, AWS pierde el control sobre la custodia (almacenamiento y control) de estas claves. Ahí es donde entra en juego la parte del cliente del modelo de responsabilidad compartida, siguiendo las mejores prácticas para proteger sus claves de acceso: las Access Keys.

Como los endpoints de los servicios de AWS son públicos y se puede acceder a ellos a través del Internet, cualquier actor que tenga posesión de los componentes de la Access Key y pueda establecer conectividad con los endpoints de AWS a través del Internet, puede generar y firmar una llamada a la API válida. Las claves de acceso tienen el mismo nivel de acceso a los recursos de AWS que el usuario de IAM al cual están asociadas, por lo que se debe utilizar el nivel de privilegio más bajo posible para los usuarios de IAM de las claves de acceso.

Se recomienda que los clientes usen credenciales temporales siempre que sea posible, mediante el uso de IAM Roles. Los IAM Roles están asociados a los recursos de AWS (por ejemplo, asociar un rol a un EC2 que permita el acceso de la instancia a S3), estos roles no tienen credenciales permanentes; se entregan credenciales nuevas al sistema operativo cada hora. Con el uso de credenciales temporales, hay una menor probabilidad de que se utilicen en el código o en los archivos de configuración permanentes (embebidas) lo que reduce el riesgo de verse comprometidas e incluso, si se ven comprometidas, el tiempo de expiración reduce significativamente el riesgo asociado.

Teniendo en cuenta el caso de uso de un desarrollador que quiere probar una aplicación local en su equipo accediendo a DynamoDB en AWS, también se recomienda utilizar credenciales temporales en lugar de “hardcodear” las claves de acceso (Access Key) en el archivo de credenciales del dispositivo. La obtención de credenciales temporales se puede lograr de varias maneras: mediante la integración de línea de comandos de AWS (CLI de AWS) con AWS Single Sign On (AWS SSO), directamente en la consola de AWS SSO, o mediante scripts que utilizan el proceso AssumeRole para emitir las credenciales (muchas de ellas integradas con el IdP para la autenticación SAMLv2, por ejemplo) y entregarlas a la sesión de la terminal o al archivo de credenciales.

Si el uso de credenciales permanentes es imprescindible, es fundamental que se adopten las siguientes prácticas:

1. No genere claves de acceso al usuario root de la cuenta de AWS a menos que tenga un caso de uso legítimo (que son extremadamente limitados)
2. Cree políticas con el nivel de privilegio más bajo posible
3. Rote periódicamente estas credenciales
4. Supervise las credenciales no utilizadas y elimínelas periódicamente
5. Establezca restricciones en el uso de estas credenciales, consulte algunas opciones en la sección a continuación.

Prácticas recomendadas para restringir el uso de credenciales no temporales

Las políticas de control de acceso administradas por AWS están diseñadas para cubrir las necesidades de permisos de una amplia gama de clientes. Por este motivo, estas políticas de acceso administradas por AWS no imponen por defecto ningún tipo de condición restrictiva para ejecutar llamadas a la API, por ejemplo, desde una red específica (dirección IP, VPC, subnet, VPC endpoint), hora/día o el estado de validación de una autenticación de segundo factor (MFA). No obstante, IAM proporciona una amplia gama de condiciones que pueden ser utilizadas para restringir el acceso, como se sugiere a continuación.

MFA

Si las credenciales se utilizan en una situación en la que es posible validar un segundo factor de autenticación, coloque una condición de restricción de validación de MFA.

Consulte aquí ejemplos de cómo validar un MFA a través de la aplicación y aquí un ejemplo de validación de MFA a través de la CLI.

Restricción del origen de las solicitudes

IAM le permite usar una condición aws:SourceIp mediante rangos CIDR. Si la IP está dentro del (los) rango(s) de direcciones, la solicitud puede permitirse; de lo contrario, se rechazará.
La política a continuación, restringe cualquier llamada a la API que no se origine desde una dirección IP que pertenezca a los rangos especificados (192.0.2.0/24 y 203.0.113.0/24).

Advertencia: Tenga cuidado y pruebe antes de usar la restricción de dirección IP en SCPs (que se aplica a una o más cuentas de AWS) sin condiciones adicionales para “Principals” específicos. Los servicios de AWS realizan llamadas a sus recursos, por ejemplo AWS CloudFormation, y en casos limitados, estas llamadas pueden bloquearse incluso si la política incluye la condición de excepción como en el ejemplo anterior (“Bool”: {“aws:viaAWSService”: “false”}).

Cuando los recursos que deben realizar las llamadas a la API están en AWS (como EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Lambda), se deben usar atributos de origen nativos de AWS, como la VPC de origen (aws:SourceVPC) o el VPC endpoint de origen (AWS: SourceVPCE).

Resumen

Siempre buscamos evitar que las Access Keys se expongan accidentalmente y que personas no autorizadas accedan a ellas. Sin embargo, si esto ocurre, el impacto se puede reducir significativamente si se limitan las Access Keys a las acciones que permiten (privilegio mínimo) e incorporan barreras de protección adicionales (condiciones) para poder utilizarlas de acuerdo con las sugerencias anteriores.

Agregar estas capas de seguridad es muy importante en un mundo digital, teniendo en cuenta el panorama actual de ciberseguridad.

No deje la protección de sus Access Keys para mañana. ¡Haga su parte del modelo de responsabilidad compartida y no ponga en riesgo sus datos!

Referencias

• SIGv4:

https://docs.thinkwithwp.com/general/latest/gr/signature-version-4.html

• Políticas administradas e integradas: https://docs.thinkwithwp.com/pt_br/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
• Valide el MFA a través de la aplicación: https://docs.thinkwithwp.com/IAM/latest/UserGuide/id_credentials_mfa_sample-code.html
• Valide el MFA mediante la CLI:

 https://thinkwithwp.com/pt/premiumsupport/knowledge-center/authenticate-mfa-cli/

• Puntos de enlace de la VPC:

https://docs.thinkwithwp.com/vpc/latest/privatelink/vpc-endpoints.html

• Cree un AssumeRole de la CLI con SSO:

https://docs.thinkwithwp.com/cli/latest/userguide/cli-configure-sso.html

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

Sobre los autores

Maria Ane Dias es arquitecta de soluciones especializada en seguridad en AWS, cuenta con experiencia en desarrollo y tiene un gran gusto por el IoT y el área de manufactura. Ayuda a los clientes a crear y mantener sus viajes de seguridad en la nube. Tiene 20 años de experiencia en el área de TI.

Daniel García es un experto en seguridad en AWS con más de 20 años de experiencia en tecnología de la información y seguridad. Trabaja en estrecha colaboración con clientes en Brasil y América Latina para definir e implementar sus viajes de seguridad en la nube.

Gracias: Julio Carvalho y Fernando Cabral por revisar esta publicación de blog.