Uprość sposób zarządzania autoryzacją w swoich aplikacjach dzięki zweryfikowanym uprawnieniom Amazon – teraz ogólnodostępnym

Podczas tworzenia nowej aplikacji lub integrowania istniejącej z nowym środowiskiem prawidłowe wdrożenie uwierzytelniania i autoryzacji użytkownika wymaga znacznych nakładów pracy. W przeszłości zbudowałbyś własny system uwierzytelniania, ale dziś możesz skorzystać z zewnętrznego dostawcy tożsamości, takiego jak Amazon Cognito. Jednak logika autoryzacji jest zwykle implementowana w kodzie.

Może się to rozpocząć od przydzielenia wszystkim użytkownikom roli dla ich funkcji. Jednak z biegiem czasu uprawnienia te stają się coraz bardziej złożone. Liczba ról rośnie, ponieważ uprawnienia stają się również bardziej szczegółowe. Nowe przypadki użycia powodują potrzebę niestandardowych uprawnień. Na przykład jeden użytkownik może udostępniać dokument innemu użytkownikowi w innej roli lub agent pomocy technicznej może wymagać tymczasowego dostępu do konta klienta w celu rozwiązania problemu. Zarządzanie uprawnieniami w kodzie jest podatne na błędy i stanowi poważne wyzwanie podczas audytu uprawnień i decydowania, kto ma do czego dostęp, zwłaszcza gdy te uprawnienia są wyrażane w różnych aplikacjach i przy użyciu wielu języków programowania.

Na re:Invent 2022 twórcy wprowadzili w wersji zapoznawczej Amazon Verified Permissions, szczegółową usługę zarządzania uprawnieniami i autoryzacji dla Twoich aplikacji, z której można korzystać na dowolną skalę. Amazon Verified Permissions centralizuje uprawnienia w magazynie zasad i pomaga programistom używać tych uprawnień do autoryzowania działań użytkownika w ich aplikacjach. Podobnie jak dostawca tożsamości upraszcza uwierzytelnianie, magazyn zasad umożliwia zarządzanie autoryzacją w spójny i skalowalny sposób.

Aby zdefiniować szczegółowe uprawnienia, Amazon Verified Permissions wykorzystuje Cedar, język polityki open source i zestaw programistyczny (SDK) do kontroli dostępu. Możesz zdefiniować schemat dla swojego modelu autoryzacji pod względem typów głównych, typów zasobów i prawidłowych akcji. W ten sposób, gdy tworzona jest polityka, jest ona weryfikowana pod kątem Twojego modelu autoryzacji. Możesz uprościć tworzenie podobnych zasad za pomocą szablonów. Zmiany w magazynie zasad są kontrolowane, dzięki czemu można zobaczyć, kto wprowadził zmiany i kiedy.

Następnie możesz połączyć swoje aplikacje z Amazon Verified Permissions za pośrednictwem AWS SDK, aby autoryzować żądania dostępu. Dla każdego żądania autoryzacji odpowiednie zasady są pobierane i oceniane w celu określenia czy działanie jest dozwolone, czy nie. Możesz odtworzyć te żądania autoryzacji, aby potwierdzić, że uprawnienia działają zgodnie z przeznaczeniem.

Z dniem dzisiejszym autorzy z przyjemnością informują, że usługa Amazon Verified Permissions jest ogólnie dostępna z nowymi możliwościami i uproszczonym interfejsem użytkownika w konsoli zarządzania AWS.

Zobaczmy, w jaki sposób możesz to wykorzystać w praktyce.

Tworzenie Magazynu Zasad ze zweryfikowanymi uprawnieniami Amazon

W konsoli Amazon Verified Permissions wybierz Create policy store. Magazyn zasad to kontener logiczny, w którym przechowywane są zasady i schematy. Decyzje dotyczące autoryzacji są więc podejmowane na podstawie wszystkich polityk obecnych w magazynie zasad.

Aby skonfigurować nowy magazyn zasad, możesz użyć różnych metod. Na przykład możesz zacząć od konfiguracji sterowanej, przykładowego magazynu zasad (na przykład aplikacji do udostępniania zdjęć, sklepu internetowego lub menedżera zadań) lub pustego magazynu zasad (zalecane dla zaawansowanych użytkowników). Wybierz opcję Guided setup, wprowadź przestrzeń nazw dla swojego schematu (MyApp) i wybierz Dalej.

Zasoby to obiekty, na których podmioty zabezpieczeń mogą działać. W swojej aplikacji masz użytkowników (zleceniodawców), którzy mogą tworzyć, czytać, aktualizować i usuwać dokumenty (zasoby). Zacznij od definiowania typu zasobu Dokumenty.

Wprowadź nazwę typu zasobu i dodaj dwa wymagane atrybuty:

• właściciel (String), aby określić, kto jest właścicielem dokumentu.
• isPublic (Boolean) do oznaczania dokumentów publicznych, które każdy może przeczytać.

Określ cztery akcje dla typu zasobu Document:

• DocumentCreate
• DocumentRead
• DocumentUpdate
• DocumentDelete

Wprowadź Użytkownika jako nazwę typu głównego, który będzie używał tych działań na Dokumentach. Następnie wybierz Next.

Teraz skonfigurujesz typ użytkownika głównego. Możesz użyć niestandardowej konfiguracji do zintegrowania zewnętrznego źródła tożsamości, ale w tym przypadku skorzystaj z puli użytkowników Amazon Cognito, którą utworzyłeś wcześniej. Wybierz Connect user pool.

W oknie dialogowym wybierz region AWS, w którym znajduje się pula użytkowników, wprowadź identyfikator puli użytkowników i wybierz Connect.

Teraz, gdy pula użytkowników Amazon Cognito jest podłączona, możesz dodać kolejny poziom ochrony, sprawdzając poprawność identyfikatorów aplikacji klienckich. Na razie nie korzystaj z tej opcji.

W sekcji Principal attributes wybierz atrybuty, których zamierzasz użyć do kontroli dostępu opartej na atrybutach w swoich zasadach. Wybierz sub (temat), używany do identyfikacji użytkownika końcowego zgodnie ze specyfikacją OpenID Connect. Możesz wybrać więcej atrybutów. Na przykład użyć email_verified w zasadach, aby nadać uprawnienia tylko użytkownikom Amazon Cognito, których adres e-mail został zweryfikowany.

W ramach tworzenia magazynu zasad utwórz pierwszą politykę, która daje użytkownikowi danilop dostęp do odczytu dokumentu doc.txt.

W poniższym kodzie konsola umożliwia Ci podgląd wynikowej polityki przy użyciu języka Cedar.

permit(
  principal == MyApp::User::"danilop",
  action in [MyApp::Action::"DocumentRead"],
  resource == MyApp::Document::"doc.txt"
) when {
  true
};

Na koniec wybierz opcję Create policy store.

Dodawanie uprawnień do magazynu zasad

Po utworzeniu magazynu zasad wybierz Policies w okienku nawigacji. Z listy rozwijanej Create policy wybierz Create static policy. Polityka statyczna zawiera wszystkie informacje potrzebne do jej oceny. W swojej drugiej polityce zezwól każdemu użytkownikowi na czytanie dokumentów publicznych. Domyślnie wszystko jest zabronione, więc w Policy Effect wybierz Permit.

W Policy scope pozostawi zaznaczone All principals i All resources i wybierz akcję DocumentRead. W sekcji Policy zmień klauzulę when condition, aby ograniczyć uprawnienia do zasobów, gdzie isPublic jest równe true:

permit (
  principal,
  action in [MyApp::Action::"DocumentRead"],
  resource
)
when { resource.isPublic };

Wprowadź opis polityki i wybierz Create policy.

W przypadku swojej trzeciej polityki utwórz kolejną politykę statyczną, aby umożliwić pełny dostęp właścicielowi dokumentu. Ponownie w obszarze Policy Effect wybierz Permit, a w Policy scope pozostaw zaznaczone All principals i All resources. W tym wypadku również pozostaw zaznaczone All actions.

W sekcji Policy zmień klauzulę warunkową when, aby ograniczyć uprawnienia do zasobów, w których właściciel jest równy podrzędnemu zleceniodawcy:

permit (principal, action, resource)
when { resource.owner == principal.sub };

W swojej aplikacji musisz zezwolić na dostęp do odczytu określonym użytkownikom, którzy nie są właścicielami dokumentu. Aby to uprościć, utwórz szablon zasad. Szablony zasad pozwalają tworzyć zasady na podstawie szablonu, który używa symboli zastępczych dla niektórych ich wartości, takich jak podmiot zabezpieczeń lub zasób. Symbole zastępcze w szablonie to słowa kluczowe zaczynające się od znaku the ?.

W okienku nawigacji wybierz Policy templates, a następnie Create policy template. Wprowadź opis i użyj następującej treści szablonu zasad. Korzystając z tego szablonu, możesz określić wartości symboli zastępczych ?principal i ?resource.

permit(
  principal == ?principal,
  action in [MyApp::Action::"DocumentRead"],
  resource == ?resource
);

Zakończ tworzenie szablonu polisy. Teraz użyj szablonu, aby uprościć tworzenie zasad. Wybierz Policies w okienku nawigacji, a następnie Create a template-linked policy na liście rozwijanej Create policy dropdown. Wybierz dopiero co utworzony szablon zasad i kliknij Next.

Aby nadać dostęp użytkownikowi (danilop) do konkretnego dokumentu (new-doc.txt), po prostu przekaż następujące wartości (zwróć uwagę, że MyApp jest przestrzenią nazw magazynu zasad):

• For the Principal: MyApp::User::"danilop"
• For the Resource: MyApp::Document::"new-doc.txt"

Zakończ tworzenie zasad. Teraz pora na sprawdzenie, czy zasady pracują, tak jak się tego od nich oczekuje.

Testowanie zasad w konsoli

W swoich aplikacjach możesz używać zestawów AWS SDK do uruchamiania żądania autoryzacji. Konsola umożliwia symulowanie tego, co zrobiłyby Twoje aplikacje. Wybierz Test bench w okienku nawigacji. Aby uprościć testowanie, użyj trybu Visual. Jako alternatywę możesz użyć tej samej składni JSON, co w zestawach SDK.

Jako Principal przekaż użytkownika janedoe. Jako Resource użyj pliku requirements.txt. To nie jest dokument publiczny (isPublic ma wartość false), a atrybut właściciela jest równy sub janedoe. Dla akcji wybierz MyApp::Action::"DocumentUpdate".

Uruchamiając żądanie autoryzacji, możesz przekazać Additional entities z większą ilością informacji o podmiotach zabezpieczeń i zasobach powiązanych z żądaniem. Na razie jednak pozostaw tę część pustą.

Wybierz Run authorization request u góry, aby zobaczyć decyzję opartą na bieżących zasadach. Zgodnie z przewidywaniami, decyzja jest dozwolona. Tutaj widać również, które zasady zostały spełnione przez żądanie autoryzacji. W tym przypadku jest to polityka, która umożliwia pełny dostęp do właściciela dokumentu.

Możesz również przetestować inne wartości. Jeśli zmienisz właściciela dokumentu i akcję na DocumentRead, decyzja to odmowa (deny). Jeśli następnie ustawisz atrybut zasobu isPublic na wartość true, decyzja brzmi: Zezwól (allow), ponieważ istnieje zasada zezwalająca wszystkim użytkownikom na czytanie dokumentów publicznych.

Obsługa grup w Uprawnieniach

Użytkownicy administracyjni w Twojej aplikacji muszą mieć możliwość usunięcia dowolnego dokumentu. W tym celu utwórz rolę dla administratorów. Najpierw wybierz Schema w okienku nawigacji, a następnie Edit schema. Na liście typów jednostek wybierz dodanie nowego. Użyj Role jako Type name i dodaj ją. Następnie wybierz User w typach encji i edytuj go, aby dodać Rolę jako parent. Zapisz zmiany i Utwórz następującą politykę:

permit (
  principal in MyApp::Role::"admin",
  action in [MyApp::Action::"DocumentDelete"],
  resource
);

Na stanowisku testowym uruchom żądanie autoryzacji, aby sprawdzić, czy użytkownik jeffbarr może usunąć (DocumentDelete) zasób doc.txt. Ponieważ nie jest właścicielem zasobu, żądanie zostaje odrzucone.

Teraz w Additional entities dodaj jednostkę MyApp::User z jeffbarr jako identyfikatorem. Jako parent dodaj encję MyApp::Role z admin jako identyfikatorem i potwierdź. Konsola ostrzega, że odwołuje się do encji MyApp::Role::"admin", ale nie jest ona uwzględniona w dodatkowych danych encji. Dodaj go i rozwiąż ten problem.

Ponownie uruchom żądanie autoryzacji, które jest teraz dozwolone, ponieważ według dodatkowych jednostek principal (jeffbarr) jest administratorem.

Użycie Amazon Verified Permissions w Twojej Aplikacji

W swoich aplikacjach mogę uruchamiać żądania autoryzacji za pomocą akcji isAuthorized API (lub isAuthrizedWithToken, jeśli zleceniodawca pochodzi z zewnętrznego źródła tożsamości).

Na przykład, poniższy kod w języku Python używa zestawu AWS SDK dla języka Python (Boto3) do sprawdzania, czy użytkownik ma dostęp do odczytu dokumentu. Żądanie autoryzacji korzysta z magazynu zasad, który właśnie utworzyłeś.

Python

import boto3
import time

verifiedpermissions_client = boto3.client("verifiedpermissions")

POLICY_STORE_ID = "XAFTHeCQVKkZhsQxmAYXo8"

def is_authorized_to_read(user, resource):

    authorization_result = verifiedpermissions_client.is_authorized(
        policyStoreId=POLICY_STORE_ID, 
        principal={"entityType": "MyApp::User", "entityId": user}, 
        action={"actionType": "MyApp::Action", "actionId": "DocumentRead"},
        resource={"entityType": "MyApp::Document", "entityId": resource}
    )

    print('Can {} read {} ?'.format(user, resource))

    decision = authorization_result["decision"]

    if decision == "ALLOW":
        print("Request allowed")
        return True
    else:
        print("Request denied")
        return False

if is_authorized_to_read('janedoe', 'doc.txt'):
    print("Here's the doc...")

if is_authorized_to_read('danilop', 'doc.txt'):
    print("Here's the doc...")

Uruchom ten kod i, jak można się spodziewać, dane wyjściowe będą zgodne z testami przeprowadzonymi wcześniej.

Can janedoe read doc.txt ?
Request denied
Can danilop read doc.txt ?
Request allowed
Here's the doc...

Dostępność i koszty

Usługa Amazon Verified Permissions jest obecnie dostępna we wszystkich komercyjnych regionach AWS, z wyłączeniem regionów zlokalizowanych w Chinach.

Dzięki Amazon Verified Permissions płacisz tylko za to, czego używasz, na podstawie liczby żądań autoryzacji i wywołań API wykonanych w usłudze. Aby uzyskać więcej informacji, zapoznaj się z cennikiem usługi Amazon Verified Permissions.

Korzystając z Amazon Verified Permissions, możesz skonfigurować szczegółowe uprawnienia przy użyciu języka polityki Cedar i uprościć kod swoich aplikacji. W ten sposób uprawnienia są utrzymywane w scentralizowanym magazynie i są łatwiejsze do audytu. Przeczytaj więcej o tym, jak autorzy zbudowali Cedar with automated reasoning and differential testing.

Źródło: AWS