Comment expliquez-vous aux experts qu'un serveur de base de données ne doit pas résider dans la DMZ?
Nos experts en sécurité, administrateurs de base de données, équipe réseau et équipe infrastructure affirment tous que le serveur de base de données est situé dans le DMZ avec le serveur HTTP et le milieu. -serveur de logiciels.
Leur raison:
Si le serveur de base de données est compromis (en raison d'un niveau intermédiaire non sécurisé), au moins le serveur de base de données est en dehors du système interne. S'il se trouve à l'intérieur de notre réseau, le pirate peut alors utiliser le serveur de base de données pour accéder à d'autres systèmes.
Ce qu'ils disent, c'est:
- Ne plaçons pas le serveur middleware derrière un deuxième pare-feu et le serveur de base de données derrière un troisième pare-feu.
- Utilisons un seul pare-feu (celui du serveur HTTP) au cas où un pirate souhaiterait obtenir les données sensibles de notre base de données, du moins c'est tout ce qu'il peut obtenir.
La deuxième déclaration a en fait été dite ... textuellement.
Veuillez noter que ce serveur de base de données contiendra des informations sensibles, y compris les coordonnées bancaires.
Maintenant, ces experts ont-ils un sens pour vous? Je suis développeur de logiciels et je ne comprends pas leur logique. C'est comme, "Mettre la boîte à bijoux à l'extérieur de la maison pour que les voleurs ne prennent pas la peine d'entrer pour la télé?"
"Rendre votre réseau sûr pour les bases de données" de SANS ( http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24 ) se lit un peu daté dans certaines sections, mais fournit un niveau décent de conseils "pour les nuls" dans la direction que vous recherchez.
Vous pouvez également vous épuiser en fouillant dans le centre de ressources du NIST américain ( http://csrc.nist.gov/ ). Je pense que l'ISO/IEC 27033-2: 2012 de l'ISO serait également sur le sujet, mais je n'ai pas de copie à portée de main pour en être sûr.
Vous essayez de séparer/isoler les serveurs les plus sensibles (les serveurs de base de données) des plus exposés (et donc vulnérables).
Vous proposez une approche de "défense en profondeur", qui vise à a) empêcher les attaques dans la mesure du possible, et b) retarder leur progression (et l'accès aux choses importantes) dans le cas contraire.
Idéalement, tout est toujours renforcé et corrigé, les serveurs n'écoutent que le trafic sur les ports requis, et uniquement à partir des appareils autorisés, tout le trafic "en vol" est inaccessible aux auditeurs non autorisés (via le chiffrement et/ou l'isolement), et tout est surveillé pour détecter toute intrusion et l'intégrité.
Si tout cela est en place avec une certitude à 100%, alors tant mieux, votre "opposition" a abordé le point a) ci-dessus, autant que possible. Bon début, mais qu'en est-il du point b)?
Si un serveur Web est compromis, l'architecture que vous proposez est bien meilleure. Leur empreinte potentielle d'attaque et leur vecteur sont beaucoup plus importants que nécessaire.
La justification de la séparation de la base de données des serveurs Web n'est pas différente de la justification acceptée pour séparer les serveurs Web du LAN. Plus franchement: s'ils sont tellement convaincus qu'un serveur Web compromis ne présente aucun danger pour les autres systèmes dans la même zone de sécurité, pourquoi pensent-ils qu'un DMZ est requis du tout?
C'est terriblement frustrant d'être dans votre situation. À tout le moins, à votre place, je créerais une note de risque décrivant vos préoccupations et suggestions, et je ferais en sorte qu'ils le reconnaissent. CYA, de toute façon.
C'est comme, "Mettre la boîte à bijoux à l'extérieur de la maison pour que les voleurs ne prennent pas la peine d'entrer pour la télé?"
Oui, c'est exactement comme ça.
Si vous ne vous souciez pas de la valeur de la base de données, relativement parlant, alors assurez-vous qu'il est logique de la laisser à l'extérieur - si l'hypothèse est que l'application est horriblement précaire, mais vous devez la mettre de toute façon en place pour une raison quelconque, et Je ne veux pas le sécuriser, alors c'est logique comme un moyen d'isoler cet horrible système non sécurisé de tous les autres systèmes internes.
D'un autre côté, il n'y a vraiment aucune excuse pour s'attendre à avoir une TELLE application non sécurisée qui permet une prise en charge complète du serveur de base de données. De plus, il n'y a aucune raison réelle d'utiliser "l'exposition" comme alternative à l '"isolement" - il existe également des solutions simples pour le faire correctement.
En fin de compte, il semble que ce soit l'une des 2 situations possibles:
- Ces soi-disant "experts" sont vraiment ignorants.
- Il y a d'autres exigences commerciales qui sont négociées ici.
Je pense que votre analogie fonctionne parfaitement. S'ils vous disent ensuite l'équivalent de "En fait, ces bijoux sont faux, oh et btw le téléviseur est vraiment un travail personnalisé de 60" 5K avec des jantes en or ", alors cela pourrait être un compromis judicieux (encore mieux pour le faire correctement, bien que ).
Sinon, il est probable qu'il n'y a aucun moyen de l'expliquer, car ils travaillent par manque de connaissances.
Si la base de données contient des détails sur la carte, on peut très facilement affirmer que vous ne remplissez pas l'exigence PCI DSS sur la protection appropriée).
Il échoue également aux vérifications d'intégrité sur des points de défaillance uniques et protège vos actifs principaux.
Si les données valent des milliards, pourquoi ne dépenseriez-vous pas quelques milliers de plus pour ajouter des couches de protection? La bonne pratique de l'industrie consiste à disposer de zones de sécurité en couches.
Vous pouvez les diriger vers PCI, le Guide des bonnes pratiques de l'ISF et bien d'autres.
Si vous suggérez que le serveur de base de données passe de la même zone de sécurité que le serveur Web à la même zone de sécurité que certains systèmes internes, alors on peut raisonnablement conclure que vous réduisez la sécurité.
Si le statu quo veut que le serveur Web et le serveur de base de données se trouvent tous les deux dans la DMZ et qu'aucune connexion ne soit autorisée de DMZ au réseau interne, le déplacement du serveur de base de données de DMZ vers le réseau interne serait nécessite d'autoriser les connexions de DMZ au réseau interne. Cela signifierait que vous réduisez la sécurité du réseau interne sans obtenir une meilleure protection de la base de données.
Si vous croyez vraiment que la base de données est plus sensible que le réseau interne (ce qui peut très bien être vrai), alors vous ne voudriez aucun compromis du réseau interne pour accéder directement à la base de données.
Donc, le point que vous devez faire est que vous ne voulez pas déplacer le serveur de base de données d'une zone de sécurité à une autre, mais plutôt ce que vous voulez faire est de créer une zone de sécurité entièrement nouvelle. Pour vraiment suivre cela, vous devrez en fait acheter un pare-feu supplémentaire et le mettre entre le DMZ et le réseau supplémentaire sécurisé.
Ensuite, cela revient à évaluer le coût d'achat et de maintenance de ce pare-feu supplémentaire par rapport à la sécurité supplémentaire qu'il fournit.
AvID a déjà couvert la question principale, mais en venant sous un angle légèrement différent, la plupart des pare-feu prendront en charge plusieurs interfaces et pourront contrôler le trafic entre les interfaces.
La configuration des multiples interfaces pour héberger chacun des aspects de la solution (frontend, middleware, backend) réduirait le risque de compromettre la base de données à partir du serveur Web sans nécessiter plusieurs pare-feu physiques (si c'est ce qui inquiète les autres équipes) ... est-ce un problème de coût?) et sans introduire de route vers le réseau interne.
Vous vous demandez simplement si cela vous donnerait un `` levier '' pratique pour soutenir l'argument en faveur de la mise en œuvre d'une séparation, c'est-à-dire que cela apporte quelque chose de différent à la discussion qu'ils doivent contrer?
À défaut, qu'en est-il d'un scénario de simulation basé sur une vulnérabilité de serveur Web historique, qui aurait entraîné un compromis ultérieur de tout autre serveur sur le même segment de réseau (y compris la base de données) et comment un DMZ en couches serait empêcher le compromis ultérieur, il y aurait vraisemblablement un coût monétaire, il serait donc "facile" d'illustrer le rapport coût/effort?
En supposant que vous essayez de les persuader de le faire plutôt que de les convaincre (nécessairement) que c'est correct:
Expliquez que lorsque leurs gros clients et prospects viennent faire un audit de sécurité, ils échoueront.
Si l'obstacle est l'entreprise, ce sera la seule raison suffisante et nécessaire.
Un bon argument est que la barre n'est vraiment pas si élevée pour séparer les serveurs Web et les serveurs de base de données dans des DMZ distinctes.
Utilisez un vrai routeur/pare-feu et placez les serveurs Web et les serveurs de base de données sur des VLAN séparés, tous deux en dehors du LAN sécurisé interne, avec des règles de pare-feu contrôlant l'accès aux ports minimum requis d'Internet aux serveurs Web, du Web serveurs aux serveurs de base de données, et aucun accès provenant des serveurs Web au LAN sécurisé.
Le pare-feu empêcherait également tout accès direct d'Internet aux serveurs de base de données et contrôlerait étroitement tout accès des serveurs de base de données vers le LAN sécurisé (à des fins d'authentification ou autre).
De cette façon, l'attaquant ne peut même pas accéder directement au réseau contenant les serveurs de base de données.
S'ils obtiennent une tête de pont sur l'un de vos serveurs Web, ils ne sont toujours pas sur le même réseau avec un accès illimité pour attaquer vos serveurs de base de données, et si vous avez un type de surveillance des journaux en place, vous devriez recevoir des notifications sur le violation des serveurs Web avant que les attaquants aient eu beaucoup de temps pour attaquer autre chose.
Même s'ils parviennent à violer vos serveurs de base de données après un certain temps via le seul port ouvert que le serveur Web peut utiliser pour communiquer avec la base de données, ils ont gaspillé tout ce temps à accomplir relativement peu, période pendant laquelle vous avez été conscients de leur attaque, au lieu de passer tout ce temps à entrer dans votre réseau local sécurisé.
Ils ne peuvent même pas atteindre le LAN depuis le DMZ où les serveurs Web vivent, donc leur seul chemin dans le LAN sous quelque forme que ce soit est de sauter sur les serveurs de base de données, protégés dans l'autre DMZ. Les chances sont que vos serveurs de base de données sont ou seront liés à une sorte de système d'authentification d'entreprise (Active Directory ou autre). Voulez-vous cette capacité de la même manière DMZ avec vos serveurs Web publics ?
Si je peux être assez préoccupé par les problèmes de sécurité pour créer des sous-réseaux invités et DMZ sur mon home, pour avoir un endroit pour mettre des "choses" ("Internet des objets" ) sans les avoir directement sur mon réseau local, une préoccupation de plusieurs milliards de dollars peut sûrement se permettre le partage de l'esprit et le temps de faire la même chose avec des serveurs Web et des serveurs de bases de données importants. Je le fais au bureau avec une combinaison d'une pile de plusieurs- des commutateurs L2/L3 gérés par Procurve pour mille dollars, un SonicWall UTM et un routeur Ubiquiti EdgeMax. Chez home, j'ai un Ubiquiti EdgeRouter Lite à 100 $, un commutateur HP 8 ports géré à 100 $ et un Ubiquiti Unifi AP qui prend en charge plusieurs VLAN, et ma configuration est totalement capable de faire ce dont nous parlons.
Et j'ai la tranquillité d'esprit de ne pas craindre que mon DVR connecté au réseau, mon imprimante, mon lecteur BluRay, mon thermostat et quoi que ce soit d'autre, exécutant un micrologiciel obsolète qui ne sait pas quoi avec des exploits inconnus, ne sait pas être piraté et atteindre mon ordinateur et mes fichiers personnels sur le réseau.
Il n'est pas très difficile pour les experts en sécurité de configurer ce genre de chose, et cela n'a certainement pas besoin d'impliquer du matériel physique distinct pour chaque pare-feu. SDN (mise en réseau définie par logiciel) fait fureur ces jours-ci, non?
Même le EdgeRouter Lite à 100 $ peut transférer près de 1 Gbit/s via le routeur, avec prise en charge de plusieurs interfaces virtuelles et de règles de pare-feu entre toutes ces interfaces.
Une toute petite boîte est vraiment un panier plein de pare-feu.
Donc, si vous dépensez de l'argent réel sur un routeur haut de gamme, vous obtiendrez toutes ces fonctionnalités et quelques autres avec des performances de routage plus puissantes.
Même quelque chose comme Ubiquiti EdgeRouter Pro 8 vous donne 2 millions de paquets par seconde pour seulement 375 $, avec 8 interfaces physiques et VLAN sous-interfaces sur chacune d'elles si vous en avez besoin. Si vous avez besoin de performances supérieures à vous pouvez vous tourner vers Brocade (Vyatta), Cisco, Juniper, etc. pour un matériel plus gros. Ou quelque chose comme la série SuperMassive de Dell/Sonicwall. Ou exécuter le routeur virtuel Vyatta sur un serveur Xeon multicœur robuste.
Je n'essaie pas de colporter des routeurs, je fais juste remarquer que la barre n'est pas vraiment si haute pour obtenir le type de séparation de sécurité que vous devriez probablement avoir et que vous voulez évidemment ici.
@Craig ... bonne réponse pratique pratique. Étant donné que bruce_bana a déclaré que le coût ne devrait pas être un problème, cela devrait être réaliste à mettre en œuvre après avoir utilisé la réponse @DerekM (qui est également bonne) pour convaincre les prétendus experts en sécurité. @DTK ... bonne réponse de l'ACY. Celui-ci, je le mettrais certainement en œuvre si j'étais bruce_bana. @bruce bana ... essayez ce lien à partir de ce site pour un problème/solution comparable/connexe ... Quelle est la meilleure pratique pour placer des serveurs de base de données dans des topologies de réseau sécurisées
Dites à votre supérieur direct que vous n'êtes pas autorisé à accepter ce risque au nom de l'entreprise. Soulignez que la valeur des données dans la base de données est de xxx $ et que ce niveau d'acceptation des risques doit provenir d'une personne autorisée à le faire, et demandez-lui de se faire le champion de l'obtention d'un membre de la direction pour approuver l'acceptation des risques.
Pour estimer la valeur des données, déterminez s’il s’agit de données liées à PCI DSS (si tel est le cas, examinez le coût par client que Target/Home Depot a encouru pour les ventes perdues, le crédit surveillance, fraude), ou s'il s'agit d'un PII (dans l'affirmative, examinez les dommages financiers par patient que les systèmes médicaux ont subis en perte de confiance, surveillance du vol d'identité, perte de réputation), ou s'il s'agit de l'avantage concurrentiel de votre entreprise (commerce secrets, données financières non encore publiées, propriété intellectuelle), alors la valeur des données pourrait être l'évaluation actuelle de l'entreprise.
Si l'on vous donne un ordre direct d'accepter le risque au nom de la société, il se peut que l'on vous demande de commencer à agir en qualité de mandataire social et, à ce titre, vous avez l'obligation (éventuellement légale) de signaler que vous êtes une personne non nommée à laquelle vous devez jouer comme un seul et vous devez informer la chaîne de gestion du conseil d'administration de la société. Soyez prêt à faire face à des revers importants et à dépenser un capital politique important pour le faire savoir.
Bonne chance!