Podejścia do uwierzytelniania zewnętrznych aplikacji w scenariuszu maszyna-maszyna
Amazon Web Services (AWS) obsługuje wiele mechanizmów uwierzytelniania (AWS Signature v4, OpenID Connect, SAML 2.0 i inne), niezbędnych do zapewnienia bezpiecznego dostępu do zasobów AWS.
Jednakże, w ścisłym scenariuszu maszyna-maszyna (m2m), nie wszystkie są dobrym rozwiązaniem. W tych przypadkach nie jest obecny człowiek, który mógłby wprowadzić dane uwierzytelniające użytkownika. Przykładem takiego scenariusza jest sytuacja, w której aplikacja lokalna wysyła dane do środowiska AWS, tak jak przedstawiono na rysunku nr 1.
Ten post ma na celu pomóc Ci w podjęciu decyzji, które z podejść jest najlepsze, aby bezpiecznie połączyć Twoje aplikacje, zarówno te znajdujące się lokalnie, jak i te spoza AWS ze środowiskiem AWS, gdy w grę nie wchodzi żadna inna interakcja człowieka. Autorzy przeprowadzą Cię przez różne dostępne alternatywy i wyróżnią zalety oraz wady każdej z nich.
Rysunek nr 1: Bezpieczne łączenie Twoich zewnętrznych aplikacji z AWS w scenariuszach typu maszyna-maszyna
Określanie najlepszego podejścia
Warto rozpocząć od przyjrzenia się możliwym mechanizmom uwierzytelniania, które AWS obsługuje w poniższej tabeli. Najpierw zidentyfikowana zostanie usługa AWS lub usługi, gdzie uwierzytelnianie może zostać skonfigurowane – nazywane usługą AWS front-end. Następnie zostanie wskazana usługa AWS, która naprawdę zajmuje się całym procesem uwierzytelniania z AWS w tle – zwaną usługą backendu. Zostanie oceniony także cały mechanizm w oparciu o przypadek użycia.
|
Mechanizm uwierzytelniania |
Usługa front-end AWS |
Usługa backendu AWS |
Dobry dla komunikacji m2m? |
|
AWS Signature v4 |
|
Tak |
|
|
Mutual TLS |
AWS STS |
Tak |
|
|
OpenID Connect |
AWS STS |
Tak |
|
|
SAML |
|
AWS STS |
Tak |
|
Kerberos |
|
AWS STS |
Tak |
|
Komunikacja Microsoft Active Directory |
|
AWS STS |
Nie |
Tabela nr 1: Mechanizmy uwierzytelniania dostępne w AWS
Uwagi
- Amazon Cognito jako dostawca tożsamości sprawdza się tylko wtedy, kiedy w procesie uwierzytelniania uczestniczy ludzki użytkownik końcowy, na przykład w celu uwierzytelnienia użytkownika w aplikacji mobilnej lub internetowej;
- Pełna lista usług AWS, która obsługuje Microsoft Active Directory jako źródło uwierzytelniania, zależy od konkretnej konfiguracji używanej w AWS do nawiązywania połączenia z Active Directory. Podczas korzystania z AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) użyj tej listy.
Poniżej zostanie omówiona każda z alternatyw, a także ocena dwóch dodatkowych cech w 5-stopniowej skali (od bardzo niskiej do bardzo wysokiej) dla każdego mechanizmu uwierzytelniania:
- Złożoność: Jak łatwo jest wdrożyć mechanizm uwierzytelniania?
- Wygoda: Jak łatwo jest na bieżąco korzystać z mechanizmu uwierzytelniania?
Jak zaraz się przekonasz, niektóre z mechanizmów niekoniecznie są dobrym wyborem do scenariusza typu maszyna-maszyna. Twórcy skupiają się na uwierzytelnianiu zewnętrznych aplikacji, ale nie uwierzytelnianiu serwerów, innych komputerów lub urządzeń Internet of Things (IoT), które zostały już obszernie udokumentowane.
Uwierzytelnianie oparte na Active Directory jest dostępne poprzez AWS SSO lub ograniczony zestaw usług AWS i w obu przypadkach ma zapewnić użytkownikom końcowym dostęp do kont AWS oraz aplikacji biznesowych. Uwierzytelnianie oparte na usłudze Active Directory jest także wykorzystywane do uwierzytelniania w sieci urządzeń, takich jak komputery z systemem Windows lub Linux. Jednakże nie jest ono używane do uwierzytelniania aplikacji za pomocą AWS. Z tego też powodu zostanie to wykluczone z dalszej analizy w tym artykule.
Pora kolejno przyjrzeć się pozostałym mechanizmom uwierzytelniania jeden po drugim, wraz z ich zaletami i wadami.
AWS Signature v4
Celem AWS Signature v4 jest uwierzytelnienie przychodzących żądań HTTPS(S) do interfejsów API usług AWS. Proces AWS Signature v4 został szczegółowo wyjaśniony w dokumentacji API AWS, ale w dużym skrócie: to wywołujący oblicza podpis korzystając ze swoich poświadczeń i następnie dodaje go do nagłówka żądania HTTP(S). Z drugiej strony AWS akceptuje żądania tylko wtedy, jeśli podany podpis jest ważny.
Rysunek nr 2: Uwierzytelnianie Signature v4
Natywny dla AWS, niski w złożoności i wysoce wygodny, AWS Signature v4 stanowi naturalny wybór dla uwierzytelniania scenariuszy typu maszyna-maszyna z AWS. Wykorzystuje się go za kulisami przez AWS Command Line Interface (AWS CLI) i AWS SDK.
Zalety:
- AWS Signature v4 jest bardzo wygodny: podpis jest wbudowany w SDK i dostarczany przez AWS. Oprócz tego jest automatycznie obliczany w imieniu dzwoniącego. Jeśli wolisz nie korzystać z zestawu SDK, proces podpisywania jest prostym obliczeniem, które można zaimplementować w dowolnym języku programowania;
- Istnieje mniej poświadczeń do zarządzania. Nie ma potrzeby zarządzania żmudnymi certyfikatami cyfrowymi ani nawet długotrwałymi poświadczeniami AWS, ponieważ proces AWS Signature v4 obsługuje tymczasowe poświadczenia AWS;
- Nie ma potrzeby interakcji z zewnętrznym dostawcą tożsamości: kiedy żądanie zostaje podpisane, możesz zacząć działać, pod warunkiem, że podpis jest ważny.
Wady:
- Jeśli preferujesz, aby nie przechowywać długoterminowych poświadczeń AWS dla swoich aplikacji lokalnych, musisz najpierw przeprowadzić uwierzytelnianie za pośrednictwem zewnętrznego dostawcy tożsamości, aby uzyskać tymczasowe poświadczenia AWS. To może wymagać korzystania z OpenID Connect lub SAML, oprócz Signature v4.
Wzajemny TLS (Mutual TLS)
Mutual TLS, a dokładniej wspólny mechanizm uwierzytelniania protokołu Transport Layer Security (TLS), umożliwia uwierzytelnianie po obu stronach – zarówno klienta, jak i serwera kanału komunikacji. Domyślnie strona serwera kanału TLS jest zawsze uwierzytelniana. W przypadku wzajemnego TLS klienci muszą również przedstawić aktualny certyfikat X.509, aby zweryfikować swoją tożsamość.
Amazon API Gateway niedawno zapowiedział natywną obsługę dla wzajemnego uwierzytelniania TLS (więcej informacji na ten temat znajdziesz w najnowszym poście na blogu). Możesz włączyć wzajemne uwierzytelnianie TLS w domenach niestandardowych w celu uwierzytelnienia regionalnych interfejsów API REST i HTTPS API (z wyjątkiem prywatnych lub brzegowych interfejsów API, dla których nowa funkcja nie jest obsługiwana w chwili, gdy powstawał ten tekst).
Rysunek nr 3: Wzajemne uwierzytelnianie TLS
Zalety
- Wzajemny TLS jest szeroko rozpowszechniony w przypadku IoT i aplikacji typu business-to-business.
Wady
- Musisz zarządzać certyfikatami cyfrowymi oraz ich cyklem życia. Może to spowodować znaczne obciążenie i złożoność Twoich operacji IT;
- Na poziomie aplikacji musisz także zwrócić szczególną uwagę na unieważnione certyfikaty w celu zredukowania ryzyka nadużyć. Odkąd API Gateway nie weryfikuje w sposób automatyczny tego, czy certyfikat klienta został odwołany, musisz zaimplementować własną logikę, aby to zrobić, na przykład za pomocą Lambda authorizer.
OpenID Connect
OpenID Connect (OIDC), a w szczególności OIDC 1.0, jest standardem zbudowanym na podstawie struktury autoryzacji OAuth 2.0 w celu zapewnienia uwierzytelnienia dla aplikacji mobilnych i internetowych. OIDC może być użyty w celu delegowania uwierzytelniania do zewnętrznego dostawcy tożsamości, takiego jak Amazon Cognito lub jakiegokolwiek dostawcy tożsamości obsługującego ten standard oraz do uzyskania dostępu do AWS poprzez przedstawienie tokena uzyskanego od dostawcy tożsamości. Następnie AWS weryfikuje token u dostawcy tożsamości, a po pomyślnym zakończeniu dostarcza zestaw tymczasowych danych uwierzytelniających AWS na stronie żądającej. Cały proces został szczegółowo opisany w dokumentacji AWS and Access Management.
Rysunek nr 4: Uwierzytelnianie OIDC
Wprowadzenie OIDC może wydawać się skomplikowane, ale jest to szeroko rozpowszechniony mechanizm uwierzytelniania, szczególnie dla mobilnych i internetowych aplikacji oraz architektury mikrousług, w tym scenariuszy typu machine-to-machine.
Zalety
- Wraz z OIDC nie tylko unikasz przechowywania długotrwałych poświadczeń AWS dla swoich aplikacji lokalnych, ale możesz również użyć istniejącego katalogu lokalnego jako dostawcy tożsamości, np. Active Directory;
- OIDC nie wymaga dedykowanej, istniejącej wcześniej konfiguracji w środowisku AWS. Dokładniej: relacja zaufania nie jest potrzebna między preferowanym dostawcą a AWS;
- Wreszcie: OIDC wykorzystuje przepływ komunikatów REST/JSON poprzez HTTTP, co sprawia, że jest szczególnie dobrze dopasowany (w porównaniu do SAML) dla dzisiejszych programistów aplikacji.
Wady
- Korzystanie OIDC wraz z AWS wymaga zewnętrznego dostawcy tożsamości dla środowiska lokalnego;
- Musisz zarządzać tokenami OAuth 2.0, takimi jak tokeny dostępu i tokeny odświeżania, oraz ich cyklami życia. To może spowodować znaczne obciążenie i złożoność operacji IT.
SAML
SAML 2.0 to otwarty standard wymiany informacji o tożsamości i zabezpieczeniach pomiędzy aplikacjami i dostawcami usług. SAML może zostać wykorzystany do delegowania uwierzytelniania do zewnętrznego dostawcy tożsamości, takiego jak środowisko Active Directory działające lokalnie oraz do uzyskania dostępu do AWS przez podanie prawidłowej asercji SAML (sprawdź informacje na temat federacji opartej na SAML 2.0 i dowiedz się, jak skonfigurować środowisko AWS do korzystania z SAML 2.0).
IAM weryfikuje potwierdzenie SAML u Twojego dostawcy i jeśli zakończy się powodzeniem, dostarcza zestaw tymczasowych danych uwierzytelniających AWS stronie żądającej. Cały proces został opisany w dokumentacji IAM.
Rysunek nr 5: uwierzytelnianie SAML
SAML może wydawać się skomplikowany, jednak jest to wszechstronny mechanizm uwierzytelniania, który może pasować do wielu różnych przypadków użycia, w tym scenariuszy typu machine-to-machine.
Zalety
- Dzięki SAML nie tylko unikasz przechowywania długotrwałych poświadczeń AWS dla aplikacji lokalnych, ale możesz również użyć istniejącego katalogu lokalnego, jak Active Directory jako dostawcy tożsamości;
- SAML nie określa żadnej konkretnej technologii ani protokołu, za pomocą którego powinno odbywać się uwierzytelnianie. Programista posiada całkowitą swobodę w stosowaniu tego, który jest bardziej wygodny lub sensowniejszy: oparty na kluczach (jak certyfikaty X.509), oparty na kluczach (jak Kerberos) lub dowolny inny odpowiedni mechanizm;
- SAML to także dobry wybór, gdy potrzebne są powiązania protokołów inne niż HTTP.
Wady
- Korzystanie z SAML z AWS wymaga zewnętrznego dostawcy tożsamości dla środowiska lokalnego;
- SAML wymaga także ustanowienia zaufania pomiędzy dostawcą tożsamości a środowiskiem AWS, co zwiększa złożoność tego procesu;
- Ze względu na to, że SAML oparty jest na języku XML, nie jest tak zwięzły i treściwy jak np. AWS Signature V4 lub OIDC;
- Musisz zarządzać asercjami SAML i ich cyklami życia. Może to spowodować znaczne obciążenie i złożoność operacji IT.
Kerberos
Pierwotnie opracowany przez MIT Kerberos v5 jest standardowym protokołem IETF, który umożliwia uwierzytelnianie klient/serwer w niezabezpieczonej sieci. Nie jest obsługiwana od razu przez AWS, ale możesz użyć dostawcy tożsamości, takiego jak Active Directory, do wymiany biletu Kerberos dostarczonego do aplikacji na token OIDC/OAuth lub potwierdzenie SAML, które może być zatwierdzone przez AWS.
Rysunek nr 6: Uwierzytelnianie Kerberos (poprzez SAML lub OIDC)
Skonfigurowanie Kerberos jest dość skomplikowane, ale ma sens w sytuacjach, w których posiadasz już środowisko lokalne z uwierzytelnianiem Kerberos.
Zalety
- Wraz z Kerberos nie tylko unikasz przechowywania długotrwałych poświadczeń AWS dla aplikacji lokalnych, ale możesz także wykorzystać istniejący katalog lokalny, taki jak Active Directory jako dostawcę tożsamości.
Wady
- Korzystanie z Kerberos z AWS wymaga konwersji biletu Kerberos na coś, co może zostać zaakceptowane przez AWS. Dlatego też wymaga użycia mechanizmów uwierzytelniania OIDC lub SAML, tak ja opisano wcześniej.
Wnioski
Pora na zebranie informacji i podsumowanie dyskusji w poniższej tabeli, wraz z uwzględnieniem zalet i wad każdego podejścia.
|
Mechanizm uwierzytelniania |
Usługa front-end AWS |
Złożoność |
Wygoda |
|
AWS Signature v4 |
|
Niska |
Bardzo wysoka |
|
Wzajemny TLS |
|
Średnia |
Wysoka |
|
OpenID Connect |
|
Średnia |
Wysoka |
|
SAML |
|
Wysoka |
Średnia |
|
Kerberos |
|
Bardzo wysoka |
Niska |
AWS Signature v4 jest najwygodniejszym i najmniej skomplikowanym mechanizmem ze wszystkich, ale jak w każdej sytuacji ważne jest, aby przed dokonaniem wyboru zacząć od własnych wymagań i kontekstu. Na wybór mogą mieć wpływ dodatkowe czynniki, takie jak struktura, kultura organizacji czy zasoby dostępne dla projektu. Celowo utrzymując tę dyskusję skupioną na prostych czynnikach, twórcy wymyślili następującego „pomocnika” przy podejmowaniu decyzji.
Korzystaj z AWS Signature v4, gdy:
- Masz dostęp do poświadczeń AWS (tymczasowych lub długoterminowych);
- Chcesz wywołać usługi AWS bezpośrednio przez ich interfejsy API.
Korzystaj z wzajemnego TLS, gdy:
- Koszt i wysiłek związany z utrzymaniem certyfikatów cyfrowych jest akceptowalny dla Twojej organizacji;
- Twoja organizacja ma już wdrożony proces obsługi certyfikatów cyfrowych;
- Planujesz wywoływać usługi AWS bezpośrednio przez niestandardowe interfejsy API.
Korzystaj z OpenID Connect, gdy:
- Potrzebujesz lub chcesz uzyskać tymczasowe dane uwierzytelniające AWS przy użyciu mechanizmu opartego na REST;
- Chcesz wywołać usługi AWS bezpośrednio lub przez interfejsy API.
Korzystaj z SAML, gdy:
- Musisz zdobyć tymczasowe dane uwierzytelniające AWS;
- Posiadasz wdrożony proces uwierzytelniania oparty na SAML;
- Chcesz wywoływać usługi AWS bezpośrednio przez ich interfejsy API.
Korzystaj z Kerberos, gdy:
- Masz już wdrożony proces uwierzytelniania oparty na protokole Kerberos;
- Żaden z wymienionych do tej pory mechanizmów nie może zostać użyty w Twoim przypadku użycia.
Twórcy artykułu mają nadzieję, że artykuł ten będzie pomocny w znalezieniu drogi wśród wielu różnych alternatyw oferowanych przez AWS, aby bezpiecznie połączyć zewnętrzne aplikacje ze środowiskiem AWS i wybrać najbardziej odpowiedni mechanizm dla konkretnego przypadku użycia.
Jeśli posiadasz uwagi do tego artykułu, pozostaw komentarz w sekcji Komentarze, znajdującej się poniżej. Jeśli posiadasz pytania odnoszące się do tego artykułu, rozpocznij nowy wątek na forum programistów AWS lub skontaktuj się z pomocą techniczną AWS.
źródło: AWS
44-200 Rybnik
Poland
REGON: 240692928
KRS: 275333
