Lorsque vos microservices commencent à discuter tranquillement : la sécurité est importante

Imaginez que vous ayez passé plusieurs mois à construire un système. Ces microservices exquis sont comme un groupe de membres d’une équipe bien formés, travaillant individuellement et ensemble en parfaite harmonie. Mais un jour, vous constatez que personne ne prête attention aux messages qui circulent entre eux. Le mot de passe est bien visible et le contrôle d'accès est inefficace, comme si les secrets d'affaires étaient écrits sur des cartes postales et envoyés partout. Cette sensation vous donne-t-elle froid dans le dos ?

Nous avons rencontré trop de scénarios similaires. Ce n’est pas que tout le monde ne prête pas attention à la sécurité, mais que les microservices sont trop « discrets ». Chaque service est en mouvement et les liens sont si longs que les murs de sécurité traditionnels ne peuvent pas les couvrir. Les vulnérabilités peuvent surgir des petits coins auxquels vous vous attendez le moins.

Quel est le problème ?

Ne vous précipitez pas encore pour vérifier le code. Bien souvent, la racine du problème n’est pas la profondeur technique, mais l’idée. Vous pensez que la « communication interne » est sûre, vous pouvez donc vous authentifier à votre guise et économiser sur le cryptage de la transmission si vous le pouvez. Ou bien, chaque équipe utilise des normes de sécurité différentes. Le service A est extrêmement strict, mais le service B a une porte ouverte.

Le plus souvent, il y a trop de choses à gérer. Les clés volent partout, les certificats expirés sont ignorés et la question de savoir qui a le droit d'accéder à quelle base de données est devenue une question confuse. Les attaquants aiment le plus ce genre de « chaos ». Ils n’ont pas besoin de forcer la porte, ils trouvent simplement une fenêtre latérale non verrouillée et se faufilent à l’intérieur.

Alors, à quoi ressemble une approche fiable ?

Vous devez changer de façon de penser : vous ne pouvez plus considérer la sécurité comme un mur extérieur, mais en faire une « méthode de conversation » entre les services à chaque instant. Tout comme les appareils intelligents de votre maison, lorsqu’ils sont reliés entre eux, ils doivent d’abord confirmer que « vous êtes vous ».

Premièrement, l’identité est une règle de fer. Chaque microservice, voire chaque appel, doit disposer d'une « carte d'identité » unique et vérifiable. Aucune demande ne peut être autorisée pour usurper l'identité de quelqu'un d'autre. Il ne s’agit pas seulement de se connecter, il s’agit d’une chaîne de confiance tout au long.

Deuxièmement, le cryptage des communications est standard et non facultatif. Quelle que soit la distance parcourue par les données sur le réseau, même si elles vont uniquement d’un point A à un point B, elles sont verrouillées. Utilisez les protocoles obligatoires les plus récents et ne laissez aucune chance à la transmission de texte clair.

Troisièmement, l’autorité doit être détaillée, jusqu’aux os. « Pouvoir accéder au service A » ne signifie pas pouvoir accéder à toutes ses données et fonctions. Vous devez suivre le principe du moindre privilège, accorder juste assez d'autorisations et les réviser de temps en temps.

C’est facile à dire, mais est-ce que cela posera beaucoup de problèmes à faire ? C’est là que beaucoup d’équipes se retrouvent bloquées.

Comment faire pour que ce ne soit plus « douloureux » ?

L’essentiel est de ne pas faire de la sécurité un lourd fardeau. Il doit être facilement intégré à votre processus de développement. Par exemple, la politique de sécurité doit être générée automatiquement en tant qu'élément de base au moment de la création du service, plutôt que d'être ajoutée après coup.

Une gestion unifiée est essentielle. Vous ne pouvez pas laisser chaque équipe créer son propre système de mots de passe. Vous avez besoin d'un endroit centralisé pour gérer les clés, les certificats et les politiques sans devenir un point de défaillance unique. Cela garantit la cohérence sans ralentir le développement.

De plus, vous ne pouvez bien vous débrouiller que si vous pouvez voir. Vous avez besoin de journaux clairs et d’une surveillance capable de voir toutes les traces d’accès entre les services en un coup d’œil. Un comportement anormal peut être alerté immédiatement, au lieu d'attendre qu'un problème survienne et de chercher ensuite une aiguille dans une botte de foin.

L'automatisation est votre amie. La configuration manuelle des règles de sécurité entraînera des erreurs tôt ou tard. Essayez d'utiliser une approche déclarative pour définir les politiques et laissez l'outil les exécuter et les synchroniser automatiquement. Cela permet de gagner beaucoup de temps et d'éliminer la négligence humaine.

Est-ce que quelqu'un fait vraiment ça ?

certainement. Lorsque chez Kpowe nous aidons nos clients dans la mise en œuvre, nous commençons souvent avec un groupe de services restreint mais central à titre pilote. Par exemple, assurez-vous d’abord que tous les services liés à l’identité des utilisateurs réalisent une authentification et un chiffrement monolithiques. L'effet a été immédiat : les demandes d'accès inexplicables dans le journal ont disparu et les alarmes du système sont devenues beaucoup plus silencieuses.

Les clients ont constaté que cela ne ralentissait pas leurs itérations. La sécurité faisant désormais partie de l’infrastructure, les développeurs n’ont plus à se soucier des correctifs de sécurité temporaires. Lorsqu’un nouveau service est lancé, il hérite directement d’un paradigme de sécurité mature, le rendant fiable et sans souci.

faire le premier pas

Si vous sentez que vous êtes confus, il est préférable de commencer par un « audit de communication » approfondi. Sortez votre schéma d'architecture, dessinez tous les flux de données entre services, puis posez-vous quelques questions simples : les données sur cette ligne sont-elles cryptées ? L'appelant a-t-il été identifié ? Avez-vous donné trop de permissions ?

La réponse pourrait vous surprendre. Trouver les maillons faibles est le début du renforcement.

La sécurité des microservices n’est pas un « projet » qui peut être résolu une fois pour toutes. C'est un état permanent. Tout comme rester en bonne santé, cela nécessite des habitudes quotidiennes et quelques outils. Si vous y réfléchissez de manière trop complexe, vous n’oserez pas le faire ; si vous y réfléchissez simplement, vous serez confronté à des dangers cachés.

En dernière analyse, ne s'agit-il pas simplement de permettre aux militaires de discuter librement sans laisser les conversations privées être écoutées ? Trouvez cet équilibre et votre système pourra être véritablement flexible tout en permettant aux gens de dormir paisiblement. Kpowe a parcouru cette route en profondeur. Nous savons où les pièges sont susceptibles de se présenter et nous savons également comment marcher avec plus de régularité. La sécurité vaut votre temps et vos efforts pour bien faire les choses.

Créé en 2005,kpuissancea été dédié à un fabricant professionnel d'unités de mouvement compactes, dont le siège est à Dongguan, province du Guangdong, en Chine. Tirant parti des innovations en matière de technologie d'entraînement modulaire,kpuissanceintègre des moteurs hautes performances, des réducteurs de précision et des systèmes de contrôle multiprotocoles pour fournir des solutions de systèmes d'entraînement intelligents efficaces et personnalisées.kpuissancea fourni des solutions de systèmes d'entraînement professionnelles à plus de 500 entreprises clientes dans le monde avec des produits couvrant divers domaines tels que les systèmes de maison intelligente, l'électronique automatique, la robotique, l'agriculture de précision, les drones et l'automatisation industrielle.