Skydda ditt Azure Storage-konto

Azure Storage tillhandahåller skalbar, hållbar molnlagring för blobs, filer, köer och tabeller i ett enda lagringskonto. Eftersom ett lagringskonto kan innehålla data med mycket olika känslighetsnivåer och ofta är ett mål för exfiltrations- och ransomware-attacker, vidta medvetna åtgärder för att skydda kontot, den data det innehåller och de identiteter som får tillgång till det.

Den här artikeln ger säkerhetsrekommendationer för att hjälpa till att skydda ditt Azure Storage-konto. Dessa rekommendationer gäller för alla datatjänster i kontot (Blobs, Files, Queues och Tables). För vägledning specifik för varje datatjänst, se artiklarna om relaterade säkerheter i slutet av denna artikel.

Säkerhetsrekommendationerna i den här artikeln implementerar Nulová dôvera (Zero Trust) principer: "Verifiera explicit", "Använd åtkomst med minst behörighet" och "Anta intrång". Omfattande vägledning om Noll förtroende finns i Vägledningscenter för noll förtroende.

Tjänstspecifik säkerhet

Azure Storage har arkitektoniska egenskaper som formar hur du distribuerar det säkert. De val du gör när du skapar ett konto – distributionsmodell, typ, redundans och endpoint-konfiguration – är svåra att ändra senare och påverkar säkerhetsläget för varje arbetsbelastning som använder kontot.

Lagringskontoarkitektur

  • Använd Azure Resource Manager-distributionsmodellen: Skapa nya lagringskonton genom att använda Azure Resource Manager-distributionsmodellen. Resource Manager-konton stödjer Azure rollbaserad åtkomstkontroll (RBAC), hanterade identiteter, Microsoft Entra ID-auktorisering för data, resurslås, taggar och policy – inget av detta finns tillgängligt med den klassiska distributionsmodellen. Migrera eventuella kvarvarande klassiska konton. För mer information, se Migrera ett klassiskt lagringskonto till Azure Resource Manager.

  • Separata lagringskonton efter arbetsbelastning, miljö och känslighet: Skapa separata konton för utveckling, förproduktion och produktion, samt separata konton för data med olika känslighetsklassificeringar. Ett lagringskonto är en förtroendegräns för delad nyckel och en policygräns – att blanda arbetsbelastningar i ett konto ökar explosionsradien för en kompromiss och gör åtkomst till minsta privilegium svårare att modellera.

  • Använd ett konto per region för regional isolering: Att placera konton i den region där de arbetsbelastningar som använder dem körs minskar dataöverföringen mellan regioner och förenklar gränserna för regelefterlevnad. För multiregiondesigner, para ihop regionala konton med georedundant lagring eller objektreplikering istället för att betjäna alla regioner från ett enda konto. Mer information finns i Azure Storage-redundans.

Lämplig användning av Azure Storage

  • Använd inte Azure Storage-kontonycklar som långvariga autentiseringsuppgifter för program: Lagringskontonycklar ger full kontroll över kontot och kan inte begränsas. Applikationer bör använda Microsoft Entra ID med hanterade identiteter eller, när Entra ID inte är ett alternativ, kortlivade användardelegerade delade åtkomstsignaturtoken (SAS). Mer information finns i Auktorisera åtkomst till data i Azure Storage.

  • Använd inte Azure Storage som en allmän hemlighetslagring: Hemligheter, anslutningssträngar och certifikat hör hemma i Azure Key Vault, som tillhandahåller rotation, åtkomstpolicyer, hårdvarusäkerhetsmodul (HSM) skydd och revisionsspår. Mer information finns i Översikt över Azure Key Vault.

Nätverkssäkerhet

Lagringskonton är internetåtkomliga som standard. Att minska nätverksattackytan är den mest effektiva förändringen du kan göra för att skydda ett konto mot obehörig åtkomst, dataexfiltration och spaning.

  • Inaktivera offentlig nätverksåtkomst till lagringskontot: När dina klienter är helt i Azure eller nås via Private Link, ställ in kontots offentliga nätverksåtkomst på Inaktiverad så att endast förfrågningar via privata endpoints accepteras. Mer information finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.

  • Använd privata endpoints för åtkomst från virtuella nätverk: En privat endpoint tilldelar en privat IP-adress från ditt virtuella nätverk till lagringskontot och dirigerar trafik över Microsoft-ryggraden. I kombination med inaktiverad offentlig nätverksåtkomst eliminerar privata endpoints internetexponering. Mer information finns i Använda privata slutpunkter för Azure Storage.

  • Begränsa offentlig åtkomst med lagringsbrandväggen när privata endpoints inte är praktiska: Om klienter måste nå kontot via offentligt nätverk, ställ in brandväggens standardåtgärd på Neka och tillåt endast de specifika IP-områden, virtuella nätverkssubnät (via service-endpoints) eller resursinstanser som behöver åtkomst. Mer information finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.

    • Tillåt betrodda Microsoft-tjänster när de behöver åtkomst till kontot: Brandväggsregler som nekar som standard blockerar begäranden från andra Azure-tjänster (till exempel Azure Backup, Log Analytics och Microsoft Defender for Storage) samt från Azure-portalen och diagnostikpipelines. Lägg till Tillåt Azure-tjänster på listan över betrodda tjänster för att komma åt detta undantag för lagringskontot så att förstapartstjänster du är beroende av kan nå kontot utan att öppna det mot det publika internet. Mer information finns i Grant-åtkomst till betrodda Azure-tjänster.

    • Ge tillgång till specifika resursinstanser snarare än betrodda tjänster generellt: Föredra resursinstansregler, som auktoriserar en namngiven Azure-resurs och dess hanterade identitet, framför det generella undantaget "Tillåt betrodda Microsoft-tjänster". Regler för resursinstanser ger en mindre förtroendeyta. Mer information finns i Bevilja åtkomst från Azure-resursinstanser.

  • Koppla lagringskonton till en nätverkssäkerhetsperimeter: En nätverkssäkerhetsperimeter definierar logiska gränser mellan plattformen som en tjänsteresurs och blockerar trafik utanför perimetern som standard, vilket ger djupgående skydd utöver brandväggsregler per konto. För mer information, se Network security perimeter for Azure Storage.

  • Upprätthåll en minsta TLS-version på 1.2 eller senare: Konfigurera lagringskontots minsta TLS-version för att avvisa klienter som förhandlar om äldre, föråldrade versioner. För mer information, se Konfigurera minsta nödvändiga version av Transport Layer Security (TLS) för ett lagringskonto.

  • Kräv säker överföring (HTTPS): Aktivera egenskapen Secure transfer required för att avvisa alla förfrågningar som görs över HTTP. Detta krav gäller för REST-endpoints samt för SMB-åtkomst till Azure Files. För mer information, se Kräv säker överföring för ett lagringskonto.

    • Vissa scenarier, såsom äldre SMB-klienter eller äldre verktyg, kräver HTTP. I sådana fall, isolera dessa klienter i ett kontrollerat nätverkssegment och migrera dem från HTTP så snart som möjligt.

  • Begränsa objektreplikering och kopieringsoperationer mellan olika hyresgäster: Konfigurera lagringskontot så att kopierings- och objektreplikeringsoperationer endast tillåts från källkonton i samma hyresgäst, eller endast från tillåtna källkonton. Denna konfiguration förhindrar datarörelse över hyresgästgränser av användare som har dataplansbehörigheter. För mer information, se Tillåten omfattning för kopieringsoperationer och Förhindra objektreplikering över Microsoft Entra-tenants.

  • Använd VNet-servicetaggar för utgående regler till Azure Storage: När du begränsar utgående trafik från ett virtuellt nätverk till Azure Storage, använd servicetaggen Storage (eller regionsspecifik variant) istället för hårdkodade IP-intervall. Microsoft behåller servicetaggen i takt med att IP-området utvecklas. Mer information finns i Översikt över Azure-tjänsttaggar.

  • Föredra Microsoft globala nätverk för inkommande routing: Konfigurera lagringskontots nätverksroutingpreferens till Microsoft nätverksrouting så att inkommande trafik går in i Microsoft-ryggraden vid den närvaropunkt närmast klienten och stannar kvar på Microsoft-nätverket end-to-end. Internetrouting lämnar Microsoft-nätverket tidigare och ökar exponeringen mot den publika internetvägen. Mer information finns i Konfigurera inställningar för nätverksroutning för Azure Storage.

Identitets- och åtkomsthantering

Lagringskonton stöder två auktoriseringsmodeller: Microsoft Entra ID (identitetsbaserat, granskabart, återkalleligt) och Shared Key (en symmetrisk hemlighet med fullständig kontoåtkomst). Flytta arbetsbelastningar till Microsoft Entra ID där så är möjligt och behandla Shared Key som en äldre reservlösning.

  • Använd Microsoft Entra ID för att auktorisera åtkomst till data: Microsoft Entra ID-auktorisation använder OAuth 2.0-tokens och integreras med villkorad åtkomst, hanterade identiteter och RBAC-revisionsspår. Den är överlägsen Shared Key i alla avseenden för dataplansåtkomst. Mer information finns i Auktorisera åtkomst till data i Azure Storage.

  • Förbjud auktorisation av delade nyckel: Ställ in egenskapen allowSharedKeyAccess så false att kontot avvisar alla förfrågningar som är signerade med kontonycklarna. Endast Microsoft Entra ID och, där det är tillämpligt, användardelegerade SAS-förfrågningar accepteras. Mer information finns i Förhindra auktorisering med delad nyckel för ett Azure-lagringskonto.

  • Tilldela RBAC-roller på minsta rimliga omfattning: Tilldela de inbyggda Storage data-plan-rollerna (till exempel Storage Blob Data Reader, Storage Queue Data Contributor) på container-, share-, kö- eller tabellnivå när det är möjligt, snarare än på konto- eller prenumerationsnivå. För mer information, se Auktorisera åtkomst till blobs med Azure rollbaserad åtkomstkontroll.

    • Lägg till ABAC-villkor för att ytterligare begränsa åtkomst till dataplanet: Azure attributbaserad åtkomstkontroll (ABAC) låter dig koppla villkor till rolltilldelningar – till exempel att begränsa åtkomst till blobs med en specifik indextagg eller under ett specifikt vägprefix. För mer information, se Auktorisera åtkomst till blobs med Azure-rolltilldelningar med ABAC-villkor.

  • Använd användardelegerings-SAS istället för tjänste- eller konto-SAS när SAS krävs: En användardelegerad SAS signeras med en Microsoft Entra-behörighet istället för kontonyckeln, så att återkalla användardelegeringsnyckeln omedelbart ogiltigförklarar varje SAS som utfärdas från den. Tjänste- och konto-SAS-tokens signerade med kontonycklar kan inte återkallas individuellt. Mer information finns i Bevilja begränsad åtkomst till Azure Storage-resurser med hjälp av signaturer för delad åtkomst (SAS).

    • Begränsa varje SAS till minimibehörigheter och kortaste livslängd: Tilldela endast de specifika operationerna (till exempel, read men inte write) och sätt utgångsdatum till en timme eller mindre för service-SAS som inte backas upp av en lagringsåtkomstpolicy. För mer information, se Bästa praxis vid användning av SAS.

    • Konfigurera en SAS-utgångspolicy på kontot: Sätt en övre gräns för giltighetsperioden för SAS-tokens som utfärdas från kontot. Överträdelser loggas så att du kan hitta och åtgärda långlivade SAS i din kodbas. Mer information finns i Skapa en förfalloprincip för signaturer för delad åtkomst.

    • Begränsa SAS-tokens till endast HTTPS: När du måste utfärda en SAS, tillåt endast HTTPS i SAS-signaturen för att undvika exponering av token i clear. Mer information finns i Bevilja begränsad åtkomst till Azure Storage-resurser med hjälp av signaturer för delad åtkomst (SAS).

  • Om du måste använda kontonycklar, skydda och rotera dem: Spara kontonycklar i Azure Key Vault, hämta dem vid körning istället för att bädda in dem i konfigurationen, och rotera dem i en definierad takt. Ha en dokumenterad rotationsprozedur som undviker driftstopp genom att använda båda tangenterna under rollover. Mer information finns i Hantera åtkomstnycklar för lagringskonto.

  • Tilldela privilegierade lagringsroller just-in-time med Microsoft Entra Privileged Identity Management (PIM): För roller som medger ändringar i hanteringsplanet för lagring (till exempel Storage Account Contributor eller Owner) ska du kräva PIM-aktivering med godkännande och flerfaktorsautentisering i stället för permanenta tilldelningar. Mer information finns i Vad är Microsoft Entra Privileged Identity Management?.

Dataskydd

Azure Storage krypterar all data i vila som standard med Microsoft-hanterade nycklar. Rekommendationerna i detta avsnitt lägger till kundkontroll, skydd mot oavsiktlig eller illvillig modifiering samt minskar exponeringen av data under överföring och i vila.

  • Konfigurera kundhanterade nycklar (CMK) för kryptering i vila: Använd en nyckel du hanterar i Azure Key Vault eller Managed HSM som kontokrypteringsnyckel. CMK låter dig rotera, granska och återkalla krypteringsnyckeln oberoende av Microsoft-hanterade nycklar. Den stöder efterlevnadskrav som kräver kontroll av kundnyckeln. Mer information finns i Kundhanterade nycklar för Azure Storage-kryptering.

  • Aktivera infrastrukturkryptering för försvar på djupet med dubbel kryptering: Infrastrukturkryptering innebär ett andra, tjänsthanterat krypteringslager ovanpå det primära krypteringslagret. Du måste aktivera det vid kontoskapandet. För mer information, se Aktivera infrastrukturkryptering för dubbel kryptering av data.

  • Använd krypteringsomfattningar för att isolera kryptering för specifika containrar eller blobbar: Med krypteringsomfattningar kan du 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.

  • Aktivera Azure Storage-kryptering för all data under överföring: Kombinera Secure transfer required = enabled (se nätverkssäkerhet) med en minsta TLS-version av 1.2 eller senare. Tillsammans säkerställer de att kontot avvisar både okrypterade och svagt krypterade anslutningar.

  • Använd klientsidans kryptering för den mest känsliga datan: För data vars klartext aldrig får visas på servern, kryptera i klienten innan uppladdning. Klientbaserad kryptering är komplementär till tjänstebaserad kryptering och kan användas tillsammans med CMK för lager-på-lager-skydd. För stöd och mönster för SDK:er per tjänst, se relaterade säkerhetsartiklar.

  • Skydda lagringskontot med ett resurslås: Applicera ett CanNotDelete- eller ReadOnly-lås för att förhindra oavsiktlig eller illvillig radering eller omkonfiguration av kontot. Lås gäller för kontoresursen, inte för datan i den, så de kompletterar – inte ersätter – mjuk borttagning och oföränderlighet. Mer information finns i Tillämpa ett Azure Resource Manager-lås på ett lagringskonto.

För dataskyddsfunktioner som är specifika för datatjänster (oföränderlighet för blobbar och WORM-principer, krypteringsomfång för blobbar) finns motsvarande underartikel under Relaterade säkerhetsartiklar.

Loggning och övervakning

Lagringskonton är ofta mål för stölder av legitimation, exfiltrationsförsök och felkonfiguration. Du behöver kontinuerlig loggning och hotdetektering för att snabbt upptäcka och reagera på attacker.

  • Aktivera Microsoft Defender for Storage: Defender for Storage erbjuder hotdetektering, malware-skanning vid uppladdning för blobs och upptäckt av känslig data. Den flaggar avvikande åtkomstmönster, kända skadliga IP-adresser och Tor-avslut samt ovanlig autentiseringsaktivitet. Aktivera det på prenumerations- eller lagringskontonivå. För mer information, se Översikt av Microsoft Defender for Storage.

    • Aktivera skadlig kodskanning för blob-uppladdningar på konton som accepterar opålitligt innehåll: Skadlig kodskanning inspekterar uppladdade blobs och markerar eller tar bort skadligt innehåll innan det kan levereras till nedströmskonsumenter. För mer information, se Malware Scanning i Defender for Storage.

    • Aktivera hotupptäckt för känsliga data: Upptäckt av känsliga data klassificerar data i kontot och prioriterar varningar på containrar som innehåller känslig information. För mer information, se Upptäckt av känsliga data i Defender for Storage.

  • Skicka diagnostiska inställningar till ett Log Analytics-arbetsområde: Konfigurera diagnostikinställningar på kontot och varje datatjänst (Blobs, Files, Queues, Tables) för att skicka StorageRead, StorageWrite, och StorageDelete loggar plus alla mätvärden till Log Analytics. Behåll loggar under den period som krävs enligt dina efterlevnadsskyldigheter. Mer information finns i Övervaka Azure Storage.

  • Granska hur varje förfrågan är auktoriserad: Lagringsloggar registrerar om varje förfrågan var auktoriserad med Microsoft Entra ID, delad nyckel, SAS eller anonymt. Sök regelbundet i loggarna för att upptäcka oväntade auktoriseringsmetoder, särskilt användning av delad nyckel efter att du inaktiverat den eller anonym åtkomst efter att du inaktiverat den. För mer information, se Övervaka förfrågningar mot Azure Storage.

  • Avisering vid högsignalsäkerhetshändelser: Konfigurera Azure Monitor-varningar för händelser som nyckelregenerering, regeländringar i brandväggar, ändringar i offentlig nätverksåtkomst, användning av delad nyckel på konton där den ska inaktiveras, och Defender for Storage-varningar. För mer information, se Logga aviseringar i Azure Monitor.

  • Vidarebefordra loggar till en central SIEM: För svar i företagsskala, vidarebefordra lagringsloggar från Log Analytics till Microsoft Sentinel eller annan SIEM så att lagringshändelser korrelerar med identitet, nätverk och endpoint-signaler. För mer information, se Connect Azure Storage to Microsoft Sentinel.

Efterlevnad och styrning

Styrningskontroller gör säkra konfigurationer till standard och upptäcker drift automatiskt. För alla lagringsanläggningar som är större än ett fåtal konton är policybaserad tillsyn det enda hållbara sättet att hålla baslinjen konsekvent.

  • Tillämpa Azure Policy för att upprätthålla grundläggande lagringssäkerhet: Tilldela inbyggda policyer som blockerar osäkra konfigurationer vid implementering och granska befintliga konton. Högvärdiga inbyggda funktioner inkluderar: kräv säker överföring, kräv minst TLS 1.2, neka tillgång till offentligt nätverk, neka offentlig blobåtkomst, kräv infrastrukturkryptering och kräv CMK. En fullständig lista finns i inbyggda Azure Policy-definitioner för Azure Storage och Azure Policy-kontroller för regelefterlevnad för Azure Storage.

  • Använd Microsoft cloud security benchmark (MCSB) som baslinje: Anpassa lagringskontroller med MCSB v2-domäner för en konsekvent säkerhetsnivå över tjänster. För mer information, se Översikt av Microsoft molnsäkerhetsbenchmark.

  • Tagglagringskonton med ägare, dataklassificering och miljö: Styrningspolicyer, kostnadshantering och incidenthantering beror alla på konsekvent taggning. Applicera taggar via Azure Policy så att de inte kan utelämnas vid skapandet.

  • Granska efterlevnadserbjudanden innan du lagrar reglerade data: Azure Storage har certifieringar för vanliga regelverk (HIPAA, PCI DSS, FedRAMP, ISO 27001 och andra). Bekräfta täckningen för din arbetsbelastning innan utplacering. För mer information, se Azure Storage-efterlevnadserbjudanden.

Säkerhetskopiering och återställning

Tvärregional redundans plus validerade failover-procedurer ger regional motståndskraft för lagringskontot. För skydd mot datatjänstspecifik radering (blob soft delete, blob versioning, ändringsflöde, tidpunktsåterställning, fildelning mjuk radering och snapshots), se motsvarande delartikel i Relaterade säkerhetsartiklar.

  • Välj ett lämpligt redundansalternativ för dina återställningsbehov: Georedundant lagring (GRS/RA-GRS/GZRS/RA-GZRS) replikerar data till en parad region och stödjer kundinitierad failover för regional motståndskraft. Zonredundant lagring (ZRS/GZRS) skyddar mot zonnivåfel inom en region. Mer information finns i Azure Storage-redundans.

  • Lita inte på geo-redundans för skydd mot ransomware: Geo-redundant replikering speglar data – och eventuell korruption eller skadlig radering – till den parade regionen. Kombinera GRS med oföränderlighetspolicyer, mjuk borttagning och versionshantering för ransomware och manipulationsskydd. För mer information, se Data protection features in Azure Storage.

  • Öva kundinitierad failover och failback: För konton med RA-GRS eller RA-GZRS, kör en planerad failover-övning för att validera din återställningsprocedur innan du behöver den. Mer information finns i Haveriberedskap och felöverföring för lagringskonton.

För säkerhetsvägledning specifik för varje Azure Storage-datatjänst, se:

Nästa steg

  • Uppdaterades senast