Comment stocker les informations d'identification requises par une application?

Tout le monde dit que le stockage des informations d'identification dans le contrôle de version (git) est une mauvaise chose. Il doit donc y avoir d'autres façons de stocker les informations d'identification qui sont bien meilleures.

Une application doit recevoir des informations d'identification de quelque part pour utiliser les services dont elle dépend. Ces informations d'identification sont généralement stockées dans des fichiers de configuration. Il n'est pas question d'entrer manuellement chaque serveur pour créer ce fichier, car les serveurs vont et viennent sans intervention humaine.

Comment gérer les informations d'identification d'une application?

Une bonne gestion des secrets d'une application a toujours été un défi. L'adoption du cloud a posé de nouveaux défis. Il y a une excellente présentation de l' OWASP sur la réalité et les défis du stockage de secrets dans le cloud.

Vous pourriez être surpris d'apprendre que le stockage de secrets dans le code source est l'une des solutions (ou "architecture") présentée. C'est parce que, pour le moment, il n'y a pas d'architecture parfaite ou de moyen de le faire. Au final, vos secrets pourraient être cryptés ... mais qu'est-ce qui garde la clé de cryptage? "Des tortues jusqu'en bas", ont-ils dit.

Chaque type de gestion secrète a ses forces et ses faiblesses et la présentation couvre déjà cela. Au lieu de cela, je vais essayer de passer en revue certaines des fonctionnalités que vous recherchez peut-être dans une solution de gestion secrète (informations d'identification):

• Contrôle d'accès: pouvez-vous accorder un accès en écriture aux administrateurs et un accès en lecture aux applications? Pouvez-vous limiter les applications pouvant lire (l'application A n'a accès qu'à ces secrets)?
• Journaux d'audit: requis pour de nombreux rapports de conformité et un bon moyen de déterminer si quelque chose ne va pas
• Stockage sécurisé des secrets: comment la solution stocke-t-elle les secrets? DB chiffrée? FS crypté? Qui / quoi détient la clé de chiffrement, le cas échéant? Comment cette clé est-elle utilisée - une fois au démarrage puis jetée en toute sécurité?
• Rotation ou renouvellement des clés / mots de passe: si un secret est compromis, pouvez-vous le révoquer et envoyer un secret mis à jour aux applications? Les applications peuvent-elles / devraient-elles regrouper le service de gestion secrète?
• Compatibilité: Certaines de ces solutions offrent une intégration étroite avec certains langages ou framework. Certains offrent l'API REST. Ça vous intéresse?

En examinant ces éléments, en quoi ils sont importants pour vous et comment ils sont mis en œuvre par la solution, vous pourrez choisir l' un des services de gestion secrets disponibles .

Pour un environnement purement basé sur EC2, la solution la plus simple consiste à utiliser des rôles AWS IAM et des stratégies de compartiment S3. Certaines formulations de ce modèle incluent également KMS pour le chiffrement et DynamoDB au lieu de S3 pour le stockage, mais je n'ai pas trouvé de raison extrêmement convaincante d'utiliser non plus. Consultez https://github.com/poise/citadel , il est spécifiquement destiné aux utilisateurs de Chef mais le modèle sous-jacent fonctionne pour n'importe quoi, vous devrez peut-être créer votre propre assistant pour effectuer le téléchargement réel depuis S3.