Créer une configuration de routage résiliente à une catastrophe régionale

IBM Cloud Activity Tracker Event Routing est un service régional à service partagé et à haute disponibilité. Cependant, vous pouvez également configurer une configuration de routage vers une instance de sauvegarde pour atténuer la perte de données en cas de catastrophe régionale.

Pour plus d'informations sur la haute disponibilité et la reprise après sinistre offertes par le service IBM Cloud Activity Tracker Event Routing, consultez la section Haute disponibilité et reprise après sinistre.

Comprendre les cibles et les itinéraires

Avant de créer une région de sauvegarde, vous devez comprendre les cibles et les itinéraires.

Les cibles sont créées au sein d’une région mais sont des ressources mondiales. Pour plus d'informations, voir Gestion des cibles.
Les routes sont globales au niveau d'un compte et sont évaluées dans toutes les régions où IBM Cloud Activity Tracker Event Routing est déployé. Pour plus d'informations, voir Gestion des itinéraires.
La configuration des paramètres du compte définit des informations telles que les cibles par défaut où les événements sont collectés dans le compte, les types de points de terminaison autorisés à gérer la configuration, les emplacements des métadonnées de configuration et les emplacements autorisés pour le stockage des données dans le compte. Pour plus d'informations, voir Paramètres de configuration de compte.

Si la région de métadonnées principale et la région de métadonnées de sauvegarde configurées dans les paramètres du compte ne sont pas disponibles, aucun événement ne sera acheminé.

Routage vers une cible de sauvegarde dans une région différente

Vous pouvez configurer une cible de sauvegarde pour les données acheminées par votre instance IBM Cloud Activity Tracker Event Routing vers une cible qui s'exécute dans une région différente. Vous pouvez ensuite acheminer toutes les données vers vos cibles principales et de sauvegarde. La configuration d’une cible de sauvegarde vous donne des cibles synchronisées. Vous pouvez passer à la sauvegarde sans temps d’arrêt et avec une perte de données minimale en cas de catastrophe régionale.

La création d’une deuxième cible à des fins de sauvegarde entraîne des frais supplémentaires pour l’exécution de l’instance cible de sauvegarde.

. Exemple de configuration de routage permettant de sauvegarder tous les événements d'audit vers une deuxième destination située dans une autre région

Dans cet exemple, la source des événements d'audit se trouve dans la région de Toronto (ca-tor). Les événements d'audit du service IBM Cloud sont envoyés par IBM Cloud Activity Tracker Event Routing à une instance IBM Cloud Logs à Dallas (us-south). Une configuration régionale de routage résistant aux catastrophes est créée pour acheminer les événements d'audit vers une instance IBM Cloud Logs (cible 2) dans la région de Washington (us-east). Tous les événements sont envoyés à la fois à la cible dans la région de Dallas ( us-south ) et à la région de Washington ( us-east ).

Target 2 fournit à l'utilisateur des événements d'audit historiques dans la région de Washington ( us-east ). Si la région de Dallas ( us-south ) n'est pas disponible, les utilisateurs ont des événements d'activité de Toronto ( ca-tor ) disponibles dans la région de Washington ( us-east ).

Pour les utilisateurs sans configuration de routage résiliente aux catastrophes, aucun événement d’audit historique n’est disponible dans une deuxième région.

Pour plus d'informations sur la configuration des itinéraires, voir Gestion des itinéraires.

De plus, vous devez définir une région de métadonnées de sauvegarde pour votre sauvegarde de métadonnées. La région des métadonnées de sauvegarde doit être une région différente de votre région de métadonnées principale.

Considérations de sécurité dans un environnement à deux cibles

Lorsque vous configurez un environnement avec une cible de sauvegarde, vous devez prendre en compte les éléments suivants :

Les restrictions basées sur le contexte donnent aux propriétaires et administrateurs de compte la possibilité de définir et d'appliquer des restrictions d'accès aux ressources IBM Cloud en fonction des critères d'une règle. Les critères incluent l’emplacement réseau des demandes d’accès, le type de point de terminaison à partir duquel la demande est envoyée et parfois l’API à laquelle la demande tente d’accéder. Ces restrictions s'associent aux politiques IAM traditionnelles, qui reposent sur l'identité, afin d'offrir une couche de protection supplémentaire. Pour plus d'informations, consultez la section Que sont les restrictions basées sur le contexte?

Si des règles basées sur le contexte sont configurées dans le compte, assurez-vous que les règles sont définies pour les emplacements principal et de sauvegarde.

Vous pouvez configurer des règles de restriction basées sur le contexte pour les cibles IBM Cloud Object Storage (COS), IBM Cloud Logs et IBM® Event Streams for IBM Cloud®.

Pour obtenir la liste complète des services prenant en charge les restrictions basées sur le contexte, consultez Services intégrés aux restrictions basées sur le contexte.
IBM Cloud® Identity and Access Management (IAM) vous permet de contrôler en toute sécurité l'accès à toutes les ressources cloud de manière cohérente dans IBM Cloud. Les autorisations et autorisations IAM doivent permettre au service d’acheminer les événements vers les cibles principales et de sauvegarde.

Gestion automatique des catastrophes

Vous pouvez choisir d'autoriser IBM Cloud Activity Tracker Event Routing à gérer une catastrophe régionale comme décrit dans Haute disponibilité et reprise après sinistre.

Dans ce cas, aucun frais supplémentaire n'est facturé pour une deuxième instance cible. Cependant, vous courez également les risques suivants :

Aucun accès n’est disponible aux données historiques de la région qui a subi la catastrophe.
Des données sont perdues lorsque vous configurez une nouvelle instance alors que l'instance existante n'est pas disponible.
Tous les événements acheminés vers une cible IBM Cloud Logs peuvent être archivés. Pour plus d'informations, consultez Comprendre vos responsabilités lorsque vous utilisez IBM Cloud Logs.