Megosztás a következőn keresztül:

Korlátozott hozzáférés engedélyezése az Azure Storage-erőforrásokhoz közös hozzáférésű jogosultságkódokkal

  • Cikk

A megosztott hozzáférésű jogosultságkód (SAS) biztonságos delegált hozzáférést biztosít a tárfiók erőforrásaihoz. Sas használatával részletesen szabályozhatja, hogy egy ügyfél hogyan férhet hozzá az adataihoz. Példa:

  • Milyen erőforrásokhoz férhet hozzá az ügyfél.

  • Milyen engedélyekkel rendelkeznek ezekhez az erőforrásokhoz.

  • Az SAS érvényességének hossza.

A közös hozzáférésű jogosultságkódok típusai

Az Azure Storage háromféle közös hozzáférésű jogosultságkódot támogat:

  • Felhasználói delegálási SAS

  • Service SAS

  • Fiók SAS-fiókja

Fontos

Megosztott hozzáférésű jogosultságkódok használata esetén a Microsoft a felhasználói delegálási SAS használatát javasolja. A felhasználói delegálási SAS-t a fiókkulcs helyett a Microsoft Entra hitelesítő adatai védik, ami kiváló biztonságot nyújt. Az adathozzáférés engedélyezéséről további információt az Adatokhoz való hozzáférés engedélyezése az Azure Storage-ban című témakörben talál.

Felhasználói delegálási SAS

A felhasználói delegálási SAS-t a Microsoft Entra hitelesítő adatai, valamint az SAS-hez megadott engedélyek védik. A felhasználói delegálási SAS csak a Blob Storage-ra vonatkozik.

További információ a felhasználói delegálási SAS-ről: Felhasználói delegálási SAS (REST API) létrehozása.

Service SAS

A szolgáltatás SAS-t a tárfiók kulccsal védik. A szolgáltatás SAS csak az egyik Azure Storage-szolgáltatásban delegálja az erőforráshoz való hozzáférést: Blob Storage, Queue Storage, Table Storage vagy Azure Files.

A szolgáltatás SAS-ről további információt a Szolgáltatás SAS (REST API) létrehozása című témakörben talál.

Fiók SAS-fiókja

A fiók SAS-jének biztonságát a tárfiókkulcs biztosítja. A fiókalapú SAS egy vagy több tárolószolgáltatás erőforrásaihoz nyújt hozzáférést. A szolgáltatáson vagy a felhasználói delegálási SAS-en keresztül elérhető összes művelet egy fiók SAS-ével is elérhető.

Az alábbiakhoz is delegálhat hozzáférést:

  • Szolgáltatásszintű műveletek (például a Szolgáltatás tulajdonságainak lekérése/beállítása és a Szolgáltatásstatisztikák lekérése ).

  • Olyan műveletek olvasása, írása és törlése, amelyek nem engedélyezettek a szolgáltatás SAS-jével.

A fiók SAS-ével kapcsolatos további információkért hozzon létre egy fiók SAS-t (REST API).

A közös hozzáférésű jogosultságkódok a következő két űrlap egyikét használhatják:

  • Alkalmi SAS. Alkalmi SAS létrehozásakor a kezdő időpont, a lejárati idő és az engedélyek meg lesznek adva az SAS URI-ban. Bármilyen típusú SAS lehet alkalmi SAS.

  • Szolgáltatás SAS tárolt hozzáférési szabályzattal. A tárolt hozzáférési szabályzat egy erőforrástárolón van definiálva, amely lehet blobtároló, tábla, üzenetsor vagy fájlmegosztás. A tárolt hozzáférési szabályzat egy vagy több szolgáltatás közös hozzáférésű jogosultságkódjának korlátozásainak kezelésére használható. Ha egy szolgáltatás SAS-ét egy tárolt hozzáférési szabályzathoz társítja, az SAS örökli a tárolt hozzáférési szabályzathoz definiált korlátozásokat – a kezdési időpontot, a lejárati időt és az engedélyeket.

Feljegyzés

A felhasználói delegálási SAS-nek vagy fiók SAS-nek alkalmi SAS-nek kell lennie. A tárolt hozzáférési szabályzatok nem támogatottak a felhasználói delegálási SAS-ben vagy a fiók SAS-ében.

A közös hozzáférésű jogosultságkód működése

A megosztott hozzáférésű jogosultságkód egy olyan jogkivonat, amely hozzá van fűzve egy Azure Storage-erőforrás URI-hoz. A lekérdezési paraméterek speciális készletét tartalmazó jogkivonat, amely azt jelzi, hogy az ügyfél hogyan érheti el az erőforrásokat. Az egyik lekérdezési paraméter, az aláírás az SAS-paraméterekből jön létre, és az SAS létrehozásához használt kulccsal van aláírva. Az Azure Storage ezt az aláírást használja a tárolási erőforráshoz való hozzáférés engedélyezéséhez.

Feljegyzés

Az SAS-jogkivonatok generációjának naplózása nem lehetséges. Bármely felhasználó, aki jogosult SAS-jogkivonat létrehozására, akár a fiókkulcs használatával, akár azure-beli szerepkör-hozzárendeléssel, a tárfiók tulajdonosának tudta nélkül is megteheti. Ügyeljen arra, hogy korlátozza azokat az engedélyeket, amelyek lehetővé teszik, hogy a felhasználók SAS-jogkivonatokat generáljanak. Ha meg szeretné akadályozni, hogy a felhasználók olyan SAS-t generáljanak, amely a blob- és üzenetsor-számítási feladatok fiókkulcsával van aláírva, letilthatja a megosztott kulcs hozzáférését a tárfiókhoz. További információt a Megosztott kulccsal történő engedélyezés megakadályozása című témakörben talál.

SAS-aláírás és engedélyezés

Sas-jogkivonatot felhasználói delegálási kulccsal vagy tárfiókkulcskal (megosztott kulccsal) írhat alá.

SAS-jogkivonat aláírása felhasználói delegálási kulccsal

SAS-jogkivonatot a Microsoft Entra hitelesítő adataival létrehozott felhasználói delegálási kulccsal írhat alá. A felhasználódelegálási SAS a felhasználói delegálási kulccsal van aláírva.

A kulcs lekéréséhez, majd az SAS létrehozásához egy Microsoft Entra biztonsági tagnak hozzá kell rendelnie egy Azure-szerepkört, amely tartalmazza a Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey műveletet. További információ: Felhasználói delegálási SAS (REST API) létrehozása.

SAS-jogkivonat aláírása fiókkulccsal

A szolgáltatás SAS és a fiók SAS is a tárfiók kulccsal van aláírva. A fiókkulccsal aláírt SAS létrehozásához az alkalmazásnak hozzá kell férnie a fiókkulcshoz.

Ha egy kérés SAS-jogkivonatot tartalmaz, a kérés az SAS-jogkivonat aláírása alapján lesz engedélyezve. Az Sas-jogkivonat létrehozásához használt hozzáférési kulcsot vagy hitelesítő adatokat az Azure Storage is használja az SAS-t birtokló ügyfél számára való hozzáférés biztosításához.

Az alábbi táblázat összefoglalja, hogyan engedélyezve van az egyes SAS-jogkivonatok típusa.

Sas típusa Az engedélyezés típusa
Felhasználódelegálási SAS (csak Blob Storage) Microsoft Entra ID
Service SAS Megosztott kulcs
Fiók SAS-fiókja Megosztott kulcs

A Microsoft azt javasolja, hogy lehetőség szerint használjon felhasználói delegálási SAS-t a magasabb szintű biztonság érdekében.

SAS-jogkivonat

Az SAS-jogkivonat egy olyan sztring, amelyet az ügyféloldalon hoz létre, például az Azure Storage-ügyfélkódtárak egyikével. Az SAS-jogkivonatot az Azure Storage semmilyen módon nem követi nyomon. Korlátlan számú SAS-jogkivonatot hozhat létre az ügyféloldalon. Miután létrehozott egy SAS-t, eloszthatja azokat az ügyfélalkalmazásokban, amelyek hozzáférést igényelnek a tárfiók erőforrásaihoz.

Az ügyfélalkalmazások egy kérés részeként biztosítják az SAS URI-t az Azure Storage-nak. Ezután a szolgáltatás ellenőrzi az SAS-paramétereket és az aláírást annak ellenőrzéséhez, hogy érvényes-e. Ha a szolgáltatás ellenőrzi, hogy az aláírás érvényes-e, akkor a kérés engedélyezve van. Ellenkező esetben a rendszer elutasítja a kérést a 403-es (Tiltott) hibakóddal.

Íme egy példa egy szolgáltatás SAS URI-jára, amely az erőforrás URI-ját, az elválasztó karaktert ('?' ) és az SAS-jogkivonatot jeleníti meg.

Egy SAS-jogkivonattal rendelkező erőforrás-URI összetevőit bemutató ábra.

Feljegyzés

A lekérdezési sztring elválasztó karaktere ('?') nem része az SAS-jogkivonatnak. Ha SAS-jogkivonatot hoz létre a portálról, a PowerShellből, az Azure CLI-ből vagy valamelyik Azure Storage SDK-ból, előfordulhat, hogy hozzá kell fűznie az elválasztó karaktert az erőforrás URL-címéhez.

Mikor érdemes közös hozzáférésű jogosultságkódot használni?

Sas használatával biztonságos hozzáférést biztosíthat a tárfiók erőforrásaihoz minden olyan ügyfélnek, aki egyébként nem rendelkezik engedélyekkel ezekhez az erőforrásokhoz.

Gyakori eset, amikor az SAS hasznos egy olyan szolgáltatás, amelyben a felhasználók saját adatokat olvasnak és írnak a tárfiókba. Az olyan esetekben, amikor a tárfiók felhasználói adatokat tárol, két tipikus kialakítási minta létezik:

  1. Az ügyfelek egy hitelesítést végző, előtérbeli proxyszolgáltatással töltik fel- és le az adatokat. Ez az előtérbeli proxyszolgáltatás lehetővé teszi az üzleti szabályok érvényesítését. Nagy mennyiségű adat vagy nagy mennyiségű tranzakció esetén azonban a keresletnek megfelelő skálázható szolgáltatás létrehozása költséges vagy nehéz lehet.

    Forgatókönyvdiagram: Előtérbeli proxyszolgáltatás

  2. Egy egyszerű szolgáltatás hitelesíti az ügyfelet, majd létrehoz egy SAS-t. Miután az ügyfélalkalmazás megkapta az SAS-t, közvetlenül hozzáférhet a tárfiók erőforrásaihoz. A hozzáférési engedélyeket az SAS határozza meg, és az SAS által engedélyezett időközre vonatkozóan. Az SAS-szel nincs szükség az összes adat az előtérbeli proxyszolgáltatáson keresztül történő átirányítására.

    Forgatókönyvdiagram: SAS-szolgáltatói szolgáltatás

Számos valós szolgáltatás használhatja a két megközelítés hibrid használatát. Előfordulhat például, hogy egyes adatok az előtérbeli proxyn keresztül lesznek feldolgozva és érvényesítve. Más adatok mentése és/vagy olvasása közvetlenül az SAS használatával történik.

Emellett sas szükséges a forrásobjektumhoz való hozzáférés engedélyezéséhez egy másolási műveletben bizonyos esetekben:

  • Amikor egy másik, másik tárfiókban található blobba másol egy blobot.

    Opcionálisan sas használatával is engedélyezheti a célblobhoz való hozzáférést.

  • Amikor egy másik tárfiókban található fájlba másol egy fájlt.

    Opcionálisan sas használatával is engedélyezheti a célfájlhoz való hozzáférést.

  • Ha egy blobot egy fájlba vagy egy fájlt egy blobba másol.

    SAS-t akkor is használnia kell, ha a forrás- és célobjektumok ugyanabban a tárfiókban találhatók.

A SAS használatával kapcsolatos ajánlott eljárások

Ha közös hozzáférésű jogosultságkódokat használ az alkalmazásokban, két lehetséges kockázattal kell tisztában lennie:

  • Ha kiszivárog egy SAS, azt bárki használhatja, aki beszerezi, ami potenciálisan veszélyeztetheti a tárfiókját.

  • Ha egy ügyfélalkalmazáshoz biztosított SAS lejár, és az alkalmazás nem tud új SAS-t lekérni a szolgáltatásból, akkor az alkalmazás működése akadályozható lehet.

A megosztott hozzáférésű jogosultságkódok használatára vonatkozó alábbi javaslatok segíthetnek csökkenteni ezeket a kockázatokat:

  • SAS-t mindig HTTPS használatával hozhat létre vagy terjeszthet. Ha egy SAS-t http-en keresztül ad át, és elfogják, a középső támadást végrehajtó támadó képes olvasni az SAS-t. Ezután ugyanúgy használhatják ezt az SAS-t, mint a kívánt felhasználó. Ez veszélyeztetheti a bizalmas adatokat, vagy adatsérülést okozhat a rosszindulatú felhasználó számára.

  • Ha lehetséges, használjon felhasználói delegálási SAS-t. A felhasználói delegálási SAS kiváló biztonságot nyújt egy szolgáltatás SAS-nek vagy egy fiók SAS-nek. A felhasználói delegálási SAS-t a Microsoft Entra hitelesítő adatai védik, így nem kell a kóddal együtt tárolnia a fiókkulcsot.

  • Rendelkezik egy visszavonási tervvel egy SAS-hez. Győződjön meg arról, hogy készen áll a válaszadásra, ha egy SAS sérült.

  • Sas-lejárati szabályzat konfigurálása a tárfiókhoz. Az SAS lejárati szabályzata azt az ajánlott időközt határozza meg, amelyen az SAS érvényes. Az SAS lejárati szabályzatai a szolgáltatás SAS-jára vagy egy fiók SAS-ére vonatkoznak. Ha egy felhasználó olyan szolgáltatás SAS-t vagy fiók SAS-t hoz létre, amelynek érvényességi időtartama nagyobb, mint az ajánlott időköz, figyelmeztetés jelenik meg. Ha az Azure Storage naplózása az Azure Monitorral engedélyezve van, akkor a rendszer egy bejegyzést ír az Azure Storage-naplókba. További információ: Lejárati szabályzat létrehozása közös hozzáférésű jogosultságkódokhoz.

  • Hozzon létre egy tárolt hozzáférési szabályzatot egy szolgáltatás SAS-hez. A tárolt hozzáférési szabályzatok lehetővé teszik a szolgáltatás SAS-engedélyeinek visszavonását anélkül, hogy újra kellene létrehoznia a tárfiókkulcsokat. Állítsa be a lejárati dátumot a jövőben (vagy a végtelenben), és győződjön meg arról, hogy rendszeresen frissül, hogy a jövőben még messzebbre vigye. Tárolónként öt tárolt hozzáférési szabályzat van korlátozva.

  • Használjon rövid távú lejárati időt egy alkalmi SAS-szolgáltatás SAS-jén vagy fiók SAS-jén. Ily módon még akkor is érvényes, ha egy SAS sérült, csak rövid ideig érvényes. Ez a gyakorlat különösen fontos, ha nem hivatkozhat tárolt hozzáférési szabályzatra. A rövid lejárati idő a blobba írható adatok mennyiségét is korlátozza a feltöltéshez rendelkezésre álló idő korlátozásával.

  • Szükség esetén az ügyfelek automatikusan megújítják az SAS-t. Az ügyfeleknek jóval a lejárat előtt meg kell újítaniuk az SAS-t, hogy időt hagyhassanak az újrapróbálkozáshoz, ha az SAS-t biztosító szolgáltatás nem érhető el. Ez bizonyos esetekben szükségtelen lehet. Előfordulhat például, hogy az SAS-t kis számú azonnali, rövid élettartamú művelethez szeretné használni. Ezek a műveletek várhatóan a lejárati időn belül befejeződnek. Ennek eredményeképpen nem számít arra, hogy az SAS megújul. Ha azonban olyan ügyfele van, amely rutinszerűen küld kéréseket SAS-en keresztül, akkor a lejárat lehetősége is felmerül.

  • Legyen óvatos az SAS kezdési időpontjával. Ha egy SAS kezdési idejét az aktuális időpontra állítja, a hibák időnként előfordulhatnak az első néhány percben. Ennek az az oka, hogy a különböző gépek kissé eltérő aktuális időpontokkal rendelkeznek (más néven óraeltérés). A kezdési idő általában legalább 15 perc lehet a múltban. Vagy egyáltalán ne állítsa be, ami minden esetben azonnal érvényessé teszi. Ugyanez általában érvényes a lejárati időre is – ne feledje, hogy bármilyen kérésre akár 15 percnyi óraátállítást is megfigyelhet bármelyik irányban. A 2012-02-12 előtti REST-verziót használó ügyfelek esetében a tárolt hozzáférési szabályzatra nem hivatkozó SAS maximális időtartama 1 óra. Az 1 óránál hosszabb időtartamot meghatározó szabályzatok sikertelenek lesznek.

  • Legyen óvatos az SAS datetime formátumával. Egyes segédprogramok (például az AzCopy) esetében a dátum/idő értékeket "+%Y-%m-%dT%H:%M:%SZ" formátumban kell formázni. Ez a formátum kifejezetten a másodperceket tartalmazza.

  • Adja meg a lehető legkevesebb jogosultságot az SAS-vel. A biztonsági ajánlott eljárás az, hogy a felhasználók a lehető legkevesebb erőforráshoz biztosítják a minimálisan szükséges jogosultságokat. Ha lehetséges, csak olvasható SAS-t használjon. Ha egy felhasználónak csak egyetlen objektumhoz kell olvasási hozzáférést biztosítania, akkor olvasási hozzáférést kell biztosítani az adott objektumhoz, és nem kell olvasási/írási/törlési hozzáférést biztosítani az összes objektumhoz. Ez csökkenti a kárt, ha egy SAS sérült, mert az SAS kevesebb hatalom kezében a támadó.

    Nem lehet közvetlenül azonosítani, hogy mely ügyfelek fértek hozzá egy erőforráshoz. A hozzáférés nyomon követéséhez azonban használhatja az SAS egyedi mezőit, az aláírt IP-címet (sip), az aláírt kezdő (st) és az aláírt lejárati (se) mezőket. Létrehozhat például egy SAS-jogkivonatot egy egyedi lejárati idővel, amelyet aztán korrelálhat azzal az ügyféllel, akinek kiadták.

  • Tudja meg, hogy fiókját minden használatért kiszámlázzuk, beleértve az SAS-t is. Ha írási hozzáférést biztosít egy blobhoz, a felhasználó dönthet úgy, hogy feltölt egy 200 GB-os blobot. Ha olvasási hozzáférést is adott nekik, dönthetnek úgy, hogy 10-szer töltik le, ami 2 TB kimenő költséget von maga után. Adjon meg ismét korlátozott engedélyeket a rosszindulatú felhasználók lehetséges műveleteinek csökkentéséhez. Használja a rövid élettartamú SAS-t a fenyegetés csökkentéséhez (de tartsa szem előtt az óraeltéréseket a befejezési időpontban).

  • Sas használatával írt adatok ellenőrzése. Amikor egy ügyfélalkalmazás adatokat ír a tárfiókba, vegye figyelembe, hogy az adatokkal kapcsolatban problémák merülhetnek fel. Ha ellenőrizni szeretné az adatokat, végezze el az ellenőrzést az adatok megírása után és az alkalmazás általi használat előtt. Ez a gyakorlat védelmet nyújt a fiókba írt sérült vagy rosszindulatú adatokkal szemben, akár egy olyan felhasználó, aki megfelelően szerezte be az SAS-t, vagy egy kiszivárgott SAS-t kihasználó felhasználó.

  • Tudja, mikor ne használjon SAS-t. Előfordulhat, hogy a tárfiókja egy adott műveletével kapcsolatos kockázatok meghaladják az SAS használatának előnyeit. Ilyen műveletekhez hozzon létre egy középszintű szolgáltatást, amely az üzleti szabályok érvényesítése, hitelesítése és naplózása után ír a tárfiókba. Emellett néha egyszerűbb más módokon kezelni a hozzáférést. Ha például nyilvánosan olvashatóvá szeretné tenni a tároló összes blobját, a tárolót nyilvánossá teheti ahelyett, hogy sast biztosítna minden ügyfél számára a hozzáféréshez.

  • Az alkalmazás figyeléséhez használja az Azure Monitor és az Azure Storage naplóit. Az engedélyezési hibák az SAS-szolgáltató szolgáltatás leállása miatt fordulhatnak elő. A tárolt hozzáférési szabályzat véletlen eltávolításából is előfordulhatnak. Az Azure Monitor és a Storage Analytics naplózásával megfigyelheti az ilyen típusú engedélyezési hibák kiugró emelkedését. További információ: Azure Storage-metrikák az Azure Monitorban és az Azure Storage Analytics naplózásában.

  • Sas-lejárati szabályzat konfigurálása a tárfiókhoz. Az ajánlott eljárások azt javasolják, hogy korlátozza az SAS-hez tartozó időközt, ha az illetéktelenek megsérülnek. A tárfiókok SAS-lejárati szabályzatának beállításával megadhat egy ajánlott felső lejárati korlátot, amikor egy felhasználó létrehoz egy szolgáltatás SAS-t vagy egy fiók SAS-t. További információ: Lejárati szabályzat létrehozása közös hozzáférésű jogosultságkódokhoz.

Feljegyzés

A tároló nem követi nyomon a tárolófiókhoz generált megosztott hozzáférési aláírások számát, és egyetlen API sem képes ezt a részletet megadni. Ha tudnia kell a tárfiókhoz létrehozott közös hozzáférésű jogosultságkódok számát, manuálisan kell nyomon követnie a számot.

Az SAS használatának első lépései

A közös hozzáférésű jogosultságkódok használatának megkezdéséhez tekintse meg az egyes SAS-típusokról szóló alábbi cikkeket.

Felhasználói delegálási SAS

Service SAS

Fiók SAS-fiókja

Következő lépések