Wyobraź sobie, że dopiero zaczynasz przygodę z Amazon Web Services i od początku chcesz mieć wszystko, jak należy – bezpiecznie, wygodnie i z głową. Szukasz rozwiązania, które nie tylko uprości logowanie, ale też pozwoli w przyszłości skalować się wraz z rozwojem twojej firmy czy projektu. Jeśli w tym opisie widzisz siebie – dobrze trafiłeś!
Z kolei część z nas ma zupełnie inne wyzwania. Być może pracujesz z AWS-em od lat i pamiętasz czasy, kiedy IAM (Identity and Access Management) było jedyną słuszną opcją logowania się do konta. Wszyscy deweloperzy mieli swoje długo żyjące klucze dostępowe, a integracja z zewnętrznymi systemami uwierzytelniania (takimi jak AD FS) była w tamtych latach wystarczająca, choć mało przyjazna. Teraz, gdy usługi chmurowe rozwinęły się nieprawdopodobnie, masz spore obawy, czy obecna konfiguracja nadal jest bezpieczna. Zastanawiasz się, czy można to zrobić prościej – tak, żeby zarządzanie dostępami nie kosztowało cię masy czasu i nie wymagało ręcznego sprawdzania, kto faktycznie powinien jeszcze mieć konto, a komu powinno się je dawno wyłączyć.
A może rozpoznajesz się w trzecim scenariuszu – firma, w której pracujesz, miała do tej pory jedno konto AWS założone przez zewnętrznego partnera. Zaczęliście na nim przygodę z chmurą i wszelkie uprawnienia są tam skonfigurowane za pomocą prostych kont IAM Users. Teraz jednak szykuje się ekspansja – kolejne projekty, środowiska, a może nawet przejęcie całkiem nowego obszaru biznesowego. Czas więc zacząć tworzyć nowe konta AWS, a wraz z tym pojawia się potrzeba zapanowania nad całym dostępem i uproszczenia procesu logowania w jednym miejscu. W końcu każdy, kto pracuje z chmurą, wie, że posiadanie kilkunastu czy kilkudziesięciu kont wymaga pewnego ustrukturyzowania – nie chcesz chyba za każdym razem spędzać długich godzin na resetowaniu haseł i ręcznym tworzeniu nowych użytkowników?
Jeżeli w którejkolwiek z powyższych historii widzisz siebie albo swój zespół – jesteś w odpowiednim miejscu. W tym artykule przyjrzymy się usłudze AWS IAM Identity Center (dawniej AWS Single Sign-On), która może znacząco ułatwić życie każdemu, kto musi zarządzać dostępem do jednego lub kilkuset kont AWS. Pokażemy też, jak taką konfigurację wdrożyć i na co zwrócić szczególną uwagę przy integracji z obecnymi systemami uwierzytelniania, takimi jak Okta czy Entra (Azure AD). Dzięki temu – niezależnie od tego, czy dopiero zaczynasz swoją chmurową podróż, czy masz już na koncie lata doświadczeń – znajdziesz tu coś, co pomoże ci usystematyzować i zabezpieczyć twoje środowisko.
Brak kontroli
Niektórzy uważają, że „wszystko będzie dobrze”, dopóki ktoś niepożądany faktycznie nie włamie się do ich konta. Prawda jest jednak taka, że – w dobie internetu i narzędzi do automatycznego przeszukiwania publicznych zasobów – bardzo łatwo o wyciek danych uwierzytelniających, zwłaszcza jeżeli nadal korzystasz z klasycznych kont IAM Users z długowiecznymi kluczam (Access i Secret Key). Przykładowo wyobraź sobie dewelopera, który wrzucił do publicznego repozytorium na GitHubie fragment kodu zawierający klucze AWS lub nawet zdążył wdrożyć nową wersję twojej strony internetowej z kluczami użytymi gdzieś w JavaScripcie. Dziś wystarczy prosta wyszukiwarka (np. Shodan, BinaryEdge czy nawet ta dostępna na GitHubie) i już ktoś może te klucze znaleźć. Jeśli dołożymy do tego marną lub zerową znajomość konceptu principle of least privilege (PoLP) i skompromitowane klucze mają nadmierne prawa dostępu, konsekwencje mogą być bardzo poważne. Atakujący z dostępem do twoich kont AWS może w mig stworzyć całe mnóstwo zasobów(czyli generować koszty), skopiować wrażliwe dane z S3, a nawet namieszać w ustawieniach sieci czy DNS. Z pozoru drobny wyciek kluczy może w efekcie oznaczać gigantyczne straty finansowe i wizerunkowe.
Druga grupa osób, która z reguły najbardziej docenia Identity Center, to ci, którzy już doświadczyli skutków tzw. spóźnionego offboardingu. To sytuacja, w której pracownik czy zewnętrzny kontraktor kończy współpracę, a jego dostęp do chmury nie zostaje w porę zablokowany. Jeżeli firma bazuje wyłącznie na kontach IAM Users, to ktoś musi pamiętać, aby takie konta natychmiast ręcznie usuwać (lub przynajmniej wyłączać klucze), co nie zawsze dzieje się wystarczająco szybko. W wielu organizacjach dopiero po paru tygodniach czy nawet miesiącach ktoś orientuje się, że była współpracowniczka wciąż widnieje na liście aktywnych użytkowników. A przecież jeśli odeszła z zespołu czy firmy w złej atmosferze, ma wciąż dostęp do newralgicznych danych i może to wykorzystać. Przy usługach takich jak AWS IAM Identity Center wystarczy usunąć lub zablokować konto użytkownika w centralnym systemie tożsamości, żeby z automatu zabrać dostęp do wszystkich powiązanych kont i aplikacji.
Wreszcie trzeci powód, by pomyśleć o AWS IAM Identity Center już na starcie: spokój i wygoda zarazem. Nie każdy w zespole jest DevOpsem czy administratorem chmury – mamy product managerów, analityków, testerów, którzy chcą po prostu móc zalogować się do konsoli i kliknąć tu czy tam, bez zgłębiania tajników IAM Policies. Dla nich obecność prostego procesu opartego na firmowym systemie logowania jest rozwiązaniem idealnym, bo nie muszą przejmować się osobnymi hasłami do chmury czy kluczami. A do tego, jeśli firma wprowadziła regułę, że każde konto loguje się wyłącznie z użyciem MFA, to jest to automatycznie egzekwowane również w Identity Center, nie trzeba nic dodatkowo konfigurować w AWS-ie.
Z perspektywy bezpieczeństwa i wygody widać więc wyraźnie, że stawianie na nowoczesne rozwiązania do centralnego zarządzania tożsamością i dostępem w chmurze to nie tylko kaprys dużych korporacji. Również małe zespoły, pojedynczy deweloperzy czy osoby planujące rozbudowę środowiska w AWS-ie mogą zyskać na tym rozwiązaniu. Oszczędzą czas, zminimalizują ryzyko wycieków i złych konfiguracji, a także postawią solidny fundament pod przyszłą rozbudowę projektu. Bez względu na to, czy obawiasz się ataku z zewnątrz, czy chcesz po prostu spać spokojniej, mając pewność, że wszystkie konta i dostępy masz w jednym miejscu – omawiane w tym artykule rozwiązanie jest zdecydowanie warte uwagi.
Podstawy
AWS IAM Identity Center to usługa, która upraszcza zarządzanie dostępem do środowisk AWS. Dzięki niej możesz stworzyć jeden punkt kontroli, z którego zarządzasz kontami, użytkownikami i ich poziomami uprawnień. Jest to przydatne zarówno wówczas, gdy masz jedno konto AWS, jak i wtedy, gdy ich liczba sięga kilkudziesięciu czy nawet kilkuset
Jeżeli pracujesz na pojedynczym koncie, IAM Identity Center pomaga w prostym konfigurowaniu logowania do AWS Console czy CLI. Wystarczy, że dodasz użytkowników, określisz ich uprawnienia i gotowe – nie musisz tworzyć nadmiarowych ról ani pamiętać o utrzymywaniu osobnych mechanizmów autoryzacyjnych.
W większych organizacjach, gdzie kont AWS jest wiele, IAM Identity Center staje się jeszcze ważniejszy. Pozwala on zdefiniować centralnie, którzy użytkownicy mają dostęp do poszczególnych kont i jakie konkretne zadania mogą w nich wykonywać. Jedną z najciekawszych funkcji jest możliwość szybkiego połączenia Identity Center z zewnętrznym dostawcą tożsamości (Identity Provider, IdP). Oznacza to, że jeśli twoja firma korzysta z Okta, Entra (Azure AD) albo innego rozwiązania obsługującego standardy SAML czy OpenID Connect, możesz stworzyć automatyczną integrację. Dzięki temu użytkownicy uwierzytelniają się w znanym sobie systemie logowania, a AWS dowiaduje się tylko o tym, który użytkownik się pojawił oraz jaką rolę czy poziom dostępu mu przydzielić. Co najlepsze, to wszystko może dziać się w pełni automatycznie. Gdy w systemie kadrowym przyjmujemy do pracy nową osobę i dodajemy ją do grupDevOps, Identity Center może natychmiast pozwolić jej wejść na konkretny zestaw kont AWS z rolą i uprawnieniami zdefiniowanymi w permission secie o nazwie DevOps.
Wiele osób nadal korzysta z kont IAM Users z kluczami Access/Secret Key, które – jeśli nie ustawi się okresowego wymuszenia zmiany – mogą istnieć latami. To prawdziwa pułapka. Po pierwsze, niesie ogromne ryzyko, że te klucze prędzej czy później wyciekną (np. trafią 0do kodu w publicznym repozytorium), a po drugie, trudno nimi zarządzać w dużej skali. IAM Identity Center pozwala przejść na tymczasowe poświadczenia, które są generowane tylko wtedy, gdy użytkownik faktycznie się loguje. W efekcie nie ma już potrzeby utrzymywania masy haseł czy długowiecznych kluczy w plikach konfiguracyjnych.
Sam serwis AWS IAM Identity Center nie wiąże się z żadnymi opłatami. Jeśli chcesz zweryfikować, jak działa na małą skalę, wystarczy włączyć go i przeprowadzić podstawową konfigurację. Nie poniesiesz przy tym żadnych kosztów za użytkowników, grupy czy permission sety.
Dobrze zaprojektowana infrastruktura w chmurze oznacza mniej problemów w przyszłości. Skonfigurowanie IAM Identity Center na starcie (lub poświęcenie chwili na migrację istniejących użytkowników) może zaoszczędzić sporo pracy adminom i zespołom bezpieczeństwa w dłuższej perspektywie. Jeśli w przyszłości zechcesz wprowadzić dodatkowe poziomy ochrony, typu kontrola dostępów po atrybutach (uwzględniający np. e-mail, nazwę użytkownika czy departament, w którym pracuje), Identity Center będzie na to gotowe.
Co ważne, możesz uruchomić ten serwis równolegle z dotychczasowymi rozwiązaniami, takimi jak konta IAM Users. Nie musisz od razu porzucać istniejącej konfiguracji i obawiać się, że praca deweloperów zostanie przerwana. Identity Center jest w pełni niezależne – możesz zatem testować je w ograniczonym zakresie, przydzielać grupy wybranych użytkowników do nowego systemu logowania i dopiero później, stopniowo, migrować resztę.
Ostatecznie, gdy spojrzymy na cały ekosystem AWS i na to, jak szybko rośnie zapotrzebowanie na przejrzyste, bezpieczne zarządzanie dostępem, łatwo zrozumieć popularność IAM Identity Center. Jest intuicyjny, nie generuje dodatkowych kosztów, a przy tym pozwala unikać typowych pułapek związanych z klasycznym kontami IAM Users.
Elementy usługi
Wcześniej pojawiły się już określenia takie jak „permission set” czy „grupy”. W tej części wyjaśnimy, czym one są i jak ich używać. Przejrzymy też wszystkie dostępne w konsoli komponenty, aby pokazać, jak dokładnie działają i w jaki sposób pomagają efektywnie zarządzać dostępem.
USERS
W Identity Center użytkownicy mogą pochodzić z różnych źródeł. Najprostsze to lokalna baza tożsamości wewnątrz Identity Center. Możesz jednak również użyć zewnętrznego dostawcy, dzięki czemu nie musisz zajmować się ręcznym tworzeniem kont użytkowników w AWS-ie:
- lokalni użytkownicy – tworzysz ich w samym Identity Center, definiujesz imiona, nazwiska, e-maile i hasła. Takie konta sprawdzają się w małych zespołach, gdy nie masz innego systemu logowania;
- użytkownicy z zewnętrznego IdP – to najwygodniejsza opcja w firmach mających już zintegrowany system uwierzytelniania. Wówczas Identity Center na bieżąco pobiera dane o użytkownikach, a sam dostęp do AWS-u zależy od reguł definiowanych w IdP (np. kiedy ktoś odejdzie z firmy i zostanie usunięty w IdP, automatycznie traci dostęp do AWS).
GROUPS
Grupy w Identity Center to zbiory użytkowników, którym można przypisać jednolite prawa dostępu. Zamiast przypinać permission sety każdemu osobno, dodajesz ich do odpowiednich grup i łączysz je z kontem AWS czy aplikacją.
Przykład – możesz mieć grupy DevOps-Prod (z pełnymi uprawnieniami do produkcji) i DevOps-NonProd (ograniczonymi uprawnieniami) przypisane do konkretnych permission setów na właściwych kontach AWS. Jeśli nowa osoba dołącza do działu DevOps, wystarczy przydzielić ją do odpowiednich grup, a cała magia dzieje się w tle.
Jeśli korzystasz z zewnętrznych dostawców tożsamości, to dobrą praktyką jest tworzenie grup o nazwach, które same się tłumaczą, np. AWS#123456789012#Administrator:
- AWS – bo przeważnie masz jeszcze wiele innych aplikacji i typów grup; 123456789012 (ID lub nazwa konta) – żeby wiedzieć, do jakiego konta ta grupa powinna mieć dostęp;
- Administrator – prawa, na jakich dana grupa może „bawić się” na powyższym koncie.
AWS ACCOUNTS
Dzięki podglądowi struktury twojej organizacji AWS wraz z listą wszystkich kont możesz łatwo sprawdzić, jakie grupy i użytkownicy przypisani są do kont i jakich zestawów uprawnień używają.
PERMISSION SETS
Zestawy uprawnień to tak naprawdę szablony dla ról IAM, które stworzone zostaną na poszczególnych kontach AWS. Definiujesz w nich, co dana rola może robić (np. pełny dostęp do EC2, ale tylko odczyt do S3). Warto mieć jasną strukturę permission setów, aby z łatwością mapować je do ról w zespole. AWS udostępnia predefiniowane zestawy uprawnień (np. AdministratorAccess, PowerUser, Billing). Możesz też zdefiniować własne – podobnie jak w IAM Policies. Dobrą praktyką jest przypinanie permission setów grupom, a nie pojedynczym użytkownikom. Oszczędza to czas i zmniejsza ryzyko błędów.
APPLICATIONS
AWS IAM Identity Center potrafi również przyjąć rolę identity providera i obsługiwać logowanie do aplikacji innych niż konto AWS. Możesz więc mieć pojedynczy punkt logowania, który zapewnia dostęp nie tylko do konsoli AWS, ale także do zewnętrznych aplikacji obsługujących standard SAML 2.0 (np. Salesforce, Slack czy Amazon Q).
SETTINGS
Warto poświęcić również nieco czasu zakładce Ustawienia, by lepiej zrozumieć sposób działania Identity Center. Poniżej omawiamy najważniejsze opcje:
- Identity Source – w tym miejscu określasz, skąd Identity Center będzie pobierać dane o użytkownikach i grupach. Masz trzy opcje do wyboru:
-
- Local directory – tworzysz konta i grupy bezpośrednio w panelu Identity Center. Sprawdzi się w małych środowiskach bez istniejących dostawców tożsamości.
- Active Directory – możesz wskazać domenę AD jako źródło tożsamości, jeśli w firmie jest klasyczne rozwiązanie on-prem lub w chmurze (np. AWS Directory Service for Microsoft AD).
- External identity provider – integracja z nowoczesnymi IdP (Azure AD/ Entra, Okta i inne).
Jak już wspominaliśmy wyżej, w praktyce najczęściej spotyka się dwa warianty: lokalny (dla małych zespołów lub testów) i zewnętrzny IdP (duże lub średnie firmy).
Jeśli zdecydujemy się na użycie zewnętrznego dostawcy tożsamości, to warto wspomnieć o SCIM (System for Cross-domain Identity Management), czyli protokole, który pozwala automatycznie synchronizować użytkowników i grupy z twojego IdP do Identity Center. Dzięki temu w AWS-ie pojawiają się zasoby odzwierciedlające rzeczywistą strukturę z twojej firmy. Jeżeli nie skonfigurujemy SCIM, to dostęp z zewnętrznego IdP nadal będzie możliwy, ale to po stronie zespołu obsługującego AWS będzie zadanie tworzenia grup i użytkowników o takich samych nazwach jak w obecnym systemie.
- Delegated Administrator – jeśli zarządzasz wieloma kontami w ramach AWS Organizations, możesz wyznaczyć jedno z nich jako delegated administrator dla Identity Center. To oznacza, że zarządzanie użytkownikami i grupami nie musi odbywać się wyłącznie z konta głównego (management account). Ma to swoje zalety i wady:
-
- plusy – możesz powierzyć administrację dostępem w AWS-ie komuś innemu w firmie, nie dając mu od razu praw do całego konta głównego, a tym samym do całej organizacji;
- ograniczenia – nadal pewne rzeczy wymagają uprawnień konta głównego. Delegowany administrator nie będzie w stanie nadawać dostępów do konta głównego ani modyfikować jakichkolwiek permission setów użytych na tym koncie.
- Atrybuty sesji (Attributes for Access Control) – to dodatkowy poziom elastyczności w modelu uprawnień. Możesz używać atrybutów (np. departament, stanowisko) z systemu tożsamości w IdP do definiowania, kto co może robić w AWS-ie. Poniżej przedstawiamy dwa przykłady:
-
- jeżeli w IdP wprowadzimy pole department=Finance, to w AWS-ie możesz zdefiniować permission set przyznający dostęp do określonych zasobów wyłącznie osobom z tym atrybutem;
- tworząc permission set pozwalający na połączenie RDS z poziomu roli IAM, możemy wykorzystać tag user-Name do stworzenia generycznej polityki dostępu typu:
{
„Action”: „rds-db:connect”,
„Effect”: „Allow”,
„Resource”: „arn:aws:rds-db:*:*:dbuser:\
*/${aws:PrincipalTag/userName}”
}
Konfiguracja krok po kroku
Przyszła pora, by przejść z teorii do praktyki i pokazać, jak włączyć oraz skonfigurować AWS IAM Identity Center. Wbrew pozorom nie jest to proces skomplikowany – wystarczy jedynie stworzyć grupy, użytkowników, zestawy uprawnień i wszystko ze sobą spiąć! Jeśli do tej pory korzystałeś tylko z klasycznych kont IAM Users, masz szansę wprowadzić do swojego środowiska nowoczesny, centralny mechanizm zarządzania dostępem.
WŁĄCZENIE IDENTITY CENTER
Na początku musimy uruchomić samą usługę w AWS. W tym celu:
- Zaloguj się na konto główne w organizacji AWS – to właśnie tutaj dostępne są serwisy wspomagające Twoją organizację, w tym Identity Center.
- Wpisz w pasku wyszukiwania IAM Identity Center i kliknij link do tej usługi.
- Kliknij Enable AWS IAM Identity Center. 4. Poczekaj chwilę, aż usługa się aktywuje. Gdy zobaczysz komunikat, że Identity Center jest gotowe, możesz przejść do kolejnego etapu konfiguracji.
Jeśli zamiast możliwości wykonania kroku trzeciego widzisz pełny dostęp do Identity Center, to ktoś już tu kiedyś był i aktywował usługę za ciebie. Jeżeli natomiast nie widzisz zupełnie możliwości włączenia usługi, a zamiast tego wyświetla się komunikat, że Identity Center istnieje w innym regionie – przełącz region.
WYBÓR DOSTAWCY TOŻSAMOŚCI
Najważniejszy wybór dotyczy tego, skąd będą pochodzić dane o użytkownikach i grupach:
- Local directory (lokalna baza) – najszybsze rozwiązanie, idealne do małych środowisk lub testów. AWS tworzy lokalny user store, w którym możesz ręcznie dodawać konta i grupy. Zaletą jest prostota – wchodzisz w zakładkę Users, wybierasz Add user i w kilka sekund masz gotowe konto. Wadą bywa natomiast brak integracji z firmowymi systemami – musisz pamiętać, by usuwać konta w Identity Center, gdy pracownik odejdzie, a twoi programiści będą mieli osobne konto do zasobów chmurowych.
- Active Directory – jeśli masz firmową domenę AD, możesz spiąć ją z Identity Center. Dzięki temu użytkownicy, którzy istnieją w AD, będą mieli dostęp do chmury, o ile przypiszesz im odpowiednie uprawnienia. Rozwiązanie często spotykane w firmach, które przenoszą się z klasycznego AD FS do nowszego rozwiązania opartego na chmurze.
- External identity provider (IdP) – najczęściej wybierana opcja w średnich i dużych organizacjach, które korzystają z zewnętrznych rozwiązań typu Okta czy Entra (Azure AD).
Przy tej integracji AWS IAM Identity Center importuje (za pomocą SCIM-a lub SAML-a) informacje o tym, kto jest użytkownikiem, w jakich grupach się znajduje i jakie ma atrybuty. Gdy nowa osoba dołączy do zespołu i zostanie dodana do grupy DevOps w IdP, automatycznie będzie mogła zalogować się do AWS-u i otrzyma określone uprawnienia. Analogicznie, jeśli ktoś zmienia dział lub odchodzi z pracy, wystarczy modyfikacja w IdP – AWS dostosuje się do tego bez dodatkowych kliknięć.
Jak skonfigurować wybrane źródło tożsamości? Poniżej instrukcja krok po kroku:
- W konsoli AWS IAM Identity Center wybierz zakładkę Settings.
- W sekcji Identity Source kliknij Change.
- Wybierz Local Directory, AD lub External provider.
- Postępuj zgodnie z instrukcjami wyświetlanymi na ekranie (np. podanie adresu URL SAML lub danych integracji SCIM).
- Zapisz zmiany.
Jeżeli zdecydujesz się na integrację z Okta czy Entra (Azure AD), będziesz musiał wykonać dodatkowe kroki konfiguracyjne po stronie IdP – stworzenie aplikacji, wygenerowanie lub wybranie istniejących grup i przypisanie ich do aplikacji czy konfiguracja automatycznego wypychania użytkowników i grup (provisioningu, SCIM). Dokumentacja AWS-u prowadzi przez to krok po kroku i zwykle cały proces zajmuje maksymalnie kilkanaście minut.
TWORZENIE PERMISSION SETÓW
Gdy już wybraliśmy źródło tożsamości, pora przygotować zestawy uprawnień, które będą przypisywane do kont AWS:
- Wejdź w sekcję Permission sets.
- Kliknij Create permission set.
- Wybierz tryb tworzenia. Możesz skorzystać z wbudowanego szablonu (np. AdministratorAccess, PowerUser, Billing, ReadOnly) albo zdefiniować własną politykę dostępu.
- Nadaj nazwę i opcjonalny opis.
- W sekcji Session duration wybierz, jak długo ma trwać sesja użytkowników korzystających z tej roli (np. 1h, 4h, 8h). Jest to punkt opcjonalny.
- Zapisz swój permission set.
Tworząc zestawy uprawnień, staraj się, aby były one generyczne i pasowały do wszystkich twoich kont. Jeżeli użyjesz polityki wskazującej na konkretny ARN konkretnego zasobu na koncie A, to taki permission set może być bezużyteczny dla użytkowników z konta B.
PRZYPISYWANIE DO KONT AWS
Następnie przychodzi kluczowy etap – skojarzenie grup bądź konkretnych osób z kontami AWS oraz dodanie im praw dostępu poprzez wybranie odpowiednich permission setów:
- Wejdź do zakładki AWS Accounts, wybierz interesujące cię konto (lub zaznacz wiele kont, jeśli chcesz masowo przypisać uprawnienia).
- Kliknij Assign users or groups.
- Wskaż, kogo chcesz przypisać (np. grupę DevOps).
- Wybierz permission set, np. AdministratorAccess albo DevOps-Prod.
- Zapisz zmiany.
Kilka sekund zajmie rozpropagowanie twoich nowych ustawień na wszystkich wybranych kontach. AWS automatycznie utworzy tam odpowiednie role i przypnie polityki. Teraz, gdy użytkownik należący do takiej grupy zaloguje się przez Identity Center, zobaczy na swojej liście kont AWS te, do których ma dostęp.
TESTOWANIE LOGOWANIA
Na koniec warto sprawdzić, czy nasza nowa konfiguracja działa prawidłowo. Na głównej stronie Identity Center w sekcji Settings summary znajdziesz adres URL prowadzący do twojej instancji portalu logowania do AWS (AWS access portal URL) – skopiuj go i użyj do testów logowania:
- Otwórz AWS access portal (czyli link, który przed chwilą skopiowałeś).
- Jeśli korzystasz z lokalnych użytkowników Identity Center, zaloguj się, używając loginu i hasła. Jeśli skonfigurowałeś zewnętrznego dostawcę, to zostaniesz automatycznie przeniesiony na stronę logowania dostawcy.
- Tam wystarczy użyć swoich danych logowania na konto firmowe. Pamiętaj, że jeśli masz aktywną sesję w swoim IdP, to możesz nawet nie zauważyć przekierowań i wrócisz do portalu Identity Center już zalogowany.
- Zobacz, czy na liście kont AWS pojawiają się te, do których nadałeś dostęp.
- Spróbuj wejść do konsoli, wybierając swoją przypisaną rolę. Sprawdź, czy uprawnienia są zgodne z wybranym permission setem.
Jeżeli wszystko poszło dobrze, możesz pogratulować sobie podstawowego uruchomienia AWS IAM Identity Center!
CODZIENNA PRACA
Powyżej omówiliśmy już, jak wygląda prosty proces logowania do konsoli, więc pora na coś ciekawszego. Na początek – dostęp CLI dla miłośników linii poleceń, potrzebujących sesji dla swoich skryptów i aplikacji lokalnych:
- Zainstaluj AWS CLI w wersji 2.x (ta wersja ma natywną obsługę SSO).
- Wykonaj polecenie aws configure sso.
- Podaj adres swojego AWS SSO Portal i ewentualnie region, w którym masz włączone Identity Center.
- Zaloguj się w przeglądarce, kiedy CLI o to poprosi (otworzy się okno logowania do twojego IdP lub lokalnego directory).
- Po powrocie do CLI wybierz z listy konto i rolę, którą chcesz zapisać w konfiguracji jako profil.
- W celu użycia nowo utworzonego profilu zaloguj się do SSO: aws sso login –profile dev.
- Używaj tego profilu do wykonywania akcji, np. aws s3 ls –profile dev.
- Opcjonalnie wyeksportuj zmienną środowiskową AWS_PROFILE, żeby nie musieć do każdej komendy doklejać profilu.
Gdy twoja sesja wygaśnie (domyślnie po kilku godzinach), wystarczy powtórzyć krok szósty, by odnowić sesję Koniec z długowiecznymi kluczami, koniec z koniecznością ich resetowania – teraz wszystko dzieje się dynamicznie
Uprawnienia przydzielane przez CLI są identyczne z tymi, które użytkownik widzi w konsoli. Nie ma ryzyka, że ktoś przez GUI ma inne prawa niż przez CLI. Dodatkowo, ponieważ każda sesja CLI opiera się na krótkotrwałych tokenach, nawet jeśli ktoś przypadkiem je przechwyci, nie będą one działać wiecznie.
Ten model znakomicie współgra z dobrymi praktykami bezpieczeństwa – nie przechowujesz na stałe w swoim komputerze żadnych długowiecznych kluczy, a do tego możesz łatwo wymuszać wieloskładnikowe uwierzytelnianie (MFA), jeśli zostało włączone w zewnętrznym IdP lub lokalnym directory w Identity Center.
CZAS NA PORZĄDKI
AWS IAM Identity Center to potężne narzędzie ułatwiające i porządkujące zarządzanie dostępem do chmury. Umożliwia rezygnację z przestarzałych, długożyjących kluczy, a dzięki integracji z zewnętrznymi dostawcami tożsamości pozwala w pełni automatyzować przyznawanie i odbieranie uprawnień. Nieważne, czy w twojej organizacji jest jedno konto AWS, czy kilkadziesiąt – dzięki centralizacji i permission setom łatwiej zachować kontrolę nad tym, kto ma wgląd w dane i możliwość modyfikacji zasobów.
Zachęcamy do wypróbowania IAM Identity Center na własną rękę – wystarczy włączyć tę usługę na koncie głównym i postępować według opisanych kroków. Jeśli potrzebujesz pomocy przy konfiguracji lub bardziej złożonych wdrożeniach (np. w integracji z dużym środowiskiem firmowym), możesz też skorzystać ze wsparcia oficjalnych partnerów AWS. Dzięki temu zyskasz pewność, że cały proces przebiegnie sprawnie i bez zbędnych komplikacji.
Dla wielu zespołów to właśnie dobrze zaprojektowane zarządzanie dostępem decyduje o komforcie pracy oraz poczuciu bezpieczeństwa. Niezależnie od tego, czy dopiero zaczynasz przygodę z chmurą, czy masz już bogate doświadczenie w AWS-ie – warto sprawdzić, jak IAM Identity Center może uprościć codzienną pracę i zmniejszyć ryzyko kosztownych błędów konfiguracyjnych.
Autor
Michał Brygidyn
Autor, jako Cloud Security Architect, AWS Community Builder i AWS Ambassador, od lat dba o bezpieczeństwo i „bezobsługowość” organizacji AWS w wielu dużych projektach. Często można spotkać go w roli prelegenta oraz uczestnika na tematycznych konferencjach i meetupach.
