AWS - Basic Information

Hierarchia organizacji

Konta

W AWS istnieje konto główne, które jest rodzicem dla wszystkich kont w twojej organizacji. Jednak nie musisz używać tego konta do wdrażania zasobów, możesz stworzyć inne konta, aby oddzielić różne infrastruktury AWS między sobą.

Jest to bardzo interesujące z punktu widzenia bezpieczeństwa, ponieważ jedno konto nie będzie mogło uzyskać dostępu do zasobów innego konta (chyba że specjalnie utworzone są mosty), dzięki czemu możesz stworzyć granice między wdrożeniami.

Dlatego w organizacji istnieją dwa typy kont (mówimy o kontach AWS, a nie kontach użytkowników): jedno konto, które jest wyznaczone jako konto zarządzające, oraz jedno lub więcej kont członkowskich.

• Konto zarządzające (konto główne) to konto, którego używasz do tworzenia organizacji. Z konta zarządzającego organizacją możesz zrobić następujące rzeczy:

• Tworzyć konta w organizacji

• Zapraszać inne istniejące konta do organizacji

• Usuwać konta z organizacji

• Zarządzać zaproszeniami

• Stosować polityki do podmiotów (korzeni, OU lub kont) w organizacji

• Włączyć integrację z obsługiwanymi usługami AWS, aby zapewnić funkcjonalność usług we wszystkich kontach w organizacji.

• Możliwe jest zalogowanie się jako użytkownik główny, używając adresu e-mail i hasła użytego do utworzenia tego konta głównego/organizacji.

Konto zarządzające ma odpowiedzialności konta płatnika i jest odpowiedzialne za opłacanie wszystkich opłat, które są naliczane przez konta członkowskie. Nie możesz zmienić konta zarządzającego organizacją.

• Konta członkowskie składają się z pozostałych kont w organizacji. Konto może być członkiem tylko jednej organizacji w danym czasie. Możesz przypisać politykę do konta, aby zastosować kontrole tylko do tego jednego konta.

• Konta członkowskie muszą używać ważnego adresu e-mail i mogą mieć nazwę, generalnie nie będą mogły zarządzać rozliczeniami (ale mogą otrzymać do nich dostęp).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Jednostki Organizacyjne

Konta mogą być grupowane w Jednostki Organizacyjne (OU). W ten sposób możesz tworzyć polityki dla Jednostki Organizacyjnej, które będą stosowane do wszystkich kont podrzędnych. Zauważ, że OU może mieć inne OU jako dzieci.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

Polityka kontroli usług (SCP) to polityka, która określa usługi i działania, które użytkownicy i role mogą wykorzystywać w kontach, na które wpływa SCP. SCP są podobne do polityk uprawnień IAM, z tym że nie przyznają żadnych uprawnień. Zamiast tego, SCP określają maksymalne uprawnienia dla organizacji, jednostki organizacyjnej (OU) lub konta. Gdy dołączysz SCP do korzenia swojej organizacji lub OU, SCP ogranicza uprawnienia dla podmiotów w kontach członkowskich.

To jest JEDYNY sposób, aby nawet użytkownik root mógł być powstrzymany przed zrobieniem czegoś. Na przykład, może być użyty do powstrzymania użytkowników przed wyłączaniem CloudTrail lub usuwaniem kopii zapasowych. Jedynym sposobem na obejście tego jest również skompromitowanie konta głównego, które konfiguruje SCP (konto główne nie może być zablokowane).

Przykłady SCP:

• Całkowicie odmówić kontu root

• Zezwolić tylko na określone regiony

• Zezwolić tylko na usługi z białej listy

• Odmówić wyłączenia GuardDuty, CloudTrail i S3 Public Block Access

• Odmówić usunięcia lub modyfikacji ról odpowiedzialności za bezpieczeństwo/incydenty.

• Odmówić usunięcia kopii zapasowych.

• Odmówić tworzenia użytkowników IAM i kluczy dostępu

Znajdź przykłady JSON w https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name to unikalna nazwa, którą ma każdy zasób w AWS, składa się z tego:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Zauważ, że w AWS są 4 partycje, ale tylko 3 sposoby ich nazywania:

• AWS Standard: aws

• AWS China: aws-cn

• AWS US public Internet (GovCloud): aws-us-gov

• AWS Secret (US Classified): aws

IAM - Zarządzanie Tożsamością i Dostępem

IAM to usługa, która pozwala zarządzać Uwierzytelnianiem, Autoryzacją i Kontrolą Dostępu w Twoim koncie AWS.

• Uwierzytelnianie - Proces definiowania tożsamości i weryfikacji tej tożsamości. Proces ten można podzielić na: Identyfikację i weryfikację.

• Autoryzacja - Określa, do czego tożsamość ma dostęp w systemie po jej uwierzytelnieniu.

• Kontrola Dostępu - Metoda i proces, w jaki sposób przyznawany jest dostęp do zabezpieczonego zasobu.

IAM można zdefiniować przez jego zdolność do zarządzania, kontrolowania i regulowania mechanizmów uwierzytelniania, autoryzacji i kontroli dostępu tożsamości do Twoich zasobów w Twoim koncie AWS.

Użytkownik główny konta AWS

Kiedy po raz pierwszy tworzysz konto Amazon Web Services (AWS), zaczynasz od pojedynczej tożsamości logowania, która ma pełny dostęp do wszystkich usług i zasobów AWS w koncie. To jest główny użytkownik konta AWS i uzyskuje się do niego dostęp, logując się za pomocą adresu e-mail i hasła, które użyłeś do utworzenia konta.

Zauważ, że nowy użytkownik admina będzie miał mniej uprawnień niż użytkownik główny.

Z punktu widzenia bezpieczeństwa zaleca się tworzenie innych użytkowników i unikanie korzystania z tego.

Użytkownicy IAM

Użytkownik IAM to podmiot, który tworzysz w AWS, aby reprezentować osobę lub aplikację, która używa go do interakcji z AWS. Użytkownik w AWS składa się z nazwy i poświadczeń (hasło i do dwóch kluczy dostępu).

Kiedy tworzysz użytkownika IAM, przyznajesz mu uprawnienia, czyniąc go członkiem grupy użytkowników, która ma odpowiednie polityki uprawnień (zalecane), lub bezpośrednio przypisując polityki do użytkownika.

Użytkownicy mogą mieć włączone MFA do logowania przez konsolę. Tokeny API użytkowników z włączonym MFA nie są chronione przez MFA. Jeśli chcesz ograniczyć dostęp kluczy API użytkowników za pomocą MFA, musisz wskazać w polityce, że aby wykonać określone działania, MFA musi być obecne (przykład tutaj).

CLI

• ID klucza dostępu: 20 losowych wielkich liter alfanumerycznych, takich jak AKHDNAPO86BSHKDIRYT

• ID tajnego klucza dostępu: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie ma możliwości odzyskania utraconych ID tajnych kluczy dostępu).

Kiedy musisz zmienić klucz dostępu, powinieneś postępować według tego procesu: Utwórz nowy klucz dostępu -> Zastosuj nowy klucz do systemu/aplikacji -> oznacz oryginalny jako nieaktywny -> Przetestuj i zweryfikuj, że nowy klucz dostępu działa -> Usuń stary klucz dostępu

MFA - Uwierzytelnianie wieloskładnikowe

Jest używane do tworzenia dodatkowego czynnika uwierzytelniania oprócz istniejących metod, takich jak hasło, tworząc w ten sposób wieloskładnikowy poziom uwierzytelniania. Możesz użyć darmowej aplikacji wirtualnej lub fizycznego urządzenia. Możesz używać aplikacji takich jak Google Authenticator za darmo, aby aktywować MFA w AWS.

Polityki z warunkami MFA mogą być przypisane do następujących:

• Użytkownika lub grupy IAM

• Zasobu, takiego jak koszyk Amazon S3, kolejka Amazon SQS lub temat Amazon SNS

• Polityki zaufania roli IAM, która może być przyjęta przez użytkownika

Jeśli chcesz uzyskać dostęp przez CLI do zasobu, który sprawdza MFA, musisz wywołać GetSessionToken. To da ci token z informacjami o MFA. Zauważ, że poświadczenia AssumeRole nie zawierają tych informacji.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

As stated here, istnieje wiele różnych przypadków, w których MFA nie może być używane.

Grupy użytkowników IAM

Grupa użytkowników IAM to sposób na przypisanie polityk do wielu użytkowników jednocześnie, co może ułatwić zarządzanie uprawnieniami tych użytkowników. Role i grupy nie mogą być częścią grupy.

Możesz przypisać politykę opartą na tożsamości do grupy użytkowników, aby wszyscy użytkownicy w grupie użytkowników otrzymali uprawnienia polityki. Nie możesz zidentyfikować grupy użytkowników jako Principal w polityce (takiej jak polityka oparta na zasobach), ponieważ grupy odnoszą się do uprawnień, a nie do uwierzytelniania, a podmioty są uwierzytelnionymi jednostkami IAM.

Oto kilka ważnych cech grup użytkowników:

• Grupa użytkowników może zawierać wielu użytkowników, a użytkownik może należeć do wielu grup.

• Grupy użytkowników nie mogą być zagnieżdżone; mogą zawierać tylko użytkowników, a nie inne grupy użytkowników.

• Nie ma domyślnej grupy użytkowników, która automatycznie obejmuje wszystkich użytkowników w koncie AWS. Jeśli chcesz mieć taką grupę użytkowników, musisz ją utworzyć i przypisać do niej każdego nowego użytkownika.

• Liczba i rozmiar zasobów IAM w koncie AWS, takich jak liczba grup oraz liczba grup, do których użytkownik może należeć, są ograniczone. Aby uzyskać więcej informacji, zobacz kwoty IAM i AWS STS.

Role IAM

Rola IAM jest bardzo podobna do użytkownika, ponieważ jest to tożsamość z politykami uprawnień, które określają, co może i czego nie może robić w AWS. Jednak rola nie ma żadnych poświadczeń (hasła ani kluczy dostępu) związanych z nią. Zamiast być unikalnie przypisana do jednej osoby, rola ma być przyjmowana przez każdego, kto jej potrzebuje (i ma wystarczające uprawnienia). Użytkownik IAM może przyjąć rolę, aby tymczasowo uzyskać różne uprawnienia do konkretnego zadania. Rola może być przypisana do użytkownika federacyjnego, który loguje się za pomocą zewnętrznego dostawcy tożsamości zamiast IAM.

Rola IAM składa się z dwóch typów polityk: polityki zaufania, która nie może być pusta, definiującej kto może przyjąć rolę, oraz polityki uprawnień, która nie może być pusta, definiującej co może uzyskać dostęp.

Usługa AWS Security Token Service (STS)

Usługa AWS Security Token Service (STS) to usługa internetowa, która ułatwia wydawanie tymczasowych, ograniczonych poświadczeń. Jest specjalnie dostosowana do:

Tymczasowe poświadczenia w IAM

Tymczasowe poświadczenia są głównie używane z rolami IAM, ale mają również inne zastosowania. Możesz zażądać tymczasowych poświadczeń, które mają bardziej ograniczony zestaw uprawnień niż standardowy użytkownik IAM. To zapobiega przypadkowemu wykonywaniu zadań, które nie są dozwolone przez bardziej ograniczone poświadczenia. Korzyścią tymczasowych poświadczeń jest to, że wygasają automatycznie po określonym czasie. Masz kontrolę nad czasem, przez jaki poświadczenia są ważne.

Polityki

Uprawnienia polityki

Służą do przypisywania uprawnień. Istnieją 2 typy:

• Polityki zarządzane przez AWS (wstępnie skonfigurowane przez AWS)

• Polityki zarządzane przez klienta: skonfigurowane przez Ciebie. Możesz tworzyć polityki na podstawie polityk zarządzanych przez AWS (modyfikując jedną z nich i tworząc własną), korzystając z generatora polityk (widok GUI, który pomaga w przyznawaniu i odmawianiu uprawnień) lub pisząc własne.

Zgodnie z domyślnym dostępem jest odmowa, dostęp zostanie przyznany, jeśli określono wyraźną rolę. Jeśli istnieje pojedyncza "Deny", to nadpisze "Allow", z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są dozwolone domyślnie).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

The global fields that can be used for conditions in any service are documented here. The specific fields that can be used for conditions per service are documented here.

Inline Policies

Ten rodzaj polityk jest bezpośrednio przypisany do użytkownika, grupy lub roli. Wtedy nie pojawiają się one na liście Polityk, ponieważ nikt inny nie może ich używać. Polityki inline są przydatne, jeśli chcesz utrzymać ścisły związek jeden do jednego między polityką a tożsamością, do której jest stosowana. Na przykład, chcesz mieć pewność, że uprawnienia w polityce nie są przypadkowo przypisane do tożsamości innej niż ta, dla której są przeznaczone. Kiedy używasz polityki inline, uprawnienia w polityce nie mogą być przypadkowo przypisane do niewłaściwej tożsamości. Dodatkowo, gdy używasz konsoli zarządzania AWS do usunięcia tej tożsamości, polityki osadzone w tożsamości są również usuwane. To dlatego, że są częścią głównego podmiotu.

Resource Bucket Policies

To są polityki, które mogą być definiowane w zasobach. Nie wszystkie zasoby AWS je wspierają.

Jeśli główny podmiot nie ma wyraźnego odmowy dostępu do nich, a polityka zasobów przyznaje im dostęp, to są one dozwolone.

IAM Boundaries

Granice IAM mogą być używane do ograniczenia uprawnień, do których użytkownik lub rola powinny mieć dostęp. W ten sposób, nawet jeśli inny zestaw uprawnień jest przyznawany użytkownikowi przez inną politykę, operacja nie powiedzie się, jeśli spróbuje ich użyć.

Granica to po prostu polityka przypisana do użytkownika, która wskazuje maksymalny poziom uprawnień, jakie użytkownik lub rola mogą mieć. Tak więc, nawet jeśli użytkownik ma dostęp administratora, jeśli granica wskazuje, że może tylko czytać koszyki S·, to jest to maksymalne, co może zrobić.

To, SCP i przestrzeganie zasady najmniejszych uprawnień to sposoby kontrolowania, aby użytkownicy nie mieli więcej uprawnień niż te, których potrzebują.

Session Policies

Polityka sesji to polityka ustawiana, gdy rola jest przyjmowana w jakiś sposób. Będzie to jak granica IAM dla tej sesji: Oznacza to, że polityka sesji nie przyznaje uprawnień, ale ogranicza je do tych wskazanych w polityce (maksymalne uprawnienia to te, które ma rola).

To jest przydatne dla środków bezpieczeństwa: Kiedy administrator ma przyjąć bardzo uprzywilejowaną rolę, może ograniczyć uprawnienia tylko do tych wskazanych w polityce sesji, w przypadku gdy sesja zostanie skompromitowana.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Note that by default AWS może dodać polityki sesji do sesji, które będą generowane z powodu innych przyczyn. Na przykład, w nieautoryzowanych rolach przyjętych przez cognito domyślnie (korzystając z ulepszonej autoryzacji), AWS wygeneruje poświadczenia sesji z polityką sesji, która ogranicza usługi, do których sesja ma dostęp do następującej listy.

Dlatego, jeśli w pewnym momencie napotkasz błąd "... ponieważ żadna polityka sesji nie zezwala na ...", a rola ma dostęp do wykonania akcji, to dlatego, że istnieje polityka sesji, która to uniemożliwia.

Federacja Tożsamości

Federacja tożsamości pozwala użytkownikom z dostawców tożsamości, którzy są zewnętrzni dla AWS, na bezpieczny dostęp do zasobów AWS bez konieczności podawania poświadczeń użytkownika AWS z ważnego konta IAM. Przykładem dostawcy tożsamości może być twoje własne korporacyjne Microsoft Active Directory (poprzez SAML) lub usługi OpenID (jak Google). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.

Aby skonfigurować to zaufanie, generowany jest dostawca tożsamości IAM (SAML lub OAuth), który ufa innej platformie. Następnie, przynajmniej jedna rola IAM jest przypisana (ufająca) do dostawcy tożsamości. Jeśli użytkownik z zaufanej platformy uzyskuje dostęp do AWS, uzyskuje dostęp jako wspomniana rola.

Jednak zazwyczaj chcesz nadać inną rolę w zależności od grupy użytkownika na zewnętrznej platformie. Wtedy kilka ról IAM może ufać zewnętrznemu dostawcy tożsamości, a zewnętrzna platforma będzie tą, która pozwoli użytkownikom przyjąć jedną rolę lub inną.

Centrum Tożsamości IAM

AWS IAM Identity Center (następca AWS Single Sign-On) rozszerza możliwości AWS Identity and Access Management (IAM), aby zapewnić centralne miejsce, które łączy administrację użytkownikami i ich dostępem do kont AWS oraz aplikacji w chmurze.

Domena logowania będzie wyglądać jak <user_input>.awsapps.com.

Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:

• Katalog Centrum Tożsamości: Zwykli użytkownicy AWS

• Active Directory: Obsługuje różne konektory

• Zewnętrzny dostawca tożsamości: Wszyscy użytkownicy i grupy pochodzą z zewnętrznego dostawcy tożsamości (IdP)

W najprostszym przypadku katalogu Centrum Tożsamości, Centrum Tożsamości będzie miało listę użytkowników i grup i będzie mogło przypisywać polityki do nich do dowolnych kont organizacji.

Aby nadać dostęp użytkownikowi/grupie Centrum Tożsamości do konta, zostanie utworzony zaufany dostawca tożsamości SAML, a rola ufająca dostawcy tożsamości z wskazanymi politykami zostanie utworzona w docelowym koncie.

AwsSSOInlinePolicy

Możliwe jest nadawanie uprawnień za pomocą polityk inline do ról utworzonych za pomocą IAM Identity Center. Role utworzone w kontach, którym nadano polityki inline w AWS Identity Center, będą miały te uprawnienia w polityce inline o nazwie AwsSSOInlinePolicy.

Dlatego, nawet jeśli zobaczysz 2 role z polityką inline o nazwie AwsSSOInlinePolicy, to nie oznacza, że mają te same uprawnienia.

Zaufania i Role Między Kontami

Użytkownik (ufający) może utworzyć rolę międzykontową z pewnymi politykami, a następnie zezwolić innemu użytkownikowi (zaufanemu) na dostęp do swojego konta, ale tylko mając dostęp wskazany w nowych politykach roli. Aby to utworzyć, wystarczy utworzyć nową rolę i wybrać rolę międzykontową. Role do dostępu międzykontowego oferują dwie opcje. Zapewnienie dostępu między kontami AWS, które posiadasz, oraz zapewnienie dostępu między kontem, które posiadasz, a zewnętrznym kontem AWS. Zaleca się określenie użytkownika, który jest zaufany, a nie podawanie czegoś ogólnego, ponieważ w przeciwnym razie inni uwierzytelnieni użytkownicy, tacy jak użytkownicy federacyjni, będą mogli również nadużywać tego zaufania.

AWS Simple AD

Nieobsługiwane:

• Relacje zaufania

• Centrum administracyjne AD

• Pełne wsparcie PS API

• Kosz na śmieci AD

• Zarządzane konta usług grupowych

• Rozszerzenia schematu

• Brak bezpośredniego dostępu do OS lub instancji

Federacja Webowa lub Uwierzytelnianie OpenID

Aplikacja używa AssumeRoleWithWebIdentity do tworzenia tymczasowych poświadczeń. Jednak nie daje to dostępu do konsoli AWS, tylko dostęp do zasobów w AWS.

Inne opcje IAM

• Możesz ustawić politykę haseł, określając takie opcje jak minimalna długość i wymagania dotyczące haseł.

• Możesz pobrać "Raport poświadczeń" z informacjami o bieżących poświadczeniach (takimi jak czas utworzenia użytkownika, czy hasło jest włączone...). Możesz generować raport poświadczeń tak często, jak co cztery godziny.

AWS Identity and Access Management (IAM) zapewnia szczegółową kontrolę dostępu w całym AWS. Dzięki IAM możesz określić kto może uzyskać dostęp do jakich usług i zasobów, oraz na jakich warunkach. Dzięki politykom IAM zarządzasz uprawnieniami dla swojej siły roboczej i systemów, aby zapewnić minimalne uprawnienia.

Prefiksy ID IAM

Na tej stronie możesz znaleźć prefiksy ID IAM kluczy w zależności od ich natury:

Zalecane uprawnienia do audytu kont

Następujące uprawnienia przyznają różny dostęp do metadanych:

• arn:aws:iam::aws:policy/SecurityAudit

• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

• codebuild:ListProjects

• config:Describe*

• cloudformation:ListStacks

• logs:DescribeMetricFilters

• directconnect:DescribeConnections

• dynamodb:ListTables

Różne

Uwierzytelnianie CLI

Aby zwykły użytkownik mógł uwierzytelnić się w AWS za pomocą CLI, musisz mieć lokalne poświadczenia. Domyślnie możesz je skonfigurować ręcznie w ~/.aws/credentials lub uruchamiając aws configure. W tym pliku możesz mieć więcej niż jeden profil, jeśli żaden profil nie jest określony przy użyciu aws cli, używany będzie ten o nazwie [default] w tym pliku. Przykład pliku poświadczeń z więcej niż 1 profilem:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Jeśli musisz uzyskać dostęp do różnych kont AWS i Twój profil ma dostęp do przyjęcia roli w tych kontach, nie musisz ręcznie wywoływać STS za każdym razem (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) i konfigurować poświadczeń.

Możesz użyć pliku ~/.aws/config, aby wskazać, które role przyjąć, a następnie użyć parametru --profile jak zwykle (operacja assume-role zostanie wykonana w sposób przezroczysty dla użytkownika). Przykład pliku konfiguracyjnego:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Z tym plikiem konfiguracyjnym możesz następnie używać aws cli, jak:

aws --profile acc2 ...

Jeśli szukasz czegoś podobnego do tego, ale dla przeglądarki, możesz sprawdzić rozszerzenie AWS Extend Switch Roles.

Odniesienia

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html

• https://aws.amazon.com/iam/

• https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html