Nous faisons une application à l'aide de PHP et en utilisant certains services tiers nécessitant une clé d'API secrete. Nous avons un fichier PHP contenant toutes ces définitions de clés que nous importatons ensuite (en utilisant requis_once) en cas de besoin.
Cette approche est-elle sûre? Devrions-nous stocker les clés dans un endroit différent?
merci.
4 Réponses :
Il doit être relativement sûr tant que le fichier n'est pas accessible depuis le Web. Beaucoup de sites vont placer des fichiers sensibles en dehors du Webroot sur le serveur et les inclure simplement en cas de besoin dans leur application.
Quelque chose de similaire a été demandé aujourd'hui pour un script shell. La réponse est valable ici également: assurez-vous de stocker le fichier en dehors de la racine Web ou (si cela n'est pas possible) le protège à l'aide d'un fichier J'aime aussi nonset () toute variables contenant des données sensibles Après utilisation, donc pas même un dépotoir variable complet (par exemple, dans un message de débogage) plus tard dans ce script pourrait le révéler. .htaccess .
+1 Pour désétablir les variables une fois qu'ils n'étaient pas nécessaires. Je fais cela avec mes mots de passe de base de données.
Maintenant que j'y pense, puis-je laisser les clés au même endroit (avec de meilleurs paramètres d'autorisation), mais la cryptant uniquement la clé de cryptage en dehors de la portée de la barroot. De cette façon, nous pourrions lire le fichier dans autant de machines que nous en avons besoin dès que nous les avons configurés avec notre clé? Merci encore.
@Diogo une idée très intéressante, mais vous devrez faire le déchiffrement sur chaque demande que vous servez - je ne sais pas si c'est une bonne idée de la performance. De plus, le gain de sécurité va probablement être trop petit par rapport au coût de la mise en œuvre. Néanmoins, idée intéressante.
J'ai toujours défini les autorisations de certificats et d'autres fichiers contenant des données sensibles telles que seule mon équipe de développement et le service Apache peut accéder au fichier. Ceci est important si vous utilisez un serveur partagé par une grande organisation, comme une université, où de nombreuses personnes pourraient avoir des autorisations au fichier par défaut. Souvent, j'ai vu des autorisations de lecture données à tout le monde afin que le serveur Web puisse accéder au fichier (puisqu'il n'est ni le propriétaire ni dans la permission du groupe pour le fichier, la seule chose qui reste est de donner la lecture à "Autre"). < / p>
Au lieu de cela, j'espère qu'il y ait un groupe contenant uniquement mon équipe de développement et définir les autorisations de lecture / écriture pour le fichier à ce groupe. J'utilise ensuite ACL pour ajouter une autorisation de lecture pour le service Apache. Vous devez utiliser une ACL car le propriétaire et le groupe sont normalement définis vers un groupe d'équipe de développeurs et de développement, ne vous laissant aucune option pour définir l'accès à Apache, à l'aide d'ACL.
+1 bons points pour travailler sur des serveurs partagés - il échappe souvent à l'esprit qu'un chmod 777 signifie que tous les voisins peuvent également accéder au fichier.
Maintenant que j'y pense, puis-je laisser les clés au même endroit (avec de meilleurs paramètres d'autorisation), mais la cryptant uniquement la clé de cryptage en dehors de la portée de la barroot. De cette façon, nous pourrions lire le fichier dans autant de machines que nous en avons besoin dès que nous les avons configurés avec notre clé? Merci.
Sécurité par Obfuscation:
php.ini à /usr/share/nginx/outidehtml/keystorage/83738489384828838227.php
- Run Nginx ou Apache à Chroot, Selinux
- Désactiver l'autorisation d'inscription au dossier KeyStorage
SETFACL -M Utilisateur: NGinx: x / USR / Share / NGinx / Wasthtml / KeyStorage /
- Ajouter
php.ini désactiver_class = réflexionFunction Disable_function = opcache_get_status, phpinfo, show_source, ini_get
- Pour mieux Harding, vous pouvez stocker la clé dans php.ini comme valeur I.E 123KEY = Secret64
test xxx