Comment protéger les enregistrements et zones DNS
Notes
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour commencer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.
Les enregistrements et zones DNS sont des ressources critiques. La suppression d’une zone DNS ou d’un enregistrement DNS peut entraîner une interruption de service. Il est important que les zones et les enregistrements DNS soient protégés contre toute modification non autorisée ou accidentelle.
Cet article explique comment Azure DNS permet de protéger vos enregistrements et zones DNS contre de telles modifications. Nous appliquons deux puissantes fonctionnalités de sécurité d’Azure Resource Manager : le contrôle d’accès en fonction du rôle Azure (RBAC) et les verrous de ressources.
Contrôle d'accès en fonction du rôle Azure
Le contrôle d’accès en fonction du rôle Azure (Azure RBAC) permet une gestion des accès affinée pour les utilisateurs, les groupes et les ressources Azure. Avec Azure RBAC, vous pouvez accorder le niveau d’accès dont les utilisateurs ont besoin. Pour plus d’informations sur la gestion des droits d’accès avec le contrôle Azure RBAC, voir Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (Azure RBAC) ?.
Rôle Contributeur de zone DNS
Le rôle Collaborateur de zone DNS est un rôle intégré fourni par Azure pour gérer les ressources DNS privées. Ce rôle est appliqué à un utilisateur ou à un groupe, et permet de gérer les ressources DNS.
Le groupe de ressources myResourceGroup contient cinq zones pour Contoso Corporation. L’octroi des autorisations Contributeur de zone DNS pour ce groupe de ressources à l’administrateur DNS lui donne un contrôle total sur ces zones DNS. De cette façon, il n’accorde pas d’autorisations non nécessaires. L’administrateur DNS ne peut pas créer ni arrêter des machines virtuelles.
La façon la plus simple d’attribuer des autorisations Azure RBAC consiste à utiliser le portail Azure.
Ouvrez Contrôle d’accès (IAM) pour le groupe de ressources, sélectionnez +Ajouter, puis sélectionnez le rôle Collaborateur de zone DNS. Sélectionnez les utilisateurs ou les groupes auxquels accorder des autorisations.
Vous pouvez également accorder des autorisations à l’aide d’Azure PowerShell :
# Grant 'DNS Zone Contributor' permissions to all zones in a resource group
$usr = "<user email address>"
$rol = "DNS Zone Contributor"
$rsg = "<resource group name>"
New-AzRoleAssignment -SignInName $usr -RoleDefinitionName $rol -ResourceGroupName $rsg
La commande équivalente est également disponible via l’interface de ligne de commande Azure :
# Grant 'DNS Zone Contributor' permissions to all zones in a resource group
az role assignment create \
--assignee "<user email address>" \
--role "DNS Zone Contributor" \
--resource-group "<resource group name>"
Azure RBAC au niveau de la zone
Vous pouvez appliquer les règles RBAC d’Azure à un abonnement, à un groupe de ressources ou à une ressource. Cette ressource peut correspondre à une zone DNS ou à un jeu d’enregistrements.
Par exemple, le groupe de ressources myResourceGroup contient la zone contoso.com et la sous-zone customers.contoso.com. Des enregistrements CNAMe sont créés pour chaque compte client. Le compte d’administrateur utilisé pour gérer les enregistrements CNAME se voit attribuer des autorisations lui permettant de créer des enregistrements dans la zone customers.contoso.com. Le compte peut gérer uniquement customers.contoso.com.
Vous pouvez accorder les autorisations Azure RBAC au niveau zone via le portail Azure. Ouvrez Contrôle d’accès (IAM) pour la zone, sélectionnez +Ajouter, sélectionnez le rôle Contributeur de zone DNS, puis sélectionnez les utilisateurs ou groupes auxquels accorder les autorisations.
Vous pouvez également accorder des autorisations à l’aide d’Azure PowerShell :
# Grant 'DNS Zone Contributor' permissions to a specific zone
$usr = "<user email address>"
$rol = "DNS Zone Contributor"
$rsg = "<resource group name>"
$zon = "<zone name>"
$typ = "Microsoft.Network/DNSZones"
New-AzRoleAssignment -SignInName $usr -RoleDefinitionName $rol -ResourceGroupName $rsg -ResourceName $zon -ResourceType $typ
La commande équivalente est également disponible via l’interface de ligne de commande Azure :
# Grant 'DNS Zone Contributor' permissions to a specific zone
az role assignment create \
--assignee <user email address> \
--role "DNS Zone Contributor" \
--scope "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/DnsZones/<zone name>/"
Azure RBAC au niveau du jeu d’enregistrements
Les autorisations sont appliquées au niveau du jeu d’enregistrements. L’utilisateur peut contrôler les entrées dont il a besoin et ne peut apporter aucune autre modification.
Vous pouvez configurer les autorisations RBAC Azure au niveau du jeu d’enregistrements via le portail Azure à l’aide du bouton Utilisateurs dans la page du jeu d’enregistrements :
Vous pouvez également accorder les autorisations Azure RBAC au niveau jeu d’enregistrements en utilisant Azure PowerShell :
# Grant permissions to a specific record set
$usr = "<user email address>"
$rol = "DNS Zone Contributor"
$sco =
"/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/dnszones/<zone name>/<record type>/<record name>"
New-AzRoleAssignment -SignInName $usr -RoleDefinitionName $rol -Scope $sco
La commande équivalente est également disponible via l’interface de ligne de commande Azure :
# Grant permissions to a specific record set
az role assignment create \
--assignee "<user email address>" \
--role "DNS Zone Contributor" \
--scope "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/dnszones/<zone name>/<record type>/<record name>"
Rôles personnalisés
Le rôle intégré Contributeur de zone DNS donne un contrôle total sur une ressource DNS. Vous pouvez créer vos propres rôles Azure personnalisés afin de permettre un contrôle plus précis.
Le compte utilisé pour gérer ces enregistrements CNAME reçoit les autorisations permettant de gérer uniquement les enregistrements CNAME. Le compte ne peut pas modifier les enregistrements appartenant à d’autres types. Le compte ne peut pas effectuer d’opérations au niveau d’une zone, comme la suppression d’une zone.
L’exemple suivant montre une définition de rôle personnalisé pour la gestion des enregistrements CNAME uniquement :
{
"Name": "DNS CNAME Contributor",
"Id": "",
"IsCustom": true,
"Description": "Can manage DNS CNAME records only.",
"Actions": [
"Microsoft.Network/dnsZones/CNAME/*",
"Microsoft.Network/dnsZones/read",
"Microsoft.Authorization/*/read",
"Microsoft.Insights/alertRules/*",
"Microsoft.ResourceHealth/availabilityStatuses/read",
"Microsoft.Resources/deployments/*",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Support/*"
],
"NotActions": [
],
"AssignableScopes": [
"/subscriptions/c276fc76-9cd4-44c9-99a7-4fd71546436e"
]
}
La propriété Actions définit les autorisations spécifiques de DNS suivantes :
Microsoft.Network/dnsZones/CNAME/*accorde un contrôle total sur les enregistrements CNAME.Microsoft.Network/dnsZones/readaccorde l’autorisation de lire les zones DNS, mais ne pas de les modifier, ce qui permet de voir la zone dans laquelle l’enregistrement CNAME est créé.
Les Actions restantes sont copiées à partir du rôle intégré Contributeur de Zone DNS.
Notes
Le recours à un rôle Azure personnalisé pour empêcher la suppression de jeux d’enregistrements tout en autorisant leur mise à jour ne constitue pas un contrôle efficace. Cela empêche la suppression de jeux d’enregistrements, mais pas leur modification. Les modifications autorisées incluent l’ajout et la suppression d’enregistrements du jeu d’enregistrements, y compris la suppression de tous les enregistrements pour ne laisser qu’un jeu d’enregistrements vide. Sur le plan de la résolution DNS, cela produit le même effet que la suppression du jeu d’enregistrements.
Il n’est pas possible de définir des rôles personnalisés via le portail Azure. Vous pouvez créer un rôle personnalisé basé sur cette définition de rôle en utilisant Azure PowerShell :
# Create new role definition based on input file
New-AzRoleDefinition -InputFile <file path>
Vous pouvez également le faire via l’interface de ligne de commande Azure :
# Create new role definition based on input file
az role definition create --role-definition <file path>
Ensuite, vous pouvez attribuer le rôle de la même façon qu’un rôle intégré, en procédant de la manière décrite précédemment dans cet article.
Pour plus d’informations sur la façon de créer, gérer et attribuer des rôles personnalisés, consultez Rôles personnalisés Azure.
Verrous de ressources
Azure Resource Manager prend en charge un autre type de contrôle de sécurité : la possibilité de verrouiller des ressources. Un verrou de ressource est appliqué à une ressource et le verrouillage de celle-ci s’étend à l’ensemble des utilisateurs et des rôles qui l’utilisent. Pour plus d’informations, consultez Verrouiller des ressources avec Azure Resource Manager.
Il existe deux types de verrou de ressource : CanNotDelete et ReadOnly. Ces types de verrous peuvent être appliqués à une zone DNS privée ou à un jeu d’enregistrements. Les sections suivantes décrivent quelques scénarios courants et la manière de les prendre en charge à l’aide de verrous de ressources.
Protection contre toute modification
Pour empêcher toute modification, appliquez à la zone un verrou ReadOnly. Le verrou empêche toute création, modification ou suppression de jeux d’enregistrements.
Vous pouvez créer des verrous de ressources au niveau zone via le portail Azure. Dans la page des zones DNS, sélectionnez Verrous, puis +Ajouter :
Vous pouvez également créer des verrous de ressources au niveau d’une zone via Azure PowerShell :
# Lock a DNS zone
$lvl = "<lock level>"
$lnm = "<lock name>"
$rsc = "<zone name>"
$rty = "Microsoft.Network/DNSZones"
$rsg = "<resource group name>"
New-AzResourceLock -LockLevel $lvl -LockName $lnm -ResourceName $rsc -ResourceType $rty -ResourceGroupName $rsg
La commande équivalente est également disponible via l’interface de ligne de commande Azure :
# Lock a DNS zone
az lock create \
--lock-type "<lock level>" \
--name "<lock name>" \
--resource-name "<zone name>" \
--namespace "Microsoft.Network" \
--resource-type "DnsZones" \
--resource-group "<resource group name>"
Protection d’enregistrements spécifiques
Pour empêcher la modification d’un jeu d’enregistrements DNS, appliquez-lui un verrou ReadOnly.
Notes
L’application d’un verrou CanNotDelete à un jeu d’enregistrements n’est pas un contrôle efficace. Cela empêche la suppression du jeu d’enregistrements, mais pas sa modification. Les modifications autorisées incluent l’ajout et la suppression d’enregistrements du jeu d’enregistrements, y compris la suppression de tous les enregistrements pour ne laisser qu’un jeu d’enregistrements vide. Sur le plan de la résolution DNS, cela produit le même effet que la suppression du jeu d’enregistrements.
Vous pouvez actuellement configurer des verrous de ressources au niveau jeu d’enregistrements uniquement à l’aide d’Azure PowerShell. Il n’est pas possible de le faire via le portail Azure ou Azure CLI.
# Lock a DNS record set
$lvl = "<lock level>"
$lnm = "<lock name>"
$rsc = "<zone name>/<record set name>"
$rty = "Microsoft.Network/DNSZones/<record type>"
$rsg = "<resource group name>"
New-AzResourceLock -LockLevel $lvl -LockName $lnm -ResourceName $rsc -ResourceType $rty -ResourceGroupName $rsg
Protection contre la suppression de zone
Lors de la suppression d’une zone dans Azure DNS, tous les jeux d’enregistrements contenus dans celle-ci sont supprimés. Cette opération ne peut pas être annulée. La suppression accidentelle d’une zone critique peut avoir une incidence considérable. Il est important de protéger les zones contre toute suppression accidentelle.
L’application d’un verrou CanNotDelete à une zone empêche la suppression de celle-ci. Les ressources enfants héritent des verrous. Le verrou empêche la suppression de tous les jeux d’enregistrements d’une zone. Comme décrit dans la remarque ci-dessus, ce procédé est inefficace dans la mesure où il reste toujours possible de supprimer des enregistrements à partir des jeux d’enregistrements existants.
Une autre solution est d’appliquer un verrou CanNotDelete à un jeu d’enregistrements d’une zone, comme le jeu d’enregistrements SOA. Une zone ne peut pas être supprimée sans que les jeux d’enregistrements qu’elle contient ne soient eux aussi supprimés. Ce verrou empêche la suppression d’une zone, tout en permettant de modifier librement les jeux d’enregistrements qu’elle contient. Lorsqu’un utilisateur tente de supprimer une zone, Azure Resource Manager détecte cette tentative. Étant donné que la suppression de la zone entraînerait également la suppression du jeu d’enregistrements SOA, Azure Resource Manager bloque cette tentative, car les enregistrements SOA sont verrouillés. Aucun jeu d’enregistrements n’est supprimé.
La commande PowerShell suivante crée un verrou CanNotDelete sur l’enregistrement SOA de la zone donnée :
# Protect against zone delete with CanNotDelete lock on the record set
$lvl = "CanNotDelete"
$lnm = "<lock name>"
$rsc = "<zone name>/@"
$rty = "Microsoft.Network/DNSZones/SOA"
$rsg = "<resource group name>"
New-AzResourceLock -LockLevel $lvl -LockName $lnm -ResourceName $rsc -ResourceType $rty -ResourceGroupName $rsg
Pour empêcher la suppression accidentelle d’une zone, vous pouvez également utiliser un rôle personnalisé. Ce rôle garantit que les comptes utilisés pour gérer vos zones ne disposeront pas d’autorisations permettant de supprimer des zones.
Lorsque vous avez besoin de supprimer une zone, vous pouvez effectuer une suppression en deux étapes :
- Tout d’abord, attribuez des autorisations de suppression de zone.
- Ensuite, accordez des autorisations pour supprimer la zone en question.
Le rôle personnalisé fonctionne pour toutes les zones auxquelles ces comptes accèdent. Les comptes disposant d’autorisations de suppression de zone, tels que celui du propriétaire de l’abonnement, peuvent malgré tout supprimer accidentellement une zone.
Il est possible d’utiliser les deux approches (verrous de ressources et rôles personnalisés) en même temps pour une défense en profondeur des zones DNS.
Étapes suivantes
- Pour plus d’informations sur Azure RBAC, consultez Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (Azure RBAC) ?.
- Pour plus d’informations sur l’utilisation des verrous de ressources, voir Verrouiller des ressources avec Azure Resource Manager.