Anvend bedste praksis for sikkerhed i Azure Storage
Vi har gennemgået, hvordan du opretter og arbejder med en SAS (Shared Access Signature) og de fordele, det kan give din lagersikkerhedsløsning.
Det er vigtigt at forstå, at når du bruger en SAS i dit program, kan der være potentielle risici.
Hvis en SAS er kompromitteret, kan alle, der får den, få adgang til lageret.
Hvis en SAS, der leveres til et klientprogram, udløber, og programmet ikke kan hente en ny SAS fra din tjeneste, kan programfunktionaliteten blive forhindret.
Se denne video for at få flere idéer til, hvordan du sikrer dit lager. Denne video er baseret på Azure Tips and Tricks #272 Azure Security Best Practices.
Anbefalinger til administration af risici
Lad os se på nogle anbefalinger, der kan hjælpe med at afhjælpe risici, når du arbejder med en SAS.
Anbefaling | Beskrivelse |
---|---|
Brug altid HTTPS til oprettelse og distribution | Hvis en SAS overføres via HTTP og opfanges, kan en hacker opfange og bruge SAS. Disse man-in-the-middle-angreb kan kompromittere følsomme data eller tillade beskadigelse af data af den ondsindede bruger. |
Reference gemte adgangspolitikker, hvor det er muligt, | Politikker for gemt adgang giver dig mulighed for at tilbagekalde tilladelser uden at skulle genoprette Azure Storage-kontonøglerne. Angiv udløbsdatoen for lagerkontoens nøgle langt i fremtiden. |
Angiv udløbstider på kort sigt for en ikke-planlagt SAS- | Hvis en SAS er kompromitteret, kan du afhjælpe angreb ved at begrænse SAS's gyldighed til kort tid. Denne praksis er vigtig, hvis du ikke kan referere til en gemt adgangspolitik. Udløbstider på kort sigt begrænser også mængden af data, der kan skrives til en blob, ved at begrænse den tid, der er tilgængelig til upload til den. |
Kræv, at klienter automatisk fornyer SAS- | Kræv, at dine kunder fornyer SAS i god tid før udløbsdatoen. Ved at forny tidligt giver du tid til nye forsøg, hvis den tjeneste, der leverer SAS, ikke er tilgængelig. |
Planlæg SAS's starttidspunkt omhyggeligt | Hvis du angiver starttidspunktet for en SAS til nu, kan fejl blive observeret med mellemrum i de første par minutter på grund af urets skævhed (forskelle i det aktuelle klokkeslæt i henhold til forskellige maskiner). Generelt skal du angive starttidspunktet til mindst 15 minutter i fortiden. Eller undlad at angive et bestemt starttidspunkt, hvilket medfører, at SAS er gyldig med det samme i alle tilfælde. De samme betingelser gælder generelt for udløbstidspunktet. Du kan se op til 15 minutters ur skæv i begge retninger på enhver anmodning. For klienter, der bruger en REST API-version, der er ældre end 2012-02-12, er den maksimale varighed for en SAS, der ikke refererer til en lagret adgangspolitik, 1 time. Alle politikker, der angiver en længere periode, mislykkes. |
Definer minimumadgangstilladelser for ressourcer | En bedste praksis for sikkerhed er at give en bruger de minimumsrettigheder, der kræves. Hvis en bruger kun har brug for læseadgang til et enkelt objekt, skal du give brugeren læseadgang til det enkelte objekt og ikke læse/skrive/slette adgang til alle objekter. Denne praksis hjælper også med at mindske skaden, hvis en SAS kompromitteres, fordi SAS har mindre magt i hænderne på en hacker. |
Forstå kontofakturering for forbrug, herunder et SAS- | Giv begrænsede tilladelser for at hjælpe med at afhjælpe ondsindede brugeres potentielle handlinger. Læse- og skrivetilladelser kan medføre faktureringsgebyrer. Brug en kortlivet SAS til at reducere denne trussel. |
Valider data, der er skrevet ved hjælp af et SAS- | Når et klientprogram skriver data til din Azure Storage-konto, skal du være opmærksom på, at der kan være problemer med dataene. Hvis dit program kræver validerede eller godkendte data, skal du validere dataene efter skriftlig, men før de bruges. Denne praksis beskytter også mod, at beskadigede eller skadelige data skrives til din konto, enten af en bruger, der har erhvervet SAS korrekt, eller af en bruger, der udnytter en lækket SAS. |
Antag ikke, at sas altid er det rigtige valg | I nogle scenarier opvejer de risici, der er knyttet til en bestemt handling i forhold til din Azure Storage-konto, fordelene ved at bruge en SAS. I forbindelse med sådanne handlinger skal du oprette en tjeneste på mellemniveau, der skriver til din lagerkonto, når du har udført validering, godkendelse og overvågning af forretningsregel. Nogle gange er det også nemmere at administrere adgang på andre måder. Hvis du vil gøre alle blobs i en objektbeholder offentligt læsbare, kan du gøre objektbeholderen offentlig i stedet for at angive en SAS til alle klienter for at få adgang. |
Overvåg dine programmer med Azure Storage Analytics- | Du kan bruge logføring og målepunkter til at observere enhver stigning i godkendelsesfejl. Du kan muligvis se stigninger fra et udfald i din SAS-udbydertjeneste eller til utilsigtet fjernelse af en gemt adgangspolitik. |