Role między kontami i zasady zasobów

Rzeczywiste architektury obejmują wiele kont: konto produkcyjne, konto rejestrowania i konto usług współdzielonych. Obciążenia i ludzie często muszą uzyskiwać dostęp do zasobów między tymi granicami.

Bezpieczne rozwiązanie nigdy nie polega na kopiowaniu danych uwierzytelniających między kontami. Zamiast tego należy przyznać ograniczony dostęp za pomocą ról międzykontowych lub zasad opartych na zasobach.

Najczęstszy wzorzec polega na umieszczeniu roli na koncie docelowym, którą przyjmuje podmiot z konta źródłowego.

• Zasada zaufania roli wskazuje konto źródłowe lub podmiot.
• Podmiot źródłowy wywołuje AssumeRole i otrzymuje tymczasowe dane uwierzytelniające.
• Następnie działa na koncie docelowym w zakresie uprawnień roli.

Przyjęcie roli między kontami wymaga, aby obie strony na to zezwalały:

• Zasada zaufania roli docelowej zezwala podmiotowi źródłowemu.
• Zasada tożsamości podmiotu źródłowego zezwala na sts:AssumeRole dla tej roli.

Jeśli którejkolwiek zasady brakuje, przyjęcie roli kończy się niepowodzeniem. To podwójne sprawdzenie jest częstym zagadnieniem egzaminacyjnym.

Niektóre usługi obsługują zasady oparte na zasobach, dołączane bezpośrednio do zasobu, takie jak zasada zasobnika S3, zasada klucza KMS lub zasada kolejki SQS.

Mogą one przyznać dostęp podmiotowi z innego konta bez przyjmowania przez ten podmiot roli. Zewnętrzne konto używa własnej tożsamości, a zasada zasobu autoryzuje ten dostęp.

Mechanizm należy wybrać zależnie od usługi:

• W przypadku usług bez zasady zasobu (EC2, większość interfejsów API) należy użyć roli międzykontowej.
• W przypadku S3, KMS, SNS, SQS, Lambda i innych usług zasada zasobu może przyznać bezpośredni dostęp między kontami.

Zasady zasobów pozwalają uniknąć dodatkowego wywołania AssumeRole.

Przy przyznawaniu zewnętrznej stronie (np. dostawcy SaaS) dostępu między kontami należy dodać warunek external ID do zasady zaufania.

Dostawca musi przekazać unikatową tajną wartość podczas przyjmowania roli. Blokuje to problem zdezorientowanego zastępcy, w którym atakujący nakłania dostawcę do uzyskania dostępu do konta niewłaściwego klienta.

Role międzykontowe powinny przyznawać minimum niezbędne do działania, ograniczone do konkretnych zasobów i działań.

Częstym błędem jest szerokie zaufanie do całego zewnętrznego konta połączone z uprawnieniami administratora. Należy zawęzić zaufanie do konkretnej roli lub użytkownika, a uprawnienia do dokładnie określonego zadania.

Częsty projekt centralizuje funkcję na jednym koncie, do którego inne konta uzyskują dostęp za pomocą ról, na przykład konto bezpieczeństwa przyjmujące role tylko do odczytu na każdym koncie obciążenia.

Każde konto obciążenia zawiera rolę o identycznej nazwie, ufającą kontu bezpieczeństwa, dzięki czemu narzędzia mogą jednolicie skanować wszystkie konta.

AWS Resource Access Manager (RAM) udostępnia określone zasoby, takie jak podsieci lub bramy Transit Gateway, między kontami w organizacji.

RAM służy do udostępniania samego zasobu, a nie do przyznawania uprawnień API umożliwiających działanie na nim. Uzupełnia role i zasady zasobów w zakresie udostępniania sieci i infrastruktury.

Dostęp między kontami poszerza obszar zaufania, dlatego należy regularnie go audytować.

• CloudTrail rejestruje każde AssumeRole i każde wywołanie API między kontami.
• IAM Access Analyzer oznacza zasady zasobów przyznające dostęp spoza Państwa konta.

Należy je przeglądać, aby wcześnie wykrywać niezamierzone udostępnianie.

Aby bezpiecznie łączyć konta, należy preferować role dla obliczeń i interfejsów API, zasady zasobów dla usług przechowywania i przesyłania komunikatów oraz zawsze stosować najmniejsze uprawnienia i external ID w przypadku zewnętrznych stron.

Nigdy nie należy udostępniać długoterminowych kluczy między kontami.

Proszę przeanalizować dostęp między kontami.

Nauczyli się Państwo, jak bezpiecznie łączyć konta.

• Role międzykontowe wymagają zarówno zasady zaufania, jak i źródłowej zasady tożsamości.
• Zasady oparte na zasobach przyznają bezpośredni dostęp w usługach takich jak S3 i KMS.
• W przypadku zewnętrznych stron należy używać external ID, a audyty przeprowadzać za pomocą Access Analyzer i CloudTrail.