Protection des informations d'identification sensibles

Résumé

Il est fondamental pour les développeurs d'applications de s'assurer que les informations d'identification sensibles sont protégées. Le codage en dur des informations d'identification sensibles, telles que les clés API et les clés secrètes, est l'une des erreurs les plus couramment commises par les développeurs lors du développement d'une application et peut entraîner leur divulgation. Ce document technique explique les risques liés au codage en dur des données sensibles et décrit les mesures que vous pouvez prendre pour les éviter.

Introduction

Ce document technique vous explique, en tant que développeur, comment éviter de coder en dur les informations d'identification afin de gagner du temps lors du lancement ou de la publication de nouvelles fonctionnalités et, par conséquent, d'éviter de créer une faille de sécurité. Il fournit également des conseils sur les bonnes pratiques telles que la protection par couches, la rotation des clés de chiffrement et l'utilisation de référentiels de code privés au lieu de référentiels publics.

Exigences relatives à la politique de protection des données (PPD)

L'une des politiques que vous avez acceptées lors du démarrage du processus de développement d'un service pour l'Appstore des partenaires de vente est la Politique de protection des données d'Amazon Seller Central. Dans le Secure Coding Practices section, le DPP déclare :

Les développeurs ne doivent pas coder en dur les informations d'identification sensibles dans leur code, y compris les clés de chiffrement, les clés d'accès secrètes ou les mots de passe. Les informations d'identification sensibles ne doivent pas être exposées dans des référentiels de code publics. Les développeurs doivent gérer des environnements de test et de production distincts.

Processus de développement de logiciels

Prises dans l'urgence lors du lancement d'un nouveau produit, les organisations peuvent se risquer à prendre des raccourcis, notamment par le codage en dur d'informations d'identification sensibles. Celui-ci consiste à enregistrer des informations d'identification en dehors d'un systèmes de stockage sécurisé, notamment le code source, les wikis, la documentation, les feuilles de calcul et les fichiers de configuration. Informations d'identification est le terme utilisé dans ce document technique pour désigner les mots de passe, les numéros d'identification personnels (PIN), les clés Secure Shell (SSH), les clés de chiffrement et de déchiffrement et les clés ou jetons d'accès secrets Amazon SP-API.

Voici un exemple d'informations d'identification codées en dur :

{ "AssumedRoleUser":
  {
    "AssumedRoleId": "AROAIEGLQIIQUSJ2I5XRM:s3-access",
    "Arn": "arn:aws:sts:AWS-ACCOUNT-NUMBER:assumed-role/s3-read/s3-access"
  },
  "Credentials": {
    "SecretAccessKey":"wZJph6PX3snOZU4g6yfXdkyXp5m+nwkEtdUHwC3w",
    "SessionToken": "FQoGZXIvYXdzENr/////////REST-OF-TOKEN",
    "Expiration":"2018-11-O2T16:46:23Z",
    "AccessKeyId":"ASIAXQZXUENECYQBAAQG"
  }
}

Bien que le codage en dur des informations d'identification puisse sembler être une option lors du processus de développement, cette méthode induit des risques importants pour vos applications. En effet, si un acteur malveillant parvient à accéder à votre base de code, il peut facilement accéder à vos informations d'identification. L'acteur malveillant peut alors contrôler toutes les ressources auxquelles les informations d'identification sont autorisées à accéder.

Par exemple, si un acteur malveillant trouve vos informations d'identification Amazon SP-API, il peut effectuer des appels d'API en votre nom à votre insu et sans votre autorisation. Il est possible que vous n'appreniez jamais qu'un attaquant utilise vos informations d'identification, car il est difficile de déterminer si un accès est légitime ou non.

Plutôt que de coder en dur les informations d'identification, les développeurs devraient stocker les informations d'identification dans un système de stockage sécurisé, tel que AWS Secrets Manager. Votre application peut ensuite appeler ce système de stockage pour récupérer les informations d'identification nécessaires au besoin uniquement.

Applications API partenaire de vente

Pour les développeurs avec API pour les partenaires de vente applications (SP-API), SP-API s'appuie sur Connectez-vous avec Amazon Codes d'autorisation (LWA), jetons d'accès et jetons d'actualisation.

Les développeurs doivent protéger ces informations d'identification en conséquence, car les risques et les mesures d'atténuation décrits dans ce document technique s'appliquent à eux.

Les protections d'Amazon

Amazon analyse en permanence Internet pour détecter si des informations d'identification sensibles sont accessibles au public. Lorsqu'Amazon trouve des clés sur Internet, l'équipe chargée de la sécurité de l'information fait pivoter les clés pour éliminer le risque et empêcher les acteurs malveillants de prendre le contrôle de l'application. Amazon en informe ensuite le propriétaire de la clé.

Les clés ayant été divulguées au public, Amazon part du principe qu'une personne non autorisée y a accès, ce qui met en danger les propriétaires d'applications Amazon SP-API. Malheureusement, après rotation des clés, le propriétaire d'une application ne peut plus la contrôler.

Bien que ce processus contribue à protéger les applications Amazon SP-API, il entraîne des interruptions majeures pour les propriétaires d'applications et leurs clients. En général, les développeurs Amazon SP-API ne se rendent pas compte qu'Amazon a effectué une rotation de leurs clés et perdent un temps précieux à rechercher la cause première de ces interruptions. Un développeur peut mettre des jours à se rendre compte qu'Amazon a modifié les clés et à contacter Amazon via un dossier d'assistance.

C'est le seul mécanisme dont dispose Amazon pour protéger vos informations d'identification. Si un autre identifiant, tel qu'une clé de déchiffrement, était divulgué, Amazon ne serait pas en mesure de désactiver ou de modifier cette clé. Un attaquant aurait alors le pouvoir de déchiffrer vos informations sensibles, à l'insu d'Amazon ou de votre développeur.

La meilleure façon d'éviter le stress de telles interruptions de votre activité est d'éviter de coder en dur vos informations d'identification.

Bonnes pratiques de gestion des informations d'identification

Les sections suivantes présentent les bonnes pratiques de gestion des informations d'identification.

Protection par couches

Les informations d'identification doivent être protégées dans un système de stockage sécurisé. Un système de stockage d'informations d'identification aide les utilisateurs à protéger les informations secrètes nécessaires pour accéder aux applications, aux services et aux ressources informatiques. L'utilisation de ce type de système permet aux utilisateurs de disposer d'un référentiel unique pour toutes les informations secrètes, ce qui facilite la gestion de leur protection, de leur rotation et de leur utilisation dans les applications, les services et les autres ressources protégées.

Étant donné qu'un seul système de stockage d'informations d'identification peut stocker toutes vos informations secrètes, il est impératif qu'il soit protégé. Pour ce faire, limitez l'accès aux seules personnes et ressources qui en ont besoin. Vous devrez également en chiffrer le contenu à l'aide d'algorithmes de chiffrement puissants et mettre en place une journalisation, une surveillance et un système d'alertes robustes qui permettront une réponse rapide aux incidents.

Rotation des clés

Une bonne pratique consiste à partir du principe que vos informations d'identification finiront par être exposées. Atténuez ce risque supposé en établissant un calendrier de rotation des clés. La planification de la rotation des clés réduit la période pendant laquelle des informations d'identification compromises peuvent être utilisées par des utilisateurs non autorisés. La rotation des clés est généralement déclenchée par des actions spécifiques, par exemple lorsque le propriétaire d'une clé renonce à son rôle basé sur le “besoin de savoir”, ou en fonction de la durée pendant laquelle une clé est en service. Amazon recommande une rotation automatique des clés au moins tous les 180 jours.

Gestion de référentiels de code privés

Un référentiel public expose votre code au monde entier, le mettant à la disposition des concurrents comme des attaquants. Vous courez alors un risque majeur d'exposition des activités normales de votre entreprise. C'est pourquoi Amazon recommande, en plus de suivre les recommandations de ce document technique, de veiller à ce que vos référentiels restent privés.

Vous pouvez contribuer à protéger les informations d'identification et les actifs sensibles en maintenant des référentiels de code privés. Notez toutefois qu'un référentiel privé ne protège pas complètement vos informations d'identification et ne remplace pas le respect des recommandations de ce document technique.

Si vous êtes un développeur et que vous utilisez GitHub comme principal service d'hébergement de référentiel de code, vous devez vous référer à la section Configuration de la visibilité des référentiels dans la documentation de GitHub pour savoir comment maintenir vos référentiels privés. Vous devriez également envisager de tirer parti des fonctionnalités intégrées de ces services, notamment l'analyse automatique du code pour détecter les informations d'identification et le chiffrement des informations secrètes en mode natif.

Conseils pour les clients d'Amazon Web Services (AWS)

Bien que ces conseils soient dédiés aux problèmes rencontrés par les clients d'AWS, les clients d'autres fournisseurs de cloud ou les développeurs disposant d'un environnement sur site peuvent également tirer parti de services équivalents pour atteindre le même objectif.

Les développeurs peuvent tirer parti des rôles AWS IAM pour réduire les efforts liés aux processus d'authentification et de contrôle. Cependant, certains services et applications nécessitent des informations d'identification à durée de vie plus longue, notamment les clés API, les bases de données de mots de passe et les clés SSH, qui ne doivent pas être codées en dur dans le code source de l'application.

AWS Secrets Manager vous aide à gérer, récupérer et modifier régulièrement les informations d'identification de bases de données, les clés d'API et d'autres informations secrètes tout au long de leur cycle de vie. Pour consulter un scénario d'utilisation de base d'AWS Secrets Manager, des tutoriels et des guides, reportez-vous à la Documentation sur AWS Secrets Manager. Pour éviter de coder les informations d'identification en dur, les développeurs peuvent configurer Secrets Manager afin que les utilisateurs et les services puissent récupérer les informations d'identification via des appels d'API Secrets Manager.

Pour gagner en efficacité, il est recommandé d'apprendre à utiliser les rôles AWS IAM pour les applications exécutées sur EC2. Vous devez également apprendre à fournir en toute sécurité des informations d'identification aux fonctions AWS Lambda avec Secrets Manager.

Conclusion

En suivant les bonnes pratiques décrites dans ce document technique, telles que la protection par couches, la rotation des clés de chiffrement et l'utilisation de référentiels de code privés au lieu de référentiels publics, vous pouvez garantir la sécurité de vos données et de vos applications. Ne sacrifiez pas la sécurité au nom de la rapidité, car il est préférable de disposer d'un cycle de vie de développement logiciel robuste qui donne à la sécurité la priorité absolue pour garantir le lancement d'un produit sûr dans les délais.

Lectures complémentaires

Pour plus d'informations, consultez les sections suivantes :

• Politique de protection des données
• Politique d'utilisation acceptable
• Bonnes pratiques en matière de sécurité, d'identité et de conformité
• Configuration de la visibilité des référentiels
• Stockage, distribution et rotation des informations d'identification en toute sécurité
• Les 10 principales précautions de sécurité à améliorer dans votre compte AWS

Historique du document

Remarques

Les vendeurs et les développeurs Amazon sont tenus de procéder à leur propre évaluation indépendante des informations contenues dans ce document. Ce document : (a) est fourni à titre informatif uniquement, (b) représente les pratiques actuelles, susceptibles d'être modifiées sans préavis, et (c) ne crée aucun engagement ni aucune garantie de la part d'Amazon.com Services LLC (Amazon) et de ses filiales, fournisseurs ou concédants de licence. Les produits ou services de l'API Amazon Services sont fournis « tels quels » sans garantie, déclaration ou condition d'aucune sorte, qu'elle soit expresse ou implicite. Les responsabilités et obligations d'Amazon concernant l'API Amazon Services sont régies par les contrats d'API Amazon Services (y compris le contrat Amazon Services API Developer Agreement ou le Amazon Services Business Solutions Agreement), et ce document ne fait partie d'aucun contrat entre Amazon et une quelconque partie et ne le modifie pas.

© 2022 Amazon.com Services LLC ou ses filiales. Tous droits réservés.