Uwierzytelnianie w AWS Client VPN: uprawnienia IAM nie są metodą logowania
Uprawnienia w konsoli nie uwierzytelniają tunelu. Porównaj metody z certyfikatem, AD i SAML, a potem sprawdź, kiedy przekierowanie portów przez SSM pasuje do jednej prywatnej bazy danych.
Przyznanie użytkownikowi uprawnienia do tworzenia lub opisywania punktu końcowego AWS Client VPN nie pozwala mu się z nim połączyć. To dwa różne rodzaje tożsamości: IAM zarządza wywołaniami AWS API, a punkt końcowy akceptuje tylko skonfigurowane na nim metody uwierzytelniania klienta. Użytkownik może więc mieć szerokie uprawnienia w konsoli i mimo to nie mieć niczego, co klient VPN mógłby przedstawić. Zdecyduj, której metodzie ufa punkt końcowy, a potem zdecyduj, czy pełny tunel jest właściwą formą dla przyznawanego dostępu.
Tożsamość API to nie tożsamość tunelu
Kiedy ktoś mówi „rola IAM jest przypięta, dlaczego VPN nadal zawodzi”, odpowiedź zwykle brzmi, że żaden krok przepływu połączenia nigdy nie czyta tej roli. Klient przedstawia certyfikat, nazwę użytkownika i hasło AD albo asercję SAML. Punkt końcowy weryfikuje jedno z nich, a następnie przydziela adres.
IAM nadal ma znaczenie, tylko później i gdzie indziej: tworzenie punktu końcowego, kojarzenie podsieci, publikowanie tras i pisanie reguł autoryzacji to działania API. Trzymaj te uprawnienia ograniczone do operatorów, którzy ich potrzebują, zamiast dawać każdemu użytkownikowi możliwość przepisania reguł dostępu punktu końcowego.
Wybierz spośród metod obsługiwanych przez punkt końcowy
AWS Client VPN akceptuje wzajemne uwierzytelnianie oparte na certyfikacie, uwierzytelnianie Active Directory i uwierzytelnianie federacyjne oparte na SAML. Certyfikat serwera jest wymagany niezależnie od wybranej metody klienta, a konfiguracja łącząca metody wymaga powodzenia obu, a nie jednej.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
Certyfikaty są najtańsze w uruchomieniu i najłatwiejsze do popełnienia błędu na skalę, ponieważ każdy użytkownik potrzebuje poświadczenia, a każde odejście wymaga unieważnienia. Uwierzytelnianie katalogowe przenosi ten cykl życia do istniejącego systemu. Federacja przenosi go do dostawcy tożsamości i dodaje do klienta krok w przeglądarce.
Przeczytaj konfigurację samego punktu końcowego, zanim zaczniesz debugować klienta. Jeśli wzajemne uwierzytelnianie jest włączone obok metody opartej na użytkowniku, klient z ważnym certyfikatem, ale bez konta w katalogu, nadal zawiedzie, a błąd zwykle wygląda jak ogólny problem z uzgadnianiem.
Federacja to nie przekazywanie kluczy dostępu
Konfiguracja SAML nie wpuszcza do tunelu kluczy dostępu IAM ani tokenu przyjętej roli. Dostawca tożsamości uwierzytelnia osobę, zwraca asercję, a punkt końcowy akceptuje ją w ramach skonfigurowanego zaufania. Powstała sesja to sesja VPN, a nie sesja AWS API.
Ta różnica decyduje, kto co może zdiagnozować. Problemy z IdP pojawiają się jako błąd przeglądarki lub klienta, zanim w ogóle istnieje tunel, natomiast problemy z tunelem pojawiają się po udanej asercji. Zapytaj, który z tych dwóch przypadków widzisz, zanim otworzysz którąkolwiek konsolę.
Po zalogowaniu nadal decydują trasy i autoryzacja
Uwierzytelnianie daje sesji adres; nie daje sesji celu. Trasy punktu końcowego mówią klientowi, do których podsieci wysyłać, reguły autoryzacji decydują, którzy użytkownicy mogą dotrzeć do których z tych podsieci, a o reszcie decydują grupy zabezpieczeń i własne uprawnienia celu.
Dlatego użytkownik, który pomyślnie się uwierzytelni, nadal może nie dotrzeć do bazy danych. Sprawdź skojarzenie tabeli tras z podsiecią, regułę autoryzacji dla grupy użytkownika i grupę zabezpieczeń na celu w tej kolejności, ponieważ każde z nich daje inny rodzaj przekroczenia limitu czasu.
Dla jednej prywatnej bazy danych porównaj z przekierowaniem portów
Jeśli prawdziwym zadaniem jest jedno zatwierdzone połączenie z jedną prywatną bazą danych, pełny tunel sieciowy jest wyborem, a nie wymogiem. AWS Systems Manager Session Manager może przez IAM otworzyć sesję przekierowania portu do zarządzanego węzła, a ten węzeł dociera do bazy danych w sieci prywatnej. Użytkownik nigdy nie otrzymuje adresu VPC. Zarządzany węzeł staje się jedynym hostem, który może dotrzeć do portu bazy danych, i zwykle właśnie o to prosił przegląd bezpieczeństwa. Użytkownicy potrzebują wtedy lokalnego klienta i polecenia sesji zamiast profilu VPN.
Kompromis to zakres wobec wymagań wstępnych. Przekierowanie portów wymaga agenta SSM w zarządzanym węźle, osiągalności sieciowej z tego węzła do bazy danych, wtyczki Session Manager na komputerze użytkownika i uprawnienia do uruchomienia właśnie tej sesji. To nie jest trasa do każdej podsieci i nie przenosi dowolnych protokołów tak, jak robi to tunel.
W każdym razie zachowaj własną tożsamość bazy danych. Weryfikacja TLS i uwierzytelnianie bazy danych nie znikają dlatego, że ścieżka została autoryzowana przez IAM, a zatwierdzona sesja nic nie mówi o tym, które tabele użytkownik może czytać.
Wybieraj według zakresu i cyklu życia: tunel, gdy wielu użytkowników potrzebuje wielu celów i możesz prowadzić cykl życia certyfikatów lub katalogu; sesję przekierowania, gdy garstka osób potrzebuje jednej usługi i wolisz nie rozdawać adresów sieciowych. W każdym razie zapisz metodę uwierzytelniania, regułę autoryzacji i logowanie do bazy danych jako trzy odrębne fakty, ponieważ zawodzą osobno.