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

This commit is contained in:
Translator
2025-03-21 09:10:59 +00:00
parent 6d3c9e3810
commit ee29889b8e

View File

@@ -10,7 +10,7 @@
В AWS є **кореневий обліковий запис**, який є **батьківським контейнером для всіх облікових записів** вашої **організації**. Однак вам не потрібно використовувати цей обліковий запис для розгортання ресурсів, ви можете створити **інші облікові записи, щоб розділити різні AWS** інфраструктури між собою.
Це дуже цікаво з точки зору **безпеки**, оскільки **один обліковий запис не зможе отримати доступ до ресурсів з іншого облікового запису** (якщо спеціально не створені мости), таким чином ви можете створити межі між розгортаннями.
Це дуже цікаво з точки зору **безпеки**, оскільки **один обліковий запис не зможе отримати доступ до ресурсів іншого облікового запису** (якщо спеціально не створені мости), таким чином ви можете створити межі між розгортаннями.
Отже, в організації є **два типи облікових записів** (ми говоримо про облікові записи AWS, а не облікові записи користувачів): один обліковий запис, який призначений як обліковий запис управління, і один або кілька облікових записів учасників.
@@ -70,10 +70,10 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
**Політика контролю ресурсів (RCP)** - це політика, яка визначає **максимальні дозволи для ресурсів у вашій організації AWS**. RCP схожі на політики IAM за синтаксисом, але **не надають дозволів** — вони лише обмежують дозволи, які можуть бути застосовані до ресурсів іншими політиками. Коли ви прикріплюєте RCP до кореня вашої організації, організаційної одиниці (OU) або облікового запису, RCP обмежує дозволи ресурсів для всіх ресурсів у відповідному обсязі.
Це є ЄДИНИМ способом забезпечити, щоб **ресурси не перевищували попередньо визначені рівні доступу** — навіть якщо політика на основі ідентичності або ресурсів є занадто дозволяючою. Єдиний спосіб обійти ці обмеження - також змінити RCP, налаштовану обліковим записом управління вашої організації.
Це є ЄДИНИМ способом забезпечити, щоб **ресурси не перевищували попередньо визначені рівні доступу** — навіть якщо політика на основі ідентичності або ресурсу є занадто дозволяючою. Єдиний спосіб обійти ці обмеження - також змінити RCP, налаштовану обліковим записом управління вашої організації.
> [!WARNING]
> RCP лише обмежують дозволи, які можуть мати ресурси. Вони не контролюють безпосередньо те, що можуть робити суб'єкти. Наприклад, якщо RCP забороняє зовнішній доступ до S3 бакету, це забезпечує, що дозволи бакету ніколи не дозволяють дії, що виходять за межі встановленого ліміту — навіть якщо політика на основі ресурсів налаштована неправильно.
> RCP лише обмежують дозволи, які можуть мати ресурси. Вони не контролюють безпосередньо, що можуть робити суб'єкти. Наприклад, якщо RCP забороняє зовнішній доступ до S3 бакету, це забезпечує, що дозволи бакету ніколи не дозволяють дії, що виходять за межі встановленого ліміту — навіть якщо політика на основі ресурсу неправильно налаштована.
Приклади RCP:
@@ -127,7 +127,7 @@ IAM можна визначити за його здатністю керува
#### CLI
- **ID ключа доступу**: 20 випадкових великих алфавітно-цифрових символів, таких як AKHDNAPO86BSHKDIRYT
- **ID секретного ключа доступу**: 40 випадкових великих і малих символів: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (неможливо відновити втрачені ID секретного ключа доступу).
- **ID секретного ключа доступу**: 40 випадкових великих і малих літер: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (неможливо відновити втрачені ID секретного ключа доступу).
Коли вам потрібно **змінити ключ доступу**, це процес, який ви повинні виконати:\
_Створіть новий ключ доступу -> Застосуйте новий ключ до системи/додатку -> позначте оригінальний як неактивний -> протестуйте та перевірте, що новий ключ доступу працює -> видаліть старий ключ доступу_
@@ -158,14 +158,14 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
Ось деякі важливі характеристики груп користувачів:
- **Група** користувачів може **містити багато користувачів**, а **користувач** може **належати до кількох груп**.
- **Група користувачів** може **містити багато користувачів**, а **користувач** може **належати до кількох груп**.
- **Групи користувачів не можуть бути вкладеними**; вони можуть містити лише користувачів, а не інші групи користувачів.
- **Не існує групи користувачів за замовчуванням, яка автоматично включає всіх користувачів в обліковому записі AWS**. Якщо ви хочете мати таку групу користувачів, ви повинні створити її та призначити кожного нового користувача до неї.
- Кількість і розмір ресурсів IAM в обліковому записі AWS, таких як кількість груп і кількість груп, до яких може належати користувач, обмежені. Для отримання додаткової інформації див. [Квоти IAM та AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
### [Ролі IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
Роль IAM **дуже схожа** на **користувача**, оскільки це **ідентифікація з політиками дозволів, які визначають, що** вона може і не може робити в AWS. Однак роль **не має жодних облікових даних** (пароль або ключі доступу), пов'язаних з нею. Замість того, щоб бути унікально пов'язаною з однією особою, роль призначена для того, щоб її **могли приймати будь-хто, хто її потребує (і має достатні дозволи)**. **Користувач IAM може прийняти роль, щоб тимчасово** отримати різні дозволи для конкретного завдання. Роль може бути **призначена** [**федеративному користувачу**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html), який входить, використовуючи зовнішнього постачальника ідентичності замість IAM.
**Роль IAM** дуже **схожа** на **користувача**, оскільки це **ідентифікація з політиками дозволів, які визначають, що** вона може і не може робити в AWS. Однак роль **не має жодних облікових даних** (пароль або ключі доступу), пов'язаних з нею. Замість того, щоб бути унікально пов'язаною з однією особою, роль призначена для того, щоб її **могли приймати будь-хто, хто її потребує (і має достатні дозволи)**. **Користувач IAM може прийняти роль, щоб тимчасово** отримати різні дозволи для конкретного завдання. Роль може бути **призначена** [**федеративному користувачу**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html), який входить, використовуючи зовнішнього постачальника ідентичності замість IAM.
Роль IAM складається з **двох типів політик**: **політики довіри**, яка не може бути порожньою, що визначає, **хто може прийняти** роль, і **політики дозволів**, яка не може бути порожньою, що визначає, **до чого вона може отримати доступ**.
@@ -186,7 +186,7 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
- Політики, керовані AWS (попередньо налаштовані AWS)
- Політики, керовані клієнтом: Налаштовані вами. Ви можете створювати політики на основі політик, керованих AWS (модифікуючи одну з них і створюючи свою), використовуючи генератор політик (GUI, який допомагає вам надавати та відмовляти в дозволах) або написавши свої власні.
За **замовчуванням доступ** **заборонено**, доступ буде надано, якщо була вказана явна роль.\
За **замовчуванням доступ** є **забороненим**, доступ буде надано, якщо була вказана явна роль.\
Якщо **існує єдиний "Deny", він переважатиме над "Allow"**, за винятком запитів, які використовують кореневі облікові дані безпеки облікового запису AWS (які за замовчуванням дозволені).
```javascript
{
@@ -216,9 +216,9 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
#### Вбудовані політики
Цей вид політик **безпосередньо призначається** користувачу, групі або ролі. Тоді вони не з'являються у списку політик, оскільки інші не можуть їх використовувати.\
Вбудовані політики корисні, якщо ви хочете **підтримувати сувору однозначну відповідність між політикою та ідентичністю**, до якої вона застосовується. Наприклад, ви хочете бути впевненими, що дозволи в політиці не призначені ненавмисно іншій ідентичності, окрім тієї, для якої вони призначені. Коли ви використовуєте вбудовану політику, дозволи в політиці не можуть бути ненавмисно прикріплені до неправильної ідентичності. Крім того, коли ви використовуєте AWS Management Console для видалення цієї ідентичності, політики, вбудовані в ідентичність, також видаляються. Це тому, що вони є частиною основної сутності.
Вбудовані політики корисні, якщо ви хочете **підтримувати строгі однозначні відносини між політикою та ідентичністю**, до якої вона застосовується. Наприклад, ви хочете бути впевненими, що дозволи в політиці не призначені випадково іншій ідентичності, окрім тієї, для якої вони призначені. Коли ви використовуєте вбудовану політику, дозволи в політиці не можуть бути випадково прикріплені до неправильної ідентичності. Крім того, коли ви використовуєте AWS Management Console для видалення цієї ідентичності, політики, вбудовані в ідентичність, також видаляються. Це тому, що вони є частиною основної сутності.
#### Політики ресурсних бакетів
#### Політики ресурсних кошиків
Це **політики**, які можуть бути визначені в **ресурсах**. **Не всі ресурси AWS підтримують їх**.
@@ -228,7 +228,7 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
Межі IAM можна використовувати для **обмеження дозволів, до яких користувач або роль повинні мати доступ**. Таким чином, навіть якщо інший набір дозволів надається користувачу іншою **політикою**, операція **не вдасться**, якщо він спробує їх використати.
Межа - це просто політика, прикріплена до користувача, яка **вказує максимальний рівень дозволів, які користувач або роль можуть мати**. Отже, **навіть якщо у користувача є доступ адміністратора**, якщо межа вказує, що він може лише читати S· бакети, це максимальне, що він може зробити.
Межа - це просто політика, прикріплена до користувача, яка **вказує максимальний рівень дозволів, які користувач або роль можуть мати**. Отже, **навіть якщо у користувача є доступ адміністратора**, якщо межа вказує, що він може лише читати S· кошики, це максимальне, що він може зробити.
**Це**, **SCP** та **дотримання принципу найменших привілеїв** - це способи контролю, щоб користувачі не мали більше дозволів, ніж їм потрібно.
@@ -267,13 +267,13 @@ AWS IAM Identity Center (наступник AWS Single Sign-On) розширює
Для входу користувачів можна використовувати 3 джерела ідентичності:
- Довідник Identity Center: Звичайні користувачі AWS
- Identity Center Directory: Звичайні користувачі AWS
- Active Directory: Підтримує різні конектори
- Зовнішній постачальник ідентичності: Всі користувачі та групи походять від зовнішнього постачальника ідентичності (IdP)
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
У найпростішому випадку довідника Identity Center, **Identity Center матиме список користувачів і груп** і зможе **призначати політики** їм для **будь-якого з облікових записів** організації.
У найпростішому випадку каталогу Identity Center, **Identity Center матиме список користувачів і груп** і зможе **призначати політики** їм для **будь-якого з облікових записів** організації.
Щоб надати доступ користувачу/групі Identity Center до облікового запису, **буде створено постачальника ідентичності SAML, який довіряє Identity Center**, і **роль, що довіряє постачальнику ідентичності з вказаними політиками, буде створена** в цільовому обліковому записі.
@@ -285,7 +285,7 @@ AWS IAM Identity Center (наступник AWS Single Sign-On) розширює
### Довіра та ролі між обліковими записами
**Користувач** (довіряючий) може створити роль між обліковими записами з деякими політиками, а потім **дозволити іншому користувачу** (довіреному) **отримати доступ до свого облікового запису**, але лише **маючи доступ, вказаний у нових політиках ролі**. Щоб створити це, просто створіть нову роль і виберіть Роль між обліковими записами. Ролі для доступу між обліковими записами пропонують два варіанти. Надання доступу між обліковими записами AWS, які ви володієте, і надання доступу між обліковим записом, яким ви володієте, і стороннім обліковим записом AWS.\
**Користувач** (довіряючий) може створити роль між обліковими записами з деякими політиками, а потім **дозволити іншому користувачу** (довіреному) **отримати доступ до свого облікового запису**, але лише **маючи доступ, вказаний у нових політиках ролі**. Щоб створити це, просто створіть нову роль і виберіть Роль між обліковими записами. Ролі для доступу між обліковими записами пропонують два варіанти. Надання доступу між обліковими записами AWS, які ви володієте, і надання доступу між обліковим записом, яким ви володієте, та стороннім обліковим записом AWS.\
Рекомендується **вказати користувача, який є довіреним, а не ставити щось загальне**, оскільки в іншому випадку інші автентифіковані користувачі, такі як федеративні користувачі, також зможуть зловживати цією довірою.
### AWS Simple AD
@@ -307,7 +307,7 @@ AWS IAM Identity Center (наступник AWS Single Sign-On) розширює
### Інші варіанти IAM
- Ви можете **встановити параметри політики паролів**, такі як мінімальна довжина та вимоги до паролів.
- Ви можете **завантажити "Звіт про облікові дані"** з інформацією про поточні облікові дані (такі як час створення користувача, чи увімкнено пароль...). Ви можете генерувати звіт про облікові дані так часто, як раз на **чотири години**.
- Ви можете **завантажити "Звіт про облікові дані"** з інформацією про поточні облікові дані (такі як час створення користувача, чи активовано пароль...). Ви можете генерувати звіт про облікові дані так часто, як раз на **чотири години**.
AWS Identity and Access Management (IAM) забезпечує **точний контроль доступу** по всьому AWS. З IAM ви можете вказати, **хто може отримати доступ до яких сервісів і ресурсів**, і за яких умов. За допомогою політик IAM ви керуєте дозволами для вашої робочої сили та систем, щоб **забезпечити найменші привілеї**.
@@ -315,20 +315,20 @@ AWS Identity and Access Management (IAM) забезпечує **точний к
На [**цій сторінці**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) ви можете знайти **префікси ID IAM** ключів залежно від їх природи:
| Код ідентифікатора | Опис |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ABIA | [Токен носія служби AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| Код ідентифікатора | Опис |
| ------------------ | -------------------------------------------------------------------------------------------------------- |
| ABIA | [Токен носія служби AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ACCA | Контекстно-специфічні облікові дані |
| AGPA | Група користувачів |
| AIDA | Користувач IAM |
| AIPA | Профіль екземпляра Amazon EC2 |
| AKIA | Ключ доступу |
| ANPA | Керована політика |
| ANVA | Версія в керованій політиці |
| APKA | Публічний ключ |
| AROA | Роль |
| ASCA | Сертифікат |
| ACCA | Контекстно-специфічні облікові дані |
| AGPA | Група користувачів |
| AIDA | Користувач IAM |
| AIPA | Профіль екземпляра Amazon EC2 |
| AKIA | Ключ доступу |
| ANPA | Керована політика |
| ANVA | Версія в керованій політиці |
| APKA | Публічний ключ |
| AROA | Роль |
| ASCA | Сертифікат |
| ASIA | [Тимчасові (AWS STS) ідентифікатори ключів доступу](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) використовують цей префікс, але є унікальними лише в комбінації з секретним ключем доступу та токеном сесії. |
### Рекомендовані дозволи для аудиту облікових записів
@@ -346,10 +346,10 @@ AWS Identity and Access Management (IAM) забезпечує **точний к
## Різне
### Аутентифікація CLI
### CLI автентифікація
Щоб звичайний користувач міг аутентифікуватися в AWS через CLI, вам потрібно мати **локальні облікові дані**. За замовчуванням ви можете налаштувати їх **вручну** в `~/.aws/credentials` або **запустивши** `aws configure`.\
У цьому файлі ви можете мати більше одного профілю, якщо **жоден профіль** не вказано за допомогою **aws cli**, буде використовуватися той, що називається **`[default]`** в цьому файлі.\
Щоб звичайний користувач міг автентифікуватися в AWS через CLI, вам потрібно мати **локальні облікові дані**. За замовчуванням ви можете налаштувати їх **вручну** в `~/.aws/credentials` або **запустивши** `aws configure`.\
У цьому файлі ви можете мати більше ніж один профіль, якщо **жоден профіль** не вказано за допомогою **aws cli**, буде використовуватися той, що називається **`[default]`** у цьому файлі.\
Приклад файлу облікових даних з більш ніж 1 профілем:
```
[default]