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


49

Je ne suis pas encore habitué à la façon dont fonctionne 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, il est plus probable que vous partagiez ce référentiel sur Github ou d'autres hôtes Git.

Certaines choses ne doivent 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 éléments doivent toujours faire partie du référentiel Git, car vous les utilisez pour transmettre votre code à 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 plus sur la façon de "cacher" des parties du code.


3
Je commencerais par utiliser un dépôt privé. Ensuite, en fonction de mon niveau de confiance, je pourrai .gitignore mes fichiers de configuration qui contiennent les données sensibles et les version uniquement localement. (Local étant un emplacement central non externe qui peut être un serveur interne ou qui sait)
Rig

Réponses:


30

La méthode préférée pour garder secrets les mots de passe / clés d’API sur heroku consiste à définir des valeurs de configuration via l’application en ligne de commande heroku. L'exemple suivant tiré d' un article du centre de développement de heroku

(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

Puis référencez ces valeurs de configuration dans votre code en utilisant 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 .bashrcfichier.

De plus, je ne suis pas sûr du type d'application que vous utilisez, mais dans Rails, heroku n'utilise pas votre fichier database.yml, il définit simplement le nom d'utilisateur / mot de passe de votre base de données en fonction des paramètres de votre application. Donc, vous pouvez éviter de sauvegarder ces informations d'identification dans git

De plus, si vous exécutez votre propre application et souhaitez la garder privée, une excellente alternative à github est bitbucket, qui offre des référentiels privés gratuits.


17

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

Obfuscation (pour le code seulement)

Pour les parties du code que vous souhaitez masquer, pouvez-vous les insérer dans un projet différent, les compiler et ne réintégrer que le code compilé, pas le code source? Ce n'est pas un cryptage et ne convient pas au cryptage de mots de passe ou de clés. Les utilisateurs peuvent toujours désosser leur code compilé, mais ils n’obtiennent pas le code source.

Dépôt GIT privé

Faut-il que ce soit un dépôt git public ?

Stockage sur serveur

Pouvez-vous stocker ces informations dans un fichier protégé dans le répertoire de base du compte d'utilisateur sous lequel l'application est exécutée? Je copierais la manière dont ssh fait cela avec ~ / .ssh / id_rsa et un chmod de 600. À défaut, une variable d'environnement pourrait être utilisée. Il vous faut quelque part sur le serveur pour stocker une sorte de clé, sinon vous ne pouvez rien protéger.

Cryptographie symétrique (juste pour vous)

Si vous êtes le seul développeur, vous pouvez placer une clé sur le serveur, disposer de la même clé sur votre machine et utiliser un schéma de chiffrement symétrique pour protéger certaines données, telles qu'un mot de passe ou un certificat. Partager 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 éléments secrets dans un référentiel git public, une cryptographie à clé publique / clé privée (asymétrique) a été créée pour ce genre de chose. Installez une clé privée sur votre serveur (ne la copiez pas dans le contrôle de source!) Et générez une clé publique à partir de celle-ci. Cryptez 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 vérifier la clé publique dans le contrôle de source afin que d'autres personnes puissent chiffrer des données à l'aide de la même clé publique et que seul le serveur puisse la 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 fichier de clés sécurisé sur le serveur sur lequel stocker la clé privée. cette. Peut-être ont-ils des indices sur la façon dont les autres résolvent le défi auquel vous êtes confrontés?


Pour ajouter, WRT au stockage côté serveur - Je ne sais pas si vous pouvez le faire avec Heroku, mais j'ai déjà vu des configurations dans lesquelles un script est lancé depuis le hook de post-réception et / ou quelque chose comme Capistrano sur le serveur de déploiement pour copiez le fichier de base de données de déploiement à l'emplacement correct. Cela vous permet de conserver complètement le fichier de base de données hors du référentiel et de disposer d'un mécanisme automatique pour garantir que ces informations sont toujours en place.
Shauna

Même les dépôts privés GIT devraient protéger les données sensibles. Juste au cas où cela deviendrait public par accident pendant un moment. De plus, je pense que le crypto asymétrique devrait toujours être utilisé, au lieu de symétrique. Je ne vois aucun inconvénient, mais uniquement cet avantage: vous pouvez même laisser des API quelque part pour faciliter le cryptage de nouvelles données sensibles à coder en dur.
Tiberiu-Ionuț Stan

7

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

Pour ce qui est des 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 un fork privé de votre projet aux fins de déploiement.


1
Merci, mais quel est le flux de travail pour cela?
Jonas

6

Vous ne devriez pas cacher des parties du code. La sécurité de votre système ne doit pas dépendre du secret du code; c'est ce qu'on appelle "la sécurité par l'obscurité", ce qui est mal vu par les experts en sécurité car cela fonctionne très mal.

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

Important: ne codez jamais de clé cryptographique, de mot 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 endroit idéal pour poser des questions sur la sécurité!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.