BLOG

Sécurité moderne pour environnements modernes

Miniature F5
F5
Publié le 29 novembre 2021


Autrefois, l’architecture d’entreprise était physique et singulière, idéalement située au même endroit, qui pouvait être facilement gérée et sécurisée.

Aujourd’hui, la situation s’est inversée. La ruée vers la numérisation oblige les organisations à évoluer à une vitesse sans précédent. Les organisations qui ont adopté des méthodologies agiles et des pratiques DevOps ont pu moderniser leurs environnements, leurs piles application et leurs déploiements, en décomposant des applications auparavant monolithiques en architectures de microservices, en automatisant les tâches de routine, en adoptant Kubernetes (k8s) pour la gestion des conteneurs et en passant au cloud public pour la fourniture de services agiles.

Bien que cela ait grandement amélioré la commodité pour les organisations et leurs utilisateurs finaux, cela s’est accompagné de problèmes de sécurité importants.

Face à ce rythme de changement, la sécurité est restée, pour l’essentiel, à la traîne. Dans de nombreux cas, DevOps a été mis en œuvre et distribué sans intervention en matière de sécurité, ce qui oblige le service informatique à corriger les problèmes au fur et à mesure qu'ils surviennent et, dans certains exemples publics significatifs, après qu'ils se soient produits.

Alors, quelle est la meilleure façon d’alléger la pression sur les technologies de sécurité, tout en prévenant les violations, sans créer de frictions entre les utilisateurs ?

S’éloigner de la sécurité centralisée

À bien des égards, les besoins de sécurité lors de la décentralisation dans des environnements virtualisés ont pris les organisations par surprise.  À mesure que nous nous éloignons de nos contrôles de sécurité centralisés traditionnels, les contrôles distribués dont nous disposons ne sont pas vraiment suffisants.

Étant donné que les environnements centralisés étaient bien connus et quantifiés, il était relativement facile d’obtenir une uniformité des contrôles de sécurité, des opérations, des rapports et des alertes. Les changements apportés aux technologies adoptées ont été peu fréquents en raison des investissements importants, de la propriété intellectuelle accumulée et du coût élevé du changement.

La prise en charge de plusieurs nouveaux environnements a entraîné une série de défis et de considérations, tels qu'un manque de maturité et de capacité, des environnements cloud disparates, un mélange de technologies, des opérations peu claires, une faible visibilité, des rapports difficiles et souvent une faible maturité.

En réponse à ces défis, les fournisseurs de cloud public nous ont fourni des passerelles de transit, un point de contrôle central où transite tout le trafic vers et depuis les locataires.

Dans les environnements modernes, avec des applications distribuées sur plusieurs clouds, locataires et centres de données, il est tout à fait logique de disposer d'une sécurité au sein de chaque application. Cela garantit que la sécurité est inhérente, c'est-à-dire qu'elle ne peut pas être oubliée, supprimée ou contournée. Cela signifie également que la sécurité est en place quand et où elle est nécessaire et supprimée dans le cadre de la phase de mise hors service de application .

Ce modèle offre également la possibilité à la sécurité de « se déplacer vers la gauche » en étant présente à toutes les étapes du cycle de vie et dans tous les environnements. Cela signifie que les contrôles de sécurité ne sont pas rencontrés pour la première fois lors du déploiement et de l’exécution, ou lors de la préproduction et de la production.

Apporter la sécurité à l'organisation

Les équipes de sécurité souhaitent s’éloigner du rôle de « bureau du non » en apportant la sécurité à l’organisation, plutôt qu’en faisant glisser l’organisation vers la sécurité. À notre avis, la meilleure façon d’y parvenir est de permettre aux équipes DevOps de consommer la sécurité de la manière qui répond à leurs besoins. Cela signifie mettre en œuvre et utiliser la sécurité dès le début d’une application ou d’un programme, plutôt qu’après.

Appelé « déplacement vers la gauche » de la sécurité, cela signifie mettre en œuvre des contrôles de sécurité à des stades plus précoces du cycle de vie du développement, par exemple : Modélisation des menaces, tests de sécurité des application statiques, analyse de la composition logicielle et mise à disposition de contrôles de sécurité à un stade ultérieur dans des environnements à un stade antérieur, par exemple : Pare-feu application Web, tests de sécurité application dynamiques, etc. dans les environnements de développement et de test.

Bien sûr, la sécurité distribuée tend à apporter son lot de défis. Pour parvenir à une sécurité distribuée, il faut traditionnellement disposer de technologies, de piles et de contrôles différents pour différents environnements. Cela ne génère aucune économie d’échelle car la diversité des environnements augmente et il devient exponentiellement plus difficile de prendre en charge chaque nouvel environnement disparate et ensemble de contrôles.

Cela signifie également que vous obtenez peu de cohérence en matière de sécurité dans différents environnements, ce qui peut entraîner des problèmes. Le plus important est sans doute que vous disposez également d’alertes, de rapports et de journaux différents pour chaque environnement, ce qui rend très difficile la gestion ou la prévision de vos environnements.

Où allons-nous alors ?

Dans un monde idéal, comment fonctionne la sécurité dans un environnement décentralisé avec plusieurs utilisateurs, applications et clouds ?

La réponse est une pile uniforme qui peut être déployée partout où cela est nécessaire. La pile serait de petite taille, adaptée aux environnements modernes et prendrait en charge un déploiement et un déclassement rapides. Il comprendrait également des contrôles de sécurité complets, matures et de niveau entreprise.

Il y aurait un point de contrôle central ; un point unique pour définir la politique une fois pour toutes et la déployer à l’échelle mondiale. La définition des politiques serait flexible et définie en fonction du réseau, de l’identité, de la sécurité et des application . Le point de contrôle central fournirait également une visibilité, une journalisation et des rapports centralisés et uniformes.

Et l'ensemble de la solution serait 100 % piloté par API pour permettre véritablement aux équipes de développement, de sécurité et d'exploitation d'évoluer de manière collaborative au rythme de l'entreprise.

F5 peut vous aider à réaliser une telle vision. En savoir plus.