Machine-to-machine gestion des identités

Machine-to-machine L'authentification (M2M) permet aux services et aux applications exécutés sur AWS de communiquer en toute sécurité entre eux pour accéder aux ressources et aux données. Au lieu d'utiliser des informations d'identification statiques à long terme, les systèmes d'authentification automatique émettent des informations d'identification temporaires ou des jetons pour identifier les machines fiables. Ils permettent de contrôler avec précision quelles machines peuvent accéder à des parties spécifiques de l'environnement sans intervention humaine. Une authentification automatique bien conçue contribue à améliorer votre niveau de sécurité en limitant la large exposition aux informations d'identification, en permettant la révocation dynamique des autorisations et en simplifiant la rotation des informations d'identification. Les méthodes classiques d'authentification des machines incluent les profils d' EC2 instance, l'attribution des informations d'identification du client Amazon Cognito, les connexions TLS (MTLS) authentifiées mutuellement et IAM Roles Anywhere. Cette section fournit des conseils sur la mise en œuvre de flux d'authentification M2M sécurisés et évolutifs sur AWS.

EC2 profils d'instance

Pour les scénarios dans lesquels une application ou un service s'exécutant sur Amazon Elastic Compute Cloud (Amazon EC2) doit appeler AWS APIs, pensez à utiliser des profils d' EC2 instance. Les profils d'instance permettent aux applications qui s'exécutent sur EC2 des instances d'accéder en toute sécurité à d'autres services AWS sans avoir besoin de clés d'accès IAM statiques à longue durée de vie. Vous devez plutôt attribuer un rôle IAM à votre instance afin de fournir les autorisations requises via le profil d'instance. L' EC2 instance peut ensuite obtenir automatiquement des informations d'identification de sécurité temporaires à partir du profil d'instance pour accéder à d'autres services AWS. 

Le schéma suivant illustre ce scénario.

1. Une application de l' EC2 instance qui doit appeler une API AWS extrait les informations d'identification de sécurité fournies par le rôle à partir de l'élément iam/security-credentials/<role-name> de métadonnées de l'instance. 

2. L'application reçoit le AccessKeyIdSecretAccessKey, et un jeton secret qui peut être utilisé pour signer les demandes d'API AWS.

3. L'application appelle une API AWS. Si le rôle autorise l'action de l'API, la demande est réussie.

Pour en savoir plus sur l'utilisation d'informations d'identification temporaires avec les ressources AWS, consultez la section Utilisation d'informations d'identification temporaires avec les ressources AWS dans la documentation IAM.

Avantages

• Sécurité améliorée. Cette méthode évite de distribuer des informations d'identification à long terme aux EC2 instances. Les informations d'identification sont fournies temporairement via le profil d'instance. 

• Intégration facile. Les applications qui s'exécutent sur l'instance peuvent obtenir automatiquement des informations d'identification sans codage ni configuration supplémentaires. L'AWS utilise SDKs automatiquement les informations d'identification du profil de l'instance.

• Autorisations dynamiques. Vous pouvez modifier les autorisations disponibles pour l'instance en mettant à jour le rôle IAM attribué au profil d'instance. Les nouvelles informations d'identification qui reflètent les autorisations mises à jour sont automatiquement obtenues. 

• Rotation. AWS alterne automatiquement les informations d'identification temporaires afin de réduire le risque de compromission des informations d'identification. 

• Révocation. Vous pouvez révoquer les informations d'identification immédiatement en supprimant l'attribution de rôle du profil d'instance.

Considérations relatives à la conception

• Une EC2 instance ne peut avoir qu'un seul profil d'instance attaché.

• Utilisez les rôles IAM avec le moins de privilèges. Attribuez uniquement les autorisations requises par votre application au rôle IAM pour le profil d'instance. Commencez avec des autorisations minimales et ajoutez-en d'autres ultérieurement si nécessaire. 

• Utilisez les conditions IAM dans la politique de rôle pour restreindre les autorisations en fonction des balises, des plages d'adresses IP, de l'heure, etc. Cela limite les services et les ressources auxquels l'application peut accéder.

• Déterminez le nombre de profils d'instance dont vous avez besoin. Toutes les applications exécutées sur une EC2 instance partagent le même profil et disposent des mêmes autorisations AWS. Vous pouvez appliquer le même profil d'instance à plusieurs EC2 instances afin de réduire les frais administratifs en réutilisant les profils d'instance le cas échéant.

• Surveillez l'activité. Utilisez des outils tels qu'AWS CloudTrail pour surveiller les appels d'API qui utilisent les informations d'identification du profil d'instance. Surveillez toute activité inhabituelle qui pourrait indiquer que vos informations d'identification ont été compromises. 

• Supprimez les informations d'identification inutiles. Supprimez les attributions de rôles des profils d'instance non utilisés pour empêcher l'utilisation d'informations d'identification. Vous pouvez utiliser le conseiller d'accès IAM pour identifier les rôles inutilisés. 

• Utilisez l'PassRoleautorisation pour restreindre le rôle qu'un utilisateur peut transmettre à une EC2 instance lorsqu'il lance l'instance. Cela empêche l'utilisateur d'exécuter des applications qui disposent de plus d'autorisations que celles qui lui ont été accordées.

• Si votre architecture couvre plusieurs comptes AWS, réfléchissez à la manière dont EC2 les instances d'un compte peuvent avoir besoin d'accéder aux ressources d'un autre compte. Utilisez les rôles entre comptes de manière appropriée pour garantir un accès sécurisé sans avoir à intégrer des informations d'identification de sécurité AWS à long terme.

• Pour gérer les profils d'instance à grande échelle, vous pouvez utiliser l'une des options suivantes :

  • Utilisez les runbooks d'AWS Systems Manager Automation pour automatiser l'association des profils d'instance aux EC2 instances. Cela peut être fait au moment du lancement ou après l'exécution d'une instance.

  • Utilisez AWS CloudFormation pour appliquer des profils d'instance aux EC2 instances par programmation au moment de leur création, au lieu de les configurer via la console AWS.

• Il est recommandé d'utiliser des points de terminaison VPC pour se connecter de manière privée aux services AWS pris en charge tels qu'Amazon S3 et Amazon DynamoDB à partir d'applications exécutées sur des instances. EC2 

Octroi d'informations d'identification client Amazon Cognito

Amazon Cognito est un service géré de gestion de l'identité et de l'accès des clients. Amazon Cognito fournit des flux d'authentification OAuth conformes, notamment la possibilité d'authentifier des machines ou des applications plutôt que des utilisateurs via le type d'autorisation d'identification du client. Cette subvention permet à une application de récupérer directement des informations d'identification AWS temporaires pour accéder aux services AWS. Les informations d'identification du client Amazon Cognito constituent un moyen sécurisé de fournir des autorisations AWS aux applications sans interaction humaine avec l'utilisateur. Les applications présentent leur identifiant client et leur secret client au point de terminaison du jeton Amazon Cognito. En retour, ils reçoivent un jeton d'accès qu'ils peuvent utiliser pour authentifier les demandes ultérieures adressées à diverses ressources et services. L'étendue de cet accès est dictée par les autorisations associées à l'ID client. L'application qui reçoit la demande doit valider le jeton en vérifiant sa signature, son horodatage d'expiration et son audience. Après ces vérifications, l'application vérifie que l'action demandée est autorisée en validant les revendications contenues dans le jeton.

Le schéma suivant illustre cette méthode.

1. L'application (App Client) qui souhaite demander des ressources à un serveur (Resource Server) demande un jeton à Amazon Cognito.

2. Les groupes d'utilisateurs Amazon Cognito renvoient un jeton d'accès.

3. App Client envoie une demande au serveur de ressources et inclut le jeton d'accès.

4. Le serveur de ressources valide le jeton avec Amazon Cognito.

5. Si la validation est réussie et que l'action demandée est autorisée, le serveur de ressources répond avec la ressource demandée.

Avantages

• Authentification automatique. Cette méthode ne nécessite pas de contexte utilisateur ni de connexion. L'application s'authentifie directement à l'aide de jetons.

• Informations d'identification à court terme. Les applications peuvent d'abord obtenir un jeton d'accès auprès d'Amazon Cognito, puis utiliser le jeton d'accès limité dans le temps pour accéder aux données du serveur de ressources.

• OAuth2 soutien. Cette méthode réduit les incohérences et facilite le développement des applications car elle suit les normes établies OAuth2 .

• Sécurité renforcée. L'utilisation de l'attribution des informations d'identification du client améliore la sécurité, car l'identifiant du client et le secret du client ne sont pas transférés vers le serveur de ressources, contrairement à un mécanisme d'autorisation par clé d'API. L'ID client et le secret sont partagés et utilisés uniquement lorsque vous appelez Amazon Cognito pour obtenir des jetons d'accès limités dans le temps.

• Contrôle d'accès précis grâce à des oscilloscopes. L'application peut définir et demander des étendues et des revendications supplémentaires afin de limiter l'accès à des ressources spécifiques uniquement.

• Piste d'audit. Vous pouvez utiliser les informations collectées CloudTrail pour déterminer la demande envoyée à Amazon Cognito, l'adresse IP à partir de laquelle la demande a été faite, l'auteur de la demande, la date à laquelle elle a été faite et des informations supplémentaires. 

Considérations relatives à la conception

• Définissez soigneusement et limitez l'étendue de l'accès pour chaque ID client au minimum requis. Des périmètres restreints permettent de réduire les vulnérabilités potentielles et de garantir que les services n'ont accès qu'aux ressources nécessaires. 

• Protégez le client IDs et les secrets en utilisant des services de stockage sécurisés tels qu'AWS Secrets Manager pour stocker les informations d'identification. Ne vérifiez pas les informations d'identification dans le code source.

• Surveillez et auditez les demandes de jetons et leur utilisation à l'aide d'outils tels que CloudTrail et CloudWatch. Surveillez les modèles d'activité inattendus qui pourraient indiquer des problèmes. 

• Automatisez la rotation des secrets des clients selon un calendrier régulier. À chaque rotation, créez un nouveau client d'application, supprimez l'ancien client et mettez à jour l'identifiant et le secret du client. Facilitez ces rotations sans perturber les communications de service. 

• Appliquez des limites de débit aux demandes de points de terminaison symboliques afin de prévenir les abus et les attaques par déni de service (DoS). 

• Préparez une stratégie pour révoquer les jetons en cas de faille de sécurité. Bien que les jetons soient de courte durée, les jetons compromis doivent être immédiatement invalidés.

• Utilisez AWS CloudFormation pour créer par programmation des groupes d'utilisateurs Amazon Cognito et les clients d'applications qui représentent les machines devant s'authentifier auprès d'autres services.

• Le cas échéant, mettez en cache des jetons pour optimiser les performances et les coûts.

• Assurez-vous que l'expiration des jetons d'accès correspond au niveau de sécurité de votre entreprise.

• Si vous utilisez un serveur de ressources personnalisé, vérifiez toujours le jeton d'accès pour vous assurer que la signature est valide, que le jeton n'a pas expiré et que les étendues correctes sont présentes. Vérifiez toute réclamation supplémentaire si nécessaire.

• Pour gérer les informations d'identification des clients à grande échelle, vous pouvez utiliser l'une des options suivantes :

  • Centralisez la gestion de toutes les informations d'identification des clients dans une seule instance Amazon Cognito centralisée. Cela permet de réduire les frais de gestion de plusieurs instances Amazon Cognito et de simplifier la configuration et l'audit. Veillez toutefois à planifier l'échelle et à prendre en compte les quotas du service Amazon Cognito.

  • Conférez la responsabilité des informations d'identification des clients aux comptes de charge de travail et autorisez plusieurs instances Amazon Cognito. Cette option favorise la flexibilité mais peut augmenter les frais généraux et la complexité globale par rapport à l'option centralisée.

Connexions MTLS

L'authentification TLS mutuelle (mTLS) est un mécanisme qui permet au client et au serveur de s'authentifier mutuellement avant de communiquer en utilisant des certificats TLS. Les cas d'utilisation courants des MTL incluent les secteurs soumis à des réglementations strictes, les applications Internet des objets (IoT) et les applications business-to-business (B2B). Amazon API Gateway prend actuellement en charge les MTL en plus de ses options d'autorisation existantes. Vous pouvez activer les MTL sur des domaines personnalisés pour vous authentifier par rapport au protocole REST et HTTP régionaux. APIs Les demandes peuvent être autorisées à l'aide de Bearer, de JSON Web Tokens (JWTs) ou de signer des demandes avec une autorisation basée sur IAM. 

Le schéma suivant montre le flux d'authentification mTLS pour une application exécutée sur une EC2 instance et une API configurée sur Amazon API Gateway.

1. API Gateway demande un certificat approuvé publiquement directement auprès d'AWS Certificate Manager (ACM).

2. ACM génère le certificat à partir de son autorité de certification (CA).

3. Le client qui appelle l'API présente un certificat avec la demande d'API.

4. API Gateway vérifie le compartiment Trust Store Amazon S3 que vous avez créé. Ce compartiment contient les certificats X.509 auxquels vous faites confiance pour accéder à votre API. Pour qu'API Gateway puisse traiter la demande, l'émetteur du certificat et l'ensemble de la chaîne de confiance jusqu'au certificat de l'autorité de certification racine doivent se trouver dans votre magasin de confiance.

5. Si le certificat du client est fiable, API Gateway approuve la demande et appelle la méthode.

6. L'action d'API associée (dans ce cas, une fonction AWS Lambda) traite la demande et renvoie une réponse qui est envoyée au demandeur.

Avantages

• Authentification M2M. Les services s'authentifient mutuellement directement au lieu d'utiliser des secrets ou des jetons partagés. Il n'est donc plus nécessaire de stocker et de gérer des informations d'identification statiques.

• Protection contre les altérations. Le chiffrement TLS protège les données en transit entre les services. Les communications ne peuvent pas être lues ou modifiées par des tiers. 

• Intégration facile. Le support de MTL est intégré aux principaux langages de programmation et frameworks. Les services peuvent activer les MTL avec un minimum de modifications de code. 

• Autorisations granulaires. Les services ne font confiance qu'à des certificats spécifiques, ce qui permet un contrôle précis des appelants autorisés. 

• Révocation. Les certificats compromis peuvent être révoqués immédiatement afin qu'ils ne soient plus fiables, empêchant ainsi tout accès ultérieur. 

Considérations relatives à la conception

• Lorsque vous utilisez API Gateway :

  • Par défaut, les clients peuvent appeler votre API en utilisant le execute-api point de terminaison généré par API Gateway pour votre API. Pour garantir que les clients peuvent accéder à votre API uniquement en utilisant un nom de domaine personnalisé avec mTLS, désactivez ce point de terminaison par défaut. Pour en savoir plus, consultez la section Désactivation du point de terminaison par défaut pour une API REST dans la documentation d'API Gateway.

  • API Gateway ne vérifie pas si les certificats ont été révoqués.

  • Pour configurer le protocole MTL pour une API REST, vous devez utiliser un nom de domaine personnalisé régional pour votre API, avec une version TLS minimale de 1.2. Le protocole mTLS n'est pas pris en charge pour le mode privé. APIs

• Vous pouvez émettre des certificats pour API Gateway depuis votre propre autorité de certification ou les importer depuis l'autorité de certification privée AWS.

• Créez des processus pour émettre, distribuer, renouveler et révoquer des certificats de service en toute sécurité. Automatisez l'émission et le renouvellement dans la mesure du possible. Si l'un des côtés de votre communication M2M est une passerelle d'API, vous pouvez l'intégrer à AWS Private CA.

• Protégez l'accès à l'autorité de certification privée. Compromettre l'autorité de certification compromet la confiance dans tous les certificats qu'elle a émis.

• Stockez les clés privées en toute sécurité et séparément des certificats. Faites pivoter les touches régulièrement pour limiter l'impact en cas de compromission.

• Révoquez les certificats immédiatement lorsqu'ils ne sont plus nécessaires ou s'ils sont compromis. Distribuez des listes de révocation de certificats aux services. 

• Dans la mesure du possible, émettez des certificats destinés uniquement à des fins ou à des ressources spécifiques afin de limiter leur utilité en cas de compromission.

• Établissez des plans d'urgence pour les expirations de certificats et les pannes de l'infrastructure de l'autorité de certification ou de la liste de révocation des certificats (CRL). 

• Surveillez votre système pour détecter les défaillances et les pannes de certificats. Surveillez les pics de défaillances qui pourraient indiquer des problèmes.

• Si vous utilisez AWS Certificate Manager (ACM) avec AWS Private CA, vous pouvez utiliser AWS CloudFormation pour demander des certificats publics et privés par programmation.

• Si vous utilisez ACM, utilisez AWS Resource Access Manager (AWS RAM) pour partager le certificat d'un compte de sécurité vers le compte de charge de travail.

Rôles Anywhere IAM

Nous vous recommandons d'utiliser IAM Roles Anywhere pour la gestion des identités M2M lorsque des machines ou des systèmes doivent se connecter aux services AWS mais ne prennent pas en charge les rôles IAM. IAM Roles Anywhere est une extension d'IAM qui utilise une infrastructure à clé publique (PKI) pour accorder l'accès aux charges de travail à l'aide d'informations d'identification de sécurité temporaires. Vous pouvez utiliser des certificats X.509, qui peuvent être émis par le biais d'une autorité de certification ou par une autorité de certification privée AWS, pour établir un point d'ancrage de confiance entre l'autorité de certification et IAM Roles Anywhere. Comme pour les rôles IAM, la charge de travail peut accéder aux services AWS en fonction de sa politique d'autorisation, qui est attachée au rôle. 

Le schéma suivant montre comment utiliser IAM Roles Anywhere pour connecter AWS à des ressources externes.

1. Vous créez un point d'ancrage de confiance pour établir un lien de confiance entre votre compte AWS et l'autorité de certification qui émet des certificats pour vos charges de travail sur site. Les certificats sont émis par une autorité de certification que vous enregistrez en tant qu'ancre de confiance (racine de confiance) dans IAM Roles Anywhere. L'autorité de certification peut faire partie de votre système d'infrastructure à clé publique (PKI) existant, ou il peut s'agir d'une autorité de certification que vous avez créée avec l'autorité de certification privée AWS et que vous gérez avec ACM. Dans cet exemple, nous utilisons ACM.

2. Votre application envoie une demande d'authentification à IAM Roles Anywhere et envoie sa clé publique (codée dans un certificat) ainsi qu'une signature signée par la clé privée correspondante. Votre application précise également le rôle à assumer dans la demande.

3. Lorsque IAM Roles Anywhere reçoit la demande, il valide d'abord la signature avec la clé publique, puis confirme que le certificat a été émis par une ancre de confiance. Une fois les deux validations réussies, votre application est authentifiée et IAM Roles Anywhere crée une nouvelle session de rôle pour le rôle spécifié dans la demande en appelant AWS Security Token Service (AWS STS).

4. Vous utilisez l'outil d'aide aux informations d'identification fourni par IAM Roles Anywhere pour gérer le processus de création d'une signature avec le certificat et pour appeler le point de terminaison pour obtenir les informations d'identification de session. L'outil renvoie les informations d'identification au processus d'appel dans un format JSON standard.

5. En utilisant ce modèle de confiance passerelle entre IAM et PKI, les charges de travail sur site utilisent ces informations d'identification temporaires (clé d'accès, clé secrète et jeton de session) pour assumer le rôle IAM et interagir avec les ressources AWS sans avoir besoin d'informations d'identification à long terme. Vous pouvez également configurer ces informations d'identification à l'aide de l'AWS CLI ou d'AWS SDKs.

Avantages

• Aucune identification permanente. Les applications n'ont pas besoin de clés d'accès AWS à long terme avec des autorisations étendues. 

• Accès précis. Les politiques déterminent quel rôle IAM peut être assumé pour une entité spécifique. 

• Rôles sensibles au contexte. Le rôle peut être personnalisé en fonction des détails de l'entité authentifiée.

• Révocation. La révocation des autorisations de confiance empêche immédiatement une entité d'assumer un rôle.

Considérations relatives à la conception

• Les serveurs doivent être en mesure de prendre en charge l'authentification basée sur des certificats. 

• Il est recommandé de verrouiller la politique de confiance à utiliser aws:SourceArn ou aws:SourceAccount pour le compte sur lequel l'ancre de confiance a été configurée. 

• Les balises principales sont reportées à partir des détails du certificat. Il s'agit notamment du nom commun (CN), du nom alternatif du sujet (SAN), du sujet et de l'émetteur.

• Si vous utilisez ACM, utilisez la RAM AWS pour partager le certificat d'un compte de sécurité vers le compte de charge de travail.

• Utilisez les autorisations du système de fichiers du système d'exploitation (OS) pour restreindre l'accès en lecture à l'utilisateur propriétaire.

• Ne cochez jamais les clés dans le contrôle de source. Stockez-les séparément du code source afin de réduire le risque de les inclure accidentellement dans un ensemble de modifications. Si possible, pensez à utiliser un mécanisme de stockage sécurisé.

• Assurez-vous de disposer d'un processus de rotation et de révocation des certificats.