Pourquoi les serveurs doivent-ils être placés en dehors du réseau d'entreprise?
Dans un réponse à Comment gérez-vous les analyses massives de ports? , l'utilisateur tylerl a déclaré:
... Et vous, comme un administrateur informatique avisé, exécutez tous vos serveurs ailleurs sur Internet, pas à l'intérieur de votre réseau d'entreprise, pour toute une série de raisons que je n'entrerai pas ici
En tant qu'administrateur informatique peu avisé, quelles sont ces raisons?
Avoir tous vos serveurs d'entreprise dans le même réseau est une mauvaise idée car si l'un des serveurs est compromis, l'attaquant peut facilement se propager aux autres. Les serveurs sont souvent configurés pour être sécurisés sur le front-end, mais lorsqu'il s'agit de serveurs communiquant entre eux, il existe différentes façons de trouver des vulnérabilités. De plus, la sensibilité des données n'est souvent pas la même. Alors qu'un serveur Web est important pour la disponibilité, un serveur de base de données contient souvent de précieuses données client. Les séparer est en tout cas une bonne idée.
Les fournisseurs d'hébergement spécialisés pour des serveurs spécifiques sont également capables de maintenir leurs serveurs plus sécurisés.
Grâce à Internet, il n'y a aucune raison de ne pas séparer les serveurs, sauf si votre application dépend tellement du temps que, par exemple, les serveurs de base de données doivent être accessibles directement.
Il n'y a rien de mal à exécuter des serveurs à l'intérieur du réseau d'entreprise - sauf que le réseau d'entreprise ne doit pas être un réseau large et plat. Vous devez envisager de séparer les actifs et les utilisateurs dans différentes "zones", puis d'écrire des règles qui permettent un accès correct (et prévu) entre ces zones. dans votre modèle, incluez une "zone Internet" ainsi que tous les liens directs vers des tiers que votre entreprise peut avoir (par exemple, VPN aux fournisseurs)
J'utiliserais toujours des pare-feu plutôt que de simplement diviser le réseau en VLAN. Les pare-feu offrent de meilleures fonctionnalités pour créer des règles (ou des groupes de règles) afin que vous puissiez mettre en liste blanche le trafic que vous prévoyez de faire circuler entre les zones.
Vous pouvez placer des contrôles de sécurité aux frontières intra-zone, tels que:
- Rapports IPS/IDS à votre Soc/SIEM
- Fonctionnalité de liste de contrôle d'accès (prise en charge par certains fabricants de pare-feu) qui vous permettra de vous assurer que seuls les utilisateurs autorisés peuvent accéder à une zone, où résident des serveurs/applications. Bien sûr, votre journal DENY sera utile pour le SoC
L'organisation des zones sera différente pour chaque organisation, mais les exemples communs sont:
- séparer le développement/les tests de la production
- séparation des utilisateurs des serveurs de production
- la séparation des serveurs d'applications à haut risque ou hautement sensibles des serveurs d'applications non sensibles
Il y a des risques. Attention à ne pas trop faire le nombre de zones et à le rendre trop complexe. Sinon, le fardeau du maintien des règles deviendra un gros coût. Envisagez d'investir dans un pare-feu doté d'une bonne gestion des règles ou même d'une application de gestion des règles distincte (par exemple, Tuffin SecureTrack +, il y en a d'autres également).
Sachez également que certains fournisseurs de pare-feu disposent de méthodes propriétaires pour ajouter des listes de contrôle d'accès aux règles; ceux-ci peuvent avoir un impact important sur les performances du pare-feu et vous devrez peut-être un kit plus grand que prévu.
Les serveurs doivent généralement être accessibles à partir d'Internet, donc la conception de votre réseau doit autoriser les connexions d'Internet au réseau où se trouvent vos serveurs. Maintenant, si vous placez les serveurs dans le réseau interne, cela signifie que vous devez exposer le réseau interne à Internet par conception . =
Et il n'y a de toute façon aucune raison de mettre les serveurs dans le réseau de l'entreprise. Même si les serveurs sont utilisés à partir des postes de travail du réseau de l'entreprise, ils n'ont généralement pas besoin d'établir de connexions avec les postes de travail.
Sans ressasser ce que d'autres ont déjà fait ressortir, voici quelques raisons supplémentaires du point de vue de l'administrateur réseau:
Garder vos serveurs sur une zone de sécurité, un sous-réseau et VLAN fournit la segmentation du réseau. Cela réduira le trafic de diffusion inutile vers vos serveurs et fournira plus de bande passante entre le trafic de serveur à serveur. La segmentation du réseau est un une partie importante de la sécurité et de la conception du réseau sur laquelle je vous encourage à en savoir plus.
Et dans le même ordre d'idées: avec une zone de sécurité distincte, forcer vos clients à traverser un pare-feu matériel pour communiquer avec vos serveurs permet un contrôle beaucoup plus précis sur le trafic autorisé vers et depuis vos serveurs. Cela peut servir à diverses fins de sécurité et peut également aider à empêcher les virus tels que les vers d'avoir même la possibilité d'exploiter un port sur votre serveur qui est autrement ouvert et sensible aux attaques. Les clients vont naturellement être moins sûrs car vos utilisateurs ont la possibilité, à des degrés divers, de faire des choses peu sûres sur et avec eux. Les serveurs, cependant, vous avez un contrôle total sur.
Vous pouvez segmenter davantage les serveurs en deux zones distinctes. Une zone serait réservée à vos serveurs internes qui ne fournissent pas nécessairement d'hébergement et n'ont pas besoin d'être accessibles par le monde extérieur. L'autre zone serait un type de serveur-DMZ où les serveurs qui sont accédés par le monde extérieur pour quelque soit leur hébergement et auraient un ensemble complètement différent de paramètres de sécurité.