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
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éldául:
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
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).
Megjegyzés:
A Microsoft azt javasolja, hogy ha lehetséges, használja a Microsoft Entra hitelesítő adatait biztonsági ajánlott eljárásként a fiókkulcs használata helyett, amely könnyebben feltörhető. Ha az alkalmazás tervezése megosztott hozzáférési aláírásokat igényel a Blob Storage-hoz való hozzáféréshez, a Microsoft Entra hitelesítő adataival hozzon létre egy felhasználói delegálási SAS-t, ha lehetséges, a magasabb szintű biztonság érdekében. További információ: Adatokhoz való hozzáférés engedélyezése az Azure Storage-ban.
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.
Megjegyzé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.
Megjegyzé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.
Megjegyzé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:
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.
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.
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.
Best practices when using SAS
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.
Megjegyzés:
A Storage nem követi nyomon a tárfiókhoz létrehozott közös hozzáférésű jogosultságkódok számát, és egyetlen API sem tudja megadni ezt a részletet. 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
- Felhasználódelegálási SAS létrehozása tárolóhoz vagy blobhoz a PowerShell használatával
- Felhasználói delegálási SAS létrehozása tárolóhoz vagy blobhoz az Azure CLI-vel
- Felhasználói delegálási SAS létrehozása tárolóhoz vagy blobhoz .NET-tel