AWS - Basic Information

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити вашу компанію рекламовану на HackTricks або завантажити HackTricks у PDF Перевірте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks мерч
Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFT
Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.
Поділіться своїми хакінг-трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

Ієрархія Організації

Облікові записи

У AWS існує кореневий обліковий запис, який є батьківським контейнером для всіх облікових записів вашої організації. Однак вам не потрібно використовувати цей обліковий запис для розгортання ресурсів, ви можете створити інші облікові записи для розділення різних AWS інфраструктур між ними.

Це дуже цікаво з точки зору безпеки, оскільки один обліковий запис не зможе отримати доступ до ресурсів з іншого облікового запису (крім випадків, коли спеціально створюються мости), таким чином ви можете створити межі між розгортаннями.

Отже, існують два типи облікових записів в організації (ми говоримо про облікові записи AWS, а не облікові записи користувачів): один обліковий запис, який призначений як обліковий запис управління, та один або кілька облікових записів учасників.

Обліковий запис управління (кореневий обліковий запис) - це обліковий запис, який ви використовуєте для створення організації. З облікового запису управління організації ви можете виконувати наступні дії:
Створювати облікові записи в організації
Запрошувати інші існуючі облікові записи до організації
Видаляти облікові записи з організації
Керувати запрошеннями
Застосовувати політику до сутностей (корені, ОУ або облікові записи) всередині організації
Увімкнути інтеграцію з підтримуваними службами AWS для надання функціональності служби у всіх облікових записах організації.
Можливо увійти як користувач кореневого облікового запису, використовуючи електронну адресу та пароль, використані для створення цього кореневого облікового запису/організації.

Обліковий запис управління має відповідальність платника і відповідає за оплату всіх витрат, які накопичуються обліковими записами учасників. Ви не можете змінити обліковий запис управління організації.

Облікові записи учасників складаються з усіх інших облікових записів в організації. Обліковий запис може бути учасником лише однієї організації одночасно. Ви можете прикріпити політику до облікового запису, щоб застосовувати контроль лише до цього облікового запису.
Облікові записи учасників мають використовувати дійсну адресу електронної пошти і можуть мати ім'я, в цілому вони не зможуть керувати розрахунками (але їм може бути надано доступ до них).

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

Організаційні одиниці

Акаунти можна групувати в Організаційні одиниці (OU). Таким чином, ви можете створювати політики для Організаційної одиниці, які будуть застосовуватися до всіх дочірніх акаунтів. Зверніть увагу, що OU може мати інші OU як дочірні.

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

Політика керування службою (SCP)

Політика керування службою (SCP) - це політика, яка визначає служби та дії, які користувачі та ролі можуть використовувати в облікових записах, на які впливає SCP. SCP подібні до політик дозволів IAM, за винятком того, що вони не надають жодних дозволів. Замість цього SCP визначають максимальні дозволи для організації, одиниці організації (OU) або облікового запису. Коли ви прикріплюєте SCP до кореня вашої організації або OU, SCP обмежує дозволи для сутностей в облікових записах учасників.

Це ЄДИНИЙ спосіб, як навіть кореневий користувач може бути зупинений від виконання чогось. Наприклад, його можна використовувати для зупинки користувачів від вимкнення CloudTrail або видалення резервних копій. Єдиний спосіб обійти це - скомпрометувати також головний обліковий запис, який налаштовує SCP (головний обліковий запис не може бути заблокований).

Зауважте, що SCP обмежують лише принципали в обліковому записі, тому інші облікові записи не постраждають. Це означає, що відмова SCP у s3:GetObject не зупинить людей від доступу до публічного відра S3 у вашому обліковому записі.

Приклади SCP:

Відмова від кореневого облікового запису повністю
Дозвіл лише на певні регіони
Дозвіл лише на білі списки служб
Відмова від вимкнення GuardDuty, CloudTrail та S3 Public Block Access
Відмова від видалення ролей безпеки/відповіді на інциденти
Відмова від видалення резервних копій
Відмова від створення користувачів IAM та ключів доступу

Знайдіть приклади JSON за посиланням https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Ім'я ресурсу Amazon (ARN) - це унікальне ім'я кожного ресурсу всередині AWS, воно складається таким чином:

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

Зауважте, що в AWS є 4 розділи, але тільки 3 способи їх виклику:

AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws

IAM - Identity and Access Management

IAM - це служба, яка дозволяє керувати Аутентифікацією, Авторизацією та Контролем доступу всередині вашого облікового запису AWS.

Аутентифікація - Процес визначення ідентичності та перевірка цієї ідентичності. Цей процес може бути розділений на: Ідентифікацію та перевірку.
Авторизація - Визначає, до чого може мати доступ ідентичність у системі після того, як її аутентифікували.
Контроль доступу - Метод та процес надання доступу до захищеного ресурсу

IAM може бути визначений за його здатністю керувати, контролювати та управляти механізмами аутентифікації, авторизації та контролю доступу ідентичностей до ваших ресурсів у межах вашого облікового запису AWS.

Кореневий користувач облікового запису AWS

Коли ви вперше створюєте обліковий запис Amazon Web Services (AWS), ви починаєте з одного ідентифікатора входу, який має повний доступ до всіх служб та ресурсів AWS в обліковому записі. Це користувач кореневого користувача облікового запису AWS і доступ до нього здійснюється шляхом входу за допомогою адреси електронної пошти та пароля, які ви використали для створення облікового запису.

Зауважте, що новий адміністратор матиме менше дозволів, ніж кореневий користувач.

З точки зору безпеки рекомендується створювати інших користувачів та уникати використання цього.

Користувачі IAM

Користувач IAM - це сутність, яку ви створюєте в AWS для представлення особи або додатку, які використовують його для взаємодії з AWS. Користувач в AWS складається з імені та облікових даних (пароль та до двох ключів доступу).

Коли ви створюєте користувача IAM, ви надаєте йому дозволи, зробивши його членом групи користувачів, до якої додаються відповідні політики дозволів (рекомендовано), або прямо прикріплюючи політики до користувача.

Користувачі можуть мати ввімкнене MFA для входу через консоль. API-токени користувачів з ввімкненим MFA не захищені MFA. Якщо ви хочете обмежити доступ до ключів API користувачів за допомогою MFA, вам потрібно вказати в політиці, що для виконання певних дій потрібно наявність MFA (приклад тут).

CLI

Ідентифікатор ключа доступу: 20 випадкових великих літерно-цифрових символів, наприклад AKHDNAPO86BSHKDIRYT
Секретний ідентифікатор ключа доступу: 40 випадкових символів верхнього та нижнього регістрів: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (неможливо відновити втрачені секретні ідентифікатори ключів доступу).

Кожного разу, коли вам потрібно змінити ключ доступу, ви повинні дотримуватися цього процесу: Створити новий ключ доступу -> Застосувати новий ключ до системи/додатку -> позначити початковий ключ як неактивний -> Перевірити та підтвердити, що новий ключ доступу працює -> Видалити старий ключ доступу

MFA - Багатофакторна аутентифікація

Використовується для створення додаткового фактора аутентифікації на додаток до ваших існуючих методів, таких як пароль, тим самим створюючи багатофакторний рівень аутентифікації. Ви можете використовувати безкоштовне віртуальне додаток або фізичний пристрій. Ви можете використовувати додатки, наприклад google authentication, безкоштовно для активації MFA в AWS.

Політики з умовами MFA можуть бути прикріплені до наступного:

Користувача або групи IAM
Ресурсу, такого як відрізок Amazon S3, черга Amazon SQS або тема Amazon SNS
Довіри до ролі IAM, яку може припустити користувач

Якщо ви хочете отримати доступ через CLI до ресурсу, який перевіряє MFA, вам потрібно викликати GetSessionToken. Це надасть вам токен з інформацією про MFA. Зауважте, що підтвердження AssumeRole не містить цієї інформації.

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

Як зазначено тут, існує багато випадків, коли MFA не може бути використаний.

Групи користувачів IAM

Група користувачів IAM - це спосіб прикріплення політик до кількох користувачів одночасно, що може спростити управління дозволами для цих користувачів. Ролі та групи не можуть бути частиною групи.

Ви можете прикріпити політику на основі ідентичності до групи користувачів, щоб всі користувачі у групі користувачів отримували дозволи політики. Ви не можете ідентифікувати групу користувачів як Principal у політиці (наприклад, у політиці на основі ресурсів), оскільки групи стосуються дозволів, а не аутентифікації, і принципали - аутентифіковані сутності IAM.

Ось деякі важливі характеристики груп користувачів:

Група може містити багато користувачів, і користувач може належати до декількох груп.
Групи користувачів не можуть бути вкладені; вони можуть містити лише користувачів, а не інші групи користувачів.
Немає стандартної групи користувачів, яка автоматично включає всіх користувачів у обліковому записі AWS. Якщо ви хочете мати таку групу користувачів, вам потрібно створити її та призначити кожного нового користувача до неї.
Кількість та розмір ресурсів IAM у обліковому записі AWS, такі як кількість груп та кількість груп, членом яких може бути користувач, обмежені. Для отримання додаткової інформації див. IAM та квоти AWS STS.

Ролі IAM

Роль IAM дуже схожа на користувача, оскільки це ідентичність з політиками дозволів, які визначають, що вона може і не може робити в AWS. Однак роль не має жодних облікових даних (пароль або ключі доступу), пов'язаних з нею. Замість того, щоб бути унікально пов'язаним з однією особою, роль призначена для прийняття будь-ким, хто потребує цього (і має достатньо дозволів). Користувач IAM може припускати роль тимчасово, щоб надати різні дозволи для конкретного завдання. Роль може бути призначена для федерованого користувача, який увійшовши в систему, використовує зовнішнього постачальника ідентичності замість IAM.

Роль IAM складається з двох типів політик: політика довіри, яка не може бути порожньою, визначаючи хто може припускати роль, та політика дозволів, яка не може бути порожньою, визначаючи що вона може отримати доступ.

Служба безпеки AWS (STS)

Служба безпеки AWS (STS) - це веб-служба, яка сприяє видачі тимчасових обмежених привілеїв. Вона спеціально призначена для:

Тимчасові облікові дані в IAM

Тимчасові облікові дані використовуються в основному з ролями IAM, але є й інші використання. Ви можете запитати тимчасові облікові дані, які мають більш обмежений набір дозволів, ніж ваш стандартний користувач IAM. Це запобігає вам випадковому виконанню завдань, які не дозволені більш обмеженими обліковими даними. Перевагою тимчасових облікових даних є те, що вони автоматично закінчуються після встановленого періоду часу. Ви маєте контроль над тим, на який термін дійсні облікові дані.

Політики

Дозволи політики

Використовуються для призначення дозволів. Є 2 типи:

Керовані політики AWS (передвстановлені AWS)
Керовані політики клієнта: Налаштовані вами. Ви можете створювати політики на основі керованих політик AWS (змінюючи одну з них та створюючи свою власну), використовуючи генератор політик (інтерфейс з графічним відображенням, який допомагає вам надавати та відмовляти в дозволах) або пишучи свої власні..

За замовчуванням доступ заборонено, доступ буде наданий, якщо було вказано явну роль. Якщо існує одне "Відмовити", воно перевершить "Дозволити", за винятком запитів, які використовують кореневі облікові дані безпеки облікового запису AWS (які за замовчуванням дозволені).

{
"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"}
}
}
]
}

Глобальні поля, які можуть бути використані для умов у будь-якому сервісі, документовані тут. Конкретні поля, які можуть бути використані для умов на кожному сервісі, документовані тут.

Вбудовані політики

Цей тип політик прямо призначений для користувача, групи або ролі. Тоді вони не з'являються у списку політик, як будь-який інший може їх використовувати. Вбудовані політики корисні, якщо ви хочете зберігати строгий один-до-одного відношення між політикою та ідентичністю, до якої вона застосовується. Наприклад, ви хочете бути впевнені, що дозволи в політиці не будуть ненавмисно надані іншій ідентичності, ніж та, для якої вони призначені. Коли ви використовуєте вбудовану політику, дозволи в політиці не можуть бути ненавмисно прикріплені до неправильної ідентичності. Крім того, коли ви використовуєте консоль керування AWS для видалення цієї ідентичності, вбудовані в ідентичність політики також видаляються. Це тому, що вони є частиною основної сутності.

Політики ресурсів віджучка

Це політики, які можуть бути визначені в ресурсах. Не всі ресурси AWS підтримують їх.

Якщо у суб'єкта немає явного заперечення щодо них, і політика ресурсу надає їм доступ, то вони дозволені.

Межі IAM

Межі IAM можуть бути використані для обмеження дозволів, до яких користувач або роль повинні мати доступ. Таким чином, навіть якщо користувачу надано інший набір дозволів за допомогою іншої політики, операція завершиться невдачею, якщо він спробує їх використовувати.

Межа - це просто політика, прикріплена до користувача, яка вказує максимальний рівень дозволів, які може мати користувач або роль. Таким чином, навіть якщо у користувача є адміністративний доступ, якщо межа вказує, що він може лише читати S3-ведра, це максимум, що він може зробити.

Це, SCP та дотримання принципу найменших привілеїв - це способи контролювати, щоб користувачі не мали більше дозволів, ніж ті, які вони потребують.

Політики сеансу

Політика сеансу - це політика, встановлена при припущенні ролі якимось чином. Це буде схоже на межу IAM для цього сеансу: Це означає, що політика сеансу не надає дозволів, але обмежує їх до тих, що вказані в політиці (максимальні дозволи - ті, які має роль).

Це корисно для заходів безпеки: коли адміністратор збирається припустити дуже привілейовану роль, він може обмежити дозвіл лише до тих, що вказані в політиці сеансу в разі компрометації сеансу.

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

За замовчуванням AWS може додавати політики сесій до сесій, які будуть створені через треті причини. Наприклад, у невідомих ролях Cognito за замовчуванням (використовуючи покращену аутентифікацію), AWS буде генерувати сесійні облікові дані з політикою сесії, яка обмежує сервіси, які може отримати доступ до сесії до наступного списку.

Отже, якщо ви стикаєтеся з помилкою "... тому що жодна політика сесії не дозволяє ...", і роль має доступ для виконання дії, це через наявність політики сесії, яка цьому заважає.

Ідентифікація Федерації

Ідентифікація федерації дозволяє користувачам з зовнішніх постачальників ідентичності отримувати доступ до ресурсів AWS без необхідності надавати облікові дані користувача AWS від дійсного облікового запису IAM. Прикладом постачальника ідентичності може бути ваш корпоративний Microsoft Active Directory(через SAML) або служби OpenID (наприклад, Google). Федеративний доступ дозволить користувачам у ньому отримувати доступ до AWS.

Для налаштування цього довіри, створюється постачальник ідентичності IAM (SAML або OAuth), який буде довіряти іншій платформі. Потім, принаймні одна роль IAM призначається (довіряється) постачальнику ідентичності. Якщо користувач з довіреної платформи отримує доступ до AWS, він отримає доступ як зазначена роль.

Однак зазвичай ви захочете надати різні ролі в залежності від групи користувачів у платформі третьої сторони. Тоді кілька ролей IAM можуть довіряти постачальнику ідентичності третьої сторони, і саме третя сторона буде дозволяти користувачам припускати одну роль або іншу.

Центр Ідентичності IAM

Центр ідентичності IAM AWS (наступник AWS Single Sign-On) розширює можливості управління ідентичністю та доступом AWS (IAM), щоб забезпечити центральне місце, яке об'єднує адміністрування користувачів та їх доступ до облікових записів AWS та хмарних додатків.

Домен для входу буде виглядати як <user_input>.awsapps.com.

Для входу користувачів можна використовувати 3 джерела ідентичності:

Довідник Центру Ідентичності: Звичайні користувачі AWS
Active Directory: Підтримує різні конектори
Зовнішній постачальник ідентичності: Усі користувачі та групи постачальника зовнішньої ідентичності (IdP)

У найпростішому випадку довідника Центру Ідентичності, Центр Ідентичності матиме список користувачів та груп і зможе призначати політики для них до будь-яких облікових записів організації.

Для надання доступу користувачеві/групі Центру Ідентичності до облікового запису буде створено постачальника ідентичності SAML, який довіряє Центру Ідентичності, і в обліковому записі призначення буде створено роль, яка довіряє постачальнику ідентичності з вказаними політиками.

AwsSSOInlinePolicy

Можливо надавати дозволи через вбудовані політики ролям, створеним через Центр Ідентичності IAM. Ролі, створені в облікових записах, які отримують вбудовані політики в Центрі Ідентичності AWS, матимуть ці дозволи в вбудованій політиці під назвою AwsSSOInlinePolicy.

Отже, навіть якщо ви бачите 2 ролі з вбудованою політикою під назвою AwsSSOInlinePolicy, це не означає, що вони мають однакові дозволи.

Довіра та Ролі між Обліковими записами

Користувач (довіряючий) може створити Роль між Обліковими записами з деякими політиками, а потім, дозволити іншому користувачеві (довіреному) отримати доступ до його облікового запису, але лише з доступом, вказаним у нових політиках ролі. Для цього просто створіть нову Роль та виберіть Роль між Обліковими записами. Ролі для доступу між обліковими записами пропонують два варіанти. Надання доступу між обліковими записами AWS, які ви володієте, та надання доступу між обліковим записом, який ви володієте, та обліковим записом AWS третьої сторони. Рекомендується вказати користувача, якому довіряють, і не вказувати загальні дані, оскільки в іншому випадку інші аутентифіковані користувачі, такі як федеровані користувачі, також зможуть зловживати цим довір'ям.

AWS Simple AD

Не підтримується:

Довірчі відносини
Центр адміністрування AD
Повна підтримка PS API
Кошик для відновлення AD
Керовані облікові записи служб
Розширення схеми
Відсутність прямого доступу до ОС або екземплярів

Веб-федерація або Аутентифікація OpenID

Додаток використовує AssumeRoleWithWebIdentity для створення тимчасових облікових даних. Однак це не надає доступ до консолі AWS, лише доступ до ресурсів у межах AWS.

Інші опції IAM

Ви можете встановити політику пароля, вказавши параметри, такі як мінімальна довжина та вимоги до пароля.
Ви можете завантажити "Звіт про облікові дані" з інформацією про поточні облікові дані (наприклад, час створення користувача, чи увімкнений пароль...). Ви можете генерувати звіт про облікові дані не частіше одного разу кожні чотири години.

Управління ідентичністю та доступом AWS (IAM) надає деталізований контроль доступу до всіх служб AWS. За допомогою IAM ви можете вказати, хто може отримати доступ до яких служб та ресурсів, і за яких умов. За допомогою політик IAM ви керуєте дозволами для вашого персоналу та систем, щоб забезпечити найменші дозволи.

Префікси ID IAM

На цій сторінці ви можете знайти префікси ID IAM ключів в залежності від їх природи:

ABIA

AWS STS service bearer token

ACCA

Конкретні облікові дані

AGPA

Група користувачів

AIDA

Користувач IAM

AIPA

Профіль екземпляра Amazon EC2

AKIA

Ключ доступу

ANPA

Керована політика

ANVA

Версія в керованій політиці

APKA

Публічний ключ

AROA

Роль

ASCA

Сертифікат

ASIA

Тимчасові (AWS STS) ідентифікатори ключів доступу використовують цей префікс, але вони є унікальними лише в поєднанні з секретним ключем доступу та токеном сесії.

Різне

Аутентифікація CLI

Для того, щоб звичайний користувач міг аутентифікуватися в AWS через CLI, вам потрібно мати локальні облікові дані. За замовчуванням ви можете налаштувати їх вручну в ~/.aws/credentials або запустивши aws configure. У цьому файлі може бути більше одного профілю, якщо не вказано жодного профілю за допомогою aws cli, буде використаний той, який називається [default] в цьому файлі. Приклад файлу облікових даних з більш ніж 1 профілем:

[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

Якщо вам потрібно отримати доступ до різних облікових записів AWS і ваш профіль має доступ до припущення ролі всередині цих облікових записів, вам не потрібно викликати вручну STS кожного разу (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) та налаштовувати облікові дані.

Ви можете використовувати файл ~/.aws/config для вказання ролей для припущення, а потім використовувати параметр --profile як зазвичай (операція assume-role буде виконана прозоро для користувача). Приклад файлу конфігурації:

[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

З цим файлом конфігурації ви можете використовувати aws cli наступним чином:

aws --profile acc2 ...

Якщо ви шукаєте щось схоже на це, але для браузера, ви можете перевірити розширення AWS Extend Switch Roles.

Посилання