Sécurité de base de données/mise à l'échelle Question

Question

Typiquement, j'utilise une base de données telle que MySQL ou PostGreSQL sur la même machine que l'application qui l'utilise, ce qui rend l'accès facile et sécurisé. Je suis en train de construire le premier site qui aura un serveur de base de données physique séparé (plus tard cette année il le fera). Je me demande 3 choses:

1. (sécurité) Quelles sont les choses que je devrais examiner dans les démarreurs se rapportant à la sécurité de l'accès à la base de données d'une machine séparée? (Évolutivité) Est-ce que les problèmes d'évolutivité auxquels je devrais penser à propos de cela (technologie agnostique)? Si vous démarrez le DB sur le même serveur physique (en utilisant une machine virtuelle VMWare séparée) et que vous passez ensuite à un serveur physique différent, y a-t-il des problèmes implicites auxquels je vais devoir faire face? Une autre machine virtuelle n'est-elle pas encore accessible via localhost?

Si ces questions sont complètement ridicules, je m'excuse auprès de vous experts DB.

Answer 1

Facile, je vous l'accorde. Sécurisé .. bien, la sécurité a très peu à voir avec l'emplacement physique du serveur de base de données.

Pour accéder à vos trois questions cependant:

1. D'abord, regardez comment vous pouvez limiter l'accès aux tables de base de données en utilisant les serveurs de base de données modèle de sécurité. A savoir, si votre application n'a pas besoin de supprimer des tables, assurez-vous que l'utilisateur qu'elle utilise pour se connecter n'a pas cette capacité. Deuxièmement, regardez comment crypter la connexion entre le serveur de base de données et votre application. Dans Windows, cela est assez transparent grâce à kerberos et peut même être appliqué par les paramètres de stratégie de groupe, pas sûr sur les autres plates-formes. Troisièmement, examinez les fonctionnalités de la base de données pour crypter les données "au repos". Ce qui signifie, est-ce que nativement soutenir le cryptage des fichiers de données eux-mêmes?

Le point ici est que votre application est seulement un point d'entrée possible pour le serveur de base de données lui-même. Demandez-vous, ce qui se passerait si quelqu'un peut se connecter directement sans passer par votre application en utilisant vos informations d'identification d'applications. Ensuite, demandez ce qui peut arriver s'ils trouvent un problème d'injection SQL. Demandez-vous également quelles informations peuvent être glanées si quelqu'un est capable de surveiller le trafic IP entre votre application et le serveur. Peuvent-ils discerner des données? Enfin, demandez-vous, que se passe-t-il s'ils obtiennent une copie de la base de données elle-même? Les longueurs que vous allez pour # 1 dépendront de plusieurs facteurs tels que: Quelle est la valeur des données (par exemple: ce qui se passerait pour vous, votre entreprise ou vos clients si elle était perdue); et, Combien de temps avez-vous pour trouver une solution idéale?

2. évolutivité: Ceci est purement une fonction de la charge. Malheureusement, la seule façon de mettre à l'échelle la plupart des applications de base de données est de l'augmenter. Cela signifie que vous acquérez un serveur de base de données plus volumineux en cas de besoin. Stack Overflow a traversé cela il n'y a pas si longtemps. Certains types de bases de données (nosql, mongodb, etc) supportent un concept connu sous le nom de déchiquetage ou sharding. MySql, PostGreSql, etc ne le font pas. Au lieu de cela, vous devrez concevoir spécifiquement l'application pour le gérer. Ce qui veut dire ne pas utiliser de clés auto incrémentées, etc. Cela peut être un PITA royal ... c'est pourquoi la mise à l'échelle est beaucoup plus facile en fonction de votre application.

3. Une autre machine virtuelle n'est pas accessible via "localhost". localhost définit l'accès à votre serveur actuel.Que ce serveur soit une VM ou non est sans importance. Vous devrez référencer votre serveur de base de données par son nom. Maintenant, la transition de la VM de la base de données à un autre serveur physique devrait avoir un impact nul puisque vous le référençant par son nom. Au-delà, il n'y a pas d'autres considérations.

Answer 2

En plus de réponse valide de Chris,

sécurité

Utilisez un mécanisme de sécurité sur le réseau en plus de quelle que soit la sécurité comprend la base de données ou d'un cadre d'application fournit. Peut-être que c'est un simple pare-feu sur le réseau, en cours d'exécution IPSEC, ou sur un tunnel SSL. Le fait est que vous ne devez pas supposer que les auteurs de la base de données sont des experts en sécurité réseau, ou que le mécanisme d'authentification de la base de données a même traité la sécurité du réseau.

Évolutivité

Un problème d'évolutivité vient à l'esprit lors du déplacement du local à distance dbs. La communication TCP/IP à distance est beaucoup plus lente que la communication de tuyau locale. Votre application peut avoir des problèmes d'évolutivité cachés en raison de fréquents allers-retours à la base de données. Entre chaque requête, votre application attend successivement chaque réponse de base de données. Sur un système local, la latence est si petite que vous ne l'avez peut-être pas remarqué.