Les modifications des réseaux de l’entreprise, l’ajout de nouveaux serveurs, la mise à jour des règles de pare-feu ou le remplacement d’équipements peuvent être des tâches complexes. Réalisées fréquemment, ces tâches souvent traitées manuellement deviennent le principal problème de tous les administrateurs de réseaux et de serveurs. C’est aussi un exercice difficile. Lorsque la mise en œuvre d’un changement prend trop de temps, le lancement d’un nouveau service s’en voit retardé. Toutefois, en implémentant une modification trop rapidement, sans en vérifier d’abord l’impact sur le réseau, des erreurs de configuration risquent de se produire, exposant ainsi le réseau à des risques potentiels.
Voici cinq des défis les plus courants qui concernent les modifications liées au réseau.
Clonage de serveur
Les administrateurs de serveur demandent constamment aux administrateurs de réseau d’ajouter des règles de pare-feu pour les nouveaux serveurs. Ces demandes s’expriment souvent de la manière suivante : « Pouvez-vous accorder au serveur Y, qui est un nouveau serveur, le même accès réseau que le serveur X ? » Pour la plupart des administrateurs de serveur, c’est là que s’arrête leur implication. De leur point de vue, ils ont fait leur travail : le serveur est en ligne et prêt à fonctionner. Mais c’est en réalité le début de la bataille des équipes réseau/pare-feu. La solution consiste à localiser toutes les règles d’accès pertinentes dans l’ensemble de l’environnement et d’ajouter automatiquement le nouveau serveur Y à ces règles.
Mise hors service du serveur
Dans le scénario ci-dessus, lorsque les administrateurs de serveurs ajoutent le nouveau serveur Y au réseau, il est nécessaire de savoir s’il doit remplacer un autre serveur (serveur X) obsolète ? Si tel est le cas, comment garantir que l’accès au réseau du serveur X soit supprimé ? Un flux de travail relatif à la mise hors service des serveurs est une réponse adaptée à la suppression de l’accès aux serveurs devenus inutiles sur le réseau. Ainsi, il est possible de réduire le risque que l’ancienne adresse IP de ce serveur ne soit réaffectée et utilisée, par exemple, par des utilisateurs malveillants pour accéder à d’autres actifs. Il sera alors possible de supprimer l’accès de l’ancien serveur tout en maintenant le contrôle du processus.
Demandes de connectivité des applications
Les administrateurs de pare-feu travaillent en permanence avec des organisations qui traitent plus d’un millier de modifications par mois. Les ingénieurs, qui ont de nombreuses autres tâches, telles que la mise à niveau de pare-feu, le remplacement d’une infrastructure réseau vieillissante et le dépannage de problèmes réseau courants, gèrent souvent ces modifications manuellement, ce qui entraîne des coûts importants et des retards dans l’application des modifications. Dans ce contexte, il peut être utile de s’intégrer à un système de ticket. Une réponse consiste à automatiser le flux de travail qui identifiera les règles qui doivent être implémentées et à les comparer à la stratégie de sécurité définie.
Recertification de règles
Voici un exemple de requête formulée fréquemment aux équipes chargées de la gestion des pare-feux : « Pouvez-vous ouvrir les ports X, Y et Z aux serveurs A, B et C pendant 90 jours, pendant que nous testons un nouveau widget ? » Cela concerne plusieurs équipes qui expérimentent constamment de nouvelles technologies nécessitant un accès à d’autres zones du réseau. Mais avec des équipes réseaux toujours plus sollicitées, comment se souvenir que la règle demandée soit supprimée dès le 91e jour ? Pour cela, il est crucial de s’appuyer sur un dispositif permettant de voir aisément les règles à venir, celles qui vont expirer… L’administrateur peut alors prolonger le temps nécessaire ou confirmer que les règles peuvent être désactivées ou supprimées.
Déploiement de serveurs sans vulnérabilité
Lorsqu’un administrateur de serveur déploie un nouveau serveur et demande l’accès à celui-ci, le nouveau serveur est ajouté manuellement à tous les pare-feu. Mais, le système d’exploitation du serveur a-t-il été corrigé ? A-t-il été mis à jour ? Y a-t-il une vulnérabilité critique qui devrait l’empêcher d’être exposé au réseau ? Comment le savoir ? Pour cela, il est fondamental de pouvoir exercer dès le départ des scans de vulnérabilité qui permettront de déployer le nouveau serveur en toute confiance.