Udělení omezeného přístupu Azure Storage prostředkům pomocí sdílených přístupových podpisů (SAS)

Sdílený přístupový podpis (SAS) poskytuje zabezpečený delegovaný přístup k prostředkům v účtu úložiště. Pomocí SAS máte podrobnou kontrolu nad tím, jak může klient přistupovat k vašim datům. Například:

• K jakým prostředkům má klient přístup.

• Jaká oprávnění mají k těmito prostředkům.

• Jak dlouho je SAS platný

Typy sdílených přístupových podpisů

Azure Storage podporuje tři typy sdílených přístupových podpisů:

• SAS delegování uživatele

• SAS služby

• SAS účtu

SAS delegování uživatele

SAS delegování uživatele je zabezpečen Azure Active Directory přihlašovacími údaji (Azure AD) a také oprávněními zadanými pro SAS. SAS delegování uživatele se vztahuje pouze na úložiště objektů blob.

Další informace o SAS delegování uživatele najdete v tématu Vytvoření SAS delegování uživatele (REST API).

SAS služby

Sas služby je zabezpečený pomocí klíče účtu úložiště. SAS služby deleguje přístup k prostředku pouze v jedné z Azure Storage služeb: Blob Storage, Queue Storage, Table Storage nebo Azure Files.

Další informace o SAS služby najdete v tématu Vytvoření SAS služby (REST API).

SAS účtu

SAS účtu je zabezpečený pomocí klíče účtu úložiště. SAS účtu deleguje přístup k prostředkům v jedné nebo více službách úložiště. Všechny operace dostupné prostřednictvím služby nebo SAS delegování uživatele jsou také dostupné prostřednictvím SAS účtu.

Můžete také delegovat přístup k následujícím akcím:

• Operace na úrovni služby (například operace Get/Set Service Properties a Get Service Stats).

• Operace čtení, zápisu a odstranění, které nejsou povolené pomocí SAS služby.

Další informace o SAS účtu najdete v tématu Vytvoření SAS účtu (REST API).

Sdílený přístupový podpis může mít jednu z následujících dvou podob:

• Ad hoc SAS. Při vytváření ad hoc SAS se v identifikátoru URI SAS zadá čas spuštění, čas vypršení platnosti a oprávnění. Jakýkoli typ SAS může být ad hoc SAS.

• Sas služby s uloženými zásadou přístupu. Uložené zásady přístupu se definují v kontejneru prostředků, kterým může být kontejner objektů blob, tabulka, fronta nebo sdílená sdílená složky. Uložené zásady přístupu je možné použít ke správě omezení jednoho nebo více sdílených přístupových podpisů služby. Když přidružíte SAS služby k uloženým zásadám přístupu, zdědí SAS omezení pro čas spuštění, čas vypršení platnosti a oprávnění definovaná — — pro uložené zásady přístupu.

Jak sdílený přístupový podpis funguje

Sdílený přístupový podpis je podepsaný identifikátor URI, který odkazuje na jeden nebo více prostředků úložiště. Identifikátor URI obsahuje token, který obsahuje speciální sadu parametrů dotazu. Token určuje, jak může klient získat přístup k prostředkům. Jeden z parametrů dotazu, podpis, je vytvořený z parametrů SAS a podepsaný klíčem použitým k vytvoření SAS. Tento podpis používá Azure Storage k autorizaci přístupu k prostředku úložiště.

Podpis SAS a autorizace

Token SAS můžete podepsat pomocí klíče delegování uživatele nebo pomocí klíče účtu úložiště (sdílený klíč).

Podepsání tokenu SAS pomocí klíče delegování uživatele

Token SAS můžete podepsat pomocí klíče delegování uživatele vytvořeného pomocí přihlašovacích údajů Azure Active Directory (Azure AD). SAS delegování uživatele je podepsaný klíčem delegování uživatele.

Abyste získali klíč a pak vytvořili SAS, musí mít objekt zabezpečení Azure AD přiřazenou roli Azure, která zahrnuje Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey akci. Další informace najdete v tématu Vytvoření SAS delegování uživatele (REST API).

Podepsání tokenu SAS pomocí klíče účtu

SAS služby i SAS účtu jsou podepsané klíčem účtu úložiště. Pokud chcete vytvořit SAS, který je podepsaný klíčem účtu, musí mít aplikace přístup ke klíči účtu.

Pokud požadavek obsahuje token SAS, je tato žádost autorizována na základě způsobu podepsání tohoto tokenu SAS. Přístupový klíč nebo přihlašovací údaje, které použijete k vytvoření tokenu SAS, používá také Azure Storage k udělení přístupu klientovi, který sas vlastní.

Následující tabulka shrnuje, jak se autorizuje každý typ tokenu SAS.

Microsoft doporučuje používat SAS delegování uživatelů, pokud je to možné, pro zajištění špičkového zabezpečení.

Token SAS

Token SAS je řetězec, který vygenerujete na straně klienta, například pomocí jedné z Azure Storage klientských knihoven. Token SAS žádným způsobem nesleduje Azure Storage token SAS. Na straně klienta můžete vytvořit neomezený počet tokenů SAS. Jakmile vytvoříte SAS, můžete ho distribuovat do klientských aplikací, které vyžadují přístup k prostředkům ve vašem účtu úložiště.

Klientské aplikace poskytují identifikátor URI SAS Azure Storage jako součást požadavku. Potom služba zkontroluje parametry SAS a podpis a ověří, jestli jsou platné. Pokud služba ověří platnost podpisu, je žádost autorizována. Jinak se požadavek odmítne s kódem chyby 403 (Zakázáno).

Tady je příklad identifikátoru URI SAS služby, který zobrazuje identifikátor URI prostředku a token SAS. Vzhledem k tomu, že token SAS se skládá z řetězce dotazu URI, musí za identifikátorem URI prostředku nejprve následovat otazník a potom token SAS:

Kdy použít sdílený přístupový podpis

Pomocí SAS můžete poskytnout zabezpečený přístup k prostředkům ve vašem účtu úložiště všem klientům, kteří k těmito prostředkům nemají jinak oprávnění.

Běžný scénář, kdy je SAS užitečný, je služba, ve které uživatelé čtou a zapisují vlastní data do vašeho účtu úložiště. Ve scénáři, kde účet úložiště ukládá data uživatelů, existují dva typické modely návrhu:

1. Klienti nahrávají a stahují data přes front-endovou proxy službu, která provádí ověřování. Tato front-endová proxy služba umožňuje ověřování obchodních pravidel. Ale u velkých objemů dat nebo u velkokanáze transakcí může být vytvoření služby, která se může škálovat tak, aby odpovídala poptávce, nákladná nebo obtížná.

   

2. Zjednodušená služba podle potřeby ověří klienta a potom vygeneruje sdílený přístupový podpis. Jakmile klientská aplikace obdrží SAS, bude mít přímý přístup k prostředkům účtu úložiště. Přístupová oprávnění jsou definována sas a po dobu povolenou SAS. Sdílený přístupový podpis snižuje potřebu směrování všech dat přes front-endovou proxy službu.

   

Mnoho služeb z reálného světa může využít hybridní z těchto dvou přístupů. Některá data se například můžou zpracovávat a ověřovat přes front-endový proxy server. Jiná data se ukládají nebo čtou přímo pomocí SAS.

Navíc se v určitých scénářích vyžaduje SAS k autorizaci přístupu ke zdrojovému objektu v operaci kopírování:

• Při kopírování objektu blob do jiného objektu blob, který se nachází v jiném účtu úložiště.

  Volitelně můžete k autorizaci přístupu k cílovému objektu blob použít také SAS.

• Při kopírování souboru do jiného souboru, který se nachází v jiném účtu úložiště.

  Volitelně můžete k autorizaci přístupu k cílovému souboru použít také SAS.

• Při kopírování objektu blob do souboru nebo souboru do objektu blob.

  Sas musíte použít i v případě, že se zdrojové a cílové objekty nacházejí ve stejném účtu úložiště.

Osvědčené postupy při používání SAS

Když ve svých aplikacích používáte sdílené přístupové podpisy, musíte si být vědomi dvou potenciálních rizik:

• Pokud dojde k úniku SAS, může ho použít kdokoli, kdo ho získá, což může potenciálně ohrozit váš účet úložiště.

• Pokud vyprší platnost SAS poskytnutého klientské aplikaci a aplikace nemůže z vaší služby načíst nový SAS, může to bránit fungování aplikace.

Následující doporučení pro používání sdílených přístupových podpisů můžou pomoct tato rizika zmírnit:

• K vytvoření nebo distribuci SAS vždy používejte HTTPS. Pokud se SAS předá přes protokol HTTP a zachytí, útočník, který provádí útok prostředníka, může SAS přečíst. Potom mohou tento SAS použít stejně, jako by to mohl mít zamýšlený uživatel. To může potenciálně ohrozit citlivá data nebo umožnit poškození dat uživateli se zlými úmysly.

• Pokud je to možné, používejte SAS delegování uživatele. SAS delegování uživatele poskytuje špičkové zabezpečení SAS služby nebo SAS účtu. Sas delegování uživatele je zabezpečený pomocí přihlašovacích údajů Azure AD, takže není nutné ukládat klíč účtu s vaším kódem.

• Musí mít pro SAS plán odvolání. Ujistěte se, že jste připraveni reagovat na ohrožení zabezpečení SAS.

• Definujte uložené zásady přístupu pro SAS služby. Uložené zásady přístupu poskytují možnost odvolat oprávnění pro SAS služby, aniž byste museli znovu generovat klíče účtu úložiště. Nastavte vypršení platnosti na tyto velmi daleko v budoucnu (nebo nekonečné) a ujistěte se, že je pravidelně aktualizován, aby se posunul dál do budoucnosti.

• U ad hoc SAS služby SAS nebo SAS účtu používejte dobu vypršení platnosti v blízké době platnosti. Tímto způsobem platí, že i když dojde k ohrožení zabezpečení SAS, je platný pouze po krátkou dobu. Tento postup je zvlášť důležitý, pokud nemůžete odkazovat na uložené zásady přístupu. Blízké vypršení platnosti také omezuje množství dat, která lze zapsat do objektu blob, omezením dostupného času pro nahrání do objektu blob.

• V případě potřeby mají klienti automaticky obnovovat SAS. Klienti by měli sas prodloužit těsně před vypršením platnosti, aby se v případě nedostupné služby, která SAS poskytuje, měla čas na opakování. V některých případech to může být zbytečné. Můžete například chtít, aby se SAS používal pro malý počet okamžitých a krátkodobých operací. Očekává se, že tyto operace budou dokončeny během doby vypršení platnosti. V důsledku toho neočekáváte prodloužení platnosti SAS. Pokud ale máte klienta, který pravidelně zasažuje požadavky přes SAS, může se stát, že vyprší platnost.

• Při zahájení SAS buďte opatrní. Pokud nastavíte čas spuštění SAS na aktuální čas, může k selháním docházet přerušovaně v prvních několika minutách. Je to způsobeno tím, že různé počítače mají mírně odlišnou aktuální dobu (označuje se jako zkosení hodin). Obecně platí, že počáteční čas nastavte na alespoň 15 minut v minulosti. Nebo ji vůbec nastavujte, aby byla ve všech případech okamžitě platná. To samé platí i pro dobu vypršení platnosti – mějte na paměti, že u libovolného požadavku můžete sledovat až 15minutový zkosení hodin v obou směrech. Pro klienty, kteří používají verzi REST před 12. 2. 2012, je maximální doba trvání SAS, která neodkašuje na uložené zásady přístupu, 1 hodina. Všechny zásady, které určují delší období než 1 hodinu, selžou.

• Při formátování data a času SAS buďte opatrní. U některých nástrojů (například AzCopy) potřebujete formáty data a času na +%Y-%m-%dT%H:%M:%SZ. Tento formát konkrétně zahrnuje sekundy.

• Konkrétní informace o prostředku, ke kterým chcete získat přístup. Osvědčeným postupem zabezpečení je poskytnout uživateli minimální požadovaná oprávnění. Pokud uživatel potřebuje přístup ke čtení jenom k jedné entitě, udělte jim přístup pro čtení k této jediné entitě, a ne ke čtení, zápisu nebo odstranění ke všem entitám. To také pomáhá snížit škody v případě ohrožení SAS, protože SAS má menší výkon v rukou útočníka.

• Je třeba mít na paměti, že se na váš účet bude účtovat veškeré využití, a to i prostřednictvím SAS. Pokud objektu blob poskytnete přístup pro zápis, uživatel se může rozhodnout nahrát 200GB objekt blob. Pokud jste jim také dali přístup pro čtení, mohou si ho stáhnout 10krát, takže vám budou účtovány 2 TB náklady na přenos dat. Opět poskytněte omezená oprávnění, která vám pomůžou zmírnit potenciální akce uživatelů se zlými úmysly. Využijte krátkodobý SAS ke snížení této hrozby (ale pozor na zkosení hodin v koncovém čase).

• Ověření zapisovaných dat pomocí SAS Když klientská aplikace zapisuje data do vašeho účtu úložiště, mějte na paměti, že s daty mohou být problémy. Pokud máte v plánu data ověřit, proveďte toto ověření po zápisu dat a před jejich použitím vaší aplikací. Tento postup také chrání před poškozenými nebo škodlivými daty, která se zapisují do vašeho účtu, a to buď uživatelem, který SAS správně získal, nebo uživatelem, který zneužívá prozrazený SAS.

• Vědět, kdy se nemá používat SAS Někdy rizika spojená s konkrétní operací s vaším účtem úložiště převažují nad výhodami použití SAS. Pro tyto operace vytvořte službu střední vrstvy, která po ověření, ověřování a auditování obchodních pravidel zapisuje do vašeho účtu úložiště. Někdy je také jednodušší spravovat přístup jinými způsoby. Pokud například chcete, aby všechny objekty blob v kontejneru bylo veřejně čitelné, můžete kontejner nastavit jako veřejný, místo abyste každému klientovi poskytovali sas pro přístup.

• Pomocí Azure Monitor a Azure Storage můžete monitorovat svou aplikaci. K selhání autorizace může dojít kvůli výpadku služby poskytovatele SAS. Může k nim dojít také při neúmyslné odebrání uložených zásad přístupu. Pomocí protokolování Azure Monitor a analýzy úložiště můžete sledovat špičky v těchto typech selhání autorizace. Další informace najdete v tématu Azure Storage metriky v Azure Monitor a Azure Storage Analytics.

Začínáme se SAS

Pokud chcete začít používat sdílené přístupové podpisy, podívejte se na následující články pro jednotlivé typy SAS.

SAS delegování uživatele

• Vytvoření SAS delegování uživatele pro kontejner nebo objekt blob pomocí PowerShellu
• Vytvoření SAS delegování uživatele pro kontejner nebo objekt blob pomocí Azure CLI
• Vytvoření SAS delegování uživatele pro kontejner nebo objekt blob pomocí .NET

SAS služby

• Vytvoření SAS služby pro kontejner nebo objekt blob pomocí .NET

SAS účtu

• Vytvoření SAS účtu pomocí .NET

Další kroky

• Delegování přístupu pomocí sdíleného přístupového podpisu (REST API)
• Vytvoření SAS delegování uživatele (REST API)
• Vytvoření SAS služby (REST API)
• Vytvoření SAS účtu (REST API)