Bezpieczne Zarządzanie Dostępami w AWS

Wersja ENG tutaj

W ostatnim wpisie, który publikowałam tutaj, ujęłam najlepsze praktyki w zakresie bezpieczeństwa, w oparciu o moje doświadczenie związane z przeprowadzaniem AWS Well-Architected Review. W niniejszym artykule chcę się z Wami podzielić, tematem, który wydaje się być tak podstawowy, i tak oczywisty, że czasem sama pomijam pewne składowe, co jest moim błędem. Niedawno, w czasie pewnego nowego “projektu”, w którym miałam okazję i przyjemność wziąć udział, i o którym niedługo powiem coś więcej, sama natknęłam na to, że nie wszystko, nawet dla mnie, jest oczywiste. W czasie spontanicznej rozmowy, odnajduję czasem problem z klarownym wyjaśnieniem dla laika np. na czym polega automatyczna rotacja credential’i w AWS. Z jednej strony czuję się źle, bo przecież zajmuję się bezpieczeństwem, ale z drugiej, mam kolejne punkty, z którymi mogę więcej popracować w praktyce, co przełoży się na większe rozeznanie w temacie, a zatem i większą pewność, że faktycznie pomogę zrozumieć temat innym.

Kto ma dostęp do czego?

Podstawą zarządzania bezpieczeństwem w AWS jest zasada określająca, kto może uzyskać dostęp do czego. Koncepcja ta dzieli się na dwie główne kategorie: „kto” — obejmujący programistów, aplikacje, workload’y i zadania automatyczne, oraz „co” — obejmujące zasoby AWS, takie jak np. zasoby S3, funkcje Lambda. IAM łączy te podmioty poprzez kontrolę dostępu i uprawnienia, definiując i wymuszając, kto może uzyskać dostęp do jakich zasobów i na jakich warunkach.

Klucz bezpieczeństwa

Poniżej odpowiemy sobie na pytanie co jest fundamentem dla budowy wszelkich reguł dotyczących bezpiecznego korzystania z usług AWS, w tym IAM.

Zero Trust

Zasada Zerowego Zaufania, polega na założeniu, że każda próba dostępu może być potencjalnym zagrożeniem, dlatego domyślnie nie ufa się nikomu — ani użytkownikom wewnętrznym, ani zewnętrznym. Zero Trust zwraca uwagę na kilka niezbędnych punktów:

1. Nawet w przypadku gdy wewnętrzna usługa próbuje uzyskać dostęp do innej wewnętrznej usługi, weryfikacja jest wymagana.
2. Uprawnienia dostępu buduj przy założeniu, że każdy dostęp jest potencjalnym naruszeniem bezpieczeństwa.
3. Ogranicz dostęp i uprawnienia tak bardzo, jak to możliwe, nie przeszkadzając przy tym w codziennych pracach użytkowników.

Adoptowanie modelu Zero Trust umożliwia zmniejszenie ryzyka niezamierzonego przyznania dostępu nieautoryzowanym użytkownikom. IAM i strategia Zero Trust doskonale ze sobą współpracują, zapewniając, że polityki i procedury IAM są zawsze przestrzegane, niezależnie od potrzeb dostępu użytkownika.

Zasada Najmniejszych Uprawnień

Zasada ta odnosi się do modelu Zero Trust i polega na ograniczeniu dostępu i uprawnień tak bardzo, jak to możliwe, bez zakłócania normalnej pracy użytkowników.

W celu zapewnienia bezpieczeństwa, należy przydzielać użytkownikom i rolom wyłącznie niezbędne minimalne uprawnienia potrzebne do wykonania ich zadań, dlatego polityki IAM powinny być projektowane z myślą o ograniczaniu dostępu do absolutnego minimum, z opcją rozszerzania uprawnień w razie potrzeby. Proces ten wymaga definiowania, audytowania i dostosowywania uprawnień, aby zminimalizować ryzyko nadmiernego dostępu.

AWS Identity and Access Management (IAM)

Podstawowa usługa AWS, ściśle związana z bezpieczeństwem w środowisku chmurowym. Usługa ta umożliwia granularne zarządzanie dostępem do usług i wszelkich zasobów AWS. Tożsamości IAM, czyli użytkownicy, grupy użytkowników, role, zapewniają kontrolę nad tym, kto jest autoryzowany do wykonywania działań w kontach AWS. Poniżej po krótce przedstawiam jak wygląda podział w zakresie wspomnianych tożsamości.

Główny użytkownik AWS (root)

Po utworzeniu konta AWS zaczynamy od jednej tożsamości logowania — “root” — , która ma pełny dostęp do wszystkich usług i zasobów AWS na danym koncie. Jest to tzw. główny użytkownik konta AWS, do którego dostęp uzyskuje się, logując się przy użyciu adresu e-mail i hasła użytych do założenia konta (zaleca się używać również wieloskładnikowe uwierzytelnianie — MFA). Konto root nie powinno być używane do codziennych zadań. Należy zabezpieczyć jego dane logowania i używać wyłącznie do zadań, które wymagają najwyższych uprawnień.

Użytkownicy IAM

Użytkownik IAM to tożsamość z określonymi uprawnieniami dla jednej osoby lub aplikacji. Lepszą praktyką jest korzystanie z tymczasowych poświadczeń (poświadczenia te mogą mieć bardziej ograniczony zestaw uprawnień niż standardowe poświadczenia użytkownika IAM i automatycznie wygasają po określonym czasie), zamiast tworzenia użytkowników IAM z długoterminowymi poświadczeniami, takimi jak hasła i klucze dostępu. Jeżeli już tworzymy użytkowników IAM, mogą być oni dodawani do tzw. grup IAM, co ułatwia zarządzanie uprawnieniami dla wielu użytkowników jednocześnie.

Root & użytkownik IAM

• Użytkownik Root
  Jak wspomniałam wyżej, poświadczenia użytkownika root umożliwiają pełny dostęp do wszystkich zasobów i usług w koncie AWS, w związku z czym nie można ograniczyć dostępu głównego użytkownika za pomocą zasad IAM. Jedynym rozwiązaniem są polityki kontroli usług AWS Organizations, które mogą nałożyć pewne ograniczenia na użytkownika root.
• Użytkownik IAM
  Użytkownicy IAM to tożsamości utworzone w ramach konta AWS, które reprezentują osoby lub usługi współdziałające z zasobami AWS. Mogą mieć oni przydzielone specyficzne uprawnienia dostosowane do ich roli i potrzeb, ograniczając tym samym zakres dostępu do zasobów AWS. Użytkownicy IAM mogą posiadać długoterminowe poświadczenia, takie jak nazwa użytkownika i hasło lub klucze dostępu, które umożliwiają im dostęp do konsoli AWS, AWS CLI lub poprzez wykorzystanie interfejsów API AWS.

Kluczowe Różnice
1. Konto root ma dostęp do wszystkich zasobów i usług w koncie AWS, podczas gdy uprawnienia użytkownika IAM można szczegółowo dostosować.
2. Poświadczenia root powinny być używane tylko do wybranych zadań zarządzania kontem i usługami, które wymagają najwyższego poziomu uprawnień, z kolei użytkownicy IAM są zalecani do codziennego dostępu do zasobów AWS, umożliwiając ograniczenie uprawnień do niezbędnego minimum.
3. Najlepsze praktyki bezpieczeństwa mówią, aby zabezpieczać poświadczenia konta root i stosować dodatkowe środki ochrony jak MFA. Użytkownikom IAM również można (i należy) stosować polityki bezpieczeństwa, w tym MFA.

Grupy użytkowników IAM

Grupa IAM to tożsamość określająca zbiór użytkowników IAM. Grupy nie mogą być używane do logowania, ale umożliwiają określenie uprawnień dla wielu użytkowników naraz, co ułatwia zarządzanie uprawnieniami dla zbiorów użytkowników jak np. developerzy.

Role IAM

Rola IAM to kolejna tożsamość z określonymi uprawnieniami, podobna do użytkownika IAM, lecz nieprzypisana do konkretnej osoby. Ten rodzaj tożsamości z tymczasowymi poświadczeniami jest używany w sytuacjach, takich jak dostęp użytkowników federacyjnych, tymczasowe uprawnienia użytkowników IAM, dostęp międzykontowy, czy dostęp między usługami. Więcej na temat wymienionych przypadków sytuacji możesz znaleźć tutaj.

Kluczową praktyką w zarządzaniu dostępem w środowisku AWS jest używanie ról do delegowania uprawnień. Zamiast umieszczania kluczy dostępu w kodzie lub instancjach, rekomenduje się wykorzystanie ról IAM i generowanie tymczasowych poświadczeń bezpieczeństwa, co pozwala na przejmowanie roli IAM za pomocą operacji AWS Security Token Service (STS) lub poprzez przełączenie się na rolę w konsoli AWS, co jest znacznie bezpieczniejsze niż używanie długoterminowych haseł czy kluczy dostępu. Aplikacje działające na instancjach AWS EC2, które potrzebują dostępu do innych usług AWS, na przykład do zapisu i odczytu danych w Amazon S3, powinny również korzystać z ról IAM. Dzięki temu unika się problemu związanego z bezpieczną dystrybucją i zarządzaniem poświadczeniami na każdej instancji, eliminując potrzebę tworzenia użytkowników IAM z kluczami dostępu.

Inaczej mówiąc, rola to jednostka, która posiada własny, specyficzny zestaw uprawnień, jednak nie jest ani zdefiniowanym użytkownikiem, ani grupą użytkowników. W odróżnieniu od użytkowników IAM, role nie posiadają stałego zestawu poświadczeń. Zamiast tego, usługa Amazon EC2 zapewnia instancjom tymczasowe poświadczenia, które są automatycznie odnawiane, co zwiększa bezpieczeństwo i ułatwia zarządzanie.

Koncept AWS IAM

Polityki

AWS IAM obejmuje kilka rodzajów polityk, tym samym umożliwiając szczegółowe kontrolowanie dostępu użytkowników, grup i ról do zasobów AWS.

Polityki zarządzane przez AWS

Dla użytkowników nowych w AWS, rozważenie użycia predefiniowanych polityk zarządzanych przez AWS jest wygodnym rozwiązaniem. Te polityki pokrywają powszechne przypadki użycia i są dostosowane do typowych funkcji IT, a także są automatycznie aktualizowane przy wprowadzaniu nowych usług lub API przez AWS. Należy jednak pamiętać, że polityki zarządzane przez AWS nie gwarantują zasady najmniejszych uprawnień, co może stanowić ryzyko bezpieczeństwa.

Polityki wbudowane (inline)

Najlepszą praktyką jest stosowanie zasady najmniejszych uprawnień przez tworzenie własnych polityk zarządzanych przez klienta. Pozwalają one na precyzyjne określenie niezbędnych uprawnień dla grup użytkowników, oferując jednocześnie funkcje takie jak wielokrotne użycie, centralne zarządzanie zmianami, wersjonowanie i zarządzanie uprawnieniami delegowanymi. Polityki wbudowane są używane, w przypadku kiedy występuje ścisła relacja między polityką a przypisaną do niej tożsamością, co zapobiega przypadkowemu przydzieleniu uprawnień niewłaściwej tożsamości.

Najlepsze praktyki

W tej części skupimy się na przedstawieniu najlepszych praktyk w zakresie zarządzania dostępami w środowisku AWS.

1. Zalecenia dla polityk IAM

• Definiowanie warunków w politykach IAM pozwala na większą kontrolę nad dostępem, np. ograniczając dostęp do zasobów z określonych zakresów IP lub wymagając uwierzytelnienia MFA do wykonania określonych działań. Jednak lepiej unikać nadmiernego komplikowania polityk :)
• Należy weryfikować zarówno składnię pliku JSON który definiuje politykę, jak i ich logikę. W tym celu przydatne może być narzędzie IAM Access Analyzer, które pomaga w ocenie polityk i sugeruje zmiany, aby ograniczyć nadmiernie szerokie uprawnienia.
• Używając analizy aktywności zarejestrowanej przez AWS CloudTrail, można generować szablony polityk, które odzwierciedlają faktycznie używane uprawnienia, co ułatwia dostosowanie ich do zasady najmniejszych uprawnień.
• Regularna rewizja polityk IAM, z uwzględnieniem przypisanych poziomów dostępu (List, Read, Write, Permissions management, Tagging) dla każdej akcji w usłudze, jest kluczowa dla utrzymania bezpieczeństwa konta AWS.

2. Centralizacja IAM

• Używaj oddzielnych kont AWS dla różnych środowisk (np. development, testowe, produkcyjne) dla maksymalnego oddzielenia zasobów i uprawnień. AWS IAM Identity Center dostarcza centralny zestaw tożsamości, dostęp do kont w całej organizacji AWS, połączenie z istniejącym dostawcą tożsamości, tymczasowe poświadczenia, MFA oraz jednokrotne logowanie do wszystkich uprawnień kont AWS.
• Deleguj dostęp do zasobów między kontami AWS, tworząc role w jednym koncie i umożliwiając użytkownikom z innego konta przyjmowanie tych ról, aby uniknąć niepotrzebnego powtarzania definicji użytkowników, ról i polityk.

3. Rola IAM zamiast użytkownika IAM

Role IAM powinny być używane dla aplikacji działających na instancjach Amazon EC2, które wykonują żądania do AWS, aplikacje mobilne wykonujące żądania do AWS, lub gdy użytkownicy w firmie są uwierzytelniani w korporacyjnej sieci i chcą korzystać z AWS bez konieczności ponownego logowania.

Zatem kiedy i po co tworzyć użytkowników IAM zamiast roli? Tworzenie użytkowników IAM jest zalecane tylko w przypadkach, które nie są obsługiwane przez użytkowników federacyjnych. Do takich przypadków mogą należeć workload’y, które nie mogą korzystać z ról IAM, klientów zewnętrznych AWS nieobsługujących dostępu przez IAM Identity Center, dostępu do AWS CodeCommit oraz, w określonych przypadkach, dostępu do Amazon Keyspaces (dla Apache Cassandra).

4. Nie korzystaj z konta root

• Konto root powinno być używany wyłącznie do tworzenia administratora IAM. Poświadczenia użytkownika root należy bezpiecznie przechowywać i używać tylko w sytuacjach wyjątkowych, o czym pisałam wyżej.
• Usuń klucz dostępu użytkownika root lub stosuj regularną rotacje kluczy dostępowych, jeśli decydujesz się je zachować.

5. Wieloskładnikowe uwierzytelnianie (MFA)

Włączenie MFA dla wszystkich użytkowników w celu dodatkowego zabezpieczenia konta AWS, nawet w przypadku złamania hasła lub kluczy dostępu.

6. Poświadczenia bezpieczeństwa

• Implementuj niestandardową politykę haseł wymagającą od użytkowników tworzenia silnych/bardziej skomplikowanych haseł i ich regularnej rotacji.
• Usuwaj hasła i klucze dostępu IAM, których nie używasz, oraz poświadczenia użytkowników, którzy nie potrzebują dostępu do konsoli lub używają tylko konsoli.
• Regularnie zmieniaj hasła i klucze dostępu nie tylko dla użytkowników IAM, ale również dla usług AWS.

Aby podnieść poziom bezpieczeństwa, zaleca się implementację automatyzacji rotacji poświadczeń bezpieczeństwa za pomocą integracji AWS IAM, AWS Secrets Manager, AWS Lambda oraz AWS CloudTrail. AWS IAM umożliwia precyzyjne zarządzanie tożsamościami użytkowników oraz ich kluczami dostępu, oferując kontrolę nad uprawnieniami i dostępem do zasobów AWS. AWS Secrets Manager jest kluczowym komponentem w tej architekturze, dostarczając rozwiązania do bezpiecznego przechowywania kluczy dostępu, tajnych danych oraz automatyzacji ich rotacji. Mechanizm automatyzacji rotacji wykorzystuje funkcje AWS Lambda do generowania nowych kluczy dostępu i aktualizacji przechowywanych sekretów w Secrets Manager według zaplanowanego harmonogramu. Działanie to umożliwia aplikacjom bezproblemowe korzystanie z aktualnych i bezpiecznych poświadczeń, minimalizując ryzyko związane z potencjalnym wykorzystaniem przestarzałych lub skompromitowanych kluczy. Dodatkowo, AWS CloudTrail pełni funkcję audytową, rejestrując wszelkie operacje wykonane na poświadczeniach, co zapewnia dodatkową warstwę kontroli i możliwość weryfikacji zgodności z politykami bezpieczeństwa. Monitorowanie to pozwala na szybką identyfikację i reagowanie na wszelkie nieautoryzowane lub podejrzane działania w środowisku AWS.

Wprowadzenie opisanego rozwiązania nie tylko zwiększa bezpieczeństwo przez zapewnienie ciągłej rotacji poświadczeń, ale również redukuje złożoność zarządzania nimi, automatyzując procesy wymagające dotąd ręcznej interwencji. Jest to szczególnie istotne w dynamicznie zmieniających się środowiskach chmurowym, gdzie szybkość i automatyzacja procesów bezpieczeństwa są kluczowe dla utrzymania wysokiego poziomu ochrony danych i zasobów.

7. Automatyzacja

Zamiast ręcznego zarządzania zasobami IAM przez konsolę AWS lepiej jest używać narzędzi do automatyzacji, takich jak Terraform czy CloudFormation, w celu minimalizacji ryzyka błędów ludzkich i ułatwienia przeprowadzania audytów oraz raportowania dla wymogów zgodności.

Przykładowe przypadki użycia dla AWS IAM

1. Tworzenie i zarządzanie tożsamościami użytkowników, zarządzanie ich uprawnieniami dostępu do zasobów AWS.
2. Przydzielanie uprawnień do zasobów AWS dla aplikacji i usług bez potrzeby hardkodowania kluczy dostępu w kodzie aplikacji.
3. Delegowanie uprawnień użytkownikom, aplikacjom lub usługom za pomocą ról IAM bez konieczności udostępniania kluczy dostępu.
4. Ograniczanie dostępu użytkowników i usług do absolutnego minimum, które jest potrzebne do wykonania ich zadań.
5. Integracja z zewnętrznymi systemami uwierzytelniania, takimi jak Active Directory lub dostawcy tożsamości OpenID Connect, aby umożliwić użytkownikom korzystanie z istniejących poświadczeń do uzyskiwania dostępu do zasobów AWS.
6. Wzmocnienie bezpieczeństwa poprzez wymaganie od użytkowników dodatkowej formy uwierzytelnienia oprócz hasła.
7. Używanie AWS CloudTrail i innych narzędzi do monitorowania i rejestrowania działań związanych z IAM w celu audytu i zgodności.
8. Automatyzacja tworzenia i zarządzania użytkownikami, grupami, rolami i politykami IAM za pomocą infrastruktury jako kod (IaC) i AWS CLI lub SDK.
9. Tworzenie zaawansowanych polityk dostępu, które ograniczają dostęp na podstawie różnych warunków, takich jak adres IP, godzina dnia czy uwierzytelnianie MFA.
10. Systematyczna rotacja kluczy dostępu IAM i certyfikatów, aby zmniejszyć ryzyko kompromitacji.

Podsumowanie

W tym wpisie poruszyłam kwestię, która może wydawać się oczywista, ale często jest pomijana — podstawy zarządzania bezpieczeństwem w AWS. W kolejnym wpisie postaram się przybliżyć temat kolejnych usług z zakresu bezpieczeństwa, a tym czasem, zachęcam do ciągłej nauki i dostosowywania praktyk bezpieczeństwa, aby skutecznie zarządzać dostępem i zabezpieczeniami w Waszym środowisku chmurowym.