Model osobního klíče

Používá token, který klientům poskytuje omezený přímý přístup ke konkrétnímu prostředku. Tím se snižuje zátěž v podobě přenosu dat z aplikace. Tento přístup je zvlášť užitečný u aplikací, které používají úložné systémy nebo fronty hostované v cloudu. Může minimalizovat náklady a maximalizovat škálovatelnost a výkon.

Kontext a problém

Klientské programy a webové prohlížeče často potřebují číst a zapisovat soubory nebo datové proudy do a z úložiště aplikace. Aplikace obvykle zpracuje přesun dat – buď načtením z úložiště a jeho streamováním do klienta, nebo načtením nahraného datového proudu z klienta a jeho uložením do úložiště dat. Tento postup ale spotřebovává cenné prostředky, jako je výpočetní výkon, paměť a šířka pásma.

Nahrávání a stahování dat ale může zajišťovat přímo úložiště dat, a aplikace tak přesouvaná data zpracovávat nemusí. To ale obvykle vyžaduje, aby měl klient přístup k zabezpečovacím přihlašovacím údajům úložiště. Může to být užitečný způsob, jak minimalizovat náklady na přenos dat a požadavky na škálování aplikace na více instancí a jak maximalizovat výkon. Znamená to ale, že aplikace už nebude moct spravovat zabezpečení dat. Jakmile klient získá přímý přístup k úložišti dat, nemůže už aplikace fungovat jako vrátný. Už proces neřídí a nemůže zabránit následnému nahrávání dat do úložiště nebo jejich stahování z něj.

Tento přístup není reálně možný v distribuovaných systémech, ve kterých je nutné obsluhovat nedůvěryhodné klienty. Aplikace musí být schopné bezpečně řídit granulární přístup k datům, ale současně snižovat zatížení serveru tím, že nastaví připojení a pak povolí klientovi, aby při zpracovávání požadovaných operací čtení a zápisu přímo komunikoval s úložištěm dat.

Řešení

Je potřeba vyřešit problém řízení přístupu k úložišti dat, kdy úložiště nemůže spravovat ověřování a autorizaci klientů. Jedním z typických řešení je omezit přístup k veřejnému připojení úložiště dat a poskytnout klientovi klíč nebo token, který může úložiště dat ověřit.

Tento klíč nebo token označujeme jako osobní klíč (valet key). Poskytuje časově omezený přístup ke konkrétním prostředkům a umožňuje provádět pouze předdefinované operace, jako je čtení a zápis v případě úložiště nebo fronty nebo odesílání a stahování v případě webového prohlížeče. Aplikace může snadno a rychle vytvořit a vystavit osobní klíč klientskému zařízení nebo webovému prohlížeči. Tento klíč klientovi umožní provádět požadované operace, aniž by aplikace musela zpracovávat přenosy dat přímo. Tím se omezí nároky na zpracování a sníží se dopad na výkon a škálovatelnost na straně aplikace a serveru.

Tento token umožňuje klientovi přistupovat ke konkrétnímu prostředku v úložišti dat, přičemž přístup je omezený jak časově, tak z hlediska přístupových oprávnění, jak to znázorňuje obrázek. Po uplynutí určité doby se klíč stává neplatným a přístup k prostředku nadále neumožňuje.

Pro klíč můžete nakonfigurovat také další závislosti, například rozsah data. V závislosti na možnostech úložiště dat může klíč v úložišti dat například upravovat celou tabulku, nebo jen její konkrétní řádky. V cloudových úložných systémech může mít klíč přístup k celému kontejneru, nebo jen ke konkrétní položce v něm.

Aplikace také může ukončit platnost klíče. Například když klient oznámí serveru, že byla dokončena operace přenosu dat. Server pak může tento klíč zneplatnit, aby se zabránilo dalšímu přístupu.

Tento model může zjednodušit správu přístupů k prostředkům, protože díky němu odpadá nutnost vytvořit a ověřit uživatele, udělit mu oprávnění a pak tohoto uživatele znovu odebrat. Také usnadňuje omezení umístění, oprávnění a doby platnosti – to vše jednoduše vygenerováním klíče za běhu. Důležitým faktorem je co největší omezení doby platnosti a hlavně umístění prostředku, aby mohl příjemce použít klíč jen pro zamýšlený účel.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

Správa stavu platnosti a období klíče. Pokud dojde k úniku nebo ohrožení bezpečnosti klíče, znamená to v zásadě, že cílová položka je během doby platnosti odemčená a přístupná pro zneužití. V závislosti na tom, jak byl klíč vystaven, je ho obvykle možné odvolat nebo zablokovat. Je možné změnit serverové zásady nebo lze zrušit platnost serverového klíče použitého k podepsání. Abyste minimalizovali riziko povolení neautorizovaných operací, nastavte krátkou dobu platnosti. Pokud je ale doba platnosti klíče příliš krátká, může se stát, že klient před vypršením jeho platnosti nestihne dokončit operaci. Pokud potřebujete více přístupů k chráněným prostředkům, povolte, aby mohli autorizovaní uživatelé platnost klíče před vypršením obnovit.

Řízení úrovně přístupu, kterou klíč poskytuje. Klíč by měl uživateli standardně umožnit pouze provedení akcí, které jsou potřeba k dokončení operace, například pokud klient nemá mít oprávnění nahrávat do úložiště data, měl by mít přístup jen pro čtení. V případě nahrávání souborů je běžné nastavit klíč pouze s oprávněním k zápisu a s omezením na určitou dobu a umístění. Je velmi důležité definovat přesně prostředek nebo sadu prostředků, na které se má klíč vztahovat.

Zvažte, jak řídit chování uživatelů. Implementace tohoto modelu obnáší určitou ztrátu kontroly nad prostředky, ke kterým mají uživatelé udělený přístup. Možnosti řízení jsou omezené zásadami a oprávněními definovanými pro službu nebo cílové úložiště dat. Obvykle například nelze vytvořit klíč, který by omezoval velikost dat zapisovaných do úložiště nebo počet jeho použití pro přístup k souboru. To může vést ke vzniku obrovských neočekávaných nákladů na přenos dat, a to i v případě použití zamýšleným klientem, například v důsledku chyby v kódu, která způsobí opakované nahrávání a stahování. Pokud chcete omezit počet nahrání souboru na minimum, vynuťte, aby klient po dokončení každé operace odeslal aplikaci oznámení. Některá úložiště dat například vyvolávají události, které můžete použít v kódu aplikace, abyste mohli monitorovat operace a řídit chování uživatele. V případě víceklientských scénářů, kdy stejný klíč používají všichni uživatelé z jednoho tenanta, je obtížné vynutit kvóty pro jednotlivé uživatele.

Ověřování a případné úpravy všech odesílaných dat. Uživatel se zlými úmysly, který získá přístup ke klíči, může do systému nahrát data ohrožující zabezpečení tohoto systému. Autorizovaní uživatelé můžou zase nahrát data, která jsou neplatná, a při jejich zpracování může dojít k chybě nebo selhání systému. Abyste tomu předešli, zkontrolujte ještě před použitím všechna nahraná data a ověřte, jestli neobsahují škodlivý obsah.

Auditování všech operací. Mnoho mechanismů zpracování klíče může protokolovat operace jako nahrávání, stahování nebo selhání. Tyto protokoly je obvykle možné zahrnout do procesu auditování. A pokud jsou uživateli účtovány poplatky na základě velikosti souborů nebo objemu dat, dají se použít také k fakturaci. Protokoly můžete použít k detekci neúspěšných ověření způsobených například problémy se zprostředkovatelem klíče nebo neúmyslným odebráním uložených zásad přístupu.

Bezpečné doručení klíče. Klíč může být součástí adresy URL, kterou uživatel aktivuje na webové stránce, nebo může být použitý v operaci přesměrování na serveru, která automaticky spustí stahování. Používejte vždy HTTPS, aby byl klíč doručován přes zabezpečený kanál.

Ochrana citlivých dat během přenosu. Citlivá data doručovaná prostřednictvím aplikace se obvykle provádí pomocí protokolu TLS a tato data by se měla vynucovat pro klienty, kteří přistupují přímo k úložišti dat.

Další skutečnosti, na které je potřeba při implementaci tohoto modelu pamatovat:

• Pokud klient neoznámí nebo nemůže oznámit serveru, že proběhlo dokončení operace, a jediným limitem je období platnosti klíče, nebude moct aplikace provádět operace auditování – například monitorovat počet nahrání nebo stažení nebo zabránit opakovanému nahrání nebo stažení.

• Je možné omezit flexibilitu zásad klíče, které lze generovat. Například některé mechanismy povolují pouze použití časového období vypršení platnosti. U jiných nelze nastavit dostatečnou členitost oprávnění pro čtení a zápis.

• Pokud zadáváte počáteční čas období platnosti klíče nebo tokenu, nastavte o něco dřívější čas, než je aktuální čas serveru – hodiny klienta totiž můžou být mírně nesynchronizované. Pokud čas nezadáte, použije se obvykle aktuální čas serveru.

• Adresa URL obsahující klíč se zaznamená v souborech protokolů serveru. V době, kdy analyzujete soubory protokolu, už platnost klíče zpravidla vypršela, přesto omezte přístup k protokolu. Pokud jsou protokolovaná data přenášena do monitorovacího systému nebo jiného umístění, zvažte nastavení zpožděného odesílání, abyste předešli úniku klíče v době, kdy jeho platnost ještě nevypršela.

• Pokud se kód klienta používá ve webovém prohlížeči, bude možná potřeba povolit v prohlížeči podporu sdílení prostředků mezi zdroji (CORS), aby kód spuštěný v tomto prohlížeči mohl přistupovat k datům v jiné doméně, než je ta, která stránku obsluhuje. Některé starší prohlížeče a některá úložiště dat nepodporují CORS a kód, který běží v těchto prohlížečích, nemusí být schopen použít valet key k poskytnutí přístupu k datům v jiné doméně, jako je například účet cloudového úložiště.

Kdy se má tento model použít

Tento model je užitečný v následujících scénářích:

• Když chcete minimalizovat načítání prostředků a maximalizovat výkon a škálovatelnost. Použití osobního klíče nevyžaduje uzamčení prostředku ani volání vzdáleného serveru, neomezuje počet osobních klíčů, které je možné vystavit, a předchází vzniku kritického prvku způsobujícího selhání při přenosu dat prostřednictvím kódu aplikace. Vytvoření osobního klíče je obvykle jednoduchá kryptografická operace spočívající v podepsání řetězce s klíčem.

• Když chcete minimalizovat provozní náklady. Povolení přímého přístupu k úložištím a frontám je úsporné z hlediska prostředků a nákladů, může zkrátit dobu odezvy v síti a pomoct snížit počet požadovaných výpočetních prostředků.

• Když klienti pravidelně nahrávají nebo stahují data, zejména v případě velkého objemu dat, nebo když každá operace zahrnuje velké soubory.

• Když má aplikace k dispozici omezené množství výpočetních prostředků, ať už z důvodu omezeného hostování, nebo úspory nákladů. V tomto scénáři je tento model zvlášť užitečný, pokud probíhá velké množství paralelních operací nahrávání nebo stahování dat, protože tyto přenosy dat nemusí zpracovávat aplikace.

• Když jsou data uložená ve vzdáleném úložišti dat nebo jiném datovém centru. Pokud aplikace plní roli vrátného, můžou být účtovány poplatky za větší šířku pásma kvůli přenosu dat mezi datovými centry nebo mezi klientem a aplikací ve veřejné nebo privátní síti a potom mezi aplikací a úložištěm dat.

Tento model nemusí být vhodný v následujících situacích:

• Když musí aplikace provádět určité operace s daty před jejich uložením nebo odesláním klientovi. Pokud aplikace provádí například ověření, protokoluje úspěšné přístupy nebo transformuje data. Některá úložiště dat a klienti ale můžou vyjednat a provádět jednoduché transformace, jako je komprese a dekomprese (například webový prohlížeč může obvykle zpracovávat formáty gzip).

• V případě, že je kvůli návrhu stávající aplikace obtížné model začlenit. Použití tohoto modelu obvykle vyžaduje jiný přístup k architektuře týkající se doručování a přijímání dat.

• Pokud je potřeba uchovávat záznamy pro audit nebo řídit počet provedených operací přenosu dat a používaný mechanismus osobního klíče nepodporuje oznámení, která by mohl server ke správě těchto operací použít.

• Pokud je potřeba omezit velikost dat, zejména u operací nahrávání. Toho je možné docílit pouze tak, že aplikace po dokončení každé operace zkontroluje velikost dat, nebo po uplynutí určitého období, případně v pravidelných intervalech, zkontrolujte objem nahraných dat.

Návrh úloh

Architekt by měl vyhodnotit způsob použití vzoru Valet Key v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Azure podporuje sdílené přístupové podpisy v Azure Storage pro podrobné řízení přístupu k datům v objektech blob, tabulkách a frontách a pro fronty a témata služby Service Bus. Můžete nakonfigurovat token sdíleného přístupového podpisu, který bude poskytovat konkrétní přístupová práva, například oprávnění ke čtení, zápisu, aktualizaci a odstraňování určité tabulky, rozsahu klíčů v tabulce, fronty, objektu blob nebo kontejneru objektů blob. Platnost může být zadaná časová období. Tato funkce je vhodná pro použití osobního klíče pro přístup.

Zvažte úlohu, která má stovky mobilních nebo desktopových klientů, kteří často nahrávají velké binární soubory. Bez tohoto vzoru má úloha v podstatě dvě možnosti. První je poskytnout stálý přístup a konfiguraci všem klientům, aby mohli provádět nahrávání přímo do účtu úložiště. Druhým je implementace modelu směrování brány pro nastavení koncového bodu, ve kterém klienti používajíxiovaný přístup k úložišti, ale nemusí do transakce přidávat další hodnotu. Oba přístupy trpí problémy vyřešené v kontextu vzoru:

• Dlouhou dobu, předsdílené tajné kódy. Potenciálně bez velkého způsobu poskytování různých klíčů různým klientům.
• Přidali jsme výdaje za spuštění výpočetní služby, která má dostatek prostředků pro aktuálně přijímané velké soubory.
• Potenciálně zpomalí interakce klientů přidáním další vrstvy výpočetních prostředků a směrování sítě do procesu nahrávání.

Použití vzoru Valet Key řeší problémy se zabezpečením, optimalizací nákladů a výkonem.

1. Klienti se od posledního zodpovědného okamžiku ověřují na lehkou hmotnost, škálovat na nulu hostovaného rozhraní API služby Azure Functions a požádat o přístup.

2. Rozhraní API ověří požadavek a pak získá a vrátí časový a omezený token SaS s rozsahem.

   Token vygenerovaný rozhraním API omezuje klienta na následující omezení:

   • Který účet úložiště se má použít. To znamená, že klient nemusí tyto informace předem znát.
   • Konkrétní kontejner a název souboru, které se mají použít; zajistit, aby se token mohl používat s maximálně jedním souborem.
   • Krátké okno operace, například tři minuty. Toto krátké časové období zajišťuje, aby tokeny měly hodnotu TTL, která neprodlužuje její nástroj.
   • Oprávnění pouze k vytvoření objektu blob, ne ke stažení, aktualizaci nebo odstranění.

3. Tento token pak používá klient v úzkém časovém intervalu k nahrání souboru přímo do účtu úložiště.

Rozhraní API generuje tyto tokeny autorizovaným klientům pomocí klíče delegování uživatele na základě vlastní spravované identity Microsoft Entra ID rozhraní API. Protokolování je povolené u účtů úložiště i rozhraní API pro generování tokenů umožňuje korelaci mezi požadavky na tokeny a použitím tokenu. Rozhraní API může použít ověřovací informace klienta nebo jiná dostupná data k rozhodnutí, který účet úložiště nebo kontejner se má použít, například ve víceklientské situaci.

Kompletní ukázka je k dispozici na GitHubu v příkladu vzoru Valet Key. Následující fragmenty kódu jsou upraveny z tohoto příkladu. První z nich ukazuje, jak funkce Azure Functions (nalezená ve službě ValetKey.Web) generuje token delegovaného sdíleného přístupového podpisu uživatelem pomocí vlastní spravované identity funkce Azure Functions.

[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();
  };
}

Následující fragment kódu je objekt pro přenos dat (DTO) používaný rozhraním API i klientem.

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

Klient (nalezený ve službě ValetKey.Client) pak použije identifikátor URI a token vrácený z rozhraní API k provedení nahrávání, aniž by vyžadoval další prostředky a při plném výkonu klient-úložiště.

...

// 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);
}

...

Další kroky

Při implementaci tohoto modelu můžou být relevantní následující pokyny:

• Implementace příkladu je k dispozici na GitHubu v příkladu vzoru Valet Key.
• Udělení omezeného přístupu k prostředkům Azure Storage pomocí sdílených přístupových podpisů
• Ověřování sdílených přístupových podpisů pomocí služby Service Bus

Související prostředky

Při implementaci tohoto modelu můžou být relevantní také následující vzory:

• Model Vrátný. Tento model lze použít ve spojení s modelem osobního klíče k ochraně aplikací a služeb pomocí vyhrazené hostitelské instance, která plní úlohu zprostředkovatele mezi klienty a aplikací nebo službou. Vrátný ověřuje a upravuje požadavky a zajišťuje předávání požadavků a dat mezi klientem a aplikací. Může tak zajišťovat další vrstvu zabezpečení a zmenšit prostor pro útok na systém.
• Model hostování statického obsahu. Popisuje, jak nasadit statické prostředky do služby cloudového úložiště, která je může poskytovat přímo klientovi, aby se snížil počet požadavků na nákladné instance výpočtů. Pokud nechcete, aby byly prostředky veřejně dostupné, můžete je pomocí modelu osobního klíče zabezpečit.