Zapraszam Cię do lektury kolejnego wpisu z serii Cloud Governance. Tym razem skupimy się na aspektach zarządzania tożsamością w chmurze AWS.
Przyjrzymy się w jaki sposób możemy zarządzać użytkownikami oraz ich uprawnieniami. Dodatkowo spróbuję pokazać Ci jak można do tego podejść zaczynając od jednego kont AWS, przechodząc dalej gdy ich ilość zaczyna rosnąć.
Jeśli zastanawiasz się czy warto używać więcej niż jednego konta, to zapraszam Cie do artykuły gdzie znajdziesz odpowiedź „Czy jedno konto AWS to nie za mało?„.
Dostęp do konta AWS
Zaczynasz przygodę z AWS, zakładasz swoje pierwsze konto AWS. Masz login ( w postaci adresu email i hasło). Czas zatem odpalić pierwszą usługę!
Zaraz, zaraz, tylko czy praca na koncie root (to konto z loginem jako email adres) jest bezpieczna?
No właśnie, to temat o którym przypominam na każdym razem.
Zasady pracy z AWS:
- Nie używaj na codzień konta root.
- Patrz punkt nr 1.
Tak więc przejdzmy do konkretów….
Zarządzanie jednym kontem AWS
Jeśli na początku masz tylko jeden konto, to sprawa jest dość prosta.
W AWS znajdziesz taką usługę jak Identity and Access Management (IAM), która służy do zarządzania dostępami i uprawnieniami w ramach pojedynczego konta AWS.
Dlatego pierwszym krokiem po założeniu konta AWS jest przejście do tej usługi i założenie użytkownika (tzw. IAM User), którego będziesz używać na codzień do pracy z AWS.
Podstawowe właściwości tej usługi to:
- Zarządzanie użytkownikami,
- Konfiguracją grup i przynależności użytkowników,
- Zarządzanie uprawnieniami z wykorzystaniem IAM Policies,
- Zarządzaniem dostępami uprawnieniami pomiędzy usługami,
- Polityka haseł itp.
Podsumowując, jeśli pracujesz na jednym koncie AWS, to wykorzystaj te usługę do zarządzani wszystkimi dostępami i uprawnieniami do Twoich zasobów.
Cross-Account Access
Co jednak, gdy używamy więcej kont AWS. Powiedzmy, że jest sytuacja, w której mam dwa konta: Developerskie i Produkcyjne.
Potrzebujemy, aby użytkownicy z konta Developerskiego mogli dostać się do zasobów lub dokonać konfiguracji na koncie Produkcyjnym.
Mamy tutaj dwie możliwości:
OPCJA 1 – Stworzyć dodatkowego IAM User na koncie produkcyjnym.
Metoda ta ma jednak pewne wady.
Po pierwsze pracownik ma teraz dwa loginy, dwa hasła (lub nawet więcej jeśli kont AWS będzie więcej).
Po drugie z punktu widzenia administracyjnego wraz ze wzrostem ilości konta pomnaża się ilość pracy związanej z zarządzaniem użytkownikami i kontami.
Do tego dochodzą dodatkowe ID kont, URL do konsoli itp.
OPCJA 2 – wykorzystać opcje dostępu tzw. Cross-Account Access.
Jak to działa? Wrócmy do naszego scenariusza, dwa konta, Developerskie i Produkcyjne.
Na końcie developerskim mamy zespół użytkowników, każdy ma własnego IAM Usera, powiązanego z IAM Group – Developers.
Teraz zespół ten potrzebuje dostać się do zasobów znajdujących się na końcie Produkcyjnym.
W tym celu na końcie Produkcyjnym utworzona została IAM Role, dzięki, której zespół developerów będzie mógł „przełączyć” się na konto Produkcyjne.
IAM Role powiązana jest z odpowiednimi uprawnieniami, zgodnie z tym co jest potrzebne zespołowi do wykonania swojej pracy.
Zatem, pozostaje nam jeden login, więcej kont. Ale nadal konfiguracja odpowiednich IAM Roli, pamiętanie nazw itp.
Szczegóły tego jak skonfigurować taki dostęp znajdziesz TUTAJ
AWS Single Sing-On
Idziemy teraz dalej, a co gdy kont w naszej organizacji ciągle przybywa?
Pojawiają się tutaj wyzwania związane, tworzeniem odpowiednich IAM ROLE na każdym z kont, użytkownicy muszą pamiętać ID kont AWS, nazwy IAM Roli jakie są z nimi powiązane.
Część konfiguracji potwarzalnej możemy oczywiście automatyzować. Użytkownicy mogą instalować dodatkowe wtyczki do przeglądarki aby zarządzać skrótami do przełączania się miedzy kontami.
Ja kiedyś popełniłem taką „ala” konsolę z linkami do konto roli AWS (console.lukado.eu), gdzie agregowałem wszystkie potrzebne URL’e.
Czyli nadal zarządzanie dostępami jest mocno rozproszone.
Na szczęście można to zrobić jeszcze inaczej….
W AWS jest usługa AWS Single Sing-ON, która jak sama nazwa wskazuje, zapewnia SSO dla różnych aplikacji w tym też własnie kont AWS, którymi zarządzamy w ramach naszej organizacji.
Usługa pozwala nam:
- Zarządzać aplikacjami, do których będzie dostęp (w tym kontami AWS),
- Tworzyć użytkowników i grupy ( w wariańcie gdy AWS SSO ma własny katalog użytkowników),
- Nadawać odpowiednie uprawnienia,
- Integrować się z zewnętrznymi Identity Providerami,
Dla przykładu jeśli używasz Microsoft365, gdzie jednocześnie Azure AD jest katalogem użytkowników, to możesz to powiązać z AWS SSO. Wtedy użytkownicy i grupy „spływają” z zewnętrznego Identity, a w AWS SSO nadajesz uprawnienia do odpowiednich kont AWS, lub też innych aplikacji.
Więcej na ten temat znajdziesz TUTAJ
Ale nasza firma korzysta już z ADFS
Duże organizacje, często mają już wdrożone mechanizmy dostępów do wewnętrznych systemów, np w oparciu o ADFS/
W chwili, gdy taka organizacja planuje wdrożyć rozwiązania chmurowe natychmiast pojawia się pytanie, a co z zarządzaniem dostępami, czy można to z integrować?
Tutaj oczywiście nie ma żadnego problemy aby pracownicy firmy logowali się od AWS właśnie z wykorzystaniem np. wspomnianego już ADFS.
Wymagane jest tylko przygotowanie odpowiedniej integracji.
Więcej na temat tego jak to zrobić znajdziesz TUTAJ
Pamietaj, że te wszystkie elementy możemy w pełni zautomatyzować. Chodzi tu głównie o konfigurację i spięcie z ADFS dla każdego nowego konta AWS jakie powstaje w ramach naszej organizacji.
W tym celu możemy skorzystać chociażby z usługi AWS CloudFormation.
Dzięki AWS Organization i CloudFormation StackSets możemy przygotować całą bazową konfigurację (np. konfigurację ról i ADFS jako Identity Providera) i wdrażać ją na każde nowe konto.
PODSUMOWANE
W zależności od modelu działania, skali i wymogów naszej organizacji do wyboru jest kilka rozwiązań.
ZAPAMIETAJ, nie używaj konta głównego „root” do pracy z AWS…
A dalej wybieraj rozwiązania spełniające Twoje potrzeby.
JEDNO KONTO – usługa IAM i każdy pracownik ma swojego IAM User’a.
WIĘCEJ KONTO – usługa IAM i Cross Account Access, lub AWS SSO,
Integracja z ADFS lub innym prowiderem – również jak najbardziej do zrobienia, kwestia tylko odpowiedniej konfiguracji.
Artykuł oryginalnie ukazał się na blogu https://welastic.pl/blog
Zbuduje swoje bezpieczne środowisko AWS.
