Comment crypter les informations de connexion à la base de données sur un serveur Web?
OWASP déconseille de stocker les informations d'identification de la base de données en texte brut:
https://www.owasp.org/index.php/Password_in_Configuration_File
Cependant, ils ne fournissent pas de suggestions sur la façon de crypter les informations d'identification d'accès à la base de données, où stocker les clés, comment gérer l'accès aux clés, etc.
Quelqu'un a-t-il une expérience concrète de la mise en œuvre d'une telle solution qui peut suggérer une architecture sur une pile LAMP (Ubuntu 10, PHP 5.3)?
PS - Je ne cherche pas de réponses du type "ne vous embêtez pas - si quelqu'un obtient un accès root, il est trop tard", etc.
Les autres réponses ici sont toutes correctes sous deux aspects clés. Le fichier contenant votre chaîne de connexion ne doit pas être conservé dans un emplacement lisible par tout le monde et, comme vous le constatez, vous ne pouvez pas empêcher quelqu'un d'accéder à la clé s'il a compromis votre serveur. Néanmoins, il existe d'autres raisons de crypter la clé (ou le fichier). Une des raisons pour lesquelles l'OWASP recommande de ne pas stocker en texte clair est d'empêcher la divulgation accidentelle des informations d'identification à ceux qui n'en ont pas besoin.
Alors que beaucoup font valoir que le chiffrement de la chaîne de connexion sur le système en cours d'exécution fournit peu de valeur réelle (sécurité par obscurité), cela est vrai principalement dans le contexte du système en direct. En supposant une configuration LAMP traditionnelle, les autorisations basées sur les fichiers empêcheraient la lecture de tout utilisateur autre que l'utilisateur de script sous lequel le processus php/Apache est exécuté. Le fait d'avoir le fichier en dehors de l'emplacement racine fournit un peu plus de sécurité potentielle (en cas de gestionnaires MIME mal configurés ou .htaccess) mais n'est pas strictement nécessaire.
La plus grande valeur dans la séparation des paramètres de connexion est que les détails et les données d'authentification n'ont plus besoin d'être remis aux développeurs/testeurs ou à d'autres personnes qui peuvent avoir un réel besoin de se connecter au serveur. En gardant les détails de connexion hors du contrôle de la source et hors de la distribution générale, vous réduisez la possibilité de perte ou de fuite.
Un deuxième avantage est la distribution et la sauvegarde de la source. Une meilleure pratique serait certainement de ne transférer que les fichiers contenant des informations sensibles de connexion et de compte chiffrés eux-mêmes, mais pour de nombreuses raisons, ce n'est pas toujours pratique. Pour cette raison, si le cryptage est utilisé, séparer la clé de la chaîne de connexion et séparer la chaîne de connexion de la source est une action essentielle. Cela a séparé les fonctions et la protection des clés de chiffrement (ou des fichiers de configuration) et devient une fonction d'administrateur système plutôt qu'une fonction de développeur.
Cela à l'écart, dans Apache/php, vous avez un certain nombre d'options.
1.) Ne mettez pas du tout la chaîne de connexion dans le code php. Vous pouvez mettre ces valeurs dans votre httpd.conf Ou fichier d'hôtes virtuels. La connexion ne nécessite alors aucun paramètre lors de l'utilisation de mysql_connect() ... une utilisation plus détaillée est disponible ici: http://www.php.net/manual/en/class.mysqli.php
2.) Incluez le fichier de configuration configfile.php comme d'habitude, mais déplacez le fichier de connexion hors de webroot si vous le pouvez, et cryptez le fichier lui-même. Le déchiffrement du système d'exploitation peut être configuré par le SA pour le processus qui accédera au fichier. Utilisez alternativement si vous ne pouvez pas déplacer le fichier hors de la racine Web (hébergement partagé), sécurisez le fichier avec .htaccess
<files configfile>
order allow,deny
deny from all
</files>
Pour Microsoft IIS avec ASP.NET, la chaîne de connexion est stockée dans le fichier application.config ou web.config et le chiffrement utilisé peut être soit une clé machine statique, stockée dans l'un de ces fichiers , ou une clé générée par IIS lui-même - qui n'est pas stockée dans un emplacement accessible. Des détails sont disponibles sur MSDN, avec lequel je ne jetterai pas cette réponse car votre question était spécifique à LAMP.
Je dois également noter que, lorsque cela est possible, ma préférence est d'éviter complètement le problème en utilisant l'authentification intégrée. Le mappage de l'utilisateur du système d'exploitation à un utilisateur db extrait presque complètement les exigences de protection du contexte de cette question.
J'ai très peu d'expérience avec cela, mais je vous ai toujours entendu le laisser en clair (quel est l'intérêt de chiffrer si la clé est juste là de toute façon) et laisser les informations d'identification dans un fichier inclus, puis mettre un contrôle d'accès très strict sur ce fichier .
d'après mon expérience avec le web ... il y a plusieurs façons de faire les choses ... et peu de façons de bien faire les choses.
(de mon téléphone excusez ma brièveté)
Il est peu utile de chiffrer le mot de passe de votre base de données. Dans le cas de PHP vous avez même besoin que le code cryptographique s'exécute sur chaque demande - c'est juste une perte de temps CPU. En plus de cela, il y a tout un tas d'autres raisons pour lesquelles ce n'est pas une bonne idée:
- Votre application doit décrypter les données. Étant donné que dans PHP les fichiers de configuration sont très probablement PHP, également, une personne ayant accès au fichier de configuration a également probablement accès au fichier contenant le code de déchiffrement). /clé.
- Perte de temps CPU pour décrypter le mot de passe.
- Si la base de données est correctement configurée, le mot de passe ne vous donne aucun avantage - l'accès doit être limité à l'hôte local (ou à tout hôte sur lequel le serveur Web s'exécute) et dans le cas où des outils tels que phpMyAdmin sont sur le serveur, ils doivent être protégés par un autre mot de passe. En fait, en cas de par ex. PostgreSQL s'exécutant localement, vous n'aurez peut-être pas besoin du tout d'un mot de passe car vous pouvez simplement accorder à un utilisateur système l'accès à une certaine base de données - donc si votre code PHP s'exécute en tant qu'utilisateur, vous évitez de stocker any mot de passe pour la base de données.
Alors .. qu'est-ce que pouvez que vous faites qui a du sens? Assez simple, ne placez pas plus de fichiers à la racine du document que nécessaire. Étant donné que les bonnes applications utilisent généralement des URL propres routées via un seul fichier .php, ne placez ce fichier qu'à la racine du document. Tout le reste - c'est-à-dire que l'autre code d'application, les fichiers de configuration, etc. doivent être en dehors de la racine du document. De cette façon, une mauvaise configuration du serveur (par exemple le moteur PHP étant désactivé et envoyant ainsi du code simple à l'utilisateur) ne donnera à l'utilisateur l'accès qu'à un seul PHP qui ne contient probablement pas beaucoup plus qu'un appel require et un appel de fonction.
Assurez-vous également que vos fichiers ne sont pas accessibles en écriture/en lecture universelle (surtout lorsque vous devez utiliser l'hébergement partagé). Avec un serveur correctement configuré (php ne fonctionnant pas en tant que www-data ou un utilisateur similaire mais votre utilisateur), vous pouvez complètement désactiver l'accès "monde" et éventuellement "groupe" à vos fichiers.