Les exigences commerciales conflictuelles sont un problème courant – et vous le trouvez dans tous les recoins d’une organisation, y compris dans les technologies de l’information. Résoudre ces conflits est indispensable, mais ce n’est pas toujours facile – bien qu’il existe parfois une nouvelle solution qui aide.
Dans la gestion informatique, il y a une lutte constante entre les équipes de sécurité et d’exploitation. Oui, les deux équipes veulent en fin de compte disposer de systèmes sécurisés plus difficiles à violer. Cependant, la sécurité peut se faire au détriment de la disponibilité – et vice versa. Dans cet article, nous examinerons le conflit entre la disponibilité et la sécurité, ainsi qu’une solution permettant de résoudre ce conflit.
L’équipe des opérations se concentre sur la disponibilité… les équipes de sécurité se verrouillent
Les équipes opérationnelles auront toujours la stabilité, et donc la disponibilité, comme priorité absolue. Oui, les équipes opérationnelles feront également de la sécurité une priorité, mais uniquement dans la mesure où elle touche à la stabilité ou à la disponibilité, jamais en tant qu’objectif absolu.
Cela se traduit par l’objectif de disponibilité des « cinq neuf » qui définit une exigence incroyablement élevée : qu’un système fonctionne et soit disponible pour répondre aux demandes 99,999 % du temps. C’est un objectif louable qui satisfait les parties prenantes. Des outils tels que la haute disponibilité aident ici en fournissant des redondances au niveau du système ou du service, mais les objectifs de sécurité peuvent rapidement entraver l’atteinte des « cinq neuf ».
Pour les équipes de sécurité, l’objectif ultime est d’avoir des systèmes aussi verrouillés que possible, réduisant la surface d’attaque et les niveaux de risque globaux au minimum absolu. En pratique, les équipes de sécurité peuvent exiger qu’un système soit mis hors service immédiatement et non dans deux semaines, ce qui réduit la disponibilité afin de corriger immédiatement, sans parler des conséquences pour les utilisateurs.
Il est facile de voir que cette approche créerait un énorme casse-tête pour les équipes opérationnelles. Pire encore, là où la haute disponibilité a vraiment aidé les équipes opérationnelles à atteindre leurs objectifs de disponibilité et de stabilité, elle peut en fait aggraver les choses pour les équipes de sécurité qui doivent désormais s’occuper d’un nombre exponentiellement accru de serveurs ou de services, qui nécessitent tous une protection et une surveillance.
Quelle bonne pratique suivre ?
Cela crée un conflit entre les opérations et la sécurité, ce qui signifie que les deux groupes sont rapidement en désaccord sur des sujets tels que les meilleures pratiques et les processus. En ce qui concerne les correctifs, une politique de correctifs basée sur une fenêtre de maintenance entraînera moins de perturbations et augmentera la disponibilité car il y a un délai de plusieurs semaines entre les efforts de correctifs et les temps d’arrêt associés.
Mais il y a un hic : les fenêtres de maintenance ne se corrigent pas assez rapidement pour se défendre correctement contre les menaces émergentes, car ces menaces sont souvent activement exploitées quelques minutes après leur divulgation (ou même avant la divulgation, par exemple Log4j).
Le problème se produit dans tous les types de charges de travail et peu importe que vous utilisiez la dernière approche DevOps, DevSecOps ou n’importe quelle autre approche comme la saveur du jour. En fin de compte, soit vous corrigez plus rapidement pour des opérations sécurisées au détriment de la disponibilité ou des performances, soit vous corrigez plus lentement et prenez des risques inacceptables avec la sécurité.
ça devient vite très compliqué
Décider à quelle vitesse patcher n’est que le début. Parfois, le patch n’est pas simple. Vous pourriez, par exemple, avoir affaire à des vulnérabilités au niveau du langage de programmation – qui à leur tour ont un impact sur les applications écrites dans ce langage, par exemple, CVE-2022-31626une vulnérabilité PHP.
Lorsque cela se produit, un autre groupe participe au conflit entre disponibilité et sécurité : les développeurs qui doivent gérer une vulnérabilité au niveau du langage en deux étapes. Tout d’abord, en mettant à jour la version linguistique en question, ce qui est la partie la plus facile.
Mais la mise à jour d’une version linguistique n’apporte pas seulement des améliorations de sécurité ; elle apporte également d’autres changements fondamentaux. C’est pourquoi les développeurs doivent passer par une deuxième étape : compenser les changements au niveau du langage apportés par la réécriture du code de l’application.
Cela signifie également un nouveau test et même une recertification dans certains cas. Tout comme les équipes opérationnelles qui veulent éviter les temps d’arrêt liés au redémarrage, les développeurs veulent vraiment éviter les modifications de code étendues aussi longtemps que possible, car cela implique un travail majeur qui, oui, assure une sécurité plus stricte – mais laisse autrement les développeurs sans rien à montrer pour leur temps. .
Vous pouvez facilement voir pourquoi les processus actuels de gestion des correctifs provoquent un conflit à plusieurs niveaux entre les équipes. Une politique de haut en bas peut résoudre le problème dans une certaine mesure, mais cela signifie généralement que personne n’est vraiment satisfait du résultat.
Pire encore, ces politiques peuvent souvent compromettre la sécurité en laissant les systèmes non corrigés pendant trop longtemps. L’application de correctifs aux systèmes à des intervalles hebdomadaires ou mensuels en pensant que le risque est acceptable, au niveau de menace actuel, conduira tôt ou tard à une confrontation avec la réalité qui donne à réfléchir.
Il existe un moyen d’atténuer considérablement – ou même de résoudre le conflit entre les correctifs immédiats (et les perturbations) et les correctifs différés (et les failles de sécurité). La réponse réside dans un patching sans interruption et sans friction, à tous les niveaux ou au moins à autant de niveaux que possible.
Un patch sans friction peut résoudre le conflit
Le correctif en direct est l’outil de correctif sans friction que votre équipe de sécurité devrait rechercher. Grâce à la correction en direct, vous corrigez beaucoup plus rapidement que les fenêtres de maintenance régulières ne pourraient jamais espérer atteindre, et vous n’avez jamais besoin de redémarrer les services pour appliquer les mises à jour. Patching rapide et sécurisé, avec peu ou pas de temps d’arrêt. Un moyen simple et efficace de résoudre le conflit entre disponibilité et sécurité.
À TuxCare nous fournissons des correctifs complets en direct pour les composants critiques du système Linux, ainsi que des correctifs pour plusieurs langages de programmation et versions de langage de programmation qui se concentrent sur les problèmes de sécurité et n’introduisent aucun changement au niveau du langage qui autrement forcerait la refactorisation du code – votre code continuera à fonctionner tel quel, uniquement en toute sécurité. Même si votre entreprise s’appuie sur des applications non prises en charge, vous n’aurez pas à vous soucier des vulnérabilités qui se propagent dans vos systèmes via une faille de langage de programmation – et vous n’avez pas non plus besoin de mettre à jour le code de l’application.
Donc, pour conclure, dans le conflit entre disponibilité et sécurité, correction en direct est le seul outil qui peut réduire considérablement la tension entre les opérations et les équipes de sécurité.