Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Підтримайте HackTricks

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

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

В 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

Service Control Policy (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 - Управління ідентифікацією та доступом

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

  • ID ключа доступу: 20 випадкових великих алфавітно-цифрових символів, таких як AKHDNAPO86BSHKDIRYT

  • ID секретного ключа доступу: 40 випадкових великих і малих символів: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (неможливо відновити втрачені ID секретних ключів доступу).

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

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

Вона використовується для створення додаткового фактора для аутентифікації на додаток до ваших існуючих методів, таких як пароль, тим самим створюючи багатофакторний рівень аутентифікації. Ви можете використовувати безкоштовний віртуальний додаток або фізичний пристрій. Ви можете безкоштовно використовувати такі програми, як Google Authenticator, щоб активувати 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 (модифікуючи одну з них і створюючи свою), використовуючи генератор політик (GUI, що допомагає вам надавати та відмовляти в дозволах) або написавши свої власні.

За замовчуванням доступ заборонено, доступ буде надано, якщо була вказана явна роль. Якщо існує єдиний "Deny", він переважатиме над "Allow", за винятком запитів, які використовують кореневі облікові дані безпеки облікового запису 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"}
}
}
]
}

The глобальні поля, які можна використовувати для умов у будь-якій службі, задокументовані тут. Специфічні поля, які можна використовувати для умов для кожної служби, задокументовані тут.

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

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

Політики ресурсних кошиків

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

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

Межі IAM

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

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

Це, 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 без необхідності надавати облікові дані користувача AWS з дійсного облікового запису IAM. Прикладом постачальника ідентичності може бути ваш власний корпоративний Microsoft Active Directory (через SAML) або OpenID сервіси (як Google). Федеративний доступ дозволить користувачам всередині нього отримувати доступ до AWS.

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

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

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

AWS IAM Центр ідентичності (наступник AWS Single Sign-On) розширює можливості AWS Identity and Access Management (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 Identity and Access Management (IAM) забезпечує точний контроль доступу по всій AWS. З IAM ви можете вказати, хто може отримати доступ до яких сервісів і ресурсів, і за яких умов. За допомогою політик IAM ви керуєте дозволами для вашої робочої сили та систем, щоб забезпечити найменші привілеї.

Префікси IAM ID

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

ABIA

Токен носія служби AWS STS

ACCA

Облікові дані, специфічні для контексту

AGPA

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

AIDA

Користувач IAM

AIPA

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

AKIA

Ключ доступу

ANPA

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

ANVA

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

APKA

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

AROA

Роль

ASCA

Сертифікат

ASIA

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

Рекомендовані дозволи для аудиту облікових записів

Наступні привілеї надають різний доступ для читання метаданих:

  • 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

Різне

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 як зазвичай (прийняття ролі буде виконано прозоро для користувача). Приклад конфігураційного файлу:

[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.

Посилання

Підтримати HackTricks
PreviousAWS PentestingNextAWS - Federation Abuse

Last updated