Machine-to-machine gestión de identidad

Machine-to-machine La autenticación (M2M) permite que los servicios y las aplicaciones que se ejecutan en AWS se comuniquen entre sí de forma segura para acceder a los recursos y los datos. En lugar de utilizar credenciales estáticas de larga duración, los sistemas de autenticación automática emiten credenciales o fichas temporales para identificar las máquinas de confianza. Permiten controlar con precisión qué máquinas pueden acceder a partes específicas del entorno sin intervención humana. La autenticación automática bien diseñada ayuda a mejorar su postura de seguridad al limitar la exposición generalizada de las credenciales, permitir la revocación dinámica de los permisos y simplificar la rotación de credenciales. Los métodos típicos de autenticación de máquinas incluyen los perfiles de EC2 instancia, la concesión de credenciales de cliente de Amazon Cognito, las conexiones TLS (mTLS) autenticadas mutuamente y los roles de IAM en cualquier lugar. Esta sección proporciona orientación sobre la implementación de flujos de autenticación M2M seguros y escalables en AWS.

EC2 perfiles de instancia

En los casos en los que tenga una aplicación o un servicio ejecutándose en Amazon Elastic Compute Cloud (Amazon EC2) que necesite llamar a AWS APIs, considere la posibilidad de utilizar perfiles de EC2 instancia. Los perfiles de instancia permiten que las aplicaciones que se ejecutan en EC2 las instancias accedan de forma segura a otros servicios de AWS sin necesidad de claves de acceso de IAM estáticas y duraderas. En su lugar, debe asignar una función de IAM a su instancia para proporcionar los permisos necesarios a través del perfil de la instancia. A continuación EC2 , la instancia puede obtener automáticamente credenciales de seguridad temporales del perfil de la instancia para acceder a otros servicios de AWS. 

En el siguiente diagrama se ilustra este escenario.

1. Una aplicación de la EC2 instancia que necesita llamar a una API de AWS recupera las credenciales de seguridad proporcionadas por el rol del elemento iam/security-credentials/<role-name> de metadatos de la instancia. 

2. La aplicación recibe el AccessKeyIdSecretAccessKey, y un token secreto que se puede usar para firmar las solicitudes de API de AWS.

3. La aplicación llama a una API de AWS. Si el rol permite la acción de la API, la solicitud se ha realizado correctamente.

Para obtener más información sobre el uso de credenciales temporales con los recursos de AWS, consulte Uso de credenciales temporales con los recursos de AWS en la documentación de IAM.

Beneficios

• Seguridad mejorada. Este método evita la distribución de credenciales a largo plazo a las EC2 instancias. Las credenciales se proporcionan temporalmente a través del perfil de la instancia. 

• Integración sencilla. Las aplicaciones que se ejecutan en la instancia pueden obtener credenciales automáticamente sin necesidad de codificación ni configuración adicionales. AWS utiliza SDKs automáticamente las credenciales del perfil de la instancia.

• Permisos dinámicos. Puedes cambiar los permisos disponibles para la instancia actualizando la función de IAM que está asignada al perfil de la instancia. Las nuevas credenciales que reflejan los permisos actualizados se obtienen automáticamente. 

• Rotación. AWS rota automáticamente las credenciales temporales para reducir el riesgo de que las credenciales se vean comprometidas. 

• Revocación. Puede revocar las credenciales inmediatamente eliminando la asignación de funciones del perfil de la instancia.

Consideraciones sobre el diseño

• Una EC2 instancia solo puede tener un perfil de instancia adjunto.

• Utilice funciones de IAM con privilegios mínimos. Asigna solo los permisos que tu aplicación requiera al rol de IAM para el perfil de la instancia. Comience con los permisos mínimos y añada más permisos más adelante si es necesario. 

• Utilice las condiciones de IAM en la política de funciones para restringir los permisos en función de las etiquetas, los intervalos de direcciones IP, la hora del día, etc. Esto limita los servicios y recursos a los que puede acceder la aplicación.

• Tenga en cuenta el número de perfiles de instancia que necesita. Todas las aplicaciones que se ejecutan en una EC2 instancia comparten el mismo perfil y tienen los mismos permisos de AWS. Puede aplicar el mismo perfil de instancia a varias EC2 instancias, de modo que puede reducir la sobrecarga administrativa reutilizando los perfiles de instancia cuando proceda.

• Supervise la actividad. Utilice herramientas como AWS CloudTrail para supervisar las llamadas a la API que utilizan las credenciales del perfil de la instancia. Esté atento a cualquier actividad inusual que pueda indicar que las credenciales están comprometidas. 

• Elimine las credenciales innecesarias. Elimine las asignaciones de funciones de los perfiles de instancia no utilizados para evitar el uso de credenciales. Puede utilizar el asesor de acceso de IAM para identificar las funciones no utilizadas. 

• Utilice el PassRole permiso para restringir el rol que un usuario puede transferir a una EC2 instancia al lanzar la instancia. Esto impide que el usuario ejecute aplicaciones que tengan más permisos de los que se le han concedido.

• Si su arquitectura abarca varias cuentas de AWS, considere cómo las EC2 instancias de una cuenta podrían necesitar acceder a los recursos de otra cuenta. Utilice las funciones multicuenta de forma adecuada para garantizar un acceso seguro sin tener que incrustar credenciales de seguridad de AWS a largo plazo.

• Para gestionar los perfiles de instancia a escala, puede utilizar una de estas opciones:

  • Utilice los manuales de ejecución de AWS Systems Manager Automation para automatizar la asociación de los perfiles de instancia a EC2 las instancias. Esto se puede hacer en el momento del lanzamiento o después de que se ejecute una instancia.

  • Utilice AWS CloudFormation para aplicar perfiles de instancia a EC2 las instancias mediante programación en el momento de la creación, en lugar de configurarlos a través de la consola de AWS.

• Se recomienda utilizar puntos de enlace de VPC para conectarse de forma privada a servicios de AWS compatibles, como Amazon S3 y Amazon DynamoDB, desde aplicaciones que se ejecutan en instancias. EC2 

Concesión de credenciales de cliente de Amazon Cognito

Amazon Cognito es un servicio gestionado de identidad y acceso de clientes. Amazon Cognito proporciona flujos de autenticación OAuth compatibles, incluida la capacidad de autenticar máquinas o aplicaciones en lugar de usuarios mediante el tipo de concesión de credenciales de cliente. Esta subvención permite a una solicitud recuperar directamente las credenciales temporales de AWS para acceder a los servicios de AWS. Las credenciales de cliente de Amazon Cognito son una forma segura de proporcionar permisos de AWS a las aplicaciones sin la interacción de un usuario humano. Las aplicaciones presentan su ID de cliente y su secreto de cliente en el punto final del token de Amazon Cognito. A cambio, reciben un token de acceso, que pueden usar para autenticar las solicitudes posteriores a varios recursos y servicios. El alcance de este acceso viene determinado por los permisos asociados al ID del cliente. La aplicación que recibe la solicitud debe validar el token comprobando su firma, fecha de caducidad y público. Tras estas comprobaciones, la aplicación verifica que la acción solicitada está permitida validando las afirmaciones del token.

El siguiente diagrama ilustra este método.

1. La aplicación (App Client) que quiere solicitar recursos de un servidor (Resource Server) solicita un token de Amazon Cognito.

2. Los grupos de usuarios de Amazon Cognito devuelven un token de acceso.

3. App Client envía una solicitud al servidor de recursos e incluye el token de acceso.

4. El servidor de recursos valida el token con Amazon Cognito.

5. Si la validación se realiza correctamente y se permite la acción solicitada, el servidor de recursos responde con el recurso solicitado.

Beneficios

• Autenticación de máquinas. Este método no requiere el contexto del usuario ni los inicios de sesión. La aplicación se autentica directamente con fichas.

• Credenciales a corto plazo. Las aplicaciones pueden obtener primero un token de acceso de Amazon Cognito y, a continuación, utilizar el token de acceso con límite de tiempo para acceder a los datos del servidor de recursos.

• OAuth2 soporte. Este método reduce las inconsistencias y ayuda al desarrollo de aplicaciones porque sigue el estándar establecido OAuth2 .

• Seguridad mejorada. El uso de la concesión de credenciales de cliente proporciona una mayor seguridad, ya que el ID y el secreto del cliente no se transfieren al servidor de recursos, a diferencia de lo que ocurre con un mecanismo de autorización de claves de API. El identificador y el secreto del cliente se comparten y solo se utilizan cuando se realizan llamadas a Amazon Cognito para obtener tokens de acceso con un límite de tiempo.

• Control de acceso detallado mediante osciloscopios. La aplicación puede definir y solicitar alcances y derechos adicionales para limitar el acceso únicamente a recursos específicos.

• Registro de auditoría. Puede usar la información recopilada por CloudTrail para determinar la solicitud que se realizó a Amazon Cognito, la dirección IP desde la que se realizó la solicitud, quién la realizó, cuándo se realizó y detalles adicionales. 

Consideraciones sobre el diseño

• Defina y restrinja cuidadosamente el alcance de acceso de cada ID de cliente al mínimo requerido. Los alcances estrictos ayudan a reducir las posibles vulnerabilidades y a garantizar que los servicios solo tengan acceso a los recursos necesarios. 

• Proteja sus clientes IDs y sus secretos mediante servicios de almacenamiento seguro, como AWS Secrets Manager, para almacenar las credenciales. No registre las credenciales en el código fuente.

• Supervise y audite las solicitudes y el uso de los tokens con herramientas como CloudTrail y CloudWatch. Esté atento a los patrones de actividad inesperados que puedan indicar problemas. 

• Automatice la rotación de los secretos de los clientes de forma periódica. Con cada rotación, cree un nuevo cliente de aplicación, elimine el cliente anterior y actualice el identificador y el secreto del cliente. Facilite estas rotaciones sin interrumpir las comunicaciones del servicio. 

• Imponga límites de velocidad a las solicitudes de puntos finales simbólicos para ayudar a prevenir los ataques de abuso y denegación de servicio (DoS). 

• Prepara una estrategia para revocar los tokens en caso de que se produzca una violación de la seguridad. Si bien los tokens son de corta duración, los tokens comprometidos deben invalidarse de inmediato.

• Utilice AWS CloudFormation para crear mediante programación los grupos de usuarios de Amazon Cognito y los clientes de aplicaciones que representan las máquinas que necesitan autenticarse en otros servicios.

• Cuando proceda, almacene en caché los tokens para proporcionar eficiencia en el rendimiento y optimizar los costes.

• Asegúrese de que la caducidad de los tokens de acceso se ajuste a la postura de seguridad de su organización.

• Si utilizas un servidor de recursos personalizado, verifica siempre el token de acceso para asegurarte de que la firma sea válida, que el token no haya caducado y que tenga los alcances correctos. Verifica cualquier afirmación adicional según sea necesario.

• Para gestionar las credenciales de los clientes a gran escala, puede utilizar una de estas opciones:

  • Centralice la administración de todas las credenciales de los clientes en una única instancia centralizada de Amazon Cognito. Esto puede reducir la sobrecarga de administración de varias instancias de Amazon Cognito y simplificar la configuración y la auditoría. Sin embargo, asegúrese de planificar la escala y tener en cuenta las cuotas de servicio de Amazon Cognito.

  • Federe la responsabilidad de las credenciales de los clientes con las cuentas de carga de trabajo y permita varias instancias de Amazon Cognito. Esta opción promueve la flexibilidad, pero puede aumentar los gastos generales y la complejidad general en comparación con la opción centralizada.

Conexiones mTLS

La autenticación TLS mutua (mTLS) es un mecanismo que permite que tanto el cliente como el servidor se autentiquen entre sí antes de comunicarse mediante certificados con TLS. Los casos de uso comunes de los MTL incluyen industrias con regulaciones estrictas, aplicaciones de Internet de las cosas (IoT) y aplicaciones business-to-business (B2B). Actualmente, Amazon API Gateway admite mTLS, además de las opciones de autorización existentes. Puede habilitar los mTLs en dominios personalizados para autenticarse mediante REST regional y HTTP. APIs Las solicitudes se pueden autorizar mediante Bearer, JSON Web Tokens (JWTs) o firmar las solicitudes con una autorización basada en IAM. 

El siguiente diagrama muestra el flujo de autenticación mTLS para una aplicación que se ejecuta en una EC2 instancia y una API configurada en Amazon API Gateway.

1. API Gateway solicita un certificado de confianza pública directamente a AWS Certificate Manager (ACM).

2. ACM genera el certificado a partir de su autoridad de certificación (CA).

3. El cliente que llama a la API presenta un certificado con la solicitud de la API.

4. API Gateway comprueba el bucket del almacén de confianza de Amazon S3 que ha creado. Este depósito contiene los certificados X.509 en los que puede confiar para acceder a su API. Para que API Gateway pueda procesar la solicitud, el emisor del certificado y toda la cadena de confianza hasta el certificado de CA raíz deben estar en tu almacén de confianza.

5. Si el certificado del cliente es de confianza, API Gateway aprueba la solicitud y llama al método.

6. La acción de API asociada (en este caso, una función de AWS Lambda) procesa la solicitud y devuelve una respuesta que se envía al solicitante.

Beneficios

• Autenticación M2M. Los servicios se autentican entre sí directamente en lugar de utilizar claves o secretos compartidos. Esto elimina la necesidad de almacenar y administrar las credenciales estáticas.

• Protección contra manipulaciones. El cifrado TLS protege los datos en tránsito entre servicios. Las comunicaciones no pueden ser leídas ni alteradas por terceros. 

• Fácil integración. La compatibilidad con mTLS está integrada en los principales marcos y lenguajes de programación. Los servicios pueden habilitar los MTL con cambios de código mínimos. 

• Permisos granulares. Los servicios solo confían en certificados específicos, lo que permite un control detallado de las personas que llaman permitidas. 

• Revocación. Los certificados comprometidos se pueden revocar inmediatamente, por lo que ya no son de confianza, lo que impide un mayor acceso. 

Consideraciones sobre el diseño

• Cuando utilizas API Gateway:

  • De forma predeterminada, los clientes pueden llamar a tu API mediante el execute-api punto de conexión que API Gateway genera para tu API. Para garantizar que los clientes solo puedan acceder a tu API mediante un nombre de dominio personalizado con mTLS, desactiva este punto final predeterminado. Para obtener más información, consulta Cómo deshabilitar el punto final predeterminado para una API REST en la documentación de API Gateway.

  • API Gateway no comprueba si los certificados se han revocado.

  • Para configurar mTLS para una API REST, debes usar un nombre de dominio regional personalizado para tu API, con una versión mínima de TLS de 1.2. mTLS no es compatible con aplicaciones privadas. APIs

• Puede emitir certificados para API Gateway desde su propia CA o importarlos desde AWS Private Certificate Authority.

• Cree procesos para emitir, distribuir, renovar y revocar certificados de servicio de forma segura. Automatice la emisión y la renovación siempre que sea posible. Si un lado de su comunicación M2M es una puerta de enlace de API, puede integrarla con AWS Private CA.

• Proteja el acceso a la CA privada. Poner en peligro la CA compromete la confianza en todos los certificados que emitió.

• Guarde las claves privadas de forma segura y separada de los certificados. Gire las claves periódicamente para limitar el impacto en caso de que se vean comprometidas.

• Revoca los certificados inmediatamente cuando ya no sean necesarios o estén en peligro. Distribuya las listas de revocación de certificados a los servicios. 

• Siempre que sea posible, emita certificados que estén destinados únicamente a fines o recursos específicos para limitar su utilidad en caso de que se vean comprometidos.

• Tenga planes de contingencia para los vencimientos de los certificados y las interrupciones de la infraestructura de la CA o de la lista de revocación de certificados (CRL). 

• Supervise su sistema para detectar fallos e interrupciones en los certificados. Esté atento a los picos de errores que puedan indicar problemas.

• Si utiliza AWS Certificate Manager (ACM) con AWS Private CA, puede utilizar AWS CloudFormation para solicitar certificados públicos y privados mediante programación.

• Si utiliza ACM, utilice AWS Resource Access Manager (AWS RAM) para compartir el certificado de una cuenta de seguridad con la cuenta de carga de trabajo.

IAM Roles Anywhere

Le recomendamos que utilice IAM Roles Anywhere para la administración de identidades M2M cuando las máquinas o los sistemas necesiten conectarse a los servicios de AWS pero no admitan los roles de IAM. IAM Roles Anywhere es una extensión de IAM que utiliza una infraestructura de clave pública (PKI) para conceder el acceso a las cargas de trabajo mediante credenciales de seguridad temporales. Puede usar los certificados X.509, que pueden emitirse a través de una CA o por una CA privada de AWS, para establecer un nexo de confianza entre las funciones de CA e IAM en cualquier lugar. Al igual que con las funciones de IAM, la carga de trabajo puede acceder a los servicios de AWS en función de su política de permisos, que se adjunta a la función. 

En el siguiente diagrama se muestra cómo puede utilizar IAM Roles Anywhere para conectar AWS con recursos externos.

1. Debe crear un ancla de confianza para establecer la confianza entre su cuenta de AWS y la CA que emite los certificados para sus cargas de trabajo locales. Los certificados los emite una entidad emisora de certificados que usted registra como entidad de confianza (raíz de confianza) en IAM Roles Anywhere. La CA puede formar parte de su sistema de infraestructura de clave pública (PKI) existente o puede ser una CA que haya creado con AWS Private Certificate Authority y que administre con ACM. En este ejemplo, utilizamos ACM.

2. Su aplicación realiza una solicitud de autenticación a IAM Roles Anywhere y envía su clave pública (codificada en un certificado) y una firma firmada con la clave privada correspondiente. La aplicación también especifica el rol que se va a asumir en la solicitud.

3. Cuando IAM Roles Anywhere recibe la solicitud, primero valida la firma con la clave pública y, a continuación, valida que el certificado haya sido emitido por una entidad de confianza. Cuando ambas validaciones se realicen correctamente, la aplicación se autenticará e IAM Roles Anywhere creará una nueva sesión de rol para el rol especificado en la solicitud mediante una llamada a AWS Security Token Service (AWS STS).

4. Utiliza la herramienta de ayuda para credenciales que proporciona IAM Roles Anywhere para gestionar el proceso de creación de una firma con el certificado y llamar al punto final para obtener las credenciales de la sesión. La herramienta devuelve las credenciales al proceso de llamada en un formato JSON estándar.

5. Al utilizar este modelo de confianza puente entre IAM y PKI, las cargas de trabajo locales utilizan estas credenciales temporales (clave de acceso, clave secreta y token de sesión) para asumir la función de IAM e interactuar con los recursos de AWS sin necesidad de credenciales a largo plazo. También puede configurar estas credenciales mediante la AWS CLI o AWS SDKs.

Beneficios

• Sin credenciales permanentes. Las aplicaciones no necesitan claves de acceso de AWS a largo plazo con permisos amplios. 

• Acceso detallado. Las políticas determinan qué función de IAM puede asumir una entidad específica. 

• Funciones sensibles al contexto. El rol se puede personalizar en función de los detalles de la entidad autenticada.

• Revocación. La revocación de los permisos de confianza impide inmediatamente que una entidad asuma una función.

Consideraciones sobre el diseño

• Los servidores deben poder admitir la autenticación basada en certificados. 

• Se recomienda bloquear la política de confianza para usar aws:SourceArn o aws:SourceAccount para la cuenta en la que se ha configurado el anclaje de confianza. 

• Las etiquetas principales se extraen de los detalles del certificado. Estas incluyen el nombre común (CN), el nombre alternativo del sujeto (SAN), el sujeto y el emisor.

• Si utiliza ACM, utilice la RAM de AWS para compartir el certificado de una cuenta de seguridad con la cuenta de carga de trabajo.

• Utilice los permisos del sistema de archivos del sistema operativo (SO) para restringir el acceso de lectura al usuario propietario.

• Nunca introduzca las claves en el control de código fuente. Guárdelas por separado del código fuente para reducir el riesgo de incluirlas accidentalmente en un conjunto de cambios. Si es posible, considere la posibilidad de utilizar un mecanismo de almacenamiento seguro.

• Asegúrese de contar con un proceso para rotar y revocar los certificados.