Avant de décider de ces questions de sécurité, vous devez évaluer le modèle de menace. Sans idée de ce contre quoi vous vous défendez, toutes les mesures que vous prendrez auront probablement peu de valeur.
Maintenant, vous pouvez vous préoccuper de certaines choses dans ce contexte:
- Les attaquants obtenant un accès physique à vos données (par exemple, pénétrer dans le centre de données, voler des bandes de sauvegarde, etc.)
- Les attaquants obtiennent un accès en lecture à votre base de données brute
- Les attaquants compromettant votre application, par exemple par injection SQL, dépassements de mémoire tampon, etc.
Pour le premier scénario, le stockage de la base de données et de toutes les sauvegardes sur des volumes chiffrés devrait fonctionner, à condition que le serveur soit sans tête - le vol du serveur ou des bandes nécessiterait alors de casser le chiffrement au niveau du disque.
Pour le deuxième scénario, le chiffrement des données de la base de données est utile, mais uniquement si vous ne stockez nulle part les clés ou les mots de passe requis.
Dans le troisième scénario, tout dépend du contexte dans lequel l'attaque se produit: s'il s'agit, par exemple, d'une attaque XSS ou CSRF, alors un attaquant peut faire tout ce que l'utilisateur légitime peut faire, et le cryptage de vos données n'aide en rien .
Votre modèle de menace est donc un attaquant qui obtient un accès en lecture à la base de données brute, soit en trouvant les informations de connexion et en réussissant à se connecter au serveur de base de données de l'extérieur, soit en obtenant un accès root au serveur de base de données. Un chemin typique consiste à obtenir d'abord un accès shell sur le serveur Web; à partir de là, un attaquant peut alors lire les informations d'identification d'accès à partir du fichier de configuration et se connecter à la base de données.
Une autre considération est l'endroit où vous conservez les clés et les phrases secrètes, surtout si vous utilisez une plate-forme avec un modèle d'exécution sans état tel que PHP. Idéalement, vous demandez au client de taper sa phrase secrète si nécessaire, et de la conserver uniquement en mémoire, ou mieux, de faire le déchiffrement côté client (mais ce n'est pas souvent faisable). Sur une plate-forme sans état, l'état est généralement effectué à l'aide de sessions, de memcache, de bases de données ou de fichiers plats; mais tous ces éléments sont bien plus vulnérables que de conserver l'état dans la mémoire d'une application Web avec état. Éviter cela est un problème de poule et d'oeuf, car si vous cryptez l'état avant de le persister, vous venez de créer un autre secret dont vous devez vous souvenir en toute sécurité. Se souvenir de la phrase secrète sur le client et l'envoyer avec chaque demande qui en a besoin peut être la solution la moins horrible alors;