Accès aux données dans les bases de données de production internes à partir d'un serveur Web en DMZ
Je travaille sur un site Web externe (en DMZ) qui a besoin d'obtenir des données de notre base de données de production interne.
Toutes les conceptions que j'ai imaginées sont rejetées parce que le service réseau ne permettra aucune connexion d'aucune sorte (WCF, Oracle, etc.) à l'intérieur de la DMZ.
Les suggestions qui sont venues du côté du réseautage relèvent généralement de deux catégories -
1) Exportez les données requises vers un serveur dans le DMZ et exportez éventuellement les enregistrements modifiés/insérés, ou
2) Sondez de l'intérieur, en demandant continuellement un service dans le DMZ si elle a des demandes qui ont besoin d'être traitées.
Je suis opposé à la suggestion 1 parce que je n'aime pas l'idée d'une base de données située dans la DMZ. L'option 2 semble être une quantité ridicule de complications supplémentaires pour la nature de ce qui est fait.
S'agit-il des seules solutions légitimes? Y a-t-il une solution évidente qui me manque? Le décret "Pas de connexion depuis la DMZ" est-il pratique?
Edit: Une ligne que j'entends constamment est que "aucune grande entreprise ne permet à un site Web de se connecter à l'intérieur pour obtenir des données de production en direct. C'est pourquoi ils envoient des e-mails de confirmation". Est-ce vraiment ainsi que cela fonctionne?
Je suis désolé, mais votre service de réseautage est en panne ou quelque chose comme ça - ils ne comprennent clairement pas quel est le but d'un DMZ est. Pour résumer - il y a trois "domaines" - le grand, mauvais monde extérieur, votre monde intérieur pur et virginal, et la DMZ bien connue, fiable et sûre.
Les règles sont les suivantes:
- Les connexions de l'extérieur ne peuvent atteindre que les hôtes de la DMZ et sur des ports spécifiques (80, 443, etc.);
- Les connexions de l'extérieur vers l'intérieur sont absolument bloquées;
- Les connexions de l'intérieur vers le DMZ ou l'extérieur sont fines et dandy;
- Seuls les hôtes dans le DMZ peuvent établir des connexions vers l'intérieur, et encore, uniquement sur des ports bien connus et autorisés.
Le point quatre est celui qu'ils n'ont pas saisi - la politique "pas de connexion de la DMZ" est erronée.
Demandez-leur "Comment fonctionne notre système de messagerie alors?" Je suppose que vous avez un serveur de messagerie d'entreprise, peut-être un échange, et que des particuliers ont des clients qui s'y connectent. Demandez-leur d'expliquer comment votre messagerie d'entreprise, avec accès à la messagerie Internet, fonctionne et est conforme à leur politique.
Désolé, cela ne vous donne pas vraiment de réponse.
Je suis architecte en sécurité dans une firme financière Fortune 50. Nous avons eu ces mêmes conversations. Je ne suis pas d'accord avec votre groupe réseau. Je comprends leur angoisse, et je comprends qu'ils aimeraient une meilleure solution mais la plupart des endroits n'optent pas avec les meilleurs choix (en raison de l'ignorance de leur part [c'est-à-dire les gars du réseau pas vous]).
Deux options si elles sont difficiles à définir: vous pouvez utiliser une solution de proxy SQL comme greensql (je ne travaille pas pour eux, sachez-les), ce ne sont que greensql dot com.
L'approche à laquelle ils font référence que la plupart des "grandes organisations" utilisent est un modèle Web à plusieurs niveaux. Lorsque vous avez un serveur Web frontal (accessible au grand public), un niveau intermédiaire (couche d'application ou de services où se produisent les processus réels) et un niveau de base de données. Le niveau intermédiaire est la seule chose qui peut parler au niveau de la base de données. À mon avis, ce modèle est optimal pour la plupart des grandes organisations. MAIS cela étant dit, la plupart des grandes organisations se heurteront à un produit fourni par le fournisseur qui ne prend pas en charge un niveau intermédiaire, elles se sont développées sans niveau intermédiaire et la transition nécessite des ressources de développement qu'elles n'ont pas à épargner pour développer les services Web de niveau intermédiaire, ou carrément il n'y a pas de priorité dans certaines entreprises pour emprunter cette voie.
C'est une zone grise, pas de bien ou de mal à cet égard, donc s'ils parlent en termes de finalité, ils ont clairement tort. J'applaudis leur zèle, en tant que professionnel de la sécurité, je comprends d'où ils viennent. MAIS, nous devons permettre aux entreprises de fonctionner en toute sécurité. C'est le défi et le gant que j'essaie toujours de me jeter. comment puis-je fournir à mes clients (mes développeurs, mes administrateurs, mes administrateurs, les utilisateurs professionnels) ce qu'ils veulent (dans des limites raisonnables, et si je dis non à quelqu'un, j'essaie toujours de proposer une alternative qui répond à la plupart de leurs besoins).
Honnêtement, cela devrait être une conversation ouverte. Voici où je pense que vous pouvez obtenir de la place, demandez-leur de modéliser le risque qu'ils cherchent à atténuer. Demandez-leur de proposer des solutions alternatives qui permettent à vos applications Web de fonctionner. S'ils disent qu'ils ne peuvent pas parler, il leur incombe de fournir une solution. S'ils ne le peuvent pas, vous travaillez par défaut. Site sur lequel vous ouvrez les connexions du dmz au db UNIQUEMENT pour les ports approuvés. Faites-leur savoir que DMZ est pour offrir des services externes. Les services externes ne sont pas bons sans données internes pour autre chose que des solutions de transfert de fichiers potentiellement.
Juste mes deux cents, j'espère que ce commentaire vous aidera. Et essayez d'être facile avec mes frères de sécurité. Nous avons quelques moins expérimentés dans notre troupeau qui se cramponnent à d'anciennes façons de faire. À mesure que le monde évolue, la menace évolue, tout comme notre approche de l'atténuation.
Je suis surtout avec Ken Ray là-dessus; cependant, il semble qu'il y ait des informations manquantes. Voyons si je comprends bien:
- Vous avez une application web.
- Une partie de cette application Web doit afficher les données d'un autre serveur de production (pas celui qui sauvegarde normalement votre site).
- Les données que vous souhaitez/avez besoin sont gérées par une application complètement différente en interne.
- Ces données sont essentielles au flux normal de votre entreprise et seul un ensemble limité doit être disponible pour le monde extérieur.
Si je suis sur la bonne voie, je dois dire que je suis d'accord avec votre service informatique et je ne vous laisserais pas non plus accéder directement à ce serveur.
Prenez simplement l'option 1. Demandez au serveur de production d'exporter les données dont vous avez besoin vers un emplacement de dépôt communément accessible. Demandez à l'autre serveur db (un dans la zone démilitarisée) de récupérer les données et de les importer régulièrement. Enfin, demandez à votre application Web de parler UNIQUEMENT au serveur db dans le dmz.
Étant donné le nombre de personnes qui construisent des sites ces jours-ci, je serais également réticent à simplement ouvrir un port sql du dmz au serveur Web en question. Franchement, je pourrais être convaincu d'ouvrir la connexion si j'étais assuré que 1. vous n'utilisiez que des proc stockés pour accéder aux données dont vous avez besoin; 2. les informations de compte utilisées pour accéder à la base de données étaient cryptées et entièrement limitées à l'exécution de ces procs uniquement; 3. ces procs n'avaient aucun sql dynamique et étaient limités aux sélections; 4. votre code a été construit correctement.
Un informaticien ordinaire ne serait probablement pas qualifié pour répondre à toutes ces questions. Et si cette base de données provenait d'un tiers, je parierais que vous pourriez perdre le support si vous deviez y accéder depuis l'extérieur de son application normale.
Pourquoi ne répliquez-vous pas vos serveurs de base de données? Vous pouvez vous assurer que la connexion est établie entre les serveurs internes et les serveurs externes et non l'inverse.
Une façon consiste à utiliser le cadre de synchronisation ms - vous pouvez créer un service Windows simple qui peut synchroniser les modifications de la base de données interne vers votre base de données externe (qui peut résider sur un serveur db distinct), puis l'utiliser dans votre site Web public. L'avantage est que votre logique de synchronisation peut filtrer les données sensibles et ne garder que les éléments vraiment nécessaires. Et puisque l'intégralité du contrôle des données sera dans vos serveurs internes (pousser les données au lieu de les tirer), je ne pense pas que les TI auront un problème avec cela.
La connexion établie n'est jamais établie - elle est désactivée - ce qui signifie qu'aucun port n'a besoin d'être ouvert.
Avant de parler de votre problème particulier, je voudrais aborder la mise à jour que vous avez fournie.
Je n'ai pas travaillé pour une "grande" entreprise - bien que grande soit difficile à juger sans contexte, mais j'ai créé ma part d'applications Web pour le département à but non lucratif et universitaire pour lequel je travaillais auparavant. Dans les deux situations, je me suis toujours connecté à la base de données de production qui se trouve sur le réseau interne du serveur Web sur la DMZ. Je suis à peu près sûr que de nombreuses grandes entreprises le font également; pensez par exemple à la façon dont l'architecture de Sharepoint est configurée - indexation back-end, base de données, etc. serveurs, qui sont connectés à des serveurs Web frontaux situés dans la DMZ.
De même, la pratique consistant à envoyer des e-mails de confirmation, dont je pense que vous faites référence à des confirmations lorsque vous vous inscrivez à un site, ne traite généralement pas de la sécurité. Il s'agit davantage d'une méthode pour vérifier qu'un utilisateur a entré une adresse e-mail valide.
Maintenant que cela est hors de portée, examinons votre problème. Malheureusement, à part les deux solutions que vous avez présentées, je ne vois pas d'autre moyen de procéder. Bien que certaines choses auxquelles vous voudrez peut-être penser:
Solutions 1:
Selon la sensibilité des données avec lesquelles vous devez travailler, les extraire sur un serveur sur le DMZ - que ce soit en utilisant un service ou une sorte de logiciel de synchronisation automatique - va à l'encontre du bon sens de sécurité de base . Ce que vous avez fait, c'est déplacer les données d'un serveur derrière un pare-feu vers celui qui se trouve en face. Elles pourraient tout aussi bien vous permettre d'accéder au serveur de base de données interne à partir de la DMZ.
Solution 2:
Je ne suis pas un expert en réseau, alors corrigez-moi si je me trompe, mais un mécanisme d'interrogation nécessite toujours une sorte de communication du serveur Web pour informer le serveur de base de données qu'il a besoin de certaines données, ce qui signifie qu'un port doit être ouvert , et encore une fois, vous pourriez aussi bien leur dire de vous permettre d'accéder à la base de données interne sans les tracas, car vous n'avez pas vraiment ajouté de sécurité supplémentaire avec cette méthode.
J'espère donc que cela vous aidera au moins à vous fournir des arguments pour vous permettre d'accéder directement aux données. Pour moi, il semble qu'il y ait de nombreuses idées fausses dans votre service réseau sur la façon dont une architecture d'application Web sécurisée basée sur une base de données devrait ressembler.
Voici ce que vous pourriez faire ... c'est un peu exagéré, mais cela devrait fonctionner ...
Écrivez un service qui se trouve sur le serveur dans la DMZ. Il écoutera sur trois ports, A, B et C (choisissez les numéros de port qui ont du sens). J'appellerai cela l'application de tunnel DMZ.
Écrivez un autre service qui vit n'importe où sur le réseau interne. Il se connectera à l'application tunnel DMZ sur le port B. Une fois cette connexion établie, l'application tunnel DMZ) n'a plus besoin d'écouter sur le port B. est la "connexion de contrôle".
Lorsqu'un élément se connecte au port A de l'application tunnel DMZ, il envoie une demande via la connexion de contrôle pour une nouvelle connexion DB/autre. L'application tunnel interne répondra en se connectant à la ressource interne Une fois cette connexion établie, elle se reconnecte à l'application tunnel DMZ sur le port C.
Après avoir éventuellement vérifié certains jetons (cette partie dépend de vous), l'application de tunnel DMZ transmettra ensuite les données dans les deux sens entre les connexions qu'elle a reçues sur les ports A et C. Vous aurez effectivement un transparent TCP proxy créé à partir de deux services exécutés dans le DMZ et sur le réseau interne.
Et, pour le mieux, une fois cela fait, vous pouvez expliquer ce que vous avez fait à votre service informatique et regarder leurs visages alors qu'ils se rendent compte que vous n'avez pas violé la lettre de leur politique de sécurité, mais vous êtes toujours productif. Je vous le dis, ils détesteront ça.
Si toutes les solutions de développement ne peuvent pas être appliquées en raison de restrictions d'ingénierie système dans DMZ alors donnez-leur la balle.
Mettez votre site Web dans l'intranet et dites-leur ' Maintenant, j'ai besoin de connexions HTTP: 80 ou HTTPS: 443 entrantes pour ces applications. Configurez ce que vous voulez: proxy inverses, ISA Server , rupture de protocoles, SSL ... J'adapterai mon application si nécessaire. '
À propos d'ISA, je suppose qu'ils en ont un si vous avez un échange avec des connexions externes.
De nombreuses entreprises choisissent cette solution lorsqu'une ressource doit être partagée entre l'intranet et le public.
La mise en place d'un réseau spécifique et intranet avec des règles de sécurité élevées est le meilleur moyen de faciliter l'administration, l'intégration et le déploiement. Ce qui est plus facile est bien connu, ce qui est connu est maîtrisé: moins de faille de sécurité.
De plus en plus d'ingénieurs système (comme les mines) préfèrent maintenir un réseau intranet avec de petites "failles de sécurité" comme HTTP que d'ouvrir d'autres protocoles et ports.
Soit dit en passant, s'ils connaissaient les services WCF, ils auraient accepté cette solution. Il s'agit de la solution la plus sûre si elle est bien conçue.
Personnellement, j'utilise ces deux méthodes: les services TCP (HTTP ou non) et ISA Server).