Wzorzec klucza portiera

Używając tokenu zapewniającego klientom ograniczony bezpośredni dostęp do określonego zasobu, można odciążyć transfer danych z aplikacji. Jest to szczególnie przydatne w aplikacjach, które korzystają z systemów magazynowania hostowanych w chmurze lub kolejek, i umożliwia zminimalizowanie kosztów oraz zmaksymalizowanie wydajności i skalowalności.

Kontekst i problem

Programy klienckie i przeglądarki internetowe często muszą odczytywać i zapisywać pliki lub strumienie danych do i z magazynu aplikacji. Zazwyczaj aplikacja będzie obsługiwać przenoszenie danych — pobierając je z magazynu i przesyłając strumieniowo do klienta, albo odczytując przekazany strumień z klienta i przechowując go w magazynie danych. Jednak takie podejście pochłania cenne zasoby, na przykład zasoby obliczeniowe, pamięć i przepustowość.

Magazyny danych mogą obsługiwać przekazywanie i pobieranie danych bezpośrednio, nie wymagając od aplikacji jakiegokolwiek przetwarzania w celu przeniesienia tych danych. Jednak zazwyczaj wymaga to od klienta dostępu do poświadczeń zabezpieczeń dla magazynu. Ta technika może być przydatna do zminimalizowania kosztów transferu danych i konieczności skalowania aplikacji oraz do zmaksymalizowania wydajności. Jednak oznacza to, że aplikacja nie może dłużej zarządzać bezpieczeństwem danych. Gdy klient łączy się z magazynem danych w celu uzyskania bezpośredniego dostępu, aplikacja nie może pełnić roli strażnika. Nie kontroluje już procesu i nie może zapobiegać dalszemu przekazywaniu ani pobieraniu z magazynu danych.

Nie jest to podejście realistyczne w systemach rozproszonych, które muszą obsługiwać klientów niezaufanych. Zamiast tego aplikacje muszą mieć możliwość bezpiecznego kontrolowania dostępu do danych w szczegółowy sposób i jednocześnie zmniejszania obciążenia serwera, konfigurując to połączenie, a następnie umożliwiając klientowi komunikowanie się bezpośrednio z magazynem danych w celu wykonania wymaganych operacji odczytu lub zapisu.

Rozwiązanie

Problem kontroli dostępu do magazynu danych w sytuacji, w której magazyn nie może zarządzać uwierzytelnianiem i autoryzacją klientów, wymaga rozwiązania. Typowym rozwiązaniem jest ograniczenie dostępu do publicznego połączenia magazynu danych i zapewnienie klientowi klucza lub tokenu, który może zweryfikować magazyn danych.

Ten klucz lub token jest zwykle nazywany kluczem portiera. Zapewnia on ograniczony czasowo dostęp do określonych zasobów i umożliwia wykonywanie tylko wstępnie zdefiniowanych operacji, takich jak odczytywanie i zapisywanie w magazynie lub kolejkach albo przekazywanie i pobieranie w przeglądarce internetowej. Aplikacje mogą szybko i łatwo tworzyć oraz wystawiać klucze portiera dla urządzeń klienckich i przeglądarek internetowych, umożliwiając klientom wykonywanie wymaganych operacji bez konieczności bezpośredniej obsługi transferu danych przez aplikację. Eliminuje to obciążenie związane z przetwarzaniem w aplikacji i na serwerze oraz niweluje wpływ na ich wydajność i skalowalność.

Klient używa tego tokenu, aby uzyskać dostęp do danego zasobu w magazynie danych tylko przez określony czas i z określonymi ograniczeniami uprawnień dostępu, jak pokazano na rysunku. Po upływie tego czasu klucz traci ważność i nie pozwala na dostęp do zasobu.

Istnieje również możliwość skonfigurowania klucza z innymi zależnościami, takimi jak zakres danych. Na przykład w zależności od funkcji magazynu danych klucz może określać pełną tabelę w magazynie danych lub tylko wybrane wiersze w tabeli. W systemach magazynowania w chmurze klucz może określać kontener lub tylko wybrany element w kontenerze.

Klucz może również zostać unieważniony przez aplikację. To rozwiązanie jest przydatne, jeśli klient informuje serwer o ukończeniu operacji transferu danych. Następnie serwer może unieważnić ten klucz, aby zapobiec dalszemu dostępowi.

Korzystając z tego wzorca, można uprościć zarządzanie dostępem do zasobów, ponieważ nie wymaga on tworzenia i uwierzytelniania użytkownika, przyznawania uprawnień, a następnie ponownego usuwania użytkownika. Ułatwia to również ograniczenie lokalizacji, uprawnień i okresu ważności — wszystko przez wygenerowanie klucza w czasie wykonywania. Ważnym czynnikiem jest ścisłe ograniczenie okresu ważności, a szczególnie lokalizacji zasobu, aby odbiorca mógł użyć go tylko zgodnie z przeznaczeniem.

Problemy i kwestie do rozważenia

Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:

Zarządzaj stanem i okresem ważności klucza. Ujawniony lub naruszony klucz skutecznie odblokowuje element docelowy i umożliwia jego złośliwe wykorzystanie w okresie ważności. Klucz można zwykle odwołać lub wyłączyć, w zależności od tego, jak został wystawiony. Można zmienić zasady po stronie serwera lub unieważnić klucz serwera, za pomocą którego został on podpisany. Aby zminimalizować ryzyko związane z zezwoleniem na wykonywanie nieautoryzowanych operacji w odniesieniu do magazynu danych, wyznacz krótki okres ważności. Jednak gdy okres ważności jest zbyt krótki, klient może nie zdążyć z wykonaniem operacji przed wygaśnięciem klucza. Jeśli wymaganych jest wiele operacji uzyskiwania dostępu do chronionego zasobu, zezwalaj autoryzowanym użytkownikom na odnawianie klucza przed upływem okresu ważności.

Kontroluj poziom dostępu zapewnianego przez klucz. Zazwyczaj klucz powinien pozwalać użytkownikowi tylko na wykonywanie akcji, które są niezbędne do ukończenia operacji, np. dostęp tylko do odczytu, gdy klient nie powinien mieć możliwości przekazywania danych do magazynu danych. W przypadku przekazywania plików często stosowanym rozwiązaniem jest określenie klucza dającego uprawnienia tylko do zapisu, a także lokalizacji i okresu ważności. Niezwykle ważne jest dokładne określenie zasobu lub zestawu zasobów, których dotyczy klucz.

Zastanów się, jak kontrolować zachowanie użytkowników. Zaimplementowanie tego wzorca oznacza pewną utratę kontroli nad zasobami, do których mają dostęp użytkownicy. Poziom kontroli, który może być stosowany, jest ograniczony przez możliwości zasad i uprawnienia dostępne dla usługi lub docelowego magazynu danych. Na przykład zazwyczaj nie jest możliwe utworzenie klucza ograniczającego rozmiar danych, które można zapisać w magazynie, czy liczbę możliwych użyć klucza w celu uzyskania dostępu do pliku. Może to spowodować ogromne i nieoczekiwane koszty transferu danych, nawet w przypadku użycia przez właściwego klienta. Przyczyną może być błąd w kodzie powodujący wielokrotne przekazywanie lub pobieranie. Aby ograniczyć liczbę możliwych przekazań pliku, tam, gdzie to możliwe, wymuszaj na kliencie informowanie aplikacji o ukończeniu operacji. Na przykład niektóre magazyny danych wywołują zdarzenia, które mogą być używane przez kod aplikacji do monitorowania operacji i kontrolowania zachowania użytkowników. Trudno jednak wymusić limity przydziału dla poszczególnych użytkowników w scenariuszu wielodostępnym, w którym ten sam klucz jest używany przez wszystkich użytkowników z jednej dzierżawy.

Weryfikuj i, opcjonalnie, oczyszczaj wszystkie przekazane dane. Złośliwy użytkownik, który uzyska dostęp do klucza, może przekazać dane umożliwiające naruszenie bezpieczeństwa systemu. Także autoryzowani użytkownicy mogą przekazać nieprawidłowe dane, które podczas przetwarzania mogą spowodować wystąpienie błędu lub awarię systemu. Aby zabezpieczyć się przed tym, upewnij się, że wszystkie przekazane dane są przed użyciem weryfikowane i sprawdzane pod kątem złośliwej zawartości.

Przeprowadzaj inspekcje wszystkich operacji. Wiele mechanizmów opartych na kluczach umożliwia rejestrowanie operacji, takich jak przekazywanie i pobieranie, oraz niepowodzenia. Dzienniki zwykle można włączyć do procesu inspekcji, a także używać ich do rozliczeń, jeśli użytkownik jest obciążany opłatą uzależnioną od rozmiaru plików lub ilości danych. Dzienniki umożliwiają wykrywanie błędów uwierzytelniania, których przyczyną mogą być problemy z dostawcą kluczy lub przypadkowe usunięcie przechowywanych zasad dostępu.

Dostarczaj klucz w bezpieczny sposób. Klucz może być osadzony w adresie URL aktywowanym przez użytkownika na stronie internetowej lub może być używany w operacji przekierowania, tak aby pobieranie odbywało się automatycznie. Zawsze używaj protokołu HTTPS, aby dostarczyć klucz za pośrednictwem bezpiecznego kanału.

Chroń poufne dane podczas przesyłania. Dane poufne dostarczane za pośrednictwem aplikacji zwykle będą odbywać się przy użyciu protokołu TLS i powinny być wymuszane dla klientów, którzy uzyskują bezpośredni dostęp do magazynu danych.

Inne problemy, które należy brać pod uwagę podczas implementowania tego wzorca:

• Jeśli klient nie informuje lub nie może informować serwera o zakończeniu operacji, a jedynym ograniczeniem jest okres ważności klucza, aplikacja nie może wykonywać operacji inspekcji, takich jak zliczanie liczby operacji przekazywania lub pobierania bądź zapobieganie wielokrotnemu przekazywaniu lub pobieraniu.

• Elastyczność zasad kluczy, które można wygenerować, może być ograniczona. Na przykład niektóre mechanizmy pozwalają tylko na używanie okresu ważności ograniczonego czasowo. Inne nie pozwalają na określenie wystarczającego stopnia szczegółowości uprawnień do odczytu/zapisu.

• Jeśli określono czas rozpoczęcia okresu ważności klucza lub tokenu, upewnij się, że jest on nieco wcześniejszy niż bieżący czas serwera, aby uwzględnić fakt, że zegary klienta mogą być niezsynchronizowane. Domyślnie, jeśli nie zostanie on określony, jest to zazwyczaj bieżący czas serwera.

• Adres URL zawierający klucz jest rejestrowany w plikach dziennika serwera. Klucz zazwyczaj wygasa, zanim pliki dziennika zostaną użyte do analizy, ale upewnij się, że dostęp do nich jest ograniczony. Jeśli dane dziennika są przesyłane do systemu monitorowania lub przechowywane w innej lokalizacji, rozważ zaimplementowanie opóźnienia, aby zapobiec wyciekom kluczy przed wygaśnięciem ich okresu ważności.

• Jeśli w przeglądarce internetowej jest uruchamiany kod klienta, przeglądarka może wymagać obsługi udostępniania zasobów między źródłami (CORS, Cross-Origin Resource Sharing), aby kod wykonywany w przeglądarce internetowej mógł uzyskiwać dostęp do danych w innej domenie niż ta, która obsłużyła stronę. Niektóre starsze przeglądarki i niektóre magazyny danych nie obsługują mechanizmu CORS, a kod uruchamiany w tych przeglądarkach może nie być w stanie użyć klucza valet w celu zapewnienia dostępu do danych w innej domenie, takiej jak konto magazynu w chmurze.

Kiedy używać tego wzorca

Ten wzorzec jest przydatny w następujących sytuacjach:

• Aby zminimalizować ilość ładowanych zasobów oraz zmaksymalizować wydajność i skalowalność. Korzystanie z klucza portiera nie wymaga blokowania zasobu. Nie jest wymagane wywoływanie serwera zdalnego, nie ma żadnego limitu liczby kluczy portiera, które można wystawić, a także można uniknąć pojedynczego punktu awarii wynikającego z przeprowadzenia transferu danych za pośrednictwem kodu aplikacji. Tworzenie klucza portiera zazwyczaj jest prostą operacją kryptograficzną polegającą na podpisaniu ciągu za pomocą klucza.

• Aby zminimalizować koszty operacyjne. Włączenie bezpośredniego dostępu do magazynów i kolejek nie wymaga dużej ilości zasobów i ponoszenia wysokich kosztów, może powodować mniej rund sieciowych i może pozwalać na zmniejszenie ilości wymaganych zasobów obliczeniowych.

• Gdy klienci regularnie przekazują lub pobierają dane, szczególnie w przypadku, gdy jest ich dużo lub gdy każda operacja obejmuje duże pliki.

• Gdy aplikacja ma ograniczony dostęp do zasobów obliczeniowych, zarówno z powodu ograniczeń hostingu, jak i kwestii związanych z kosztami. W tym scenariuszu wzorzec jest jeszcze bardziej przydatny, jeśli w jednym czasie odbywa się wiele operacji przekazywania lub pobierania, ponieważ zwalnia aplikację z obsługi transferu danych.

• Gdy dane są przechowywane w zdalnym magazynie danych lub w innym centrum danych. Jeśli aplikacja miała pełnić rolę strażnika, może być naliczana opłata za dodatkową przepustowość przesyłania danych między centrami danych bądź w sieciach publicznych lub prywatnych między klientem i aplikacją, a następnie między aplikacją i magazynem danych.

Ten wzorzec może nie być użyteczny w następujących sytuacjach:

• Jeśli aplikacja musi wykonać jakieś zadanie na danych, zanim zostaną one zapisane lub wysłane do klienta. Na przykład jeśli aplikacja musi przeprowadzić weryfikację, zarejestrować udany dostęp lub wykonać transformację danych. Jednak niektóre magazyny danych i klienci mogą negocjować i przeprowadzać proste przekształcenia, takie jak kompresja i dekompresja (na przykład przeglądarka internetowa może zwykle obsługiwać formaty gzip).

• Jeśli projekt istniejącej aplikacji utrudnia zastosowanie wzorca. Korzystanie z tego wzorca na ogół wymaga innego podejścia do architektury dostarczania i architektury odbierania danych.

• Jeśli zachodzi konieczność obsługi dzienników inspekcji lub kontroli liczby wykonanych operacji transferu danych, a używany mechanizm klucza portiera nie obsługuje powiadomień umożliwiających serwerowi zarządzanie tymi operacjami.

• Jeśli zachodzi konieczność ograniczenia rozmiaru danych, szczególnie podczas operacji przekazywania. Jedynym rozwiązaniem tego problemu w przypadku aplikacji jest sprawdzanie rozmiaru danych po zakończeniu operacji lub sprawdzanie rozmiaru przekazywanych plików po upływie określonego czasu lub zgodnie z harmonogramem.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec klucza valet może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

Platforma Azure obsługuje sygnatury dostępu współdzielonego w usłudze Azure Storage w celu szczegółowej kontroli dostępu do danych w obiektach blob, tabelach i kolejkach oraz do kolejek i tematów usługi Service Bus. Token sygnatury dostępu współdzielonego można skonfigurować tak, aby zapewnić określone prawa dostępu, na przykład do odczytu, zapisu, aktualizacji i usuwania określonej tabeli, zakresu kluczy w tabeli, kolejki, obiektu blob lub kontenera obiektów blob. Ważność może być określonym okresem czasu. Ta funkcja jest odpowiednia do używania klucza valet w celu uzyskania dostępu.

Rozważ obciążenie, które ma setki klientów mobilnych lub stacjonarnych często przekazujących duże pliki binarne. Bez tego wzorca obciążenie ma zasadniczo dwie opcje. Pierwszym z nich jest zapewnienie stałego dostępu i konfiguracji do wszystkich klientów w celu przeprowadzenia przekazywania bezpośrednio na konto magazynu. Drugą jest zaimplementowanie wzorca routingu bramy w celu skonfigurowania punktu końcowego, w którym klienci używają dostępu proxied do magazynu, ale może to nie być dodanie dodatkowej wartości do transakcji. Oba podejścia mają problemy rozwiązane w kontekście wzorca:

• Długożytne, wstępnie współużytowane tajemnice. Potencjalnie bez zbyt dużej ilości sposobu, aby udostępnić różne klucze różnym klientom.
• Dodano wydatki związane z uruchamianiem usługi obliczeniowej, która ma wystarczające zasoby, aby poradzić sobie z aktualnie odbieranymi dużymi plikami.
• Potencjalnie spowalniając interakcje klientów przez dodanie dodatkowej warstwy obliczeń i przeskoku sieciowego do procesu przekazywania.

Użycie wzorca klucza valet rozwiązuje problemy związane z zabezpieczeniami, optymalizacją kosztów i wydajnością.

1. Klienci, w ostatnim odpowiedzialnym momencie, uwierzytelniają się w lekkim, skalowalnym do zera interfejsie API hostowanym przez funkcję platformy Azure w celu żądania dostępu.

2. Interfejs API weryfikuje żądanie, a następnie uzyskuje i zwraca ograniczony token SaS czasu i zakresu.

   Token wygenerowany przez interfejs API ogranicza klienta do następujących ograniczeń:

   • Którego konta magazynu użyć. Oznacza to, że klient nie musi znać tych informacji przed upływem czasu.
   • Określony kontener i nazwa pliku do użycia; zapewnienie, że token może być używany z co najwyżej jednym plikiem.
   • Krótkie okno operacji, takie jak trzy minuty. Ten krótki okres gwarantuje, że tokeny mają czas wygaśnięcia, który nie rozszerza przeszłości jego narzędzia.
   • Uprawnienia do tworzenia tylko obiektu blob, a nie pobierania, aktualizowania ani usuwania.

3. Ten token jest następnie używany przez klienta w wąskim przedziale czasu, aby przekazać plik bezpośrednio do konta magazynu.

Interfejs API generuje te tokeny dla autoryzowanych klientów przy użyciu klucza delegowania użytkownika na podstawie własnej tożsamości zarządzanej microsoft Entra ID interfejsu API. Rejestrowanie jest włączone zarówno na kontach magazynu, jak i na interfejsie API generowania tokenu, zezwalają na korelację między żądaniami tokenu a użyciem tokenu. Interfejs API może używać informacji o uwierzytelnianiu klienta lub innych dostępnych danych, aby zdecydować, które konto magazynu lub kontener ma być używane, na przykład w sytuacji wielodostępnej.

Kompletny przykład jest dostępny w witrynie GitHub w przykładzie wzorca klucza valet. Poniższe fragmenty kodu są dostosowane z tego przykładu. W pierwszym z nich pokazano, jak funkcja platformy Azure (znajdująca się w pliku ValetKey.Web) generuje delegowany przez użytkownika token sygnatury dostępu współdzielonego przy użyciu własnej tożsamości zarządzanej funkcji platformy Azure.

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

Poniższy fragment kodu to obiekt transferu danych (DTO) używany zarówno przez interfejs API, jak i klienta.

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

Klient (znaleziony w pliku ValetKey.Client) następnie używa identyfikatora URI i tokenu zwróconego z interfejsu API do wykonania przekazywania bez konieczności stosowania dodatkowych zasobów i pełnej wydajności klienta do magazynu.

...

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

...

Następne kroki

Następujące wskazówki mogą być istotne podczas implementowania tego wzorca:

• Implementacja przykładu jest dostępna w usłudze GitHub w przykładzie wzorca klucza valet.
• Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage za pomocą sygnatur dostępu współdzielonego (SAS)
• Uwierzytelnianie za pomocą sygnatury dostępu współdzielonego w usłudze Service Bus

Powiązane zasoby

Podczas implementowania tego wzorca mogą być również istotne następujące wzorce:

• Wzorzec strażnika. Ten wzorzec może być używany w połączeniu ze wzorcem klucza portiera do ochrony aplikacji i usług przy użyciu dedykowanego wystąpienia hosta, które działa jako broker między klientami a aplikacją lub usługą. Strażnik weryfikuje i oczyszcza żądania oraz przekazuje żądania i dane między klientem i aplikacją. Może zapewnić dodatkową warstwę zabezpieczeń i ograniczyć obszar ataków na system.
• Wzorzec hostingu zawartości statycznej. Opisuje sposób wdrażania zasobów statycznych w usłudze magazynu opartego na chmurze, która może dostarczać te zasoby bezpośrednio do klienta, ograniczając potrzebę korzystania z kosztownych wystąpień obliczeniowych. W przypadku, gdy zasoby nie mają być ogólnie dostępne, można je zabezpieczyć za pomocą wzorca klucza portiera.