2016-09-17 1 views
0

Je crée une application Rails et j'essaie de comprendre la sécurité car elle implique des clés secrètes.Comprendre la sécurité et les clés secrètes

Mon projet utilise Rails 5 et la gemme Devise.

J'ai lu à plusieurs endroits que vous ne voulez pas mettre des fichiers comme secrets.yml sur github pour des raisons de sécurité (que j'ai découvert plusieurs commits sur la route). Cependant, mes clés secrètes utilisées en production sont des variables d'environnement (bien que mon développement et mes clés ne le soient pas, elles peuvent être vues). Ce que j'essaie de comprendre maintenant, c'est que c'est bien que des fichiers comme secrets.yml (j'ai aussi entendu des choses à propos de database.yml aussi), ont fini sur github, aussi longtemps que les bits importants (comme les clés secrètes) sont des variables d'environnement, que heureusement Rails semble avoir pensé par défaut? Ou devrais-je faire l'effort de supprimer ces fichiers?

Répondre

0

Si vous supprimez les informations sensibles (en les remplaçant par des variables d'environnement), vous pouvez valider le fichier. Ce n'est pas seulement secrets.yml. Les clés de chiffrement, les clés API et les informations d'identification ne doivent pas être validées dans Git.

Si vous avez déjà transmis ces informations à Git, vous pouvez les supprimer en effectuant une Rebase, mais cela ne garantit pas que chaque copie est supprimée. Il vaudrait mieux changer le secret. Cela impliquerait l'utilisation d'une variable d'environnement, en définissant la valeur existante dans l'environnement, puis en générant une nouvelle valeur pour le secret et en changeant la variable d'environnement à un certain point. La modification du secret invaliderait toutes les sessions utilisateur existantes, il est donc préférable d'informer les utilisateurs à l'avance et de le faire pendant le temps où le plus petit nombre d'utilisateurs utilisent le site.

Jusqu'à ce que vous changiez la valeur secrète, votre site est vulnérable.

+0

Comme je l'ai mentionné dans un autre commentaire, mon secrets.yml (et je crois que les autres fichiers importants ainsi), ressemble essentiellement à ce que j'ai énuméré à la fin de ce commentaire. D'après ce que je comprends de votre réponse, il semble que je devrais être sûr, et il est bon en général de pousser des informations comme secrets.yml tant que la production secret_key_base est une variable d'environnement? C'est ce que mes secrets.yml ressemble à >>> développement: secret_key_base: abc123youcanseethiskey test: secret_key_base: 123456ghgyoucanseethiskey production: secret_key_base: <% = ENV ["SECRET_KEY_BASE"]%> – mc92

+0

Cela ne contient pas le secret de production réel. Les clés de développement et de test ne sont pas des informations sensibles. Donc, pas besoin de s'inquiéter de ce fichier, il est destiné à être vérifié dans Git comme ça .. –

0

« Ce que je suis en train de comprendre maintenant, est-ce est-il bien que les fichiers comme secrets.yml (j'ai aussi entendu certaines choses sur database.yml aussi bien), ont fini sur GitHub, »

N'entrez jamais d'informations personnelles/sensibles dans vos dépôts Github.

Peu importe le nom du fichier; Si elle contient des informations sensibles, ne poussez pas sur votre repo distant.

+0

Il a déjà été poussé, ce que je demande est si je devrais faire l'effort de l'enlever après qu'il ait été là-haut à travers plusieurs commits. Il (secrets.yml) ressemble essentiellement à ceci: développement: secret_key_base: abc123youcanseethiskey test: secret_key_base: 123456ghgyoucanseethiskey production: secret_key_base: <% = ENV [ "SECRET_KEY_BASE"]%> Ce que je suis en essayant de donner un sens à, est-ce que cette façon particulière est assez sûre, ce que votre réponse ne m'a pas fait comprendre. – mc92

+0

Si vous l'avez déjà commise, je changerais mes clés dès que possible. Vous pouvez également rebaser mais vos clés peuvent déjà avoir été grattées. – hetre85