Imaginez ce scénario. Vous développez une application et avez besoin d'une clé API pour vous connecter à un service d'un mot de passe, de base de données ou d'une clé de compte de stockage. Alors vous l'insérez directement dans votre code, peut-être dans un fichier de configuration ou une variable d'environnement. Ça fonctionne et tout tourne normalement jusqu'à ce que vous poussiez ce code sur GitHub ou partagez un notebook avec un collègue, avec un collègue. Et voilà, votre secret n'en est plus vraiment un. Si ce code tombe entre de mauvaises mains, tout votre système est exposé. Azure Key Vault est l'outil qui résout ce problème. Il vous offre un endroit sécurisé pour stocker vos secrets afin qu'ils ne finissent jamais dans votre code. Mais voici ce que la plupart des gens oublient. Le simple fait d'avoir un Key Vault ne vous rend pas automatiquement sécurisé. La manière dont vous le configurez, contrôlez l'accès et attribuez les permissions est tout aussi importante.

À la fin de cet épisode, vous saurez ce qu'est réellement Key Vault, ce que vous pouvez y stocker, comment fonctionne l'accès et la plus grosse erreur qui pourrait exposer vos secrets. Le tout dans langage simple, sans jargon juste l'essentiel dont vous avez besoin. Alors qu'est-ce que Azure Key Vault exactement ? Qu'est-ce que Azure Key Vault ? Voici la définition la plus simple. Azure Key Vault est un coffre-fort numérique basé sur le cloud pour vos secrets. C'est un service géré par Microsoft pour centraliser clés API, mots de passe de base de données, chaînes de connexion, clés de chiffrement et certificats. Vous n'avez pas à vous soucier de l'infrastructure, car Azure gère les mises à jour, la disponibilité et la sécurité. Vous n'avez qu'à l'utiliser. Imaginez cela comme un immeuble de bureau. Vous avez des postes de travail, des salles de réunion et des dossiers, mais quelque part, au sous-sol, il y a une salle forte où vous gardez les éléments importants, clés maîtresses, argent liquide, documents juridiques.

Personne n'y entre sans autorisation ni authentification. Et chaque fois qu'il y a un ouvre la porte, c'est qu'on signe dans un journal. C'est ça Key Vault. La salle sécurisée au sous-sol de votre architecture Azure. Maintenant, comparez cela à l'ancien état. Il y a 20 ans, si vous aviez besoin d'un mot de passe de base de données, vous le codiez en dur dans un fichier de configuration, une variable d'environnement, au pire, en texte brut dans votre code source. Si quelqu'un accédait à ce serveur, il avait tout. Et si vous deviez renouveler ce mot de passe, il fallait le mettre à jour partout. Chaque fichier de configuration, chaque environnement, chaque déploiement. C'est un cauchemar. Key Vault change tout cela. Au lieu de disperser vos secrets dans votre code et vos fichiers de configuration, vous les stockez en un seul endroit central. Vos applications les demandent lors de l'exécution, uniquement quand elles ont besoin.

Et comme tout est centralisé, vous pouvez renouveler un secret à un seul endroit et chaque application qu'il utilise récupère la nouvelle valeur, automatiquement, sans modification de code, ni redéploiement, ni redéploiement. Mais voici le point important. Key Vault n'est pas juste un gestionnaire de mots de passe pour vos applications. C'est un service de sécurité fondamental. Chaque service Azure peut s'y intégrer. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, les Pipeline DevOps, tous savent communiquer avec Key Vault. Il devient l'épine dorsale de votre architecture cloud sécurisée. Une fois configuré correctement, vous n'avez plus du tout à vous soucier de la gestion des identifiants. Que pouvez-vous stocker ? Maintenant que vous savez ce qu'est Key Vault, parlons de ce que vous pouvez réellement y mettre. Vous disposez de trois catégories principales. Les secrets, les clés et les certificats.

Chacune a un rôle différent et comprendre cette différence vous aide à utiliser Key Vault correctement. Commençons par les secrets. C'est ce que les gens stockent le plus couramment. Les secrets incluent les chaînes de connexion, les clés API, les mots de passe de base de données, les clés de compte de stockage, en somme tous les identifiants quotidiens dans vos applications quotidiens dont vos applications ont besoin pour déloguer avec d'autres services. Au lieu de les insérer dans votre code ou votre fichier de configuration, vous les placez dans Key Vault. Votre application les récupère à l'exécution et personne ne les voit jamais en texte clair. Voyez cela comme un tiroir verrouillé dans votre armoire de classement numérique. Viennent ensuite les clés. Il s'agit de clés de chiffrement pour les données au repos. Si vous utilisez des clés gérées par le client pour le stockage Azure, les bases de données SQL ou le chiffrement de disques de machines virtuelles, ces clés peuvent résider dans Key Vault.

Cela vous donne un contrôle total sur qui peut les utiliser et quand. Et si vous avez besoin de clés matérielles pour la conformité, le niveau premium vous protège grâce au HSM. Les certificats ? Certificats TLS et SSL pour vos applications web, API et services internes. Key Vault peut les stocker, gérer leur cycle de vie et même les renouveler automatiquement lorsqu'ils arrivent à expiration. C'est un véritable soulagement pour quiconque a déjà vu un certificat expirer à 3h du matin, un dimanche. Voici un exemple concret. Imaginez une application web ayant besoin d'une chaîne de connexion et d'une clé API pour un service tiers. A l'ancienne, vous auriez mis les deux dans votre fichier de paramètres GISA. Si ce fichier finit dans votre dépôt, quiconque a accès au code peut voir vos identifiants de base de données. Avec Key Vault, vous stockez ces deux valeurs en tant que secret. Votre application les récupère au démarrage et ils n'apparaissent jamais dans votre code source.

Besoin de renouveler le mot de passe de la base de données ? Mettez-le à jour dans Key Vault. L'application récupère la nouvelle valeur automatiquement au redémarrage suivant. Aucun changement de code, aucun redéploiement. Ce qui surprend souvent, c'est que le versionnage est intégré. Lorsque vous mettez à jour un secret, Key Vault ne remplace pas l'ancienne valeur et crée une nouvelle version. Les anciennes versions sont conservées pour pouvoir revenir en arrière en cas de problème. C'est extrêmement pratique lors d'incidents. Vous pouvez rapidement revenir à un secret précédent sans avoir à vous souvenir de son ancienne valeur. Vous pouvez stocker les trois types, secrets clés et certificats, dans le même coffre. Mais la meilleure pratique consiste à les séparer par environnement. Ayez un coffre pour le développement, un pour les tests et un pour la production. Cela évite d'utiliser accidentellement un secret de production en environnement de dev et limite l'impact si un coffre est compromis.

Mais stocker des secrets n'est qu'une partie de l'histoire. La vraie question est de savoir qui peut y accéder. Comment fonctionne le contrôle d'accès ? Parlons maintenant de qui peut entrer. Key Vault propose deux manières de contrôler l'accès et votre choix a une grande importance. Le premier modèle concerne les stratégies d'accès hérité. C'est l'ancienne méthode. Vous créez des stratégies directement sur le coffre et vous attribuez des autorisations à des utilisateurs ou groupes pour des types de données précis. Le problème est que ces stratégies sont liées directement au coffre. Si vous avez plusieurs coffres, vous devez gérer les stratégies séparément pour chacun. Cela n'est pas extensible. Microsoft déconseille désormais leur utilisation en raison de problèmes de sécurité connus. Elles ne prennent pas en charge la gestion des identités privilégiées et peuvent créer des chemins d'escalade inattendus.

Le second modèle est le contrôle d'accès en fonction du rôle Azure RBAC. C'est la méthode moderne. Elle utilise les identités entre ID et reste cohérente avec la gestion des autorisations dans le reste d'Azure. Si vous savez déjà accorder l'accès à un compte de stockage ou une machine virtuelle, vous savez déjà le faire. Pour Key Vault. Même système, même modèle. Voici la règle d'or, le moindre privilège. N'accorder que le minimum d'accès nécessaire, rien de plus. Si quelqu'un a seulement besoin de lire des secrets, ne lui donnez pas la permission de les créer ou de les supprimer. Si quelqu'un n'a besoin que de gérer des certificats, ne lui donnez pas accès aux clés. Laissez-moi passer en revue les rôles principaux. Il y a le lecteur Key Vault. Cela permet de lister les secrets, mais pas de lire leurs valeurs. Utisateur de secrets Key Vault. Cela permet de lire réellement les valeurs des secrets et responsable des secrets Key Vault.

Cela permet de créer, mettre à jour et supprimer des secrets. Notez la logique. Chaque rôle est spécifique aux données dans le coffre, pas au coffre lui-même. Ah ! Comparons maintenant cela aux rôles étendus. Propriétaire, contributeur, lecteur. S'applique au coffre-fort en tant que ressource et non aux données qu'il contient. Un propriétaire peut supprimer l'intégralité du coffre-fort. Un contributeur peut modifier les paramètres du coffre-fort. Cependant, aucun de ces rôles ne donne accès aux secrets à l'intérieur. Il s'agit d'une couche d'autorisation distincte et c'est le point essentiel. Le contrôle d'accès est comme un gâteau à plusieurs coups. Vous avez besoin d'accès au coffre-fort lui-même, c'est la première couche et aux données à l'intérieur, c'est la seconde. Les deux doivent être accordés séparément. La plupart des débutants ne pensent qu'à la première couche et oublient la seconde.

C'est là que les problèmes commencent. L'erreur de sécurité numéro 1. Voici le problème. La plupart des gens voient le rôle de contributeur Key Vault et pensent qu'il est su. Ils voient le mot contributeur et supposent qu'ils peuvent gérer les paramètres sans toucher au secret. La documentation de Microsoft disait initialement exactement cela. Ce rôle ne vous permet pas d'accéder aux secrets, clés ou certificats. Sauf que ce n'est pas tout à fait vrai. Un utilisateur avec le rôle contributeur Key Vault peut modifier les stratégies d'accès du coffre. Et si ce coffre utilise encore les anciennes stratégies d'accès, ce qui est courant, il peut s'accorder un accès en lecture complet ou ads. Aucun exploit spécial n'est nécessaire, aucune vulnérabilité à corriger. C'est simplement le fonctionnement des autorisations. Des chercheurs en sécurité chez Datadog l'ont prouvé en 2024. Ils ont montré qu'un contributeur peut obtenir un accès complet aux données via les anciennes stratégies La réponse de Microsoft a été intéressante.

Ils ont affirmé que ce n'était pas une vulnérabilité, mais ils ont mis à jour la documentation pour avertir que ce rôle peut s'octroyer un accès aux données. Ce n'est donc pas un bug de Key Vault, mais un piège de configuration. Même les équipes expérimentées se font avoir car le nom du rôle semble inoffensif. Contributeur ne semble pas être quelqu'un qui peut lire vos mots de passe de base de données, mais en pratique, il le peut. Réfléchissez au risque. Si un attaquant compromet un compte avec le rôle de contributeur, il n'a pas besoin de forcer le corps. Il n'a pas besoin de casser le chiffrement. Il modifie simplement la stratégie d'accès, s'accorde un accès en lecture et exfiltre silencieusement tous vos secrets, chaînes de connexion, clés API, certificats, tout. Et comme les changements de stratégie sont une activité administrative courante, cela ne peut nous déclencher aucune alerte.

Son, quelle est la solution ? D'abord, utilisez le Airbacé Azure pour l'accès aux données au lieu des anciennes stratégies d'accès. Le Airbac sépare la gestion du coffre-fort des données qu'il contient. Deuxièmement, n'attribuez jamais le rôle de contributeur Key Vault à quelqu'un qui n'en a pas absolument besoin. Troisièmement, si vous avez déjà des utilisateurs avec ce rôle Auditélé dès aujourd'hui, remplacez le rôle de contributeur par des rôles plus précis comme utilisateur de secrets Key Vault ou responsable de secrets Key Vault. Il existe une deuxième erreur qui aggrave la première. Placez tous vos secrets dans un seul coffre. Si vous utilisez un seul coffre pour tout, développement, test, pré-production, production, toutes vos applications et qu'il est compromis, tout est exposé. C'est un point de défaillance unique ? Nous parlerons un peu plus

Ne mettez pas tous vos oeufs dans le même panier, surtout quand ce panier contient les clés de toute votre infrastructure. L'identité gérée, la référence absolue. Alors comment bien faire les choses ? Parlons de la meilleure façon d'accéder à Key Vault. Il y a un problème fondamental. Pour obtenir des identifiants depuis Key Vault, votre application doit s'authentifier mais pour s'authentifier, elle a besoin d'identifiants ou stockez-vous les identifiants que votre application utilise pour obtenir des identifiants. C'est le problème de l'œuf et de la poule. L'ancienne solution était un principal de service avec un secret client. Mais ce secret doit être stocké quelque part dans un fichier de configuration, des variables d'environnement ou un pipeline de déploiement ou un pipeline de déploiement. Et voilà revenu au point de départ, vous avez simplement déplacé le secret ailleurs. L'identité gérée résout complètement ce problème.

Voici comment cela fonctionne. Lorsque vous activez l'identité gérée sur une ressource Azure comme une application web, une fonction ou une machine virtuelle, Azure crée automatiquement une identité pour cette ressource dans EntraID. Cette identité est entièrement gérée par Azure. Aucun identifiant à créer, aucun secret à renouveler, rien à stocker. La ressource possède simplement une identité connue d'Azure. Il en existe deux types. L'identité gérée affectée par le système est liée à une ressource spécifique. Si vous supprimez la ressource, l'identité disparaît également. Elle partage le même cycle de vie, ce qui simplifie l'administration. L'identité gérée affectée par l'utilisateur est une identité autonome que vous pouvez attribuer à plusieurs ressources. Elle ne partage pas son cycle de vie avec elle, ce qui est utile lorsque vous avez besoin de la même identité pour plusieurs services.

Voici à quoi cela ressemble en pratique. Vous avez une application web qui doit lire une chaîne de connexion de bases de données depuis Key Vault. Vous activez l'identité gérée affectée par le système sur l'application web. Ensuite, vous accordez à cette identité le rôle d'utilisateur de secrets Key Vault sur votre coffre. C'est tout. Plus de chaînes de connexion dans le code, plus de secrets clients dans les fichiers de configuration. L'application web s'authentifie auprès de Key Vault en utilisant son identité gérée et Azure gère toute la gestion des identifiants en arrière-plan. C'est ce qui se rapproche le plus d'une authentification sans identifiant dans Azure. C'est une révolution pour la sécurité car cela élimine le vecteur d'attaque le plus courant, le vol d'identifiant, le vol d'identifiant. S'il n'y a pas d'identifiant à voler, un attaquant n'a rien à compromettre. Laissez-moi vous donner un exemple concret.

Imaginez un pipeline de données dans Synapse qui doit accéder à un compte de stockage. A l'ancienne, vous stockeriez la clé du compte de stockage dans la configuration du pipeline. Si quelqu'un obtenait l'accès à ce pipeline, il avait la clé. Avec l'identité gérée, l'espace de travail Synapse possède une identité. Cette identité reçoit l'accès à Key Vault où la clé du compte de stockage est stockage et stockée. Le pipeline récupère la clé lors de l'exécution, l'utilise et ne la stocke jamais nulle part. Aucune clé dans le code, aucun secret dans la configuration du pipeline. En combinant l'identité gérée avec RBAC et le moindre privilège, vous obtenez une base sécurisée pour toute charge de travail Azure. Vos applications s'authentifient sans identifiant. Elles n'accèdent qu'à ce dont elles ont besoin et chaque accès est journalisé et auditable. C'est le modèle recommandé par Microsoft pour presque tous les scénarios.

Une fois que vous commencerez à l'utiliser, vous vous demanderez pourquoi vous faisiez autrement. Coût et stratégie multicoffre. Parlons donc des coûts. C'est là que la plupart des gens sont surpris. Combien coûte réellement Azure Key Vault ? Le modèle de tarification est ça. Pas de frais de stockage par secret. Vous ne payez pas pour chaque mot de passe ou clé API que vous stockez. Au lieu de cela, vous payez par opération. Pour le niveau standard, c'est environ 3 centimes pour 10 000 opérations. Un appel de récupération de secret compte comme une opération. Tout comme la création d'un secret ou la liste du contenu du coffre. Pour une application classique de petite à moyenne taille, cela représente quelques centimes par mois. Vraiment quelques centimes. Comparer cela à AWS Secrets Manager. Il facture 40 centimes par secret et par mois juste pour le stockage, plus des frais pour les appels API.

Si vous avez 100 secrets, cela fait 40 dollars par mois avant même d'en lire un seul. Avec Azure Key Vault, 100 secrets avec une utilisation modérée pourrait vous coûter 15 centimes. La différence augmente rapidement à grande échelle. Il existe également un niveau premium. Il ajoute des clés protégées par HSM pour les charges de travail nécessitant le plus haut niveau d'assurance cryptographique. Pensez aux transactions financières, aux données de santé, aux systèmes gouvernementaux. Le coût par opération est plus élevé. Environ 15 centimes pour 10 000 opérations pour les types de clés avancées, plus des frais mensuels, par clé HSM, par clé HSM. Mais pour la plupart des applications, le niveau standard est largement suffisant. Voici la surprise tarifaire qui prend les gens au dépourvu. Pour une application web classique avec quelques secrets et quelques milliers d'opérations par mois, Key Vault coûte moins d'un dollar.

Vous dépenserez plus dans le café que vous boirez en le configurant. Mais il existe une stratégie qui compte plus que le coût.

Proche intelligente est une stratégie multicoffre. Utilisez des coffres séparés pour le développement, les tests, la pré-production et la production. Cela évite l'accident le plus courant. Quelqu'un exécutant un script de test qui lie accidentellement à une base de données de production car la chaîne de connexion était dans le même coffre. Lorsque les environnements sont séparés, cette erreur devient impossible. Vous devriez également séparer par unité commerciale ou domaine de conformité. Si vous gérez des données de carte de paiement, placez ces secrets dans leur propre coffre. Les charges de travail métier général vont dans un autre, les données de santé et dans un troisième. Il ne s'agit pas de compliquer les choses, mais de limiter le rayon d'action d'un incident. Si un coffre est compromis, seuls les secrets de ce coffre sont exposés. Le reste de votre infrastructure reste en sécurité et deux filets de sécurité intégrés que vous devriez toujours activer.

La suppression réversible signifie que si quelqu'un supprime un secret, il n'est pas définitivement perdu. Il passe dans un état récupérable pour une période de rétention que vous choisissez jusqu'à 90 jours. La protection contre la purge va encore plus. Personne ne peut supprimer définitivement le coffre ou son contenu avant l'expiration de cette période de rétention. Ensemble, ils empêchent le genre de perte de données accidentelles qui empêchent les équipes de sécurité de dormir. Comment tout cela se connaît ? Relions tout cela ensemble et voyons comment les pièces s'assemblent. Kivolt n'est pas une île. C'est le système nerveux central des secrets. Dans votre architecture Azure, lorsque vous comprenez comment tout le système fonctionne, tout devient clair. Voici ce qui se passe lorsqu'une application a besoin d'un secret. L'application le demande en utilisant son identité gérée. Cette identité est déjà enregistrée dans Antra ID.

Azure la crée automatiquement lorsque vous avez activé l'identité gérée sur la ressource. Antra ID valide que l'identité légitime puis transmet la demande à Kivolt. Kivolt vérifie les autorisations RBS que vous avez attribuées. Si l'identité possède le bon rôle comme utilisateur des secrets, Kivolt, le secret, est renvoyé. Tout cela se produit en quelques millisecondes. L'application ne voit jamais d'identifiant. Elle ne stocke jamais de mots de passe. Elle obtient simplement la valeur dont elle a besoin. Maintenant, pensez à combien de services Azure peuvent s'y connecter. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, DevOps, Pipelines. Ils savent tous comment communiquer avec Kivolt. Vous pouvez configurer une application web pour référencer un secret directement dans ces paramètres d'application. Vous pouvez configurer un pipeline Data Factory pour récupérer une clé de compte de stockage depuis Kivolt hors de l'exécution.

Vous pouvez configurer un cluster Kubernetes pour récupérer des secrets via le pilote CSI de Kivolt. Chaque service s'intègre de la même manière, avec le même système d'identité, les mêmes relais rebancés et les mêmes journaux d'audit. Le modèle CICD est particulièrement puissant. Vos pipelines récupèrent les secrets depuis Kivolt au moment du déploiement. Ils ne les stockent jamais dans des variables de pipeline ou des secrets de référentiel. Si vous devez renouveler le mot de passe d'une base de données, vous le mettez à jour dans Kivolt. A la prochaine exécution de votre pipeline, ils récupèrent automatiquement la nouvelle valeur. Aucune modification de pipeline, aucun changement de code, aucun redéploiement. Voici ce qui rend tout cela cohérent. Une fois Kivolt configuré avec une identité managée et air basse, vous n'avez plus à vous soucier de la gestion des identifiants. Vos applications fonctionnent tout simplement.

Les secrets sont renouvelés sans que personne ne s'en aperçoive. Les certificats sont renouvelés sans urgence en pleine nuit. Le système gère tout cela en arrière-plan. C'est la posture de sécurité qui compte. L'identité est le périmètre par le réseau. Peu importe qu'une personne soit à l'intérieur ou à l'extérieur de votre réseau virtuel, ce qui compte, c'est de savoir si elle dispose d'une identité valide avec les bonnes autorisations. Kivolt impose cela par conception. Chaque demande d'accès passe par l'authentification entre ID et l'autorisation RBAC, quelle que soit sa provenance. Et tout est consigné. Chaque lecture de secret, chaque opération de clé, et chaque récupération de certificat. Vous pouvez voir qui a accédé à quoi et quand. Si quelque chose semble suspect, vous disposez des données pour enquêter. C'est crucial pour la conformité, la réponse aux incidents et pour savoir ce qui se passe dans votre environnement.

C'est là toute la beauté du système. Kivolt, entre ID et RBAC et l'identité managée fonctionnent ensemble comme un cadre de sécurité unifié. Chaque élément renforce les autres. Et lorsqu'ils sont tous bien configurés, vous disposez d'un système de gestion des identifiants plus sécurisé et plus simple à utiliser que tout ce que vous pourriez créer vous-même. Conseil pratique. Alors que devriez-vous faire concrètement demain ? Transformons ces connaissances en actions. Voici les points que vous pouvez traiter cette semaine. Commencez par votre modèle d'autorisation. Ouvrez votre Kivolt dans le portail, accédez à la configuration d'accès et vérifiez ce qui est indiqué. Si vous voyez stratégie d'accès au coffre V, c'est l'ancienne méthode. Vous devriez privilégier le contrôle d'accès en fonction du rôle Azure. La migration est simple. Changez de modèle d'autorisation et attribuez des rôles RBAC aux personnes qui avaient déjà des stratégies d'accès.

Faites-le dès aujourd'hui. Microsoft le recommande et les recherches dont nous avons parlé en ont montré la raison exacte. Ensuite, auditez les comptes possédant le rôle de contributeur Kivolt. Ouvrez le volet IM de votre coffre et vérifiez qu'il dispose d'un accès contributeur. Toute personne ayant ce rôle doit avoir une raison valable. La plupart du temps, ce n'est pas le cas. Remplacez contributeur par quelque chose de plus spécifique. Si quelqu'un a seulement besoin de dire des secrets, utilisez l'utilisateur des secrets Kivolt. S'ils doivent gérer des secrets, utilisez le responsable des secrets Kivolt. L'objectif est de fermer complètement ce chemin d'escalade. Ensuite, tirez parti de l'identité gérée. Tout service Azure nécessitant l'accès à Kivolt devrait l'utiliser. Si vous avez une application web, une fonction, une data factory ou une machine virtuelle, utilisant encore un principal de service avec un secret client passé à l'identité gérée.

C'est plus simple, plus sécurisé et cela résout le problème de l'œuf et de la poule évoquée. Azure gère la gestion des informations d'identification pour vous en arrière. Une dernière chose, activez la suppression réversible et la protection contre le vidage sur chaque coffre. La suppression réversible est activée par défaut mais pas la protection contre le vidage. Activez-la. Ce paramètre empêche quiconque de supprimer définitivement un coffre ou son contenu pendant la période de rétention. Cela a sauvé plus d'une équipe d'une erreur désastreuse. Voici votre appel à l'action. Examinez votre approche actuelle de gestion des secrets. Trouvez un secret qui se trouve encore dans un fichier de configuration, une variable d'environnement au codé en dur. Déplacez-le vers Kivolt cette semaine, juste un seul. Une fois que vous verrez à quel point c'est simple que vous voudrez déplacer le reste. La sécurité n'est pas une configuration unique.

C'est une pratique. Kivolt facilite cette pratique mais seulement si vous l'utilisez correctement. Les outils sont là. Les modèles ont fait leur propre. Maintenant, c'est à vous de les mettre en œuvre. C'est ça le système. Kivolt est votre coffre-fort numérique mais il n'est aussi sûr que les contrôles d'accès que vous mettez en place. Commencez par l'audit que je viens d'écrire. Vérifiez votre modèle d'autorisation. Vérifiez vos attributions de contributeurs et déplacez un secret dans un coffre cette semaine. Abonnez-vous pour plus de conseils en sécurité cloud et partagez ceci avec quelqu'un qui stocke encore des secrets dans des fichiers de configuration.