Åtgärda anonym läsåtkomst till blobdata (Azure Resource Manager-distributioner)
Azure Blob Storage stöder valfri anonym läsåtkomst till containrar och blobar. Anonym åtkomst kan dock utgöra en säkerhetsrisk. Vi rekommenderar att du inaktiverar anonym åtkomst för optimal säkerhet. Om du inte tillåter anonym åtkomst kan du förhindra dataintrång som orsakas av oönstrade anonym åtkomst.
Som standard är anonym åtkomst till dina blobdata alltid förbjuden. Standardkonfigurationen för ett Azure Resource Manager-lagringskonto förbjuder användare att konfigurera anonym åtkomst till containrar och blobar i ett lagringskonto. Den här standardkonfigurationen tillåter inte all anonym åtkomst till ett Azure Resource Manager-lagringskonto, oavsett åtkomstinställningen för en enskild container.
När anonym åtkomst för lagringskontot inte tillåts avvisar Azure Storage alla anonyma läsbegäranden mot blobdata. Användare kan inte senare konfigurera anonym åtkomst för containrar i det kontot. Containrar som redan har konfigurerats för anonym åtkomst accepterar inte längre anonyma begäranden.
Varning
När en container har konfigurerats för anonym åtkomst kan alla klienter läsa data i containern. Anonym åtkomst utgör en potentiell säkerhetsrisk, så om ditt scenario inte kräver det rekommenderar vi att du inte tillåter det för lagringskontot.
Reparation för Azure Resource Manager jämfört med klassiska lagringskonton
Den här artikeln beskriver hur du använder ett DRAG-ramverk (Detection-Remediation-Audit-Governance) för att kontinuerligt hantera anonym åtkomst för lagringskonton som använder Azure Resource Manager-distributionsmodellen. Alla allmänna v2-lagringskonton, Premium-blockbloblagringskonton, Premium-filresurskonton och Blob Storage-konton använder Azure Resource Manager-distributionsmodellen. Vissa äldre v1-konton för generell användning och premiumsidans blobkonton kan använda den klassiska distributionsmodellen.
Om ditt lagringskonto använder den klassiska distributionsmodellen rekommenderar vi att du migrerar till Azure Resource Manager-distributionsmodellen så snart som möjligt. Azure Storage-konton som använder den klassiska distributionsmodellen dras tillbaka den 31 augusti 2024. Mer information finns i Klassiska Azure-lagringskonton dras tillbaka den 31 augusti 2024.
Om du inte kan migrera dina klassiska lagringskonton just nu bör du åtgärda anonym åtkomst till dessa konton nu. Information om hur du åtgärdar anonym åtkomst för klassiska lagringskonton finns i Åtgärda anonym läsåtkomst till blobdata (klassiska distributioner). Mer information om Azure-distributionsmodeller finns i Resource Manager och klassisk distribution.
Om anonym läsåtkomst
Anonym åtkomst till dina data är alltid förbjuden som standard. Det finns två separata inställningar som påverkar anonym åtkomst:
Inställning för anonym åtkomst för lagringskontot. Ett Azure Resource Manager-lagringskonto erbjuder en inställning för att tillåta eller neka anonym åtkomst för kontot. Microsoft rekommenderar att du inte tillåter anonym åtkomst för dina lagringskonton för optimal säkerhet.
När anonym åtkomst tillåts på kontonivå är blobdata inte tillgängliga för anonym läsåtkomst om inte användaren vidtar ytterligare steg för att uttryckligen konfigurera containerns inställning för anonym åtkomst.
Konfigurera containerns inställning för anonym åtkomst. Som standard är en containers inställning för anonym åtkomst inaktiverad, vilket innebär att auktorisering krävs för varje begäran till containern eller dess data. En användare med rätt behörighet kan ändra en containers inställning för anonym åtkomst för att endast aktivera anonym åtkomst om anonym åtkomst tillåts för lagringskontot.
I följande tabell sammanfattas hur de två inställningarna tillsammans påverkar anonym åtkomst för en container.
| Anonym åtkomstnivå för containern är inställd på Privat (standardinställning) | Anonym åtkomstnivå för containern är inställd på Container | Anonym åtkomstnivå för containern är inställd på Blob | |
|---|---|---|---|
| Anonym åtkomst tillåts inte för lagringskontot | Ingen anonym åtkomst till någon container i lagringskontot. | Ingen anonym åtkomst till någon container i lagringskontot. Inställningen för lagringskontot åsidosätter containerinställningen. | Ingen anonym åtkomst till någon container i lagringskontot. Inställningen för lagringskontot åsidosätter containerinställningen. |
| Anonym åtkomst tillåts för lagringskontot | Ingen anonym åtkomst till den här containern (standardkonfiguration). | Anonym åtkomst tillåts till den här containern och dess blobar. | Anonym åtkomst tillåts till blobar i den här containern, men inte till själva containern. |
När anonym åtkomst tillåts för ett lagringskonto och konfigurerats för en specifik container, godkänns en begäran om att läsa en blob i containern som skickas utan ett Authorization huvud av tjänsten, och blobens data returneras i svaret. Men om begäran skickas med ett Authorization huvud ignoreras anonym åtkomst på lagringskontot och begäran auktoriseras baserat på de angivna autentiseringsuppgifterna.
Identifiera anonyma begäranden från klientprogram
När du inte tillåter anonym läsåtkomst för ett lagringskonto riskerar du att avvisa begäranden till containrar och blobar som för närvarande är konfigurerade för anonym åtkomst. Om du inte tillåter anonym åtkomst för ett lagringskonto åsidosätts åtkomstinställningarna för enskilda containrar i lagringskontot. När anonym åtkomst inte tillåts för lagringskontot misslyckas eventuella framtida anonyma begäranden till det kontot.
För att förstå hur nekande av anonym åtkomst kan påverka klientprogram rekommenderar vi att du aktiverar loggning och mått för det kontot och analyserar mönster för anonyma begäranden under ett tidsintervall. Använd mått för att fastställa antalet anonyma begäranden till lagringskontot och använd loggar för att avgöra vilka containrar som används anonymt.
Övervaka anonyma begäranden med Metrics Explorer
Om du vill spåra anonyma begäranden till ett lagringskonto använder du Azure Metrics Explorer i Azure Portal. Mer information om Metrics Explorer finns i Analysera mått med Azure Monitor Metrics Explorer.
Följ dessa steg för att skapa ett mått som spårar anonyma begäranden:
Navigera till ditt lagringskonto i Azure-portalen. Under avsnittet Övervakning väljer du Mått.
Välj Lägg till mått. I dialogrutan Mått anger du följande värden:
- Lämna fältet Omfång inställt på namnet på lagringskontot.
- Ange måttnamnområdet till Blob. Det här måttet rapporterar endast begäranden mot Blob Storage.
- Ange fältet Mått till Transaktioner.
- Ange aggregeringsfältet till Summa.
Det nya måttet visar summan av antalet transaktioner mot Blob Storage under ett angivet tidsintervall. Det resulterande måttet visas enligt följande bild:
Välj sedan knappen Lägg till filter för att skapa ett filter för måttet för anonyma begäranden.
I dialogrutan Filter anger du följande värden:
- Ange egenskapsvärdet till Autentisering.
- Ange fältet Operator till likhetstecknet (=).
- Ange fältet Värden till Anonym genom att välja det i listrutan eller skriva in det.
I det övre högra hörnet väljer du det tidsintervall som du vill visa måttet över. Du kan också ange hur detaljerad aggregeringen av begäranden ska vara genom att ange intervall var som helst från 1 minut till 1 månad.
När du har konfigurerat måttet börjar anonyma begäranden att visas i diagrammet. Följande bild visar anonyma begäranden aggregerade under de senaste 30 minuterna.
Du kan också konfigurera en aviseringsregel för att meddela dig när ett visst antal anonyma begäranden görs mot ditt lagringskonto. Mer information finns i Skapa, visa och hantera måttaviseringar med Azure Monitor.
Analysera loggar för att identifiera containrar som tar emot anonyma begäranden
Azure Storage-loggar samlar in information om begäranden som gjorts mot lagringskontot, inklusive hur en begäran har auktoriserats. Du kan analysera loggarna för att avgöra vilka containrar som tar emot anonyma begäranden.
Om du vill logga begäranden till ditt Azure Storage-konto för att utvärdera anonyma begäranden kan du använda Azure Storage-loggning i Azure Monitor. Mer information finns i Övervaka Azure Storage.
Azure Storage-loggning i Azure Monitor stöder användning av loggfrågor för att analysera loggdata. Om du vill köra frågor mot loggar kan du använda en Azure Log Analytics-arbetsyta. Mer information om loggfrågor finns i Självstudie: Kom igång med Log Analytics-frågor.
Skapa en diagnostikinställning i Azure Portal
Om du vill logga Azure Storage-data med Azure Monitor och analysera dem med Azure Log Analytics måste du först skapa en diagnostikinställning som anger vilka typer av begäranden och för vilka lagringstjänster du vill logga data för. När du har konfigurerat loggning för ditt lagringskonto är loggarna tillgängliga på Log Analytics-arbetsytan. Information om hur du skapar en arbetsyta finns i Skapa en Log Analytics-arbetsyta i Azure Portal.
Information om hur du skapar en diagnostikinställning i Azure Portal finns i Skapa diagnostikinställningar i Azure Monitor.
En referens för fält som är tillgängliga i Azure Storage-loggar i Azure Monitor finns i Resursloggar.
Frågeloggar för anonyma begäranden
Azure Storage-loggar i Azure Monitor innehåller den typ av auktorisering som användes för att göra en begäran till ett lagringskonto. I loggfrågan filtrerar du på egenskapen AuthenticationType för att visa anonyma begäranden.
Om du vill hämta loggar för de senaste sju dagarna för anonyma begäranden mot Blob Storage öppnar du Log Analytics-arbetsytan. Klistra sedan in följande fråga i en ny loggfråga och kör den:
StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri
Du kan också konfigurera en aviseringsregel baserat på den här frågan för att meddela dig om anonyma begäranden. Mer information finns i Skapa, visa och hantera loggaviseringar med Hjälp av Azure Monitor.
Svar på anonyma begäranden
När Blob Storage tar emot en anonym begäran lyckas den begäran om alla följande villkor är uppfyllda:
- Anonym åtkomst tillåts för lagringskontot.
- Målcontainern har konfigurerats för att tillåta anonym åtkomst.
- Begäran är för läsåtkomst.
Om något av dessa villkor inte är sant misslyckas begäran. Svarskoden vid fel beror på om den anonyma begäran gjordes med en version av tjänsten som stöder ägarutmaningen. Ägarutmaningen stöds med tjänstversionerna 2019-12-12 och senare:
- Om den anonyma begäran gjordes med en tjänstversion som stöder ägaruppgiften returnerar tjänsten felkoden 401 (obehörig).
- Om den anonyma begäran gjordes med en tjänstversion som inte stöder ägarutmaningen och anonym åtkomst inte tillåts för lagringskontot, returnerar tjänsten felkoden 409 (konflikt).
- Om den anonyma begäran gjordes med en tjänstversion som inte stöder ägarutmaningen och anonym åtkomst tillåts för lagringskontot returnerar tjänsten felkoden 404 (hittades inte).
Mer information om ägarutmaningen finns i Bearer-utmaningen.
Åtgärda anonym åtkomst för lagringskontot
När du har utvärderat anonyma begäranden till containrar och blobar i ditt lagringskonto kan du vidta åtgärder för att åtgärda anonym åtkomst för hela kontot genom att ange kontots allowblobpublicaccess-egenskap till False.
Inställningen för anonym åtkomst för ett lagringskonto åsidosätter de enskilda inställningarna för containrar i kontot. När du inte tillåter anonym åtkomst för ett lagringskonto är alla containrar som har konfigurerats för att tillåta anonym åtkomst inte längre tillgängliga anonymt. Om du inte tillåter anonym åtkomst för kontot behöver du inte heller inaktivera anonym åtkomst för enskilda containrar.
Om ditt scenario kräver att vissa containrar måste vara tillgängliga för anonym åtkomst bör du flytta containrarna och deras blobar till separata lagringskonton som är reserverade för anonym åtkomst. Du kan sedan inte tillåta anonym åtkomst för andra lagringskonton.
För att åtgärda anonym åtkomst krävs version 2019-04-01 eller senare av Azure Storage-resursprovidern. Mer information finns i REST API för Azure Storage-resursprovider.
Behörigheter för att neka anonym åtkomst
Om du vill ange egenskapen AllowBlobPublicAccess för lagringskontot måste en användare ha behörighet att skapa och hantera lagringskonton. Rollbaserade Azure-åtkomstkontrollroller (Azure RBAC) som ger dessa behörigheter omfattar åtgärden Microsoft.Storage/storageAccounts/write . Inbyggda roller med den här åtgärden är:
- Azure Resource Manager rollen Ägare
- Azure Resource Manager rollen Deltagare
- Rollen Lagringskontodeltagare
Rolltilldelningar måste begränsas till lagringskontots nivå eller högre för att tillåta att en användare tillåter anonym åtkomst för lagringskontot. Mer information om rollomfång finns i Förstå omfånget för Azure RBAC.
Var noga med att begränsa tilldelningen av dessa roller endast till de administrativa användare som behöver möjligheten att skapa ett lagringskonto eller uppdatera dess egenskaper. Använd principen om minsta behörighet för att se till att användarna har minst behörighet att utföra sina uppgifter. Mer information om hur du hanterar åtkomst med Azure RBAC finns i Metodtips för Azure RBAC.
Dessa roller ger inte åtkomst till data i ett lagringskonto via Microsoft Entra-ID. De innehåller dock åtgärden Microsoft.Storage/storageAccounts/listkeys/action, som ger åtkomst till kontoåtkomstnycklarna. Med den här behörigheten kan en användare använda kontoåtkomstnycklarna för att komma åt alla data i ett lagringskonto.
Själva åtgärden Microsoft.Storage/storageAccounts/listkeys/action ger dataåtkomst via kontonycklarna, men ger inte en användare möjlighet att ändra egenskapen AllowBlobPublicAccess för ett lagringskonto. För användare som behöver komma åt data i ditt lagringskonto men inte bör ha möjlighet att ändra lagringskontots konfiguration bör du överväga att tilldela roller som Storage Blob Data Contributor, Storage Blob Data Reader eller Reader och Data Access.
Kommentar
De klassiska prenumerationsadministratörsrollerna Tjänstadministratör och medadministratör innehåller motsvarigheten till rollen Azure Resource Manager-ägare. Rollen Ägare innehåller alla åtgärder, så att en användare med någon av dessa administrativa roller också kan skapa lagringskonton och hantera kontokonfiguration. Mer information finns i Azure-roller , Microsoft Entra-roller och klassiska prenumerationsadministratörsroller.
Ange egenskapen AllowBlobPublicAccess för lagringskontot till False
Om du vill neka anonym åtkomst för ett lagringskonto anger du kontots AllowBlobPublicAccess-egenskap till False.
Viktigt!
Om du inte tillåter anonym åtkomst för ett lagringskonto åsidosätts åtkomstinställningarna för alla containrar i lagringskontot. När anonym åtkomst inte tillåts för lagringskontot misslyckas eventuella framtida anonyma begäranden till det kontot. Innan du ändrar den här inställningen måste du förstå effekten på klientprogram som kan komma åt data i ditt lagringskonto anonymt genom att följa stegen som beskrivs i Identifiera anonyma begäranden från klientprogram.
Följ dessa steg om du vill neka anonym åtkomst för ett lagringskonto i Azure Portal:
Navigera till ditt lagringskonto i Azure-portalen.
Leta upp konfigurationsinställningen under Inställningar.
Ange Tillåt anonym blobåtkomst till Inaktiverad.
Kommentar
Att neka anonym åtkomst för ett lagringskonto påverkar inte några statiska webbplatser som finns i lagringskontot. Den $web containern är alltid offentligt tillgänglig.
När du har uppdaterat inställningen för anonym åtkomst för lagringskontot kan det ta upp till 30 sekunder innan ändringen är helt spridd.
Exempelskript för massreparation
Följande PowerShell-exempelskript körs mot alla Azure Resource Manager-lagringskonton i en prenumeration och anger inställningen AllowBlobPublicAccess för dessa konton till 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"
}
Kontrollera inställningen för anonym åtkomst för flera konton
Om du vill kontrollera inställningen för anonym åtkomst för en uppsättning lagringskonton med optimala prestanda kan du använda Azure Resource Graph Explorer i Azure Portal. Mer information om hur du använder Resource Graph Explorer finns i Snabbstart: Kör din första Resource Graph-fråga med Azure Resource Graph Explorer.
När du kör följande fråga i Resource Graph Explorer returneras en lista över lagringskonton och anonym åtkomstinställning för varje konto visas:
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess
Följande bild visar resultatet av en fråga i en prenumeration. För lagringskonton där egenskapen AllowBlobPublicAccess uttryckligen anges visas den i resultatet som sant eller falskt. Om egenskapen AllowBlobPublicAccess inte har angetts för ett lagringskonto visas den som tom (eller null) i frågeresultatet.
Använda Azure Policy för att granska efterlevnad
Om du har ett stort antal lagringskonton kanske du vill utföra en granskning för att se till att dessa konton har konfigurerats för att förhindra anonym åtkomst. Om du vill granska en uppsättning lagringskonton för deras efterlevnad använder du Azure Policy. Azure Policy är en tjänst som du kan använda för att skapa, tilldela och hantera principer som tillämpar regler för Azure-resurser. Azure Policy hjälper dig att hålla resurserna kompatibla med företagets standarder och serviceavtal. Mer information finns i Översikt över Azure Policy.
Skapa en princip med en granskningseffekt
Azure Policy stöder effekter som avgör vad som händer när en principregel utvärderas mot en resurs. Granskningseffekten skapar en varning när en resurs inte är i kompatibilitet, men inte stoppar begäran. Mer information om effekter finns i Förstå Azure Policy-effekter.
Följ dessa steg för att skapa en princip med en granskningseffekt för inställningen anonym åtkomst för ett lagringskonto med Azure Portal:
I Azure-portalen, gå till tjänsten Azure Policy.
Under avsnittet Redigering väljer du Definitioner.
Välj Lägg till principdefinition för att skapa en ny principdefinition.
I fältet Definitionsplats väljer du knappen Mer för att ange var resursen för granskningsprinciper finns.
Ange ett namn för principen. Du kan även ange en beskrivning och kategori.
Under Principregel lägger du till följande principdefinition i avsnittet policyRule .
{ "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "not": { "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "false" } } ] }, "then": { "effect": "audit" } }Spara principen.
Tilldela principen
Tilldela sedan principen till en resurs. Omfånget för principen motsvarar den resursen och eventuella resurser under den. Mer information om principtilldelning finns i Azure Policy-tilldelningsstruktur.
Följ dessa steg för att tilldela principen till Azure-portalen:
- I Azure-portalen, gå till tjänsten Azure Policy.
- Under avsnittet Redigering väljer du Tilldelningar.
- Välj Tilldela princip för att skapa en ny principtilldelning.
- I fältet Omfång väljer du omfånget för principtilldelningen.
- I fältet Principdefinition väljer du knappen Mer och väljer sedan den princip som du definierade i föregående avsnitt i listan.
- Ange ett namn för principtilldelningen. Beskrivningen är valfri.
- Lämna Principtillämpning inställd på Aktiverad. Den här inställningen påverkar inte granskningsprincipen.
- Välj Granska + skapa för att skapa tilldelningen.
Visa efterlevnadsrapport
När du har tilldelat principen kan du visa efterlevnadsrapporten. Efterlevnadsrapporten för en granskningsprincip innehåller information om vilka lagringskonton som inte följer principen. Mer information finns i Hämta principefterlevnadsdata.
Det kan ta flera minuter innan efterlevnadsrapporten blir tillgänglig när principtilldelningen har skapats.
Följ dessa steg om du vill visa efterlevnadsrapporten i Azure Portal:
I Azure-portalen, gå till tjänsten Azure Policy.
Välj Efterlevnad.
Filtrera resultatet efter namnet på den principtilldelning som du skapade i föregående steg. Rapporten visar hur många resurser som inte följer principen.
Du kan öka detaljnivån i rapporten för ytterligare information, inklusive en lista över lagringskonton som inte är kompatibla.
Använda Azure Policy för att framtvinga auktoriserad åtkomst
Azure Policy stöder molnstyrning genom att se till att Azure-resurser följer krav och standarder. För att säkerställa att lagringskonton i organisationen endast tillåter auktoriserade begäranden kan du skapa en princip som förhindrar att ett nytt lagringskonto skapas med en anonym åtkomstinställning som tillåter anonyma begäranden. Den här principen förhindrar också alla konfigurationsändringar av ett befintligt konto om inställningen för anonym åtkomst för kontot inte är kompatibel med principen.
Tvingande principen använder neka-effekten för att förhindra en begäran som skulle skapa eller ändra ett lagringskonto för att tillåta anonym åtkomst. Mer information om effekter finns i Förstå Azure Policy-effekter.
Om du vill skapa en princip med en neka-effekt för en anonym åtkomstinställning som tillåter anonyma begäranden följer du samma steg som beskrivs i Använda Azure Policy för att granska efterlevnaden, men ange följande JSON i avsnittet policyRule i principdefinitionen:
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "deny"
}
}
När du har skapat principen med neka-effekten och tilldelat den till ett omfång kan en användare inte skapa ett lagringskonto som tillåter anonym åtkomst. En användare kan inte heller göra några konfigurationsändringar i ett befintligt lagringskonto som för närvarande tillåter anonym åtkomst. Om du försöker göra det resulterar det i ett fel. Inställningen för anonym åtkomst för lagringskontot måste vara inställd på false för att kunna fortsätta med att skapa eller konfigurera kontot.
Följande bild visar felet som uppstår om du försöker skapa ett lagringskonto som tillåter anonym åtkomst när en princip med neka-effekten kräver att anonym åtkomst inte tillåts.
