Gestion des données Azure Automation
Cet article contient plusieurs rubriques expliquant comment les données sont protégées et sécurisées dans un environnement Azure Automation.
TLS 1.2 pour Azure Automation
Pour garantir la sécurité des données en transit vers Azure Automation, nous vous encourageons vivement à configurer l’utilisation du protocole TLS (Transport Layer Security) 1.2. Voici une liste de méthodes ou de clients qui communiquent via HTTPS avec le service Automation :
Appels de Webhook
Runbook Workers hybrides comprenant des machines gérées par Update Management et Suivi des modifications et inventaire.
Nœuds DSC
Les versions antérieures de TLS/SSL (Secure Sockets Layer) se sont avérées vulnérables et bien qu’elles fonctionnent encore pour assurer la compatibilité descendante, elles sont déconseillées. Nous ne recommandons pas de configurer explicitement votre agent de façon à ce qu’il utilise uniquement TLS 1.2, sauf en cas de nécessité, car cela peut annuler les fonctionnalités de sécurité au niveau de la plateforme qui vous permettent de détecter automatiquement et de tirer parti des protocoles plus sécurisés et plus récents dès qu’ils sont disponibles, tels que TLS 1.3.
Pour plus d’informations sur la prise en charge du protocole TLS 1.2 avec l’agent Log Analytics pour Windows et Linux, qui est une dépendance pour le rôle Runbook Worker hybride, consultez Vue d’ensemble de l’agent Log Analytics – TLS 1.2.
Instructions spécifiques à la plateforme
| Plateforme/Langage | Support | Informations complémentaires |
|---|---|---|
| Linux | Les distributions de Linux s’appuient généralement sur OpenSSL pour la prise en charge de TLS 1.2. | Vérifiez OpenSSL Changelog pour vous assurer que votre version d’OpenSSL est prise en charge. |
| Windows 8.0 - 10 | Pris en charge, activé par défaut. | Pour confirmer que vous utilisez toujours les paramètres par défaut. |
| Windows Server 2012 - 2016 | Pris en charge, activé par défaut. | Pour confirmer que vous utilisez toujours les paramètres par défaut |
| Windows 7 SP1 et Windows Server 2008 R2 SP1 | Pris en charge, mais non activé par défaut. | Consultez la page Paramètres de Registre de TLS pour plus d’informations sur l’activation. |
Conservation des données
Quand vous supprimez une ressource dans Azure Automation, elle est conservée pendant de nombreux jours à des fins d’audit avant d’être supprimée définitivement. Vous ne pouvez ni voir ni utiliser la ressource pendant cette période. Cette stratégie vaut aussi pour les ressources qui appartiennent à un compte Automation supprimé. La stratégie de rétention s’applique à tous les utilisateurs et ne peut actuellement pas être personnalisée. Cependant, si vous souhaitez conserver les données sur une plus longue période, vous pouvez transférer les données de tâches Azure Automation dans des journaux Azure Monitor.
Le tableau suivant récapitule la stratégie de rétention pour les différentes ressources.
| Données | Stratégie |
|---|---|
| Comptes | Un compte est définitivement supprimé 30 jours après avoir été supprimé par un utilisateur. |
| Éléments multimédias | Une ressource est définitivement supprimée 30 jours après avoir été supprimée par un utilisateur ou 30 jours après qu’un utilisateur a supprimé un compte qui contenait la ressource. Les ressources incluent des variables, des planifications, des informations d’identification, des certificats, des packages Python 2 et des connexions. |
| Nœuds DSC | Un nœud DSC est définitivement supprimé 30 jours après avoir été désinscrit d’un compte Automation via le portail Azure ou l’applet de commande Unregister-AzAutomationDscNode dans Windows PowerShell. De même, un nœud peut être supprimé définitivement 30 jours après qu’un utilisateur a supprimé le compte qui contenait le nœud. |
| travaux | Une tâche est supprimée et définitivement retirée 30 jours après avoir été modifiée (par exemple, suite à la fin, à l’arrêt ou à l’interruption de la tâche). |
| Modules | Un module est définitivement supprimé 30 jours après avoir été supprimé par un utilisateur ou 30 jours après qu’un utilisateur a supprimé le compte qui contenait le module. |
| Configurations de nœud/fichiers MOF | Une ancienne configuration de nœud est définitivement supprimée 30 jours après la génération d’une nouvelle configuration de nœud. |
| Rapports sur le nœud | Le rapport sur un nœud est définitivement supprimé définitivement 90 jours après la génération d’un nouveau rapport pour ce même nœud. |
| Runbooks | Un runbook est définitivement supprimé 30 jours après qu’un utilisateur a supprimé la ressource ou 30 jours après qu’un utilisateur a supprimé le compte qui contenait la ressource1. |
1Le runbook peuvent être récupéré dans la fenêtre de 30 jours en ouvrant un incident de support Azure auprès du support Microsoft Azure. Accédez au site de support Azure et sélectionnez Soumettre une demande de support.
Sauvegarde de données
Quand vous supprimez un compte Automation dans Azure, tous les objets du compte sont supprimés. Ces objets peuvent notamment consister en des runbooks, des modules, des configurations, des paramètres, des tâches ou des ressources. Ces objets ne peuvent pas être récupérés après que le compte a été supprimé. Vous pouvez utiliser les informations suivantes pour sauvegarder le contenu de votre compte Automation avant de le supprimer.
Runbooks
Vous pouvez exporter vos Runbooks vers vos fichiers de script en utilisant soit le portail Azure, soit l’applet de commande Get-AzureAutomationRunbookDefinition dans Windows PowerShell. Vous pouvez importer ces fichiers de script dans un autre compte Automation, comme expliqué dans Gérer les runbooks dans Azure Automation.
Modules d'intégration
Vous ne pouvez pas exporter les modules d’intégration à partir d’Azure Automation, ils doivent être mis à disposition en dehors du compte Automation.
Éléments multimédias
Vous ne pouvez pas exporter de ressources Azure Automation : certificats, connexions, informations d’identification, planifications et variables. En revanche, vous pouvez utiliser le portail Azure et des applets de commande Azure pour noter les détails de ces ressources. Ces détails vous serviront par la suite à créer les ressources qui seront utilisées par les runbooks que vous importerez dans un autre compte Automation.
Vous ne pouvez pas récupérer la valeur des variables chiffrées ou des champs de mot de passe des informations d’identification en utilisant des applets de commande. Si vous ne connaissez pas ces valeurs, vous pouvez les récupérer dans un runbook. Pour récupérer des valeurs de variables, consultez Ressources de variable dans Azure Automation. Pour en savoir plus sur la récupération des valeurs d’informations d’identification, consultez Ressources d’informations d’identification dans Azure Automation.
Configurations DSC
Vous pouvez exporter vos configurations DSC dans des fichiers de script en utilisant soit le portail Azure, soit l'applet de commande Export-AzAutomationDscConfiguration dans Windows PowerShell. Vous pouvez importer et utiliser ces configurations dans un autre compte Automation.
Géo-réplication dans Azure Automation
La géoréplication est une fonctionnalité standard des comptes Azure Automation. Au moment de configurer votre compte, vous choisissez une région primaire. Le service de géoréplication interne d’Automation affecte alors automatiquement une région secondaire au compte. Les données de compte de la région primaire sont sauvegardées en continu dans la région secondaire. La liste complète des régions primaires et secondaires est accessibles dans Réplication entre les régions dans Azure : continuité d’activité et reprise d’activité.
La sauvegarde créée par le service de géoréplication Automation est une copie complète de ressources, configurations et autre objets analogues Automation. Cette sauvegarde peut être utilisée si la région primaire perd des données à la suite d’une défaillance. Dans le cas peu probable d’une perte des données d’une région primaire, Microsoft tente de les récupérer.
Notes
Azure Automation stocke les données client dans la région sélectionnée par le client. À des fins de continuité d’activité et reprise d’activité, pour toutes les régions, à l’exception de Brésil Sud et Asie Sud-Est, les données Azure Automation sont stockées dans une région différente (région appariée Azure). Dans le cas de la région Brésil Sud (État de Sao Paulo) de la géographie Brésil et de la région Asie Sud-Est (Singapour) de la géographie Asie-Pacifique, nous stockons les données Azure Automation dans la même région afin de répondre aux exigences de résidence des données pour ces régions.
Le service de géoréplication Automation n’est pas directement accessible aux clients externes en cas de défaillance régionale. Si vous souhaitez conserver la configuration et les runbooks Automation pendant les défaillances régionales, configurez la récupération d’urgence des comptes Automation et de leurs ressources dépendantes, comme les modules, les connexions, les informations d’identification, les certificats, les variables et les planifications. Plus d’informations
Étapes suivantes
- Pour en savoir plus sur les instructions de sécurité, consultez Meilleures pratiques de sécurité dans Azure Automation.
- Pour en savoir plus sur les ressources sécurisées dans Azure Automation, consultez Chiffrement des ressources sécurisées dans Azure Automation.
- Pour découvrir plus en détail la géoréplication, consultez Création et utilisation de la géoréplication active.