Rappel du principe d’Azure Bastion
Aujourd’hui je vous propose d’utiliser Azure Automation afin de provisionner votre Bastion dans le Cloud mais uniquement lorsque vous en avez besoin. Si vous suivez un peu le blog, vous savez probablement qu’Azure Bastion est un service que j’apprécie particulièrement. Ce composant permet d’accéder de manière sécurisée en RDP ou en SSH à une machine Windows ou Linux dans votre Cloud Microsoft.
L’intérêt de cette solution est qu’elle permet de se connecter à vos serveurs sans avoir besoin « d’ouvrir les tuyaux » sur Internet de manière publique puisque l’accès RDP/SSH s’effectue directement depuis le portail web d’Azure avec un compte Azure AD approuver.
C’est donc une rapproche fortement recommandée si vous souhaitez respecter la méthodologie de sécurité que l’on appelle Zero Trust. Le problème, c’est qu’Azure Bastion est un composant qui reste assez onéreux si vous envisagez de le laisser actif de manière permanente (jour, nuit, weekend, etc.) – je vous propose donc de voir comment automatiser sa création et sa suppression vu qu’il ne peut pas être interrompu / désactivé temporairement. 🙂
Avant d’aller plus loin je vous encourage à consulter les 2 liens ci-dessous :
- Présentation de Azure Bastion dans mon ancien article 🛡️
- Prix concernant l’utilisation d’Azure Bastion 💰
Etape 0 – Prérequis
Pour mettre en place mon scénario, voici ce que j’ai créé dans un Resource Group de test. Juste une machine virtuelle avec tout ce qui est nécessaire en termes de réseau.
Je vous rappelle les points clés :
- La VM dispose d’un NSG affecté à sa carte réseau qui permet d’autoriser la connexion sur le port 22/TCP (SSH) – nous aurions pu tester sur un VM Windows, j’ai choisi une Linux.
- Notez bien que la VM ne dispose de pas de sa propre adresse IP publique. Nous n’en avons pas besoin car nous ne souhaitons pas que la VM soit accessible d’un point de vue public sur Internet. Nous utiliserons notre Azure Bastion pour l’administrer. 🙂
Autre prérequis nécessaire, si nous voulons pouvoir créer et supprimer notre Azure Bastion sans avoir à gérer les dépendances il faut que nous créions notre subnet AzureBastionSubnet sur votre VNET. Pour rappel, vous devez respecter la convention de nommage pour ce nom et il doit s’agit d’un /26 au minimum. C’est ce que j’ai fait sur le VNET qui est utilisé par ma VM.
Le prix de ce Subnet est anecdotique dans notre facture nous pouvons donc le créer dès à présent. 😉
Etape 1 – Création de notre objet Azure Automation
Dans votre portail Azure, cherchez maintenant un objet Azure Automation. C’est cet objet que nous allons utiliser pour générer des automatismes dans Azure. Et point intéressant, ce composant ne coûte vraiment pas grand-chose. Nous allons utiliser l’option « Runbooks » afin de créer 2 scripts PowerShell : un exécuté le matin pour créer le Bastion et un le soir pour supprimer le Bastion. De cette façon, nous allons économiser les frais de fonctionnement du Bastion pour la nuit. 👍
"Please enable appropriate RBAC permissions to the system identity of this automation account. Otherwise, the runbook may fail..."
try
{
"Logging in to Azure..."
Connect-AzAccount -Identity
}
catch {
Write-Error -Message $_.Exception
throw $_.Exception
}
Write-Output "Connection successful"
Write-Output "Trying to create the Azure Bastion..."
try
{
Select-AzSubscription -SubscriptionId "b23edba1-your-subscribtion-id"
New-AzBastion -ResourceGroupName "Test" -Name "ThibaultBastion2" `
-PublicIpAddressRgName "Test" -PublicIpAddressName "VMLinuxTest-vnet-ip" `
-VirtualNetworkRgName "Test" -VirtualNetworkName "VMLinuxTest-vnet" `
-Sku "Basic"
}
catch {
Write-Error -Message $_.Exception
throw $_.Exception
}
J’ai gardé le modèle de script qui est mis à disposition par défaut par Microsoft. Vous pouvez bien entendu changer et adapter le nom des composants en fonction de votre scénario. Même chose, nous aurions pu utiliser des variables – j’ai été au plus rapide pour notre exemple. C’est la ligne qui contient New-AzBastion qui va permettre de créer notre Azure Bastion.
Lorsque vous êtes prêt, vous pouvez tenter d’exécuter manuellement votre script pour vérifier que l’opération se déroule correctement. Vous pourrez voir dans les Logs et dans votre Resource Group qu’un nouveau Bastion a été créé avec succès.
Etape 2 – Suppression du Bastion
Pour réaliser la suppression de notre Bastion nous allons maintenant utiliser le même script que précédemment mais remplacer la ligne commençant par New-AzBastion par Remove-AzBastion.
"Please enable appropriate RBAC permissions to the system identity of this automation account. Otherwise, the runbook may fail..."
try
{
"Logging in to Azure..."
Connect-AzAccount -Identity
}
catch {
Write-Error -Message $_.Exception
throw $_.Exception
}
Write-Output "Connection successful"
Write-Output "Trying to create the Azure Bastion..."
try
{
Select-AzSubscription -SubscriptionId "b23edba1-your-subscribtion-id"
Remove-AzBastion -ResourceGroupName "Test" -Name "ThibaultBastion2" -Force
}
catch {
Write-Error -Message $_.Exception
throw $_.Exception
}
Exécutez le script pour vérifier que cela fonctionne et que votre objet Bastion va bien finir par disparaître.
Etape 3 – Automatisation de nos scripts
Nous avons pu vérifier que nos 2 scripts PowerShell fonctionnaient correctement et que l’objet Bastion était bien supprimé de notre Resource Group. 🙂
Il nous reste maintenant à automatiser nos 2 scripts. Imaginons que vos équipes commencent le matin à 9h vous pouvez planifier le premier script à 8h30. Si vous terminez à 17h et bien pareil vous pouvez supprimer l’objet Bastion à 17h30.
Pour cette partie, je vous encourage à consulter mon ancien article car je l’ai déjà expliqué.
- Voir l’article : Azure Automation – Planifier l’exécution d’un script PowerShell
Sur chacun de vos scripts, vous allez devoir créer un Schedule.
Cette gestion de l’accès à nos VM peut être rapprochée de l’option Just-In-Time VM Access qui est disponible dans Microsoft Defender for Cloud. Je vous avais d’ailleurs déjà parlé de cette option dans l’article suivant. La différence principale entre les 2 méthodes est d’ailleurs très intéressante :
- Avec Just-In-Time VM Access, il y une véritable ouverture de flux qui est réalisée. Le port 22/SSH ou 3389/RDP est en effet ouvert pour une durée limitée dans le temps au niveau de votre VNet/NSG.
- En revanche, avec la méthode Azure Bastion, il n’y a pas d’ouverture de flux qui soit réalisée au niveau de votre VM, NSG ou VNet. Vous accédez à la VM via déport d’affichage graphique depuis le portail web Azure. Cette seconde méthode est donc plus intéressante d’un point de vue sécurité si l’on se conforme au modèle Zero Trust. 🛡️
