Happy 10th Birthday – AWS Identity and Access Management

Usługa Amazon S3 skończyła 15 lat na początku tego roku, a wkrótce do jej grona dołączy usługa Amazon EC2. Na początku maja obchodziliśmy dziesiąte urodziny AWS Identity and Access Management (IAM).

Pierwsza dekada

Przejdźmy przez ostatnią dekadę i powróćmy do niektórych z najważniejszych premier IAM

Maj 2011 - uruchomiono IAM z możliwością tworzenia użytkowników, grup użytkowników i dołączania dokumentów polityki do jednego z nich, z obsługą piętnastu usług AWS. Generator polityk AWS mógł być użyty do tworzenia polityk od podstaw, był również dostępny niewielki zbiór predefiniowanych szablonów polityk. To ustanowiło standard dla uprawnień IAM, z uprawnieniami fine-grained dla działań i zasobów oraz wykorzystaniem warunków do kontrolowania, kiedy zasada obowiązuje. Ten model skalował się wraz z AWS i pozostaje dziś kluczowym elementem IAM.

Sierpień 2011 - wprowadzono możliwość korzystania z istniejących tożsamości poprzez federację z kontem AWS, w tym obsługę krótkoterminowych tymczasowych poświadczeń AWS.

Czerwiec 2012 - Wraz z wprowadzeniem ról IAM dla instancji EC2, ułatwiono kodowi działającemu na instancji EC2 wykonywanie wywołań usług AWS.

Luty 2015 – uruchomiono zasady Managed Policies i jednocześnie przekształcono istniejące zasady IAM uprawnień w pierwszorzędne obiekty, które można tworzyć, nazywać i wykorzystywać dla wielu użytkowników, grup lub ról uprawnień IAM.

Luty 2017 - uruchomiono AWS Organizations i udostępniono możliwość wdrożenia zarządzania opartego na politykach, które obejmowały wiele kont AWS, pogrupowanych w hierarchię jednostek organizacyjnych (ou). To uruchomienie oznaczało również debiut zasad Service Control Policies (SCP), które dały możliwość umieszczania barier ochronnych wokół poziomu dostępu dozwolonego na kontach organizacji.

Kwiecień 2017 - Opierając się na rolach IAM dla instancji EC2, wprowadzano role typu service-linked (powiązane z usługą). To dało uprawnienia do delegowania uprawnień do usług AWS i ułatwiło pracę z usługami AWS, które musiały wywołać inne usługi AWS w twoim imieniu.

Grudzień 2017 - wprowadzono AWS Single Sign-On, aby ułatwić centralne zarządzanie dostępem do kont AWS i aplikacji biznesowych. SSO jest oparte na uprawnieniach IAM i korzysta z ról , tymczasowych poświadczeń i innych podstawowych funkcji uprawnień IAM.

Listopad 2018 – Wprowadzono kontrolę dostępu opartą na atrybutach Attribute-Based Access Control (ABAC) jako uzupełnienie oryginalnej kontroli dostępu opartej na rolach, aby umożliwić korzystanie z różnych typów atrybutów użytkownika, zasobów i środowiska do podejmowania decyzji dotyczących polityk i uprawnień. To uruchomienie umożliwiło tagowanie użytkowników i ról uprawnień IAM, co umożliwiło dopasowanie atrybutów tożsamości i atrybutów zasobów w zasadach.

Po tym uruchomieniu kontynuowano obsługę korzystania z ABAC w połączeniu z AWS SSO i Cognito.

Grudzień 2019 – wprowadzono IAM Access Analyzer, aby przeanalizować istniejące polityki i określić, do których zasobów można uzyskać dostęp publicznie lub z innych kont.

Marzec 2021 - Dodano walidację polityk (ponad 100 sprawdzeń polityk) i praktyczne zalecenia do IAM Access Analyzer, aby pomóc w tworzeniu polityk IAM i SCP, które wykorzystują sprawdzone w czasie dobre praktyki AWS.

Kwiecień 2021 - Umożliwiono generowanie szablonów polityk IAM o najniższych uprawnieniach na podstawie aktywności związanej z dostępem.

Wtedy i teraz

Na początku typowy klient może używać IAM do kontrolowania dostępu do kilku kontenerów S3, instancji EC2 i kolejek SQS, a wszystko to na jednym koncie AWS. Obecnie niektórzy z naszych klientów używają IAM do kontrolowania dostępu do miliardów obiektów, które obejmują wiele kont AWS!

Ponieważ każde wywołanie interfejsu API AWS musi wywołać IAM w celu sprawdzenia uprawnień, zespół IAM od samego początku skupił się na dostępności i skalowalności. W 2011 roku, funkcja „czy klient może to zrobić?” obsługiwała kilka tysięcy żądań na sekundę. Obecnie, w miarę pojawiania się nowych usług i powiększania się bazy klientów AWS, funkcja ta obsługuje obecnie ponad 400 milionów wywołań API na sekundę na całym świecie.

Jak widać z podsumowania, IAM przeszedł dość długą drogę od swoich prostych, ale potężnych początków zaledwie dziesięć lat temu. Chociaż wiele z tego, co było prawdą dziesięć lat temu, pozostaje prawdą dzisiaj, chcemy zwrócić uwagę na kilka dobrych praktyk, które ewoluowały w czasie.

Wiele kont - pierwotnie klienci na ogół korzystali z jednego konta AWS i wielu użytkowników. Obecnie, aby dostosować się do wielu jednostek biznesowych i obciążeń, AWS zaleca korzystanie z organizacji AWS i wielu kont. Nawet jeśli korzystanie z AWS jest na początku stosunkowo proste i nieskomplikowane, prawdopodobnie zwiększy się skala i złożoność, i zawsze dobrze jest zaplanować to z góry. Aby dowiedzieć się więcej, przeczytaj artykuł Tworzenie dobrej praktyki w środowisku AWS.

Użytkownicy i logowanie SSO - w podobnym duchu AWS zaleca korzystanie z logowania AWS SSO do centralnego tworzenia użytkowników i zarządzania nimi, a następnie przyznawania im dostępu do co najmniej jednego konta AWS. Aby dowiedzieć się więcej, przeczytaj AWS Single Sign-On User Guide.

źródło: AWS