Présentation de la haute disponibilité et de la reprise après incident pour Secrets Manager

La haute disponibilitéLa capacité d'un service ou d'une charge de travail à résister aux défaillances et à continuer à fournir une capacité de traitement selon un niveau de service prédéfini. (HA) est la capacité d'un service à rester opérationnel et accessible en cas de défaillance inattendue. La reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception de haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.

Secrets Manager est un service régional qui remplit les objectifs de niveau de service(SLO) définis avec le plan standard. Pour plus d'informations sur les régions et les centres de données disponibles pour Secrets Manager IBM Cloud, voir Disponibilité des services et de l'infrastructure par emplacement.

Architecture à haute disponibilité

Une instance de service Secrets Manager est provisionnée sur trois zones dans une région multizone sans point de défaillance unique. Les demandes d'API sont acheminées via un équilibreur de charge global vers trois nœuds d'instance HA situés chacun dans une zone de disponibilité différente.

Si une zone de disponibilité subit des défaillances, le service continuera à fonctionner, les demandes d'API étant acheminées via un équilibreur de charge global vers les nœuds d'instance HA survivants. Il peut s'écouler un court laps de temps (quelques secondes) entre la panne et la reconnaissance de la défaillance par l'équilibreur de charge global, pendant lequel des demandes peuvent être envoyées à l'instance défaillante. Les charges de travail qui accèdent de manière programmatique à l'instance de service doivent suivre la logique de relance de la disponibilité du client pour maintenir la disponibilité. Il n'y a pas de dégradation notable du service en cas de défaillance d'une zone.

les instances de IBM Cloud® Secrets Manager sont hautement disponibles et ne nécessitent aucune configuration.

Architecture de reprise après sinistre

Pour récupérer une instance de service hors service, une instance de service de récupération doit être créée dans une région de récupération. En général, l'instance de service de reprise doit être configurée avec les mêmes données que l'instance de service source, mais il existe des exceptions à cette règle.

Certains secrets devront être adaptés à la région de récupération, par exemple les chaînes de connexion ou les clés API peuvent faire référence à des instances de service spécifiques à la région. Ces valeurs seront différentes dans l'instance du service de récupération.

L'instance de service Secret Manager peut avoir des dépendances créées par le client sur ces services optionnels, assurez-vous qu'ils existent dans la région récupérée.

Une telle instance devrait être créée avant le fait (avant tout désastre potentiel) et maintenue en synchronisation avec l'instance source.

Fonctionnalités de reprise après sinistre

Secrets Manager prend en charge les fonctions de reprise après sinistre suivantes :

Planifier le rétablissement dans une région de rétablissement. L'instance de récupération doit s'aligner sur la charge de travail " les approches de reprise après sinistre dans le cadre du " IBM Cloud. L'instance de reprise doit suivre les modifications apportées aux données de l'instance de service principale, notamment en ce qui concerne les groupes, les secrets, les versions de secrets, les certificats et les notifications d'événements.

Si le sinistre n'a pas d'incidence sur l'instance de service de production, par exemple en cas de corruption des données, le client peut réparer les données dans l'instance de service en place.

Le service prend en charge les options de reprise après sinistre suivantes :

Caractéristiques du DR pour Secrets Manager
Fonction	Description	Élément à prendre en compte
Rotation	Rétablir la version secrète précédente	L'instance de service de production doit être disponible. Il y a un nombre limité de versions dans l'historique des versions. Voir les problèmes connus et les limites.

Toutes les autres options de reprise après sinistre sont créées et prises en charge par le client.

Caractéristiques DR des clients pour Secrets Manager
Fonction	Description	Élément à prendre en compte
Source externe de vérité	Tous les secrets sont créés à l'aide d'un script, décrit ci-dessous.	Le client doit créer le script et conserver la configuration à un endroit où elle peut être utilisée en cas de sinistre
Sauvegarde et restauration	Sauvegarde d'une instance de service à l'aide d'un script écrit par le client.	Le client doit créer le script et conserver la copie de sauvegarde à un endroit où elle pourra être utilisée lors de la récupération
Synchronisation en direct	Les changements secrets dans la production sont automatiquement observés et propagés pour récupérer l'instance de service, voir la description ci-dessous	Le client doit créer et entretenir les outils. La corruption des données sera synchronisée avec l'instance de récupération.

Fonction de rotation

Les secrets du gestionnaire de secrets sont généralement mis à jour par "rotation", l'écriture d'une valeur entraînant la création d'une nouvelle version du secret. Il peut être possible de rétablir les données corrompues en restaurant les secrets d'anciennes versions dans l'instance de production. Seul un nombre fixe de versions est conservé. Voir gestion des versions secrètes.

Source externe de vérité Caractéristique fournie par le client

Le client doit créer et utiliser une combinaison de terraformes, de scripts ou de programmes comme source de vérité. Mettez d'abord à jour la source de vérité, puis utilisez-la pour créer/mettre à jour l'instance de service primaire et l'instance de service de récupération. La source doit être disponible pour la version de restauration et constitue un point de défaillance unique.

Si un client déclare un sinistre dans l'instance primaire, le service de la région de reprise sera utilisé (exploitation minimale) ou créé (empreinte zéro). Redirigez les composants de votre charge de travail vers l'instance récupérée ou insérez éventuellement dans le code de réessai de votre application pour rediriger les demandes vers la deuxième instance (opération minimale).

Le référentiel qui contient la source de vérité doit pouvoir être récupéré à un moment donné, par exemple à l'aide de buckets Object Storage avec versioning, ou de référentiels Github.

Sauvegarde et restauration des fonctionnalités fournies par le client

Pour sauvegarder manuellement vos secrets d'une région à l'autre, vous devez d'abord avoir une instance de Secrets Manager dans une autre région. Exécutez ensuite les étapes suivantes pour garantir la disponibilité entre les régions.

Répertoriez et téléchargez les secrets de votre instance à l'aide de l'API ou de l'interface de ligne de commande Secrets Manager.

Si vous avez des configurations existantes sur des moteurs de secrets dans votre instance, vous pouvez également récupérer les informations de manière programmatique afin de les recréer dans une nouvelle instance. Pour plus d'informations, voir Obtenir la configuration d'un type de secret API.

Ajoutez vos secrets téléchargés à l'instance nouvellement créée.

La création d'une sauvegarde automatique de vos secrets est possible en automatisant le flux manuel, ce qui peut se faire de différentes manières. Examinez les exemples suivants pour voir si l'un d'entre eux pourrait vous convenir.

Fonctionnalité de synchronisation en direct fournie par le client

Il est possible pour le client de créer un script ou un programme pour télécharger des secrets depuis votre instance de service principale en utilisant l'API Secrets Manager ou et de remplir l'instance de service de récupération avec les données. Le script peut tirer parti d' IBM Cloud Consigne les événements d'audit de l'instance principale pour maintenir la synchronisation de l'instance de récupération avec Code Engine. Des sauvegardes gérées par le client doivent être conservées pour restaurer la situation après le sinistre.

Créez un script qui télécharge périodiquement vos secrets et les importe dans votre instance de sauvegarde.

Créez une destination et un abonnement dans Event Notifications qui pointe vers une action IBM Cloud Code Engine. Configurez l'action pour qu'elle écoute les événements du cycle de vie tels que secret_created et secret_rotated. Ensuite, lorsque l'action reçoit l'événement, l'action télécharge le secret à partir d'une instance et l'ajoute à l'instance de sauvegarde.

Secrets Manager prend en charge les notifications pour les différents types de secrets qu'il fournit. Pour plus d'informations sur les différents types d'événement de cycle de vie disponibles, voir Activation des notifications d'événements.

Planification de la reprise après incident

Les étapes de la reprise après sinistre doivent être pratiquées régulièrement. Lors de l'élaboration de votre plan, envisagez les scénarios d'échec et les résolutions suivants.

Scénarios de DR pour Secrets Manager
Echec	Résolution
Défaillance du matériel (point unique)	IBM fournit une instance qui résiste à un seul point de défaillance matérielle au sein d'une zone - aucune configuration n'est requise.
défaillance de zone	IBM fournit une instance qui résiste à la défaillance d'une zone - aucune configuration n'est requise.
Altération de données	Utiliser la rotation pour restaurer la version secrète précédente dans une instance de service disponible.
Altération de données	Restaurer une version non corrompue à un moment donné à partir de la source externe de vérité ou de sauvegarde et de restauration.
Défaillance régionale	Basculer les charges de travail critiques pour utiliser la version restaurée dans une région de récupération. Restaurer l'instance à l'aide d'une source externe de vérité, d'une sauvegarde et d'une restauration ou d'une synchronisation en direct.

Vos responsabilités en matière d'HA et de DR

La liste de contrôle suivante, associée à chaque caractéristique, peut vous aider à créer et à mettre en pratique votre plan.

Rotation
- Créez une instance de ressources de test et entraînez-vous à la rotation des versions de secrets et à la restauration d'une version de secret.
Source externe de vérité
- Vérifiez que la source de vérité se trouve dans un référentiel disponible à l'emplacement de restauration.
- Vérifiez que la source de vérité ne dépend pas de la région sinistrée afin d'éviter toute dépendance à l'égard d'une région défaillante.
Sauvegarde et restauration
- Vérifiez que la sauvegarde se trouve dans un référentiel disponible à l'emplacement de restauration.
- Vérifiez que le script écrit par le client pour restaurer les données est disponible dans la région de restauration.
- Vérifiez que le script et la sauvegarde ne dépendent pas de la région sinistrée afin d'éviter de dépendre d'une région défaillante. Considérons un seau régional croisé Object Storage
Synchronisation en direct
- Vérifier que l'instance de service de restauration est actuellement disponible dans la région de restauration
Pour la source externe de la vérité et la synchronisation en direct :
- Vérifier que les charges de travail de récupération dans la région de récupération sont intégrées à l'instance de service de récupération
- Vérifiez que les secrets spécifiques à la région sont disponibles dans l'instance du service de récupération.

Pour en savoir plus sur la répartition des responsabilités entre le client et IBM Cloud pour l'utilisation de Secrets Manager, voir Comprendre vos responsabilités lors de l'utilisation de Secrets Manager.

Les étapes de la reprise après sinistre doivent être pratiquées régulièrement. Lors de l'élaboration de votre plan, envisagez les scénarios d'échec suivants et leur résolution.

Récupération des clients après une perte de BYOK

Si votre instance de service a été provisionnée en utilisant la clé racine de IBM® Key Protect for IBM Cloud® ou Hyper Protect Crypto Services et que vous avez accidentellement supprimé la clé racine, ouvrez un dossier de support pour le service et incluez les informations suivantes :

Le CRN de votre instance de service
Le CRN de votre instance Key Protect ou HPCS de secours
Le nouvel identifiant de la clé racine Key Protect ou HPCS
Le CRN et l'ID de la clé de l'instance Key Protect ou HPCS d'origine, s'ils sont disponibles

Voir Récupération d'une perte accidentelle de clé pour autorisation dans les documents Key Protect et HPCS.

Objectif de temps de récupération (RTO) et objectif de point de récupération (RPO)

Caractéristiques RTO/RPO pour Secrets Manager
Fonction	RTO et RPO
Rétablir la version secrète précédente	RTO = minutes, la pratique et éventuellement l'écriture de scripts amélioreront les délais de RTO, RPO = 0.
Source externe de vérité - empreinte zéro	RTO = quelques minutes. Temps nécessaire à l'approvisionnement et à l'introduction des données. Il faut également tenir compte du temps nécessaire pour adapter les charges de travail récupérées au nouveau point de terminaison de l'instance de service. RPO = 0, la source de vérité est modifiée avant d'apporter des changements à la production.
Source externe de vérité - sauvegarde entièrement opérationnelle	RTO = quelques secondes, RPO = 0. Améliorer la description de l'empreinte zéro afin de conserver une instance de service active dans la région de reprise.
Sauvegarde et restauration	RTO = quelques minutes. Temps nécessaire à l'approvisionnement et à l'introduction des données. Il faut également tenir compte du temps nécessaire pour adapter les charges de travail récupérées au nouveau point de terminaison de l'instance de service. RPO = heure de la dernière sauvegarde.
Synchronisation en direct	RTO = minutes, RPO = minutes s'il s'agit d'un événement ou la période, par exemple quotidienne, s'il s'agit de sauvegardes périodiques.

Lors de la création d'une nouvelle instance de service, le RTO de la charge de travail utilisant Secrets Manager inclura le temps nécessaire pour ajuster les charges de travail récupérées au nouveau point d'extrémité de l'instance de service.

Gestion des modifications

La gestion des modifications comprend des tâches telles que les mises à niveau, les changements de configuration et la suppression.
Il est recommandé d'accorder aux utilisateurs et aux processus les rôles et les actions IAM avec le moins de privilèges possible pour leur travail. Par exemple, limiter la possibilité de supprimer des ressources de production.

Comment IBM® assure la reprise après sinistre

en cas de sinistre, IBM® prend des mesures de récupération spécifiques.

Comment IBM® récupère les pannes de zone

En cas de défaillance d'une zone, IBM Cloud résoudra la panne de la zone et, lorsque la zone sera à nouveau en ligne, l'équilibreur de charge global recommencera à envoyer des demandes d'API au nœud d'instance restauré, sans qu'aucune action du client ne soit nécessaire.

Comment IBM® se remet des échecs régionaux

Lorsqu'une région est restaurée après une panne, IBM tente de restaurer l'instance de service à partir de l'état régional, ce qui n'entraîne aucune perte de données et permet de restaurer l'instance de service avec les mêmes chaînes de connexion.

RTO = quelques minutes
RPO = 0 minute

Si l'état régional est corrompu, le service sera restauré à l'état de la dernière sauvegarde interne. Toutes les données associées au service sont sauvegardées une fois par jour par le service dans un espace de Cloud Object Storage interrégional géré par le service. Il y a un potentiel de perte de données de 24 heures. Ces sauvegardes ne sont pas disponibles pour la reprise après sinistre gérée par le client. Lorsqu'un service est récupéré à partir de sauvegardes, l'identifiant de l'instance est également restauré, de sorte que les clients utilisant le point d'accès n'ont pas besoin d'être mis à jour avec de nouvelles chaînes de connexion.

RTO = 2 heures
RPO = 24 heures maximum

Dans le cas où IBM ne peut pas restaurer l'instance de service, le client doit restaurer comme décrit dans la section sur la reprise après sinistre.

Comment IBM® maintient les services

Toutes les mises à niveau suivent les meilleures pratiques du service IBM® et disposent d'un plan de reprise et d'un processus de retour en arrière. Des mises à jour régulières pour les nouvelles fonctionnalités et la maintenance sont effectuées dans le cadre des opérations normales. Cette maintenance peut occasionnellement provoquer de courts intervalles d'interruption qui sont gérés par la logique de relance de la disponibilité du client. Les changements sont introduits de manière séquentielle, région par région et zone par zone à l'intérieur d'une région. Les mises à jour sont annulées au premier signe de défaut.

Les modifications complexes sont activées et désactivées à l'aide d'indicateurs de caractéristiques afin de contrôler l'exposition.

Les changements qui ont un impact sur les charges de travail des clients sont détaillés dans les notifications. Pour plus d'informations, voir les notifications de suivi et l'état de la maintenance planifiée, les annonces et les notes de version qui ont un impact sur ce service.