Anonieme leestoegang tot blobgegevens herstellen (Azure Resource Manager-implementaties)
Azure Blob Storage ondersteunt optionele anonieme leestoegang tot containers en blobs. Anonieme toegang kan echter een beveiligingsrisico vormen. We raden u aan anonieme toegang uit te schakelen voor optimale beveiliging. Het ongedaan maken van anonieme toegang helpt om schendingen van gegevens te voorkomen die worden veroorzaakt door ongewenste anonieme toegang.
Anonieme toegang tot uw blobgegevens is standaard altijd verboden. De standaardconfiguratie voor een Azure Resource Manager-opslagaccount verbiedt gebruikers anonieme toegang tot containers en blobs in een opslagaccount te configureren. Deze standaardconfiguratie staat alle anonieme toegang tot een Azure Resource Manager-opslagaccount niet toe, ongeacht de toegangsinstelling voor een afzonderlijke container.
Wanneer anonieme toegang voor het opslagaccount niet is toegestaan, weigert Azure Storage alle anonieme leesaanvragen voor blobgegevens. Gebruikers kunnen later geen anonieme toegang configureren voor containers in dat account. Containers die al zijn geconfigureerd voor anonieme toegang, accepteren geen anonieme aanvragen meer.
Waarschuwing
Wanneer een container is geconfigureerd voor anonieme toegang, kan elke client gegevens in die container lezen. Anonieme toegang vormt een mogelijk beveiligingsrisico, dus als uw scenario dit niet vereist, raden we u aan dit niet toe te laten voor het opslagaccount.
Herstel voor Azure Resource Manager versus klassieke opslagaccounts
In dit artikel wordt beschreven hoe u een DRAG-framework (Detection-Remediation-Audit-Governance) gebruikt om continu anonieme toegang te beheren voor opslagaccounts die gebruikmaken van het Azure Resource Manager-implementatiemodel. Alle v2-opslagaccounts voor algemeen gebruik, premium blok-blobopslagaccounts, Premium-bestandsshareaccounts en Blob Storage-accounts maken gebruik van het Azure Resource Manager-implementatiemodel. Sommige oudere v1-accounts voor algemeen gebruik en premium-pagina-blobaccounts kunnen gebruikmaken van het klassieke implementatiemodel.
Als uw opslagaccount gebruikmaakt van het klassieke implementatiemodel, raden we u aan om zo snel mogelijk naar het Azure Resource Manager-implementatiemodel te migreren. Azure Storage-accounts die gebruikmaken van het klassieke implementatiemodel, worden op 31 augustus 2024 buiten gebruik gesteld. Zie klassieke Azure-opslagaccounts worden op 31 augustus 2024 buiten gebruik gesteld voor meer informatie.
Als u uw klassieke opslagaccounts op dit moment niet kunt migreren, moet u nu anonieme toegang tot deze accounts herstellen. Zie Anonieme leestoegang tot blobgegevens herstellen (klassieke implementaties) voor meer informatie over het herstellen van anonieme toegang tot klassieke opslagaccounts. Zie Resource Manager en klassieke implementatie voor meer informatie over Azure-implementatiemodellen.
Over anonieme leestoegang
Anonieme toegang tot uw gegevens is altijd standaard verboden. Er zijn twee afzonderlijke instellingen die van invloed zijn op anonieme toegang:
Instelling voor anonieme toegang voor het opslagaccount. Een Azure Resource Manager-opslagaccount biedt een instelling om anonieme toegang voor het account toe te staan of te weigeren. Microsoft raadt aan om anonieme toegang voor uw opslagaccounts niet toe tewijsen voor optimale beveiliging.
Wanneer anonieme toegang is toegestaan op accountniveau, zijn blobgegevens niet beschikbaar voor anonieme leestoegang, tenzij de gebruiker de extra stap neemt om de instelling voor anonieme toegang van de container expliciet te configureren.
Configureer de instelling voor anonieme toegang van de container. De instelling voor anonieme toegang van een container is standaard uitgeschakeld, wat betekent dat autorisatie vereist is voor elke aanvraag voor de container of de bijbehorende gegevens. Een gebruiker met de juiste machtigingen kan de instelling voor anonieme toegang van een container wijzigen om anonieme toegang alleen in te schakelen als anonieme toegang is toegestaan voor het opslagaccount.
De volgende tabel geeft een overzicht van de invloed van de twee instellingen op anonieme toegang voor een container.
| Anoniem toegangsniveau voor de container is ingesteld op Privé (standaardinstelling) | Anoniem toegangsniveau voor de container is ingesteld op Container | Anoniem toegangsniveau voor de container is ingesteld op Blob | |
|---|---|---|---|
| Anonieme toegang is niet toegestaan voor het opslagaccount | Geen anonieme toegang tot een container in het opslagaccount. | Geen anonieme toegang tot een container in het opslagaccount. De instelling van het opslagaccount overschrijft de containerinstelling. | Geen anonieme toegang tot een container in het opslagaccount. De instelling van het opslagaccount overschrijft de containerinstelling. |
| Anonieme toegang is toegestaan voor het opslagaccount | Geen anonieme toegang tot deze container (standaardconfiguratie). | Anonieme toegang is toegestaan voor deze container en de bijbehorende blobs. | Anonieme toegang is toegestaan voor blobs in deze container, maar niet voor de container zelf. |
Wanneer anonieme toegang is toegestaan voor een opslagaccount en is geconfigureerd voor een specifieke container, wordt een aanvraag om een blob in die container te lezen die wordt doorgegeven zonder Authorization header geaccepteerd door de service en worden de gegevens van de blob geretourneerd in het antwoord. Als de aanvraag echter wordt doorgegeven met een Authorization header, wordt anonieme toegang voor het opslagaccount genegeerd en wordt de aanvraag geautoriseerd op basis van de opgegeven referenties.
Anonieme aanvragen van clienttoepassingen detecteren
Wanneer u anonieme leestoegang voor een opslagaccount weigert, loopt u het risico dat aanvragen voor containers en blobs worden geweigerd die momenteel zijn geconfigureerd voor anonieme toegang. Als u anonieme toegang voor een opslagaccount niet toewijst, worden de toegangsinstellingen voor afzonderlijke containers in dat opslagaccount overschreven. Wanneer anonieme toegang niet is toegestaan voor het opslagaccount, mislukken toekomstige anonieme aanvragen voor dat account.
Om te begrijpen hoe het ongedaan maken van anonieme toegang van invloed kan zijn op clienttoepassingen, raden we u aan om logboekregistratie en metrische gegevens voor dat account in te schakelen en patronen van anonieme aanvragen gedurende een bepaalde periode te analyseren. Gebruik metrische gegevens om het aantal anonieme aanvragen voor het opslagaccount te bepalen en gebruik logboeken om te bepalen welke containers anoniem worden geopend.
Anonieme aanvragen bewaken met Metrics Explorer
Als u anonieme aanvragen voor een opslagaccount wilt bijhouden, gebruikt u Azure Metrics Explorer in Azure Portal. Zie Metrische gegevens analyseren met Azure Monitor Metrics Explorer voor meer informatie over Metrics Explorer.
Volg deze stappen om een metrische waarde te maken waarmee anonieme aanvragen worden bijgehouden:
Ga in het Navigeer naar uw opslagaccount in de Azure-portal. Selecteer de optie Metrische gegevens in de sectie Monitoring.
Selecteer Metrische gegevens toevoegen. Geef in het dialoogvenster Metrische gegevens de volgende waarden op:
- Laat het veld Bereik ingesteld op de naam van het opslagaccount.
- Stel de metrische naamruimte in op Blob. Deze metrische gegevens melden alleen aanvragen voor Blob Storage.
- Stel het veld Metrische waarde in op Transacties.
- Stel het veld Aggregatie in op Som.
De nieuwe metrische waarde geeft de som weer van het aantal transacties ten opzichte van Blob Storage gedurende een bepaald tijdsinterval. De resulterende metrische waarde wordt weergegeven zoals wordt weergegeven in de volgende afbeelding:
Selecteer vervolgens de knop Filter toevoegen om een filter te maken voor de metrische waarde anonieme aanvragen.
Geef in het dialoogvenster Filter de volgende waarden op:
- Stel de eigenschapswaarde in op Verificatie.
- Stel het veld Operator in op het gelijkteken (=).
- Stel het veld Waarden in op Anoniem door het te selecteren in de vervolgkeuzelijst of in te typen.
Selecteer in de rechterbovenhoek het tijdsinterval waarvoor u de metrische waarde wilt weergeven. U kunt ook aangeven hoe gedetailleerd de aggregatie van aanvragen moet zijn door intervallen op te geven tussen 1 minuut en 1 maand.
Nadat u de metrische gegevens hebt geconfigureerd, worden anonieme aanvragen weergegeven in de grafiek. In de volgende afbeelding ziet u anonieme aanvragen die in de afgelopen 30 minuten zijn samengevoegd.
U kunt ook een waarschuwingsregel configureren om u op de hoogte te stellen wanneer een bepaald aantal anonieme aanvragen wordt gedaan voor uw opslagaccount. Zie Waarschuwingen voor metrische gegevens maken, weergeven en beheren met behulp van Azure Monitor voor meer informatie.
Logboeken analyseren om containers te identificeren die anonieme aanvragen ontvangen
Azure Storage-logboeken leggen details vast over aanvragen die zijn gedaan voor het opslagaccount, inclusief hoe een aanvraag is geautoriseerd. U kunt de logboeken analyseren om te bepalen welke containers anonieme aanvragen ontvangen.
Als u aanvragen wilt registreren bij uw Azure Storage-account om anonieme aanvragen te evalueren, kunt u Azure Storage-logboekregistratie in Azure Monitor gebruiken. Zie Azure Storage bewaken voor meer informatie.
Logboekregistratie van Azure Storage in Azure Monitor ondersteunt het gebruik van logboekquery's om logboekgegevens te analyseren. Als u logboeken wilt opvragen, kunt u een Azure Log Analytics-werkruimte gebruiken. Zie Zelfstudie: Aan de slag met Log Analytics-query's voor meer informatie over logboekquery's.
Een diagnostische instelling maken in Azure Portal
Als u Azure Storage-gegevens wilt registreren met Azure Monitor en deze wilt analyseren met Azure Log Analytics, moet u eerst een diagnostische instelling maken die aangeeft welke typen aanvragen en voor welke opslagservices u gegevens wilt vastleggen. Nadat u logboekregistratie voor uw opslagaccount hebt geconfigureerd, zijn de logboeken beschikbaar in de Log Analytics-werkruimte. Zie Een Log Analytics-werkruimte maken in Azure Portal om een werkruimte te maken.
Zie Diagnostische instellingen maken in Azure Monitor voor meer informatie over het maken van een diagnostische instelling in Azure Portal.
Zie Resourcelogboeken voor een verwijzing naar velden die beschikbaar zijn in Azure Storage-logboeken in Azure Monitor.
Query's uitvoeren op logboeken voor anonieme aanvragen
Azure Storage-logboeken in Azure Monitor bevatten het type autorisatie dat is gebruikt voor het indienen van een aanvraag bij een opslagaccount. Filter in uw logboekquery op de eigenschap AuthenticationType om anonieme aanvragen weer te geven.
Als u logboeken voor de afgelopen zeven dagen voor anonieme aanvragen voor Blob Storage wilt ophalen, opent u uw Log Analytics-werkruimte. Plak vervolgens de volgende query in een nieuwe logboekquery en voer deze uit:
StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri
U kunt ook een waarschuwingsregel configureren op basis van deze query om u op de hoogte te stellen van anonieme aanvragen. Zie Logboekwaarschuwingen maken, weergeven en beheren met Behulp van Azure Monitor voor meer informatie.
Antwoorden op anonieme aanvragen
Wanneer Blob Storage een anonieme aanvraag ontvangt, slaagt die aanvraag als aan alle volgende voorwaarden wordt voldaan:
- Anonieme toegang is toegestaan voor het opslagaccount.
- De doelcontainer is geconfigureerd om anonieme toegang toe te staan.
- De aanvraag is voor leestoegang.
Als een van deze voorwaarden niet waar is, mislukt de aanvraag. De antwoordcode op fout is afhankelijk van of de anonieme aanvraag is gedaan met een versie van de service die ondersteuning biedt voor de bearer-uitdaging. De bearer-uitdaging wordt ondersteund met serviceversies 2019-12-12 en hoger:
- Als de anonieme aanvraag is gedaan met een serviceversie die ondersteuning biedt voor de bearer-uitdaging, retourneert de service foutcode 401 (Niet geautoriseerd).
- Als de anonieme aanvraag is gedaan met een serviceversie die de bearer-uitdaging niet ondersteunt en anonieme toegang niet is toegestaan voor het opslagaccount, retourneert de service foutcode 409 (Conflict).
- Als de anonieme aanvraag is gedaan met een serviceversie die de bearer-uitdaging niet ondersteunt en anonieme toegang is toegestaan voor het opslagaccount, retourneert de service foutcode 404 (Niet gevonden).
Zie Bearer-uitdaging voor meer informatie over de bearer-uitdaging.
Anonieme toegang voor het opslagaccount herstellen
Nadat u anonieme aanvragen voor containers en blobs in uw opslagaccount hebt geëvalueerd, kunt u actie ondernemen om anonieme toegang voor het hele account te herstellen door de eigenschap AllowBlobPublicAccess van het account in te stellen op False.
De instelling voor anonieme toegang voor een opslagaccount overschrijft de afzonderlijke instellingen voor containers in dat account. Wanneer u anonieme toegang voor een opslagaccount niet toestaat, zijn containers die zijn geconfigureerd om anonieme toegang toe te staan niet meer anoniem toegankelijk. Als u anonieme toegang voor het account niet wilt toestaan, hoeft u geen anonieme toegang voor afzonderlijke containers uit te schakelen.
Als uw scenario vereist dat bepaalde containers beschikbaar moeten zijn voor anonieme toegang, moet u deze containers en hun blobs verplaatsen naar afzonderlijke opslagaccounts die zijn gereserveerd voor anonieme toegang. Vervolgens kunt u anonieme toegang voor andere opslagaccounts niet toestaan.
Voor het herstellen van anonieme toegang is versie 2019-04-01 of hoger van de Azure Storage-resourceprovider vereist. Zie de REST API van Azure Storage-resourceprovider voor meer informatie.
Machtigingen voor het ongedaan maken van anonieme toegang
Als u de eigenschap AllowBlobPublicAccess voor het opslagaccount wilt instellen, moet een gebruiker gemachtigd zijn om opslagaccounts te maken en te beheren. Rollen voor op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) die deze machtigingen bieden, omvatten de actie Microsoft.Storage/storageAccounts/write . Ingebouwde rollen met deze actie zijn onder andere:
- De rol Eigenaar voor Azure Resource Managers
- De rol Inzender voor Azure Resource Managers
- De rol Eigenaar in het opslagaccount
Roltoewijzingen moeten worden toegewezen aan het niveau van het opslagaccount of hoger, zodat een gebruiker anonieme toegang voor het opslagaccount niet toestaat. Zie Bereik begrijpen voor Azure RBAC voor meer informatie over rolbereik.
Wees voorzichtig met het beperken van de toewijzing van deze rollen aan gebruikers met beheerdersrechten die de mogelijkheid nodig hebben om een opslagaccount te maken of de eigenschappen ervan bij te werken. Gebruik het principe van minimale bevoegdheden om ervoor te zorgen dat gebruikers de minste machtigingen hebben die ze nodig hebben om hun taken uit te voeren. Zie Best practices voor Azure RBAC voor meer informatie over het beheren van toegang met Azure RBAC.
Deze rollen bieden geen toegang tot gegevens in een opslagaccount via Microsoft Entra-id. Ze bevatten echter de Microsoft.Storage/storageAccounts/listkeys/action, die toegang verleent tot de accounttoegangssleutels. Met deze machtiging kan een gebruiker de toegangssleutels voor het account gebruiken om toegang te krijgen tot alle gegevens in een opslagaccount.
De Microsoft.Storage/storageAccounts/listkeys/action zelf verleent gegevenstoegang via de accountsleutels, maar verleent een gebruiker niet de mogelijkheid om de eigenschap AllowBlobPublicAccess voor een opslagaccount te wijzigen. Voor gebruikers die toegang nodig hebben tot gegevens in uw opslagaccount, maar niet de mogelijkheid hebben om de configuratie van het opslagaccount te wijzigen, kunt u overwegen rollen toe te wijzen, zoals Inzender voor opslagblobgegevens, Opslagblobgegevenslezer of Lezer en Gegevenstoegang.
Notitie
De klassieke abonnementsbeheerdersrollen Servicebeheerder en Medebeheerder bevatten het equivalent van de rol Azure Resource Manager-eigenaar. De rol Eigenaar bevat alle acties, zodat een gebruiker met een van deze beheerdersrollen ook opslagaccounts kan maken en accountconfiguratie kan beheren. Zie Azure-rollen, Microsoft Entra-rollen en klassieke abonnementsbeheerdersrollen voor meer informatie.
De eigenschap AllowBlobPublicAccess van het opslagaccount instellen op False
Als u anonieme toegang voor een opslagaccount wilt weigeren, stelt u de eigenschap AllowBlobPublicAccess van het account in op False.
Belangrijk
Als u anonieme toegang voor een opslagaccount niet toewijst, worden de toegangsinstellingen voor alle containers in dat opslagaccount overschreven. Wanneer anonieme toegang niet is toegestaan voor het opslagaccount, mislukken toekomstige anonieme aanvragen voor dat account. Voordat u deze instelling wijzigt, moet u weten wat de gevolgen zijn voor clienttoepassingen die mogelijk anoniem toegang hebben tot gegevens in uw opslagaccount door de stappen te volgen die worden beschreven in Anonieme aanvragen detecteren van clienttoepassingen.
Als u anonieme toegang voor een opslagaccount in Azure Portal wilt weigeren, voert u de volgende stappen uit:
Ga in het Navigeer naar uw opslagaccount in de Azure-portal.
Zoek de configuratie-instelling onder Instellingen.
Stel Anonieme toegang tot Blob toestaan in op Uitgeschakeld.
Notitie
Het ongedaan maken van anonieme toegang voor een opslagaccount heeft geen invloed op statische websites die in dat opslagaccount worden gehost. De $web-container is altijd openbaar toegankelijk.
Nadat u de instelling voor anonieme toegang voor het opslagaccount hebt bijgewerkt, kan het tot 30 seconden duren voordat de wijziging volledig wordt doorgegeven.
Voorbeeldscript voor bulkherstel
Het volgende PowerShell-voorbeeldscript wordt uitgevoerd op alle Azure Resource Manager-opslagaccounts in een abonnement en stelt de instelling AllowBlobPublicAccess voor deze accounts in op 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"
}
Controleer de instelling voor anonieme toegang voor meerdere accounts
Als u de instelling voor anonieme toegang in een set opslagaccounts met optimale prestaties wilt controleren, kunt u Azure Resource Graph Explorer gebruiken in Azure Portal. Zie de quickstart: Uw eerste Resource Graph-query uitvoeren met behulp van Azure Resource Graph Explorer voor meer informatie over het gebruik van Resource Graph Explorer.
Als u de volgende query uitvoert in Resource Graph Explorer, wordt een lijst met opslagaccounts geretourneerd en wordt voor elk account anonieme toegangsinstelling weergegeven:
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess
In de volgende afbeelding ziet u de resultaten van een query in een abonnement. Voor opslagaccounts waarin de eigenschap AllowBlobPublicAccess expliciet is ingesteld, wordt deze weergegeven in de resultaten als waar of onwaar. Als de eigenschap AllowBlobPublicAccess niet is ingesteld voor een opslagaccount, wordt deze weergegeven als leeg (of null) in de queryresultaten.
Azure Policy gebruiken om te controleren op naleving
Als u een groot aantal opslagaccounts hebt, kunt u een controle uitvoeren om ervoor te zorgen dat deze accounts zijn geconfigureerd om anonieme toegang te voorkomen. Gebruik Azure Policy om een set opslagaccounts voor hun naleving te controleren. Azure Policy is een service die u kunt gebruiken om beleidsregels te maken, toe te wijzen en te beheren die regels toepassen op Azure-resources. Azure Policy helpt u om deze resources te laten voldoen aan uw bedrijfsstandaarden en serviceovereenkomsten. Zie Overzicht van Azure Policy voor meer informatie.
Een beleid maken met een controle-effect
Azure Policy ondersteunt effecten die bepalen wat er gebeurt wanneer een beleidsregel wordt geëvalueerd op basis van een resource. Met het controle-effect wordt een waarschuwing gemaakt wanneer een resource niet voldoet aan de naleving, maar de aanvraag niet wordt gestopt. Zie Azure Policy-effecten begrijpen voor meer informatie over effecten.
Als u een beleid wilt maken met een controle-effect voor de instelling voor anonieme toegang voor een opslagaccount met Azure Portal, voert u de volgende stappen uit:
Navigeer in de Azure-portal naar de Azure Policy-service.
Selecteer Definities in de sectie Ontwerpen.
Selecteer Beleidsdefinitie toevoegen om een nieuwe beleidsdefinitie te maken.
Selecteer voor het veld Definitielocatie de knop Meer om op te geven waar de resource voor het controlebeleid zich bevindt.
Geef een naam op voor het beleid. U kunt desgewenst een beschrijving en categorie opgeven.
Voeg onder Beleidsregel de volgende beleidsdefinitie toe aan de sectie policyRule .
{ "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "not": { "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "false" } } ] }, "then": { "effect": "audit" } }Sla het beleid op.
Het beleid toewijzen
Wijs vervolgens het beleid toe aan een resource. Het bereik van het beleid komt overeen met die resource en alle onderliggende resources. Zie de structuur van Azure Policy-toewijzingen voor meer informatie over beleidstoewijzing.
Volg deze stappen om het beleid toe te wijzen met Azure Portal:
- Navigeer in de Azure-portal naar de Azure Policy-service.
- Selecteer Opdrachten in de sectie Ontwerpen.
- Selecteer Beleid toewijzen om een nieuwe beleidstoewijzing te maken.
- Selecteer voor het veld Bereik het bereik van de beleidstoewijzing.
- Selecteer voor het veld Beleidsdefinitie de knop Meer en selecteer vervolgens het beleid dat u in de vorige sectie in de lijst hebt gedefinieerd.
- Geef een naam op voor de beleidstoewijzing. De beschrijving is optioneel.
- Laat beleids afdwingen ingesteld op Ingeschakeld. Deze instelling heeft geen invloed op het controlebeleid.
- Selecteer Beoordelen en maken om de opdracht te maken.
Nalevingsrapport weergeven
Nadat u het beleid hebt toegewezen, kunt u het nalevingsrapport bekijken. Het nalevingsrapport voor een controlebeleid bevat informatie over welke opslagaccounts niet voldoen aan het beleid. Zie Nalevingsgegevens voor beleid ophalen voor meer informatie.
Het kan enkele minuten duren voordat het nalevingsrapport beschikbaar is nadat de beleidstoewijzing is gemaakt.
Voer de volgende stappen uit om het nalevingsrapport weer te geven in Azure Portal:
Navigeer in de Azure-portal naar de Azure Policy-service.
Selecteer Naleving.
Filter de resultaten voor de naam van de beleidstoewijzing die u in de vorige stap hebt gemaakt. In het rapport ziet u hoeveel resources niet voldoen aan het beleid.
U kunt inzoomen op het rapport voor meer informatie, waaronder een lijst met opslagaccounts die niet in overeenstemming zijn.
Azure Policy gebruiken om geautoriseerde toegang af te dwingen
Azure Policy ondersteunt cloudgovernance door ervoor te zorgen dat Azure-resources voldoen aan vereisten en standaarden. Om ervoor te zorgen dat opslagaccounts in uw organisatie alleen geautoriseerde aanvragen toestaat, kunt u een beleid maken dat voorkomt dat een nieuw opslagaccount wordt gemaakt met een instelling voor anonieme toegang waarmee anonieme aanvragen worden toegestaan. Dit beleid voorkomt ook dat alle configuratiewijzigingen in een bestaand account worden gewijzigd als de instelling voor anonieme toegang voor dat account niet aan het beleid voldoet.
Het afdwingingsbeleid gebruikt het effect Weigeren om te voorkomen dat een aanvraag waarmee een opslagaccount wordt gemaakt of gewijzigd om anonieme toegang toe te staan. Zie Azure Policy-effecten begrijpen voor meer informatie over effecten.
Als u een beleid wilt maken met het effect Weigeren voor een instelling voor anonieme toegang die anonieme aanvragen toestaat, volgt u dezelfde stappen die worden beschreven in Azure Policy gebruiken om te controleren op naleving, maar geeft u de volgende JSON op in de sectie policyRule van de beleidsdefinitie:
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "deny"
}
}
Nadat u het beleid met het effect Weigeren hebt gemaakt en dit hebt toegewezen aan een bereik, kan een gebruiker geen opslagaccount maken dat anonieme toegang toestaat. Een gebruiker kan geen configuratiewijzigingen aanbrengen in een bestaand opslagaccount dat momenteel anonieme toegang toestaat. Als u dit probeert, treedt er een fout op. De instelling voor anonieme toegang voor het opslagaccount moet zijn ingesteld op false om door te gaan met het maken of configureren van het account.
In de volgende afbeelding ziet u de fout die optreedt als u probeert een opslagaccount te maken dat anonieme toegang toestaat wanneer een beleid met een weigeringseffect vereist dat anonieme toegang niet is toegestaan.
