PowerShell Roomba – Comment automatiser le nettoyage de vos accès à vos bases de données avec Azure Automation

C’est le début du mois et votre forfait 4G vient d’être renouvelé. Super ! On va pouvoir l’entamer à grands coups de billet-plein-de-captures-d’écran…

Dans un précédent article, nous avons vu comment faire, avec PowerShell, un nettoyage “one shot” des règles obsolètes des pare-feux de nos serveurs SQL Azure. Ici, nous allons voir comment automatiser cette tâche.

Comment créer un compte Azure Automation

Dans un premier temps, nous devons créer un compte Azure Automation. C’est le service qui va nous permettre d’exécuter régulièrement le script PowerShell qui supprime les règles obsolètes de nos pare-feux. Pour ceux qui ne connaissent pas, Laurent a écrit un très bon article à ce sujet.

Rendez-vous sur la page principale du service (en utilisant le champ de recherche ou le menu de gauche) puis créez un nouveau compte. Les détails de cette étape se trouvent sur la documentation officielle.

Veillez à demander la création d’un compte d’identification. De cette manière, lorsque vous cliquerez sur “Créer”, trois choses magiques vont se produire sous vos yeux éblouis (tellement “sous” vos yeux en fait que vous n’y verrez que du feu, d’où l’éblouissement).

• Un nouveau compte d’identification est créé, avec un principal associé dans l’Active Directory. C’est ce compte qui sera utilisé pour exécuter le script.
• Un certificat associé au compte est généré. C’est lui qui permettra de s’authentifier.
• Le rôle de “contributeur” est assigné au nouveau compte.

S’il ne vous est pas possible de créer de compte d’identification, c’est que vous ne disposez pas des droits nécessaires. Il vous faut être propriétaire de la souscription et être administrateur, général ou limité, dans l’annuaire Active Directory associé à la souscription.

Vous pouvez voir les détails du compte créé dans la section “Comptes d’identification” (ou “Run As Accounts” si votre portail est en anglais).

Un second compte est créé pour la gestion des ressources Azure Classic.

Notez bien la section Connexion. Les données qui s’y trouvent seront utilisées par notre script pour l’authentification.

Création d’un Runbook PowerShell

Une fois notre compte Automation créé, il nous faut un “Runbook”. C’est lui qui contiendra la définition du script et la planification de son exécution.

L’important, ici, est de choisir un runbook de type PowerShell. Bien sûr, ça ne vous empêche pas de choisir un nom parlant ni de saisir une description digne des plus belles envolées lyriques.

Là encore vous pouvez vous tourner vers la documentation Microsoft  pour plus de détails sur la création de Runbooks.

Ajouter un script PowerShell

Le Runbook maintenant créé, on se retrouve face à l’écran suivant.  En déployant l’arborescence du menu de gauche, on trouve dans les sections Connexions  (1) et Certificats  (2) des références au compte de service généré précédemment. Ça tombe bien, c’est justement ce qu’il va nous falloir pour automatiser notre script.

En effet, le script PowerShell que nous avions développé dans l’article précédent fait le travail, mais il pose un problème de taille : il requiert notre intervention à plusieurs reprises. En particulier sur :

• L’appel de la fonction Login-AzureRmAccount ouvre une fenêtre d’authentification dans laquelle on entre nos credentials.
• L’appel à la fonction Remove-AzureRmSqlServerFirewallRule demande confirmation à l’utilisateur

Mise à jour du script de suppression de règle de pare-feu

Pour une exécution live, c’est pratique, mais pour l’automatisation, c’est pas le top. On va donc devoir modifier le code source de la façon suivante :

$subscriptionName = "MySubscription"



$resourceGroupName = "MyResourceGroup"
$serverName = "MyServerName"
$permanentRules = @("rule1","rule5")

$connectionName = "AzureRunAsConnection"
$servicePrincipalConnection = Get-AutomationConnection -Name $connectionName

# Avant on avait Login-AzureRmAccount
Add-AzureRmAccount `
    -ServicePrincipal `
    -TenantId $servicePrincipalConnection.TenantId `
    -ApplicationId $servicePrincipalConnection.ApplicationId `
    -CertificateThumbprint   $servicePrincipalConnection.CertificateThumbprint

Select-AzureRmSubscription -SubscriptionName $subscriptionName
$rules = Get-AzureRmSqlServerFirewallRule -ResourceGroupName $resourceGroupName -ServerName $serverName

foreach($rule in $rules) {
    if($permanentRules -notcontains $rule.FirewallRuleName) {
        Remove-AzureRmSqlServerFirewallRule `
            -FirewallRuleName $rule.FirewallRuleName `
            -ResourceGroupName $resourceGroupName `
            -ServerName $serverName `
            -Confirm:$false    # on ne veut pas avoir à confirmer
    }
}

Attention: si vous souhaitez autoriser tous vos services Azure à utiliser votre serveur Azure SQL, pensez bien à ajouter la règle “AllowAllWindowsAzureIps” à la liste de règles permanentes.

Dans cette version, la fonction Login-AzureRmAccount a été remplacée par Add-AzureRmAccount, qui va utiliser la connexion et le certificat pour authentifier le script avec le compte d’identification du compte Automation. La référence à la connexion est récupérée par la commande Get-Automationconnection.

Pour éviter la demande de confirmation faite par la commande Remove-AzureRmSqlServerFirewallRule, on utilise le paramètre -Confirm en lui passant la valeur $false. On aurait pu aussi utiliser -force, mais personnellement je suis allergique à l’effort…

Voilà le résultat final, encore une fois en image (on a quand même 20GO à consommer).

Il ne reste plus qu’à publier le Runbook (3) et à l’exécuter pour s’assurer que tout fonctionne comme prévu.

Création d’une planification récurrente

Nous avons à présent un Runbook qui permet de nettoyer nos règles de pare-feu SQL en un click. Pour plus de sécurité, cette action doit être effectuée régulièrement. Quoi de mieux qu’une tâche planifiée pour ça ? Une fois encore, la manipulation se fait en quelques clics depuis le portail.

• Dans le menu du Runbook, cliquez sur “Planifications”
• Cliquez sur “Ajouter une planification” puis “Associer une planification à votre Runbook” et enfin “Créer une planification”
• Choisissez l’option “récurrent” et entrez la fréquence souhaitée.

Note PowerShell Roomba est terminé !

Point Bonus : modification du rôle du compte d’identification

Depuis la page d’administration des contrôles d’accès de l’abonnement (i.e. la souscription), on peut voir le compte d’identification et le rôle qui lui est assigné.

Dans l’exemple ci-dessus, le compte a le rôle contributeur. C’est bien plus que ce qu’il faut pour simplement supprimer les règles du pare-feu SQL. On va donc appliquer le principe de moindre privilège et lui attribuer le rôle “Gestionnaire de sécurité SQL”.

Suppression du rôle par défaut

• Depuis la fenêtre de Contrôle d’accès, cliquez sur “Rôles” > “Contributeur”
• Sélectionnez le compte d’identification, puis cliquez sur “Supprimer”

Le compte d’identification n’a plus de privilège. Il faut donc lui attribuer ceux dont il a besoin pour supprimer nos règles.

Ajout du nouveau rôle Gestionnaire de sécurité SQL

• Depuis la fenêtre de Contrôle d’accès cliquez sur “Ajouter”
• Sélectionner le rôle “Gestionnaire de sécurité SQL” puis rechercher le nom de votre compte d’identification
• Sélectionnez le compte d’identification, puis cliquez sur “Enregistrer”

En conclusion

L’automatisation des tâches de maintenance est une pratique indispensable à la sécurisation de vos systèmes. Azure fournit, avec Azure Automation, un moyen simple et efficace pour exécuter vos scripts PowerShell de manière récurrente garantissant ainsi que les droits d’accès à vos serveurs SQL sont limités au strict minimum.