Microservices, une technique de développement logiciel comme l’exprime Wikipedia. Sa mission, structurer une application comme un ensemble de services faiblement couplés. Les microservices indépendants communiquent les uns avec les autres en utilisant des API indépendantes du langage de programmation. Ce petit monde demande une véritable réflexion sécurité. Explication!
La société de cybersécurité Québécoise 8Brains vient de publier une réflexion sur la sécurité et les architectures microservices. L’avènement des Architectures Microservices requière une approche différente dans la mise en place des pratiques de sécurité.
Construire ce type d’Architecture ? Garder à l’esprit que la sécurité doit être adaptée à ces nouvelles règles.
Une Architecture Microservices n’a pas une équipe dédiée. Bilan, sa sécurité est multiple. Les équipes qui livrent le nouveau service se doit de se pencher sur la sécurité de son livrable.
Un aspect organisationnel souvent négligé « voir complètement oublié » indique Bruno Philippe, spécialiste des architectures de sécurité au sein de 8Brains.
D’abord, pour un Microservice donné, l’équipe en charge doit définir sa couche technique (Framework) : le(s) langage(s) utilisé(s), son dépôt de données, les mécanismes de déploiement, les mécanismes d’échanges avec les autres Microservices, etc.
Cette équipe doit donc se poser notamment les questions suivantes : Quelle taille doit faire notre Microservice ? Que doit contenir notre Microservice comme logiciels ? Pour un langage donné, quels sont les principes de développement sécurisés ? Pour un outil de déploiement donné, y-a-t-il des alertes de sécurité ? Si oui, sont-elles installées ? Quelles sont les autres Microservices qui échangent avec le nôtre ? Que devons-nous échanger ?
L’article complet, avec les réponses, à découvrir ici.
