Pare-feux : Plannifiez des fenêtres de changement de règles

La seule constante était que rien n’était constant. La société avait 100 pare-feux répartis dans 5 centres de données au service de plus de 10 lignes d’activités différentes.

Les demandes de changement des règles de pare-feu arrivaient de partout, à tout moment, et malgré des tentatives pour imposer des « fenêtres de changement ». Il y avait toujours une bonne raison pour que la demande ne puisse pas attendre. Il est rapidement devenu évident que nous passions beaucoup trop de temps à apporter des modifications hors des « fenêtres de changement » planifiées – en fait, 38 pour cent des modifications, chiffre considérable, étaient réalisées en dehors de ces fenêtres de changement.

Compte tenu du fait que c’était le principal souci pour notre équipe, je l’ai mis en tête de la liste des choses à corriger. Chaque changement étant traité comme une modification majeure, nous avons décidé de créer trois filières pour modifier les pare-feux basées sur le degré critique du changement demandé. Étant donné que davantage de changements augmentent le risque que quelque chose tourne mal, nous nous sommes assurés que les unités opérationnelles étaient conscientes que, lorsqu’elles demandaient la modification d’une application ou d’un service qui ne pouvait en aucun cas être interrompu, elles devraient patienter. Nous avions cessé de tout laisser tomber pour corriger une panne qui résultait d’une modification qui aurait pu attendre. Le nombre de fois où une nouvelle règle de pare-feu ou de proxy est rendue nécessaire par la simple mise à jour d’une application, est incroyable.

Après leur avoir présenté les choses en ces termes, il est devenu clair que la disponibilité était la charnière entre nos deux mondes. Nous avons donc défini les fenêtres de changement en termes de disponibilité. Une grande partie de l’infrastructure était, heureusement, déjà en place, et nous avions seulement besoin d’en revoir l’architecture. Nous avons créé trois « zones démilitarisées », chacune disposant de ses propres grappes de pare-feux. Les applications ont été classées en trois catégories. Les directions opérationnelles pouvaient ainsi choisir la disponibilité qui leur convenait. Les filières étaient les suivantes :

• Disponibilité minimum : 89 % de disponibilité : les modifications étaient faites tous les jours

• Disponibilité moyenne : 99 % de disponibilité : les modifications étaient faites deux fois par semaine

• Disponibilité haute : 99,9 % de disponibilité : les modifications étaient faites une fois par semaine

Notre travail consistait à nous assurer que nous implémentions bien les filières en imposant ces trois séries de fenêtres de changement, et il y eu de nombreuses discussions avec les groupes opérationnels pour définir quelle application appartenait à quelle filière. Ces changements dans nos processus impactaient également les pratiques d’autres équipes – par exemple, lorsqu’un nouvel employé entrait dans l’entreprise, il ou elle pouvait attendre plus longtemps que prévu pour accéder à certaines applications. Grâce à ce processus, nous avons appris à mieux connaître les besoins de l’entreprise et, au fil du temps, nous avons tous été en mesure de prendre de meilleures décisions.

Par exemple, les serveurs de gestion et les applications de surveillance avaient tendance à être à faible disponibilité et auraient probablement eu besoin de changements quotidiens (disponibilité faible). Les serveurs de messagerie et d’applications, les serveurs Web, à disponibilité moyenne, nécessitaient des changements hebdomadaires, tandis que les serveurs de bases de données, d’authentification, de facturation et les portails de paiement étaient strictement à disponibilité élevée. Ne pouvant nous permettre une interruption de ces systèmes, qui affectaient trop d’applications tierces, ils étaient donc mis à jour uniquement le samedi soir à minuit.

Le facteur important pour faire adopter les fenêtres de changement, est que nous avons tous pris le temps de discuter entre nous et de définir ce qu’étaient les applications les plus critiques. Nous en avons fait une liste et, ensemble, nous avons déterminé quelle application allait dans quelle fenêtre de disponibilité et pourquoi. La partie la plus difficile dans ces réunions a été leur planification – réunir toutes les personnes concernées au même moment…

Mais cela en valait la peine. On dit qu’une bonne informatique est la résultante de personnes, de processus et de technologie et c’était certainement le cas ici. Un des principaux résultats de ces réunions est de nous avoir permis de faire confiance à notre jugement concernant le choix des filières où les modifications devaient figurer. Lorsqu’un doute existait sur le choix de la filière dans laquelle devait être placée la modification, nous travaillions ensemble pour le définir.

L’étape logique suivante – surtout pour une entreprise de notre taille avec d’aussi nombreux pare-feux – était d’automatiser nos nouveaux processus. Mis à part le fait que, comme dans tant d’autres opérations de sécurité, notre domaine de pare-feux était devenu trop complexe à gérer sans automatisation, notre approche a facilité la mise en oeuvre de nos nouveaux processus. De plus, grâce à l’automatisation, la base de connaissances pouvait facilement être transmise : si quelqu’un quittait la société ou tombait malade, quelqu’un d’autre pouvait intervenir et maintenir les opérations de façon sécurisée et conforme.

En un an, nous avons réduit le nombre des modifications effectuées à l’extérieur des fenêtres de changement planifiées de 38 % à moins de 10 %. Le temps économisé nous a permis de nous concentrer sur l’optimisation. Mais le retour sur investissement intangible a été tout aussi important – notre niveau de stress a diminué et nous avons économisé le temps passé à tourner en rond ou à auditer manuellement des bases de 500 règles pour réparer une panne causée par une modification qui ne pouvait pas attendre. Nous avons employé ce temps pour resserrer nos politiques de conformité, nettoyer nos pare-feux et déployer de nouveaux services.

Depuis lors, j’ai aidé des centaines d’entreprises à résoudre leurs problèmes identiques ou semblables – et la formule : « évaluer, mettre en oeuvre et automatiser » ne m’a encore jamais fait défaut.