Wzorce kontroli dostępu do aplikacji internetowych przy wykorzystaniu usług AWS

Wzorzec aplikacji internetowej klient-serwer jest powszechnie stosowany. Kontrola dostępu umożliwia tylko autoryzowanym klientom dostęp do zasobów serwera zaplecza poprzez uwierzytelnianie klienta i zapewnianie dostępu na poziomie szczegółowym w zależności od tego, kim jest klient.

Ten artykuł koncentruje się na trzech wzorcach architektury rozwiązań, które uniemożliwiają nieautoryzowanym klientom uzyskanie dostępu do serwerów zaplecza aplikacji internetowych. W tych wzorcach architektury stosowanych jest wiele usług AWS, które spełniają wymagania różnych przypadków użycia.

Przepływ kodu uwierzytelniającego OAuth 2.0

Rysunek nr 1 przedstawia podstawy wszystkich wzorców architektonicznych omówionych w tym artykule. Tekst Understanding Amazon Cognito user pool OAuth 2.0 grants opisuje szczegóły różnych dotacji OAuth 2.0, które mogą w pewnym stopniu różnić się przepływem.

Wzorce architektury opisane w tym artykule wykorzystują Amazon Cognito jako serwer autoryzacji, a instancje Amazon Elastic Compute Cloud jako serwer zasobów. Klientem może być dowolna aplikacja front-end, taka jak aplikacja mobilna, która wysyła do serwera zasobów żądanie dostępu do chronionych zasobów.

Wzorzec 1

Rysunek nr 2 to wzorzec architektury, który odciąża pracę uwierzytelniania klientów do modułu równoważenia obciążenia aplikacji (ALB).

ALB może być używany do uwierzytelniania klientów za pośrednictwem puli użytkowników Amazon Cognito:

1. Klient wysyła żądanie HTTP do punktu końcowego ALB bez plików cookie sesji uwierzytelniania.
2. ALB przekierowuje żądanie do punktu końcowego uwierzytelniania Amazon Cognito. Klient jest uwierzytelniany przez Amazon Cognito.
3. Klient jest kierowany z powrotem do ALB z kodem uwierzytelniającym.
4. ALB używa kodu uwierzytelniającego do uzyskania tokena dostępu z punktu końcowego tokena Amazon Cognito, a także wykorzystuje token dostępu do pobierania oświadczeń użytkownika klienta z punktu końcowego Amazon Cognito UserInfo.
5. ALB przygotowuje sesyjne cookies zawierające zaszyfrowane dane i przekierowuje żądanie klienta za pomocą sesyjnego cookies. Klient używa pliku cookie sesji dla wszystkich dalszych żądań. ALB weryfikuje plik cookie sesji i decyduje, czy żądanie może zostać przekazane do jego celów.
6. Potwierdzone żądanie jest przekazywane do instancji backendowych z ALB dodając nagłówki HTTP, które zawierają dane z tokena dostępu i informacje o oświadczeniach użytkownika.
7. Serwer zaplecza może używać informacji w nagłówkach dodanych ALB do szczegółowej kontroli uprawnień.         

Kluczowym wnioskiem z tego wzorca jest to, że ALB utrzymuje cały kontekst uwierzytelniania, uruchamiając uwierzytelnianie klienta za pomocą Amazon Cognito i przygotowuje plik cookie sesji uwierzytelniania dla klienta. Adres URL wywołania zwrotnego logowania Amazon Cognito wskazuje na ALB, który umożliwia ALB dostęp do kodu uwierzytelniającego.

Więcej szczegółów na temat tego wzorca można znaleźć w dokumentacji Authenticate users using an Application Load Balancer.

Wzorzec 2

Wzorzec przedstawiony na rysunku nr 3 odciąża pracę związaną z uwierzytelnianiem klientów na Amazon API Gateway.

API Gateway może obsługiwać interfejs API REST i HTTP. API Gateway jest zintegrowany z Amazon Cognito, ale może również kontrolować dostęp do API HTTP za pomocą autoryzatora JSON Web Token (JWT), który współdziała z Amazon Cognito. ALB można zintegrować z API Gateway. Klient jest odpowiedzialny za uwierzytelnienie w Amazon Cognito w celu uzyskania tokena dostępu.

1. Klient rozpoczyna uwierzytelnianie w Amazon Cognito w celu uzyskania tokena dostępu.
2. Klient wysyła żądanie REST API lub HTTP API z nagłówkiem zawierającym token dostępu.
3. API Gateway jest skonfigurowany tak, aby posiadał:

• Pulę użytkowników Amazon Cognito jako osobę autoryzującą do zatwierdzenia tokena dostępu w żądaniu REST API lub
• Autoryzator JWT, który współdziała z pulą użytkowników Amazon Cognito w celu weryfikacji tokena dostępu w żądaniu HTTP API.

4. Po walidacji tokena dostępowego, żądanie REST lub HTTP API jest przekazywane do ALB i:

• Brama API może kierować API HTTP do prywatnego ALB za pośrednictwem punktu końcowego VPC.o
• Jeśli używany jest publiczny ALB, API Gateway może kierować zarówno REST API, jak i HTTP API do ALB.

5. API Gateway nie może bezpośrednio kierować REST API do prywatnego ALB. Może kierować do prywatnego systemu równoważenia obciążenia sieciowego (NLB) za pośrednictwem punktu końcowego VPC. Prywatny ALB można skonfigurować jako cel równoważenia obciążenia sieciowego.

Kluczowe wnioski tego wzoru to:

• API Gateway posiada wbudowane funkcje integrujące pulę użytkowników Amazon Cognito w celu autoryzacji żądań REST i/lub HTTP API.
• ALB można skonfigurować tak, aby akceptował tylko żądania HTTP API z punktu końcowego VPC ustawionego przez API Gateway.

Wzorzec 3

Amazon CloudFront jest w stanie uruchomić funkcje AWS Lambda wdrożone w lokalizacjach brzegowych AWS. Ten wzorzec (Rysunek nr 4) wykorzystuje funkcję Lambda@Edge, w której może działać jako autoryzator do walidacji żądań klientów, które używają tokena dostępu, który jest zwykle zawarty w nagłówku HTTP Authorization.

Klient może mieć indywidualny przepływ uwierzytelniania z Amazon Cognito, aby uzyskać token dostępu przed wysłaniem żądania HTTP.

1. Klient rozpoczyna uwierzytelnianie w Amazon Cognito w celu uzyskania tokena dostępu.
2. Klient wysyła żądanie HTTP z nagłówkiem Authorization, który zawiera token dostępu, na adres URL dystrybucji CloudFront.
3. Zdarzenie żądania przeglądarki CloudFront powoduje uruchomienie funkcji pod adresem Lambda@Edge.
4. Funkcja Lambda wyodrębnia token dostępu z nagłówka Authorization i weryfikuje token dostępu za pomocą Amazon Cognito. Jeśli token dostępu jest nieprawidłowy, żądanie jest odrzucane.
5. Jeżeli token dostępowy jest zatwierdzany, żądanie jest autoryzowane i przekazywane przez CloudFront do ALB. CloudFront jest skonfigurowany tak, aby dodać niestandardowy nagłówek z wartością, którą można udostępniać tylko ALB.
6. ALB ustawia regułę listener, aby sprawdzić, czy przychodzące żądanie ma niestandardowy nagłówek ze współdzieloną wartością. Dzięki temu ALB dostępny w Internecie akceptuje tylko żądania, które są przekazywane przez CloudFront.
7. Aby zwiększyć bezpieczeństwo, wspólna wartość niestandardowego nagłówka może być przechowywana w AWS Secrets Manager. Ten może wyzwolić powiązaną funkcję Lambda, aby okresowo obracać wartość sekretu.
8. Funkcja Lambda aktualizuje również CloudFront dla dodanego niestandardowego nagłówka i ALB dla wspólnej wartości w regule listener.

Kluczowe wnioski wynikające z tego wzorca to:

• Domyślnie CloudFront usunie nagłówek autoryzacji przed przekazaniem żądania HTTP do jego źródła. CloudFront musi być skonfigurowany do przekazywania nagłówka Authorization do źródła ALB. Serwer zaplecza używa tokena dostępu, aby zastosować szczegółowe poziomy uprawnień dostępu do zasobów.
• Użycie Lambda@Edge wymaga, aby funkcja znajdowała się w regionie us-wschód-1.
• Wartość niestandardowego nagłówka dodanego do CloudFront jest utrzymywana jako tajemnica, którą można udostępniać tylko ALB.

Wnioski

Wzorce architektoniczne omówione w powyższym artykule to oparte na tokenach metody kontroli dostępu do sieci Web, które są w pełni obsługiwane przez usługi AWS. Podejście to odciąża przepływ uwierzytelniania OAuth 2.0 z serwera zaplecza do usług AWS. Usługi zarządzane przez AWS mogą zapewnić odporność, skalowalność i zautomatyzowaną obsługę w celu stosowania kontroli dostępu do aplikacji internetowej.

Źródło: AWS