La protection par mot de passe d'une base de données située à côté de l'application ajoute-t-elle une sécurité?
J'ai vu des configurations où une base de données protégée par mot de passe résidait sur le même serveur qu'une application contenant les informations d'identification de ladite base de données en texte brut.
Quels sont les avantages d'une telle configuration sur une base de données simplement non protégée?
En dehors de certains brouillages, le fait de devoir configurer à la fois la base de données et l'application à ces informations d'identification semble seulement ajouter de la complexité, mais pas une réelle sécurité. Un attaquant ayant accès au serveur pourrait toujours simplement trouver les informations d'identification dans le fichier de configuration de l'application.
Edit: Je parle d'une base de données uniquement visible sur la même machine, et non exposée à l'extérieur.
Il est judicieux de protéger par mot de passe la base de données si vous sécurisez l'accès au fichier de configuration de l'application qui contient les informations d'identification en texte brut. Lorsque vous limitez l'accès en lecture au compte de l'application uniquement, l'attaquant nécessite un accès root pour voir le mot de passe. En cas de violation d'un autre compte (moins privilégié), il ne pourra pas accéder à la base de données.
C'est une sorte de protection oignon (également connue sous le nom de " Sécurité en couches "ou" Défense en profondeur "comme on le voit, par exemple, dans SANS '" Sécurité en couches : Pourquoi ça marche "livre blanc). Si un attaquant peut atteindre la ou les machines, il ne peut pas obtenir un accès complet à la base de données. L'application doit avoir un accès restreint limité aux seules tables requises, et tout ce qui n'a pas besoin d'être écrit doit être en lecture seule. Tout accès supérieur doit nécessiter un mot de passe différent jamais utilisé dans l'application.
L'avantage est qu'un attaquant disposant d'un accès réseau à la base de données mais pas d'un accès du système de fichiers au serveur ne pourra pas réellement se connecter à la base de données.
Avantages de la protection par mot de passe de la base de données
S'il n'est pas possible de l'utiliser de manière non sûre, cela réduit le risque que si la base de données et le serveur doivent être divisés à un stade ultérieur, ils seront laissés de manière non sécurisée, conduisant à de futurs exploits.
Si un attaquant peut violer la machine avec un compte limité, il peut être en mesure de se connecter aux services locaux, mais pas de réinitialiser le mot de passe de la base de données; exiger de l'attaquant qu'il s'authentifie limite les dégâts qu'il peut causer.
Si une attaque peut être utilisée pour refléter/relayer le trafic, un adversaire distant peut sembler être sur la machine locale (un exemple serait un proxy qui peut être convaincu de charger une API de base de données ou un service qui affiche les données reçues lors d'une connexion échoue à une URL donnée)
Si des mots de passe sont utilisés, différents systèmes et utilisateurs peuvent être empêchés d'utiliser les comptes les uns des autres, sinon, un attaquant de n'importe quel système peut prétendre être n'importe quel autre système.
La sécurité supplémentaire dépendra de votre scénario de menace et de vos objectifs de sécurité. Je connais au moins deux situations où cela ajoute de la sécurité:
- Il vous permet de contrôler plus finement l'accès légitime à la base de données: il peut y avoir des personnes qui ont légitimement besoin d'accéder à la base de données, mais pas aux données à l'intérieur tels que les administrateurs de base de données effectuant la maintenance. Une base de données chiffrée peut (selon la configuration) permettre d'accorder l'accès à la base de données tout en gardant le secret des données.
Dans le même esprit, le chiffrement d'une partie de la base de données (par exemple, uniquement les colonnes avec des mots de passe) permet un accès limité (par exemple pour les problèmes de débogage, pour la génération de rapports ou pour un entrepôt de données ) tout en protégeant les informations critiques. - Il peut protéger les sauvegardes de la base de données. Si la base de données est sauvegardée au niveau d'un fichier ou avec un outil de sauvegarde qui prend en charge les bases de données chiffrées, la sauvegarde sera chiffrée. Cela est utile car les sauvegardes peuvent être une source de violations de données, car elles ne sont souvent pas sécurisées ainsi que les serveurs d'où elles proviennent (voir par exemple ne sécurité de sauvegarde médiocre entraîne une fuite de données client Ameriprise ).
Si vous n'avez pas de problèmes majeurs de mise à l'échelle dans votre avenir, cela peut ne pas ajouter de sécurité pour avoir un mot de passe , mais veuillez noter que "ne pas avoir de mot de passe" n'est pas la même chose "faire confiance à quiconque prétend être votre application."
Si votre application s'exécute en tant que son propre utilisateur sur le serveur *, certaines bases de données peuvent vous permettre d'utiliser l'authentification tierce (par exemple, ce que Postgres appelle l'authentification peer), ce qui permet au serveur d'utiliser des mécanismes de réseau ou de système d'exploitation pour déterminer quels utilisateurs sont qui ils disent être. Par exemple, sous la bonne configuration, l'utilisateur de shell "bob" peut accéder au compte de base de données "bob" sans donner de mot de passe. Faire en sorte que les choses soient simples peut faciliter la sécurisation de votre base de données et de votre application.
Cela dit, comme l'indique jrtapsellanswer , vous devrez peut-être déplacer votre application vers un autre serveur pour des raisons de coût ou de performances. Dans ce cas, vous aurez probablement besoin d'un mot de passe stocké ou d'un autre secret comme une clé privée, bien qu'il existe certaines méthodes principalement au sein des réseaux privés qui pourraient être utilisées pour éviter cela.
Si vous pensez qu'il y a de bonnes chances que vous ayez besoin d'un mot de passe (ou d'un autre secret stocké) à l'avenir, alors vous devez simplement prendre les dispositions maintenant afin qu'elles ne soient pas prises de manière non sûre plus tard par quelqu'un avec moins de temps ou d'expérience.
* Idéalement, ce compte devrait être fortement mot de passe, ou uniquement disponible pour se connecter via Sudo ou un mécanisme équivalent
Vous connaissez toutes ces violations de données qui se sont produites récemment? Celles où les gens ont trouvé des sauvegardes de base de données non protégées par mot de passe dans des compartiments Amazon S3 non sécurisés? Oui.
Jamais supposez que votre base de données ne vivra que sur votre serveur sécurisé derrière vingt milliards de pare-feu. Les tracas mineurs d'un mot de passe sur votre base de données sont un petit prix à payer pour la sécurité essentiellement gratuite qu'il offre.
En complément de la réponse de Serge Ballesta.
Cela devient particulièrement délicat si vous utilisez une base de données NoSQL, par exemple MongoDB, car par défaut, tout utilisateur de base de données aura des privilèges en lecture seule pour toutes les bases de données, et il n'est même pas configuré pour avoir un db-user hors de la boîte. Il y a pas mal de faiblesses, comme l'indique Spider Labs Blog il y a quelque temps (vers 2013), mais les recommandations ne sont généralement pas suivies même pour les grandes entreprises, par ex. MacKeeper incident (fin 2015).
Dans les deux références, vous trouverez une liste des vulnérabilités les plus courantes. Si vous préférez lire les directives "officielles", vous pouvez les trouver ici , elles doivent être analogues aux bases de données SQL. Cependant, j'aime à penser qu'il n'y a pas de surpuissance lorsque le sujet est la sécurité.