Description de la haute disponibilité et de la reprise après incident pour App ID

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. Pour les services, la disponibilité est définie dans l'accord de niveau de service. La disponibilité comprend à la fois les événements planifiés et non planifiés, tels que la maintenance, les pannes et les catastrophes. (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 haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel.

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

Architecture à haute disponibilité

Une instance de service App ID est répartie sur plusieurs zones dans une région multizone sans point de défaillance unique. En cas de défaillance d'un nœud d'instance ou d'une zone de disponibilité, le service continue de fonctionner, les demandes d'API étant acheminées par un équilibreur de charge mondial vers les nœuds d'instance hautement disponibles restants. 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.

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 récupération doit être configurée avec les mêmes données que l'instance de service source. Veillez à créer des instances de sauvegarde dans une région de reprise avant un éventuel sinistre et à les maintenir régulièrement pour vous assurer qu'elles sont synchronisées avec l'instance source.

Fonctionnalités de reprise après sinistre

Planifier le rétablissement dans une région de rétablissement. L'instance de récupération doit s'aligner sur les approches de reprise après sinistre de la charge de travail dans 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 politiques de mot de passe, les utilisateurs et les configurations de SAML.

Sauvegarde et restauration de vos instances

La sauvegarde et la restauration de votre instance App ID pour garantir la disponibilité interrégionale nécessitent quelques étapes de base. Vous devez :

  1. Définissez les règles de configuration du stockage de la sauvegarde de votre instance App ID. Cette configuration inclut la planification de la manière dont les données, telles que les profils utilisateur et les utilisateurs Cloud Directory, doivent être stockées dans la sauvegarde de votre instance.

    Créez le système de secours avant qu'un incident d'indisponibilité ne se produise dans votre emplacement principal. Pour maintenir une protection continue, comme recommandé, automatisez le processus de génération de la sauvegarde et de son exécution périodique.

  2. Créer et configurer une instance de App ID dans une autre région.

  3. Configurez un processus pour stocker la sauvegarde et la restaurer dans l'instance App ID qui se trouve à l'emplacement secondaire.

Sauvegarde de votre instance à l'aide de l'API

Pour sauvegarder votre instance App ID en utilisant l'API de gestion, écrivez un script qui envoie une demande à l'API App ID pour générer des fichiers contenant les informations de configuration de votre instance App ID. Stockez ces fichiers dans un emplacement sécurisé car ils sont requis pour restaurer l'instance App ID dans une région secondaire.

Définissez les paramètres de votre sauvegarde en fonction de la configuration dans votre instance App ID, par exemple ce qui est nécessaire pour votre cas d'utilisation. Par exemple, dans le scénario suivant, vous configurez votre instance App ID avec les paramètres suivants:

  • règles sur les mots de passe, telles que le verrouillage du profil utilisateur pendant 60 minutes si l'utilisateur entre un mot de passe incorrect trois fois dans une ligne
  • Configuration SAML

Pour extraire ces paramètres utilisateur avec l'API de gestion, envoyez:

curl -X 'GET' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/cloud_directory/advanced_password_management' \
  --header 'accept: application/json' \
  --header 'Authorization: Bearer <IAM_Token>'

curl -X 'GET' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/idps/saml' \
  --header 'accept: application/json' \
  --header 'Authorization: Bearer <IAM_Token>'

En plus de conserver une sauvegarde des paramètres de configuration de votre instance App ID, vous devez générer une sauvegarde de vos utilisateurs et de vos profils utilisateur Cloud Directory. Pour effectuer cette tâche, il est recommandé d'utiliser l'API de gestion.

  • Pour exporter des utilisateurs Cloud Directory, utilisez le noeud final d'API cloud_directory/export/all. Pour télécharger l'exportation, utilisez l'API cloud_directory/export/download. Pour plus de détails sur l'exportation des utilisateurs Cloud Directory à l'aide de l'API de gestion, consultez la documentation Exportation de tous les utilisateurs.
  • Pour exporter des profils d'utilisateur, utilisez le noeud final users / export.
  • Ces deux API d'exportation génèrent deux fichiers de sauvegarde que vous devez stocker de manière sécurisée pour les utiliser ultérieurement dans le processus de restauration.

Sauvegarde de votre instance à l'aide de Terraform et de l'API

Pour sauvegarder vos paramètres App ID avec Terraform, vous pouvez écrire des scripts Terraform afin de générer des fichiers contenant les informations de configuration pour votre instance App ID. Stockez ces fichiers dans un emplacement sécurisé car vous devez les utiliser pour restaurer l'instance App ID dans une région secondaire.

Définissez les paramètres de votre sauvegarde en fonction de la configuration dans votre instance App ID, par exemple ce qui est nécessaire pour votre cas d'utilisation. Par exemple, dans le scénario suivant, vous configurez votre instance App ID avec les paramètres suivants:

  • règles sur les mots de passe, telles que le verrouillage du profil utilisateur pendant 60 minutes si l'utilisateur entre un mot de passe incorrect trois fois dans une ligne
  • Configuration SAML

Avec le script terraform suivant, vous pouvez extraire votre configuration en cours et la stocker dans des fichiers.

terraform {
  required_providers {
    ibm = {
      source = "IBM-Cloud/ibm"
      version = ">= 1.12.0"
    }
  }
}

variable "tenant_id" {
  type = string
  default = "<<YOUR TENANT ID>>"
}

variable "region" {
  type = string
  default = "<<THE REGION YOUR TENANT IS LOCATED>>"
}

provider "ibm" {
  region = var.region
  ibmcloud_api_key = "<<API KEY TO ACCESS APP ID INSTANCE>>"
}

##### ---------- Getting the configuration from your App ID instance ---------- #####

# Get Settigs about Password's rules
data "ibm_appid_apm" "app" {
    tenant_id = var.tenant_id   
}

# Get SAML config
data "ibm_appid_idp_saml" "saml" {
    tenant_id = var.tenant_id
}

##### ---------- Saving the App ID configuration to files ---------- #####

resource "local_file" "app_config" {
    content  = jsonencode(data.ibm_appid_apm.app)
    filename = "${path.module}/backup_configurations/app_config.json"
}

resource "local_file" "saml_config" {
    content  = jsonencode(data.ibm_appid_idp_saml.saml)
    filename = "${path.module}/backup_configurations/saml_config.json"
}

Dans le scénario précédent, les fichiers qui contiennent les sauvegardes sont stockés localement. Mais vous pouvez les stocker dans tout autre endroit que vous préférez, comme par exemple IBM Cloud Object Storage.

Pour générer une sauvegarde des utilisateurs et des profils utilisateur Cloud Directory, il est recommandé d'utiliser l'API de gestion.

  • Pour exporter des utilisateurs Cloud Directory, utilisez le noeud final d'API cloud_directory/export/all. Pour télécharger l'exportation, utilisez l'API cloud_directory/export/download. Pour plus de détails sur l'exportation des utilisateurs Cloud Directory avec l'API de gestion, voir Exportation de tous les utilisateurs.
  • Pour exporter des profils d'utilisateur, utilisez le noeud final users / export.
  • Ces deux API d'exportation génèrent deux fichiers de sauvegarde que vous devez stocker pour les utiliser ultérieurement dans le processus de restauration.

Restauration de votre instance App ID à l'aide de l'API

Tout d'abord, vous devez mettre à disposition manuellement une nouvelle instance de App ID dans la région secondaire. Vous pouvez ensuite restaurer vos paramètres App ID en lisant les fichiers de sauvegarde et en utilisant la demande d'API de gestion pour configurer l'instance App ID dans la région secondaire.

En continuant avec le scénario qui est inclus dans la section de sauvegarde, vous pouvez restaurer la configuration de SAML et les politiques de mot de passe en envoyant ce qui suit à l'API de gestion :

curl -X 'PUT' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/cloud_directory/advanced_password_management' \
  --header 'accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <IAM_Token>' \
  -d '<Data_from_your_backup_file>'
  • une requête PUT au point de terminaison /management/v4/<tenantId>/config/idps/saml pour mettre à jour la configuration de SAML IdP. Transmettre les données stockées dans la sauvegarde dans le corps de la requête HTTP.
curl -X 'PUT' \
  'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/idps/saml' \
  --header 'accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <IAM_Token>' \
  -d '<Data_from_your_backup_file>'

Pour restaurer les sauvegardes de vos utilisateurs Cloud Directory et de leurs profils, le cas échéant, il est recommandé d'utiliser l'API de gestion:

Restauration de votre instance App ID à l'aide de Terraform et de l'API

Lorsque vous utilisez une combinaison de Terraform et de l'API de gestion pour restaurer votre instance App ID, la première étape consiste à écrire votre script Terraform pour mettre à disposition une nouvelle instance de App ID dans la région secondaire. Vous pouvez ensuite restaurer vos paramètres App ID en lisant les fichiers de sauvegarde et en utilisant les commandes terraform pour configurer l'instance App ID dans la région secondaire.

En continuant avec le scénario inclus dans la section sauvegarde, vous pouvez restaurer la configuration de SAML et les politiques de mot de passe avec le script suivant :

terraform {
  required_providers {
    ibm = {
      source = "IBM-Cloud/ibm"
      version = ">= 1.12.0"
    }
  }
}

variable "backup_region" {
  type = string
  default = "<<REGION WHERE TO CREATE THE NEW APPID INSTANCE>>"
}

variable "backup_appid_instance_name" {
  type = string
  default = "<<THE NAME OF THE NEW APPID INSTANCE>>"
}

provider "ibm" {
  region = var.backup_region
  ibmcloud_api_key = "<<API KEY TO ACCESS APP ID INSTANCE>>"
}

##### ---------- Creating an AppID instance in a secondary location ---------- #####

data "ibm_resource_group" "group" {
  name = "Default"
}

resource "ibm_resource_instance" "backup_appid_instance" {
  name              = var.backup_appid_instance_name
  service           = "appid"
  plan              = "graduated-tier"
  location          = var.backup_region
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["backup_instance", "backup_of_appid_from_primary_region"]
}

##### ---------- Getting the configuration from the local backups ---------- #####

locals {
	app_config = jsondecode(file("${path.module}/backup_configurations/app_config.json"))
	saml_config = jsondecode(file("${path.module}/backup_configurations/saml_config.json"))
}


##### ---------- Restoring the App ID configuration into the new App ID instance ---------- #####


# Setting SAML config in the new App ID Instance
resource "ibm_appid_idp_saml" "saml" {
  tenant_id = resource.ibm_resource_instance.backup_appid_instance.guid
  is_active = local.saml_config.is_active
  config {
    entity_id = local.saml_config.config[0].entity_id
    sign_in_url = local.saml_config.config[0].sign_in_url
    display_name = local.saml_config.config[0].display_name
    encrypt_response = local.saml_config.config[0].encrypt_response
    sign_request = local.saml_config.config[0].sign_request
    certificates = [local.saml_config.config[0].certificates[0]]
  }
}

# Setting password policies config in the new App ID Instance
resource "ibm_appid_apm" "apm" {
  tenant_id = resource.ibm_resource_instance.backup_appid_instance.guid
  enabled = local.app_config.enabled
  prevent_password_with_username = local.app_config.prevent_password_with_username

  password_reuse {
    enabled = local.app_config.password_reuse[0].enabled
    max_password_reuse = local.app_config.password_reuse[0].max_password_reuse
  }

  password_expiration {
    enabled = local.app_config.password_expiration[0].enabled
    days_to_expire = local.app_config.password_expiration[0].days_to_expire
  }

  lockout_policy {
    enabled = local.app_config.lockout_policy[0].enabled
    lockout_time_sec = local.app_config.lockout_policy[0].lockout_time_sec
    num_of_attempts = local.app_config.lockout_policy[0].num_of_attempts
  }

  min_password_change_interval {
    enabled = local.app_config.min_password_change_interval[0].enabled
    min_hours_to_change_password = local.app_config.min_password_change_interval[0].min_hours_to_change_password
  }
}

Pour restaurer les utilisateurs et les profils utilisateur Cloud Directory, il est recommandé d'utiliser l'API de gestion:

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

Les informations suivantes peuvent vous aider à créer et à mettre en pratique en permanence votre plan pour l'AH et le DR. 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 concerné et incluez les informations suivantes :

  • Le CRN de votre instance de service
  • Le CRN de votre instance de sauvegarde Key Protect ou HPCS
  • Le nouvel identifiant de la clé racine Key Protect ou HPCS
  • Le CRN et l'ID 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 docs Key Protect et les documents de la DGPS.

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'attribuer aux utilisateurs et aux processus les rôles et 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® aide à assurer la reprise après sinistre

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

Comment IBM® récupère les défaillances de zones

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 requêtes 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 tentera de restaurer l'instance de service à partir de l'état régional, ce qui n'entraînera aucune perte de données et l'instance de service sera restaurée avec les mêmes chaînes de connexion.

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 deux fois par jour par le service dans une base de données interrégionale Cloud Object Storage gérée 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 = 4 heures
  • RPO = 12 heures maximum

Dans le cas où IBM ne peut pas restaurer l'instance de service, le client doit procéder à la restauration 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 mis en œuvre 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.