Transcription vidéo

Comment vous assurez-vous que vos secrets sont stockés en toute sécurité afin d'éviter les violations de données et le chaos dans vos flux de travail DevOps?

Bonjour, je suis Alex Greer, de l'équipe IBM Cloud. Avant de commencer, veillez à liker et vous abonner.

Qu'est-ce qu'un secret ?

Un secret est une donnée d'identification numérique qui permet aux entités de communiquer et d'effectuer des actions sur un service. Cette information discrète permet d'assurer la sécurité de ce point d'accès. Regardons comment ce paradigme existe.

Commençons par une entité qui a besoin d'accéder à une sorte de service. C'est un peu ambigu pour le moment, mais disons une sorte de service. Pour bien communiquer avec le service et pouvoir prendre les mesures nécessaires pour accomplir son travail, cette entité doit communiquer deux choses au service. Premièrement, qui elle est, afin que le service puisse comprendre quoi ou qui interagit avec lui. Deuxièmement, l'ensemble des droits qu'elle doit accorder dans le contexte de son service. Avec ces informations, le service peut désormais autoriser cette entité à interagir avec lui. Cette interaction est rendue possible par ce que nous appelons un "secret"

Maintenant que cette dynamique est établie, passons à un exemple avec des utilisateurs. Pour les utilisateurs, nous dirons que cet utilisateur est notre entité, et nous dirons que notre service - disons qu'il s'agit d'un développeur, et qu'il a besoin d'un accès en lecture ou en écriture. Pour ce faire, ils interagissent avec la base de données de développement. Pour obtenir cet accès, nous avons besoin d'une autorisation et d'une permission. La communication, en particulier dans ce cas, se fait en fournissant les données d'identification de l'utilisateur. Désormais, cet utilisateur peut interagir avec le référentiel de développement de manière à accomplir son travail.

Dans le cas d'une application native dans le nuage, de nombreux microservices doivent communiquer entre eux. Concentrons-nous sur ce cas. Appelons-le service "A", qui doit interagir avec une base de données appelée "DB" et obtenir un élément d'information spécifique dont il a besoin pour effectuer son travail. Ce dont il a besoin, sous forme de secret ici, est ce que nous appelons des configurations DB. Encore une fois, cette configuration de la base de données va lui permettre de communiquer correctement avec le service en disant, voici qui je suis et ce que je suis venu accomplir ici.

Mais maintenant que nous avons nos identifiants d'utilisateur dans nos configurations de base de données en tant qu'exemples de secrets, nous réalisons la vulnérabilité qui peut être créée ici si ces identifiants tombent entre de mauvaises mains. C'est pourquoi il est si important d'établir un lieu centralisé pour gérer toutes ces choses à mesure que nous développons davantage d'applications et de microservices. Et comme nous en développons toujours plus, le problème est de plus en plus complexe. Et si ces données tombent entre de mauvaises mains, comment sont-elles protégées ? Comment empêcher d'en arriver là ? Comment ces données sont-elles isolées ?

Les dégâts que cela peut provoquer, par exemple pour une atteinte à la protection des données, se comptent en millions de dollars. Si les opérations de développement ne sont pas gérées correctement, sans même parler de l’implication d'un mauvais acteur, cela peut être déroutant pour les équipes. Nous devons donc nous assurer que les données sont centralisées et correctement stockées afin de pouvoir exploiter ces secrets de la bonne manière et permettre une communication correcte avec les services.

Voyons maintenant la couche suivante de l'oignon dans un exemple plus compliqué.

Revenons à Jane, le développeur de l'entreprise. Jane – notre "dev E" ici – doit à nouveau avoir accès à ce référentiel de développement auquel elle s'est référée précédemment. Appelons-le, peut-être, GitHub. Elle doit donc pouvoir avoir un accès en écriture et doit demander les informations qui lui permettront d'accéder à ce rôle. C'est là que Secrets Manager intervient de manière parfaite et complémentaire.

Un service Secrets Manager peut stocker en toute sécurité ces données d'identification, ainsi que d'autres types de secrets, de manière centralisée. Jane peut ainsi y accéder, ou à d'autres services, comme nous le verrons dans une seconde. Jane a alors l'esprit tranquille car ses données d'identification d'utilisateur sont stockées en toute sécurité. Elle peut s'authentifier auprès du service et faire son travail, sachant que Secrets Manager s'occupe de la gestion des secrets à sa place.

Toutefois, ce qui est vraiment important pour le service Secrets Manager, c'est d'interagir avec l'IAM du fournisseur de service de cloud ou le service de gestion des identités et des accès. IAM est la source de vérité qui permet à Secrets Manager d'authentifier Jane et de transmettre l'information à GitHub d'une part, et à Jane d'obtenir l'ensemble de rôles approprié en fonction du paradigme du service IAM d'autre part. Nous comprenons maintenant ce que signifie pour un utilisateur d'obtenir des droits appropriés et de pouvoir accéder à l'outil voulu de son service dans le cadre de l'utilisation d'un service de Secrets Manager.

Examinons maintenant le cas d'un service qui interagit avec un autre service et dans lequel des atteintes à la protection des données pourraient s'avérer nuisibles.

Regardons notre exemple de service à service. Nous allons commencer par une application de prêt. Cette application souhaite demander des droits d'accès à une base de données (comme mentionné précédemment). Soyons un peu plus précis : cette base de données à laquelle il doit accéder est une table donnée de la base de données qui contient les informations nécessaires à fournir à son modèle pour qu'il puisse décider s'il veut fournir un consommateur seul. Nous l'appellerons une base de données de profils. Nous avons donc ici la base de documents de profils et nous savons que l'ensemble d'autorisations que nous souhaitons accorder va être des autorisations en lecture pour le tableau A. Alors, où allons-nous stocker le secret qui va nous permettre en fin de compte d'accéder à l'authentification, puis de définir les autorisations dont nous avons besoin ici ? Encore une fois, ce sera le service de Secrets Manager fourni, qui doit à nouveau communiquer avec IAM Cloud. Maintenant que cela est établi, de quel type de données d'identification disposons-nous ? Les données d'identification dont nous disposons sont appelées des configurations DB. Réfléchissons au scénario parcouru : ces configurations DB permettent à cette application de prêt de disposer de droits d'accès en lecture ou d'utiliser un ensemble spécifique d'informations d'une table provenant d'une base de données contenant des données d'IP et d'autres informations très sensibles. Lorsque ces configurations DB ne sont pas correctement stockées, ou que le service dans lequel elles sont stockées est compromis, le scénario est alors assez catastrophique pour le fournisseur de cette application de prêt qui doit alors informer son client qu'un mauvais acteur a pu profiter de l'accès obtenu à tort à sa configuration DB et s'en servir pour voler ses données et les utiliser contre lui. Pour atténuer ce problème, les données peuvent être stockées dans un emplacement sûr auquel les mauvais acteurs n'ont pas accès et offrant un niveau d'isolement des données adéquat pour l'entreprise. C'est là qu'interviennent les services de Secrets Manager.

Encore une fois, les services de Secrets Manager aident à assurer le stockage sécurisé des secrets afin que vous n'ayez pas à vous soucier des atteintes à la protection des dernières données d'identification ou d'autres types de secrets. Et enfin, cela rend un peu plus efficace la gestion de vos secrets pendant que vous effectuez vos opérations DevOps.

Merci. Si vous avez des questions, écrivez-nous. Si vous souhaitez voir plus de vidéos comme celle-ci, abonnez-vous et n'oubliez pas que vous pouvez développer vos compétences et gagner un badge IBM Cloud Labs, qui sont des laboratoires Kubernetes interactifs gratuits sur navigateur.

Utilisation de secrets de différents types

Les secrets que vous créez dans Secrets Manager peuvent être statiques ou dynamiques. La date et l'heure d'expiration d'un secret statique entrent en vigueur au moment de sa création ou de sa rotation. En revanche, la date et l'heure d'expiration d'un secret dynamiqueValeur unique, telle qu'un mot de passe ou une clé d'API, créée dynamiquement et louée à une application qui requiert l'accès à une ressource protégée. Une fois qu'un secret dynamique atteint la fin de son bail, l'accès à la ressource protégée est révoqué et le secret est supprimé automatiquement. sont appliquées lorsque les données secrètes sont lues ou consultées.

Secrets Manager classe davantage les secrets statiques et dynamiques par leur fonction ou objectif général. Par exemple, chaque type de secret est identifié par un nom dans le programme, tel que username_password. Si vous cherchez à gérer votre secret à l'aide de l'API ou de l'interface de ligne de commande Secrets Manager, vous pouvez utiliser ces noms dans le programme pour exécuter des opérations sur les secrets en fonction de leur type.

Consultez le tableau suivant pour connaître les types de secrets statiques et dynamiques que vous pouvez créer et gérer à l'aide du service.

* Requiert une configuration du moteur avant que les secrets ne puissent être créés dans le service.

Fonctions prises en charge par type de secret

Le tableau suivant compare et met en contraste certaines caractéristiques communes entre les types de secrets.

Comparaison des caractéristiques entre les types de secrets

	Secrets arbitraires	Données d'identification IAM	Données d'identification utilisateur	Secrets clé-valeur	Certificats importés	Certificats publics	Certificats privés	Données d'identification du service	Données d'identification personnalisées
Rotation automatique		[1]
Rotation manuelle
Paramètre d'expiration
Notifications
Historique de version
Restauration vers la version précédente
Support SDK
Support de plug-in CLI
Compatibilité de l'API HTTP de HashiCorp Vault

De quoi est composé un secret ?

Les secrets que vous stockez à l'aide du service sont composés d'attributs de métadonnées et d'une valeur de secret. Les attributs de métadonnées vous permettent d'identifier un secret tandis que la valeur de secret correspond aux données dont les services protégés ont besoin pour authentifier et autoriser votre application ou vous-même.

Reportez-vous à l'image ci-dessous pour découvrir la structure d'un secret.

{
    "name": "my-username-password",
    "id": "cb123456-8e73-4857-594839587438",
    "description": "Description for this secret",
    "secret_type": "username_password",
    "secret_group_id": "ab654321-3958-9484-1395840384754",
    "state": 1,
    "state_description": "Active",
    "create_by": "iam-ServiceId-gj403948-3048-6059-304958674930",
    "created_at": "2023-03-08-T20:44:11Z",
    "labels": [
        "dev",
        "us-south"
    ],
    "username": "user123",
    "password": "cloudy-rainy-coffee-book"
}

1. Les zones name, idet description, ainsi que d'autres zones communes contiennent des informations d'identification relatives à un secret. Ces zones contiennent les attributs généraux de votre secret, que vous pouvez utiliser pour connaître sa finalité et son historique.

2. Lorsque vous extrayez la valeur d'un secret, les zones renvoyées diffèrent en fonction du type de secret.

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour un secret arbitrary.

   {
       "name": "my-secret",
       "secret_type": "arbitrary",
       ...
       "payload": "The quick brown fox jumped over the lazy dog."
   }
   

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour un secret username_password.

   {
       "name": "my-secret",
       "secret_type": "username-password",
       ...
       "username": "foo",
       "password": "bar"
   }
   

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour un secret IAM credential.

   {
       "name": "my-iam-credentials",
       "secret_type": "iam_credentials",
       ...
       "api_key": "RmnPBn6n1dzoo0v3kyznKEpg0WzdTpW9lW7FtKa017_u",
       "api_key_id": "ApiKey-dcd0b857-b590-4507-8c64-ae89a23e8d76",
       "service_id": "ServiceId-bb4ccc31-bd31-493a-bb58-52ec399800be",
   }
   

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour un secret KV.

   {
       "name": "my-kv-secret",
       "secret_type": "kv",
       ...
       "data": '{"key":"value"}'
   }
   

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour les secrets imported_cert et public_cert.

   {
       "name": "my-certificate",
       "secret_type": "imported_cert/public_cert",
       ...
       "certificate":"...",
       "intermediate":"...",
       "private_key":"..."
   }
   

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour un secret private_cert.

   {
       "name": "my-certificate",
       "secret_type": "private_cert",
       ...
       "certificate":"...",
       "ca_chain":"...",
       "private_key":"..."
   }
   

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour un secret service_credentials.

   {
       "name": "my-secret",
       "secret_type": "service_credential",
       ...
       "credentials": {
           "key": "The quick brown fox jumped over the lazy dog."
           }
   }
   

   L'exemple tronqué suivant montre comment les données secrètes sont représentées pour un secret custom_credentials.

   {
       "name": "my-secret",
       "secret_type": "custom_credential",
       ...
       "credentials_content": {
           "key": "The quick brown fox jumped over the lazy dog."
           }
   }
   

Etats et transitions de secret

Les secrets, au cours de leur durée de vie, passent par plusieurs états qui sont fonction de la durée d'existence des secrets et de la possibilité d'accéder à leurs ressources associées.

Secrets Manager fournit une interface utilisateur graphique et une API REST pour le suivi des secrets à mesure qu'ils passent par différents stades de leur cycle de vie. Le schéma suivant montre comment un secret passe par différents états entre sa génération et sa destruction.

Premiers pas

Pour vous familiariser avec les secrets, vous pouvez accéder à la page Secrets de l'interface utilisateur de Secrets Manager ou consulter le fichier Référence d'API pour en savoir plus sur la création de secrets à l'aide d'un programme.