AWS IAM — Identity and Access Management

Хтось отримав ваш рахунок на $47 000

Це не вигаданий сценарій. Щороку сотні розробників по всьому світу отримують несподівані рахунки від AWS на тисячі — а іноді й десятки тисяч — доларів. Сценарій завжди однаковий: розробник випадково завантажив файл credentials або вставив ключ доступу прямо у вихідний код, запушив у публічний GitHub-репозиторій, а через 10–15 хвилин автоматичний бот знайшов ці ключі і почав запускати сотні EC2 інстансів для майнінгу криптовалюти.

Ця проблема має дві причини: некоректне зберігання credentials і надмірні привілеї — коли один скомпрометований ключ дає доступ до всього акаунту. Обидві причини вирішуються правильним використанням AWS IAM.

AWS Identity and Access Management (IAM) — це фундаментальний сервіс AWS, який відповідає на три питання:

1. Хто звертається до ресурсів AWS? (аутентифікація)
2. Що цьому «хто» дозволено робити? (авторизація)
3. З якими ресурсами дозволено взаємодіяти?

IAM — це не окремий сервіс, який можна вимкнути чи обійти. Це наскрізний механізм, вбудований у кожен запит до будь-якого сервісу AWS. Кожного разу, коли ви відкриваєте S3 bucket, запускаєте EC2 інстанс або викликаєте Lambda-функцію — AWS перевіряє IAM: чи маєте ви право на цю дію.

Архітектура IAM: чотири ключові сутності

IAM оперує чотирма основними сутностями: Users, Groups, Roles та Policies. Розберемо кожну з них детально — з аналогіями, які допоможуть зрозуміти концепцію до того, як ви побачите перший рядок JSON.

Аналогія: система пропусків у компанії

Уявіть велике офісне приміщення з різними кімнатами: серверна, бухгалтерія, переговорна, зона розробки, архів. Кожна кімната вимагає певного рівня доступу.

• IAM User — конкретна людина з іменним пропуском (Іван Петренко, розробник)
• IAM Group — відділ, усі члени якого мають однаковий рівень доступу (відділ розробки)
• IAM Policy — документ із переліком кімнат, до яких пропуск дає доступ, і що в них дозволено робити
• IAM Role — тимчасовий пропуск для гостя або підрядника: він видається на певний час і для конкретної задачі

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

actor "Іван (Developer)" as User
rectangle "Група: Developers" as Group #dbeafe
rectangle "Policy: S3ReadOnly" as P1 #d1fae5
rectangle "Policy: EC2StartStop" as P2 #d1fae5
rectangle "Policy: LambdaInvoke" as P3 #d1fae5

User -right-> Group : належить до
Group -down-> P1 : прикріплена
Group -down-> P2 : прикріплена

note right of P3
  Policy також можна
  прикріпити напряму до User
end note

User -down-> P3 : напряму
@enduml

IAM Users — облікові записи для людей і програм

IAM User — це сутність, яка представляє конкретну людину або програму, що взаємодіє з AWS. Кожен User має унікальне ім'я всередині акаунту та власний набір credentials (облікових даних).

Існує два типи credentials для IAM User:

1. Username + Password — для входу в AWS Management Console (веб-інтерфейс). Лише люди використовують цей тип — браузер відкривається, людина вводить логін і пароль.

2. Access Key ID + Secret Access Key — для програмного доступу: AWS CLI, AWS SDK у вашому .NET-коді, CI/CD pipelines. Це пара рядків, наприклад:

• Access Key ID: AKIAIOSFODNN7EXAMPLE
• Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Разом вони виступають як логін і пароль, але для програмного доступу. Secret Access Key показується лише один раз — у момент створення. Якщо ви його втратили — доведеться створювати нову пару ключів.

Скільки IAM Users потрібно?

Правило просте: один реальний User на одну людину або одну програму. Не треба шерити один акаунт між кількома розробниками — так неможливо відслідкувати, хто що зробив. Не треба використовувати свій особистий ключ у CI/CD pipeline — якщо ключ потрапить у логи, постраждає весь ваш акаунт.

IAM Groups — управління доступом для команд

IAM Group — це іменована колекція IAM Users, яким надаються однакові права. Ключова перевага: замість того, щоб призначати Policy кожному User окремо, ви призначаєте Policy один раз групі — і всі її члени автоматично отримують ці права.

Типова структура груп у реальній команді:

Важливі обмеження IAM Groups:

• User може належати до кількох груп одночасно
• Групи не можуть містити інші групи (немає вкладеності)
• Groups не мають власних credentials — вони лише об'єднують Users

Принцип найменших привілеїв (Least Privilege Principle)

Принцип найменших привілеїв (Principle of Least Privilege, PoLP) — це фундаментальний принцип безпеки, який гласить: кожна сутність (User, Role, програма) повинна мати лише ті права, які необхідні для виконання її конкретної задачі, і нічого більше.

Це звучить очевидно, але на практиці порушується постійно через зручність. Розглянемо типовий антипатерн:

«Дайте всьому акаунту AdministratorAccess — так простіше, і ми не будемо витрачати час на налаштування прав».

Ця «зручність» перетворюється на катастрофу, якщо:

• Один скомпрометований ключ дає зловмиснику повний контроль над усією інфраструктурою
• Розробник випадково видаляє production базу даних, маючи права на Delete
• CI/CD pipeline із зайвими правами може стати вектором атаки

Правильний підхід: починати з нуля прав і додавати лише те, що реально потрібно. AWS надає для цього зручний інструмент — IAM Access Analyzer, який аналізує реальне використання ресурсів і підказує, які права можна безпечно видалити.

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

package "Антипатерн (небезпечно)" #fef3c7 {
    actor "Dev User" as DevBad
    rectangle "AdministratorAccess\n(повний доступ до всього)" as AdminPolicy #fecaca
    DevBad -right-> AdminPolicy
    note bottom of AdminPolicy
        Якщо ключ скомпрометований —
        зловмисник має повний контроль
    end note
}

package "Правильно (Least Privilege)" #d1fae5 {
    actor "Dev User" as DevGood
    rectangle "S3: GetObject, PutObject\n(лише dev-* buckets)" as P1 #bbf7d0
    rectangle "EC2: Describe, Start, Stop\n(лише us-east-1)" as P2 #bbf7d0
    rectangle "RDS: Connect\n(лише dev-db)" as P3 #bbf7d0
    DevGood -right-> P1
    DevGood -right-> P2
    DevGood -right-> P3
}
@enduml

IAM Policies — документи прав доступу

IAM Policy — це JSON-документ, який точно описує, що дозволено або заборонено робити з якими ресурсами AWS. Policy — це серце всієї системи IAM. Без Policy жоден User або Role не може нічого зробити: за замовчуванням усе заборонено.

Анатомія IAM Policy

Розглянемо реальну Policy і розберемо кожен елемент детально:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadOnDevBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::dev-*",
                "arn:aws:s3:::dev-*/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "eu-central-1"
                }
            }
        },
        {
            "Sid": "DenyDeleteAnywhere",
            "Effect": "Deny",
            "Action": "s3:DeleteObject",
            "Resource": "*"
        }
    ]
}

Розберемо кожне поле цього документа:

Version — версія мови IAM Policy. Завжди вказуйте "2012-10-17" — це остання версія, яка підтримує всі сучасні можливості (зокрема змінні Policy). Старіша версія "2008-10-17" існує лише для зворотної сумісності.

Statement — масив правил. Один документ Policy може містити кілька Statement — кожне описує окремий набір дозволів або заборон.

Sid (Statement ID) — довільний ідентифікатор правила для зручності читання. Не є обов'язковим, але значно спрощує розуміння великих Policy. Використовуйте описові назви: AllowS3ReadOnDevBuckets, DenyDeleteProductionDB.

Effect — найважливіше поле. Приймає лише два значення:

• "Allow" — дозволяє вказані дії
• "Deny" — категорично забороняє. Важливо: Deny завжди перемагає Allow. Якщо є хоча б одне правило Deny для певної дії — вона заборонена, навіть якщо є десять правил Allow.

Action — конкретні API-операції AWS. Формат: сервіс:ДіяAPI. Наприклад:

• s3:GetObject — завантажити об'єкт з S3
• ec2:StartInstances — запустити EC2 інстанс
• rds:CreateDBInstance — створити RDS базу даних
• * — всі дії (використовуйте обережно!)
• s3:* — всі дії для S3

Resource — до яких конкретних ресурсів застосовується правило. Ресурси ідентифікуються через ARN (Amazon Resource Name) — унікальну адресу будь-якого ресурсу в AWS.

ARN — Amazon Resource Name

ARN — це рядок, який однозначно ідентифікує будь-який ресурс в AWS. Формат:

arn:partition:service:region:account-id:resource

Приклади ARN:

arn:aws:s3:::my-bucket                  ← S3 bucket (без регіону та account-id!)
arn:aws:s3:::my-bucket/*                ← всі об'єкти в bucket
arn:aws:ec2:eu-central-1:123456789012:instance/i-1234567890abcdef0
arn:aws:iam::123456789012:user/ivan
arn:aws:lambda:eu-central-1:123456789012:function:my-function

Символ * у ARN є wildcard: arn:aws:s3:::dev-* — всі bucket, що починаються на dev-.

Condition — необов'язкове поле, яке дозволяє додати умови до правила. Наприклад, дозволити дію лише з певного IP-діапазону, лише в певному регіоні, лише якщо використовується MFA, лише для конкретних тегів ресурсів. Умови роблять Policy надзвичайно гнучкими.

Типи IAM Policies

Як AWS перевіряє доступ (Policy Evaluation Logic)

Коли надходить запит до AWS API, система перевіряє дозволи у такому порядку:

1. Чи є явне Deny? → ТАК → ВІДМОВА
2. Чи є явне Allow? → ТАК → ДОЗВОЛЕНО
3. Нічого немає → ВІДМОВА (implicit deny)

Це означає: за замовчуванням усе заборонено. Потрібно явно дозволяти кожну дію. І якщо є хоча б одне Deny — воно перевищує будь-яку кількість Allow.

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

start
:Запит до AWS API;
if (Є explicit Deny
у будь-якій Policy?) then (Так)
    :ВІДМОВА
(Access Denied);
    stop
else (Ні)
    if (Є explicit Allow
у будь-якій Policy?) then (Так)
        :ДОЗВОЛЕНО;
        stop
    else (Ні)
        :ВІДМОВА
(Implicit Deny);
        stop
    endif
endif
@enduml

IAM Roles — тимчасові ідентифікації без паролів

IAM Role — це сутність IAM, яка кардинально відрізняється від IAM User. У Role немає постійних credentials (ні пароля, ні фіксованих Access Keys). Натомість, коли роль «приймається» (assumed) — AWS видає тимчасові credentials, які автоматично закінчуються через певний час (від 15 хвилин до 12 годин).

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

Де використовуються IAM Roles

Roles є основним механізмом надання доступу для сервісів AWS та програм — не людей. Розглянемо головні сценарії:

Сценарій 1: EC2 Instance Role

Ваш .NET API запущений на EC2. Він потребує доступу до S3 для зберігання файлів. Як передати credentials у застосунок?

Погано (так не треба робити):

// НЕ РОБІТЬ ТАК!!! Credentials у коді — це катастрофа
var s3Client = new AmazonS3Client("AKIAIOSFODNN7EXAMPLE", "wJalrXUtnFEMI...");

Правильно: створіть IAM Role з Policy s3:PutObject/GetObject і прикріпіть її до EC2 інстансу. AWS SDK автоматично отримає тимчасові credentials через Instance Metadata Service (IMDS) — внутрішній endpoint 169.254.169.254, доступний лише всередині EC2.

// ПРАВИЛЬНО: AWS SDK сам знаходить credentials через EC2 Instance Role
var s3Client = new AmazonS3Client(RegionEndpoint.EUCentral1);
// Credentials отримуються автоматично з IMDS — жодних ключів у коді!

Сценарій 2: Lambda Execution Role

Lambda-функція завжди виконується під певною IAM Role. Ця роль визначає, до яких сервісів функція має доступ. Мінімальна роль для Lambda: AWSLambdaBasicExecutionRole (лише запис логів у CloudWatch). Якщо Lambda пише в DynamoDB — додайте відповідну Policy.

Сценарій 3: Cross-Account Access

Ваша компанія має два AWS акаунти: production (акаунт A) та development (акаунт B). Розробнику з акаунту B потрібен читаючий доступ до S3 в акаунті A. Рішення: створіть Role в акаунті A, яка дозволяє assume її з акаунту B. Розробник «приймає» цю роль і отримує тимчасові credentials для акаунту A.

Сценарій 4: SAML / SSO Federation

Якщо ваша компанія використовує корпоративний Identity Provider (Active Directory, Okta, Google Workspace) — співробітники можуть входити в AWS через корпоративний логін, не маючи окремого IAM User. AWS Federation видає тимчасову Role при вході.

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

actor "Developer" as Dev
rectangle "IAM Role: EC2-S3-ReadWrite" as Role #dbeafe {
    note right
        Trust Policy: EC2 може
        прийняти цю роль
    end note
}

node "EC2 Instance
(.NET API)" as EC2 #d1fae5
database "S3 Bucket
(files)" as S3

rectangle "AWS STS" as STS #fce7f3 {
    note right
        Видає тимчасові credentials:
        AccessKeyId, SecretAccessKey,
        SessionToken (1h-12h)
    end note
}

EC2 -up-> STS : AssumeRole request
STS -right-> Role : Перевіряє Trust Policy
STS -down-> EC2 : Тимчасові credentials
EC2 -right-> S3 : Доступ через
тимчасові credentials
@enduml

Trust Policy — хто може прийняти роль

У IAM Role є два типи Policy:

• Permission Policy — що дозволено робити (стандартна IAM Policy)
• Trust Policy — хто може прийняти цю роль

Trust Policy — це також JSON-документ, але він визначає Principal (того, кому дозволено assume роль):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Ця Trust Policy дозволяє EC2-сервісу приймати роль. Для Lambda це буде lambda.amazonaws.com, для cross-account — ARN іншого акаунту.

MFA — Multi-Factor Authentication

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

MFA для IAM Users

AWS підтримує кілька типів MFA-пристроїв:

MFA як умова доступу в Policy

Одна з потужних можливостей IAM — вимагати MFA через умову в Policy. Наприклад, можна дозволити певні критичні операції лише якщо користувач авторизований з MFA:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEC2ManagementOnlyWithMFA",
            "Effect": "Allow",
            "Action": [
                "ec2:TerminateInstances",
                "rds:DeleteDBInstance"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

Ця Policy дозволяє видалення EC2 інстансів та RDS баз даних лише тим, хто увійшов з підтвердженим MFA.

AWS Organizations — управління множинними акаунтами

У реальних компаніях рідко є лише один AWS-акаунт. Зазвичай є мінімум три: development, staging та production. У великих компаніях — десятки або навіть сотні акаунтів для різних команд, продуктів та середовищ. AWS Organizations — це сервіс, який дозволяє централізовано управляти всіма цими акаунтами з одного місця.

Навіщо взагалі кілька акаунтів? Ізоляція — ключова відповідь. Якщо розробник випадково виконає aws ec2 terminate-instances --instance-ids --all у production — це катастрофа. Якщо він зробить це у dev-акаунті — ніхто навіть не помітить. Окремі акаунти дають жорстку ізоляцію між середовищами: помилки в одному не можуть вплинути на інший.

Структура Organizations

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

package "AWS Organization" {
    rectangle "Management Account
(Root)" as Root #fef3c7 {
        note right : Центральний акаунт.
Управляє всіма дочірніми.
    }

    package "OU: Engineering" as EngOU #dbeafe {
        rectangle "Account: Development" as Dev
        rectangle "Account: Staging" as Stage
    }

    package "OU: Production" as ProdOU #fce7f3 {
        rectangle "Account: Production EU" as ProdEU
        rectangle "Account: Production US" as ProdUS
    }

    package "OU: Shared Services" as SharedOU #d1fae5 {
        rectangle "Account: Logging" as Log
        rectangle "Account: Security" as Sec
    }

    Root -down-> EngOU
    Root -down-> ProdOU
    Root -down-> SharedOU
}
@enduml

Management Account (раніше Master Account) — головний акаунт організації. Він оплачує рахунки всіх дочірніх акаунтів (consolidated billing) і може накладати обмеження через SCPs.

Organizational Unit (OU) — логічна група акаунтів. Наприклад, OU Production містить production-акаунти, OU Engineering — dev та staging.

Service Control Policies (SCPs) — захисний пояс організації

Service Control Policies (SCPs) — це особливий тип Policy, який застосовується на рівні Organization або OU і обмежує максимально можливі права для всіх акаунтів у цій гілці.

Критично важливо: SCPs не надають прав — вони лише обмежують. SCP — це стеля. IAM Policy всередині акаунту може лише зменшити доступ, але не може дати більше, ніж дозволяє SCP.

Приклад реального SCP: заборонити будь-яке відхилення від затверджених регіонів.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllRegionsExceptEU",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-central-1",
                        "eu-west-1"
                    ]
                }
            }
        }
    ]
}

Ця SCP гарантує: ніхто в цій OU не може створити жоден ресурс поза межами Франкфурту та Ірландії — навіть якщо у них є права AdministratorAccess. Це потужний механізм compliance для GDPR.

IAM Access Analyzer — аудит реального використання

IAM Access Analyzer — це інструмент, який аналізує ваші IAM Policies і знаходить потенційні проблеми:

1. Зовнішній доступ (External Access Analyzer): знаходить ресурси (S3 buckets, Lambda functions, SQS queues), які доступні з-за меж вашого акаунту або організації. Це може бути навмисно (публічний bucket) або випадково (помилка в Policy).
2. Unused Access Analyzer: аналізує, які права фактично використовуються IAM Users і Roles за останні 90 днів, і рекомендує видалити надлишкові. Саме цей інструмент допомагає реально дотримуватись принципу найменших привілеїв.
3. Policy Validation: перевіряє синтаксис та семантику Policy ще до її застосування — знаходить помилки та потенційно небезпечні конфігурації.

AWS STS — Security Token Service

AWS Security Token Service (STS) — це сервіс, який видає тимчасові security credentials. Ми вже згадували його у контексті IAM Roles — саме STS видає тимчасові ключі при AssumeRole. Але STS має й інші сценарії використання.

Ключові операції STS

AssumeRole — найпоширеніша операція. Приймає роль і отримує тимчасові credentials:

aws sts assume-role \
    --role-arn "arn:aws:iam::123456789012:role/ReadOnlyRole" \
    --role-session-name "my-session"

Відповідь містить три компоненти, необхідних для використання: AccessKeyId, SecretAccessKey та SessionToken. Credentials діють від 15 хвилин до 12 годин.

GetCallerIdentity — перевірити, під яким акаунтом ви авторизовані прямо зараз:

aws sts get-caller-identity
# {"UserId": "AIDAIOSFODNN7EXAMPLE", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/developer"}

AssumeRoleWithWebIdentity — для Kubernetes Pods (IRSA — IAM Roles for Service Accounts) та мобільних застосунків, що використовують Google/Facebook/Cognito для аутентифікації.

IAM Best Practices для розробників

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

IAM та .NET: практична інтеграція

AWS SDK for .NET — ланцюг пошуку credentials

Коли ваш .NET-код використовує AWS SDK, він шукає credentials у певному порядку (Credential Provider Chain). Розуміння цього порядку критично важливе:

1. Явне передання (не рекомендується)
2. Змінні середовища (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
3. AWS Shared Credentials File (~/.aws/credentials)
4. AWS Config File (~/.aws/config)
5. EC2 Instance Metadata (IMDS) ← для EC2 з Instance Role
6. ECS Task Metadata ← для ECS Tasks
7. IAM Roles for EKS Service Accounts

SDK перевіряє кожен джерело по черзі і використовує перший знайдений. Це означає:

• На локальній машині (де немає EC2) — використовує ~/.aws/credentials
• На EC2 — автоматично знаходить Instance Role через IMDS (5-й пункт)

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

Конфігурація профілів (~/.aws/credentials)

Файл ~/.aws/credentials може містити кілька профілів для роботи з різними акаунтами:

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[development]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

[production-readonly]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE2
aws_secret_access_key = anotherSecretKeyExample123456789

У .NET-коді можна явно вказати профіль:

// Використати конкретний профіль
var chain = new CredentialProfileStoreChain();
if (chain.TryGetAWSCredentials("development", out var credentials))
{
    var s3Client = new AmazonS3Client(credentials, RegionEndpoint.EUCentral1);
}

// Або через Environment Variable
// AWS_PROFILE=development dotnet run

Або у файлі ~/.aws/config:

[profile development]
role_arn = arn:aws:iam::123456789012:role/DeveloperRole
source_profile = default
region = eu-central-1

Тут development профіль автоматично виконує AssumeRole — зручно для cross-account доступу.

AWS Toolkit for JetBrains Rider / Visual Studio

AWS Toolkit — це плагін для IDE, який додає зручний графічний інтерфейс для роботи з AWS прямо в редакторі:

• Браузер ресурсів AWS (S3, Lambda, DynamoDB, CloudWatch) прямо в IDE
• Запуск та дебаг Lambda-функцій локально
• Перегляд та управління EC2 інстансами
• Швидке перемикання між AWS профілями та регіонами

Встановлюється як стандартний плагін через Marketplace у Rider або через Extensions у Visual Studio.

Лабораторна робота

Завдання 1: Створення IAM User для розробника з обмеженими правами

aws configure --profile developer-lab
# Введіть отримані Access Key ID та Secret Access Key
# Region: eu-central-1
# Output format: json

# Перевірте, чи це ваш новий user
aws sts get-caller-identity --profile developer-lab

Завдання 2: IAM Role для EC2 з доступом до S3

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadWriteOnLabBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::lab-bucket-*",
                "arn:aws:s3:::lab-bucket-*/*"
            ]
        }
    ]
}

# На EC2 — credentials отримуються автоматично з Instance Metadata
aws sts get-caller-identity
# Повинна показати роль: arn:aws:sts::...:assumed-role/EC2-Lab-Role/...

aws s3 ls
# Виведе список S3 buckets

# Спробуйте заборонену дію — має показати AccessDenied
aws ec2 terminate-instances --instance-ids i-xxx

Завдання 3: Написати custom Policy та протестувати через AWS CLI

Напишіть IAM Policy, яка:

• Дозволяє lambda:InvokeFunction лише для функцій, назви яких починаються на lab-
• Дозволяє logs:GetLogEvents та logs:DescribeLogStreams в CloudWatch
• Забороняє будь-яке видалення (Delete*) у Lambda та CloudWatch

Прикріпіть Policy до вашого developer-yourname User. Перевірте через CLI:

# Спроба викликати дозволену функцію
aws lambda invoke --function-name lab-test-function output.json --profile developer-lab

# Спроба викликати заборонену функцію
aws lambda invoke --function-name production-function output.json --profile developer-lab
# Має повернути: AccessDeniedException

Резюме

IAM — це фундамент безпеки всієї вашої роботи з AWS. Ключові висновки:

• IAM Users — для людей і програм. Мають password (консоль) або Access Keys (CLI/SDK). Ніколи не шеруйте.
• IAM Groups — для команд. Зручно управляти правами великої кількості Users через Policy на рівні групи.
• IAM Roles — для сервісів AWS та cross-account доступу. Видають тимчасові credentials через STS. Використовуйте замість Access Keys де тільки можливо.
• IAM Policies — JSON-документи з правилами Allow/Deny. Deny завжди перемагає Allow. За замовчуванням усе заборонено.
• Least Privilege — давайте мінімально необхідний доступ. IAM Access Analyzer допоможе знайти надлишкові права.
• MFA — обов'язкова для всіх людей, обов'язкова для root.
• AWS Organizations + SCPs — централізоване управління множинними акаунтами з жорсткими обмеженнями на рівні організації.
• Credential Provider Chain — AWS SDK шукає credentials у певному порядку; на EC2 та Lambda вони надходять автоматично через IAM Role.

Практичні завдання

Рівень 1 (Базовий)

Завдання 1. Поясніть різницю між IAM User та IAM Role. Чому для EC2 інстансу, який звертається до S3, краще використовувати IAM Role, а не Access Keys IAM User?

Завдання 2. Проаналізуйте наступну IAM Policy. Чи зможе User, якому вона прикріплена, видаляти об'єкти з bucket production-data? Чому?

{
    "Version": "2012-10-17",
    "Statement": [
        {"Effect": "Allow", "Action": "s3:*", "Resource": "*"},
        {"Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::production-data/*"}
    ]
}

Рівень 2 (Аналіз)

Завдання 3. Ваша Lambda-функція на .NET потребує: читати з DynamoDB таблиці users, записувати в S3 bucket reports-2024, надсилати повідомлення через SES. Напишіть мінімальну IAM Policy для Execution Role цієї Lambda. Не давайте зайвих прав!

Завдання 4. Вам потрібно надати тимчасовий (на 4 години) read-only доступ до production S3 buckets зовнішньому аудитору, який не має AWS акаунту у вашій організації. Опишіть покроковий план рішення через IAM Role та STS.

Рівень 3 (Архітектура безпеки)

Завдання 5. Компанія має 3 AWS акаунти: dev, staging, production. Команда з 10 розробників і 2 DevOps-інженерів. Вимоги:

• Розробники мають повний доступ у dev, читаючий у staging, нульовий у production
• DevOps мають повний доступ у всіх акаунтах
• Нікому не дозволено запускати ресурси поза eu-central-1
• Усі критичні операції (delete, terminate) вимагають MFA

Спроектуйте IAM-архітектуру: які Users, Groups, Roles та Policies потрібні? Де використовувати Organizations та SCPs? Намалюйте схему у вигляді PlantUML-діаграми.