paint-brush
Moins de temps pour apprendre, plus de temps pour gagner du temps : une quête de microservices sécurisés par@johnjvester
1,341 lectures
1,341 lectures

Moins de temps pour apprendre, plus de temps pour gagner du temps : une quête de microservices sécurisés

par John Vester6m2024/05/28
Read on Terminal Reader

Trop long; Pour lire

L’adoption sécurisée du cloud ne nécessite plus d’investissement dans des connaissances propriétaires en matière d’infrastructure cloud, ce qui permet aux équipes de mettre en œuvre des solutions adaptées à l’entreprise. Plongez dans la comparaison entre AWS et Heroku pour un déploiement sécurisé de microservices. Découvrez les avantages des espaces privés et de Heroku Shield d'Heroku en matière de conformité, offrant une alternative stratégique en matière d'adoption du cloud et de gestion de l'infrastructure.
featured image - Moins de temps pour apprendre, plus de temps pour gagner du temps : une quête de microservices sécurisés
John Vester HackerNoon profile picture
0-item
1-item


En 2018, j'ai décidé d'utiliser mon temps libre pour contribuer à moderniser l'entreprise d'un membre de ma famille. En cours de route, je souhaitais acquérir une certaine expérience et compréhension d' AWS.


En fin de compte, j'ai découvert que presque tout mon temps libre était consacré à l'apprentissage des concepts d'infrastructure cloud AWS. Il ne me restait qu'une petite fraction de mon temps pour me concentrer sur la création de la solution cloud moderne que j'avais initialement en tête. Alors que je planifiais davantage de demandes de fonctionnalités pour l'application, j'ai réalisé que j'avais besoin d'une meilleure approche.


Début 2020, j'ai découvert Heroku. Comme je n'avais pas à me soucier des configurations cloud sous-jacentes, je pouvais consacrer mon temps à l'ajout de nouvelles fonctionnalités.


L'écosystème Heroku a très bien fonctionné pour mon cas d'utilisation simple, mais j'ai commencé à m'interroger sur des cas d'utilisation plus complexes. Qu’en est-il du scénario dans lequel un ensemble de services sécurisés et privés doivent interagir les uns avec les autres pour une solution de traitement des paiements ?

Ce cas d’usage m’obligerait-il à vivre dans l’écosystème de l’un des trois grands fournisseurs de services cloud ? Je vais le découvrir.


L’état actuel des microservices sécurisés

Pendant plusieurs années, j'ai eu la chance de travailler dans un environnement valorisant le cycle de vie DevOps . L'équipe DevOps s'est occupée de tout ce qui concerne le cloud pour moi, afin que je puisse me concentrer sur l'architecture et la création de microservices pour répondre aux besoins de mes clients.


À cette époque de ma vie, cet environnement était l’exception et non la norme. Je viens de faire une recherche sur « entreprises manquant de connaissances en infrastructure cloud » dans mon navigateur, et les résultats ont donné des conclusions assez surprenantes :


  • Il existe une grave pénurie d’expertise en matière de cloud.
  • Le manque de compétences cloud entraîne des impacts significatifs sur les performances des services cloud natifs.
  • La sécurité du cloud est un défi pour 1 entreprise sur 4.


Les principaux résultats de recherche faisaient état d'un manque de compréhension des concepts fondamentaux du cloud et de la nécessité d' une formation cruciale pour que les équipes soient efficaces. La formation dont la plupart des équipes ont besoin est généralement laissée de côté, car les demandes des clients et les livrables revêtent une priorité plus élevée.

Avec cette approche actuelle, la plupart des implémentations cloud sont contraintes d’évoluer à un rythme plus lent et sont souvent exposées à des vulnérabilités inconnues.


L’état actuel de la sécurisation de vos microservices dans le cloud n’est pas heureux.


L'état idéal pour les microservices sécurisés

L’état idéal pour les solutions cloud natives adhérerait à un énoncé de mission personnel que j’ai établi il y a plusieurs années :


« Concentrez votre temps sur la fourniture de caractéristiques/fonctionnalités qui augmentent la valeur de votre propriété intellectuelle. Tirez parti des frameworks, des produits et des services pour tout le reste.

– J.Vester


Dans ce contexte, ceux qui ont pour directive de s’orienter vers des solutions cloud natives devraient pouvoir évoluer à un rythme qui correspond aux objectifs de l’entreprise. Ils ne doivent pas être ralentis par la courbe d’apprentissage associée à l’infrastructure cloud sous-jacente.


Alors, à quoi cela ressemble-t-il lorsque nous sommes confrontés à une solution cloud englobant plusieurs microservices , qui doivent tous être isolés du public et respecter les réglementations de conformité (telles que SOC, ISO, PCI ou HIPAA) ?


À propos des espaces privés

Mon expérience Heroku 2020 a été positive. Je voulais donc voir comment cela fonctionnerait avec ce cas d'utilisation complexe. C'est alors que j'ai découvert les Espaces Privés .


Les espaces privés sont disponibles dans le cadre de Heroku Enterprise. Ce sont des environnements dédiés à l’exécution de microservices au sein d’un réseau isolé. Cette approche permet aux équipes de déployer leurs services sur un réseau qui n'est pas exposé à l'Internet public. Sous le capot, ces services fonctionnent exactement de la même manière que dans mon cas d'utilisation de base. Je peux les configurer via la CLI Heroku, et de simples commandes basées sur Git peuvent déclencher des déploiements.


Pour les besoins de conformité réglementaire, je peux m'appuyer sur Heroku Shield pour m'aider à me conformer aux normes PCI DSS, HIPAA, ISO (27001, 27017 et 27018) et SOC (1, 2 et 3).


À un niveau élevé, Heroku me permet d'implémenter une conception cloud native sécurisée qui peut être illustrée comme ceci :


Ici, nous avons une implémentation qui exploite Heroku Shield dans un espace privé. Cela permet à un ensemble de microservices (utilisant plusieurs langages de programmation différents) d'interagir avec tous les principaux réseaux de cartes primaires et secondaires, tout en respectant diverses exigences de conformité réglementaire. De plus, je bénéficie de communications sécurisées avec la plateforme Salesforce et GitLab.

Héroku en action

Grâce à Heroku CLI, je peux faire fonctionner mon espace privé et Heroku Shield. Dans Heroku, cela s'appelle un Shield Private Space . Voici quelques exemples de haut niveau pour suivre le processus.


Pour créer un nouvel espace privé Shield, nous utilisons spaces:create et ajoutons l'option --shield .


 $ heroku spaces:create payment-network --shield --team payments-team --region oregon Creating space payment-network in team payments-team... done === payment-network Team: payments-team Region: oregon State: allocating


Si le cas d'utilisation nécessite des plages CIDR (Classless Inter-Domain Routing), je peux utiliser les indicateurs --cidr et --data-cidr .


Vous remarquerez que j'ai créé mon Espace Privé dans la région de l'Oregon. Vous pouvez créer un espace privé dans l'une des 10 régions disponibles (aux États-Unis, en Europe, en Asie et en Australie). Pour obtenir la liste des régions disponibles, procédez comme suit :


 $ heroku regions ID Location Runtime ───────── ─────────────────────── ────────────── eu Europe Common Runtime us United States Common Runtime dublin Dublin, Ireland Private Spaces frankfurt Frankfurt, Germany Private Spaces london London, United Kingdom Private Spaces montreal Montreal, Canada Private Spaces mumbai Mumbai, India Private Spaces oregon Oregon, United States Private Spaces singapore Singapore Private Spaces sydney Sydney, Australia Private Spaces tokyo Tokyo, Japan Private Spaces virginia Virginia, United States Private Spaces


Pour chaque microservice qui doit s'exécuter dans l'espace privé payment-network , j'ajoute simplement l'option --space lors de l'exécution de la commande apps:create :


 $ heroku apps:create clearing-service --space payment-network Creating app... done, clearing-service


Pour accorder aux consommateurs l'accès à l'espace payment-network , je peux maintenir la liste verte des adresses IP de confiance :


 $ heroku trusted-ips:add 192.0.2.128/26 --space payment-network Added 192.0.2.128/26 to trusted IP ranges on payment-network ▸ WARNING: It may take a few moments for the changes to take effect.


Conclusion

Les équipes reçoivent souvent une directive d’en haut pour adopter une approche cloud native. Mais de nombreuses équipes manquent sérieusement de compréhension lorsqu’il s’agit de déployer des architectures cloud sécurisées. Si vous utilisez l'un des trois grands fournisseurs de cloud, combler cet écart aura un prix : probablement le non-respect des délais attendus par le propriétaire du produit.


Existe-t-il une meilleure option pour un déploiement cloud sécurisé ? Je pense que les espaces privés combinés à Heroku Shield représentent cette meilleure option. Pour moi personnellement, il est également important qu'Heroku fasse partie de la plate-forme de solutions de Salesforce, qui s'est toujours engagée à fournir une alternative d'adoption du cloud axée sur la réussite de ses clients. J’avais donc l’impression qu’il s’agissait d’une stratégie à long terme à considérer.


Passez une très bonne journée !