Architecture zero trust pour les environnements cloud et hybrides

SEYA Group conçoit l'accès zero trust pour les environnements cloud et hybrides : chaque demande est vérifiée pour l'identité, l'appareil et la plus petite autorisation dont la tâche a besoin, que l'appelant soit une personne, un pipeline ou une charge de travail. Le travail prend la forme d'une feuille de route par phases que votre équipe peut mener, et non d'un produit pour lequel vous seriez contraints d'arracher le réseau pour l'installer. Les missions sont menées par des ingénieurs seniors depuis notre bureau de Vancouver.

À qui s'adresse ce service

Aux responsables de la sécurité et de l'infrastructure dont le VPN traite encore le réseau du bureau comme de confiance, ou dont les comptes cloud ont accumulé une longue liste de rôles d'administration permanents. Aux équipes qui traversent une fusion, ont une main-d'œuvre à distance ou subissent une revue client qui demande comment un sous-traitant atteint la production. Aux architectes qui veulent régler l'identité des charges de travail avant qu'un agent ou un pipeline ne reçoive des permissions cloud.

Ce que vous obtenez

• Identité. Une cartographie de l'identité des collaborateurs, des rôles privilégiés et des comptes de service, et une recommandation sur les accès qui devraient être à la demande plutôt qu'en continu. Nous utilisons le système d'identité que vous exploitez déjà.
• Appareil. Les signaux que vous pouvez réellement collecter aujourd'hui (appareil géré, vérification de posture ou aucun) et quelles applications doivent refuser un appareil qui échoue à ces contrôles. Nous n'inventons pas un parc d'appareils que vous ne gérez pas.
• Segmentation réseau. Quels chemins doivent demeurer, lesquels doivent être sensibles à l'identité et quelles règles larges doivent être refermées. La segmentation est rédigée par rapport aux comptes du périmètre, et non par rapport à un diagramme greenfield qui ignore le VPC ou le VNet actuel.
• Identité des charges de travail. Comment un pipeline, un pod ou un service prouve son identité sans clé à longue durée de vie dans un dépôt. C'est l'élément qui relie le zero trust au DevSecOps.
• Une feuille de route par phases. Ce qui change dans la première phase sans arrêter la livraison, ce qui attend un responsable d'application et ce qui est explicitement reporté.

Déroulement d'une mission

• Phase 1, voir les accès. Inventaire des identités humaines et des identités de charges de travail et des chemins vers les environnements que vous désignez.
• Phase 2, combler les écarts évidents. Suppression ou limitation dans le temps des accès d'administration permanents, restriction des chemins de gestion exposés au public et confirmation de la journalisation. Ces changements sont revus avec vos opérateurs avant mise en production.
• Phase 3, le modèle stable. Politique pour les nouveaux comptes et les nouvelles charges de travail afin que le prochain projet ne reproduise pas l'ancien schéma. Les mauvaises configurations découvertes en cours de route sont traitées par la revue de posture de sécurité cloud plutôt que laissées sur une diapositive.

Ce dont vous avez besoin au départ

Un responsable de l'identité, un responsable de l'infrastructure et un accès en lecture aux annuaires et aux comptes cloud du périmètre. Les applications qui ne peuvent pas modifier leur connexion dans la première phase restent sur la feuille de route avec une justification, au lieu d'être forcées dans une bascule brutale. Si le patrimoine est encore en cours de conception en tant que nouvelle landing zone et que la sécurité n'est pas la raison du projet, indiquez-le lors de l'appel de cadrage. Ce service suppose que vous voulez le modèle d'accès. Il ne suppose pas que vous vouliez quitter un centre de données.

L'exemple publié le plus proche est la fondation Google Cloud de LiveRamp, qui a séparé les environnements et appliqué un IAM granulaire. Il s'agissait d'une conception de fondation pour un premier cloud, et les choix d'identité sont ceux qui trouvent leur place sur cette page.

Questions fréquentes

Faut-il retirer le VPN dès la première phase ?

Non. La première phase porte en général sur l'identité et l'accès d'administration. Les changements réseau qui bloqueraient une usine, un magasin ou un centre d'appels attendent que les responsables d'application disposent d'un chemin testé. Ici, le zero trust est une séquence, pas une bascule en un week-end.

S'agit-il d'une mise en œuvre de produit zero trust ?

Cela peut inclure la configuration des produits d'identité et d'accès que vous licencez déjà. SEYA n'exige pas un fournisseur particulier et nous ne vendons pas d'appareil zero trust. Le livrable, c'est le modèle d'accès et les changements que vous acceptez d'appliquer.

Quel est le lien avec une revue de sécurité du cloud ?

Une revue de posture liste les mauvaises configurations à une date donnée. Le zero trust est le modèle d'accès vers lequel vous souhaitez que ces comptes convergent. De nombreuses missions commencent par la revue pour que la feuille de route parte de l'accès que vous avez réellement.

Réserver une évaluation de sécurité cloud si l'accès privilégié ou le VPN du bureau est la question à laquelle on vous a demandé de répondre.