Skydda din Azure Blob Storage

Azure Blob Storage lagrar enorma mängder ostrukturerad objektdata i containrar. Det är ofta måltavla för exfiltration, utpressningstrojaner och incidenter där information exponeras offentligt. Denna artikel ger säkerhetsrekommendationer specifika för blobcontainers, blobs och hierarkiska namnrymder i Azure Data Lake Storage.

Note

Den här artikeln behandlar säkerhetspraxis specifika för Azure Blob Storage. För säkerhetsvägledning på kontonivå, se Secure your Azure Storage account.

Nätverkssäkerhet

  • Front anpassade domäner, statiska webbplatser och allt offentligt distribuerat blobinnehåll med Azure Front Door: Avsluta TLS vid Azure Front Door med ett hanterat certifikat, aktivera WAF och begränsa lagringskontots offentliga nätverksåtkomst så att endast Front Door kan nå ursprunget. Azure Storage:s egen egenutvecklade domänfunktion stöder inte hanterade TLS-certifikat, och Front Door lägger till WAF-skydd, hastighetsbegränsning och loggning som anonym containeråtkomst saknar. För mer information, se Use Azure Front Door with Azure Storage blobs.

  • Inaktivera slutpunkten för statisk webbplats när den inte används: Behållaren $web förblir offentligt läsbar så länge funktionen för statisk webbplats är aktiverad, även om allowBlobPublicAccess är false. Inaktivera funktionen statisk webbplats på konton som inte behöver det. För mer information, se Static website hosting in Azure Storage.

Identitets- och åtkomsthantering

Anonym offentlig tillgång

  • Inaktivera anonym offentlig läsåtkomst på lagringskontot: Ställ in egenskapen allowBlobPublicAccess så false att ingen container i kontot kan vara offentlig, oavsett konfiguration på containernivå. Mer information finns i Översikt: Åtgärda anonym läsåtkomst för blobdata.

  • Granska och åtgärda eventuell befintlig anonym åtkomst: Använd vägledningen i Remediate anonymous read access to blob data för att hitta containrar som tillåter offentlig åtkomst och konvertera dem till privat åtkomst eller explicit SAS-baserad delning.

SAS och ABAC på blobnivå

  • Använd användardelegerad SAS i stället för service-SAS för åtkomst till blobbar: En användardelegerad delad åtkomstsignatur (SAS) signeras med en Microsoft Entra-legitimation. Att återkalla användardelegeringsnyckeln ogiltigförklarar omedelbart varje SAS som utfärdas från den, vilket ger en återkallningsväg som service- och konto-SAS saknar. Mer information finns i Skapa en SAS för användardelegering.

  • Begränsa service-SAS med lagrade åtkomstprinciper så att den kan återkallas: Om du måste använda en service-SAS, koppla den till en lagrad åtkomstprincip på containern. Du kan sedan ändra eller ta bort policyn för att återkalla varje SAS som refererar till den. Utan en policy kan ett service-SAS endast återkallas genom att rotera kontonycklarna, vilket påverkar alla andra SAS i kontot. Mer information finns i Definiera en lagrad åtkomstprincip.

  • Använd blob-indextaggar för att villkora åtkomst via ABAC: Kombinera blob-indextaggar med attributbaserade åtkomstkontrollvillkor (ABAC) för att ge läsåtkomst endast till blobs med specifika taggvärden – till exempel, Classification=Public. Denna metod gör det möjligt för en enda rolltilldelning att betjäna många anropare utan att ge tillgång till känslig taggad data. För mer information, se Auktorisera åtkomst till blobs med ABAC-villkor.

Dataskydd

  • Använd krypteringsomfång för blobbar för att isolera kryptering för specifika containrar eller blobbar: Krypteringsomfång gör det möjligt att använda olika nycklar eller principer för nyckelrotation på container- eller blobnivå inom samma konto. Denna funktion är användbar för arbetsbelastningar i multitenantmiljöer som delar ett konto men behöver kontroll över nycklar per tenant. För mer information, se Encryption scopes for Blob Storage.

  • Använd klientbaserad kryptering för blobdata som aldrig får visas på servern i klartext: Kryptera blobinnehållet i klienten innan uppladdning. SDK:n integreras med Azure Key Vault eller Managed HSM för nyckelhantering. Kombinera med service-side CMK för lager av skydd. För mer information, se kryptering på klientsidan för blobs.

Oföränderlighet och WORM

  • Konfigurera tidsbaserade lagringspolicyer för reglerad data: Tillämpa tidsbaserad lagring på container- eller versionsnivå för att förhindra ändring eller radering av blobs under en fast period. Oföränderlighet på versionsnivå ger finare kontroll och du kan aktivera eller utöka den på enskilda versioner. Mer information finns i Lagra affärskritiska blobdata med oföränderlig lagring.

  • Använd juridiska reservationer för obegränsad lagring som drivs av juridiska eller undersökande behov: Juridiska reservationer förhindrar radering tills en auktoriserad användare uttryckligen rensar spärren, utan fast varaktighet. Mer information finns i Lagra affärskritiska blobdata med oföränderlig lagring.

  • Lås lagringspolicyer för att göra dem icke-modifierbara: Användare med lämpliga behörigheter kan förkorta eller ta bort en olåst lagringspolicy. Att låsa försäkringen gör att behållningstiden blir ett ensidigt åtagande. Lås bara efter att du validerat försäkringens löptid. För mer information, se Konfigurera oföränderlighetspolicyer för containrar.

Objektreplikering och kopieringsoperationer

  • Begränsa objektreplikering till källkonton du kontrollerar: Konfigurera destinationskontots tillåtna källkontolista så att endast kända, betrodda källkonton kan skicka data. Mer information finns i Konfigurera objektreplikering.

  • Förhindra objektreplikering mellan olika hyresgäster: Förbjud replikeringspolicyer vars käll- och destinationskonton finns i olika Microsoft Entra-tenants. Denna begränsning förhindrar att en auktoriserad användare kan konfigurera replikering till en extern hyresgäst. Mer information finns i Förhindra objektreplikering mellan Microsoft Entra-klienter.

  • Begränsa tillåtet omfattning för kopieringsoperationer: Konfigurera kontot så att kopieringsoperationer endast tillåts från källkonton i samma hyresgäst eller samma prenumeration. Denna konfiguration blockerar en gemensam exfiltrationsväg – att kopiera från ett privat konto till ett angriparkontrollerat konto. För mer information, se Tillåtet omfattning för kopieringsoperationer.

Säkerhetskopiering och återställning

  • Aktivera blob-versionering för att bevara tidigare versioner vid skriv och borttagning: När du aktiverar versionshantering skapar varje skriv- eller borttagningsoperation en ny version och behåller det föregående tillståndet. Du kan adressera och återställa versioner. Mer information finns i Blob-versionshantering.

  • Aktivera mjuk borttagning för blobbar och för containrar: Mjuk borttagning behåller borttagna blobbar och containrar under en angiven kvarhållningsperiod, så att du kan återställa dem under den tiden. Konfigurera mjuk borttagning på containernivå och blobnivå separat och aktivera båda. Mer information finns i Mjuk borttagning för blobs och Mjuk borttagning för containrar.

  • Aktivera punkt-i-tid-återställning för blockblob-konton: Punkt-i-tid-återställning fungerar med versionshantering och mjuk borttagning för att återställa ett intervall av blockblobs till en specifik tidigare tidsstämpel. Denna funktion är hjälpsam för återställning av ransomware. Punkt-i-tid-återställning kräver att du aktiverar versionshantering, blob-mjuk borttagning och ändringsflöde. Mer information finns i Återställning till tidpunkt för blockblobar.

  • Aktivera ändringsflödet för revision och forensik: Ändringsflödet är en ordnad, oföränderlig logg över varje ändring i blobs i kontot. Förutom att möjliggöra återställning i tidpunkten tillhandahåller den en hållbar revisionsdokumentation för utredningar. Mer information finns i Stöd för ändringsflöde i Azure Blob Storage.

Azure Data Lake Storage

Data Lake Storage lägger till ett hierarkiskt namnrymd och POSIX-liknande åtkomstkontrolllistor (ACL) till Blob Storage. ACL och RBAC samarbetar – ger grov åtkomst via RBAC och förfinar inom filsystemet med ACL.

  • Använd RBAC för grovkornig åtkomst och ACL för finkornig åtkomst: Tilldela inbyggda blob-RBAC-roller på container- eller kontonivå för att ge bred åtkomst. Använd sedan ACL på kataloger och filer för att begränsa åtkomsten inom containern. Använd inte bara ACL för behörigheter en användare behöver över hela containern. RBAC är mer effektivt att utvärdera och granska. Mer information finns i Åtkomstkontrollmodell i Azure Data Lake Storage.

  • Tillämpa standard-ACL:er på kataloger för att ärva behörigheter på nya barn-objekt: Standard-ACL:er gäller för filer och kataloger som skapas efter att du satt ACL:n. Ställ in dem på katalognivå för att undvika att hantera ACL:er på enskilda filer. För mer information, se Access control lists i Azure Data Lake Storage.

  • Aktivera det hierarkiska namnrymden vid kontoskapandet: Du kan inte aktivera det hierarkiska namnrymden på ett befintligt konto utan migrering. Om du vet att en arbetsbelastning använder Data Lake Storage-semantik, aktivera den direkt istället för att migrera senare. För mer information, se Azure Data Lake Storage hierarchical namespace.

Loggning och övervakning

  • Avisering vid anonyma åtkomstträffar efter att du inaktiverat anonym åtkomst: När du sätter allowBlobPublicAccess till false, filtrera lagringsloggar för AuthenticationType == "Anonymous" och varning vid eventuella träffar. Dessa träffar indikerar antingen en felkonfigurerad klient eller ett probingförsök. Mer information finns i Övervaka Azure Storage.

  • Aktivera och agera utifrån Defender for Storage-bedömningar från genomsökning efter skadlig kod: När du aktiverar genomsökning efter skadlig kod konfigurerar du automatiserade åtgärder (radering av blobbar, karantäntagg eller undertryckning av nedströmsarbetsflöden) utifrån MalwareScanningResult bedömningar så att identifierade skadliga blobbar inte kan levereras till användare. Mer information finns i Svara på resultat från genomsökning efter skadlig kod i Defender for Storage.

  • Spåra mutationer i blob-indextaggar för klassificeringsdrift: Om du använder blob-index-taggar för att styra ABAC-åtkomstvillkor, ändrar ändringar i dessa taggar direkt vem som kan läsa blobben. Logga och larma om SetBlobTags operationer mot känsliga containrar. För mer information, se Hantera och hitta data på Azure Blob Storage med blob index-taggar.

Nästa steg

  • Uppdaterades senast