Pourquoi est-il déconseillé de disposer de la base de données et du serveur Web sur le même ordinateur?
En écoutant l'interview de Scott Hanselman avec l'équipe Stack Overflow ( partie 1 et 2 ), il était catégorique: le serveur SQL et le serveur d'applications devraient se trouver sur des ordinateurs distincts. Est-ce juste pour s'assurer que si un serveur est compromis, les deux systèmes ne sont pas accessibles? Les problèmes de sécurité l'emportent-ils sur la complexité des deux serveurs (coût supplémentaire, connexion réseau dédiée entre eux, davantage de maintenance, etc.), en particulier pour une petite application, dans laquelle aucune pièce n'utilise trop de processeur ou de mémoire? Même avec deux serveurs, avec un serveur compromis, un attaquant pourrait tout de même causer de graves dommages, soit en supprimant la base de données, soit en modifiant le code de l'application.
Pourquoi serait-ce un si gros problème si la performance n’est pas un problème?
- Sécurité. Votre serveur Web réside dans une zone démilitarisée (DMZ), accessible à l’Internet public et recevant des entrées non fiables d’utilisateurs anonymes. Si votre serveur Web est compromis et que vous vous êtes conformé aux règles de privilège minimum lors de la connexion à votre base de données, la visibilité maximale correspond à ce que votre application peut faire via l'API de base de données. Si vous avez un niveau métier entre les deux, vous avez un pas de plus entre votre attaquant et vos données. Si, en revanche, votre base de données se trouve sur le même serveur, l'attaquant dispose désormais d'un accès root à vos données et à votre serveur.
- Evolutivité. Garder votre serveur Web sans état vous permet de faire évoluer vos serveurs Web horizontalement sans effort. Il est très difficile de mettre à l'échelle horizontalement un serveur de base de données.
- Performance. 2 boîtes = 2 fois le CPU, 2 fois la RAM et 2 fois les piles pour l'accès au disque.
Ceci étant dit, je peux certainement voir des cas raisonnables qu'aucun de ces points n'a d'importance.
Ce n'est pas vraiment ça compte (vous pouvez très bien faire fonctionner votre site avec web/base de données sur la même machine), c'est simplement l'étape la plus simple de la mise à l'échelle ..
C'est exactement ce que StackOverflow a fait - en commençant avec une seule machine exécutant IIS/SQL Server, puis lorsqu'il a commencé à être très chargé, un deuxième serveur a été acheté et le serveur SQL a été déplacé sur celle-ci.
Si les performances ne sont pas un problème, ne gaspillez pas votre argent en achetant/entretenant deux serveurs.
D'autre part, se référant à un autre blogueur, Scott (Watermasyck, de Telligent) - ils ont constaté que la plupart des utilisateurs pouvaient accélérer les sites Web (à l'aide du serveur de communauté de Telligent) en plaçant la base de données sur le même ordinateur que le site Web. Toutefois, dans le cas de leurs clients, le serveur Web et la base de données sont généralement les seules applications de cette machine, et le site Web ne sollicite pas beaucoup la machine. Ensuite, l'efficacité de ne pas avoir à envoyer des données sur le réseau a compensé l'augmentation de la tension.
Tom a raison sur ce point. Certaines autres raisons sont que ce n'est pas rentable et qu'il y a des risques de sécurité supplémentaires.
La configuration matérielle requise par les serveurs Web est différente de celle des serveurs de base de données. Les serveurs de base de données ont de meilleurs résultats avec beaucoup de mémoire et une matrice de disques très rapide, tandis que les serveurs Web ne nécessitent que suffisamment de mémoire pour mettre en cache les fichiers et les demandes fréquentes de base de données (en fonction de votre configuration). En ce qui concerne la rentabilité, les deux serveurs ne seront pas nécessairement moins chers. Cependant, le rapport performances/coûts devrait être plus élevé, car vous n'avez pas à faire appel à des applications différentes pour des ressources. Pour cette raison, vous allez probablement devoir dépenser beaucoup plus pour un serveur qui répond aux deux besoins et offre des performances équivalentes à celles de deux serveurs spécialisés.
Le problème de sécurité est que si la seule machine est compromise, le serveur Web et la base de données sont vulnérables. Avec deux serveurs, vous avez un peu de marge de manoeuvre car le deuxième serveur sera toujours sécurisé (au moins pendant un certain temps).
En outre, il existe des avantages en termes d'évolutivité puisqu'il est possible que vous ne deviez gérer que quelques serveurs de base de données utilisés par plusieurs applications Web. De cette façon, vous aurez moins de travail à faire pour appliquer des mises à niveau ou des correctifs et pour ajuster les performances. Je pense qu’il existe des outils de gestion de serveur pour faciliter ces tâches (dans le cas d’une machine unique).
Je pense que le facteur important serait la performance. Le code serveur/application Web et SQL Server mettraient en cache les données demandées couramment en mémoire et vous réduirez la performance de votre cache en les exécutant dans le même espace mémoire.
La sécurité est une préoccupation majeure. Dans l'idéal, votre serveur de base de données devrait être placé derrière un pare-feu et ne comporter que les ports nécessaires à l'accès aux données. Votre application Web doit se connecter au serveur de base de données avec un compte SQL disposant des droits suffisants pour que l'application fonctionne, sans plus. Par exemple, vous devez supprimer les droits permettant de supprimer des objets et vous ne devez certainement pas vous connecter à l'aide de comptes tels que "sa".
Si vous perdez le serveur Web en raison d’un piratage (c’est-à-dire une élévation complète des privilèges en droits d’administrateur), le pire des cas est que la base de données de votre application risque d’être compromise, mais pas l’ensemble du serveur (comme ce serait le cas si le serveur de base de données et serveur Web étaient la même machine). Si vous avez chiffré vos chaînes de connexion à la base de données et que le pirate informatique n’est pas assez expérimenté pour les déchiffrer, tout ce que vous avez perdu est le serveur Web.
Un facteur qui n'a pas encore été mentionné est l'équilibrage de charge. Si vous commencez par considérer le serveur Web et la base de données comme des machines distinctes, vous optimisez le nombre d'allers-retours sur le réseau et il est également plus facile d'ajouter un deuxième serveur Web ou un deuxième moteur de base de données à mesure que les besoins augmentent.
D'après mon expérience personnelle, il est souvent judicieux de placer le serveur Web et la base de données sur différentes machines. Si vous utilisez une application qui utilise beaucoup de ressources, le cycle de la CPU sur la machine peut facilement atteindre son maximum, provoquant essentiellement l'arrêt de la machine. Toutefois, si votre application utilise la base de données de manière limitée, il n’y aurait probablement pas de problème à ce qu’elles partagent un serveur.
Wow, personne ne soulève le fait que si vous achetez réellement un serveur SQL à 5 000 dollars, vous voudrez peut-être l'utiliser pour plus que votre application Web. Si vous utilisez Express, vous ne vous en souciez peut-être pas. Je vois des serveurs SQL exécuter des bases de données pour 20 à 30 applications, donc le placer sur le serveur Web ne serait pas intelligent.
Deuxièmement, cela dépend de la destination du serveur. Je travaille pour des sociétés financières et le gouvernement. Nous utilisons donc une douleur insensée dans l’approche classique consistant à n’utiliser que des sprocs et à limiter les ports de serveur Web à SQL. Donc, si l'application Web est piratée. La seule chose que le pirate informatique puisse faire est d'appeler les sprocs, car le compte d'utilisateur sur le serveur Web est verrouillé pour ne permettre que les sprocs de voir/d'appeler sur la base de données. Alors maintenant, le pirate informatique doit trouver comment entrer dans la base de données. Si c'est bien sur le serveur Web, il est facile de s'y rendre.
Je suis d'accord avec Daniel Earwicker - la question de la sécurité est plutôt imparfaite.
Si vous avez une seule configuration de boîte avec un serveur Web et uniquement la base de données de ce serveur Web, si ce serveur Web est compromis, vous perdez le serveur Web et uniquement la base de données de cette application spécifique.
C'est exactement la même chose que ce qui se passe si vous perdez le serveur Web sur une configuration à 2 serveurs. Vous perdez le serveur Web et uniquement la base de données de cette application spécifique.
L'argument selon lequel "le reste de l'intégrité du serveur de base de données est préservé", dans lequel vous avez une configuration à 2 serveurs, est sans importance car, dans le premier scénario, tous les autres serveurs de base de données relatifs à toutes les autres applications (le cas échéant) restent également affectés. - être, comme ils sont, hébergés ailleurs.
De même, à la question posée par Kev ', qu'en est-il de toutes les autres bases de données résidant sur le serveur de base de données? Tout ce que tu as perdu, c'est une base de données.
- si vous hébergiez une application et une base de données sur un serveur, hébergez uniquement les bases de données de ce serveur liées à cette application. Par conséquent, vous ne perdrez aucune base de données supplémentaire dans une configuration de serveur unique par rapport à une configuration à plusieurs serveurs.
En revanche, dans une configuration à 2 serveurs, où l'attaquant avait accès au serveur Web et, par procuration, à des droits limités (dans le meilleur des cas) sur le serveur de base de données, il pouvait mettre en danger les bases de données de toutes les autres applications. requêtes lentes, gourmandes en mémoire ou maximisant l’espace de stockage disponible sur le serveur de base de données. En séparant les applications de leurs propres préoccupations, un peu comme la virtualisation, vous les isolez de manière positive pour des raisons de sécurité.
Cela dépend de l'application et du but. Lorsque la haute disponibilité et les performances ne sont pas critiques, il n'est pas mauvais de ne pas séparer la base de données et le serveur Web. Compte tenu en particulier des gains de performances - si l’application génère un grand nombre de requêtes de base de données, une charge considérable du réseau peut être supprimée en conservant le tout sur le même système, ce qui permet de réduire les temps de réponse.
Je pense que c'est parce que les deux machines devraient généralement être optimisées de différentes manières. Autre que cela, je n'en ai aucune idée, nous exécutons toutes nos applications avec la base de données serveur sur le même ordinateur - sachant que nous ne sommes pas confrontés au public - mais nous n'avons rencontré aucun problème.
Je ne peux pas imaginer qu'un trop grand nombre de personnes se préoccupent du fait qu'une machine soit compromise pour les deux, car l'application Web aura généralement un accès presque illimité à au moins les données, sinon le schéma de la base de données.
Intéressé par ce que les autres pourraient dire.
J'ai écouté ce podcast, et c'était amusant, mais l'argument de la sécurité n'avait aucun sens pour moi. Si vous avez compromis le serveur A et que ce serveur peut accéder aux données du serveur B, vous avez immédiatement accès aux données du serveur B.
Les licences de base de données ne sont pas chères et sont souvent facturées par processeur. Par conséquent, en séparant vos serveurs Web, vous pouvez réduire le coût de vos licences de base de données.
Par exemple, si vous avez un serveur Web et une base de données contenant 8 processeurs, vous devrez payer pour une licence de 8 cpu. Cependant, si vous avez deux serveurs avec chacun 4 processeurs et que vous exécutez la base de données sur un serveur, vous ne payerez que pour une licence à 4 processeurs.
Une autre préoccupation est que les bases de données aiment utiliser toute la mémoire disponible et la garder en réserve au moment de l'utiliser. Vous pouvez le forcer à limiter la mémoire, mais cela peut considérablement ralentir l’accès aux données.