web-dev-qa-db-fra.com

Quelle est la meilleure pratique pour placer des serveurs de base de données dans des topologies de réseau sécurisées

J'ai une architecture classique DMZ:

enter image description here

Mon serveur Web est placé dans la DMZ. Le serveur Web doit communiquer avec un serveur de base de données. Ce serveur de base de données est le composant le plus critique de mon réseau car il contient des données confidentielles.

Où dois-je placer le serveur DB et pourquoi? Dois-je ajouter un deuxième pare-feu et créer une autre DMZ?

networkwebserverfirewallsdatabases
20
lisa17
  • Le meilleur emplacement consiste à placer les serveurs de bases de données dans une zone de confiance qui leur est propre.
  • Ils doivent autoriser les connexions entrantes à partir des serveurs Web uniquement, et cela doit être appliqué sur un pare-feu et sur les machines. La réalité dicte généralement quelques machines supplémentaires (db admin, etc.). Obéissez à la réalité au besoin, bien sûr.
  • Ils ne devraient établir des connexions sortantes que si vous mettez à jour des logiciels dessus.
26
Jeff Ferland

D'accord avec Jeff Ferland, les serveurs de base de données doivent être autonomes: vous devez avoir un réseau propre pour la réplication et la sauvegarde.

Pardonnez mon ASCII art, un bref aperçu d'un idéal raisonnable:

      [internet]
          |
    outer-firewall--- [proxy-zone]
          |      
         ----- [app-zone]
          |
    inner-firewall 
[lan]--/         \-- [database-zone]
  1. Exécutez un proxy inverse, Apache + mod_security/varnish/nginx/WAF/autre, dans la zone proxy. Ajoutez ici l'équilibrage de charge/le basculement si nécessaire. Serveur proxy/relais également pour les connexions sortantes (DNS, SMTP, proxy HTTP), si nécessaire.
  2. Lorsque la logique d'application s'exécute sur un serveur Web (Java/PHP/ASP), je préfère l'appeler un serveur d'applications.
  3. Lorsque vous avez besoin de mettre à l'échelle, vous pouvez mettre à l'échelle horizontalement, les équilibreurs de charge facilitent la tâche. Vous pouvez également envisager de répliquer du contenu statique non authentifié vers les proxys frontaux.
  4. vous souhaiterez peut-être ajouter une ou plusieurs zones: IDS, gestion, sauvegarde, accès à distance, proxy sortant

Vous essayez d'atténuer, alors:

  • la communication inter-zone doit être limitée au minimum requis à des fins de service et de surveillance.
  • le proxy inverse accepte les connexions non fiables provenant d'Internet, ne peut se connecter qu'aux services sur les serveurs d'applications. Si vous souhaitez classer vos zones en fonction du trafic, vous devez considérer attentivement la terminaison des HTTP et si vous souhaitez créer de nouvelles connexions HTTP aux serveurs d'applications.
  • la zone d'application accepte les connexions semi-sécurisées des mandataires, ne peut se connecter qu'aux bases de données. Vous pouvez faire un peu plus confiance à vos serveurs d'applications lorsque vous savez qu'ils ne parlent pas directement à Internet.
  • les serveurs de base de données acceptent uniquement les connexions des serveurs d'applications, la zone de base de données doit être votre réseau le plus "propre"
  • envisager d'utiliser différents pare-feu (fournisseur/produit) pour les pare-feu externes et internes
  • pour les services sortants requis (DNS, SMTP ou correctifs/mises à jour), ceux-ci doivent passer par un serveur distinct (par exemple sur la zone proxy ou la zone proxy sortante).
  • il en va de même pour toutes les connexions HTTPS de validation CC sortantes. (Si vous n'avez pas la chance d'avoir une boîte noire fournie par le fournisseur pour la validation, cela devrait également être dans une zone dédiée, à mon humble avis.)
  • utiliser l'adressage IP public uniquement dans la zone proxy, l'adressage privé ailleurs. Aucun serveur en dehors de la zone proxy n'a besoin d'une IP publique, d'un NAT ou d'une route par défaut vers Internet.

Des zones séparées facilitent le travail de votre IDS et la journalisation est plus efficace. Si vous avez les ressources, ajoutez une zone de gestion, séparez les cartes réseau de gestion pour chaque serveur (ports protégés si vous le pouvez).

En réalité, vous pouvez finir par compacter le "réseau idéal" en un seul pare-feu et VLAN, mais si vous considérez vos options maintenant avec ce qui précède à l'esprit, il devrait être plus facile de migrer à l'avenir, c'est-à-dire peu de temps après la prochaine visite de votre quartier amical Auditeur PCI-DSS ;-)

21
mr.spuratic

Ce qui suit est une configuration assez courante pour DMZ architectecutre:

L'Internet

^

Pare-feu1

^

DMZ (hébergez vos serveurs dmz ici uniquement en autorisant des ports spécifiques à travers le pare-feu)

^

Pare-feu2

^

Réseau de base de données (autoriser uniquement des ports et protocoles spécifiques du pare-feu2 vers ce réseau)

Comme vous le mentionnez, la base de données contient des données de carte de crédit (sensibles), même à l'intérieur du pare-feu2, le réseau de base de données doit être séparé des réseaux d'entreprise et d'utilisateurs. Tant de fois je vois les joyaux de la couronne d'une entreprise grande ouverte sur le réseau interne pour que tous les utilisateurs puissent y accéder et y accéder. En allant plus loin, vous pourriez avoir un administrateur de base de données VLAN autoriser uniquement les systèmes au sein de cette autorisation VLAN à accéder aux bases de données (à l'exception de l'application qui doit accéder à depuis le DMZ bien sûr).

J'espère que cela t'aides.

1
fixulate

L'architecture à 3 niveaux est la solution la plus sécurisée et évolutive. À mesure que le trafic client augmente, nous pouvons additionner autant de niveaux intermédiaires nécessaires pour garantir les performances. L'architecture à trois niveaux est également plus sécurisée car la couche intermédiaire protège le niveau de la base de données. Nous devons protéger le niveau de la base de données contre l'accès direct et nous devons le placer dans la zone de confiance et il ne devrait accepter que les connexions des serveurs d'applications.

3 Tier Architecture

1
Ali Ahmad

Comme vous devrez vous conformer à PCI-DSS, vous devrez également vous assurer que vous disposez de pare-feu à chaque connexion Internet et entre DMZ et les réseaux internes. Il existe de bons conseils dans les questionnaires d'auto-évaluation.

Ne faites pas non plus du serveur de base de données si une boîte Wintel est membre du domaine, etc.

0
Matthew

Je préférerais une architecture où le serveur de base de données est protégé par plus qu'un simple pare-feu. Autrement dit, je suppose que le serveur Web est compromis - mais au lieu de pouvoir effectuer des opérations de base de données arbitraires, il ne peut extraire que des données extrêmement limitées d'un serveur intermédiaire. Un passionné de base de données affirmerait que toute base de données disposera d'une fonction de vérification des privilèges suffisante. Mais bon, défense en profondeur.

0
markhahn