web-dev-qa-db-fra.com

Comment gère-t-on les données sensibles lors de l'utilisation de Github et Heroku?

Je ne suis pas encore habitué au fonctionnement de Git (et je me demande si quelqu'un d'autre que Linus l'est;)).

Si vous utilisez Heroku pour héberger votre application, vous devez faire vérifier votre code dans un dépôt Git. Si vous travaillez sur un projet open-source, vous allez probablement partager ce dépôt sur Github ou d'autres hôtes Git.

Certaines choses ne devraient pas être vérifiées dans le dépôt public; mots de passe de base de données, clés API, certificats, etc ... Mais ces choses doivent toujours faire partie du dépôt Git puisque vous l'utilisez pour pousser votre code vers Heroku.

Comment travailler avec ce cas d'utilisation?

Remarque: je sais que Heroku ou PHPFog peuvent utiliser des variables de serveur pour contourner ce problème. Ma question porte davantage sur la façon de "masquer" des parties du code.

50
Jonas

La méthode préférée pour garder les mots de passe/clés API secrètes sur heroku est de définir des valeurs de configuration via l'application de ligne de commande heroku. L'exemple suivant tiré de n article du centre de développement Herok

(L'exemple ci-dessous et toute ma réponse concernent les applications Rails)

$ cd myapp
$ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars and restarting myapp... done, v14
S3_KEY:     8N029N81
S3_SECRET:  9s83109d3+583493190

Référencez ensuite ces valeurs de configuration dans votre code à l'aide de la variable ENV []

AWS::S3::Base.establish_connection!(
  :access_key_id     => ENV['S3_KEY'],
  :secret_access_key => ENV['S3_SECRET']
)

De cette façon, vos mots de passe sensibles ne sont pas stockés dans le référentiel git. (Remarque: lorsque vous exécutez l'application localement, définissez ces valeurs dans votre .bashrc fichier

De plus, je ne sais pas quel type d'application vous exécutez, mais dans Rails, heroku n'utilise pas votre fichier database.yml, il définit simplement votre nom d'utilisateur/mot de passe de base de données en fonction des paramètres de votre application. Vous pouvez donc éviter d'enregistrer ces informations d'identification dans git

De plus, si vous exécutez votre propre application et que vous souhaitez qu'elle reste privée, une excellente alternative à github est bitbucket qui propose des référentiels privés gratuits.

30
Mike Vormwald

Plusieurs idées ... La cryptographie à clé publique est la réponse la plus flexible.

Obfuscation (pour le code uniquement)

Pour les parties du code que vous souhaitez masquer, pourriez-vous les placer dans un autre projet, les compiler et archiver uniquement le code compilé, pas la source? Il s'agit du cryptage not et not adapté au cryptage des mots de passe ou des clés. Les gens peuvent toujours effectuer une rétro-ingénierie de votre code compilé, mais ils n'obtiennent pas la source.

Dépôt GIT privé

Doit-il s'agir d'un référentiel public git?

Stockage serveur

Pouvez-vous stocker ces informations dans un fichier protégé dans le répertoire personnel du compte utilisateur sous lequel l'application s'exécute? Je copierais la façon dont ssh le fait avec ~/.ssh/id_rsa et un chmod de 600. A défaut, une variable d'environnement pourrait être utilisée. Vous avez besoin d'un emplacement sur le serveur pour stocker une sorte de clé, ou vous ne pouvez rien protéger.

Cryptographie symétrique (juste pour vous)

Si vous êtes le seul développeur, vous pouvez mettre une clé sur le serveur et avoir cette même clé sur votre machine et utiliser un schéma de cryptage symétrique pour protéger certaines données comme un mot de passe ou un certificat. Le partage d'une clé symétrique avec des amis devient compliqué.

Cryptographie asymétrique (pour plusieurs développeurs)

Si d'autres développeurs ont besoin de vérifier des choses secrètes dans un référentiel git public, une cryptographie à clé publique/clé privée (asymétrique) a été faite pour ce genre de chose. Installez une clé privée sur votre serveur (ne la vérifiez pas dans le contrôle de code source!) Et générez-en une clé publique. Chiffrez vos données secrètes à l'aide de la clé publique du serveur. Seul le serveur peut déchiffrer ces données à l'aide de sa clé privée. Vous pouvez même archiver la clé publique dans le contrôle de code source afin que d'autres personnes puissent chiffrer les données à l'aide de la même clé publique et que seul le serveur puisse les déchiffrer.

Outil

Openssl est probablement le seul outil de cryptographie dont vous aurez besoin. N'écrivez pas votre propre algorithme de cryptographie ou votre propre implémentation d'un algorithme publié.

Pensées de clôture

Si le "serveur" est un serveur Web qui utilise https, vous devriez déjà avoir un magasin de clés sécurisé sur le serveur pour stocker la clé privée. C'est assez époustouflant qu'une société d'hébergement ne prenne pas en compte cette. Peut-être ont-ils des indices sur la façon dont les autres résolvent le défi auquel vous êtes confronté?

17
GlenPeterson

Si vous voulez exécuter votre code sur Heroku, vous devez le leur donner - vous ne pouvez pas le garder "secret" de votre hébergeur.

En ce qui concerne les référentiels git publics, si votre projet est open source mais que vous ne souhaitez pas partager les détails de l'hébergement, vous devez conserver une branche privée de votre projet à des fins de déploiement.

7
Richard Nichols

Vous ne devez pas masquer des parties du code. La sécurité de votre système ne doit pas reposer sur le secret du code; c'est ce qu'on appelle la "sécurité par l'obscurité", qui est mal vu par les experts en sécurité car il fonctionne très mal.

Au lieu de cela, les mots de passe, les clés de chiffrement, etc. doivent être séparés du code. Stockez-les dans un fichier de configuration distinct ou une valeur de configuration qui est lue par le code. Vous n'avez pas besoin de les stocker dans git.

Important: Ne codez jamais en dur des clés cryptographiques, des mots de passe ou d'autres secrets dans votre code source! C'est une très mauvaise pratique.

Voir également:

Plug: IT Security.SE est un excellent endroit pour poser des questions sur la sécurité!

6
D.W.