Valetsleutelpatroon

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. Het biedt beperkte toegang tot specifieke resources en biedt alleen vooraf gedefinieerde bewerkingen met gedetailleerde controle, zoals schrijven naar opslag, maar niet lezen, of uploaden en downloaden in 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.

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 kunt u de toegang tot resources vereenvoudigen omdat er geen vereiste is om een gebruiker te maken en te verifiëren, machtigingen te verlenen en vervolgens de gebruiker opnieuw te verwijderen of deze machtiging nog erger te laten staan als een permanente machtiging. Het maakt het ook eenvoudig om de locatie, de machtiging en de geldigheidsperiode te beperken, allemaal door simpelweg 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 moeilijk om quota af te dwingen voor afzonderlijke gebruikers in een scenario met meerdere tenants waarbij dezelfde sleutel wordt gebruikt door alle gebruikers van één tenant. Door gebruikers machtigingen te verlenen, kunt u de hoeveelheid gegevens beheren die wordt bijgewerkt door tokens effectief gebruik te maken. De machtiging voor maken staat geen overschrijven toe, dus elk token kan slechts worden gebruikt voor één schrijfactiviteit.

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 met de sleutel kan worden vastgelegd in serverlogboekbestanden. 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.

• Hoewel de client geen vooraf geconfigureerde verificatie voor de eindresource hoeft te hebben, moet de client een vooraf geconfigureerde verificatiemethode voor de service voor de valetsleutel maken.

• Sleutels mogen alleen worden verstrekt aan geverifieerde clients met de juiste autorisatie.

• Het genereren van toegangstokens is bevoegde actie, dus de service voor de valetsleutel moet worden beveiligd met strikt toegangsbeleid. De service kan toegang verlenen tot gevoelige systemen door derden, waardoor de beveiliging van deze service van bijzonder belang is.

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.

• Wanneer de gegevens worden opgeslagen in een extern gegevensarchief of een andere regio. Als de toepassing als gatekeeper moet fungeren, kunnen er kosten in rekening worden gebracht voor de extra bandbreedte voor het overdragen van de gegevens tussen regio's of in openbare of particuliere netwerken tussen de client en de toepassing, en vervolgens tussen de toepassing en het gegevensarchief.

Dit patroon is wellicht niet geschikt in de volgende situaties:

• Als clients al uniek kunnen verifiëren bij uw back-endservice, gebruikt u dit patroon bijvoorbeeld niet met RBAC.

• 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 decomprimatie (een webbrowser kan bijvoorbeeld 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.

Workloadontwerp

Een architect moet evalueren hoe het valetsleutelpatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

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 een opgegeven periode zijn. Deze functionaliteit is geschikt voor het gebruik van een valetsleutel voor toegang.

Overweeg een workload met honderden mobiele of desktopclients die vaak grote binaire bestanden uploaden. Zonder dit patroon heeft de workload in wezen twee opties. De eerste is om permanente toegang en configuratie te bieden aan alle clients om rechtstreeks uploads uit te voeren naar een opslagaccount. Het andere is het implementeren van het gatewayrouteringspatroon om een eindpunt in te stellen waarbij clients geproxiede toegang tot opslag gebruiken, maar dit kan geen extra waarde toevoegen aan de transactie. Beide benaderingen lijden aan problemen die zijn opgelost in de patrooncontext:

• Langlevend, vooraf gedeelde geheimen. Mogelijk zonder veel manier om verschillende sleutels aan verschillende clients te bieden.
• Extra kosten voor het uitvoeren van een rekenservice met voldoende resources om te kunnen omgaan met momenteel grote bestanden.
• Mogelijk vertragen clientinteracties door een extra laag reken- en netwerkhop toe te voegen aan het uploadproces.

Met behulp van het valetsleutelpatroon worden de beveiligings-, kostenoptimalisatie- en prestatieproblemen opgelost.

1. Clients verifiëren zich op het laatste verantwoordelijke moment bij een lichtgewicht, scale-to-zero door Azure Function gehoste API om toegang aan te vragen.

2. De API valideert de aanvraag en verkrijgt en retourneert vervolgens een beperkt SaS-token voor tijd en bereik.

   Het token dat door de API wordt gegenereerd, beperkt de client tot de volgende beperkingen:

   • Welk opslagaccount moet worden gebruikt. Dit betekent dat de client deze informatie niet van tevoren hoeft te kennen.
   • Een specifieke container en bestandsnaam die moeten worden gebruikt; ervoor zorgen dat het token kan worden gebruikt met maximaal één bestand.
   • Een kort bewerkingsvenster, zoals drie minuten. Deze korte periode zorgt ervoor dat tokens een TTL hebben die niet voorbij het hulpprogramma wordt uitgebreid.
   • Machtigingen om alleen een blob te maken , niet te downloaden, bij te werken of te verwijderen.

3. Dat token wordt vervolgens gebruikt door de client, binnen het beperkte tijdvenster, om het bestand rechtstreeks naar het opslagaccount te uploaden.

De API genereert deze tokens voor geautoriseerde clients met behulp van een gebruikersdelegeringssleutel op basis van de eigen door Microsoft Entra ID beheerde identiteit van de API. Logboekregistratie is ingeschakeld voor zowel de opslagaccounts als de API voor het genereren van tokens, waardoor correlatie tussen tokenaanvragen en tokengebruik mogelijk is. De API kan clientverificatiegegevens of andere gegevens gebruiken die beschikbaar zijn om te bepalen welk opslagaccount of welke container moet worden gebruikt, zoals in een situatie met meerdere tenants.

Er is een volledig voorbeeld beschikbaar op GitHub in het voorbeeld van het valetsleutelpatroon. De volgende codefragmenten zijn aangepast uit dat voorbeeld. Deze eerste laat zien hoe de Azure-functie (gevonden in ValetKey.Web) een door de gebruiker gedelegeerd shared access Signature-token genereert met behulp van de eigen beheerde identiteit van de Azure-functie.

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

Het volgende codefragment is het object voor gegevensoverdracht (DTO) dat wordt gebruikt door zowel de API als de client.

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

De client (gevonden in ValetKey.Client) gebruikt vervolgens de URI en het token dat door de API wordt geretourneerd om het uploaden uit te voeren zonder extra resources en bij volledige prestaties van client-naar-opslag.

...

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

...

Volgende stappen

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

• De implementatie van het voorbeeld is beschikbaar op GitHub in het voorbeeld van het Valet Key-patroon.
• Beperkte toegang verlenen tot Azure Storage-resources door middel van een SAS
• Shared Access Signature-verificatie met Service Bus

Verwante resources

De volgende patronen zijn mogelijk ook relevant 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.