Comprendre votre responsabilité dans la résilience des données d'iManage Cloud

Senior Product Marketing Manager

iManage pour gérer leurs connaissances institutionnelles, leurs affaires en cours et les données confidentielles de leurs clients. Historiquement, ce modèle de déploiement a vécu dans les locaux, où les entreprises déployaient l'infrastructure, sécurisaient l'environnement, contrôlaient le stockage et décidaient exactement de la manière dont les données étaient sauvegardées et récupérées. Elles étaient propriétaires à la fois du déploiement et de la protection.

Mais comme le dirait notre sympathique héros de quartier (peut-être dans un univers parallèle) : La grande commodité s'accompagne d'une grande responsabilité.

iManage Cloud fonctionne selon un modèle de responsabilité partagée, où iManage protège la plateforme et les clients restent responsables de la protection de leurs données. Dans cet article, nous déterminons où s'arrête la responsabilité d'iManage et où commence la vôtre, en allant au-delà du langage marketing et en nous penchant sur l'architecture, la conception de la reprise et les scénarios de risque du monde réel.

Qu'est-ce que le modèle de responsabilité partagée ?

Le modèle de responsabilité partagée est à la base des plateformes SaaS modernes.

Dans chaque environnement SaaS moderne, la responsabilité est partagée entre le fournisseur et le client. Le fournisseur est responsable de la disponibilité, de l'infrastructure et de la sécurité de la plateforme. Cela comprend le calcul, la durabilité du stockage, l'évolutivité, le cryptage et la reprise après sinistre au niveau du service.

Le client est responsable de l'utilisation de la plateforme. Cela comprend les contrôles d'accès, les politiques de conservation, la gestion du cycle de vie et, en fin de compte, la possibilité de récupérer les données de l'entreprise.

Le nuage supprime le fardeau de la gestion de l'infrastructure, mais il ne supprime pas la propriété des résultats. Cette distinction est particulièrement importante dans les environnements juridiques où l'intégrité des documents, l'auditabilité et la récupérabilité sont essentielles.

Récupération du système vs récupération des documents

Avant de nous plonger dans l'architecture et les capacités, nous devons clarifier une différence fondamentale entre la récupération du système et la récupération des documents. Bien qu'elles soient toutes deux essentielles pour les clients, elles résolvent des problèmes différents et appartiennent à des propriétaires différents.

Recouvrement du système

Le recouvrement du système consiste à restaurer la plate-forme elle-même. Elle comprend :

  • Reconstruction des services dans une région redondante secondaire
  • Restauration des bases de données et des index
  • Récupération de l'infrastructure de stockage
  • L'utilisation des mécanismes de réplication et de suppression douce du fournisseur de cloud

La récupération du système est conçue pour les événements catastrophiques et fait partie des engagements de niveau de service d'iManage. Mais elle ne garantit pas qu'un espace de travail supprimé accidentellement dans la bibliothèque d'un client puisse être restauré à la demande.

Recouvrement de documents

Le recouvrement de documents concerne le recouvrement au niveau du client ou du locataire. Elle comprend :

  • Restauration des documents supprimés accidentellement ou par malveillance
  • Restauration des versions écrasées
  • Récupération des attaques de ransomware
  • Restauration du contenu de la Corbeille
  • Rétablissement à partir d'une mauvaise configuration interne
  • Rétablissement à partir d'une compromission du locataire ou d'une suppression malveillante

La récupération des documents est l'endroit où la plupart des risques quotidiens de l'entreprise existent réellement et c'est là que la responsabilité partagée devient visible.

iManage Cloud dispose de deux fonctionnalités natives principales qui aident à la récupération des documents :

  • Poubelle
  • Journal

Nous explorerons ces options de récupération en détail plus loin dans l'article. Pour l'instant, ce qu'il faut comprendre, c'est qu'iManage est propriétaire de la récupération du système et que les clients sont propriétaires de la récupération des documents.

Cette limite définit une responsabilité partagée.

L'architecture cloud d'iManage : Construit pour la disponibilité

iManage Cloud fonctionne sur Microsoft Azure et exploite les capacités de disponibilité et de redondance d'Azure.

Dans chaque région prise en charge par iManage, le service iManage Cloud est déployé sur trois zones de disponibilité Azure. Ces zones sont des centres de données physiquement séparés au sein d'une région. Si une zone tombe en panne, le trafic continue automatiquement à circuler à travers les zones restantes, sans impact pour les utilisateurs.

Azure fournit également un stockage redondant par zone géographique (GZRS), dans lequel les données écrites dans la région principale (disons l'est des États-Unis) sont répliquées de manière asynchrone dans une région secondaire jumelée située à des centaines de kilomètres de là. Ainsi, si une région entière devient indisponible, les services peuvent être redéployés dans la région jumelée ou secondaire et l'accès peut être rétabli.

Cette architecture offre une grande durabilité, une capacité de basculement régional et une reprise après sinistre au niveau de l'infrastructure.

Cette architecture protège contre :

  • Data center failure
  • Availability zone outages
  • Catastrophes régionales
  • Corruption de l'infrastructure

C'est robuste, robuste, résiliente et de qualité professionnelle. Mais la disponibilité n'est pas la même chose que la sauvegarde au niveau du locataire.

Inside iManage Cloud's Recovery Safety Net

De nombreux clients d'iManage peuvent également être familiarisés avec une période de rétention de 90 jours, au cours de laquelle les données modifiées ou supprimées peuvent être récupérées avec l'aide de l'assistance d'iManage. Cette fonction est différente de celle de la Corbeille ou du Journal, car elle n'est pas accessible aux clients et ne peut être récupérée que par le service d'assistance d'iManage. Les clients ne peuvent pas naviguer directement dans cette couche de récupération, sélectionner des points de restauration, lancer un retour en arrière ou définir la durée de conservation.

Au niveau de la couche de stockage sous-jacente, Azure Blob Storage maintient un état de suppression douce pour les objets modifiés ou supprimés pendant 90 jours maximum, après quoi ces données sont purgées pour toujours. Cela permet à iManage de récupérer les objets de données modifiés ou supprimés pendant 90 jours, mais cette capacité est explicitement destinée à des fins de récupération du système en cas de panne, de corruption ou de désastre à grande échelle.

Il n'existe pas pour fournir :

  • Récupération de documents opérationnels
  • Long-term retention
  • Granular document-niveau du document
  • Contrôles de rétention de la conformité
  • Archives de sauvegarde

Il ne s'agit pas d'une solution de sauvegarde. Il s'agit d'un filet de sécurité au niveau du système.

Capacités de récupération natives et leurs limites

Comme nous l'avons évoqué précédemment, iManage Cloud offre quelques capacités de récupération natives. Voyons en quoi elles consistent.

Corbeille / Corbeille

Lorsqu'un utilisateur supprime un document, celui-ci est déplacé vers la Corbeille pour une période limitée avant d'être purgé définitivement.

Caractéristiques clés :

  • Les documents restent indéfiniment dans la Corbeille à moins d'être explicitement purgés.
  • Les administrateurs peuvent restaurer des éléments.
  • Les éléments conservent les métadonnées et les numéros de version d'origine.

Limitations :

  • Une fois purgées, les données disparaissent définitivement.
  • La poubelle s'applique uniquement aux documents.
  • La durée de conservation est souvent faible afin d'éviter les coûts inutiles liés à l'espace de stockage et les dépassements.
  • Il ne protège pas contre les scénarios de suppression massive en dehors des fenêtres de conservation.

Journal

A chaque fois qu'un document est modifié, iManage crée une copie secondaire de l'état précédent dans le journal. C'est une excellente façon de se protéger contre les écrasements accidentels. Les clients peuvent simplement revenir à un rendu précédent à partir du Journal.

Limitations :

  • Les journaux peuvent être purgés et ne sont généralement conservés que pendant une période limitée.
  • Une fois purgés, il n'est pas possible de les récupérer.
  • S'applique uniquement aux objets documents.

Exportation / Import API

iManage fournit des API qui permettent des opérations d'exportation et de restauration en vrac qui peuvent être utilisées pour extraire des données périodiquement et réintégrer ces données dans la bibliothèque.

Limitations :

  • Limited granularity.
  • Peut ne pas préserver l'intégralité de la structure ou des métadonnées dans tous les scénarios.
  • La création manuelle de scripts est complexe sur le plan opérationnel.
  • Risque élevé de corruption et d'écrasement des données.

Ces fonctions de récupération natives sont utiles pour la récupération ciblée de documents, mais elles ne remplacent pas la sauvegarde et la récupération de niveau professionnel.

Aujourd'hui, nous allons comprendre un peu mieux pourquoi vous avez besoin de fonctionnalités de sauvegarde et de récupération que les fonctions natives ne pourront pas couvrir.

Les façons dont les données peuvent être perdues dans iManage Cloud

Il y a plusieurs façons dont les cabinets d'avocats peuvent perdre leurs données iManage Cloud et certains documents d'iManage eux-mêmes décrivent de multiples scénarios dans lesquels la perte de données peut se produire.

Ils comprennent :

  • Suppression accidentelle ou malveillante par un utilisateur
  • Écrasion accidentelle d'un document
  • Purge de la corbeille
  • Catastrophe régionale
  • Cyberattaques comme les ransomwares
  • Automatisations ou défaillances de tiers
  • Corruption de l'infrastructure
  • Mauvaise configuration administrative
  • Suppression basée sur une politique

    Suppression basée sur une politique

  • Expiration de la rétention
  • Suppression à grande échelle ou événements de nettoyage
  • .de nettoyage
  • Utilisation incorrecte des points d'extrémité de l'API de Shred

Certaines de ces situations sont opérationnelles, d'autres sont administratives et d'autres encore sont liées à un sinistre, Certains sont opérationnels, d'autres administratifs, d'autres encore liés à des catastrophes, mais aucun d'entre eux n'est hypothétique. Dans nos conversations avec des cabinets d'avocats, nous avons constaté des incidents allant de la perte d'un seul document à la suppression accidentelle d'espaces de travail entiers.

Votre responsabilité dans la planification de la continuité d'activité

La continuité d'activité à l'ère du cloud et du SaaS doit tenir compte d'événements réalistes au niveau du locataire. Cela signifie que vous avez besoin de plus que de simples flux de travail de restauration à partir de la corbeille. Qu'il s'agisse d'une mauvaise configuration ou d'une interruption de service, vous devez vous assurer que votre entreprise fonctionne et que vos engagements sont respectés.

La planification de la continuité des activités doit tenir compte de ce qui suit :

  • Les utilisateurs peuvent-ils accéder rapidement aux documents sur lesquels ils travaillent actuellement ?
  • Le processus est-il conforme aux exigences de sécurité des cabinets d'avocats ?
  • Pouvons-nous restaurer à une date et une heure spécifiques ?
  • Est-il facile d'accéder aux données récupérées ?
  • Pouvons-nous obtenir un accès immédiat aux données les plus critiques ?
  • Pouvons-nous restaurer dans une autre région si nécessaire ?

Ce ne sont là que quelques-unes des questions que vous devriez vous poser sur votre processus de continuité des activités et si ces réponses reposent uniquement sur des fonctionnalités SaaS natives, il y a de sérieuses lacunes.

HYCU : La protection indépendante des données pour iManage Cloud

La sauvegarde indépendante n'est pas un défi pour l'architecture résiliente d'iManage, c'est une reconnaissance du modèle de responsabilité partagée.

De même que les clients de Microsoft 365 déploient une sauvegarde pour Exchange et SharePoint et que les clients de Salesforce déploient une sauvegarde pour leurs données CRM, les clients d'iManage Cloud doivent envisager une protection indépendante pour leurs référentiels documentaires.

iManage et HYCU se sont associés en 2024 pour offrir aux clients une solution officielle de protection des données et de continuité des activités pour les clients iManage Cloud.

Cette couche indépendante fournit :

  • Granular, à la demande
  • Accès alternatif immédiat aux données critiques
  • Stockage et conservation contrôlés par le client
  • Contrôle des données et de la résidence
  • Couverture complète des données iManage Cloud
  • Gestion fiable et automatisée des sauvegardes
  • Récupération des données à l'épreuve des ransomwares

    Immutable, ransomware

  • Cryptage et sécurité des données de niveau entreprise

Le plus important est que le contrôle de la récupération passe de la discrétion du fournisseur à celle du client.

Réflexions finales

iManage Cloud offre une plateforme hautement résiliente, conçue pour la disponibilité, la redondance et la continuité opérationnelle. Mais la résilience de la plateforme n'est pas la même chose que la récupération des données contrôlée par le client.

C'est le cœur du modèle de responsabilité partagée, et la compréhension de votre rôle dans ce modèle est essentielle à la continuité des opérations de votre entreprise.

iManage protège et exploite la plateforme. Les clients restent responsables de la définition de la manière dont leurs données sont protégées, conservées, récupérées et mises à disposition en cas d'interruption.