Sécurisation d'une plateforme distribuée : gestion des identités, des secrets et des clés

Il s'agit du troisième blog d'une série de blogs qui couvrent divers aspects de ce qu'il nous a fallu pour créer et exploiter notre service SaaS : 

1. Plan de contrôle pour le PaaS Kubernetes distribué
2. Service mesh global pour applications distribuées
3. Sécurité de la plateforme pour les infrastructures, les applications et les données distribuées 
4. Sécurité des applications et des réseaux des clusters distribués
5. Observabilité sur une plateforme distribuée à l'échelle mondiale
6. Opérations et SRE d'une plateforme distribuée à l'échelle mondiale 
7. Cadre de service Golang pour les microservices distribués

Mon blog initial a fourni quelques informations sur les besoins qui nous ont conduit à créer une nouvelle plateforme pour les clouds distribués. Grâce à cette plateforme, nos clients créent un ensemble complexe et diversifié d’ applications , telles que la fabrication intelligente, la criminalistique vidéo pour la sécurité publique, le trading algorithmique et les réseaux de télécommunications 5G.

Étant donné que bon nombre de ces applications sont critiques, nos clients s’attendent à ce que nous fournissions non seulement une sécurité multicouche, mais également la capacité d’apporter des améliorations continues pour assurer la sécurité de leurs clusters distribués. Ce blog spécifique abordera les défis de la sécurisation de l’infrastructure, des applications et des données sur plusieurs clusters.

TL;DR (Résumé)

1. Bien qu’il soit relativement bien connu comment fournir un accès sécurisé aux applications pour les utilisateurs et les employés (nous le faisons tous les jours lorsque nous accédons à nos comptes bancaires ou à nos e-mails d’entreprise), il n’est pas aussi simple de faire de même pour l’accès d’application à application ou d’application à données, car aucun humain n’est impliqué dans le processus de vérification.
2. La sécurisation des applications et des données dans un environnement hétérogène (périphérie, plusieurs clouds et points de présence réseau) nous a obligé à résoudre un problème multicouche : identité, authentification et autorisation, secrets et gestion des clés
3. Même s'il existe de nombreuses solutions ponctuelles disponibles (par exemple, plusieurs services de fournisseurs de cloud individuels, Hashicorp Vault, SPIFFE/Spire, etc.) pour résoudre ces quatre problèmes, il n'existe pas de solution intégrée qui fonctionne avec tous les fournisseurs de cloud ou qui combine de manière transparente chacun de ces services pour une facilité d'utilisation.
4. Étant donné le manque d’expertise au sein de nos équipes de développeurs et DevOps sur la manière de rassembler ces éléments, il est devenu essentiel pour notre équipe de plateforme de fournir ces fonctionnalités sous la forme d’une solution intégrée et facile à utiliser. L’évolution du paysage de la sécurité et les nouvelles technologies rendent la tâche encore plus difficile pour ces équipes, car elles ne disposent pas de l’expertise nécessaire ni de la bande passante pour suivre tous les changements.
5. Dans le cadre de la fourniture d'une sécurité de plate-forme multicouche, nous avons créé de nouveaux composants logiciels qui ont résolu trois problèmes critiques d'une manière entièrement nouvelle : l'amorçage sécurisé d'une identité universelle qui ne souffre pas du problème des « tortues jusqu'en bas », des secrets qui peuvent être stockés et distribués sans jamais se soucier de la compromission d'un coffre-fort central (problème de mine d'or) et une gestion des clés distribuée pour faciliter la sécurité des données au repos.

Contexte du problème de sécurité

Comme indiqué ci-dessus, le problème de la sécurisation de l’accès des utilisateurs aux applications (par exemple, l’accès à nos comptes bancaires ou à nos e-mails) est bien compris. Cependant, il n’est pas aussi simple de procéder de la même manière pour l’accès d’une application à une autre ou d’une application à des données, car aucun humain n’est impliqué dans le processus de vérification.

Pour qu'une application puisse accéder à une autre ressource de manière sécurisée (par exemple, des données stockées dans un magasin d'objets ou effectuer un appel d'API vers une autre application, etc.), les conditions suivantes doivent se produire : 

1. Identité — le demandeur doit acquérir en toute sécurité une identité vérifiable qui peut être utilisée à des fins d’authentification et d’autorisation lors de l’accès aux ressources requises. Le demandeur doit également être doté en toute sécurité des ancres de confiance nécessaires qui peuvent être utilisées pour vérifier l'identité des pairs. 
    
2. Authentification — Lors du processus d'accès à une ressource donnée, le demandeur et le propriétaire de la ressource doivent vérifier en toute sécurité l'identité de chacun. Le processus de vérification de l’identité revendiquée par un pair par rapport à l’identité présentée est appelé authentification. 
    
3. Autorisation — une fois le demandeur authentifié, le processus de vérification s’il est autorisé à accéder à la ressource (ou non) est appelé Autorisation.

Dans le cadre du processus d'authentification, l' application requérante peut présenter son identité sous la forme d'un certificat PKI ou d'un secret (par exemple un mot de passe) ou d'une clé. Il y a deux problèmes qui doivent être résolus lors de l'utilisation de secrets ou d'une clé pour l'identité : 

• Les secrets et les clés ne doivent pas être stockés directement dans le code, car c'est un vecteur d'attaque facile et les clés divulguées peuvent être un gros problème. 
• Si les secrets sont stockés dans un coffre-fort externe, quelle identité (généralement un autre secret) doit être utilisée pour obtenir le secret et comment sécuriser cette identité pour obtenir le secret ?

Réaliser ces opérations de sécurité (pour l’interaction entre applications) de manière fiable et répétable est un problème non trivial. Il y a de nombreuses raisons pour lesquelles cela n’est pas anodin : 

1. Les applications peuvent être facilement clonées et générées (par exemple, des microservices). Comment attribuer une identité unique à chaque clone qui peut être nécessaire à des fins d'investigation, d'audit ou d'observabilité ? 
2. L’identité de application sera différente selon l’environnement dans lequel elle s’exécute. Par exemple, en développement et en production, l’ application est la même, mais elle nécessite une identité différente dans chaque environnement. 
3. Comment instaurer la confiance que l’infrastructure dans laquelle l’ application est générée ne volera pas l’identité ou les secrets et les clés sans se faire remarquer ? 
4. Comment sécuriser le coffre-fort central contre les attaques et sécuriser tous les secrets et clés stockés dans ce coffre-fort ?

Par conséquent, sécuriser l’infrastructure, les applications et les données dans un environnement dynamique constitue un problème très complexe. Bien que les fournisseurs de cloud aient relevé ce défi et fourni de nombreux outils pour faire face à ces problèmes, leur intégration et leur maintenance ne sont pas faciles pour les raisons suivantes : 

• Complexité — Chaque fournisseur de cloud exige que le client configure et gère plusieurs services. Par exemple dans AWS - service de métadonnées, rôles IAM, compte de service, RBAC, KMS et gestionnaire de secrets. Chacun de ces services est très différent chez chaque fournisseur de cloud , tant au niveau de leur sémantique, de leurs API que de leur surveillance. 
   
• Interopérabilité — Même lorsque les services des fournisseur de cloud sont configurés et opérationnels, aucun d’entre eux ne permet l’interopérabilité. Par exemple, une machine virtuelle exécutée dans GCP ne peut pas accéder à une ressource dans AWS, car l’identité attribuée à l’aide du compte de service GCP n’est pas comprise par une ressource AWS. 
   
• Environnements hétérogènes — Si l'environnement est réparti sur des clouds publics et privés, ou sur plusieurs clouds publics, ou — pire — à la périphérie, le défi sera de savoir comment et où stocker les secrets tels que les mots de passe, les clés, etc. — de manière centralisée ou distribuée. 
   
• Environnement spécifique : la solution pour la rotation et/ou la révocation des informations d'identification est très différente chez chacun des fournisseurs de cloud, alors que rien de tout cela n'existe pour les clusters Edge.

Alors que de nombreuses entreprises sont un fournisseur de cloud unique et qu’il peut être suffisant pour elles d’investir des ressources dans la gestion et l’amélioration des primitives de sécurité de ce fournisseur, nous opérons dans un environnement hétérogène (cloud hybride et edge) et avons dû créer une nouvelle solution pour résoudre ces problèmes.

Solution pour sécuriser une plateforme distribuée

Notre équipe a été chargée d’assurer la sécurité des applications, de l’infrastructure et des données qui peuvent résider dans une infrastructure distribuée, comme le montre la figure 1.

En conséquence, notre équipe de plateforme a décidé de créer de nouveaux services logiciels intégrant les quatre aspects suivants pour assurer la sécurité de la plateforme à travers la périphérie, n'importe quel cloud et nos PoP réseau : 

1. Gestion des identités — nous décrirons comment nous fournissons une identité basée sur PKI cryptographiquement sécurisée et infalsifiable non seulement aux applications, mais également à l'infrastructure distribuée dans un environnement hétérogène (plusieurs clouds, nos PoP mondiaux et des emplacements périphériques géographiquement dispersés) et fonctionnant comme plusieurs environnements (par exemple, machine de développement, test unitaire, production, etc.) 
    
2. Authentification et autorisation — notre infrastructure repose sur des microservices qui utilisent une identité basée sur PKI et authentifient mutuellement toutes les communications, quel que soit le protocole de communication utilisé. Nous avons également découplé l’autorisation de l’authentification afin qu’un moteur d’autorisation commun puisse être utilisé pour une variété de décisions d’autorisation et que la structure de la politique puisse être unifiée. 
    
3. Système de gestion des secrets — il existe de nombreux types de secrets (tels que les certificats TLS, les mots de passe, les jetons, etc.) nécessaires à nos logiciels, ainsi qu'aux charges de travail des clients. La méthode la plus simple aurait pu être d’adopter un coffre-fort centralisé où tous les secrets sont stockés, mais cette approche présente l’inconvénient que tout compromis révélera tous les secrets. Nous allons décrire une approche différente que nous avons mise en œuvre pour atteindre un niveau de sécurité plus élevé en renonçant à une certaine simplicité. 
    
4. Système de gestion de clés (KMS) — la sécurité des données est essentielle pour notre système distribué et l'équipe devait fournir un KMS qui fonctionne de manière transparente entre les fournisseurs de cloud. Le KMS doit gérer, versionner et faire tourner les clés utilisées pour le chiffrement symétrique des données au repos, le HMAC des jetons CSRF et les binaires signés numériquement. Nous discuterons de la manière dont nous fournissons des capacités pour les opérations sensibles à la sécurité à l'aide de ce KMS et les opérations sensibles à la latence à l'aide du système de gestion des secrets.

Identité infalsifiable pour les infrastructures et les applications

L’identité est une question fondamentale car de nombreux défis de sécurité peuvent être résolus plus facilement une fois le problème d’identité résolu. Cependant, pour résoudre le problème de l’identité, nous devons définir ce que nous entendons par là et comment émettre une identité de manière fiable. Les geeks de la cryptographie aiment avoir leur propre point de vue sur tout, et la définition de l'identité ne fait pas exception :

L'ensemble unique et complet de caractéristiques infalsifiables et cryptographiquement vérifiables , certifiées cryptographiquement via un protocole non délégué et sécurisé par une autorité de confiance, qui constituent ce qu'une personne ou une chose est connue ou considérée comme étant.

Essentiellement, ce qu’il faut, c’est une identité infalsifiable et vérifiable par cryptographie, délivrée de manière sécurisée. Délivrer une telle identité est un défi pour deux raisons : 1) amorçage de l'identité et 2) racine de confiance

Il existe quelques approches qui sont souvent discutées en relation avec l’identité : SPIFFE et Hashicorp Vault. Nous tenons à préciser que SPIFFE est un schéma de dénomination qui pourrait être utilisé dans notre système comme document d’identité (certificat X.509) — cependant, le format n’est pas adapté à certains attributs d’identité contenant des données binaires. Bien que Vault puisse être utilisé pour émettre un document d'identité, il ne résout pas les problèmes d'amorçage de l'identité et de racine de confiance :

1. Amorçage de l’identité — dans la vie réelle, lorsqu’une personne naît, son identité est établie par l’acte de naissance. Cela permet de déterminer logiquement l'identité de la personne et, en utilisant ce certificat, la personne peut dériver/demander d'autres certificats d'identité tels qu'un passeport, un permis de conduire, etc. De même, dans le monde informatique, chaque lancement d’une application (ou d’un microservice) doit démarrer une identité. L’établissement de l’identité est l’une des premières étapes que tout code en cours d’exécution doit effectuer pour pouvoir interagir avec d’autres services. De plus, étant donné que le même code application peut être lancé plusieurs fois et dans des environnements différents (ordinateur portable du développeur, test unitaire ou production), il est également nécessaire que chacun de ces lancements établisse une identité d'amorçage distincte.
2. Racine de confiance — bien que l’émission d’une identité bootstrap puisse sembler être un processus simple, le problème est de savoir qui peut provisionner cette identité. Par exemple, dans le monde réel, la fourniture d’une identité commence par l’affirmation par l’hôpital du fait qu’un enfant est né à une date et une heure données d’une personne particulière et l’on suppose que l’hôpital fabrique l’acte de naissance avec des contrôles appropriés et qu’il ne peut pas être falsifié. Par conséquent, l’acte de naissance peut être utilisé comme source de vérité (ou racine de confiance). De même, lorsqu’une application est lancée par un code humain ou automatisé, il doit y avoir une racine de confiance qui peut affirmer de manière vérifiable l’identité de l’ application qui a été lancée. Cette assertion peut ensuite être utilisée pour générer un document d’identité ultérieur pour l’ application.

Par exemple, lorsqu’une machine virtuelle est lancée dans AWS, elle est dotée d’une identité d’amorçage et le service de métadonnées d’AWS agit comme racine de confiance. Le document d'identité (signé par AWS à l'aide de sa propre clé cryptographique) ressemble à ceci :

Bien que l' instanceId puisse désigner l'identité unique de l'instance application qui a été lancée, elle doit être liée à un nom bien connu (myserver.acmecorp.com) que d'autres applications utiliseront pour communiquer avec cette instance particulière. Par conséquent, même ce document d’identité d’amorçage AWS est insuffisant, mais peut être utilisé pour émettre une autre identité qui peut être utilisée par les applications pour communiquer avec une autre application.

Comme indiqué précédemment, il était essentiel pour nous de fournir une identité permettant aux applications de communiquer et de partager des informations entre les fournisseurs de cloud et/ou les emplacements périphériques (Figure 2). Cela signifiait que nous devions créer un système d’amorçage d’identité et de racine de confiance qui fonctionne dans tous ces environnements.

Étant donné que nous utilisons Kubernetes pour gérer et orchestrer des applications (à la fois des microservices et des machines virtuelles), cela signifiait que l’amorçage d’une identité unique pour chaque pod lancé devait être intégré au processus de création de pod de Kubernetes. La figure 3 montre comment nous nous connectons au processus de création de pod à l’aide du mécanisme webhook K8s. Ce webhook, appelé Voucher, injecte un side-car de sécurité, appelé Wingman , dans tous les pods créés dans le cluster et fournit également les informations signées cryptographiquement nécessaires qui peuvent être utilisées comme racine de confiance . Ce webhook fournit un jeton signé de courte durée qui est utilisé par Wingman pour demander un certificat X.509 à Identity Authority dans le backend SaaS de Volterra.

L'Autorité d'identité applique les règles de création d'identité de manière à minimiser le « rayon d'explosion » au cas où l'un des clusters K8 serait compromis. De nombreuses autres solutions qui s’appuient sur une autorité de certification racine commune ou sur une fédération de clusters K8 ne peuvent pas limiter le rayon d’explosion, ce qui a été un élément majeur dans notre décision de conception.

Pour un Pod donné dans K8s, les attributs peuvent changer après la création du Pod. Par exemple, un Pod peut être attaché à un nouveau service après sa création. Cela signifiait que les certificats d’identité devaient être mis à jour avec le nouveau service. Wingman surveille en permanence le bon qui suit le serveur API K8s pour détecter de telles mises à jour.

Ce mécanisme fournit une identité globale unique et universelle à chaque instance application exécutée sur notre plateforme, qu’il s’agisse de notre propre charge de travail ou de la charge de travail du client. Cette identité unique et son side-car (Wingman) sont ensuite utilisés pour sécuriser toutes les communications, tous les accès et toutes les clés/secrets dans un système distribué.

Authentification et autorisation

Avoir une identité unique par Pod est un excellent début car cela facilite la tâche de mise en œuvre de l’authentification mutuelle entre les services communicants. Notre infrastructure sous-jacente est composée de nombreux services différents qui fonctionnent sur différents protocoles tels que gRPC, REST, IPSec, BGP, etc. Dès le début, l’équipe s’est fixé comme objectif d’assurer une authentification mutuelle et une sécurité des communications (canal crypté) pour toutes les parties communicantes, quel que soit le protocole. Cela signifiait également que nous ne pouvions pas lier notre identité à une solution (par exemple Istio) qui se limite à un ensemble particulier de protocoles (par exemple HTTP/TCP vs. (basé sur IP).

Étant donné que notre plateforme permet également aux clients d’exécuter les charges de travail de leur choix, nous nous attendons à ce que ces charges de travail puissent exécuter une variété de protocoles et la plateforme ne devrait pas limiter leur capacité en fournissant une identité limitée à un ensemble particulier de protocoles. Au lieu de cela, l'authentification est découplée de l'identité (via Wingman) et cela permet de se connecter à diverses technologies de maillage de services. Notre service mesh sidecar/dataplane (abordé dans un blog précédent) utilise cette identité pour fournir mTLS aux charges de travail des clients.

Étant donné que la plupart de nos propres services d'infrastructure ont été écrits à l'aide de Volterra Golang Service Framework (qui sera abordé dans un prochain blog), nous avons décidé d'intégrer la logique de consommation d'identité (à partir de Wingman) directement dans le framework. Cela a aidé nos développeurs à sécuriser leurs communications de service à service prêtes à l'emploi sans avoir à s'appuyer sur un sidecar de maillage de service pour mTLS.

L’étape logique suivante après avoir obtenu un canal sécurisé mutuellement authentifié est l’autorisation, un processus permettant au récepteur de la demande (serveur) de déterminer s’il faut ou non autoriser la demande provenant de l’appelant identifié (client). Les raisons de ne pas autoriser la demande peuvent être nombreuses : limitations de quota, autorisations, etc. Étant donné que ces raisons et leurs seuils évoluent de manière dynamique, un ensemble de règles codées en dur (politique) pour l’autorisation n’était pas envisageable pour notre plateforme.

Nous avons décidé d’utiliser le moteur d’Open Policy Agent comme point de départ et avons créé un wrapper pour l’autorisation dans le side-car Wingman. Ce code wrapper récupère les politiques pertinentes de manière dynamique et les maintient à chaud pour une évaluation rapide. Similairement à l’authentification, le découplage du moteur d’autorisation de l’identité (et de l’authentification) nous a permis d’appliquer des politiques d’autorisation à plusieurs étapes du traitement des demandes, y compris au plus profond de la logique métier et pas seulement immédiatement après l’authentification.

Étant donné que Wingman est inséré dans toutes les charges de travail, y compris celles du client, notre plateforme fournit un moteur d’autorisation en tant que fonctionnalité intégrée. Même si Open Policy Agent (OPA) est construit sur un langage puissant appelé Rego, nous voulions cacher sa complexité à nos développeurs et clients. Toutes les politiques de notre plateforme peuvent également être définies à l'aide d'une structure de politique beaucoup plus facile à comprendre et intuitive qui ne nécessite pas que les utilisateurs (DevOps) apprennent Rego et évitent donc les erreurs. Similairement à la configuration de l’authentification, notre framework de service Golang a été connecté au moteur d’autorisation de Wingman en appelant automatiquement Wingman pour l’autorisation et en masquant la complexité de l’autorisation aux développeurs.

En utilisant une identité unique (émise via Wingman) pour l'authentification et un moteur de politique programmable (dans Wingman) pour l'autorisation, nous sommes en mesure de sécuriser la communication à l'aide de mTLS et de contrôler chaque accès à l'aide d'une politique robuste et programmable.

Gestion des secrets sans coffre-fort centralisé

Chaque jour, les ingénieurs commettent des erreurs par inadvertance en stockant des clés et des mots de passe dans leur code et ces données finissent d'une manière ou d'une autre par se retrouver dans des référentiels de code ou d'artefacts publics. La gestion des secrets est difficile et sans une boîte à outils facile à utiliser et un processus bien défini, les développeurs sont censés suivre le chemin le plus court. Par conséquent, dès le début de l'entreprise, la mission de notre équipe de sécurité de la plateforme (différente de la sécurité du réseau et des applications) était de garantir que les développeurs n'aient pas à se poser des questions telles que « Où est-ce que je stocke les secrets - le code source ou les artefacts ou … ? »

Nous avons évalué deux approches courantes qui étaient à notre disposition pour la gestion des secrets lorsque nous avons commencé à construire notre plateforme, et toutes deux présentaient certaines lacunes : 

1. Secrets Kubernetes — Bien que nous utilisions Kubernetes et qu'il soit fourni avec sa solution de secrets, il n'est pas particulièrement utile pour diverses raisons : les secrets ne sont pas chiffrés au repos, les constructions de politiques ne sont pas complètes et il ne résout pas les scénarios multi-clusters.
    
2. Coffre-fort centralisé (par exemple Hashicorp ou Cyberark Vault) — Une autre approche aurait pu être d'utiliser un coffre-fort où les secrets sont stockés de manière centralisée et sont distribués aux demandeurs autorisés. Les secrets sont protégés par une clé de cryptage unique utilisée pour le stockage crypté de Vault. Le problème avec cette approche, cependant, est que le système de gestion des secrets a accès à des secrets clairs (même s’ils sont stockés sous forme cryptée) et toute compromission du système pourrait révéler tous les secrets.

Dans notre cas, étant un service SaaS, nous avons dû trouver une méthode plus robuste pour sécuriser les secrets de nos clients, car aucun compromis ne doit révéler leurs secrets.

En conséquence, nous avons décidé de mettre en œuvre une nouvelle technique que nous appelons Volterra Blindfold (marque déposée), qui fonctionne en conjonction avec notre side-car de sécurité, Wingman, comme le montre la figure 4. Cette approche permet au propriétaire du secret de verrouiller (crypter) le secret de telle manière que le secret ne soit jamais révélé en clair à une partie indésirable (y compris le serveur de décryptage). Le secret n’est même pas stocké dans un serveur de décryptage central et cette conception, à certains égards, simplifie considérablement la conception du serveur.

Nous fournissons aux utilisateurs un outil en mode sans fil qui peut être utilisé dans un environnement totalement hors ligne pour crypter le secret (S) qui peut ensuite être distribué. Par exemple, le secret peut lui-même être stocké avec la charge de travail et téléchargé dans le registre. Une fois ceci réalisé, les étapes suivantes doivent être réalisées :

Cela garantit que le plan de contrôle centralisé n'a jamais accès au secret en clair (S) et que le secret n'est disponible que dans la mémoire d'exécution du Pod pendant la durée de l'accès. En outre, une politique d’accès peut être appliquée pour définir qui a accès à un secret. La politique peut être définie en fonction des attributs d'identité tels que le nom de application , l'emplacement, le niveau de conformité, etc. De cette façon, tout sous-ensemble complexe de charges de travail peut être découpé et un contrôle d'accès précis peut être obtenu. La politique est cryptographiquement intégrée dans le processus de chiffrement, d’aveuglement, de déchiffrement et de déverrouillage : il est informatiquement impossible de contrecarrer l’intention de la politique.

En utilisant notre technique unique Blindfold pour verrouiller chaque secret et Wingman pour desceller chaque secret en fonction de la politique et de l'identité infalsifiable, nous sommes en mesure de surmonter les problèmes des solutions existantes et de fournir une gestion des secrets dans un environnement distribué sans jamais nous soucier de la compromission de la mine d'or centrale.

Gestion des clés pour les systèmes distribués

Bien que les secrets et la gestion des clés puissent sembler être deux noms différents pour le même problème, il existe des différences subtiles (mais importantes dans la pratique) entre les deux, selon la personne à qui vous posez la question et la manière dont vous souhaitez mettre en œuvre les solutions.

Le terme secret fait référence à toute information censée être secrète et non accessible aux parties non autorisées. D’une certaine manière, les clés cryptographiques sont un cas particulier de secrets. La gestion des clés, en revanche, fait généralement référence à un système qui stocke en toute sécurité le matériel de clé cryptographique sensible et contrôle l'utilisation de ce matériel. Dans certains cas, le système de gestion des clés peut distribuer des octets bruts de la clé aux parties autorisées et peut donc être confondu avec un système de gestion secret. Cependant, dans la plupart des cas, le système de gestion des clés ne distribue pas réellement les octets bruts du matériel de clé et effectue plutôt des opérations pour les demandeurs autorisés et envoie uniquement le résultat de l'opération. De nombreux systèmes de gestion de clés s'appuient également sur un stockage matériel (par exemple, HSM) pour le matériel clé, de sorte que la clé n'est jamais exposée en clair au logiciel.

Dans les environnements distribués, même pour un seul fournisseur de cloud, le problème de la gestion, de la synchronisation et de la rotation des clés cryptographiques est très difficile et les solutions actuelles sont sujettes aux erreurs, inefficaces et même peu sûres. Par exemple, si l’on utilise aujourd’hui 3 régions AWS et que l’on souhaite utiliser la même clé de chiffrement dans les 3 régions, il faudra synchroniser et faire tourner manuellement les clés. Le problème devient encore pire lorsque l’environnement s’étend sur plusieurs fournisseurs de cloud (publics et/ou privés). Même après tout cela, les propriétaires application doivent encore écrire du code complexe pour utiliser ces fonctionnalités KMS.

Notre plateforme masque toutes les complexités de la gestion des clés de l' application en laissant le side-car Wingman effectuer tout le gros du travail et en fournissant des interfaces simples à l' application pour effectuer les demandes de gestion des clés, y compris le cryptage, le décryptage, le HMAC, la vérification HMAC, la signature numérique, la vérification de la signature, la récupération de la clé (lorsque cela est autorisé), etc. Cela rend la gestion des clés pas du tout intimidante pour nos propres services d’infrastructure ainsi que pour les charges de travail des clients.

Le diagramme suivant (Figure 5) montre comment le KMS de Volterra fonctionne dans différents environnements et aide les charges de travail à décharger leur gestion des clés et leurs opérations de cryptographie sur le side-car Wingman. Selon la configuration, Wingman est capable de mettre en cache des clés et d'actualiser le cache sans même que l' application le sache. Le facteur déterminant ici est l’identité universelle et infalsifiable que nous avons introduite plus tôt. Étant donné que chaque Pod, quel que soit son emplacement, obtient une identité unique à l'échelle mondiale, il est facile pour le système Volterra KMS d'appliquer des politiques d'accès aux clés cryptographiques et à des opérations spécifiques telles que le cryptage, le décryptage, le HMAC, la vérification HMAC, la signature numérique et la vérification de signature de manière très précise.

Étant donné que toutes les clés sont gérées via le backend SaaS de Volterra, les charges de travail exécutées dans des environnements hétérogènes n’ont pas à gérer la synchronisation, la rotation, la révocation des clés, etc. — elles doivent simplement connaître les API Wingman simples pour tous leurs besoins de sécurité des données au repos.

Les bénéfices apportés par notre solution de sécurité de plateforme

Grâce à une sécurité de plateforme multicouche, nous avons pu fournir une solution complète à trois problèmes critiques d’une manière entièrement nouvelle ! Notre système est capable de démarrer en toute sécurité une identité universelle qui ne souffre pas du problème des « tortues jusqu'en bas », de gérer des secrets qui peuvent être stockés et distribués sans jamais se soucier du problème de la mine d'or, et de fournir une gestion des clés pour faciliter la sécurité des données au repos dans un environnement distribué. Cela a conduit aux gains suivants pour nos équipes internes ainsi que pour nos clients : 

1. Sécurité et conformité — identité infalsifiable et universelle, Blindfold et side-car de sécurité (Wingman) entièrement intégré et géré automatiquement par la plateforme pour sécuriser toutes les communications, autoriser chaque accès et gérer les clés/secrets dans un système distribué. Grâce à ces avancées, nous sommes en mesure de fournir une solution de sécurité plus robuste qui a facilité notre capacité et celle de nos clients à respecter les normes de conformité. 
    
2. Améliorations de la productivité — grâce à une solution de sécurité intégrée à notre processus DevOps et à notre cadre de services, il est facile pour les développeurs et les équipes DevOps de se concentrer sur leurs livrables sans se soucier des aspects clés de la sécurité des application et des sécurité des données. 
    
3. Évolution continue — l’évolution du paysage de sécurité et des nouvelles technologies conduisent à une évolution continue de Blindfold, Wingman et de notre Golang Service Framework. Par conséquent, de nouvelles fonctionnalités sont automatiquement déployées par la plateforme sans aucune modification de la logique application .

À suivre…

Cette série de blogs couvrira divers aspects de ce qu'il nous a fallu pour créer et exploiter notre service SaaS distribué à l'échelle mondiale avec de nombreux clusters application dans le cloud public, nos PoP de réseau privé et nos sites périphériques. Ensuite, ce sera la sécurité des application et des réseaux …

Nous recherchons quelques développeurs et architectes de solutions bénévoles pour nous aider à apporter cette capacité à une communauté plus large en tant que projet Open Source, veuillez contacter directement asingla@volterra.io si vous souhaitez participer à quelque chose d'amusant !