Praktyki bezpieczeństwa w wielodostępnych środowiskach SaaS AWS

Zabezpieczanie aplikacji typu oprogramowanie jako usługa (SaaS) jest najwyższym priorytetem dla wszystkich architektów i programistów aplikacji. Postępowanie w ten sposób w środowisku współdzielonym przez wielu najemców może okazać się jeszcze większym wyzwaniem. Zrozumienie struktur i koncepcji tożsamości może być czasochłonne, a utworzenie izolacji dzierżawcy w tych środowiskach wymaga głębokiego zrozumienia różnych narzędzi i usług.

Chociaż bezpieczeństwo jest podstawowym elementem każdej aplikacji, szczególne uwagi dotyczą właśnie aplikacji SaaS. Poniższy artykuł omawia wyzwania, możliwości i najlepsze praktyki w zakresie zabezpieczania wielodostępnych środowisk SaaS w Amazon Web Services (AWS).

Uwagi dotyczące bezpieczeństwa aplikacji SaaS

Aplikacje z jedną dzierżawą są często wdrażane dla konkretnego klienta i zazwyczaj dotyczą tylko tej pojedynczej jednostki. Chociaż bezpieczeństwo jest ważne w tych środowiskach, profil zagrożenia nie obejmuje potencjalnego dostępu innych klientów. Aplikacje SaaS dla wielu dzierżawców mają unikatowe względy bezpieczeństwa w porównaniu z aplikacjami z jedną dzierżawą.

Wielodostępne aplikacje SaaS w szczególności muszą zwracać uwagę na izolację tożsamości i dzierżawy. Te okoliczności są dodatkiem do środków bezpieczeństwa, które muszą podjąć wszystkie aplikacje. W tym artykule omówiono koncepcje związane z izolacją tożsamości i dzierżawy oraz sposób, w jaki AWS może pomóc dostawcom SaaS w tworzeniu bezpiecznych aplikacji.

Tożsamość

Dostęp do aplikacji SaaS mają poszczególni zleceniodawcy (często określani jako użytkownicy). Podmioty te mogą być interaktywne (na przykład za pośrednictwem aplikacji internetowej) lub oparte na maszynach (na przykład za pośrednictwem interfejsu API). Każdy podmiot jest unikalnie identyfikowany i zwykle jest powiązany z informacjami o zleceniodawcy, w tym adresem e-mail, nazwiskiem, rolą i innymi metadanymi.

Oprócz unikalnej identyfikacji każdego podmiotu, aplikacja SaaS posiada inną konstrukcję: dzierżawę. Dokument dotyczący wielu najemców definiuje najemcę jako grupę jednego lub więcej użytkowników dzielących ten sam pogląd na aplikację, z której korzystają. Ten widok może się różnić dla różnych najemców. Każdy zleceniodawca jest powiązany z najemcą, nawet jeśli jest to tylko mapowanie 1:1. Najemca jest jednoznacznie identyfikowany i posiada informacje o administratorze najemcy, informacje rozliczeniowe i inne metadane.

Gdy podmiot wysyła żądanie do aplikacji SaaS, podmiot zabezpieczeń dostarcza wraz z żądaniem identyfikator dzierżawy i użytkownika. Aplikacja SaaS weryfikuje te informacje i podejmuje decyzję o autoryzacji. We właściwie zaprojektowanych aplikacjach SaaS ten etap autoryzacji nie powinien opierać się na scentralizowanej usłudze autoryzacji. Scentralizowana usługa autoryzacji to pojedynczy punkt awarii w aplikacji. Jeśli się nie powiedzie lub zostanie przeciążony żądaniami, aplikacja nie będzie już mogła przetwarzać żądań.

Istnieją dwie kluczowe techniki zapewniania tego typu doświadczenia w aplikacji SaaS: korzystanie z dostawcy tożsamości (IdP) i reprezentowanie tożsamości lub autoryzacji w tokenie.

Korzystanie z dostawcy tożsamości (IdP)

W przeszłości niektóre aplikacje internetowe często przechowywały informacje o użytkownikach w tabeli pokrewnej bazy danych. Po pomyślnym uwierzytelnieniu podmiotu zabezpieczeń aplikacja wystawiała identyfikator sesji. W przypadku kolejnych żądań zleceniodawca przekazywał do aplikacji identyfikator sesji. Aplikacja podejmowała decyzje autoryzacyjne właśnie na podstawie tego identyfikatora sesji. Rysunek nr 1 przedstawia przykład działania tej konfiguracji.

W aplikacjach większych niż prosta aplikacja internetowa ten wzorzec jest nieoptymalny. Każde żądanie zwykle generuje co najmniej jedno zapytanie do bazy danych lub wyszukiwanie w pamięci podręcznej, tworząc tzw. „wąskie gardło” w magazynie danych przechowującym informacje o użytkowniku lub sesji. Ponadto ze względu na ścisłe powiązanie aplikacji i zarządzania użytkownikami federacja z zewnętrznymi dostawcami tożsamości staje się trudna.

Projektując swoją aplikację SaaS, powinieneś rozważyć użycie dostawcy tożsamości, takiego jak Amazon Cognito, Auth0 lub Okta. Korzystanie z dostawcy tożsamości odciąża ciężką pracę wymaganą do zarządzania tożsamością dzięki uwierzytelnianiu użytkowników, w tym federacji, obsługiwanej przez zewnętrznych dostawców tożsamości. Rysunek nr 2 przedstawia przykład, w jaki sposób dostawca SaaS może używać dostawcy tożsamości zamiast rozwiązania samozarządzającego pokazanego na rysunku nr 1.

Gdy użytkownik uwierzytelni się u dostawcy tożsamości, dostawca tożsamości wystawia standaryzowany token. Ten token jest taki sam, niezależnie od sposobu uwierzytelniania użytkownika, co oznacza, że aplikacja nie musi wbudować obsługi wielu różnych metod uwierzytelniania, których mogą używać dzierżawcy.

Dostawcy tożsamości również często obsługują dostęp federacyjny. Dostęp federacyjny oznacza, że osoba trzecia utrzymuje tożsamości, ale dostawca tożsamości posiada relację zaufania z tą osobą trzecią. Gdy klient próbuje zalogować się przy użyciu tożsamości zarządzanej przez stronę trzecią, dostawca tożsamości aplikacji SaaS obsługuje transakcję uwierzytelniania z zewnętrznym dostawcą tożsamości.

Ta transakcja uwierzytelniania często wykorzystuje protokół taki jak Security Assertion Markup Language (SAML) 2.0. Dostawca tożsamości aplikacji SaaS zarządza interakcją z dostawcą tożsamości dzierżawcy. Dostawca tożsamości aplikacji SaaS wydaje token w formacie zrozumiałym dla aplikacji SaaS. Rysunek 3 przedstawia przykład, w jaki sposób aplikacja SaaS może zapewnić obsługę federacji przy użyciu dostawcy tożsamości.

Jako przykład, zobacz: Jak skonfigurować Amazon Cognito do uwierzytelniania federacyjnego przy użyciu usługi Azure AD.

Reprezentowanie tożsamości za pomocą tokenów

Tożsamość jest zwykle reprezentowana przez podpisane tokeny. JSON Web Signatures (JWS), często określane jako JSON Web Tokens (JWT), to podpisane obiekty JSON używane w aplikacjach internetowych do wykazania, że nośnik jest upoważniony do dostępu do określonego zasobu. Te obiekty JSON są podpisane przez dostawcę tożsamości i można je zweryfikować bez wysyłania zapytań do scentralizowanej bazy danych lub usługi.

Token zawiera kilka par typu klucz-wartość, zwanych oświadczeniami, które są wystawiane przez dostawcę tożsamości. Oprócz kilku roszczeń związanych z wydaniem i wygaśnięciem tokena, może on również zawierać informacje o indywidualnym zleceniodawcy i najemcy.

Przykładowe żądania tokena dostępu

Poniższy przykład przedstawia sekcję oświadczeń typowego tokena dostępu wystawionego przez Amazon Cognito w formacie JWT.

{

"sub": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",

"cognito:groups": [

"TENANT-1"

],

"token_use": "access",

"auth_time": 1562190524,

"iss": "https://cognito-idp.us-west-2.amazonaws.com/us-west-2_example",

"exp": 1562194124,

"iat": 1562190524,

"origin_jti": "bbbbbbbbb-cccc-dddd-eeee-aaaaaaaaaaaa",

"jti": "cccccccc-dddd-eeee-aaaa-bbbbbbbbbbbb",

"client_id": "12345abcde"

}

Podmiot główny i dzierżawca, z którym jest skojarzony podmiot zabezpieczeń, są reprezentowane w tym tokenie przez kombinację identyfikatora użytkownika (oświadczenie podrzędne) i identyfikatora dzierżawcy w oświadczeniu cognito:groups. W tym przykładzie aplikacja SaaS reprezentuje dzierżawcę, tworząc grupę Cognito na dzierżawcę. Inni dostawcy tożsamości mogą umożliwiać Ci dodanie niestandardowego atrybutu do użytkownika, który jest odzwierciedlony w tokenie dostępu.

Gdy aplikacja SaaS otrzyma token JWT w ramach żądania, aplikacja weryfikuje token i rozpakowuje jego zawartość w celu podjęcia decyzji o autoryzacji. Żądania w obrębie tokenów ustanawiają to, co znane jest pod pojęciem kontekstu tokena. Podobnie jak sposób, w jaki zmienne środowiskowe mogą wpływać na aplikację wiersza polecenia, kontekst dzierżawy wpływa na sposób przetwarzania żądania przez aplikację SaaS.

Korzystając z tokena JWT, aplikacja SaaS może przetwarzać żądanie bez częstego odwoływania się do zewnętrznego dostawcy tożsamości lub innej scentralizowanej usługi.

Izolacja dzierżawców

Izolacja dzierżawy stanowi podstawę każdej aplikacji SaaS. Poszczególna aplikacja SaaS musi zapewniać, że jedna dzierżawa nie może uzyskać dostępu do zasobów innej dzierżawy. Aplikacja SaaS musi tworzyć granice, które odpowiednio izolują jednego dzierżawcę od drugiego.

Ustalenie, co stanowi wystarczającą izolację, zależy od domeny, modelu wdrażania i wszelkich obowiązujących struktur zgodności. Techniki izolowania dzierżawców od siebie zależą od modelu izolacji i używanych aplikacji. Ta sekcja zawiera omówienie strategii izolacji dzierżawców.

Twój model wdrażania wpływa na izolację

To, jak wdrażana jest aplikacja, wpływa na sposób izolacji dzierżawców. Aplikacje SaaS mogą korzystać z trzech rodzajów izolacji: silosu, puli i mostu.

Model wdrożenia silo

Model wdrażania w silosie obejmuje klientów wdrażających jeden zestaw infrastruktury na dzierżawcę. W zależności od aplikacji może to oznaczać VPC na dzierżawcę, zestaw kontenerów na dzierżawcę lub inny zasób wdrożony dla każdej dzierżawy. W tym modelu istnieje jedno wdrożenie na dzierżawcę, chociaż może istnieć pewna współużytkowana infrastruktura do administrowania między dzierżawcami. Rysunek nr 4 przedstawia przykład wdrożenia silosowego, które korzysta z modelu VPC na dzierżawcę.

Model wdrożenia pool

Model wdrażania puli obejmuje udostępniony zestaw infrastruktury dla wszystkich dzierżawców. Izolacja dzierżawy jest implementowana logicznie w aplikacji za pomocą konstrukcji na poziomie aplikacji. Zamiast posiadania oddzielnych zasobów na dzierżawcę, wymuszanie izolacji odbywa się w aplikacji. Rysunek nr 5 przedstawia przykład modelu wdrażania w puli, który wykorzystuje technologie bezserwerowe.

Na rysunku nr 5 funkcja AWS Lambda, która pobiera element z tabeli Amazon DynamoDB współdzielonej przez wszystkich dzierżawców, wymaga tymczasowych poświadczeń wystawionych przez usługę AWS Security Token Service. Te poświadczenia umożliwiają tylko żądającemu dostęp do elementów w tabeli, które należą do dzierżawcy zgłaszającego żądanie. Żądający uzyskuje te poświadczenia, przyjmując rolę AWS Identity and Access Management (IAM). Dzięki temu aplikacja SaaS może współdzielić podstawową infrastrukturę, jednocześnie izolując od siebie dzierżawców. Zobacz „Wymuszanie izolacji zależy od usługi” poniżej, aby uzyskać więcej informacji na temat tego wzorca.

Model wdrożenia bridge

Model pomostowy łączy elementy zarówno modelu silosu, jak i puli. Niektóre zasoby mogą być oddzielne, inne mogą być udostępniane. Załóżmy na przykład, że aplikacja ma udostępnioną warstwę aplikacji i wystąpienie usługi Amazon Relational Database Service (RDS) na dzierżawę. Warstwa aplikacji ocenia każde żądanie i łączy się z bazą danych dla dzierżawcy, który wysłał żądanie.

Model ten jest przydatny w sytuacji, gdy każdy najemca może wymagać określonego czasu odpowiedzi, a jeden zestaw zasobów stanowi wąskie gardło. W przykładzie RDS warstwa aplikacji mogła obsłużyć żądania narzucone przez dzierżawców, ale pojedyncza instancja RDS nie byłaby w stanie.

Decyzja o tym, który model izolacji wdrożyć, zależy od wymagań klienta, potrzeb w zakresie zgodności lub potrzeb samej branży. Może się okazać, że niektórych klientów można wdrożyć w modelu puli, podczas gdy więksi klienci mogą wymagać własnego wdrożenia w silosie.

Twoja strategia warstwowania może również wpływać na typ używanego modelu izolacji. Na przykład klient warstwy podstawowej może zostać wdrożony w infrastrukturze w puli, a klient warstwy korporacyjnej jest wdrożony w infrastrukturze silosowej.

Aby uzyskać więcej informacji na temat różnych modeli izolacji dzierżawców, przeczytaj oficjalny dokument dotyczący strategii izolacji dzierżawców.

Egzekwowanie izolacji zależy od usługi

Większość aplikacji SaaS będzie potrzebować miejsca do przechowywania informacji o stanie. Może to być relacyjna baza danych, baza danych NoSQL lub inny nośnik pamięci, który utrzymuje stan. Aplikacje SaaS zbudowane na AWS wykorzystują różne mechanizmy wymuszające izolację dzierżawców podczas uzyskiwania dostępu do trwałego nośnika pamięci.

IAM zapewnia dostęp do szczegółowej kontroli dostępu do interfejsu API AWS. Niektóre usługi, takie jak Amazon Simple Storage Service (Amazon S3) i DynamoDB, zapewniają możliwość kontrolowania dostępu do poszczególnych obiektów lub elementów za pomocą zasad IAM. Jeśli to możliwe, aplikacja powinna korzystać z wbudowanych funkcji IAM, aby ograniczyć dostęp do zasobów dzierżawy. Zobacz „Izolowanie dzierżawców SaaS za pomocą dynamicznie generowanych zasad uprawnień”, aby uzyskać więcej informacji na temat używania uprawnień do wdrażania izolacji dzierżawców.

AWS IAM oferuje również możliwość ograniczania dostępu do zasobów na podstawie tagów. Jest to znane jako kontrola dostępu oparta na atrybutach (ABAC). Ta technika umożliwia stosowanie tagów do obsługiwanych zasobów i podejmowanie decyzji dotyczących kontroli dostępu na podstawie zastosowanych tagów. Jest to bardziej skalowalny mechanizm kontroli dostępu niż kontrola dostępu oparta na rolach (RBAC), ponieważ nie trzeba modyfikować zasad uprawnień za każdym razem, gdy zasób jest dodawany lub usuwany. Zobacz, „Jak zaimplementować izolację dzierżawy SaaS za pomocą ABAC i AWS IAM”, aby uzyskać więcej informacji o tym, w jaki sposób można to zastosować do aplikacji SaaS.

Niektóre relacyjne bazy danych oferują funkcje, które mogą wymuszać izolację dzierżawców. Na przykład PostgreSQL oferuje funkcję zwaną bezpieczeństwem na poziomie wiersza (RLS). W zależności od kontekstu, w którym zapytanie jest wysyłane do bazy danych, w wynikach zwracane są tylko elementy specyficzne dla dzierżawy. Zobacz „Izolacja danych wielu dzierżawców za pomocą PostgreSQL Row Level Security”, aby uzyskać więcej informacji na temat zabezpieczeń na poziomie wiersza w PostgreSQL.

Inne trwałe nośniki pamięci nie mają modeli uprawnień dla drobnoziarnistych modeli. Mogą jednak oferować pewien rodzaj kontenera na najemcę. Na przykład w przypadku korzystania z MongoDB każdemu dzierżawcy jest przypisywany użytkownik MongoDB i baza danych MongoDB. Sekret powiązany z użytkownikiem może być przechowywany w AWS Secrets Manager. Podczas pobierania danych dzierżawy aplikacja SaaS najpierw pobiera tajny klucz, a następnie uwierzytelnia się za pomocą MongoDB. Powoduje to izolację dzierżawy, ponieważ skojarzone poświadczenia mają tylko uprawnienia dostępu do kolekcji w bazie danych specyficznej dla dzierżawy.

W ogólnym ujęciu, jeśli trwały nośnik pamięci, którego używasz, oferuje własny model uprawnień, który może wymusić izolację dzierżawców, należy go używać, ponieważ uniemożliwia to implementację izolacji w aplikacji. Mogą jednak wystąpić przypadki, w których Twój magazyn danych nie zapewnia takiego poziomu izolacji. W takiej sytuacji konieczne byłoby napisanie wymuszania izolacji dzierżawy na poziomie aplikacji. Izolacja dzierżawy na poziomie aplikacji oznacza, że aplikacja SaaS, a nie trwały nośnik pamięci zapewnia, że jedna dzierżawa nie może uzyskać dostępu do danych innej dzierżawy.

Wnioski

W tym artykule omówiono wyzwania, możliwości i najlepsze rozwiązania dla unikatowych zagadnień dotyczących zabezpieczeń związanych z wielodostępną aplikacją SaaS oraz opisano konkretne zagadnienia dotyczące tożsamości, a także metody izolacji dzierżawców.

Jeśli chcesz dowiedzieć się więcej o powyższych tematach, filar AWS Well-Architected SaaS Lens Security zajmuje się zarządzaniem wydajnością w środowiskach SaaS. Zawiera również najlepsze praktyki i zasoby ułatwiające projektowanie i zwiększanie wydajności aplikacji SaaS.

Zacznij korzystać z AWS Well-Architected SaaS Lens

AWS Well-Architected SaaS Lens koncentruje się na obciążeniach SaaS i ma na celu kierowanie krytycznego myślenia przy opracowywaniu i obsłudze obciążeń SaaS. Każde pytanie zawiera listę najlepszych praktyk, a każda najlepsza praktyka zawiera listę planów doskonalenia, które pomogą Ci je wdrożyć.

SaaS Lens może zostać zastosowany do istniejących obciążeń lub użyta do nowych obciążeń zdefiniowanych w narzędziu. Możesz go użyć, aby ulepszyć aplikację, nad którą pracujesz lub uzyskać wgląd w wiele obciążeń używanych przez dział lub obszar, z którym pracujesz.

SaaS Lens jest dostępny we wszystkich Regionach, w których oferowane jest narzędzie AWS o dobrej architekturze, zgodnie z opisem na Liście usług regionalnych AWS. Korzystanie z dobrze zaprojektowanego narzędzia AWS nie wiąże się z żadnymi kosztami.

Jeśli jesteś klientem AWS, znajdź aktualnych Partnerów AWS, którzy mogą przeprowadzić przegląd, poznając AWS Well-Architected Partners i AWS SaaS Competency Partners.

Jeśli posiadasz uwagi dotyczące tego artykułu, pozostaw komentarz w sekcji Komentarze poniżej. Jeśli masz pytania dotyczące tego artykułu, rozpocznij nowy wątek na forum Centrum bezpieczeństwa. Aby rozpocząć 30-dniowy bezpłatny okres próbny Centrum zabezpieczeń, odwiedź Centrum zabezpieczeń AWS.

źródło: AWS

źródło: AWSźródło: AWS