Dela via

Lagringskonton och tillförlitlighet

  • Artikel

Azure Storage-konton är idealiska för arbetsbelastningar som kräver snabba och konsekventa svarstider, eller som har ett stort antal åtgärder för indatautdata (IOP) per sekund. Lagringskonton innehåller alla dina Azure Storage-dataobjekt, bland annat:

  • Blobar
  • Filresurser
  • Köer
  • Tabeller
  • Diskar

Lagringskonton ger ett unikt namnområde för dina data som är tillgängliga var som helst över HTTP eller HTTPS.

Mer information om de olika typerna av lagringskonton som stöder olika funktioner finns i Typer av lagringskonton.

Information om hur ett Azure Storage-konto stöder återhämtning för din programarbetsbelastning finns i följande artiklar:

Följande avsnitt innehåller designöverväganden, en checklista för konfiguration och rekommenderade konfigurationsalternativ som är specifika för Azure Storage-konton och tillförlitlighet.

Designöverväganden

Azure Storage-konton omfattar följande designöverväganden:

  • Allmänna v1-lagringskonton ger åtkomst till alla Azure Storage-tjänster, men kanske inte har de senaste funktionerna eller lägre priser per gigabyte. Vi rekommenderar i de flesta fall att använda allmänna v2-lagringskonton. Orsaker till att använda v1 är:

    • Program kräver den klassiska distributionsmodellen.
    • Program är transaktionsintensiva eller använder betydande geo-replikeringsbandbredd, men kräver inte stor kapacitet.
    • Användning av ett REST-API för lagringstjänsten som är tidigare än den 14 februari 2014 eller ett klientbibliotek med en tidigare version än 4.x vad som krävs. En programuppgradering är inte möjlig.

Mer information finns i översikten över lagringskontot.

  • Lagringskontonamn måste vara mellan tre och 24 tecken och får endast innehålla siffror och gemener.
  • För aktuella SLA-specifikationer, referens-SLA för lagringskonton.
  • Gå till Azure Storage-redundans för att avgöra vilket redundansalternativ som är bäst för ett specifikt scenario.
  • Lagringskontonamn måste vara unika i Azure. Det får inte finnas två lagringskonton med samma namn.

Checklista

Har du konfigurerat ditt Azure Storage-konto med tillförlitlighet i åtanke?

  • Aktivera mjuk borttagning för blobdata.
  • Använd Microsoft Entra-ID för att auktorisera åtkomst till blobdata.
  • Överväg principen om lägsta behörighet när du tilldelar behörigheter till ett Microsoft Entra säkerhetsobjekt via Azure RBAC.
  • Använd hanterade identiteter för att komma åt blob- och ködata.
  • Använd blobversionshantering eller oföränderliga blobar för att lagra affärskritiska data.
  • Begränsa standardåtkomsten till Internet för lagringskonton.
  • Aktivera brandväggsregler.
  • Begränsa nätverksåtkomsten till specifika nätverk.
  • Tillåt betrodda Microsoft-tjänster att komma åt lagringskontot.
  • Aktivera alternativet Säker överföring krävs på alla dina lagringskonton.
  • Begränsa sas-token (signatur för delad åtkomst) till HTTPS endast anslutningar.
  • Undvik och förhindra att du använder auktorisering för delad nyckel för att få åtkomst till lagringskonton.
  • Återskapa dina kontonycklar med jämna mellanrum.
  • Skapa en återkallningsplan och ha den på plats för alla SAS som du utfärdar till klienter.
  • Använd förfallotid på kort sikt på en improviserad SAS, tjänst-SAS eller konto-SAS.

Konfigurationsrekommendationer

Överväg följande rekommendationer för att optimera tillförlitligheten när du konfigurerar ditt Azure Storage-konto:

Rekommendation Description
Aktivera mjuk borttagning för blobdata. Med mjuk borttagning för Azure Storage-blobbar kan du återställa blobdata när de har tagits bort.
Använd Microsoft Entra-ID för att auktorisera åtkomst till blobdata. Microsoft Entra ID ger överlägsen säkerhet och enkel användning över delad nyckel för att auktorisera begäranden till bloblagring. Vi rekommenderar att du använder Microsoft Entra auktorisering med dina blob- och köprogram när det är möjligt för att minimera potentiella säkerhetsrisker i delad nyckel. Mer information finns i Auktorisera åtkomst till Azure-blobar och köer med hjälp av Microsoft Entra-ID.
Överväg principen om lägsta behörighet när du tilldelar behörigheter till ett Microsoft Entra säkerhetsobjekt via Azure RBAC. När du tilldelar en roll till en användare, grupp eller ett program beviljar du säkerhetsobjektet endast de behörigheter som krävs för att de ska kunna utföra sina uppgifter. Genom att begränsa åtkomsten till resurser kan du förhindra både oavsiktligt och skadligt missbruk av dina data.
Använd hanterade identiteter för att komma åt blob- och ködata. Azure Blob och Queue Storage stöder Microsoft Entra autentisering med hanterade identiteter för Azure-resurser. Hanterade identiteter för Azure-resurser kan auktorisera åtkomst till blob- och ködata med Microsoft Entra autentiseringsuppgifter från program som körs på virtuella Azure-datorer (VM), funktionsappar, VM-skalningsuppsättningar och andra tjänster. Genom att använda hanterade identiteter för Azure-resurser tillsammans med Microsoft Entra autentisering kan du undvika att lagra autentiseringsuppgifter med dina program som körs i molnet och problem med att tjänstens huvudnamn upphör att gälla. Mer information finns i Auktorisera åtkomst till blob- och ködata med hanterade identiteter för Azure-resurser .
Använd blobversionshantering eller oföränderliga blobar för att lagra affärskritiska data. Överväg att använda Blob-versionshantering för att underhålla tidigare versioner av ett objekt eller använda juridiska undantag och tidsbaserade kvarhållningsprinciper för att lagra blobdata i ett WORM-tillstånd (Skriv en gång, Läs många). Oföränderliga blobar kan läsas, men kan inte ändras eller tas bort under kvarhållningsintervallet. Mer information finns i Lagra affärskritiska blobdata med oföränderlig lagring.
Begränsa standardåtkomsten till Internet för lagringskonton. Som standard är nätverksåtkomsten till lagringskonton inte begränsad och är öppen för all trafik som kommer från Internet. Åtkomst till lagringskonton bör endast beviljas till specifika virtuella Azure-nätverk när det är möjligt eller använda privata slutpunkter så att klienter i ett virtuellt nätverk (VNet) kan komma åt data på ett säkert sätt via en Private Link. Referens Använd privata slutpunkter för Azure Storage för mer information. Undantag kan göras för lagringskonton som måste vara tillgängliga via Internet.
Aktivera brandväggsregler. Konfigurera brandväggsregler för att begränsa åtkomsten till ditt lagringskonto till begäranden som kommer från angivna IP-adresser eller intervall, eller från en lista över undernät i en Azure Virtual Network (VNet). Mer information om hur du konfigurerar brandväggsregler finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.
Begränsa nätverksåtkomsten till specifika nätverk. Om du begränsar nätverksåtkomsten till nätverk som är värdar för klienter som kräver åtkomst minskar dina resursers exponering för nätverksattacker, antingen med hjälp av den inbyggda brandväggen och de virtuella nätverken eller med hjälp av privata slutpunkter.
Tillåt betrodda Microsoft-tjänster att komma åt lagringskontot. Om du aktiverar brandväggsregler för lagringskonton blockeras inkommande begäranden för data som standard, såvida inte begäranden kommer från en tjänst som körs i en Azure Virtual Network (VNet) eller från tillåtna offentliga IP-adresser. Blockerade begäranden inkluderar dessa begäranden från andra Azure-tjänster, från Azure Portal, från loggnings- och måtttjänster och så vidare. Du kan tillåta begäranden från andra Azure-tjänster genom att lägga till ett undantag för att tillåta betrodda Microsoft-tjänster att komma åt lagringskontot. Mer information om hur du lägger till ett undantag för betrodda Microsoft-tjänster finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.
Aktivera alternativet Säker överföring krävs på alla dina lagringskonton. När du aktiverar alternativet Säker överföring krävs måste alla begäranden som görs mot lagringskontot ske via säkra anslutningar. Alla begäranden som görs via HTTP misslyckas. Mer information finns i Kräv säker överföring i Azure Storage.
Begränsa sas-token (signatur för delad åtkomst) till HTTPS endast anslutningar. Att kräva HTTPS när en klient använder en SAS-token för att komma åt blobdata hjälper till att minimera risken för avlyssning. Mer information finns i Bevilja begränsad åtkomst till Azure Storage-resurser med hjälp av signaturer för delad åtkomst (SAS).
Undvik och förhindra att du använder auktorisering för delad nyckel för att få åtkomst till lagringskonton. Vi rekommenderar att du använder Microsoft Entra-ID för att auktorisera begäranden till Azure Storage och förhindra auktorisering av delad nyckel. För scenarier som kräver auktorisering av delad nyckel föredrar du alltid SAS-token framför distribution av den delade nyckeln.
Återskapa dina kontonycklar med jämna mellanrum. Om du roterar kontonycklarna med jämna mellanrum minskar risken för att exponera dina data för skadliga aktörer.
Skapa en återkallningsplan och ha den på plats för alla SAS som du utfärdar till klienter. Om en SAS komprometteras vill du återkalla sas omedelbart. Återkalla en SAS för användardelegering genom att återkalla användarens delegeringsnyckel för att snabbt ogiltigförklara alla signaturer som är associerade med den nyckeln. Om du vill återkalla en tjänst-SAS som är associerad med en lagrad åtkomstprincip kan du ta bort den lagrade åtkomstprincipen, byta namn på principen eller ändra dess förfallotid till en tidigare tidpunkt.
Använd förfallotid på kort sikt på en improviserad SAS, tjänst-SAS eller konto-SAS. Om en SAS komprometteras är den endast giltig under en kort tid. Den här metoden är särskilt viktig om du inte kan referera till en lagrad åtkomstprincip. Närtidsförfallotider begränsar också mängden data som kan skrivas till en blob genom att begränsa den tid som är tillgänglig för uppladdning till den. Klienter bör förnya SAS långt före förfallodatumet för att ge tid för återförsök om tjänsten som tillhandahåller SAS inte är tillgänglig.

Nästa steg

Lagringskonton och säkerhet