Aniket Braganza explique les avantages d’une Cloud Landing Zone, notamment lors de la mise en place d’une plateforme Cloud sécurisée et bien organisée.
Qu’est-ce qu’une Cloud Landing Zone ?
Commençons par expliquer ce qu’est une Landing Zone, également connue sous le nom de Cloud Landing Zone (CLZ), car la compréhension de ce concept nous aidera à savoir pourquoi il est si important de la mettre en place au début de notre voyage dans le Cloud.
Si nous considérons notre plateforme Cloud comme une ville, nous pouvons penser à la Cloud Landing Zone comme le plan directeur et l’infrastructure essentielle pour garantir que notre ville grandisse et se développe de manière bien organisée.
L’existence d’un plan directeur garantit que, lorsque nous ajoutons de nouvelles sections et de nouveaux services dans notre ville, nous savons où ils vont et comment les mettre en place par rapport à tout ce qui existe déjà. Il peut sembler frustrant de faire une partie de ce travail en amont, mais l’établissement de cette base et de cet échafaudage facilite la résolution de problèmes plus complexes par la suite, car nous n’avons plus à nous soucier de nos fondations.
Lorsqu’on cherche sur Internet des informations sur les CLZ, on trouve généralement les quatre raisons suivantes :
- Sécurité et conformité
- Location standardisée
- Gestion des identités et des accès
- Mise en réseau
Bien qu’il n’y ait rien de mal à considérer une CLZ de cette façon, je pense qu’il est plus approprié de donner aux équipes de développement un moyen de corréler les étapes pratiques du SDLC à la construction de votre CLZ. Je pense qu’il existe des raisons simples et pleines de bon sens d’intégrer une CLZ dans la mise en place de votre plateforme Cloud.
Pour les besoins de cette discussion, supposons que votre organisation actuelle de fournisseur de solutions Cloud (CSP) est définie comme suit :
- 1 Compte de facturation principal
- 1 Compte de sécurité
- 1 Compte d’archivage des journaux
- 1Compte de services partagés
- 2Comptes supérieurs (PROD et UAT)
- 2 Comptes inférieurs (DEV et TEST)
- n Comptes Sandbox (le nombre à déterminer par votre équipe)
Exemple de configuration d’une Cloud Landing Zone multi-comptes
Pourquoi construire une Cloud Landing Zone ?
Voici 5 bonnes raisons d’intégrer une CLZ dans la création de votre plateforme Cloud :
Sécurisation de l’accès
Gestion centralisée de l’accès aux rôles et des capacités d’audit entre les comptes
Pour réussir à construire une plateforme Cloud, les équipes de développement doivent être capables d’expérimenter. Cela signifie qu’il doit y avoir une zone d’expérimentation où ils peuvent tester les nouvelles caractéristiques et fonctionnalités.
Au départ, les équipes peuvent ne pas savoir de quel accès à la plateforme elles auront besoin et elles auront donc besoin d’un contrôle de type administrateur pour construire quelque chose avant d’affiner l’ensemble minimal de droits nécessaires. Pour ce faire, il doit y avoir une zone dans la plateforme où ils peuvent expérimenter et où, si quelque chose ne va pas, elle peut être effacée et reconstruite sans compromettre la stabilité de la plate-forme dans son ensemble.
Cela peut être accompli en établissant un compte de sécurité.
Ce compte est l’endroit où les développeurs et les utilisateurs de la plateforme peuvent être définis. Rien d’autre n’est intégré dans ce compte. Par exemple, sur votre CSP, les développeurs peuvent être définis dans IAM et être affectés à un rôle spécifique et à une stratégie spécifique. Les utilisateurs du système peuvent être enregistrés directement auprès de votre fournisseur d’identité ou se voir accorder un accès par le biais d’une connexion fédérée et/ou sociale.
Vous pouvez désormais créer un compte « Sandbox » où les développeurs peuvent déployer des branches de fonctionnalités et expérimenter la création de nouvelles fonctionnalités. Cet environnement n’aurait pas d’utilisateurs propres, mais établirait simplement une relation d’approbation fédérée qui accorderait aux développeurs un accès de niveau administrateur. Tout ce qui se trouve dans ce compte Sandbox est essentiellement jetable et peut être redéployé via Infrastructure as Code (IaC), si nécessaire.
Cette posture de sécurité garantirait qu’aucun développeur ou utilisateur ne soit jamais autorisé à accéder à vos comptes d’enregistrement, de services partagés, supérieurs ou inférieurs. En outre, aucun changement manuel ne sera jamais autorisé dans aucun de ces comptes et tous les changements seront déployés par pipeline. Les outils de pipeline utiliseraient un principal de service pour déployer des fonctionnalités sur les comptes.
Enfin, cela signifierait que tout accès aux ressources requis par tout code ou service de plateforme serait spécifié dans IaC (par exemple Terraform) et que l’accès serait audité lors de la révision du code avant son déploiement. Cela fournirait également les rapports nécessaires à la conformité en cas d’audit.
Établir la connectivité
Simplifiez la connectivité aux ressources sécurisées via un seul canal géré
La possibilité de développer de nouvelles fonctionnalités ou de se connecter à la plateforme Cloud pour dépanner les fonctionnalités existantes peut parfois être entravée par des problèmes de connectivité réseau. Si l’équipe adopte une approche ad hoc pour se connecter aux ressources ou ouvre des ressources sécurisées à l’Internet public, cela peut gravement compromettre l’équipe et la plateforme.
Toutefois, si les ressources sont verrouillées ou si la connectivité est mal configurée, les équipes peuvent passer des heures à essayer de trouver la cause première. L’adoption d’une posture réseau trop lâche peut permettre à des acteurs malveillants de falsifier la plateforme, tandis qu’une posture trop stricte peut potentiellement entraver la progression d’un travail légitime.
Une Cloud Landing Zone peut aider l’équipe à éviter de perdre du temps en simplifiant l’accès aux ressources Cloud en accordant les bons niveaux d’accès aux différents acteurs. Le fait de documenter la topographie de l’application et les interactions potentielles qui doivent être établies peut aider à fournir une orientation lors du développement et à éclairer la prise de décision future sans avoir à retravailler de manière substantielle la plateforme.
Gestion de la plateforme
Le flux de travail d’intégration continue et de livraison continue
La meilleure partie de la création d’une plateforme Cloud native est une infrastructure CI/CD robuste pour tester et déployer en permanence votre plateforme dans le Cloud. C’est un objectif réalisable, tant que personne n’est autorisé à bricoler manuellement le résultat final de ce processus de livraison.
Avoir un processus CI/CD de haute qualité est la clé du succès, car il permet à votre équipe d’ingénieurs de se concentrer sur la résolution de problèmes complexes et non sur des tâches subalternes et répétitives. Il permet à vos testeurs d’écrire ou d’exécuter des tests pour valider la fonctionnalité, et non de se demander pourquoi ils ne peuvent pas utiliser la plateforme déployée. Enfin, il vous permet de vous remettre d’une panne ou d’un problème, sans que vos équipes aient à se démener pour trouver et résoudre les problèmes critiques.
Je dirais que vos pipelines CI/CD ne sont aussi bons que la sécurité et l’infrastructure sur lesquelles vous les construisez. Par conséquent, pour établir un processus de livraison de haute qualité, il est impératif de sécuriser, d’auditer et d’améliorer continuellement les pipelines de livraison.
Je trouve que la façon la plus complète de gérer votre plateforme est de gérer les processus et les procédures qui sont utilisés pour la construire et la déployer. Si l’on veille à ce que ces processus et procédures soient mis en place avant ou à proximité du début du déploiement des fonctionnalités, les modèles et les pratiques deviennent une seconde nature pour l’équipe et l’infrastructure CLZ mise en place favorise la mise en place rapide et relativement aisée de la plate-forme.
Fonctionnalités de déploiement
La création d’un produit Cloud natif peut être une tâche assez difficile. Un certain nombre de choses font qu’il est difficile de réussir.
Tout d’abord, si une équipe adopte une méthode ad hoc pour créer et déployer des améliorations pour sa plateforme, les développeurs risquent d’écraser les fonctionnalités des autres, d’introduire des bugs et des problèmes de régression potentiels. Ces problèmes sont aggravés si les développeurs apportent manuellement des modifications à la plate-forme qui ne sont pas suivies ou réversibles.
Deuxièmement, pour plus de commodité, les développeurs peuvent déployer plusieurs environnements tels que « Sandbox » et « DEV », « UAT » ou « PROD » sur le même compte. Bien qu’il puisse être plus facile d’adopter cette approche au début, il est plus que probable que nous aurons un impact sur l’expérience utilisateur et les performances de nos environnements orientés client. Par exemple, si les testeurs effectuent des tests de charge dans l’environnement « TEST » en même temps que les utilisateurs « PROD » utilisant le système et les développeurs déployant des modifications dans « DEV », il peut y avoir tellement de conflits pour les ressources que plusieurs groupes en sont affectés.
Votre CSP peut évoluer vers le haut pour gérer la charge, mais par défaut, les comptes ont généralement des limites souples prédéfinies qui empêcheront les locataires de dépasser leurs quotas de service. Alors que la plupart des quotas peuvent être augmentés, ce n’est pas le cas de tous. C’est pourquoi l’hébergement de plusieurs environnements dans le même compte peut potentiellement avoir un impact sur l’expérience de l’équipe et de tous les utilisateurs de ces environnements. Par exemple, si les développeurs poussent trop de branches de fonctionnalités et ne nettoient pas les ressources, les déploiements « PROD » peuvent commencer à échouer à mesure que les quotas de service sont dépassés.
Ces problèmes peuvent être corrigés facilement si nous avons une CLZ en place pour délimiter clairement chaque environnement. Le code instable déployé pour les nouvelles fonctionnalités est tenu à l’écart de votre déploiement de production et plusieurs équipes d’ingénieurs et de testeurs peuvent travailler en parallèle sans affecter les performances des systèmes critiques destinés aux clients. En établissant une CLZ tôt, vous avez essentiellement mis en place les garde-fous de votre plateforme avant de commencer à la construire. Cela peut économiser du temps et de l’argent à long terme, mais plus important encore, cela isole votre flux de revenus en garantissant aux clients une bonne expérience pendant que votre équipe continue d’améliorer le produit.
Informations de journalisation
Stocker des copies de toutes les données de journal pour l’analyse, l’audit et la conformité
La journalisation est souvent considérée comme un élément auxiliaire de la création d’une plateforme Cloud, mais c’est l’une des facettes les plus cruciales. Lorsque les équipes commencent à créer une plateforme, la journalisation est généralement utilisée pour résoudre ou déboguer les problèmes. Cependant, à mesure que le temps passe et que la plateforme se développe et que les fonctionnalités deviennent plus complexes, il peut être difficile de comprendre le fonctionnement d’une plateforme. Le déchargement de tous les journaux sur un compte séparé lors de l’établissement d’une CLZ est important pour 2 raisons.
Tout d’abord, cela capture les données d’exécution et d’audit, tout en les séparant de l’exécution de la logique dans la plateforme. C’est important car si, pour une raison quelconque, il y avait des failles dans la base de code ou des acteurs malveillants qui tentaient de supprimer ou de modifier les journaux, ces opérations seraient implicitement bloquées. En veillant à ce que la CLZ soit configurée de telle sorte que le transfert des journaux se fasse uniquement vers l’avant, sans permettre aucune modification des données des journaux, la plateforme est protégée contre les acteurs malveillants ou les codes bogués.
Deuxièmement, à un moment donné dans le futur, vous voudrez soit construire, soit intégrer une solution de gestion des performances des applications et d’analyse des opérations informatiques comme Datadog, Dynatrace, AppDynamics ou SumoLogic. Ces solutions souhaitent généralement se connecter à vos comptes pour analyser les données de journal générées par votre plateforme. Ces outils fournissent de nombreuses informations précieuses sur le fonctionnement de votre plateforme, mais je me méfie de donner à un tel outil un accès direct à ma plateforme. En établissant un compte d’archivage des journaux dans notre CLZ, nous pouvons éviter cette vulnérabilité de sécurité potentielle car nous n’avons besoin d’accorder l’accès qu’à un seul compte isolé plutôt qu’à l’intégralité de notre plateforme.
Une taille unique pour tous ?
On pourrait croire qu’une Cloud Landing Zone est une sorte de modèle à l’emporte-pièce qui peut être utilisé partout, mais rien n’est plus éloigné de la vérité. Comme je l’ai dit au début, si nous considérons notre plateforme comme une ville, la CLZ est le plan directeur et l’infrastructure essentielle pour s’assurer que notre ville grandit et se développe de manière bien organisée.
Chaque produit est différent et peut tirer parti de différents services. La clé est d’établir l’échafaudage afin que nous puissions nous concentrer sur la conception, l’organisation et l’orchestration de notre plateforme, tout en faisant confiance au cadre que nous avons utilisé pour établir les fondations.
Pour plus d’informations sur la façon dont Cloudreach peut vous aider à créer une plateforme Cloud sécurisée et bien organisée, cliquez ici.
