Quel SGBD est approprié pour garder un schéma privé même lorsqu'il est installé 'à l'état sauvage'

Question

J'ai un serveur d'applications qui se connecte à un serveur de base de données. J'aimerais pouvoir fournir aux utilisateurs des installateurs et, avec un degré de confort moyen, avoir confiance que le schéma de la base de données est sécurisé.

Je comprends que je ne devrai accepter que certains risques si je ne contrôle pas l'ordinateur sur lequel il est installé: une personne déterminée disposant des outils et des connaissances appropriés pourrait consulter directement la mémoire et extraire des informations.

Au départ, je pensais que mon domaine d’activité serait simplement d’ajouter les informations d’identification à l’installateur sans qu’elles soient visualisées de manière triviale dans un éditeur hexadécimal.

Cependant, au début de mes recherches, j’ai appris que pour PostGreSQL, même si j’installais la base de données en silence et ne fournissais pas les informations d’identité à l’utilisateur, ils pouvaient simplement modifier un fichier de configuration textuel (pg_hba.conf). ) et redémarrez le serveur pour permettre un accès complet à la base de données sans informations d'identification.

Ce scénario est-il sécurisé dans un autre SGBD? Comment la plupart des produits commerciaux protègent-ils leurs schémas dans ce scénario? La plupart des produits utiliseraient-ils des bases de données intégrées?

Éditer: Je suppose (peut-être à tort) que certains produits reposent sur des bases de données que l'utilisateur ne touche jamais directement. Et bien sûr, je ne les vois jamais, car ils l'ont conçu de manière à ce que l'utilisateur n'en ait pas besoin - en utilisant probablement une base de données intégrée.

Answer 1

La plupart des produits commerciaux ne protègent pas leurs schémas. Ils tombent dans l’un des deux camps suivants:

Soit ils utilisent une base de données de classe entreprise pour un composant clé du produit (tel qu'un système de paie), auquel cas aucune tentative de masquage du schéma / des données n'est effectuée. Dans la plupart des cas, le client a quand même besoin de contrôler la base de données - pour configurer le mode de sauvegarde de la base de données, pour pouvoir créer un environnement en cluster, etc.

L'autre cas, c'est si votre " base de données " n’est rien qu’un petit fichier de paramètres ou de stockage pour une application de bureau (par exemple, les bases de données d’historique et de signets dans FireFox). Dans ce cas, vous devez simplement utiliser une base de données intégrée (telle que SQLite, identique à FireFox) et ajouter une couche de cryptage en continu (il existe une version officielle de cette entité appelée SEE), ou simplement utiliser la base de données intégrée et oublier la couche de cryptage, car l'utilisateur devra d'abord installer ses propres outils de base de données pour pouvoir lire le fichier.

Answer 2

Pour autant que je m'en souvienne, il n'y a pas de produits commerciaux qui "protègent" leurs schémas. Pour quoi voulez-vous que le schéma soit protégé?

Considérez les points suivants:

• Après tout, la seule personne pouvant protéger quoi que ce soit dans un SGBDR est l'administrateur du serveur de base de données. Et vous voulez que le schéma soit protégé contre cette personne?

• Si j'étais client et que mes données figuraient dans votre schéma, je ne voudrais pas seulement, mais espère pouvoir le voir et le consommer directement.

• Avez-vous vraiment besoin de protéger votre design relationnel? Est-ce vraiment intéressant? Avez-vous inventé quelque chose qui vaille la peine d'être caché? Je ne pense vraiment pas. Et je m'excuse par avance si vous avez.

EDIT: Commentaire supplémentaire:

Je me moque de la plupart des composants internes de la base de données pour les produits que j'utilise. C'est une autre raison pour laquelle je pense que la plupart d'entre eux ne prennent aucune mesure pour les protéger. La plupart d'entre eux ne sont pas si intéressants.

D'un côté, je suis fermement convaincu que les utilisateurs ne devraient pas avoir besoin de connaître ou de se soucier des éléments internes de la base de données. Mais au même niveau, en tant que développeur, je ne pense pas qu'il vaille la peine d'essayer de les protéger. Les cacher à l'utilisateur, oui. Protégez-les contre l'accès direct, dans la plupart des cas, non. Et pas parce que je pense qu'il est faux de protéger votre schéma. C’est parce que je pense que c’est une chose très difficile à faire et que cela ne vaut pas la peine de passer du temps en tant que développeur.

Mais à la fin, comme pour tout sujet lié à la sécurité, la seule bonne réponse est de savoir quels sont les risques impliqués par rapport aux coûts de la mise en œuvre de la mesure de sécurité.

Les moteurs de base de données actuels, qu'ils soient intégrés ou de type serveur, ne sont pas conçus pour masquer facilement le schéma de la base de données. Par conséquent, le coût de développement associé à son utilisation est bien supérieur au risque encouru, pour la plupart des utilisateurs.

Mais votre cas pourrait être différent.

Answer 3

Quel problème essayez-vous de résoudre? Rien ne peut empêcher le DBA * de faire tout ce qu'il veut sur des bases de données standard, et comme d'autres l'ont déjà souligné, il est hostile à toute ingérence dans des besoins spécifiques à un site, tels que les sauvegardes et les mises à niveau de bases de données. Vous pouvez tout au plus chiffrer le contenu de votre base de données, mais vous devez quand même fournir une clé de déchiffrement pour que votre application s'exécute et un administrateur de base de données motivé et hostile peut probablement le subvertir.

Les militaires et les services de renseignement disposent sans aucun doute de bases de données dans lesquelles même le schéma est hautement classifié, mais je ne sais pas si elles sont protégées par des moyens techniques ou s'il s'agit simplement de gros hommes armés.

(*) Administrateur de base de données ou administrateur système capable de modifier des fichiers tels que pg_hba.conf.

Answer 4

  

Comment la plupart des produits commerciaux   protéger leurs schémas dans ce   scénario?

Je ne crois pas que la plupart des produits commerciaux fassent quelque chose pour protéger leurs schémas.

Answer 5

Comment un SGBD intégré peut-il empêcher quelqu'un de bricoler avec son stockage (fichiers dans ce contexte matériel non incorporé) quand cette personne a un accès physique à la machine sur laquelle ce SGBD est exécuté? La la sécurité par l'obscurité est une proposition risquée.

Answer 6

Cette idée souffrira des mêmes problèmes que le DRM. Vous ne pouvez empêcher l'accès des personnes déterminées et vous ne causerez que des souffrances générales à vos clients. Ne le fais pas.

SQLite encapsule tout le format de la base de données dans un seul fichier. Vous pouvez éventuellement le chiffrer et le déchiffrer sur place. La faille, bien sûr, est que les utilisateurs ont besoin de la clé pour utiliser la base de données maintenant, et la seule solution possible est de la leur donner, par exemple en la codant en dur au moment de la compilation (sécurité par obscurité) ou un système de téléphone-maison (une foule de raisons pour lesquelles c'est une mauvaise idée). De plus, ils vont maintenant vous haïr parce que vous avez contrecarré toute tentative de système de sauvegarde utile et ils obtiennent des performances médiocres au démarrage.

En outre, personne ne se soucie réellement des schémas. Je déteste vous en parler, mais la conception des schémas n'est pas un problème difficile, et certainement jamais un avantage concurrentiel légitime (hormis peut-être quelques domaines spécifiques tels que la représentation des connaissances et l'entreposage de données). Les schémas ne valent généralement pas la peine d'être protégés.

Si c'est vraiment important pour vous, créez plutôt une application hébergée.