Dela via

Säkerhetsguide för Azure Storage Explorer

Med Microsoft Azure Storage Explorer kan du enkelt arbeta med Azure Storage-data på ett säkert sätt i Windows, macOS och Linux. Genom att följa dessa riktlinjer kan du se till att dina data förblir skyddade.

Allmänt

  • Använd alltid den senaste versionen av Storage Explorer. Storage Explorer-versioner kan innehålla säkerhetsuppdateringar. Att hålla sig uppdaterad hjälper till att säkerställa allmän säkerhet.
  • Anslut endast till resurser som du litar på. Data som du laddar ned från ej betrodda källor kan vara skadliga och att ladda upp data till en ej betrodd källa kan leda till förlorade eller stulna data.
  • Använd HTTPS när det är möjligt. Storage Explorer använder HTTPS som standard. I vissa scenarier kan du använda HTTP, men HTTP bör endast användas som en sista utväg.
  • Se till att endast nödvändiga behörigheter ges till de personer som behöver dem. Undvik att vara alltför tillåtande när du ger någon åtkomst till dina resurser.
  • Var försiktig när du kör kritiska åtgärder. Vissa åtgärder, till exempel borttagning och överskrivning, är oåterkalleliga och kan orsaka dataförlust. Kontrollera att du arbetar med rätt resurser innan du kör de här åtgärderna.

Välja rätt autentiseringsmetod

Storage Explorer innehåller olika sätt att komma åt dina Azure Storage-resurser. Oavsett vilken metod du väljer, här är våra rekommendationer.

Microsoft Entra-autentisering

Det enklaste och säkraste sättet att komma åt dina Azure Storage-resurser är att logga in med ditt Azure-konto. När du loggar in används Microsoft Entra-autentisering, vilket gör att du kan:

  • Ge åtkomst till specifika användare och grupper.
  • Återkalla åtkomst till specifika användare och grupper när som helst.
  • Framtvinga åtkomstvillkor, till exempel att kräva multifaktorautentisering.

Vi rekommenderar att du använder Microsoft Entra-autentisering när det är möjligt.

I det här avsnittet beskrivs de två Microsoft Entra ID-baserade tekniker som kan användas för att skydda dina lagringsresurser:

  • Rollbaserad åtkomstkontroll i Azure (Azure RBAC)
  • Åtkomstkontrollistor (ACL)

Rollbaserad åtkomstkontroll i Azure

Med Azure RBAC får du detaljerad åtkomstkontroll över dina Azure-resurser. Azure-roller och -behörigheter kan hanteras från Azure Portal.

Du kan läsa mer om Azure RBAC; se Rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Storage Explorer har stöd för Azure RBAC-åtkomst till lagringskonton, blobar, köer och tabeller. Om du behöver åtkomst till filresurser måste du tilldela Azure-roller som ger behörighet att lista lagringskontonycklar.

Listor för åtkomstkontroll

Med åtkomstkontrollistor (ACL: er) kan du styra åtkomst på fil- och mappnivå i ADLS-blobcontainrar. Du kan hantera dina ACL:er med Storage Explorer.

Signaturer för delad åtkomst (SAS)

Om du inte kan använda Microsoft Entra-autentisering rekommenderar vi att du använder signaturer för delad åtkomst. Med signaturer för delad åtkomst kan du:

  • Ge anonym begränsad åtkomst till säkra resurser.
  • Återkalla en SAS omedelbart om den genereras från en princip för delad åtkomst (SAP).

Men med signaturer för delad åtkomst kan du inte:

  • Begränsa vem som kan använda en SAS. Alla som har en giltig SAS kan använda den.
  • Återkalla en SAS om den inte genereras från en princip för delad åtkomst (SAP).

När du använder SAS i Storage Explorer rekommenderar vi följande riktlinjer:

  • Begränsa fördelningen av SAS-token och URI:er. Distribuera endast SAS-token och URI:er till betrodda individer. Om SAS-distributionen begränsas minskar risken för att en SAS missbrukas.
  • Använd endast SAS-token och URI:er från entiteter som du litar på.
  • Använd principer för delad åtkomst (SAP) när du genererar SAS-token och URI:er om möjligt. En SAS som baseras på en princip för delad åtkomst är säkrare än en tom SAS eftersom SAS kan återkallas genom att ta bort SAP.
  • Generera token med minimal resursåtkomst och behörigheter. Minimala behörigheter begränsar den potentiella skada som kan göras om en SAS missbrukas.
  • Generera token som endast är giltiga så länge som det behövs. En kort livslängd är särskilt viktig för bare SAS, eftersom det inte finns något sätt att återkalla dem när de har genererats.

Viktigt!

När du delar SAS-token och URI:er i felsökningssyfte, till exempel i tjänstbegäranden eller buggrapporter, redigerar du alltid minst signaturdelen av SAS.

Lagringskontonycklar

Lagringskontonycklar ger obegränsad åtkomst till tjänsterna och resurserna i ett lagringskonto. Därför rekommenderar vi att du begränsar användningen av nycklar för att komma åt resurser i Storage Explorer. Använd Azure RBAC-funktioner eller SAS för att ge åtkomst i stället.

Vissa Azure-roller ger behörighet att hämta lagringskontonycklar. Personer med dessa roller kan effektivt kringgå behörigheter som beviljats eller nekats av Azure RBAC. Vi rekommenderar att du inte beviljar den här behörigheten om det inte är nödvändigt.

Storage Explorer försöker använda lagringskontonycklar, om det är tillgängligt, för att autentisera begäranden. Du kan inaktivera den här funktionen i Inställningar (Tjänstlagringskonton >> Inaktivera användning av nycklar). Vissa funktioner stöder inte Azure RBAC, till exempel att arbeta med klassiska lagringskonton. Den här inställningen påverkar inte funktioner som fortfarande kräver nycklar.

Om du måste använda nycklar för att komma åt dina lagringsresurser rekommenderar vi följande riktlinjer:

  • Dela inte dina kontonycklar med någon.
  • Behandla dina lagringskontonycklar som lösenord. Om du måste göra dina nycklar tillgängliga använder du säkra lagringslösningar som Azure Key Vault.

Kommentar

Om du tror att en lagringskontonyckel har delats eller distribuerats oavsiktligt kan du generera nya nycklar för ditt lagringskonto från Azure-portalen.

Anonym åtkomst till blobcontainrar

Med Storage Explorer kan du ändra åtkomstnivån för dina Azure Blob Storage-containrar. Icke-privata blobcontainrar ger alla anonym läsåtkomst till data i dessa containrar.

När du aktiverar anonym åtkomst för en blobcontainer rekommenderar vi följande riktlinjer:

  • Aktivera inte anonym åtkomst till en blobcontainer som kan innehålla potentiellt känsliga data. Kontrollera att blobcontainern är fri från alla privata data.
  • Överför inte potentiellt känsliga data till en blobcontainer med blob- eller containeråtkomst.

Nästa steg