Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

This commit is contained in:
Translator
2025-03-21 09:24:15 +00:00
parent aed64afbe1
commit 614fc2057a
2 changed files with 40 additions and 38 deletions

View File

@@ -8,7 +8,7 @@
### 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ą.
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ą.
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.
@@ -20,11 +20,11 @@ Dlatego w organizacji istnieją **dwa typy kont** (mówimy o kontach AWS, a nie
- 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
- Stosować polityki do podmiotów (korzenie, OUs lub konta) w organizacji
- 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 **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ą.
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ą.
- **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).
@@ -42,22 +42,24 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
**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 tą różnicą, ż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 wykonaniem czegoś. Na przykład, może być użyta do powstrzymania użytkowników przed wyłączaniem CloudTrail lub usuwaniem kopii zapasowych.\
To jest JEDYNY sposób, aby **nawet użytkownik root mógł być powstrzymany** przed wykonaniem 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).
> [!WARNING]
> Zauważ, że **SCP ograniczają tylko podmioty w koncie**, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia `s3:GetObject`, nie powstrzyma ludzi przed **uzyskiwaniem dostępu do publicznego koszyka S3** w twoim koncie.
> Zauważ, że **SCP tylko ograniczają uprawnienia w koncie**, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia `s3:GetObject`, nie powstrzyma ludzi przed **uzyskiwaniem dostępu do publicznego koszyka S3** w twoim koncie.
Przykłady SCP:
- Całkowicie zablokować konto root
- Zezwolić tylko na określone regiony
- Zezwolić tylko na usługi z białej listy
- Zablokować możliwość wyłączenia GuardDuty, CloudTrail i S3 Public Block Access
- Zablokować GuardDuty, CloudTrail i S3 Public Block Access przed
- Zablokować usuwanie lub
byciem wyłączonym
modyfikowanie ról odpowiedzialnych za bezpieczeństwo/reakcję na incydenty.
- Zablokować role odpowiedzialności za bezpieczeństwo/incydenty przed usunięciem lub
zmianą.
- Zablokować usuwanie kopii zapasowych.
- Zablokować tworzenie użytkowników IAM i kluczy dostępu
@@ -68,17 +70,17 @@ Znajdź **przykłady JSON** w [https://docs.aws.amazon.com/organizations/latest/
**Polityka kontroli zasobów (RCP)** to polityka, która definiuje **maksymalne uprawnienia dla zasobów w twojej organizacji AWS**. RCP są podobne do polityk IAM pod względem składni, ale **nie przyznają uprawnień**—tylko ograniczają uprawnienia, które mogą być stosowane do zasobów przez inne polityki. Gdy dołączysz RCP do korzenia swojej organizacji, jednostki organizacyjnej (OU) lub konta, RCP ogranicza uprawnienia zasobów we wszystkich zasobach w dotkniętym zakresie.
To jest JEDYNY sposób, aby zapewnić, że **zasoby nie mogą przekroczyć zdefiniowanych poziomów dostępu**—nawet jeśli polityka oparta na tożsamości lub zasobach jest zbyt liberalna. Jedynym sposobem na obejście tych ograniczeń jest również modyfikacja RCP skonfigurowanej przez konto zarządzające twojej organizacji.
To jest JEDYNY sposób, aby zapewnić, że **zasoby nie mogą przekraczać zdefiniowanych poziomów dostępu**—nawet jeśli polityka oparta na tożsamości lub zasobach jest zbyt liberalna. Jedynym sposobem na obejście tych ograniczeń jest również modyfikacja RCP skonfigurowanej przez konto zarządzające twojej organizacji.
> [!WARNING]
> RCP ograniczają tylko uprawnienia, które mogą mieć zasoby. Nie kontrolują bezpośrednio, co mogą robić podmioty. Na przykład, jeśli RCP odmawia dostępu zewnętrznego do koszyka S3, zapewnia, że uprawnienia koszyka nigdy nie pozwalają na działania wykraczające poza ustalony limit—nawet jeśli polityka oparta na zasobach jest źle skonfigurowana.
> RCP tylko ograniczają uprawnienia, które mogą mieć zasoby. Nie kontrolują bezpośrednio, co mogą robić podmioty. Na przykład, jeśli RCP odmawia dostępu zewnętrznego do koszyka S3, zapewnia, że uprawnienia koszyka nigdy nie pozwalają na działania wykraczające poza ustalony limit—nawet jeśli polityka oparta na zasobach jest źle skonfigurowana.
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 do sekretów w Secrets Manager, aby chronić wrażliwe dane
- Wymusić granice dostępu na sekretach Menedżera Sekretów, 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)
@@ -124,8 +126,8 @@ Użytkownicy mogą mieć **włączone MFA do logowania** przez konsolę. Tokeny
#### 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 tajnego klucza dostępu).
- **ID klucza dostępu**: 20 losowych wielkich liter i cyfr, np. AKHDNAPO86BSHKDIRYT
- **ID tajnego klucza dostępu**: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie można odzyskać 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_
@@ -150,20 +152,20 @@ As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credent
### [Grupy użytkowników IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
Grupa [użytkowników IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) 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**.
Grupa użytkowników IAM [user group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) 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.
- **Grupy użytkowników nie mogą być zagnieżdżane**; 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
- 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 [IAM i limity AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
### [Role IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
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 **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**.
@@ -185,7 +187,7 @@ Służą do przypisywania uprawnień. Istnieją 2 typy:
- 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 "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).
Jeśli **istnieje pojedyncza "Odmowa", nadpisze "Zezwól"**, z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są domyślnie dozwolone).
```javascript
{
"Version": "2012-10-17", //Version of the policy
@@ -214,19 +216,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 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 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. To dlatego, że są częścią głównego podmiotu.
#### 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ą one 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ą 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ć koszyki 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ą.
@@ -234,7 +236,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**: Gdy 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**: Kiedy 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 <value> \
@@ -249,17 +251,17 @@ Dlatego, jeśli w pewnym momencie napotkasz błąd "... ponieważ żadna polityk
### 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** (takie jak **Google**). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.
Przykładem dostawcy tożsamości może być twoja własna korporacyjna **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 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 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.
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 przyjąć jedną rolę lub inną.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
### 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żytkownikami i ich dostępem 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żytkowników i ich dostęp do kont AWS** oraz aplikacji w chmurze.
Domena logowania będzie wyglądać jak `<user_input>.awsapps.com`.
@@ -273,7 +275,7 @@ Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:
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 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.
Aby nadać dostęp użytkownikowi/grupie Identity Center 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
@@ -283,7 +285,7 @@ Dlatego, nawet jeśli zobaczysz 2 role z polityką inline o nazwie **`AwsSSOInli
### 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** (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.\
**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 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
@@ -292,11 +294,11 @@ Nieobsługiwane:
- Relacje zaufania
- Centrum administracyjne AD
- Pełne wsparcie PS API
- Kosz na AD
- Konta zarządzane grupami
- Pełne wsparcie API PS
- Kosz na śmieci AD
- Zarządzane konta usług grupowych
- Rozszerzenia schematu
- Brak bezpośredniego dostępu do OS lub instancji
- Brak bezpośredniego dostępu do systemu operacyjnego lub instancji
#### Federacja Webowa lub Uwierzytelnianie OpenID
@@ -305,9 +307,9 @@ 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 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**.
- 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**.
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ć uprawnienia minimalne**.
### Prefiksy ID IAM
@@ -347,7 +349,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żyty zostanie 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żywany będzie ten o nazwie **`[default]`** w tym pliku.\
Przykład pliku poświadczeń z więcej niż 1 profilem:
```
[default]

View File

@@ -80,7 +80,7 @@ GO
## Azure SQL Database
**Azure SQL Database** to **w pełni zarządzana platforma baz danych jako usługa (PaaS)**, która zapewnia skalowalne i bezpieczne rozwiązania baz danych relacyjnych. Jest zbudowana na najnowszych technologiach SQL Server i eliminuje potrzebę zarządzania infrastrukturą, co czyni ją popularnym wyborem dla aplikacji w chmurze.
**Azure SQL Database** to **w pełni zarządzana platforma baz danych jako usługa (PaaS)**, która zapewnia skalowalne i bezpieczne rozwiązania baz danych relacyjnych. Jest oparta na najnowszych technologiach SQL Server i eliminuje potrzebę zarządzania infrastrukturą, co czyni ją popularnym wyborem dla aplikacji w chmurze.
Aby utworzyć bazę danych SQL, należy wskazać serwer SQL, na którym będzie hostowana.
@@ -97,9 +97,9 @@ Aby utworzyć bazę danych SQL, należy wskazać serwer SQL, na którym będzie
- **Redundancja danych:** Opcje to lokalna, strefowa, Geo lub Geo-Zone redundant.
- **Księga:** Kryptograficznie weryfikuje integralność danych, zapewniając, że wszelkie manipulacje są wykrywane. Przydatne dla finansów, medycyny i każdej organizacji zarządzającej wrażliwymi danymi.
Baza danych SQL może być częścią **puli elastycznej**. Puli elastyczne to opłacalne rozwiązanie do zarządzania wieloma bazami danych poprzez dzielenie konfigurowalnych zasobów obliczeniowych (eDTUs) i pamięci masowej, z ceną opartą wyłącznie na przydzielonych zasobach, a nie na liczbie baz danych.
Baza danych SQL może być częścią **elastycznego zbioru**. Elastyczne zbiory to opłacalne rozwiązanie do zarządzania wieloma bazami danych poprzez dzielenie konfigurowalnych zasobów obliczeniowych (eDTUs) i pamięci masowej, z ceną opartą wyłącznie na przydzielonych zasobach, a nie na liczbie baz danych.
#### Azure SQL Column Level Security (Masking) & Row Level Security
#### Azure SQL Column Level Security (Maskowanie) & Row Level Security
**Dynamiczne** maskowanie danych w **Azure SQL** to funkcja, która pomaga **chronić wrażliwe informacje, ukrywając je** przed nieautoryzowanymi użytkownikami. Zamiast zmieniać rzeczywiste dane, dynamicznie maskuje wyświetlane dane, zapewniając, że wrażliwe szczegóły, takie jak numery kart kredytowych, są zasłonięte.
@@ -109,7 +109,7 @@ Baza danych SQL może być częścią **puli elastycznej**. Puli elastyczne to o
### Azure SQL Managed Instance
**Azure SQL Managed Instances** są przeznaczone do większych wdrożeń w skali całej instancji SQL Server. Zapewnia niemal 100% zgodności z najnowszym silnikiem bazy danych SQL Server w wersji lokalnej (Enterprise Edition), który oferuje natywną implementację sieci wirtualnej (VNet), rozwiązującą powszechne problemy z bezpieczeństwem, oraz model biznesowy korzystny dla klientów SQL Server w wersji lokalnej.
**Azure SQL Managed Instances** są przeznaczone do większych wdrożeń w skali całej instancji SQL Server. Zapewnia niemal 100% zgodności z najnowszym silnikiem bazy danych SQL Server w wersji lokalnej (Enterprise Edition), który oferuje natywną implementację sieci wirtualnej (VNet), rozwiązującą powszechne problemy z bezpieczeństwem, oraz model biznesowy korzystny dla klientów SQL Server w wersji lokalnej.
### Azure SQL Virtual Machines