Valetsleutelpatroon

Azure
Storage

Gebruik een token dat clients beperkte directe toegang tot een specifieke bron biedt, zodat offload van gegevensoverdracht vanaf de toepassing kan worden toegepast. Dit is met name nuttig bij toepassingen die gebruikmaken van cloudopslagsystemen of -wachtrijen en kan de kosten minimaliseren en de schaalbaarheid en prestaties maximaliseren.

Context en probleem

Clientprogramma's en webbrowsers moeten vaak bestanden of gegevensstromen van en naar de opslag van een toepassing lezen en schrijven. Normaal gesproken verwerkt de toepassing de verplaatsing van de gegevens, ofwel door deze op te halen uit de opslag en naar de client te streamen, of door de geüploade stream van de client te lezen en op te slaan in het gegevensarchief. Deze benadering neemt echter waardevolle resources in beslag, zoals rekenkracht, geheugen en bandbreedte.

Gegevensarchieven kunnen gegevens direct uploaden of downloaden zonder dat de toepassing de gegevens zelf hoeft te verplaatsen. Hiervoor moet de client gewoonlijk toegang hebben tot de beveiligingsreferenties voor het archief. Het kan een handige techniek zijn om de kosten van gegevensoverdracht en de vereiste de toepassing uit te schalen, te minimaliseren, en de prestaties te maximaliseren. Het betekent echter wel dat de toepassing niet langer de beveiliging van de gegevens kan beheren. Nadat de client verbinding met het gegevensarchief heeft gemaakt voor directe toegang, kan de toepassing niet als de gatekeeper fungeren. De toepassing heeft niet langer het beheer over het proces en kan navolgende uploads of downloads vanuit het gegevensarchief niet voorkomen.

Dit is geen realistische benadering in gedistribueerde systemen die niet-vertrouwde clients moeten bedienen. In plaats daarvan moeten toepassingen de toegang tot gegevens op een veilige en zorgvuldige manier kunnen beheren, maar nog steeds de belasting op de server verminderen door deze verbinding in te stellen, zodat de client rechtstreeks kan communiceren met het gegevensarchief om de vereiste lees- of schrijfbewerkingen uit te voeren.

Oplossing

Los het probleem van het toegangsbeheer tot een gegevensarchief op, waarbij de verificatie en autorisatie van clients niet door het archief kan worden uitgevoerd. Een typische oplossing is om de toegang tot de openbare verbinding van het gegevensarchief te beperken en de client een sleutel of token te bieden die door het gegevensarchief kan worden gevalideerd.

Deze sleutel of token wordt meestal aangeduid als een valetsleutel. Deze biedt voor een beperkte periode toegang tot bepaalde resources, waarbij alleen vooraf gedefinieerde bewerkingen zijn toegestaan, zoals lezen en schrijven naar het archief of een wachtrij, of het uploaden en downloaden van gegevens via een webbrowser. Toepassingen kunnen valetsleutels snel een eenvoudig maken en uitgeven voor clientapparaten en webbrowsers. Hierdoor kunnen clients de vereiste bewerkingen uitvoeren zonder dat de toepassing de gegevens rechtstreeks hoeft over te dragen. Hierdoor vervalt de overhead van de gegevensverwerking en de impact op de prestaties en schaalbaarheid voor de toepassing en de server.

De client gebruikt dit token gedurende een bepaalde periode en met specifieke beperkingen voor toegangsmachtigingen om toegang te krijgen tot een specifieke bron in het gegevensarchief, zoals weergegeven in de afbeelding. Na de vastgestelde periode is de sleutel ongeldig en is er geen toegang tot de resource meer mogelijk.

Figure 1 - Overview of the pattern

Het is ook mogelijk om een sleutel te configureren die andere afhankelijkheden heeft, zoals het bereik van de gegevens. Afhankelijk van de mogelijkheden van het gegevensarchief kan de sleutel bijvoorbeeld een volledige tabel (of bepaalde rijen in een tabel) in een gegevensarchief aangeven. In cloudopslagsystemen kan met de sleutel een container worden opgegeven of alleen een specifiek item in een container.

De sleutel kan ook ongeldig worden gemaakt door de toepassing. Dit is een nuttige methode als de client de server op de hoogte stelt dat het overdragen van gegevens is voltooid. De server kan die sleutel vervolgens ongeldig maken om verdere toegang te voorkomen.

Met dit patroon kan het beheer voor toegang tot resources worden vereenvoudigd omdat er geen gebruiker hoeft te worden gemaakt en geverifieerd, machtigen te worden toegewezen en de gebruiker vervolgens te verwijderen. Het maakt het ook eenvoudig om de locatie, de machtiging en de geldigheidsperiode te beperken, allemaal door gewoon een sleutel tijdens runtime te genereren. De belangrijkste factoren bestaan uit het zo veel mogelijk beperken van de geldigheidsperiode en vooral de locatie van de resource. Hierdoor kan de ontvanger de resource alleen gebruiken voor het beoogde doel.

Problemen en overwegingen

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

Beheer de geldigheidsstatus en -duur van de sleutel. Als de sleutel verloren raakt of als er mee wordt geknoeid, wordt het doelitem ontgrendelt en kan hiervan gedurende de geldigheidsperiode misbruik worden gemaakt. Een sleutel kan meestal worden herroepen of uitgeschakeld, afhankelijk van hoe deze is uitgegeven. Beleid aan de serverzijde kan worden gewijzigd of de serversleutel waarmee het beleid is ondertekend, kan ongeldig worden gemaakt. Geef een korte geldigheidsperiode op om de kans op het toestaan van niet-geautoriseerde bewerkingen in het gegevensarchief te minimaliseren. Als de geldigheidsperiode echter te kort is, is de client mogelijk niet in staat de bewerking te voltooien voordat de geldigheidsperiode verloopt. Sta niet-gemachtigde gebruikers toe de sleutel te vernieuwen voordat de geldigheidsperiode verloopt indien meerdere toegangspogingen tot de beveiligde resource zijn vereist.

Bepaal het toegangsniveau dat de sleutel biedt. Gewoonlijk kan de gebruiker met de sleutel alleen de noodzakelijke acties uitvoeren om de bewerking te voltooien, zoals alleen-lezentoegang als de client geen gegevens kan uploaden in het gegevensarchief. Voor het uploaden van bestanden is het normaal om een sleutel op te geven waarmee alleen-schrijvenrechten en de locatie- en geldigheidsperiode worden gegeven. Het is essentieel dat de resource of set resources waarvoor de sleutel is bestemd, zorgvuldig worden opgegeven.

Overweeg hoe u het gedrag van gebruikers kunt beheren. Het implementeren van dit patroon houdt enig verlies in van de controle over de resources waartoe toegang wordt verleend. De mate van controle die kan worden uitgeoefend, wordt beperkt door de mogelijkheden van het beleid en de machtigingen die voor de service of het doelgegevensarchief beschikbaar zijn. Het is bijvoorbeeld niet mogelijk een sleutel te maken die een beperking oplegt aan de grootte van de gegevens die naar het archief moeten worden geschreven of aan het aantal keren dat de sleutel kan worden gebruikt om een bestand te openen. Dit kan tot hoge, onverwachte kosten voor gegevensoverdracht leiden, ook als de sleutel door de beoogde client wordt gebruikt, en kan worden veroorzaakt door herhaald uploaden of downloaden als gevolg van een fout in de code. Als u het aantal keren dat een bestand kan worden geüpload, wilt beperken, kunt u er wellicht voor zorgen dat de client de toepassing informeert wanneer een bewerking is voltooid. In bepaalde gevallen kan de toepassingscode gebruikmaken van door een gegevensarchief in werking gesteld gebeurtenissen om bewerkingen te bewaken en gedrag van gebruikers te beheren. Het is echter lastig om quota af te dwingen voor afzonderlijke gebruikers in een scenario met meerdere tenants waarbij iedereen dezelfde sleutel van één tenant gebruikt.

Valideer alle geüploade gegevens en schoon ze eventueel op. Een kwaadwillende gebruiker die toegang krijgt tot de sleutel, kan gegevens uploaden waarmee schade aan het systeem kan worden toegebracht. Maar ook gemachtigde gebruikers kunnen gegevens uploaden die ongeldig zijn en, indien verwerkt, een fout of vastloper van het systeem veroorzaken. Als u dit wilt voorkomen, dient u voor gebruik alle geüploade gegevens te valideren en te controleren op schadelijke inhoud.

Controleer alle bewerkingen. Met diverse sleutelmethoden kunnen bewerkingen in een logboek worden geregistreerd, zoals uploads, downloads en fouten. Deze logboeken kunnen gewoonlijk worden opgenomen in een controleproces maar ook gebruikt voor facturering als de gebruiker moet betalen op basis van de bestandsgrootte of het gegevensvolume. Gebruik de logboeken om verificatiefouten te registreren die kunnen worden veroorzaakt door problemen met de sleutelprovider of indien een opgeslagen beleidsregel voor toegang per ongeluk wordt verwijderd.

Lever de sleutel veilig af. De sleutel kan worden ingesloten in een URL die de gebruiker op een webpagina kan activeren, of gebruikt bij een omleiding naar een server zodat het downloaden automatisch wordt uitgevoerd. Gebruik altijd HTTPS om de sleutel via een veilig kanaal af te leveren.

Beveilig gevoelige gegevens tijdens de overdracht. Gevoelige gegevens die via de toepassing worden geleverd, vinden meestal plaats met BEHULP van TLS. Dit moet worden afgedwongen voor clients die rechtstreeks toegang hebben tot het gegevensarchief.

Andere problemen waar rekening mee moet worden gehouden bij het implementeren van dit patroon:

  • Als de client de server niet op de hoogte stelt (of kan stellen) dat een bewerking is voltooid en de enige beperking de verloopperiode van de sleutel is, kan de toepassing geen controlebewerkingen uitvoeren, zoals het tellen van het aantal uploads of downloads of het voorkomen van meerdere uploads of downloads.

  • De flexibiliteit van belangrijke beleidsregels die kunnen worden gegenereerd, is mogelijk beperkt. Met sommige methoden is bijvoorbeeld alleen het gebruik van een beperkte verloopperiode toegestaan. Met andere methoden kan bijvoorbeeld onvoldoende granulariteit worden geboden of zijn er geen lees- of schrijfmachtigingen.

  • Als de begintijd van de geldigheidsperiode voor de sleutel of het token is opgegeven, dient deze iets vroeger dan de huidige servertijd te worden ingesteld om rekening te houden met afwijkingen van de klokken van clients. De standaardwaarde, indien niet opgegeven, is gewoonlijk de huidige servertijd.

  • De URL die de sleutel bevat, wordt geregistreerd in logboekbestanden op de server. Hoewel de sleutel gewoonlijk is verlopen voordat de logboekbestanden voor analyse worden gebruikt, dient u de toegang tot deze bestanden te beperken. Als logboekgegevens naar een bewakingssysteem worden verzonden of op een andere locatie opgeslagen, kunt u overwegen een vertraging in te bouwen om verlies van sleutels te voorkomen nadat de geldigheidsperiode is afgelopen.

  • Als de clientcode wordt uitgevoerd in een webbrowser, dient de browser mogelijk ondersteuning te bieden voor CORS (Cross-Origin Resource Sharing), zodat code die wordt uitgevoerd in de webbrowser toegang tot gegevens heeft in een ander domein dan het domein dat de pagina onderhoudt. Sommige oudere browsers en sommige gegevensarchieven bieden geen ondersteuning voor CORS en code die in deze browsers wordt uitgevoerd, kan mogelijk geen valetsleutel gebruiken om toegang te bieden tot gegevens in een ander domein, zoals een cloudopslagaccount.

Wanneer dit patroon gebruiken

Dit patroon is geschikt in de volgende situaties:

  • Bij het minimaliseren van resourcebelasting en het maximaliseren van de prestaties en schaalbaarheid. Bij gebruik van een valetsleutel hoeft de resource niet te worden vergrendeld, hoeft er geen externe server te worden aangeroepen, is het uit te geven aantal valetsleutels onbeperkt en wordt voorkomen dat er een Single Point of Failure optreedt als gevolg van het uitvoeren van gegevensoverdracht via de toepassingscode. Het maken van een valetsleutel is normaal gesproken een eenvoudige, cryptografische bewerking waarbij een tekenreeks met een sleutel wordt ondertekend.

  • Bij het minimaliseren van de operationele kosten. Het toestaan van rechtstreekse toegang tot archieven en wachtrijen is resource- en kostenefficiënt en het kan leiden tot minder netwerkretouren. Ook is een reductie in het aantal rekenbronnen mogelijk.

  • Als clients regelmatig gegevens uploaden of downloaden, met name bij hoge volumes of als het bij elke bewerking om grote bestanden gaat.

  • Als er beperkte rekenbronnen voor de toepassing zijn, vanwege beperkte hosting of kostenoverwegingen. In dit scenario is het patroon nog zinvoller als er veel gelijktijdige uploads of downloads zijn, omdat de toepassing dan wordt vrijgesteld van het verwerken van de gegevensoverdracht.

  • Als de gegevens worden opgeslagen in een extern gegevensarchief of een ander datacenter. Als de toepassing als een gatekeeper moet fungeren, zijn er mogelijk kosten voor de extra bandbreedte voor het overdragen van de gegevens tussen datacenters of via openbare of particuliere netwerken tussen de client en de toepassing, en tussen de toepassing en het gegevensarchief.

Dit patroon is wellicht niet geschikt in de volgende situaties:

  • Als de toepassing bijvoorbeeld een taak met de gegevens moet uitvoeren voordat deze worden opgeslagen of naar de client verzonden. Bijvoorbeeld als de toepassing validatie moet uitvoeren, geslaagde toegang moet registreren of een transformatie van de gegevens moet uitvoeren. Sommige gegevensarchieven en clients kunnen echter onderhandelen en eenvoudige transformaties uitvoeren, zoals compressie en decompressie (bijvoorbeeld een webbrowser kan meestal gzip-indelingen verwerken).

  • Als het ontwerp van een bestaande toepassing opname van het patroon bemoeilijkt. Het gebruik van dit patroon vraagt gewoonlijk om een andere architectuur voor het afleveren en ontvangen van gegevens.

  • Als het noodzakelijk is audittrails te onderhouden of het aantal gegevensoverdrachten in de gaten te houden en de gebruikte valetsleutel geen meldingen ondersteunt die de server kan gebruiken om deze bewerkingen te regelen.

  • Als het nodig is de grootte van de gegevens te beperken, met name bij uploadbewerkingen. De enige oplossing hiervoor is dat de toepassing de grootte van de gegevens controleert nadat de bewerking is uitgevoerd of de grootte van de uploads controleert na een bepaalde periode of op regelmatige tijden.

Voorbeeld

Azure ondersteunt Shared Access Signature (SAS; handtekeningen voor gedeelde toegang) op Azure Storage voor gedetailleerd toegangsbeheer voor gegevens in blobs, tabellen en wachtrijen, en voor Service Bus-wachtrijen en -onderwerpen. Een SAS-token kan zodanig worden geconfigureerd dat specifieke rechten kunnen worden geboden, zoals het lezen, schrijven, bijwerken en verwijderen van een specifieke tabel, een sleutelbereik in een tabel, een wachtrij, een blob of een blobcontainer. De geldigheid kan tijdelijk of onbeperkt zijn.

Handtekeningen voor gedeelde toegang in Azure ondersteunt ook op servers opgeslagen beleidsregels voor toegang die kunnen worden gekoppeld aan een bepaalde resource, zoals een tabel of blob. Deze functie biedt meer controle en flexibiliteit vergeleken met door de toepassing gegenereerde SAS-tokens en dient zo mogelijk te worden gebruikt. De instellingen die in beleid op de server zijn gedefinieerd, kunnen worden gewijzigd en worden door het token overgenomen. Er hoeft dus geen nieuw token meer te worden uitgegeven, maar de in het token gedefinieerde instellingen kunnen alleen worden gewijzigd als er een nieuw token wordt uitgegeven. Dankzij deze benadering kan een geldig SAS-token worden ingetrokken voordat deze verloopt.

Zie Beperkte toegang verlenen tot Azure Storage resources met sas (Shared Access Signatures) voor meer informatie.

De volgende code toont hoe een SAS-token wordt gemaakt dat vijf minuten geldig is. De GetSharedAccessReferenceForUpload-methode retourneert een SAS-token dat kan worden gebruikt om een bestand te uploaden naar Azure Blob Storage.

[ApiController]
public class SasController : ControllerBase
{
  private readonly string blobContainer = "valetkeysample";
  private readonly string blobEndpoint = "https://<StorageAccountName>.blob.core.windows.net";
  ...
  /// <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 async Task<StorageEntitySas> GetSharedAccessReferenceForUpload(string blobName)
  {          
    var blobServiceClient = new BlobServiceClient(new Uri(blobEndpoint), new DefaultAzureCredential());

    var blobContainerClient = blobServiceClient.GetBlobContainerClient(this.blobContainer);
    var blobClient = blobContainerClient.GetBlobClient(blobName);
    var parentBlobServiceClient = blobContainerClient.GetParentBlobServiceClient();

    UserDelegationKey key = await parentBlobServiceClient.GetUserDelegationKeyAsync(DateTimeOffset.UtcNow, DateTimeOffset.UtcNow.AddDays(7));

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

    var storageSharedKeyCredential = new StorageSharedKeyCredential(blobServiceClient.AccountName, key.Value);

    return new StorageEntitySas
    {
      BlobUri = blobClient.Uri,
      Credentials = blobSasBuilder.ToSasQueryParameters(storageSharedKeyCredential).ToString()
    };
  }

  public struct StorageEntitySas
  {
    public string Credentials;
    public Uri BlobUri;
  }
}

Het volledige voorbeeld is beschikbaar in de ValetKey-oplossing die u kunt downloaden van GitHub. Het project ValetKey.Web in deze oplossing bevat een webtoepassing waarin de klasse SasController is opgenomen, zoals hierboven weergegeven. Een voorbeeld van een clienttoepassing die deze webtoepassing gebruikt om een SAS-sleutel op te halen en een bestand te uploaden naar Blob Storage, is beschikbaar in het project ValetKey.Client.

Volgende stappen

De volgende richtlijnen zijn mogelijk relevant bij het implementeren van dit patroon:

De volgende patronen kunnen ook relevant zijn bij het implementeren van dit patroon:

  • Gatekeeper-patroon. Dit patroon kan worden gebruikt in combinatie met het valetsleutelpatroon voor het beveiligen van toepassingen en services door gebruik te maken van een speciaal hostexemplaar dat als een broker tussen clients en de toepassing of service fungeert. De gatekeeper valideert aanvragen en schoont ze op, en stuurt aanvragen en gegevens tussen de client en de toepassing door. Dit biedt een extra beveiligingslaag en verkleint de kans op aanvallen op het systeem.
  • Patroon voor hosting van statische inhoud. Hierin wordt beschreven hoe statische resources moeten worden geïmplementeerd in een cloudopslagservice die deze resources rechtstreeks aan de client kan leveren, waarmee de behoefte aan (kostbare) rekenexemplaren wordt verminderd. Als de resources niet openbaar beschikbaar mogen zijn, kan het valetsleutelpatroon worden gebruikt om ze te beveiligen.