Configurer l’autorisation multi-utilisateur pour Azure Backup

J’avais déjà écrit un article sur comment sauvegarder de machine virtuelle via Runbook/Snapshot. Cette option est intéressante dans le cas où la sauvegarde native d’Azure ne supporte pas l’OS de la machine virtuelle. Microsoft continue d’apporter des mesures de sécurité sur son service sauvegarde Azure Backup.

Dans cet article, nous allons parler et tester l’autorisation multi-utilisateur (MUA), annoncée il y a seulement quelques jours en disponibilité générale. Dans quel but ? Accroître la protection des sauvegardes de vos ressources Azure.

Mais avant cela, nous allons faire un rappel de quelques mesures de protection de sauvegardes de machines virtuelles disponibles sur Azure.

Par défaut, quelles mesures de protection existent sur mes sauvegardes de VMs ?

Quand vous sauvegardez des machines virtuelles au travers de la sauvegarde native d’Azure, vous utilisez et déployez un coffre de sauvegarde. Ce dernier est directement géré par le service Azure Backup :

Ce schéma nous montre la création de snapshots et le transfert différé vers le coffre de sauvegarde.

La création de snapshots et la rétention de vos sauvegardes sont alors configurées selon une police de sauvegarde, créée dans ce coffre de sauvegarde :

Il est possible de créer plusieurs polices de sauvegardes.
Azure propose maintenant plusieurs sauvegardes par jour.

D’autre part, le nombre et la répartition des copies de vos sauvegardes vont dépendre des propriétés de ce coffre :

La création d’un Recovery Service Vault est paramétré en Geo-redondant par défaut.
Cette option reste modifiable tant qu’aucune sauvegarde n’est paramétrée.

Pour rappel, voici quelques notions de réplication à connaitre, tant elles sont très utilisées sur un grand nombre de ressources Azure :

  • Redondance locale (LRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure.
  • Redondance zonale (ZRS) : La donnée est présente en triple exemplaires, chacun réparti dans les 3 datacenters (Zones) de la même région Azure, si celle-ci le propose.
  • Géo-redondance (GRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure, et 3 autres exemplaires dans la région paire Azure de la première.

Note : il existe également d’autres scénarios de réplication Azure : RA-GRS, GZRS, … 😊

Enfin, la suppression d’une sauvegarde stockée dans un coffre conserve encore celle-ci pendant 14 jours. Cette fonctionnalité est activée par défaut et est appelée Soft-delete :

Pour information, la donnée maintenue dans cet état de soft-delete ne coûte rien.

Un coffre de sauvegarde contenant encore des sauvegardes en état de soft-delete ne peut être supprimé.

Envi d’en savoir plus sur la sauvegarde de machine virtuelle ?

Voici l’excellente vidéo de Travis Roberts expliquant le service Azure Backup et les étapes de sa mise en place sur différentes ressources Azure :

Pourquoi mettre en place l’autorisation multi-utilisateur sur les sauvegardes Azure ?

L’autorisation multi-utilisateur (MUA) pour la sauvegarde Azure vous permet d’ajouter une couche supplémentaire de protection aux opérations critiques sur vos coffres Recovery Services. Pour MUA, Sauvegarde Azure utilise une autre ressource Azure appelée protection des ressources pour garantir que les opérations critiques sont effectuées uniquement avec l’autorisation applicable.

Microsoft Doc

En y réfléchissant, un scénario apparait effectivement comme non protégé : comment sécuriser les sauvegardes contre un compte administrateur compromis ou contre une suppression accidentelle ?

En effet, un compte utilisateur Azure AD, configuré comme propriétaire ou contributeur de ressources Azure, dispose des droits pour la mise en en place de sauvegardes, mais également de ceux pour les démettre ! Les mesures listées précédemment renforcent la sécurité mais sont toutes réversibles par cet utilisateur.

Est-ce ici qu’entre en scène Azure Resource Guard ?

L’idée générale d’Azure Resource Guard est de faire reposer la répartition des tâches (donc des droits Azure) sur différents utilisateurs. Il s’agit d’un dispositif (SOD) mis en place dans tout processus de contrôle interne : acteur et contrôleur.

Comme le montre le schéma ci-dessous, deux roles sont alors nécessaires pour sécuriser les actions liées aux sauvegardes avec MUA :

  • Administrateur sauvegarde : Propriétaire ou contributeur du coffre de sauvegarde. Ce dernier met en place et gère les sauvegardes de ressources Azure. L’administrateur sauvegarde ne doit pas avoir de droits élevés et permanent sur l’Azure Resource Guard.
  • Administrateur sécurité : Propriétaire du Azure Resource Guard et gardien des opérations critiques sur le coffre de sauvegarde. Par conséquent, l’administrateur sécurité contrôle les permissions dont l’Administrateur sauvegarde a besoin pour effectuer les opérations critiques.

Quelles sont les actions restreintes grâce à Azure Resource Guard ?

L’installation du contrôle d’Azure Resource Guard sur un coffre de sauvegarde bloquera certaines actions si les droits de l’Administrateur sauvegarde sont insuffisants :

Les opérations marquées comme obligatoires ne peuvent pas être exclues de la protection par Azure Resource Guard. Enfin, cette configuration s’appliquera à tous les coffres de sauvegarde associés à celui-ci.

Où doit se trouver Azure Resource Guard ?

Le service Azure Resource Guard doit obligatoirement être sur la même région Azure que le coffre de sauvegarde qu’il protège. De plus, l’Administrateur sauvegarde ne doit pas avoir de droits de contributeur permanent sur Azure Resource Guard. Dans le cas contraire, il n’est jamais bloqué pour aucune action critique sur le coffre de sauvegarde.

Il est alors possible d’envisager différents scénarios :

  • Le coffre de sauvegarde et Azure Resource Guard sont dans la même souscription. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des souscriptions différentes du même tenant. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard ou à sa souscription.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des tenants différents. Mais l’Administrateur de sauvegarde n’a pas accès à Azure Resource Guard, à la souscription ou tenant correspondant.

Etape 0 : Rappel des prérequis

Comme pour beaucoup d’articles sur ce blog, nous allons créer différentes ressources sur Azure pour y parvenir. Comme à chaque fois, des prérequis sont nécessaires pour réaliser cette démonstration :

  • Un tenant Microsoft. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde hébergés sur différents tenants.
  • Une ou plusieurs souscriptions Azure. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde sur différentes souscriptions Azure.
  • Une machine virtuelle déjà déployée sur un tenant accessible à l’Administrateur de sauvegarde .

Dans mon cas, j’ai utilisé deux tenants différents, différenciés dans cet article par la couleur du portail Azure pour plus de simplicité :

  • Le tenant A, noir pour l’Administrateur de sauvegarde, contient la machine virtuelle à sauvegarder et le coffre de sauvegarde.
  • Le tenant B, blanc pour l’Administrateur sécurité, contient Azure Ressource Guard.

Nous avons donc les deux environnements Azure suivants :

Tenant A.

Etape I : Création d’Azure Resource Guard

Sur le tenant B, commencez la création du service Azure Resource Guard :

Renseignez les différents champs, puis cliquez sur Suivant :

Si l’erreur suivante apparaît, retournez sur la page de la souscription Azure concernée :

Cliquez comme ceci pour constater le statut du resource provider Microsoft.DataProtection :

Cliquez alors sur celui-ci puis sur Enregistrer :

Attendez quelques minutes que le traitement se termine :

Contrôler le nouveau statut du resource provider :

Retournez dans la création de votre Azure Resource Guard pour constater la disparition du message d’erreur sur le second onglet.

Sélectionnez les opérations dont vous avez besoin de protéger et cliquez comme ceci pour les valider :

Vous pourrez toujours modifier cette liste après la création dans les propriétés d’Azure Resource Guard.

Lancez la création de votre Azure Resource Guard :

Etape I : Assignation du rôle de lecteur pour l’administrateur de sauvegarde

Afin de pouvoir interroger le service Azure Resource Guard, l’Administrateur sauvegarde doit disposer d’un rôle de lecteur sur ce dernier.

Sur le tenant B, retournez sur l’Azure Resource Guard et cliquez comme-ci pour rajouter le rôle de lecteur à l’administrateur sauvegarde :

Choisissez le rôle de lecteur puis cliquez sur Suivant :

Ajoutez votre Administrateur sauvegarde :

Cliquez pour valider :

Etape II : Création du coffre de sauvegarde

De retour sur le tenant A, recherchez le service Recovery Service Vault pour le créer :

Renseignez les champs et lancez la création du coffre de sauvegarde :

Etape III : Protégez votre coffre de sauvegarder

Retournez sur le tenant B, puis copiez la valeur suivante de votre Azure Resource Guard :

Sur le tenant A, retournez sur votre coffre de sauvegarde et cliquez ici pour mettre en place la MUA :

Effectuez les opérations suivantes et collez votre Resource Guard ID dans le champ suivant :

Contrôlez la cohérence des informations de votre Azure Resource Guard :

Sauvegardez la configuration MUA de votre coffre de sauvegarde :

Votre coffre de sauvegarde est maintenant protégé, continuez sur l’étape suivante pour vérifier le blocage des opérations pour l’Administrateur sauvegarde.

Etape IV : Contrôlez le blocage pour l’administrateur sauvegarde

Restez dans les propriétés de votre coffre de sauvegarde et cliquez sur les options de sécurité :

Vous êtes immédiatement averti de la couche de protection supplémentaire grâce au service Azure Resource Guard :

Essayez de désactiver la fonctionnalité Soft Delete et sauvegardez la nouvelle configuration :

L’action de sauvegarde échoue bien et affiche la notification d’erreur suivante :

La même opération, avec un autre compte, disposant lui de droits de contributeur sur Azure Resource Guard, dans mon exemple grâce à Azure Lighthouse, ne pose aucun souci :

Etape IV : Sauvegardez votre la machine virtuelle avec MUA

La mise en place de MUA ne bloque pas l’Administrateur sauvegarde de mettre en place de nouvelles protections pour des ressources Azure.

Pour cela, retournez sur la page principale de votre coffre de sauvegarde et cliquez comme-ceci :

Continuez la configuration avec la famille de ressources Machine virtuelle :

Ajoutez votre machine virtuelle à sauvegarder :

Cochez la case correspondante pour prendre la machine virtuelle désirée et cliquez sur OK

Activez la mise en place de la sauvegarde :

Une fois le traitement terminé, retournez sur le coffre de sauvegarde comme-ci :

Cliquez ici pour afficher les détails :

Lancez une sauvegarde immédiate :

La mise en place de la sauvegarde et la première sauvegarde n’ont pas provoqué d’erreur MUA pour l’Administrateur sauvegarde.

Contrôler l’avancement des travaux de la première sauvegarde et affichez les détails pour vérifier quand celui-ci est entièrement terminé :

Après quelques minutes et plusieurs rafraichissements, la sauvegarde est complète et correctement envoyée dans le coffre de sauvegarde.

Que peut-on encore mettre en place ?

Dans certains cas, vous devrez peut-être effectuer des opérations critiques sur vos sauvegardes et MUA peut vous aider à vous assurer qu’elles sont exécutées uniquement lorsque les approbations ou les autorisations appropriées existent. Comme nous l’avons vu précédemment, l’administrateur de sauvegarde doit avoir un rôle Collaborateur sur le service de protection des ressources pour effectuer des opérations critiques qui se trouvent dans l’étendue de la protection des ressources. L’une des façons d’autoriser l’exécution juste-à-temps pour ces opérations consiste à utiliser Azure Active Directory (Azure AD) Privileged Identity Management.

Microsoft Doc

Les étapes suivantes de cet article sont facultatives, mais peuvent simplifier le processus d’élévations des droits grâce à la combinaison de plusieurs services Azure :

  • Azure Gestion des identités privilégiées (PIM)
  • Azure Resource Guard

La Gestion des identités privilégiées Azure AD, présente dans la licence Azure AD Premium P2, apporte de la souplesse dans les autorisations de droits temporaires sur des ressources Azure.

Dans le cadre de PIM et d’Azure Resource Guard, nous aurions la cinématique suivante :

  • Etape 0 : Demande d’élévation des droits par l’Administrateur sauvegarde
  • Etape I : Validation de la demande par Administrateur sécurité pour une durée donnée
  • Etape 2 : Intervention sur les sauvegardes par l’Administrateur sauvegarde
  • Etape 3 : Fin de l’élévation des privilèges d‘Administrateur sauvegarde
Le schéma ci-dessus est un exemple de scénario possible grâce à PIM.

Etape V : Intégration de PIM sur Azure Resource Guard

Sur le tenant B, recherchez le service Azure suivant :

Cliquez sur Ressources Azure puis sur la souscription ou le groupe de ressources contenant Azure Resource Guard :

Si aucune souscription n’apparait, cliquer « Découvrir les ressources » et laissez-vous guider.

Ajoutez un nouvel assignement :

Choisissez le rôle Contributeur et reprenez l’utilisateur Administrateur sauvegarde et cliquez sur Suivant :

Conservez bien la notion d’éligibilité et cliquez sur Assigner :

Etape VI : Mise en place du processus de validation

Notre utilisateur Administrateur sauvegarde est maintenant éligible pour devenir Contributeur sur Azure Resource Guard. Seulement, il est nécessaire de mettre en place un processus de validation pour l’élévation de ses droits. Sans cela et par défaut, toutes ses demandes seront automatiquement approuvées.

Sur le tenant B et au même niveau que précédemment, cliquez comme ceci dans Azure AD PIM pour modifier les paramétrages de validation :

Cliquez sur le rôle Contributeur :

Cliquez sur Modifier :

Modifiez vos paramétrages pour intégrer l’Administrateur sécurité dans l’activation et cliquez sur Mettre à jour :

Etape VII : Test de la fonctionnalité PIM sur Azure Resource Guard

Avant d’activer le rôle Contributeur sur Azure Resource Guard via Azure AD PIM, nous allons vérifier que l’action sur la sauvegarde de la machine virtuelle n’est pas autorisée dans les conditions de base.

Sur le tenant A, retourner sur le coffre de sauvegarde et cliquez comme ceci :

Cliquez ici pour arrêter le mécanisme de sauvegarde :

Arrêtez complètement le backup et supprimer les données :

Le message d’erreur suivant devrait alors apparaître :

Il est donc bien nécessaire de faire une élévation temporaire des droits sur Azure Resource Guard. Positionnez-vous sur le tenant contenant Azure Resource Guard et lancez Azure AD PIM :

Cliquez sur Mes Rôles :

Cliquez sur Ressources Azure puis sur Activer :

Entrez une justification et une période puis cliquez sur Activer :

La notification Azure suivante doit apparaître :

Sur le tenant B, cliquez sur Approuver les demandes dans Azure AD PIM :

Cliquez sur Ressources Azure et approuvez la demande :

Confirmez la demande d’approbation :

Sur le tenant A, un contrôle sur Azure AD PIM nous montre que le rôle de Contributeur est bien actif :

Retentez alors l’opération de suppression de la sauvegarde de la machine virtuelle :

Si l’erreur suivante arrive en notification, refaite un test dans quelques minutes :

Conclusion

L’ajout de cette fonctionnalité sur un coffre de sauvegarde est un vrai plus en termes de protection des ressources Azure. Il est vrai que la situation antérieure, avec des propriétaires et des contributeurs au plein pouvoirs pouvaient inquiéter en cas de scénarios d’attaque.

Il parait indispensable de sécuriser les opérations critiques liées aux sauvegardes, bien prises en compte avec Azure Resource Guard :

MUA apporte une vraie réponse pour protéger encore plus les sauvegardes et sans surcoût, sauf si Azure AD PIM est présent dans votre architecture. Nul doute qu’Azure Resource Guard va apporter encore plus de protection sur d’autres services au fil de ses évolutions.