Solutions de sauvegarde cloud

Dans cet article :

Solutions de sauvegarde cloud

Azure

AWS

Solutions de sauvegarde cloud

Google Drive et OneDrive

Les environnements Google Drive et OneDrive ne disposent pas de fonctionnalités natives leur permettant de restaurer leurs données après une attaque par ransomware ayant supprimé leurs versions précédentes. Il est donc nécessaire d'envisager certaines solutions afin de sauvegarder régulièrement leurs données et de les protéger.

Plusieurs solutions peuvent être envisagées pour atteindre cet objectif, chacune avec ses avantages et ses inconvénients.

Solution n°1 : Disque dur

Cette solution consiste à sauvegarder manuellement les fichiers de l'environnement Google Drive ou OneDrive sur un disque dur externe. Idéalement, une sauvegarde d'un environnement OneDrive ou Google Drive devrait être réalisée sur au moins deux disques durs externes afin d'éviter la perte de données en cas de défaillance d'un des disques. Bien que cette solution soit la plus simple à mettre en œuvre, elle est également la plus contraignante.

Solution n°2 : NAS

Un NAS (Network Attached Storage) est un serveur de stockage réseau physique. Cette solution consiste à installer une application de synchronisation sur le NAS — à savoir Google Drive Desktop pour un environnement Google Workspace et OneDrive pour un environnement O365 — afin de synchroniser régulièrement les disques partagés (Google Drive) et les sites SharePoint (OneDrive), et d'effectuer des sauvegardes sur les disques du NAS. Il est également possible d'utiliser certains types de RAID pour améliorer la sécurité ou la tolérance aux pannes des disques sur le NAS.

Solution n°3 : Espace de stockage AWS/Azure

Azure (Microsoft) et AWS (Amazon) proposent des espaces de stockage Cloud abordables pour stocker des sauvegardes. L'idée est de transférer régulièrement toutes les données des environnements Google Drive et OneDrive vers l'un de ces espaces de stockage, soit manuellement, soit automatiquement à l'aide d'un script et d'une machine abonnée à l'un de ces environnements. Plusieurs outils gratuits sont développés et fréquemment mis à jour à cet effet, notamment rclone et duplicity, conçus pour permettre ce type de transfert.

Solution n°4 : Solutions tierces

Certaines solutions tierces peuvent être envisagées si aucune des solutions précédentes n'est adaptée. Ces solutions rendent les sauvegardes très faciles d'utilisation, mais impliquent un coût financier important. Ce type de solution consiste à accorder à un service tiers l'accès à votre environnement Google Drive et OneDrive afin qu'il puisse récupérer automatiquement les données de manière régulière. Ces solutions offrent également des fonctionnalités de restauration des données. Parmi les exemples figurent Afi, Backupify, Spanning et SpinBackup.

Tableau récapitulatif

En analysant tous ces scénarios, il est possible de définir certains critères et de classer toutes ces solutions en conséquence, comme l'illustre le tableau suivant :

Azure

Sauvegardes immuables Azure

Les sauvegardes Azure peuvent être de deux types, Backup Vault ou Recovery Services, selon vos modèles de données :

Il existe 2 méthodes pour garantir l'immuabilité de ces sauvegardes :

1. Vérifier que la fonctionnalité Soft Delete est activée. Par défaut, Soft Delete est activé sur les coffres Recovery Services d'Azure. Cette fonctionnalité protège les sauvegardes contre les suppressions accidentelles ou malveillantes pendant une période de 14 jours sans coût supplémentaire. Si des sauvegardes sont supprimées et que Soft Delete n'est pas activé, ni vous ni Microsoft ne pouvez récupérer les données supprimées. Il est nécessaire de mettre en place la protection suivante afin d'éviter le scénario suivant :

   1. Compromission du locataire Azure et des coffres ;

   2. Désactivation de Soft Delete ;

   3. Suppression des sauvegardes ;

   4. Restauration ;

   5. Suppression définitive.

2. Utiliser l'autorisation multi-utilisateur (MUA) sur la fonctionnalité Soft Delete. La MUA pour Azure Backup utilise une nouvelle ressource appelée Resource Guard pour s'assurer que les opérations critiques, telles que la désactivation de Soft Delete, l'arrêt et la suppression des sauvegardes, ou la réduction de la rétention des stratégies de sauvegarde, sont effectuées uniquement avec l'autorisation appropriée. Pour comprendre le processus, il est nécessaire de connaître 2 rôles qui doivent être définis au sein de l'organisation Azure :

   1. Administrateur de sauvegarde : propriétaire du coffre Recovery Services ou Backup Vault qui effectue les opérations d'administration et de gestion sur ceux-ci ;

   2. Administrateur de la sécurité : propriétaire du Resource Guard, agissant en tant que gardien des opérations critiques sur le coffre. Par conséquent, l'administrateur de la sécurité contrôle les permissions dont l'administrateur de sauvegarde a besoin pour effectuer des opérations critiques sur le coffre.

Pour configurer la MUA, vous devez :

• Vérifier que Resource Guard et le Recovery Services Vault Azure sont dans la même région Azure ;

• Vérifier que l'administrateur de sauvegarde n'a pas de droits de contributeur sur Resource Guard. Vous pouvez avoir Resource Guard dans une autre souscription du même locataire ou dans un autre locataire ;

• Suivre la procédure officielle Azure.

Protéger vos opérations critiques Azure

La configuration de coffres immuables permet les protections suivantes :

• Recovery Services : protège les données contre la suppression ; empêche la modification ou la suppression de la stratégie de sauvegarde afin de réduire la durée de rétention des données.

• Backup Vaults : protège les données contre la suppression

1. Connectez-vous à votre portail Azure et recherchez Recovery Services Vaults, Backup Vaults, ou le coffre que vous souhaitez protéger :

   

1. Cliquez sur l'onglet Propriétés pour activer le coffre immutable et verrouiller le coffre pour la durée de la stratégie de sauvegarde

Remarque : cette étape est irréversible, utilisez-la avec prudence pour les données sensibles.

1. Répétez cette opération pour les autres coffres nécessaires à la continuité d'activité.

AWS

Solution dégradée (sans droits SCP)

Remarque : la première étape doit être répétée pour chaque bucket S3 contenant des données sensibles ou techniques pouvant être nécessaires en production.

1. Créer une stratégie de bucket S3 qui empêche la suppression des versions des objets du bucket S3.

   1. Dans votre console de gestion S3, cliquez sur le bucket souhaité, puis sur l'onglet Autorisations :

      

b. Sous la section Politique de bucket, cliquez sur Modifier.

c. Remplacez la politique de bucket existante (le cas échéant) par la politique JSON suivante :

{
    "Version" : "2012-10-17",
    "Statement" : [
        {
            "Sid" : "DenyVersionDeletion",
            "Effect" : "Deny",
            "Principal" : "*",
            "Action" : "s3:DeleteObject*",
            "Resource" : "arn:aws:s3:::my-bucket-stoik/*"
        }
    ]
}

Remarque : remplacez your-bucket-name par les noms ARN de votre bucket S3.

1. Créer un mécanisme d'alerte pour détecter toute modification ou suppression de ce bucket.

   1. Tout d'abord, vous devez activer CloudTrail s'il n'est pas déjà activé.

   2. Allez dans la console CloudWatch , cliquez sur Events > Rules.

      
   3. Cliquez ensuite sur Create Rule, sélectionnez le service CloudTrail dans le menu déroulant et AWS API Call via CloudTrail comme type d'événement.

      
   4. Enfin, cliquez sur Specific operations et ajoutez :

      1. PutBucketPolicy

      2. DeleteBucketPolicy

      3. DeleteBucketLifecycle

      4. DeleteBucketPublicAccessBlock

      5. PutBucketPublicAccessBlock

      6. DeleteBucket comme opérations pour lesquelles nous souhaitons être alertés.

      7. Ajoutez le code JSON suivant pour configurer l'alerte :

{
  "source" : ["aws.s3"],
  "detail-type" : ["AWS API Call via CloudTrail"],
  "detail" : {
    "eventSource" : ["s3.amazonaws.com"],
    "eventName" : ["DeleteBucket", "DeleteBucketLifecycle", "DeleteBucketPolicy", "PutBucketPolicy", "DeleteBucketPublicAccessBlock", "PutBucketPublicAccessBlock"],
    "requestParameters" : {
      "bucketName" : ["my-bucket-stoik"]
    }
  }
}

Remarque : vous devez remplacer my-bucket-stoik par le nom du bucket que vous souhaitez protéger.

e. L'étape finale consiste à configurer la cible de l'alerte. Vous pouvez choisir un sujet SNS pour envoyer une notification à un sujet SNS, ou choisir une fonction Lambda pour déclencher une fonction Lambda.