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 zajišťuje přesun dat – buď je načítá z úložiště a streamuje klientovi, nebo čte nahraný stream z klienta a ukládá ho 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 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íč zneplatnět, 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. Protože je klíč generován za běhu, je také snazší omezit umístění, oprávnění a dobu platnosti. 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. Je ale obtížné vynucovat kvóty pro jednotlivé uživatele ve scénářích s více tenanty, kde všichni uživatelé z jednoho tenanta používají stejný klíč.

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 přenášená prostřednictvím aplikace jsou obvykle doručována pomocí protokolů SSL nebo TLS. Ty je potřeba vynutit u klientů, kteří k úložišti dat přistupují přímo.

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 CORS nepodporují a kód, který běží v těchto prohlížečích, nemusí být schopen použít osobní klíč 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 mohou vyjednat a provádět jednoduché transformace, jako je komprese a dekomprese (například webový prohlížeč obvykle dokáže zpracovat 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.

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 buď omezená na určité časové období, nebo neomezená.

Sdílené přístupové podpisy Azure podporují také zásady přístupu uložené na serveru, které můžou být spojené s určitým prostředkem, například tabulkou nebo objektem blob. Ve srovnání s tokeny sdíleného přístupového podpis generovanými v aplikaci poskytuje tato funkce větší kontrolu a flexibilitu a měla by být používána, kdykoli je to možné. Můžete provést změnu nastavení zásad uložených na serveru a tyto změny se projeví v tokenu, aniž by bylo potřeba vystavovat nový token. U nastavení definovaných v tokenu to ale neplatí a při jejich změně je vždy potřeba vystavit nový token. Tento přístup také umožňuje odvolat platný token sdíleného přístupového podpisu ještě před vypršením jeho platnosti.

Další informace najdete v tématu Udělení omezeného přístupu k prostředkům Azure Storage pomocí sdílených přístupových podpisů (SAS).

Následující kód ukazuje, jak vytvořit token sdíleného přístupového podpisu, který je platný pět minut. Metoda GetSharedAccessReferenceForUpload vrátí token sdílených přístupových podpisů, který je možné použít k nahrání souboru do úložiště Azure Blob Storage.

public class ValuesController : ApiController
{
  private readonly BlobServiceClient blobServiceClient;
  private readonly string blobContainer;
  ...
  /// <summary>
  /// Return a limited access key that allows the caller to upload a file
  /// to this specific destination for a defined period of time.
  /// </summary>
  private StorageEntitySas GetSharedAccessReferenceForUpload(string blobName)
  {          
      var blob = blobServiceClient.GetBlobContainerClient(this.blobContainer).GetBlobClient(blobName);
      var storageSharedKeyCredential = new StorageSharedKeyCredential(blobServiceClient.AccountName, ConfigurationManager.AppSettings["AzureStorageEmulatorAccountKey"]);

      var blobSasBuilder = new BlobSasBuilder
      {
          BlobContainerName = this.blobContainer,
          BlobName = blobName,
          Resource = "b",
          StartsOn = DateTimeOffset.UtcNow.AddMinutes(-5),
          ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(5)
      };
      blobSasBuilder.SetPermissions(BlobSasPermissions.Write);
  
      return new StorageEntitySas
      {
          BlobUri = blob.Uri,
          Credentials = blobSasBuilder.ToSasQueryParameters(storageSharedKeyCredential).ToString()
      };
  }
  public struct StorageEntitySas
  {
      public string Credentials;
      public Uri BlobUri;
  }
}

Celá ukázka je dostupná v řešení ValetKey, které je k dispozici ke stažení na GitHubu. Toto řešení obsahuje projekt ValetKey.Web s webovou aplikací, která zahrnuje třídu ValuesController uvedenou výše. Ukázková klientská aplikace, která používá tuto webovou aplikaci k načtení klíče sdílených přístupových podpisů a nahrání souboru do úložiště objektů blob, je k dispozici v projektu ValetKey.Client.

Další kroky

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

• Ukázka, která tento model předvádí, je k dispozici na GitHubu.
• Udělení omezeného přístupu Azure Storage prostředkům pomocí sdílených přístupových podpisů (SAS)
• Ověřování sdílených přístupových podpisů pomocí služby Service Bus

Související informace

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.