Tillämpa metodtips för Azure Storage-säkerhet
Vi har gått igenom hur du skapar och arbetar med en signatur för delad åtkomst (SAS) och vilka fördelar den kan ge din lagringssäkerhetslösning.
Det är viktigt att förstå att det kan finnas potentiella risker när du använder en SAS i ditt program.
Om en SAS komprometteras kan alla som hämtar den komma åt lagringen.
Om en SAS som tillhandahålls till ett klientprogram upphör att gälla och programmet inte kan hämta en ny SAS från din tjänst kan programfunktionen hindras.
Titta på den här videon om du vill ha fler idéer om hur du skyddar din lagring. Den här videon baseras på Azure Tips and Tricks #272 Azure Security Best Practices.
Rekommendationer för att hantera risker
Nu ska vi titta på några rekommendationer som kan bidra till att minska riskerna när du arbetar med en SAS.
Rekommendation | beskrivning |
---|---|
Använd alltid HTTPS för att skapa och distribuera | Om en SAS skickas via HTTP och fångas upp kan en angripare fånga upp och använda SAS. Dessa man-in-the-middle-attacker kan kompromettera känsliga data eller tillåta skadade data av den skadliga användaren. |
Referera till lagrade åtkomstprinciper där det är möjligt | Med lagrade åtkomstprinciper kan du återkalla behörigheter utan att behöva återskapa Azure Storage-kontonycklarna. Ange förfallodatum för lagringskontonyckeln långt i framtiden. |
Ange förfallotider på kort sikt för en oplanerad SAS | Om en SAS komprometteras kan du minimera attacker genom att begränsa SAS-giltigheten till en kort tid. Den här metoden är 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. |
Kräv att klienter förnyar SAS automatiskt | Kräv att dina klienter förnyar SAS långt före förfallodatumet. Genom att förnya tidigt ger du tid för återförsök om tjänsten som tillhandahåller SAS inte är tillgänglig. |
Planera noggrant för SAS-starttiden | Om du anger starttiden för en SAS till nu kan fel observeras tillfälligt under de första minuterna på grund av klocksnedvridning (skillnader i aktuell tid enligt olika datorer). I allmänhet anger du starttiden till minst 15 minuter tidigare. Eller ange inte en specifik starttid, vilket gör att SAS är giltigt omedelbart i alla fall. Samma villkor gäller vanligtvis för förfallotiden. Du kan se upp till 15 minuters klocksnedställning i båda riktningarna på alla begäranden. För klienter som använder en REST API-version tidigare än 2012-02-12 är den maximala varaktigheten för en SAS som inte refererar till en lagrad åtkomstprincip 1 timme. Principer som anger ett mer långsiktigt fel. |
Definiera minsta åtkomstbehörigheter för resurser | Bästa praxis för säkerhet är att ge en användare de lägsta behörigheter som krävs. Om en användare bara behöver läsåtkomst till en enda entitet ger du dem läsbehörighet till den enskilda entiteten och inte läs-/skriv-/borttagningsåtkomst till alla entiteter. Den här metoden hjälper också till att minska skadan om en SAS komprometteras eftersom SAS har mindre ström i händerna på en angripare. |
Förstå kontofakturering för användning, inklusive en SAS | Ge begränsade behörigheter för att minimera potentiella åtgärder från skadliga användare. Läs- och skrivbehörigheter kan orsaka faktureringsavgifter. Använd en kortlivad SAS för att minska det här hotet. |
Verifiera data som skrivits med hjälp av en SAS | När ett klientprogram skriver data till ditt Azure Storage-konto bör du tänka på att det kan uppstå problem med data. Om programmet kräver verifierade eller auktoriserade data verifierar du data efter att de har skrivits, men innan de används. Den här metoden skyddar också mot att skadade eller skadliga data skrivs till ditt konto, antingen av en användare som har skaffat SAS korrekt eller av en användare som utnyttjar en läckt SAS. |
Anta inte att en SAS alltid är rätt val | I vissa scenarier uppväger riskerna med en viss åtgärd mot ditt Azure Storage-konto fördelarna med att använda en SAS. För sådana åtgärder skapar du en mellannivåtjänst som skriver till ditt lagringskonto när du har utfört validering, autentisering och granskning av affärsregler. Ibland är det också enklare att hantera åtkomst på andra sätt. Om du vill göra alla blobar i en container offentligt läsbara kan du göra containern offentlig i stället för att tillhandahålla en SAS till varje klient för åtkomst. |
Övervaka dina program med Azure Lagringsanalys | Du kan använda loggning och mått för att observera eventuella toppar i autentiseringsfel. Du kan se toppar från ett avbrott i SAS-providertjänsten eller till oavsiktlig borttagning av en lagrad åtkomstprincip. |