diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index ae209b456..4d1903f2e 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -8,9 +8,9 @@ ### 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 utworzyć **inne konta, aby oddzielić różne infrastruktury AWS** między sobą. +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 tworzyć granice między wdrożeniami. +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. @@ -24,7 +24,7 @@ Dlatego w organizacji istnieją **dwa typy kont** (mówimy o kontach AWS, a nie - Włączyć integrację z obsługiwanymi usługami AWS, aby zapewnić funkcjonalność usług w ramach wszystkich kont 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ść 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ą. +Konto zarządzające ma **obowiązki 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). @@ -53,13 +53,11 @@ Przykłady SCP: - Całkowicie zablokować konto root - Zezwolić tylko na określone regiony - Zezwolić tylko na usługi z białej listy -- Zablokować GuardDuty, CloudTrail i S3 Public Block Access przed +- Zablokować możliwość wyłączenia GuardDuty, CloudTrail i S3 Public Block Access -byciem wyłączonym +- Zablokować usuwanie lub -- Zablokować role odpowiedzialności za bezpieczeństwo/incydenty przed usunięciem lub - -zmianą. +modyfikowanie ról odpowiedzialnych za bezpieczeństwo/reakcję na incydenty. - Zablokować usuwanie kopii zapasowych. - Zablokować tworzenie użytkowników IAM i kluczy dostępu @@ -80,7 +78,7 @@ Przykłady RCP: - Ograniczyć koszyki S3, aby mogły być dostępne tylko przez podmioty w twojej organizacji - Ograniczyć użycie kluczy KMS, aby zezwolić tylko na operacje z zaufanych kont organizacyjnych - Ograniczyć uprawnienia na kolejkach SQS, aby zapobiec nieautoryzowanym modyfikacjom -- Wymusić granice dostępu na sekretach Menedżera Sekretów, aby chronić wrażliwe dane +- Wymusić granice dostępu do sekretów w Secrets Manager, aby chronić wrażliwe dane Znajdź przykłady w [dokumentacji Polityk Kontroli Zasobów AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) @@ -126,7 +124,7 @@ Użytkownicy mogą mieć **włączone MFA do logowania** przez konsolę. Tokeny #### CLI -- **ID klucza dostępu**: 20 losowych wielkich liter i cyfr, np. AKHDNAPO86BSHKDIRYT +- **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 tajnego klucza dostępu). Kiedy musisz **zmienić klucz dostępu**, powinieneś postępować według tego procesu:\ @@ -165,17 +163,17 @@ Oto kilka ważnych cech grup użytkowników: ### [Role IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -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** przyjąć różne uprawnienia do konkretnego zadania. Rola może być **przypisana do** [**użytkownika federacyjnego**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html), który loguje się za pomocą zewnętrznego dostawcy tożsamości zamiast 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**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html), 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 **do czego ma 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: +Usługa AWS Security Token Service (STS) to usługa internetowa, która ułatwia **wydawanie tymczasowych, ograniczonych uprawnień**. Jest specjalnie dostosowana do: ### [Tymczasowe poświadczenia w IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) -**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ą z tymczasowych poświadczeń jest to, że wygasają automatycznie po określonym czasie. Masz kontrolę nad czasem, przez jaki poświadczenia są ważne. +**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 @@ -186,8 +184,8 @@ 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** **odmowa** jest **zabroniona**, dostęp zostanie przyznany, jeśli określono wyraźną rolę.\ -Jeśli **istnieje pojedyncza "Odmowa", nadpisze "Zezwolenie"**, z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są dozwolone domyślnie). +Zgodnie z **domyślnym dostępem** jest **odmowa**, dostęp zostanie przyznany, jeśli określono wyraźną rolę.\ +Jeśli **istnieje pojedyncza "Odmowa", nadpisze ona "Zezwól"**, z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są dozwolone domyślnie). ```javascript { "Version": "2012-10-17", //Version of the policy @@ -216,19 +214,19 @@ Specyficzne pola, które mogą być używane do warunków w każdej usłudze, s #### Polityki Inline 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łą relację 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. +Polityki inline są przydatne, jeśli chcesz **utrzymać ścisłą relację jeden do jednego między polityką a tożsamością**, do której jest zastosowana. 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. Dzieje się tak, ponieważ są częścią głównego podmiotu. -#### Polityki Bucketów Zasobów +#### Polityki Koszyków Zasobów 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ą dozwolone. +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. ### Granice IAM 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ć bucket S·, to jest to maksymalne, co może zrobić. +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ą. @@ -236,7 +234,7 @@ Granica to po prostu polityka przypisana do użytkownika, która **wskazuje maks 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. +To jest przydatne dla **środków bezpieczeństwa**: Gdy administrator ma przyjąć bardzo uprzywilejowaną rolę, może ograniczyć uprawnienia tylko do tych wskazanych w polityce sesji, w przypadku gdy sesja zostanie skompromitowana. ```bash aws sts assume-role \ --role-arn \ @@ -244,7 +242,7 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -Zauważ, że domyślnie **AWS może dodawać polityki sesji do sesji**, które będą generowane z powodu innych przyczyn. Na przykład, w przypadku [nieautoryzowanych ról przyjętych przez Cognito](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) 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**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). +Zauważ, że domyślnie **AWS może dodać polityki sesji do sesji**, które będą generowane z powodu innych przyczyn. Na przykład, w przypadku [nieautoryzowanych ról przyjętych przez Cognito](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) 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**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). 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**. @@ -255,27 +253,27 @@ Przykładem dostawcy tożsamości może być twoje własne korporacyjne **Micros 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 przypisywana (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 będziesz chciał 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 na przyjęcie jednej lub drugiej roli. +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 na przyjęcie jednej lub drugiej roli.
### IAM Identity Center -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żytkowników i ich dostęp do kont AWS** oraz aplikacji w chmurze. +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 `.awsapps.com`. Aby zalogować użytkowników, można użyć 3 źródeł tożsamości: -- Katalog Identity Center: Zwykli użytkownicy AWS +- Directory Identity Center: Zwykli użytkownicy AWS - Active Directory: Obsługuje różne konektory -- Zewnętrzny dostawca tożsamości: Wszyscy użytkownicy i grupy pochodzą od zewnętrznego dostawcy tożsamości (IdP) +- Zewnętrzny dostawca tożsamości: Wszyscy użytkownicy i grupy pochodzą z zewnętrznego dostawcy tożsamości (IdP)
W najprostszym przypadku katalogu Identity Center, **Identity Center będzie miał listę użytkowników i grup** i będzie mógł **przypisywać polityki** do nich do **dowolnych kont** organizacji. -Aby nadać dostęp użytkownikowi/grupie Identity Center do konta, **zostanie utworzony zaufany dostawca tożsamości SAML**, a **rola zaufana dostawcy tożsamości z wskazanymi politykami zostanie utworzona** w docelowym koncie. +Aby nadać dostęp użytkownikowi/grupie Identity Center do konta, **zostanie utworzony dostawca tożsamości SAML ufający Identity Center**, a **rola ufająca dostawcy tożsamości z wskazanymi politykami zostanie utworzona** w docelowym koncie. #### AwsSSOInlinePolicy @@ -283,9 +281,9 @@ Możliwe jest **nadawanie uprawnień za pomocą polityk inline do ról utworzony 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 +### Zaufania i Role Między Kontami -**Użytkownik** (ufający) może utworzyć rolę między kontami 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ędzy kontami. Role do dostępu między kontami 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.\ +**Użytkownik** (ufający) może utworzyć rolę między kontami z pewnymi politykami, a następnie **zezwolić innemu użytkownikowi** (ufanemu) 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ędzy kontami. Role do dostępu między kontami 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 umieszczanie 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 @@ -295,10 +293,10 @@ Nieobsługiwane: - Relacje zaufania - Centrum administracyjne AD - Pełne wsparcie PS API -- Kosz na śmieci AD -- Zarządzane konta usług grupowych +- Kosz na AD +- Konta zarządzane grupami - Rozszerzenia schematu -- Brak bezpośredniego dostępu do systemu operacyjnego lub instancji +- Brak bezpośredniego dostępu do OS lub instancji #### Federacja Webowa lub Uwierzytelnianie OpenID @@ -307,7 +305,7 @@ Aplikacja używa AssumeRoleWithWebIdentity do tworzenia tymczasowych poświadcze ### Inne opcje IAM - Możesz **ustawić politykę haseł**, opcje takie 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**. +- Możesz **pobrać "Raport Poświadczeń"** z informacjami o aktualnych 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**. @@ -315,20 +313,20 @@ AWS Identity and Access Management (IAM) zapewnia **szczegółową kontrolę dos Na [**tej stronie**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) możesz znaleźć **prefiksy ID IAM** kluczy w zależności od ich natury: -| Kod identyfikatora | Opis | -| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| ABIA | [Token nosiciela usługi AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | +| Kod identyfikatora | Opis | +| ------------------ | -------------------------------------------------------------------------------------------------------- | +| ABIA | [Token nosiciela usługi AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | -| ACCA | Poświadczenie specyficzne dla kontekstu | -| AGPA | Grupa użytkowników | -| AIDA | Użytkownik IAM | -| AIPA | Profil instancji Amazon EC2 | -| AKIA | Klucz dostępu | -| ANPA | Polityka zarządzana | -| ANVA | Wersja w polityce zarządzanej | -| APKA | Klucz publiczny | -| AROA | Rola | -| ASCA | Certyfikat | +| ACCA | Poświadczenie specyficzne dla kontekstu | +| AGPA | Grupa użytkowników | +| AIDA | Użytkownik IAM | +| AIPA | Profil instancji Amazon EC2 | +| AKIA | Klucz dostępu | +| ANPA | Polityka zarządzana | +| ANVA | Wersja w polityce zarządzanej | +| APKA | Klucz publiczny | +| AROA | Rola | +| ASCA | Certyfikat | | ASIA | [Tymczasowe identyfikatory kluczy dostępu (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) używają tego prefiksu, ale są unikalne tylko w połączeniu z tajnym kluczem dostępu i tokenem sesji. | ### Zalecane uprawnienia do audytu kont @@ -349,7 +347,7 @@ Następujące uprawnienia przyznają różny dostęp do odczytu metadanych: ### 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.\ +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żyty zostanie ten o nazwie **`[default]`** w tym pliku.\ Przykład pliku poświadczeń z więcej niż 1 profilem: ``` [default]