Quand est-il approprié pour les connexions SSL Encrypt Database?
Disons que j'ai un serveur Web que j'ai configuré, puis un serveur de base de données.
Cependant, ils communiquent localement et sont derrière le pare-feu. À mon avis, aucun SSL n'est nécessaire ici, non?
Le seul moment pour utiliser SSL pour crypter la connexion à la base de données serait entre un serveur Web qui existe dans un serveur qui communique à distance avec un serveur de base de données situé ailleurs, non?
J'ai déjà vu des directives en matière de sécurité qui préconisaient de sécuriser avec SSL la connexion à la base de données, mais on ne savait pas quand l'utiliser.
Il semble que les deux réponses précédentes à cette question recommandent plus ou moins fortement d'activer SSL de toute façon, mais je voudrais suggérer un angle de raisonnement différent (bien que je ne recommande pas de ne pas activer SSL).
Les deux points clés pour évaluer si vous avez besoin de SSL ou non sont (a) contre quoi SSL vous protège et (b) contre quel modèle de thread: énumérer les menaces potentielles.
SSL/TLS protège le transport d'informations entre un client (dans ce cas, votre serveur Web) et un serveur (dans ce cas, votre serveur de base de données) contre la falsification et l'écoute par quiconque sur le réseau entre les deux (y compris en mesure d'accéder à ces deux machines).
Pour évaluer si SSL est utile, vous devez supposer que l'attaquant est en mesure d'effectuer l'attaque SSL est conçu pour vous protéger contre. Autrement dit, l'attaquant devrait être en mesure de renifler les paquets sur le réseau ou sur l'une ou l'autre des machines.
Si quelqu'un est en mesure de renifler des paquets à partir du serveur de base de données, il aura probablement un accès root/administrateur à ce serveur. L'utilisation de SSL/TLS à ce stade ne fera aucune différence.
Si quelqu'un est en mesure de renifler des paquets sur le réseau entre le serveur Web et le serveur de base de données (à l'exclusion de ces machines), l'utilisation de SSL/TLS les empêchera de voir/modifier le contenu de l'application. Si vous pensez que cela est possible, activez SSL. Un moyen d'atténuer ce problème serait d'utiliser deux cartes réseau sur le serveur Web: une pour le monde extérieur et une pour le LAN intérieur où se trouve le serveur de base de données (sans autres machines, ou d'une manière que vous pourriez toutes traiter comme une seule machine plus grande). Ce réseau formant la ferme ou le cluster Web global (comme vous voulez l'appeler) serait physiquement séparé et n'aurait qu'un seul point d'entrée de l'extérieur: le serveur Web lui-même (même principe pour un nœud principal de proxy inverse).
Si quelqu'un est en mesure de renifler des paquets sur le nœud principal (le serveur Web) lui-même, il est susceptible d'y avoir un accès root (les processus exécutés par des utilisateurs non root sur la machine, ne devraient pas être en mesure de lire les paquets qui ne sont pas pour eux). Dans ce cas, vous auriez quand même un gros problème.
Ce dont je doute ici, c'est de savoir si l'activation de SSL vous protège réellement dans ce scénario.
Une personne disposant d'un accès root sur le serveur Web pourra lire la configuration de votre application, y compris les mots de passe DB, et devrait pouvoir se connecter au serveur DB légitimement, même en utilisant SSL.
En contrepartie, si vous supposiez que cela justifie l'utilisation de SSL (car il pourrait être plus difficile d'examiner ce que font réellement les processus plutôt que de simplement regarder le réseau, même si vous avez le contrôle root sur la machine), cela signifierait vous pouvez également opter pour les communications avec l'hôte local (par exemple, si vous avez d'autres services sur votre serveur Web, ou dans le cas où le serveur DB et le serveur Web étaient sur la même machine).
Ce n'est pas nécessairement une mauvaise chose d'être trop prudent, mais vous devez placer votre question dans le contexte de ce que les attaquants pourraient également faire s'ils étaient en mesure de lancer une attaque contre ce contre quoi la mesure de sécurité (SSL) vous protège, et si cette mesure de sécurité les empêcherait de toute façon d'atteindre leur objectif, une fois dans cette position.
Je pense que la fenêtre est en fait assez étroite là-bas (en supposant que votre réseau principal est vraiment sécurisé, physiquement, pas seulement par un pare-feu parmi un certain nombre de machines).
Lorsque le réseau local qui inclut le serveur de base de données et les clients peut inclure d'autres processus, vous devez chiffrer la connexion entre les deux.
C'est presque toujours le cas car, même si vous supposez que le réseau local est impénétrable (vous ne devriez pas), outre le client et le serveur de base de données, il y a généralement
- les administrateurs qui doivent pouvoir se connecter et résoudre les problèmes ou effectuer des mises à jour
- collecteurs de journaux qui doivent récupérer des fichiers sans données sensibles et les déplacer ailleurs
- réplicateurs qui doivent copier le contenu de la base de données pour une sauvegarde hors site ou pour alimenter de grandes tables à faible sensibilité vers les systèmes d'exploration de données
- des moniteurs qui doivent vérifier si les autres sont encore en vie
Parmi ceux-ci, seuls les réplicateurs doivent avoir accès aux tables contenant des données sensibles, mais l'un de ces processus peut être compromis par de mauvais acteurs au sein de votre service informatique.
Le chiffrement de tous les canaux qui transportent des données sensibles permet aux honnêtes gens d'être honnêtes, vous offre une défense en profondeur et vous aide à restreindre la recherche lorsque des problèmes surviennent.
Gardez à l'esprit que toute personne se trouvant sur le même réseau que votre serveur peut être en mesure de flairer le trafic ou de lancer une attaque de type intermédiaire. SSL devrait empêcher cela, en supposant qu'il est correctement configuré. Vous devez également configurer un pare-feu sur le serveur de base de données et autoriser uniquement les connexions à partir d'adresses IP approuvées.
Ma suggestion est de l'allumer, puis de l'éteindre seulement si vous pensez que cela cause des problèmes de performances (ou autres). De cette façon, vous avez considérablement réduit vos vecteurs d'attaque.
En réalité, la surcharge du cryptage SSL sur le réseau sera minime, surtout par rapport à la charge de traitement des requêtes SQL. Vous gagneriez plus de performances en optimisant vos requêtes et la configuration des performances du serveur qu'en désactivant SSL.
Disons que j'ai un serveur Web que j'ai configuré, puis un serveur de base de données ... communiquant localement et que je suis derrière un pare-feu
Laissant de côté le fait que cette architecture suce en termes de disponibilité ...
- faites-vous confiance à tout le monde "derrière le pare-feu"?
- croyez-vous que votre pare-feu est parfait?
- pouvez-vous prévoir que vous n'aurez jamais besoin de vous connecter à distance pour prendre en charge une disponibilité plus élevée, migrer votre centre de données ou effectuer une sauvegarde?
- le mécanisme d'authentification par défaut pour le dbms est-il si sûr qu'il ne peut pas être subverti?
- avez-vous un processus de déploiement qui garantit que les informations d'identification de la base de données ne peuvent pas être compromises?
Si votre réponse à l'une de ces questions n'est pas définitivement affirmative, vous pourriez bénéficier des assurances supplémentaires de l'utilisation d'une connexion SSL correctement configurée. Le coût des performances est négligeable même sans compter sur des connexions persistantes (bien que cela aussi puisse être pratiquement éliminé en acheminant le trafic via un tunnel persistant). Il s'agit simplement de déterminer si le coût de configuration du SSL (quelques heures de travail) est supérieur à la responsabilité.