Pótkulcs minta

Egy jogkivonat használatával korlátozott közvetlen hozzáférést biztosíthat az ügyfelek számára egy adott erőforráshoz, hogy így csökkentse egy alkalmazás adatátviteli követelményeit. Ez különösen hasznos olyan alkalmazások esetében, amelyek felhőben futtatott tárolórendszereket vagy üzenetsorokat használnak, mert minimalizálja a költségeket és maximalizálja a skálázhatóságot és a teljesítményt.

Kontextus és probléma

Az ügyfélprogramoknak és a webböngészőknek gyakran kell fájlokat vagy adatfolyamokat olvasniuk és írniuk az alkalmazás tárterületére és onnan. Az alkalmazás általában az adatok áthelyezését fogja kezelni – vagy lekéri a tárolóból, és streameli az ügyfélnek, vagy beolvassa a feltöltött streamet az ügyfélről, és az adattárban tárolja. Azonban ez a megközelítés értékes erőforrásokat foglal le, például számítási, memória- és sávszélesség-erőforrásokat.

Az adattárak képesek közvetlenül kezelni az adatfeltöltést és -letöltést, így az alkalmazás részéről nincs szükség semmilyen feldolgozási tevékenységre az adatok mozgatásához. Ehhez viszont általában az ügyfélnek hozzá kell férnie a tároló biztonsági hitelesítő adataihoz. Ez hasznos módszer lehet, ha minimalizálni szeretné az adatátvitel költségeit és szükség van az alkalmazás horizontális felskálázására, valamint maximalizálni szeretné a teljesítményt. Azonban ez azt jelenti, hogy az alkalmazás már nem fogja tudni kezelni az adatok biztonságát. Miután az ügyfél közvetlen hozzáféréssel tud kapcsolódni az adattárhoz, az alkalmazás már nem töltheti be a forgalomirányító szerepét. Már nem az alkalmazás szabályozza a folyamatot, és nem akadályozhatja meg a későbbi feltöltéseket vagy letöltéseket az adattárolóban.

Ez nem reális megközelítés elosztott rendszerek esetében, amelyek nem megbízható ügyfeleket is kiszolgálnak. Ehelyett az alkalmazásoknak képesnek kell lenniük az adathozzáférést biztonságosan és részletesen szabályozni, ugyanakkor csökkenteniük kell a kiszolgáló terheltségét is, méghozzá úgy, hogy először létre kell hozniuk a kapcsolatot, majd engedélyezniük kell az ügyfél számára a közvetlen kommunikációt az adattárral, hogy az végrehajthassa a szükséges olvasási vagy írási műveleteket.

Megoldás

Meg kell oldania az adattárhoz való hozzáférés szabályozását olyan esetben, amikor a tároló nem képes kezelni az ügyfelek hitelesítését és ellenőrzését. Az egyik tipikus megoldás az adattár nyilvános kapcsolatához való hozzáférés korlátozása, és egy olyan kulcs vagy jogkivonat biztosítása az ügyfél számára, amelyet az adattár érvényesíthet.

Ezt a kulcsot vagy a jogkivonatot általában pótkulcsnak nevezzük. Időkorlátos hozzáférést biztosít bizonyos erőforrásokhoz, és csak előre meghatározott műveleteket tesz lehetővé részletes vezérléssel, például a tárolóba írást, olvasást, illetve webböngészőben való feltöltést és letöltést nem. Az alkalmazások gyorsan és könnyen létrehozhatnak és kioszthatnak pótkulcsokat ügyféleszközök és böngészők számára, amelyekkel az ügyfelek elvégezhetik a szükséges műveleteket anélkül, hogy az alkalmazásnak közvetlenül kezelni kellene az adatátvitelt. Ezzel megszűnik az alkalmazás és a kiszolgáló feldolgozási többletterhelése, a teljesítményre és skálázhatóságra gyakorolt hatásával együtt.

Az ügyfél a jogkivonattal az adattár egy kijelölt erőforrásához férhet hozzá, csak meghatározott ideig, és a hozzáférési engedélyek bizonyos mértékű korlátozásával, mint ahogy az ábrán látható. A megadott időszak után a kulcs érvénytelenné válik, és többé nem ad hozzáférést az erőforráshoz.

Ezen felül lehetősége van más függőségekkel (például az adatok hatóköre) rendelkező kulcs konfigurálására. Például az adattár képességeihez mérten a kulcs meghatározhat egy teljes táblát az adattáron belül, vagy akár csak egy tábla bizonyos sorait. Felhőalapú tárolórendszerek esetében a kulcs megadhat egy tárolót, vagy csak egy adott elemet egy tárolón belül.

A kulcsot az alkalmazás is képes érvényteleníteni. Ez hasznos megközelítés abban az esetben, ha az ügyfél értesíti a kiszolgálót az adatátvitel befejeztéről. A kiszolgáló ezután érvénytelenítheti ezt a kulcsot a további hozzáférés megakadályozása érdekében.

Ezzel a mintával egyszerűbbé teheti az erőforrásokhoz való hozzáférés kezelését, mivel nincs szükség felhasználó létrehozására és hitelesítésére, engedélyek megadására, majd a felhasználó ismételt eltávolítására, vagy rosszabb esetben állandó engedélyként hagyhatja el az engedélyt. Emellett egyszerűen korlátozhatja a helyet, az engedélyt és az érvényességi időtartamot – mindezt úgy, hogy egyszerűen generál egy kulcsot futásidőben. A legfontosabb tényező az érvényességi időszak, és különösen az erőforrás helyének minél szigorúbb korlátozása, hogy a kulcs birtokosa azt csak rendeltetésszerű célokra használhassa.

Problémák és megfontolandó szempontok

A minta megvalósítása során az alábbi pontokat vegye figyelembe:

Kezelje a kulcs érvényességi állapotát és időtartamát. Ha a kulcs kiszivárog vagy megsérül, az gyakorlatilag szabaddá teszi a célelemet, amely az érvényességi idő alatt kártékony használat áldozata lehet. A kiállítás módjától függően a kulcsot általában visszavonhatja vagy letilthatja. A kiszolgálóoldali szabályzatok módosíthatók, illetve az aláírást biztosító kiszolgálói kulcs érvényteleníthető. Adjon meg rövid érvényességi időt, hogy a minimálisra csökkentse az adattárra irányuló jogosulatlan műveletek kockázatát. Ha azonban az érvényességi időtartam túl rövid, előfordulhat, hogy az ügyfél nem tudja elvégezni a kívánt műveletet a kulcs érvényességének lejárta előtt. Engedélyezze a jogosult felhasználók számára a kulcs megújítását az érvényesség lejárta előtt arra az esetre, ha többszöri hozzáférésre van szükség a védett erőforráshoz.

Szabályozza a kulcs által biztosított hozzáférési szintet. A kulcs általában csak a művelethez szükséges tevékenységek végrehajtását engedélyezi a felhasználó számára, például csak olvasható hozzáférést ad, ha az ügyfélnek nem szabadna adatot feltöltenie az adattárba. Fájlfeltöltés esetén olyan kulcsot szokás megadni, amely csak írási engedélyt biztosít, valamint meghatározza a helyet és az érvényességi időt. Döntően fontos pontosan meghatározni azt az erőforrást vagy azt az erőforráskészletet, amelyre a kulcs érvényes.

Fontolja meg, hogyan szabályozhatja a felhasználók viselkedését. Az ilyen minta megvalósításával együtt jár az, hogy kevésbé tudja szabályozni azokat az erőforrásokat, amelyekhez hozzáférést biztosít a felhasználóknak. A szabályozás mértékét korlátozzák a szolgáltatás vagy a célzott adattár esetében elérhető szabályzatok és engedélyek képességei. Például általában nincs lehetőség egy olyan kulcs létrehozására, amely korlátozza a tárolóra írható adat méretét, vagy azt, hogy egy kulccsal hányszor férhetnek hozzá egy adott fájlhoz. Ez váratlanul hatalmas adatátviteli költséget eredményezhet, még akkor is, ha az az ügyfél használja a kulcsot, akinek szánták, és a kód olyan hibájából adódhat, amely ismétlődő fel- vagy letöltést okoz. A fájlfeltöltések számának korlátozásához ahol lehetséges, kényszerítse az ügyfelet, hogy értesítse az alkalmazást a feltöltés befejezéséről. Néhány adattár például eseményeket hoz létre, amelyeket az alkalmazás felhasználhat a műveletek monitorozására és a felhasználói viselkedés szabályozására. Egy több-bérlős forgatókönyvben azonban nehéz kvótákat kikényszeríteni az egyes felhasználók számára, ha ugyanazt a kulcsot egy bérlő összes felhasználója használja. Ha engedélyeket ad a felhasználóknak, a jogkivonatok hatékony egyszeri használatával szabályozhatja a frissítendő adatok mennyiségét. A létrehozási engedély nem teszi lehetővé a felülírást, így minden jogkivonat csak egy írási tevékenységhez használható.

Érvényesítsen és igény szerint vírusmentesítsen minden feltöltött adatot. Ha egy kártevő felhasználó hozzáférést szerzett a kulcshoz, feltölthet olyan adatot, amelyet a rendszer károsítására terveztek. Más esetekben az engedélyezett felhasználók feltölthetnek érvénytelen adatokat, amelyek feldolgozáskor hibához vagy a rendszer meghibásodásához vezethetnek. Ez ellen úgy védekezhet, hogy gondoskodik az összes adat érvényesítéséről és rosszindulatú kódok ellenőrzéséről a használat előtt.

Naplózzon minden műveletet. Sok kulcsalapú mechanizmus képes olyan műveletek naplózására, mint a feltöltések, a letöltések és a hibák. Ezeket a naplókat általában beépítheti egy naplózási folyamatba, illetve számlázáshoz is használhatja, ha a felhasználónak fájlméret vagy adatmennyiség alapján számláz. A naplók segítségével észlelheti az olyan hitelesítési hibákat, amelyek esetlegesen a kulcsszolgáltató hibájából vagy egy tárolt hozzáférési szabályzat nem szándékos eltávolításából adódnak.

A kulcsot biztonságosan adja át. URL-be ágyazhatja, amelyet a felhasználó egy weblapon tud aktiválni, vagy használhatja egy kiszolgáló-átirányítási műveletben, így a letöltés automatikusan megindul. Mindig használjon HTTPS-t, hogy biztonságos csatornán keresztül adja át a kulcsot.

Védje a bizalmas adatokat az átvitel során. Az alkalmazáson keresztül továbbított bizalmas adatok általában TLS használatával történnek, és ezeket az adattárat közvetlenül elérő ügyfelek esetében kötelezővé kell tenni.

A minta megvalósításakor érdemes egyéb problémákról is tájékozódnia:

• Ha az ügyfél nem jelzi vagy nem tudja jelezni a kiszolgáló felé a művelet befejeződését, és csak a kulcs lejárati ideje korlátozza, az alkalmazás nem lesz képes naplózási műveletek végrehajtására, például a feltöltések vagy letöltések számának nyomon követésére, és nem képes megakadályozni a többszöri fel- vagy letöltést.

• A létrehozható kulcskezelési szabályzatok esetenként nem eléggé rugalmasak. Például bizonyos mechanizmusok csak időzített lejárati idő használatát engedik. Más mechanizmusok nem engedik az olvasási/írási engedélyek kellőképpen részletes meghatározását.

• Ha meg van adva a kulcs vagy a jogkivonat érvényességi időtartamának kezdeti időpontja, győződjön meg róla, hogy az a jelenlegi kiszolgálóidőnél egy kicsit korábbi időpont, hogy az ügyfelek akkor is kaphassanak hozzáférést, ha a rendszeróra nem teljesen szinkronizált. Az alapértelmezett érték a kiszolgáló aktuális rendszerideje, ha nincs egyéb megadva.

• A kulcsot tartalmazó URL-cím rögzíthető a kiszolgáló naplófájljaiban. Bár a kulcs általában már lejár, mire a naplófájlokat a rendszer felhasználná elemzések készítéséhez, gondoskodjon a hozzáférés korlátozásáról. Ha a naplózási adatokat továbbítja egy monitorozási rendszernek vagy más helyen tárolja őket, fontolja meg egy késleltetési idő bevezetését, amellyel megakadályozza a kulcsok kiszivárgását az érvényességi idejük lejárta előtt.

• Ha az ügyfélkód webböngészőben fut, előfordulhat, hogy a böngészőnek támogatnia kell az eltérő eredetű erőforrások megosztását (CORS), így a webböngészőben lefuthatnak olyan kódok, amelyekkel a weblapot kiszolgáló tartományon keresztül hozzáférhet egy másik tartomány adataihoz. Egyes régebbi böngészők és adattárak nem támogatják a CORS-t, és előfordulhat, hogy az ezekben a böngészőkben futó kód nem tud valet kulccsal hozzáférést biztosítani egy másik tartomány adataihoz, például egy felhőalapú tárfiókhoz.

• Bár az ügyfélnek nem kell előre konfigurált hitelesítéssel rendelkeznie a végfelhasználói erőforráshoz, az ügyfélnek elő kell állítania a hitelesítési eszközöket a valet key szolgáltatáshoz.

• A kulcsokat csak a hitelesített ügyfeleknek szabad átadni megfelelő engedélyekkel.

• A hozzáférési jogkivonatok létrehozása kiemelt művelet, ezért a valet key szolgáltatást szigorú hozzáférési szabályzatokkal kell védeni. A szolgáltatás lehetővé teheti a bizalmas rendszerekhez való hozzáférést harmadik felek számára, ami különösen fontossá teszi a szolgáltatás biztonságát.

Mikor érdemes ezt a mintát használni?

Ez a minta az alábbi helyzetekben lehet hasznos:

• Ha az erőforrások terhelésének minimálisra csökkentésére, illetve a lehető legnagyobb teljesítményre és skálázhatóságra van szükség. Pótkulcs használatakor nem kell zárolni az erőforrást, nem szükséges a távoli kiszolgáló meghívása, nincs korlátozva a kiadható pótkulcsok száma, és elkerülheti, hogy az alkalmazáskódon keresztüli adatátvitel miatt egyetlen meghibásodási pont alakuljon ki. A pótkulcs létrehozása általában egy egyszerű kriptográfiai művelet, amelynek során aláír egy sztringet egy kulccsal.

• Ha az üzemeltetési költségek csökkentésére van szükség. A közvetlen hozzáférés engedélyezése a tárolókhoz és az üzenetsorokhoz erőforrás- és költséghatékony, lecsökkentheti a hálózaton belüli oda-vissza áramló adatok mennyiségét, és lehetővé teheti a szükséges számítási erőforrások számának lecsökkentését.

• Ha az ügyfelek rendszeresen töltenek fel vagy le adatot, különösen nagy forgalom esetén, vagy ha minden művelet nagy méretű fájlok mozgatásával jár.

• Ha az alkalmazásnak csak korlátozott számítási erőforrásai vannak az üzemeltetési korlátozások vagy költségvetési szempontok miatt. Ebben a helyzetben a minta még hasznosabb lehet akkor, ha sok az egyidejű adatfeltöltés és -letöltés, mert mentesíti az alkalmazást az adatátvitel kezelése alól.

• Ha az adatokat egy távoli adattárban vagy egy másik régióban tárolják. Ha az alkalmazásnak kapuőrként kellett működnie, előfordulhat, hogy az adatok régiók közötti vagy nyilvános vagy magánhálózatokon keresztül történő átvitelének további sávszélessége díjat számít fel az ügyfél és az alkalmazás, majd az alkalmazás és az adattár között.

Nem érdemes ezt a mintát használni a következő helyzetekben:

• Ha az ügyfelek már egyedileg tudnak hitelesíteni a háttérszolgáltatásban, például RBAC-vel, ne használja ezt a mintát.

• Ha az alkalmazásnak el kell végeznie még néhány feladatot az adatokon, mielőtt azokat a rendszer eltárolja vagy elküldi őket az ügyfélnek. Ha például az alkalmazásnak érvényesítést kell végeznie, feltétel a naplófájl sikeres elérése vagy átalakítást kell végezni az adatokon. Egyes adattárak és ügyfelek azonban képesek tárgyalni és végrehajtani az olyan egyszerű átalakításokat, mint a tömörítés és a dekompresszió (például egy webböngésző általában képes kezelni a gzip formátumokat).

• Ha a meglévő alkalmazáskialakítás megnehezíti a minta beépítését. A minta használatához általában egy másik architekturális megközelítés szükséges az adatok szállításához és fogadásához.

• Ha szükség van auditnaplóra és az adatátviteli műveletek számának szabályozására, és az alkalmazott pótkulcs-mechanizmus nem támogatja azokat az értesítéseket, amelyeket a kiszolgáló ezen műveletek kezeléséhez használhatna.

• Ha korlátozni kell az adatok méretét, különösen feltöltési műveleteknél. Az egyetlen megoldás az, ha az alkalmazás a művelet befejezte után ellenőrzi az adatméretet, vagy ellenőrzi a feltöltések nagyságát egy megadott idő eltelte után vagy egy megadott ütemezés szerint.

Számítási feladatok tervezése

Az építészeknek értékelniük kell, hogyan használható a Valet-kulcs minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példa

Az Azure támogatja a közös hozzáférésű jogosultságkódot az Azure Storage-en, hogy lehetővé tegye az adatok részletes hozzáférés-szabályozását a blobokban, a táblákban és az üzenetsorokban, valamint Service Bus-üzenetsorok és -témakörök esetében. A közös hozzáférésű jogosultságkód konfigurálható úgy, hogy meghatározott hozzáférést biztosítson, például olvasási, írási, frissítési és törlési engedélyt egy adott táblához, egy táblán belüli kulcstartományhoz, egy üzenetsorhoz, egy blobhoz vagy egy blobtárolóhoz. Az érvényesség egy megadott időtartam lehet. Ez a funkció kiválóan alkalmas a valet kulccsal való hozzáférésre.

Fontolja meg azt a számítási feladatot, amely több száz mobil- vagy asztali ügyféllel rendelkezik, amelyek gyakran töltenek fel nagy bináris fájlokat. E minta nélkül a számítási feladat alapvetően két lehetőséggel rendelkezik. Az első az, hogy állandó hozzáférést és konfigurációt biztosít az összes ügyfél számára a feltöltések közvetlen storage-fiókba történő végrehajtásához. A másik az átjáró-útválasztási minta implementálása egy olyan végpont beállításához, ahol az ügyfelek kihasználják a tárterülethez való hozzáférést, de ez nem feltétlenül ad további értéket a tranzakcióhoz. Mindkét megközelítés a mintakörnyezetben kezelt problémákat szenvedi el:

• Hosszú életű, előmegosztott titkok. Lehetséges, hogy nincs sok módja annak, hogy különböző kulcsokat adjon meg a különböző ügyfeleknek.
• Olyan számítási szolgáltatás futtatásához hozzáadott költség, amely elegendő erőforrással rendelkezik a nagy fájlok fogadásához.
• Lehetséges, hogy lelassítja az ügyfél-interakciókat egy további számítási és hálózati ugrási réteg hozzáadásával a feltöltési folyamathoz.

A Valet-kulcs minta használata a biztonsággal, a költségoptimalizálással és a teljesítménnyel kapcsolatos problémákat kezeli.

1. Az ügyfelek az utolsó felelős pillanatban egy kis súlyú, skálázással nullára skálázott Azure-függvény által üzemeltetett API-val hitelesítik magukat, hogy hozzáférést kérjenek.

2. Az API ellenőrzi a kérést, majd beolvas és visszaad egy korlátozott SaS-jogkivonatot a time & hatókörben.

   Az API által létrehozott jogkivonat a következő korlátozásokra korlátozza az ügyfelet:

   • Melyik tárfiókot kell használni. Ez azt jelenti, hogy az ügyfélnek nem kell előre tudnia ezeket az információkat.
   • Egy használandó tároló és fájlnév; biztosítja, hogy a jogkivonat legfeljebb egy fájllal használható legyen.
   • Egy rövid, műveletablak, például három perc. Ez a rövid időtartam biztosítja, hogy a jogkivonatok TTL-jét ne hosszabbítsa meg a segédprogramon.
   • Csak blob létrehozására vonatkozó engedélyek; nem tölthető le, nem frissíthető vagy törölhető.

3. Ezt a jogkivonatot használja az ügyfél a szűk időkereten belül, hogy közvetlenül a tárfiókba töltse fel a fájlt.

Az API ezeket a jogkivonatokat egy felhasználódelegálási kulccsal hozza létre a jogosult ügyfelek számára az API saját Microsoft Entra ID felügyelt identitása alapján. A naplózás engedélyezve van a tárfiók(ok)on és a jogkivonat-létrehozási API-n is, amely lehetővé teszi a jogkivonat-kérelmek és a tokenhasználat közötti korrelációt. Az API ügyfélhitelesítési adatokkal vagy a rendelkezésére álló egyéb adatokkal eldöntheti, hogy melyik tárfiókot vagy tárolót használja, például több-bérlős helyzetben.

Teljes minta érhető el a GitHubon a Valet Key mintamintájában. A következő kódrészletek ebből a példából lettek adaptálva. Ez az első bemutatja, hogy az Azure-függvény (amely a ValetKey.Web-ben található) hogyan hoz létre egy felhasználó által delegált megosztott hozzáférésű jogosultságkód-jogkivonatot az Azure-függvény saját felügyelt identitásával.

[Function("FileServices")]
public async Task<StorageEntitySas> GenerateTokenAsync([HttpTrigger(...)] HttpRequestData req, ..., 
                                                        CancellationToken cancellationToken)
{
  // Authorize the caller, select a blob storage account, container, and file name.
  // Authenticate to the storage account with the Azure Function's managed identity.
  ...

  return await GetSharedAccessReferenceForUploadAsync(blobContainerClient, blobName, cancellationToken);
}

/// <summary>
/// Return an access key that allows the caller to upload a blob to this
/// specific destination for about three minutes.
/// </summary>
private async Task<StorageEntitySas> GetSharedAccessReferenceForUploadAsync(BlobContainerClient blobContainerClient, 
                                                                            string blobName,
                                                                            CancellationToken cancellationToken)
{
  var blobServiceClient = blobContainerClient.GetParentBlobServiceClient();
  var blobClient = blobContainerClient.GetBlockBlobClient(blobName);

  // Allows generating a SaS token that is evaluated as the union of the RBAC permissions on the managed identity
  // (for example, Blob Data Contributor) and then narrowed further by the specific permissions in the SaS token.
  var userDelegationKey = await blobServiceClient.GetUserDelegationKeyAsync(DateTimeOffset.UtcNow.AddMinutes(-3),
                                                                            DateTimeOffset.UtcNow.AddMinutes(3),
                                                                            cancellationToken);

  // Limit the scope of this SaS token to the following:
  var blobSasBuilder = new BlobSasBuilder
  {
      BlobContainerName = blobContainerClient.Name,     // - Specific container
      BlobName = blobClient.Name,                       // - Specific filename
      Resource = "b",                                   // - Blob only
      StartsOn = DateTimeOffset.UtcNow.AddMinutes(-3),  // - For about three minutes (+/- for clock drift)
      ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(3),  // - For about three minutes (+/- for clock drift)
      Protocol = SasProtocol.Https                      // - Over HTTPS
  };
  blobSasBuilder.SetPermissions(BlobSasPermissions.Create);

  return new StorageEntitySas
  {
      BlobUri = blobClient.Uri,
      Signature = blobSasBuilder.ToSasQueryParameters(userDelegationKey, blobServiceClient.AccountName).ToString();
  };
}

A következő kódrészlet az API és az ügyfél által használt adatátviteli objektum (DTO).

public class StorageEntitySas
{
  public Uri? BlobUri { get; internal set; }
  public string? Signature { get; internal set; }
}

Az ügyfél (megtalálható a ValetKey.Client-ben), majd az API-ból visszaadott URI-t és jogkivonatot használja a feltöltés végrehajtásához anélkül, hogy további erőforrásokra és teljes ügyfél-tárteljesítményre van szükség.

...

// Get the SaS token (valet key)
var blobSas = await httpClient.GetFromJsonAsync<StorageEntitySas>(tokenServiceEndpoint);
var sasUri = new UriBuilder(blobSas.BlobUri)
{
    Query = blobSas.Signature
};

// Create a blob client using the SaS token as credentials
var blob = new BlobClient(sasUri.Uri);

// Upload the file directly to blob storage
using (var stream = await GetFileToUploadAsync(cancellationToken))
{
    await blob.UploadAsync(stream, cancellationToken);
}

...

Következő lépések

A minta megvalósításakor az alábbi útmutatás lehet releváns:

• A példa implementációja elérhető a GitHubon a Valet Key minta példáján.
• 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
• Közös hozzáférésű jogosultságkódos hitelesítés Service Bus használatával

Kapcsolódó erőforrások

A minta megvalósításakor az alábbi minták is relevánsak lehetnek:

• Forgalomirányító minta. Ez a minta a Pótkulcs mintával együtt használható fel arra, hogy az alkalmazások és szolgáltatások védelmét egy dedikált gazdapéldánnyal valósítsa meg, amely közvetítőként szolgál az ügyfelek és az alkalmazás vagy szolgáltatás között. A forgalomirányító érvényesíti és vírusmentesíti a kéréseket, valamint közvetíti a kéréseket és az adatokat az ügyfél és az alkalmazás között. Ez egy további biztonsági réteget biztosíthat, és csökkenti a számítógép támadható felületét.
• Statikus tartalom üzemeltetési minta. Leírja, hogyan kell üzembe helyezni statikus tartalmakat egy felhőalapú társzolgáltatásban, amely közvetlenül az ügyfélnek közvetíti az erőforrásokat, hogy ezzel visszaszorítsa a költséges számítási példányok szükségességét. Abban az esetben, ha az erőforrásoknak nem kell nyilvánosan elérhetőnek lenniük, azokat a Pótkulcs minta segítségével védheti meg.