Corriger l’accès en lecture anonyme aux données blob (déploiements Azure Resource Manager)
Stockage Blob Azure prend en charge l’accès en lecture anonyme facultatif aux conteneurs et objets blob. Toutefois, un accès anonyme peut représenter un risque de sécurité. Nous vous recommandons de désactiver l’accès anonyme à des fins de sécurité optimale. L’interdiction de l’accès anonyme permet d’éviter les violations de données causées par un accès anonyme indésirable.
Par défaut, l’accès anonyme à vos données de blob est toujours interdit. La configuration par défaut d’un compte de stockage Azure Resource Manager empêche les utilisateurs de configurer l’accès anonyme aux conteneurs et aux objets blob dans un compte de stockage. Cette configuration par défaut interdit tout accès anonyme à un compte de stockage Azure Resource Manager, quel que soit le paramètre d’accès d’un conteneur individuel.
Lorsque l’accès anonyme pour le compte de stockage n’est pas autorisé, le stockage Azure rejette toutes les demandes de lecture anonymes sur les données d’objet blob. Les utilisateurs ne peuvent pas configurer ultérieurement l’accès anonyme pour les conteneurs de ce compte. Les conteneurs qui ont déjà été configurés pour un accès anonyme n’acceptent plus les requêtes anonymes.
Avertissement
Lorsqu’un conteneur est configuré pour un accès anonyme, n’importe quel client peut lire les données de ce conteneur. L’accès anonyme présente un risque de sécurité potentiel. Ainsi, si votre scénario ne le nécessite pas, nous vous recommandons de l’interdire pour le compte de stockage.
Résolution des problèmes affectant Azure Resource Manager et les comptes de stockage classiques
Cet article explique comment utiliser une infrastructure DRAG (Detection-Remediation-Audit-Governance) pour gérer en permanence l’accès anonyme pour les comptes de stockage qui utilisent le modèle de déploiement Azure Resource Manager. Tous les comptes de stockage v2 à usage général, les comptes de stockage d’objets blob de blocs Premium, les comptes de partage de fichiers Premium et les comptes de stockage d’objet blob utilisent le modèle de déploiement Azure Resource Manager. Certains anciens comptes v1 à usage général et comptes d’objets blob de pages Premium peuvent utiliser le modèle de déploiement classique.
Si votre compte de stockage utilise le modèle de déploiement classique, nous vous recommandons de migrer vers le modèle de déploiement Azure Resource Manager dès que possible. Les comptes de stockage Azure qui utilisent le modèle de déploiement classique seront mis hors service le 31 août 2024. Pour plus d’informations, consultez les comptes de stockage Azure Classic mis hors service le 31 août 2024.
Si vous ne pouvez pas migrer vos comptes de stockage classiques pour le moment, vous devez corriger l’accès anonyme à ces comptes dès maintenant. Pour savoir comment corriger l’accès anonyme pour les comptes de stockage classiques, consultez Corriger l’accès en lecture anonyme aux données blob (déploiements classiques). Pour plus d’informations sur les modèles de déploiement Azure, consultez Déploiement Resource Manager et déploiement classique.
À propos de l’accès en lecture anonyme
L’accès anonyme à vos données est toujours interdit par défaut. Il existe deux paramètres distincts qui affectent l’accès anonyme :
Paramètres d’accès anonyme pour le compte de stockage. Un compte de stockage Azure Resource Manager offre un paramètre permettant d’autoriser ou de interdire l’accès anonyme pour le compte. Microsoft recommande de refuser l’accès anonyme pour vos comptes de stockage pour une sécurité optimale.
Lorsque l’accès anonyme est autorisé au niveau du compte, les données d’objet blob ne sont pas disponibles pour l’accès en lecture anonyme, sauf si l’utilisateur effectue l’étape supplémentaire pour configurer explicitement le paramètre d’accès anonyme du conteneur.
Configurez le paramètre d’accès anonyme du conteneur. Par défaut, le paramètre d’accès anonyme d’un conteneur est désactivé, ce qui signifie que l’autorisation est nécessaire pour chaque requête adressée au conteneur ou à ses données. Un utilisateur disposant des autorisations appropriées peut modifier le paramètre d’accès anonyme d’un conteneur afin de l’activer uniquement si ce dernier est autorisé pour le compte de stockage.
Le tableau suivant résume la façon dont les deux paramètres affectent ensemble l’accès anonyme pour un conteneur.
| Le niveau d’accès anonyme du conteneur est défini sur Privé (valeur par défaut) | Le niveau d’accès anonyme du conteneur est défini sur Conteneur | Le niveau d’accès anonyme du conteneur est défini sur l’objet Blob | |
|---|---|---|---|
| L’accès anonyme n’est pas autorisé pour le compte de stockage | Aucun accès anonyme à un conteneur dans le compte de stockage. | Aucun accès anonyme à un conteneur dans le compte de stockage. Le paramètre de compte de stockage remplace le paramètre de conteneur. | Aucun accès anonyme à un conteneur dans le compte de stockage. Le paramètre de compte de stockage remplace le paramètre de conteneur. |
| L’accès anonyme est autorisé pour le compte de stockage | Aucun accès anonyme à ce conteneur (configuration par défaut). | L’accès anonyme est autorisé à ce conteneur et à ses objets blob. | L’accès anonyme est autorisé aux objets blob dans ce conteneur, mais pas au conteneur lui-même. |
Quand l’accès anonyme est autorisé pour un compte de stockage et configuré pour un conteneur spécifique, une demande de lecture d’un objet blob dans ce conteneur qui est passée sans en-tête Authorization est acceptée par le service, puis les données de l’objet blob sont retournées dans la réponse. Toutefois, si la demande est passée avec un en-tête Authorization, l’accès anonyme sur le compte de stockage est ignoré et la demande est autorisée en fonction des informations d’identification fournies.
Détecter les demandes anonymes des applications clientes
Lorsque vous interdisez l’accès en lecture anonyme pour un compte de stockage, vous risquez de rejeter les requêtes à destination des conteneurs et des blobs qui sont configurés pour l’accès anonyme. L’interdiction de l’accès anonyme pour un compte de stockage prévaut sur les paramètres d’accès anonyme pour les conteneurs individuels de ce compte de stockage. Lorsque l’accès anonyme est interdit pour le compte de stockage, toute requête anonyme ultérieure adressée à ce compte échoue.
Pour que vous compreniez dans quelle mesure l’interdiction de l’accès anonyme peut influer sur les applications clientes, nous recommandons d’activer la journalisation et les métriques pour ce compte et d’analyser les modèles de requêtes anonymes sur un intervalle de temps. Utilisez des métriques pour déterminer le nombre de demandes anonymes adressées au compte de stockage et utilisez les journaux pour déterminer les conteneurs qui sont accessibles de façon anonyme.
Superviser les demandes anonymes avec Metrics Explorer
Pour effectuer le suivi des demandes anonymes adressées à un compte de stockage, utilisez Azure Metrics Explorer dans le portail Azure. Pour plus d’informations sur Metrics Explorer, consultez Analyser les métriques avec l’Explorateur de métriques Azure Monitor.
Suivez ces étapes pour créer une métrique qui effectue le suivi des requêtes anonymes :
Accédez à votre compte de stockage dans le portail Azure. Dans la section Supervision, sélectionnez Métriques.
Sélectionnez Ajouter une métrique. Dans la boîte de dialogue Métrique, spécifiez les valeurs suivantes :
- Laissez le champ Étendue défini sur le nom du compte de stockage.
- Définissez l’Espace de noms de métrique sur Blob. Cette métrique ne porte que sur les demandes à destination du stockage Blob.
- Définissez le champ Métrique sur Transactions.
- Définissez le champ Agrégation sur Somme.
La nouvelle métrique affiche la somme du nombre de transactions sur le stockage Blob sur un intervalle de temps donné. La métrique qui en résulte s’affiche comme indiqué dans l’image suivante :
Ensuite, sélectionnez le bouton Ajouter un filtre afin de créer un filtre sur la métrique pour les demandes anonymes.
Dans la boîte de dialogue Filtre, spécifiez les valeurs suivantes :
- Définissez la valeur Propriété sur Authentification.
- Affectez au champ Opérateur le signe égal (=).
- Définissez le champ Valeurs sur Anonyme en le sélectionnant dans la liste déroulante ou en saisissant dans celui-ci.
Dans l’angle supérieur droit, sélectionnez l’intervalle de temps sur lequel doit porter la métrique. Vous pouvez également indiquer le degré de précision de l’agrégation des demandes, en spécifiant des intervalles compris entre 1 minute et 1 mois.
Une fois que vous avez configuré la métrique, les demandes anonymes commencent à s’afficher sur le graphique. L’illustration suivante montre les demandes anonymes agrégées au cours des 30 dernières minutes.
Vous pouvez également configurer une règle d’alerte pour vous avertir quand un certain nombre de demandes anonymes sont effectuées sur votre compte de stockage. Pour plus d'informations, consultez Créer, afficher et gérer des alertes de métrique à l'aide d'Azure Monitor.
Analyser les journaux pour identifier les conteneurs recevant des demandes anonymes
Les journaux du stockage Azure capturent des détails sur les demandes effectuées sur le compte de stockage, y compris la manière dont une demande a été autorisée. Vous pouvez analyser les journaux pour identifier les conteneurs qui reçoivent des demandes anonymes.
Pour journaliser les demandes dans votre compte de stockage Azure afin d’évaluer les demandes anonymes, vous pouvez utiliser la journalisation du stockage Azure dans Azure Monitor. Pour plus d’informations, consultez Superviser le stockage Azure.
La journalisation du stockage Azure dans Azure Monitor prend en charge l’utilisation de requêtes de journal pour analyser les données des journaux. Pour interroger les journaux, vous pouvez utiliser un espace de travail Azure Log Analytics. Pour en savoir plus sur les requêtes de journal, consultez Tutoriel : Bien démarrer avec les requêtes Log Analytics.
Créer un paramètre de diagnostic dans le portail Azure
Pour journaliser des données de stockage Azure avec Azure Monitor et les analyser avec Azure Log Analytics, vous devez d’abord créer un paramètre de diagnostic qui indique les types de demandes et les services de stockage pour lesquels vous souhaitez journaliser les données. Après avoir configuré la journalisation pour votre compte de stockage, les journaux sont disponibles dans l’espace de travail Log Analytics. Pour créer un espace de travail, consultez Créer un espace de travail Log Analytics dans le Portail Azure.
Pour savoir comment créer un paramètre de diagnostic sur le Portail Azure, consultez Créer des paramètres de diagnostic dans Azure Monitor.
Pour obtenir des informations de référence sur les champs disponibles dans les journaux de stockage Azure dans Azure Monitor, consultez Journaux de ressource.
Interroger les journaux pour rechercher les demandes anonymes
Les journaux de stockage Azure dans Azure Monitor incluent le type d’autorisation qui a été utilisé pour effectuer une demande à destination d’un compte de stockage. Dans votre requête de journal, filtrez sur la propriété AuthenticationType pour afficher les demandes anonymes.
Pour récupérer les journaux des sept derniers jours pour les demandes anonymes sur le stockage Blob, ouvrez votre espace de travail Log Analytics. Collez ensuite la requête suivante dans une nouvelle requête de journal et exécutez-la :
StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri
Vous pouvez également configurer une règle d’alerte basée sur cette requête pour vous avertir des demandes anonymes. Pour plus d’informations, consultez Créer, afficher et gérer des alertes de journal à l’aide d’Azure Monitor.
Réponses aux demandes anonymes
Lorsque le stockage Blob reçoit une demande anonyme, cette demande réussit si toutes les conditions suivantes sont remplies :
- L’accès anonyme est autorisé pour le compte de stockage.
- Le conteneur ciblé est configuré pour autoriser l’accès anonyme.
- La demande concerne l’accès en lecture.
Si l’une de ces conditions n’est pas vraie, la demande échoue. Le code de réponse en cas d’échec dépend si la demande anonyme a été effectuée avec une version du service qui prend en charge la demande du porteur. La demande du porteur est prise en charge avec les versions de service 2019-12-12 et ultérieures :
- Si la demande anonyme a été effectuée avec une version de service qui prend en charge la demande du porteur, le service retourne le code d’erreur 401 (Non autorisé).
- Si la demande anonyme a été effectuée avec une version de service qui ne prend pas en charge la demande du porteur et que l’accès anonyme est interdit pour le compte de stockage, le service retourne le code d’erreur 409 (conflit).
- Si la demande anonyme a été effectuée avec une version de service qui ne prend pas en charge la demande du porteur et que l’accès anonyme est autorisé pour le compte de stockage, le service retourne le code d’erreur 404 (Introuvable).
Pour plus d’informations sur la demande du porteur, consultez Demande du porteur.
Corriger l’accès anonyme pour le compte de stockage
Après avoir évalué les demandes anonymes adressées aux conteneurs et aux objets blob dans votre compte de stockage, vous pouvez prendre des mesures pour corriger l’accès anonyme pour l’ensemble du compte en définissant la propriété AllowBlobPublicAccess du compte sur False.
Le paramètre d’accès anonyme pour un compte de stockage remplace les paramètres individuels des conteneurs dans ce compte. Lorsque vous interdisez l’accès anonyme pour un compte de stockage, tous les conteneurs qui sont configurés pour autoriser l’accès anonyme ne sont plus accessibles de façon anonyme. Si vous interdisez l’accès anonyme au compte, vous n’avez pas besoin de désactiver l’accès anonyme pour les conteneurs individuels.
Si votre scénario nécessite que certains conteneurs soient disponibles pour un accès anonyme, vous devez donc déplacer ces conteneurs et leurs blobs dans des comptes de stockage réservés à un accès anonyme. Vous pouvez ensuite interdire l’accès anonyme pour tous les autres comptes de stockage.
La résolution des problèmes d’accès anonyme nécessite la version 2019-04-01 ou ultérieure du fournisseur de ressources Stockage Azure. Pour plus d’informations, consultez API REST du fournisseur de ressources Stockage Azure.
Autorisations pour interdire l’accès anonyme
Afin de définir la propriété AllowBlobPublicAccess pour le compte de stockage, un utilisateur doit disposer des autorisations nécessaires pour créer et gérer des comptes de stockage. Les rôles Azure RBAC (contrôle d’accès en fonction du rôle Azure) qui fournissent ces autorisations comprennent l’action Microsoft.Storage/storageAccounts/write. Parmi les rôles intégrés comportant cette action figurent :
- Le rôle Propriétaire d’Azure Resource Manager
- Le rôle Contributeur d’Azure Resource Manager
- Le rôle Contributeur de compte de stockage
Les attributions de rôles doivent être définies au niveau du compte de stockage ou à un niveau supérieur pour permettre à un utilisateur d’interdire l’accès anonyme au compte de stockage. Pour plus d’informations sur l’étendue des rôles, consultez Comprendre l’étendue pour Azure RBAC.
Veillez à limiter l’attribution de ces rôles aux seuls utilisateurs administratifs qui ont besoin de créer un compte de stockage ou de mettre à jour ses propriétés. Appliquez le principe des privilèges minimum pour que les utilisateurs disposent des autorisations nécessaires les plus faibles possibles pour accomplir leurs tâches. Pour plus d’informations sur la gestion de l’accès avec Azure RBAC, consultez Meilleures pratiques pour Azure RBAC.
Ces rôles ne fournissent pas d’accès aux données d’un compte de stockage via Microsoft Entra ID. Toutefois, ils incluent l’action Microsoft.Storage/storageAccounts/listkeys/action, qui accorde l’accès aux clés d’accès du compte. Avec cette autorisation, un utilisateur peut utiliser les clés d’accès du compte pour accéder à toutes les données d’un compte de stockage.
Microsoft.Storage/storageAccounts/listkeys/action accorde l’accès aux données par le biais des clés de compte, mais n’accorde pas à un utilisateur la possibilité de modifier la propriété AllowBlobPublicAccess d’un compte de stockage. Pour les utilisateurs qui ont besoin d’accéder aux données de votre compte de stockage, mais qui ne doivent pas avoir la possibilité de modifier la configuration du compte de stockage, envisagez d’attribuer des rôles comme Contributeur aux données blob du stockage, Lecteur des données blob du stockage ou Lecteur et accès aux données.
Notes
Les rôles d’administrateur d’abonnement classique Administrateur de service et Co-administrateur incluent l’équivalent du rôle Propriétaire d’Azure Resource Manager. Le rôle Propriétaire comprend toutes les actions. Par conséquent, un utilisateur disposant de l’un de ces rôles administratif peut également créer des comptes de stockage et gérer la configuration des comptes. Pour plus d’informations, consultez Rôles Azure, rôles Microsoft Entra et rôles d’administrateur d’abonnements classiques.
Définir la propriété AllowBlobPublicAccess du compte de stockage sur False
Pour interdire l’accès anonyme pour un compte de stockage, définissez la propriété AllowBlobPublicAccess du compte sur False.
Important
L’interdiction de l’accès anonyme pour un compte de stockage remplace les paramètres d’accès public pour tous les conteneurs appartenant à ce compte de stockage. Lorsque l’accès anonyme est interdit pour le compte de stockage, toute requête anonyme ultérieure adressée à ce compte échoue. Avant de modifier ce paramètre, veillez à comprendre l’impact sur les applications clientes qui peuvent accéder aux données de votre compte de stockage de manière anonyme en suivant les étapes décrites dans Détecter les demandes anonymes des applications clientes.
Pour interdire l’accès anonyme à un compte de stockage dans le portail Azure, procédez comme suit :
Accédez à votre compte de stockage dans le portail Azure.
Localisez le paramètre Configuration sous Paramètres.
Définissez Autoriser l’accès anonyme blob sur Désactivé.
Remarque
L’interdiction de l’accès anonyme à un compte de stockage n’affecte aucun site web statique hébergé dans ce compte de stockage. Le conteneur $web est toujours accessible publiquement.
Après la mise à jour du paramètre d’accès anonyme pour le compte de stockage, la propagation de la modification peut prendre jusqu’à 30 secondes.
Exemple de script pour une correction en bloc
L’exemple de script PowerShell suivant s’exécute sur tous les comptes de stockage Azure Resource Manager d’un abonnement et définit le paramètre AllowBlobPublicAccess pour ces comptes sur False.
<#
.SYNOPSIS
Finds storage accounts in a subscription where AllowBlobPublicAccess is True or null.
.DESCRIPTION
This script runs against all Azure Resource Manager storage accounts in a subscription
and sets the "AllowBlobPublicAccess" property to False.
Standard operation will enumerate all accounts where the setting is enabled and allow the
user to decide whether or not to disable the setting.
Classic storage accounts will require individual adjustment of containers to remove public
access, and will not be affected by this script.
Run with BypassConfirmation=$true if you wish to disallow public access on all Azure Resource Manager
storage accounts without individual confirmation.
You will need access to the subscription to run the script.
.PARAMETER BypassConformation
Set this to $true to skip confirmation of changes. Not recommended.
.PARAMETER SubscriptionId
The subscription ID of the subscription to check.
.PARAMETER ReadOnly
Set this parameter so that the script makes no changes to any subscriptions and only reports affect accounts.
.PARAMETER NoSignin
Set this parameter so that no sign-in occurs -- you must sign in first. Use this if you're invoking this script repeatedly for multiple subscriptions and want to avoid being prompted to sign-in for each subscription.
.OUTPUTS
This command produces only STDOUT output (not standard PowerShell) with information about affect accounts.
#>
param(
[boolean]$BypassConfirmation = $false,
[Parameter(Mandatory = $true, ValueFromPipelineByPropertyName = 'SubscriptionId')]
[String] $SubscriptionId,
[switch] $ReadOnly, # Use this if you don't want to make changes, but want to get information about affected accounts
[switch] $NoSignin # Use this if you are already signed in and don't want to be prompted again
)
begin {
if ( ! $NoSignin.IsPresent ) {
Login-AzAccount | Out-Null
}
}
process {
try {
Select-AzSubscription -SubscriptionId $SubscriptionId -ErrorAction Stop | Out-Null
}
catch {
Write-Error "Unable to access select subscription '$SubscriptionId' as the signed in user -- ensure that you have access to this subscription." -ErrorAction Stop
}
foreach ($account in Get-AzStorageAccount) {
if ($null -eq $account.AllowBlobPublicAccess -or $account.AllowBlobPublicAccess -eq $true) {
Write-host "Account:" $account.StorageAccountName " isn't disallowing public access."
if ( ! $ReadOnly.IsPresent ) {
if (!$BypassConfirmation) {
$confirmation = Read-Host "Do you wish to disallow public access? [y/n]"
}
if ($BypassConfirmation -or $confirmation -eq 'y') {
try {
Set-AzStorageAccount -Name $account.StorageAccountName -ResourceGroupName $account.ResourceGroupName -AllowBlobPublicAccess $false
Write-Host "Success!"
}
catch {
Write-Output $_
}
}
}
}
elseif ($account.AllowBlobPublicAccess -eq $false) {
Write-Host "Account:" $account.StorageAccountName "has public access disabled, no action required."
}
else {
Write-Host "Account:" $account.StorageAccountName ". Error, please manually investigate."
}
}
}
end {
Write-Host "Script complete"
}
Vérifier le paramètre d’accès anonyme pour plusieurs comptes
Pour vérifier le paramètre d’accès anonyme d’un ensemble de comptes de stockage avec des performances optimales, vous pouvez utiliser l’Explorateur Azure Resource Graph dans le portail Azure. Pour en savoir plus sur l’utilisation de l’Explorateur Resource Graph, consultez Démarrage rapide : exécuter votre première requête Resource Graph à l’aide de l’Explorateur Azure Resource Graph.
L’exécution de la requête suivante dans l’Explorateur Resource Graph retourne une liste de comptes de stockage et affiche le paramètre d’accès anonyme pour chaque compte :
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess
L’image suivante montre les résultats d’une requête dans un abonnement. Pour les comptes de stockage où la propriété AllowBlobPublicAccess est définie explicitement, celle-ci apparaît dans les résultats comme vraie ou fausse. Si la propriété AllowBlobPublicAccess n’est pas définie pour un compte de stockage, elle apparaît comme vide (ou nulle) dans les résultats de la demande.
Utiliser Azure Policy pour auditer la conformité
Si vous avez un grand nombre de comptes de stockage, vous voudrez peut-être effectuer un audit pour vous assurer que ces comptes sont configurés de manière à empêcher l’accès anonyme. Pour auditer la conformité d’un ensemble de comptes de stockage, utilisez Azure Policy. Azure Policy est un service que vous pouvez utiliser pour créer, attribuer et gérer des stratégies qui appliquent des règles à des ressources Azure. Lorsque vous utilisez Azure Policy, les ressources restent conformes à vos normes d’entreprise et contrats de niveau de service. Pour plus d’informations, consultez Vue d’ensemble d’Azure Policy.
Créer une stratégie avec un effet d’audit
Azure Policy prend en charge les effets qui déterminent ce qui se produit quand une règle de stratégie est évaluée par rapport à une ressource. L’effet d’audit crée un avertissement quand une ressource n’est pas conforme, mais n’arrête pas la requête. Pour plus d’informations, consultez Comprendre les effets d’Azure Policy.
Pour créer une stratégie avec un effet d’audit pour le paramètre d’accès anonyme d’un compte de stockage avec le portail Azure, procédez comme suit :
Dans le Portail Azure, accédez au service Azure Policy.
Dans la section Création, sélectionnez Définitions.
Sélectionnez Ajouter une définition de stratégie pour créer une nouvelle définition de stratégie.
Pour le champ emplacement de la définition, sélectionnez le bouton Autres pour spécifier l’emplacement de la ressource de stratégie d’audit.
Spécifiez un nom pour la stratégie. Vous pouvez éventuellement spécifier une description et une catégorie.
Sous Règle de stratégie, ajoutez la définition de stratégie suivante à la section policyrule.
{ "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "not": { "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "false" } } ] }, "then": { "effect": "audit" } }Enregistrez la stratégie.
Affecter la stratégie
Ensuite, attribuez la stratégie à une ressource. L’étendue de la stratégie correspond à cette ressource et à toutes les ressources qu’elle contient. Pour plus d’informations sur l’attribution de stratégie, consultez Structure d’affectation d’Azure Policy.
Pour attribuer la stratégie avec le portail Azure, procédez comme suit :
- Dans le portail Azure, accédez au service Azure Policy.
- Dans la section Création, sélectionnez Attributions.
- Sélectionnez Attribuer une stratégie pour créer une attribution de stratégie.
- Pour le champ Étendue, sélectionnez l’étendue de l’attribution de stratégie.
- Pour le champ Définition de stratégie, sélectionnez le bouton Autres, puis la stratégie que vous avez définie dans la section précédente dans la liste.
- Entrez un nom pour l’attribution de stratégie. La description est facultative.
- Laissez l’option Application de stratégie définie sur Activée. Ce paramètre n’a aucun effet sur la stratégie d’audit.
- Sélectionnez Vérifier + créer pour créer l’attribution.
Afficher le rapport de conformité
Une fois que vous avez attribué la stratégie, vous pouvez afficher le rapport de conformité. Le rapport de conformité d’une stratégie d’audit fournit des informations sur les comptes de stockage qui ne sont pas conformes à la stratégie. Pour plus d’informations, consultez Obtenir les données de conformité de la stratégie.
La disponibilité du rapport de conformité peut prendre plusieurs minutes après la création de l’attribution de stratégie.
Pour afficher le rapport de conformité dans le Portail Azure, procédez comme suit :
Dans le portail Azure, accédez au service Azure Policy.
Sélectionnez Conformité.
Filtrez les résultats pour le nom de l’attribution de stratégie que vous avez créée à l’étape précédente. Le rapport indique le nombre de ressources qui ne sont pas conformes à la stratégie.
Vous pouvez explorer le rapport pour obtenir des détails supplémentaires, notamment une liste des comptes de stockage qui ne sont pas conformes.
Utiliser Azure Policy pour appliquer l’accès autorisé
Azure Policy prend en charge la gouvernance cloud en s’assurant que les ressources Azure respectent les exigences et les normes. Pour vous assurer que les comptes de stockage de votre organisation autorisent uniquement les requêtes autorisées, vous pouvez créer une stratégie qui empêche la création d’nouveau compte de stockage dont le paramètre d’accès anonyme autorise les requêtes anonymes. Cette stratégie empêchera également toutes les modifications de configuration apportées à un compte existant si le paramètre d’accès anonyme pour ce compte n’est pas conforme à la stratégie.
La stratégie d’application utilise l’effet de refus pour empêcher une requête de créer ou de modifier un compte de stockage pour autoriser l’accès anonyme. Pour plus d’informations, consultez Comprendre les effets d’Azure Policy.
Pour créer une stratégie avec un effet de refus pour un paramètre d’accès anonyme qui autorise les requêtes anonymes, suivez les mêmes étapes décrites dans Utiliser Azure Policy pour auditer la conformité, mais fournissez le fichier JSON suivant dans la section policyRule de la définition de stratégie :
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "deny"
}
}
Une fois que vous avez créé la stratégie avec l’effet de refus et l’avez attribuée à une étendue, un utilisateur ne peut plus créer de compte de stockage qui autorise l’accès anonyme. Un utilisateur ne peut pas non plus apporter des changements de configuration à un compte de stockage existant qui autorise actuellement l’accès anonyme. Toute tentative en ce sens entraîne une erreur. Le paramètre d’accès anonyme pour le compte de stockage doit être défini sur false pour poursuivre la création ou la configuration du compte.
L’image suivante montre l’erreur qui se produit si vous tentez de créer un compte de stockage qui autorise l’accès anonyme lorsqu’une stratégie avec effet de refus exige que l’accès anonyme soit interdit.
