Public DMZ architecture réseau
Il y a des années, quand j'étais étudiant, un professeur de sécurité réseau m'a appris dans une classe ce qu'est un DMZ. L'architecture qu'il a utilisée dans ses diapositives était similaire à celle-ci:
Maintenant que j'ai un emploi, mon patron, un ingénieur en sécurité avec plus de 10 ans d'expérience, a un point de vue différent. Pour lui, un DMZ ne doit pas être placé dans un "sandwich" entre le LAN et Internet. Il doit plutôt ressembler à celui illustré ci-dessous:
En cherchant avec Google des architectures de réseau avec une DMZ, j'ai trouvé différentes représentations et je suis devenu encore plus confus. Ma question est donc de savoir comment placer un DMZ dans une architecture réseau hautement sécurisée? La première représentation est-elle OK d'un point de vue de la sécurité?
Les deux sont fonctionnellement équivalents - le DMZ est effectivement dans un sandwich, car il doit avoir des connexions du monde extérieur pare-feu, mais aussi des pare-feu restreignant l'accès de celui-ci au réseau interne.
Bien que ce dernier diagramme soit souvent ce qui se passe (pour des raisons de coût - vous avez besoin de moins de pare-feu), le premier est considéré comme plus sûr car vous pouvez utiliser deux marques de pare-feu différentes, ce qui permet d'éviter une attaque sur le pare-feu les violant tous les deux. Lorsque vous utilisez un pare-feu, vous utilisez des ensembles de règles pour chaque direction et chaque connexion - et fonctionnellement, c'est la même chose que les ensembles de règles dans le deuxième exemple.
Ce n'est qu'une légère amélioration de la sécurité, car en général vous n'attaquez pas les pare-feu - vous utilisez les ports ouverts pour passer directement et attaquer le serveur Web, le serveur de messagerie, ou même passer directement pour attaquer la base de données, mais des couches de sécurité toutes Aidez-moi.
Comment placer un DMZ dans une architecture réseau hautement sécurisée?
La clé est la défense en profondeur entre les domaines de sécurité. L'étendue de l'architecture déployée dépendra des ressources disponibles, notamment des limites financières et des capacités techniques.
Défense en profondeur
La défense en profondeur est un concept d'assurance de l'information (IA) dans lequel plusieurs couches de contrôles de sécurité (défense) sont placées dans un système de technologie de l'information (TI). Il s'agit d'une tactique de superposition, pour atténuer les conséquences d'une défaillance d'un contrôle de sécurité unique. Wikipedia
Domaines de sécurité
Un domaine de sécurité est le facteur déterminant dans la classification d'une enclave de serveurs/ordinateurs. Un réseau avec un domaine de sécurité différent est séparé des autres réseaux. Wikipedia
Implémentation
Aux fins de la détermination des contrôles entre les domaines de sécurité, vous pouvez définir; Internet comme non fiable, le DMZ comme semi-fiable, et les réseaux internes comme fiables.
Par conséquent, vous utiliseriez plusieurs couches de contrôles de sécurité entre Internet et votre DMZ, qui pourraient inclure: pare-feu L3, IPS, AV, proxy inverse/équilibrage de charge, filtrage L7.
Du DMZ hôte (s) vers votre réseau interne, vous utiliseriez des couches supplémentaires de: pare-feu L3, filtrage L7 (par exemple RPC), IPS/AV.
L'accès au moindre privilège entre les domaines de sécurité est également essentiel pour maximiser l'efficacité des contrôles de sécurité.
La première représentation est-elle OK du point de vue de la sécurité?
Je conseillerais non, faute de défense en profondeur. Il n'y a qu'un seul contrôle d'accès entre Internet-DMZ et DMZ-LAN. En règle générale, une architecture hautement sécurisée comporte une séparation des fournisseurs et des couches de contrôles d'accès (L3 FW, WAF, IPS, AV, etc.).
Il n'y a absolument aucun absolu en matière de sécurité.
Du point de vue de la formation - je dirais que le premier est plus clair. Il montre que le monde extérieur passe par ces différentes couches et qu'il est plus facile de toucher le DMZ et probablement ce qui est stationné là-bas est moins risqué.
C'est aussi mieux d'un point de vue de la défense en couches - comme cela est très bien souligné dans d'autres réponses.
Mais c'est moins pratique du point de vue des coûts. Et j'ai vu de nombreuses variantes sur le diagramme inférieur - tous les réseaux de segmentation pour diverses raisons, en essayant d'en faire plus avec moins pour divers coûts ou d'autres raisons pratiques.
Honnêtement, je ne crois pas qu'il existe une "bonne voie" ou un "bon diagramme". Les facteurs comprennent:
compromis coût/risque - plusieurs couches de pare-feu avec divers fournisseurs sont certainement plus sécurisées, elles sont également plus chères. Un must have pour une opération à haute valeur/risque élevé. Trop pour une opération de faible valeur/faible risque - car il est non seulement coûteux à acheter, mais aussi à entretenir, et vous devez peser le facteur des humains qui maintiennent ces choses, et le risque de lacunes et de mauvaises configurations. Un pare-feu bien configuré vaudra mieux que deux pare-feu qui sont grands ouverts car la personne qui les configure n'en savait pas assez pour bien faire le travail!
clarté - à quoi ressemble vraiment le réseau? S'il n'y a qu'un seul pare-feu, veuillez dessiner le diagramme en conséquence, ne laissez pas les gens chercher un deuxième pare-feu. Sauf si vous parlez d'une couche logique et non d'une couche physique, auquel cas les deux "murs" peuvent être sur le même périphérique. Le but d'un diagramme est d'aider les humains à faire des choses ... un diagramme est "bien" ou "mal" uniquement en termes de sa capacité à répondre à ce besoin.
Je dirais que si votre patron prétend que son dessin est la "bonne façon" absolue - il est hors de son esprit ... il y a beaucoup d'exemples publics pour contrer cela.
Si c'est la façon la plus claire de décrire la chose avec laquelle vous travaillez, alors il a raison.
Je vais répéter certaines choses que d'autres ont dites, mais c'est parti.
Tout d'abord, je penserais à combien de sécurité est souhaitée, le coût pour y parvenir, et les problèmes qui se poseront si quelque chose échoue et la communication est perdue entre la zone sécurisée et Internet .
Votre cenario semble un peu plus sophistiqué, car il y a plus de couches du monde sombre jusqu'à ce que vos données secrètes soient atteintes. Mais cela ajoute également plus de coûts, plus de points de défaillance existent.
Le deuxième cénario est aussi sécurisé que le pare-feu. Obtenir le DMZ compromis ne facilitera pas l'attaque, car il doit passer par le pare-feu, et le pare-feu est l'élément de résistance dans tout le concept.
Et désolé, mais si la question ne portait que sur "lequel est correct: deux pare-feu ou un seul?", Je n'ai trouvé aucune référence pour le décider.
Je ne sais pas exactement ce que vous entendez par "architecture réseau hautement sécurisée". Vous devez examiner plus en détail quels sont vos objectifs de sécurité, les exigences de sécurité de l'information et le paysage des menaces dans lequel vous évoluez pour concevoir et mettre en œuvre des contrôles de sécurité appropriés.
Je vais cependant essayer de répondre à votre question à un niveau élevé.
Oui, la première architecture de sécurité est OK du point de vue de la sécurité en général. Il existe des variantes de cette architecture (par exemple, attachez-vous le DMZ aux pare-feu externes et/ou internes et/ou entre les deux), mais je ne pense pas que cela soit pertinent pour votre question à ce étape.
Ma compréhension est que cette architecture était plus populaire à une époque où les pare-feu avaient de multiples vulnérabilités publiques connues dans leur mise en œuvre qui permettraient de contourner ou même d'exploiter les pare-feu eux-mêmes et en l'absence d'autres contrôles d'atténuation.
En utilisant une implémentation différente pour vos pare-feu externes et internes, vous appliquez simplement le principe de la sélection naturelle à votre architecture et c'est généralement une bonne chose: si une implémentation est vulnérable à une attaque spécifique, la même attaque peut ne pas fonctionner sur un mise en œuvre différente si leurs traits respectifs sont suffisamment différents. Nous espérons que vous supprimez un seul point de défaillance (du point de vue de la mise en œuvre) de la "fonction de sécurité du pare-feu".
Bien sûr, en fonction de vos besoins en matière de disponibilité des informations, vous devrez peut-être envisager de regrouper vos pare-feu externes et internes, entre autres.
La deuxième architecture est également valable du point de vue de la sécurité et je pense qu'elle est désormais plus populaire que la première (coût aidant). Vous disposez d'un point de défaillance unique potentiel de la fonction de sécurité du pare-feu. Cependant, la plupart des organisations auraient (espérons-le) réalisé à ce jour que vous ne pouvez pas compter sur votre pare-feu uniquement pour fournir des services de sécurité. Routeurs/commutateurs/pare-feu hôtes/etc. peuvent tous contribuer à la posture de sécurité d'une organisation, atténuant ainsi tout ou partie des dommages causés par la compromission d'une (seule) implémentation de pare-feu. Il apparaît également que les pare-feu sont un peu plus solides de nos jours et que les attaques se sont déplacées vers des couches OSI plus élevées mais plus douces, par exemple. applications.
Je considérerais la deuxième architecture pour la plupart des déploiements. Je peux considérer la première architecture dans certaines circonstances spécifiques, y compris, mais sans s'y limiter, les objectifs et les exigences de sécurité, les motivations des attaquants potentiels et, plus important encore, les ressources.
Le risque est de loin bien pire dans le premier diagramme. Prenez du recul et lisez sur les DMZ militaires, ce sont essentiellement des endroits où vous mettez des choses que vous ne vous souciez pas de protéger. C'est une mauvaise terminologie pour commencer et une idée obsolète en informatique. Supposons maintenant que vous ayez un environnement beaucoup plus vaste avec différents niveaux de sécurité, vous ne pouvez pas jeter toutes les données dans une zone (encore moins permettre à votre pilote de trafic LAN infecté par un logiciel malveillant de le penser). Vous aurez besoin de plusieurs zones de sécurité (plusieurs DMZ si vous êtes attaché à ce terme, je les appelle des segments sécurisés). Comment ajouteriez-vous, disons, 20 zones de sécurité différentes à chacun des diagrammes ci-dessus? Continuer à les ajouter en série selon leur niveau de sécurité? ou les ajouter en parallèle au besoin? La plupart des pare-feu modernes ont plusieurs interfaces (certains grands ont jusqu'à 100 interfaces) parce que nous ajoutons des sous-réseaux sécurisés en parallèle. Dans un environnement à haute sécurité, vous pouvez avoir des zones de sécurité distinctes pour les serveurs Web, les serveurs DNS et les serveurs de messagerie, etc. . De même, si votre fournisseur de services héberge une douzaine de clients colocalisés, vous pouvez mettre chacun derrière une interface différente afin qu'ils ne puissent pas s'attaquer (ou propager des vers) différemment de l'attaque via Internet. Parcourez certains des sites Web des grands fournisseurs (Cisco et Juniper) et consultez la documentation relative à leurs plus grands pare-feu et le nombre d'interfaces qu'ils prennent en charge. Vous aurez toujours besoin de pare-feu internes et de pare-feu d'applications Web (WAF) comme Imperva (ou les proxys mod_security), mais même ces zones internes devront être segmentées et compartimentées. L'ancien schéma sandwich (architecture informatique des années 70-80) est un échec majeur en termes de sécurité et doit disparaître.
Oui, en plus de la réponse précédente, je pourrais ajouter un IPS pour bloquer les attaques que le pare-feu n'attraperait pas car ces attaques cibleraient les ports ouverts.
Cela dépend du type d'architecture réseau de votre bâtiment.
Le premier exemple est idéal pour des situations telles que l'hébergement d'une grande application Web, vous créez la sécurité dans vos couches, donc les équilibreurs de niveau, niveau d'application, niveau de données, chaque pare-feu étant protégé par différentes mesures de sécurité, mais vous travaillez sur vos propres réseaux de confiance.
Dans le deuxième exemple, exactement comment il est décrit, avec un LAN suspendu. En outre, cette option est idéale pour les situations où vous devez être en mesure de façonner le trafic pour garantir la qualité de service.
Donc, pour répondre à votre question, les deux sont valides et ont chacun leurs propres avantages, il n'y a pas de solution miracle.
La plupart des ingénieurs de pare-feu ont principalement déployé le deuxième modèle de diagramme, car un ensemble de pare-feu sont moins chers, plus faciles à configurer et à gérer. Vous pouvez utiliser chaque port du pare-feu pour une connexion physique à l'extérieur, à l'intérieur et à chaque DMZ ou utiliser plusieurs contextes (un peu comme la VM) pour séparer virtuellement les environnements. Nous utilisons le 2ème modèle dans nos centres de données plus petits et utilisons le 1er modèle avec multi FW dans nos centres de données d'entreprise. Les auditeurs adorent le 1er modèle pour les emplacements d'entreprise, car une règle mal configurée sur le 2e modèle peut provoquer un attaquant qui a pris le contrôle de votre serveur [DMZ, peut-être prendre le contrôle à l'intérieur de votre réseau. C'est beaucoup plus difficile sur le 1er modèle, car un attaquant doit traverser deux ensembles de pare-feu pour pénétrer à l'intérieur. Un administrateur de pare-feu peut faire une erreur peut-être en testant sur un pare-feu mais pas sur deux (généralement). Nous venons de déployer plusieurs pare-feu la semaine dernière. Avec les pare-feu sur Internet, connectez-vous à plusieurs DMZ et Load Balancers ... et à l'intérieur des pare-feu, connectez-vous aux mêmes DMZ/Load Balancers. Le pare-feu 2nd/inside a également un contexte multi à l'intérieur. Ce qui fournit un pare-feu entre le WAN, les environnements de production et aucun environnement de production ... où les serveurs de production peuvent accéder à tout, mais WAN peut accéder aux serveurs de production sur www et https (etc.) ou autoriser l'accès RDP aux administrateurs pour accéder à serveurs de production et DEV/QA sur le pare-feu interne.
Votre patron a raison.
La première représentation présente de nombreux problèmes ou faiblesses.
- HA (haute disponibilité): vous aurez besoin de 4 FW (2 externes et 2 internes) = $$$
- Gestion: "considéré comme plus sûr car vous pouvez utiliser deux marques différentes de pare-feu" ... beaucoup de frais généraux de gestion (mise à jour, règles, journalisation, licences). Si vous ne pouvez pas faire confiance à votre FW et que vous en avez besoin d'un autre d'un fabricant différent, vous avez un problème !!!
- IP: cette conception peut être un cauchemar avec natting, routage, etc.
- Risque: dans cette conception, un hôte compromis DMZ est dans un bel endroit pour renifler et attaquer l'homme du milieu contre les utilisateurs de la zone LAN.
Dans la vraie vie, le deuxième design est plus sûr et plus simple que le premier.
- HA (haute disponibilité): vous avez juste besoin d'un autre FW.
- Gestion: une seule boîte à gérer
- IP: point unique pour gérer le trafic de routage ou de nating
- Risque: si un hôte dans le DMZ est compromis, cette menace est contenue dans la DMZ
La réponse à la question de savoir laquelle des deux conceptions est "correcte" ne peut être fondée que sur les exigences imposées à la solution en cours de conception. En tant que tels, les deux modèles ont des avantages et des inconvénients, mais cela se résume vraiment à DEUX PILOTES D'AFFAIRES DIFFÉRENTS PRIMAIRES:
Si l'entreprise fait des exigences avec des déclarations comme:
"Nous avons besoin d'une conception de sécurité Internet/DMZ qui est ...
* rentable, coût le plus bas, conception simple et simple, simple à gérer, bon marché et sale, protection adéquate ... * etc."
Ensuite, le FW 3-LEGGED (exemple # 2) sera le modèle que vous devriez utiliser comme base pour votre conception. Et dans un monde où "ÉPARGNEZ $$$" "Réduisez les coûts" sont souvent les moteurs n ° 1, c'est le principal facteur pour lequel la conception à 3 LEGGED FW est de loin le déploiement le plus populaire - même pour les grandes organisations.
Si l'entreprise fait des exigences avec des déclarations comme:
"Nous avons besoin d'une conception de sécurité Internet/DMZ qui est ...
hautement/extrêmement sécurisé, offre la meilleure protection Internet quel que soit le coût, la protection de nos systèmes d'entreprise internes est un MUST ... etc. "
Ensuite, le modèle FW-Sandwich/2-Teir FW/Layered DMZ (exemple # 1)) est celui que vous devriez utiliser comme base pour votre conception.La raison est extrêmement simple ... Layered DMZ security ajoute des barrières uniques supplémentaires à l'entrée pour le pirate Internet. S'il parvient à travers le premier FW, il atterrit à la couche suivante, puis à la suivante, puis au FW interne backend avant a finalement atteint les joyaux de la couronne de données d'entreprise.Le modèle FW à 3 LEGGED est 1 couche de protection par laquelle si FW mal/mal configuré est compromis - il a un accès direct au réseau interne. MAUVAIS!
Mes conceptions passées sont plus complexes qu'un FW avant et arrière. Dans une conception ISP/DMZ extrêmement hautement sécurisée, j'ai architecturé FW, IPS, front VIP network, DMZ VIP Load) Équilibreurs, réseaux de fermes privées, puis les serveurs d'interface internes dorsaux. Chacune de ces couches ajoute une barrière supplémentaire à l'entrée pour le pirate. Nous définissons également des règles de conception strictes qui stipulent que "une couche dans la conception ne doit parler que au calque suivant et ne pas contourner ce calque comme raccourci "
Cette conception est certainement plus coûteuse, mais pour les grandes entreprises où les banques, les finances, les grandes bases de données d'informations sur les clients, etc. DOIVENT ÊTRE PROTÉGÉES, il serait stupide d'utiliser un FW à 3 pattes qui en fait la seule barrière entre les pirates et ceux-ci joyaux de la couronne.