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 показується лише один раз — у момент створення. Якщо ви його втратили — доведеться створювати нову пару ключів.

Root акаунт ≠ IAM User. Root акаунт — це «суперадмін» вашого AWS-акаунту, створений під час реєстрації. Він має необмежені права і не може бути обмежений через IAM. Тому:

• Ніколи не використовуйте root для повсякденної роботи
• Ніколи не створюйте Access Keys для root
• Увімкніть MFA для root і «забудьте» про нього Для всієї роботи створюйте IAM Users з мінімально необхідними правами. ::

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

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

---

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

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

Developers

• EC2: Start, Stop, Describe
• S3: Read, Write (тільки dev-buckets)
• RDS: Connect, Describe
• Lambda: Invoke, Update
• CloudWatch: Read logs

::

Важливі обмеження 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\n(.NET API)" as EC2 #d1fae5
database "S3 Bucket\n(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 : Доступ через\nтимчасові 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\n(Root)" as Root #fef3c7
    note right of Root : Центральний акаунт.\nУправляє всіма дочірніми.

    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) — захисний пояс організації

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

rectangle "SCP: Deny all actions outside eu-central-1" as SCP #fecaca {
    note right of SCP
        SCP — це стеля.
        Застосовується на OU.
        Обмежує, але не надає прав.
    end note
}

package "OU: Production" as OU #fce7f3 {
    rectangle "Account: Production" as Prod {
        file "IAM Policy:\nAdministratorAccess" as Admin
    }
    note bottom of Prod
        Навіть з AdminAccess,
        SCP блокує дії поза
        дозволеними регіонами
    end note
}

SCP -down-> OU : обмежує
@enduml

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"

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

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

start
: .NET код викликає AWS SDK;
if (Явно передані credentials?) then (Так)
    :Використати явні credentials;
    stop
else (Ні)
    if (Змінні середовища
AWS_ACCESS_KEY_ID?) then (Так)
        :Використати змінні середовища;
        stop
    else (Ні)
        if (~/.aws/credentials
файл існує?) then (Так)
            :Використати профіль
з credentials файлу;
            stop
        else (Ні)
            if (EC2 / ECS
Instance Metadata?) then (Так)
                :Отримати тимчасові
credentials з IMDS;
                stop
            else (Ні)
                :ПОМИЛКА
(Credentials not found);
                stop
            endif
        endif
    endif
endif
@enduml

Коли ваш .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.

Довідник: AWS IAM — повна документація функцій

IAM Password Policy — вимоги до паролів акаунту

Password Policy — це набір правил, які визначають вимоги до паролів усіх IAM Users у вашому акаунті. Без кастомної Policy AWS застосовує мінімальний стандарт (8 символів).

aws iam update-account-password-policy \
    --minimum-password-length 12 \
    --require-uppercase-characters \
    --require-lowercase-characters \
    --require-numbers \
    --require-symbols \
    --max-password-age 90 \
    --password-reuse-prevention 5 \
    --allow-users-to-change-password

aws iam get-account-password-policy

aws iam update-account-password-policy `
    --minimum-password-length 12 `
    --require-uppercase-characters `
    --require-lowercase-characters `
    --require-numbers `
    --require-symbols `
    --max-password-age 90 `
    --password-reuse-prevention 5 `
    --allow-users-to-change-password

aws iam get-account-password-policy

IAM Policy Simulator — тестування Policy без реального застосування

IAM Policy Simulator — це інструмент, який дозволяє перевірити, чи надають ваші Policies певний доступ, до їх застосування. Незамінний для відлагодження складних Policy з Conditions.

Через AWS Console: policy simulator → оберіть User/Role → оберіть сервіс → оберіть Actions → натисніть Run Simulation → отримайте результат Allow/Deny з поясненням.

Через AWS CLI:

# Перевірити, чи може user "developer" виконати s3:GetObject
aws iam simulate-principal-policy \
    --policy-source-arn "arn:aws:iam::123456789012:user/developer" \
    --action-names "s3:GetObject" \
    --resource-arns "arn:aws:s3:::production-data/sensitive.txt"

# Перевірити, чи може user "developer" виконати s3:GetObject
aws iam simulate-principal-policy `
    --policy-source-arn "arn:aws:iam::123456789012:user/developer" `
    --action-names "s3:GetObject" `
    --resource-arns "arn:aws:s3:::production-data/sensitive.txt"

Відповідь:

{
    "EvaluationResults": [
        {
            "EvalActionName": "s3:GetObject",
            "EvalDecision": "explicitDeny",
            "MatchedStatements": [
                {
                    "SourcePolicyId": "DenyDeleteOnProduction",
                    "StartPosition": { "Line": 5, "Column": 9 },
                    "EndPosition": { "Line": 12, "Column": 9 }
                }
            ]
        }
    ]
}

Permission Boundaries — обмеження максимальних прав

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

rectangle "Permission Boundary\n(максимальна стеля)" as Boundary #fef3c7

rectangle "Identity Policy\n(що User хоче робити)" as Identity #dbeafe

rectangle "Effective Permissions\n(реальний доступ)" as Effective #d1fae5

note right of Effective
    Effective = Identity ∩ Boundary
    Лише те, що є в обох —
    буде дозволено
end note

Boundary -down-> Effective : обмежує
Identity -down-> Effective : звужує
@enduml

Permission Boundary — це IAM Managed Policy, яка встановлює стелю для максимально можливих прав IAM User або Role. На відміну від SCP (яка діє на рівні Organizations), Permission Boundary діє на рівні окремого User або Role в одному акаунті.

Сценарій: ви хочете дозволити розробникам самостійно створювати IAM Roles для своїх Lambda-функцій, але обмежити: ролі, які вони створюють, не можуть мати прав більше, ніж дозволяє Permission Boundary.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DeveloperPermissionBoundary",
            "Effect": "Allow",
            "Action": ["s3:*", "dynamodb:*", "lambda:*", "logs:*", "cloudwatch:*"],
            "Resource": "*"
        },
        {
            "Sid": "DenyIAMEscalation",
            "Effect": "Deny",
            "Action": ["iam:CreateUser", "iam:DeleteUser", "iam:AttachUserPolicy", "iam:PutUserPolicy"],
            "Resource": "*"
        }
    ]
}

Застосування Permission Boundary до User:

# Зберегти Policy як DeveloperBoundary, потім застосувати
aws iam put-user-permissions-boundary \
    --user-name developer-alice \
    --permissions-boundary arn:aws:iam::123456789012:policy/DeveloperBoundary

# Зберегти Policy як DeveloperBoundary, потім застосувати
aws iam put-user-permissions-boundary `
    --user-name developer-alice `
    --permissions-boundary arn:aws:iam::123456789012:policy/DeveloperBoundary

IAM Conditions — розширені умови доступу

Conditions дозволяють надавати доступ лише за певних умов. Це потужний механізм для гранулярного контролю. Розглянемо найкорисніші умови:

Обмеження доступу по IP-адресі:

{
    "Condition": {
        "IpAddress": {
            "aws:SourceIp": ["203.0.113.0/24", "198.51.100.0/24"]
        }
    }
}

Лише з офісної мережі.

Обмеження лише певним часом (робочі години):

{
    "Condition": {
        "DateGreaterThan": { "aws:CurrentTime": "2024-01-01T08:00:00Z" },
        "DateLessThan": { "aws:CurrentTime": "2024-12-31T18:00:00Z" }
    }
}

Тільки з MFA:

{
    "Condition": {
        "Bool": { "aws:MultiFactorAuthPresent": "true" },
        "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" }
    }
}

Вимагає MFA і щоб аутентифікація з MFA відбулась не більш ніж годину тому.

Обмеження по тегах ресурсів (ABAC — Attribute-Based Access Control):

{
    "Condition": {
        "StringEquals": {
            "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
        }
    }
}

Розробник з тегом Environment=dev може керувати лише ресурсами з тегом Environment=dev.

CloudTrail + IAM — аудит усіх дій

AWS CloudTrail автоматично логує кожен API-виклик в AWS акаунті: хто, що, коли, звідки. Це невіддільна частина IAM-безпеки.

Перегляд останніх IAM-дій через CLI:

# Хто нещодавно створював IAM Users?
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser \
    --region eu-central-1 \
    --query "Events[*].{Time:EventTime,User:Username,Event:EventName}" \
    --output table

# Хто нещодавно AssumeRole?
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
    --region eu-central-1 \
    --max-results 10

# Хто нещодавно створював IAM Users?
aws cloudtrail lookup-events `
    --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser `
    --region eu-central-1 `
    --query "Events[*].{Time:EventTime,User:Username,Event:EventName}" `
    --output table

# Хто нещодавно AssumeRole?
aws cloudtrail lookup-events `
    --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole `
    --region eu-central-1 `
    --max-results 10

Через Console: CloudTrail → Event history → фільтр за Event name (наприклад DeleteAccessKey, AttachRolePolicy) → перегляд деталей кожної події.

IAM Identity Center (SSO) — корпоративна аутентифікація

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

actor "Співробітник" as Employee

node "Corporate IdP\n(Okta / AD / Google)" as IdP #dbeafe

node "AWS IAM Identity Center" as SSO #d1fae5

package "AWS Accounts" as Accounts {
    rectangle "Dev Account" as Dev
    rectangle "Prod Account" as Prod
}

Employee -right-> IdP : 1. Логін (LDAP/SAML)
IdP -right-> SSO : 2. Твердження SAML
SSO -right-> SSO : 3. Видача тимчасових\ncredentials (1-8h)
SSO -down-> Dev : 4. Доступ через\nPermission Set
@enduml

IAM Identity Center (раніше AWS SSO) — це рекомендований підхід для корпоративного середовища. Замість сотень окремих IAM Users — інтеграція з корпоративним Identity Provider (Microsoft Active Directory, Okta, Google Workspace) і єдиний вхід для всіх AWS акаунтів.

Як це працює:

1. Співробітник входить через корпоративний логін (Okta/AD/Google)
2. IAM Identity Center перевіряє автентифікацію через IdP
3. Видаються тимчасові AWS credentials на основі Permission Set (набір прав)
4. Credentials діють 1–8 годин і автоматично оновлюються

Permission Set — це шаблон прав (аналог IAM Role), який застосовується до конкретного акаунту. Наприклад, Permission Set DeveloperAccess дає доступ до dev-акаунту, а ReadOnlyAccess — до production.

Налаштування AWS CLI для SSO:

# Налаштувати SSO профіль
aws configure sso

# CLI запитає:
# SSO start URL: https://your-company.awsapps.com/start
# SSO Region: eu-central-1
# Account ID: (оберіть з переліку)
# Role name: (оберіть Permission Set)

# Вхід через браузер (відкривається автоматично)
aws sso login --profile my-sso-profile

# Використання профілю
aws s3 ls --profile my-sso-profile

У .NET-коді SSO профілі підтримуються автоматично через Credential Provider Chain:

// Якщо ~./aws/config має SSO профіль — SDK автоматично його використає
var s3Client = new AmazonS3Client();
// АБО явно
var chain = new CredentialProfileStoreChain();
chain.TryGetAWSCredentials("my-sso-profile", out var creds);

Автоматична ротація Access Keys

Якщо Access Keys неминуче потрібні (GitHub Actions, legacy системи) — ротуйте їх кожні 90 днів. AWS дозволяє мати два активних ключа одночасно — це забезпечує zero-downtime ротацію.

# Крок 1: Створіть новий ключ
aws iam create-access-key --user-name ci-user
# Збережіть новий KeyId та Secret

# Крок 2: Оновіть GitHub Secrets / CI/CD системи новим ключем

# Крок 3: Перевірте, що новий ключ працює
aws sts get-caller-identity --profile new-key-profile

# Крок 4: Деактивуйте старий ключ
aws iam update-access-key \
    --user-name ci-user \
    --access-key-id AKIAOLD1234 \
    --status Inactive

# Крок 5: Через тиждень (якщо все ок) — видаліть старий
aws iam delete-access-key \
    --user-name ci-user \
    --access-key-id AKIAOLD1234

# Перевірити всі ключі для user
aws iam list-access-keys --user-name ci-user

# Крок 1: Створіть новий ключ
aws iam create-access-key --user-name ci-user
# Збережіть новий KeyId та Secret

# Крок 2: Оновіть GitHub Secrets / CI/CD системи новим ключем

# Крок 3: Перевірте, що новий ключ працює
aws sts get-caller-identity --profile new-key-profile

# Крок 4: Деактивуйте старий ключ
aws iam update-access-key `
    --user-name ci-user `
    --access-key-id AKIAOLD1234 `
    --status Inactive

# Крок 5: Через тиждень (якщо все ок) — видаліть старий
aws iam delete-access-key `
    --user-name ci-user `
    --access-key-id AKIAOLD1234

# Перевірити всі ключі для user
aws iam list-access-keys --user-name ci-user

Практичний приклад: IAM від А до Я

Крок 1: Перевірте поточний акаунт

Перш за все — переконайтесь, що ви авторизовані та дізнайтесь ваш Account ID:

Значення Account — це ваш AWS Account ID. Запам'ятайте або збережіть його — він знадобиться у наступних кроках. Переконайтесь, що Arn не містить root.

Крок 2: Налаштування Password Policy

Встановіть надійну Password Policy для акаунту:

aws iam update-account-password-policy \
    --minimum-password-length 12 \
    --require-uppercase-characters \
    --require-lowercase-characters \
    --require-numbers \
    --require-symbols \
    --max-password-age 90 \
    --password-reuse-prevention 5 \
    --allow-users-to-change-password

aws iam update-account-password-policy `
    --minimum-password-length 12 `
    --require-uppercase-characters `
    --require-lowercase-characters `
    --require-numbers `
    --require-symbols `
    --max-password-age 90 `
    --password-reuse-prevention 5 `
    --allow-users-to-change-password

Крок 3: Створення IAM Group

# Створіть групу розробників
aws iam create-group --group-name Developers

# Прикріпіть AWS Managed Policies
aws iam attach-group-policy \
    --group-name Developers \
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

aws iam attach-group-policy \
    --group-name Developers \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Створіть групу розробників
aws iam create-group --group-name Developers

# Прикріпіть AWS Managed Policies
aws iam attach-group-policy `
    --group-name Developers `
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

aws iam attach-group-policy `
    --group-name Developers `
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Крок 4: Створення IAM User та додавання до групи

# Створіть User
# ЗАМІНІТЬ yourname на своє ім'я латиницею (наприклад: ivan, olena)
aws iam create-user --user-name developer-yourname

# Створіть логін для AWS Console
# ЗАМІНІТЬ YourSecureP@ssword123 на ваш надійний пароль
aws iam create-login-profile \
    --user-name developer-yourname \
    --password "YourSecureP@ssword123" \
    --password-reset-required

# Додайте User до групи Developers
aws iam add-user-to-group \
    --user-name developer-yourname \
    --group-name Developers

# Створіть User
# ЗАМІНІТЬ yourname на своє ім'я латиницею (наприклад: ivan, olena)
aws iam create-user --user-name developer-yourname

# Створіть логін для AWS Console
# ЗАМІНІТЬ YourSecureP@ssword123 на ваш надійний пароль
aws iam create-login-profile `
    --user-name developer-yourname `
    --password "YourSecureP@ssword123" `
    --password-reset-required

# Додайте User до групи Developers
aws iam add-user-to-group `
    --user-name developer-yourname `
    --group-name Developers

Перевірте вхід: відкрийте новий браузер в режимі інкогніто, перейдіть за Console sign-in URL, увійдіть як developer-yourname. Переконайтесь, що EC2 і S3 відображаються, але кнопки «Create», «Delete» або виводять помилку Access Denied.

Крок 5: Створення Access Keys для CLI

aws iam create-access-key --user-name developer-yourname

aws iam create-access-key --user-name developer-yourname

Налаштуйте профіль у AWS CLI:

aws configure --profile developer-lab
# AWS Access Key ID: AKIAIOSFODNN7EXAMPLE  ← введіть ваш реальний ключ
# AWS Secret Access Key: wJalrXU...        ← введіть ваш реальний секрет
# Default region name: eu-central-1
# Default output format: json

Перевірте дозволені та заборонені операції:

Крок 6: Створення Customer Managed Policy

Напишемо власну IAM Policy для доступу до S3 bucket з префіксом lab-:

# Збережіть Policy у файл
cat > /tmp/lab-s3-policy.json << 'EOF'
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadWriteOnLabBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::lab-*",
                "arn:aws:s3:::lab-*/*"
            ]
        },
        {
            "Sid": "DenyDeleteBucket",
            "Effect": "Deny",
            "Action": "s3:DeleteBucket",
            "Resource": "*"
        }
    ]
}
EOF

# Створіть Policy
aws iam create-policy \
    --policy-name DeveloperLabS3Access \
    --policy-document file:///tmp/lab-s3-policy.json \
    --description "Read/Write access to lab- S3 buckets, no bucket deletion"

# Прикріпіть Policy до User
# ЗАМІНІТЬ 123456789012 на ваш реальний Account ID
aws iam attach-user-policy \
    --user-name developer-yourname \
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

# Збережіть Policy у файл
$policy = @'
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadWriteOnLabBuckets",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::lab-*",
                "arn:aws:s3:::lab-*/*"
            ]
        },
        {
            "Sid": "DenyDeleteBucket",
            "Effect": "Deny",
            "Action": "s3:DeleteBucket",
            "Resource": "*"
        }
    ]
}
'@
Set-Content -Path "$env:TEMP\lab-s3-policy.json" -Value $policy

# Створіть Policy
aws iam create-policy `
    --policy-name DeveloperLabS3Access `
    --policy-document file://"$env:TEMP\lab-s3-policy.json" `
    --description "Read/Write access to lab- S3 buckets, no bucket deletion"

# Прикріпіть Policy до User
# ЗАМІНІТЬ 123456789012 на ваш реальний Account ID
aws iam attach-user-policy `
    --user-name developer-yourname `
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

Крок 7: Створення IAM Role для EC2

# Trust Policy — дозволяємо EC2 сервісу приймати цю роль
cat > /tmp/ec2-trust.json << 'EOF'
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"Service": "ec2.amazonaws.com"},
        "Action": "sts:AssumeRole"
    }]
}
EOF

# Створіть роль
aws iam create-role \
    --role-name EC2-Lab-Role \
    --assume-role-policy-document file:///tmp/ec2-trust.json \
    --description "EC2 role for lab S3 access"

# Прикріпіть Policy до ролі
# ЗАМІНІТЬ 123456789012 на ваш Account ID
aws iam attach-role-policy \
    --role-name EC2-Lab-Role \
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

# Додатково — права на CloudWatch логи
aws iam attach-role-policy \
    --role-name EC2-Lab-Role \
    --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

# Trust Policy — дозволяємо EC2 сервісу приймати цю роль
$trust = @'
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"Service": "ec2.amazonaws.com"},
        "Action": "sts:AssumeRole"
    }]
}
'@
Set-Content -Path "$env:TEMP\ec2-trust.json" -Value $trust

# Створіть роль
aws iam create-role `
    --role-name EC2-Lab-Role `
    --assume-role-policy-document file://"$env:TEMP\ec2-trust.json" `
    --description "EC2 role for lab S3 access"

# Прикріпіть Policy до ролі
# ЗАМІНІТЬ 123456789012 на ваш Account ID
aws iam attach-role-policy `
    --role-name EC2-Lab-Role `
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

# Додатково — права на CloudWatch логи
aws iam attach-role-policy `
    --role-name EC2-Lab-Role `
    --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Прикріпіть роль до запущеного EC2 інстансу:

# Знайдіть ID вашого EC2 інстансу
aws ec2 describe-instances \
    --query "Reservations[*].Instances[*].{ID:InstanceId,State:State.Name}" \
    --output table --region eu-central-1

# ЗАМІНІТЬ i-1234567890abcdef0 на реальний Instance ID
aws ec2 associate-iam-instance-profile \
    --instance-id i-1234567890abcdef0 \
    --iam-instance-profile Name=EC2-Lab-Role \
    --region eu-central-1

# Знайдіть ID вашого EC2 інстансу
aws ec2 describe-instances `
    --query "Reservations[*].Instances[*].{ID:InstanceId,State:State.Name}" `
    --output table --region eu-central-1

# ЗАМІНІТЬ i-1234567890abcdef0 на реальний Instance ID
aws ec2 associate-iam-instance-profile `
    --instance-id i-1234567890abcdef0 `
    --iam-instance-profile Name=EC2-Lab-Role `
    --region eu-central-1

Перевірте доступ з EC2:

# Підключіться до EC2 через SSH, потім виконайте:
aws sts get-caller-identity
# Arn має містити: assumed-role/EC2-Lab-Role/...

# Тест дозволеної дії
aws s3 ls  # Показує список buckets

# Тест забороненої дії
aws ec2 describe-instances
# AccessDenied — роль не має прав на EC2

Крок 8: Увімкнення MFA для User

# MFA пристрій потрібно налаштовувати через Console (потребує QR-коду)
# Після налаштування через Console — перевірте через CLI:
aws iam list-mfa-devices --user-name developer-yourname

# MFA пристрій потрібно налаштовувати через Console (потребує QR-коду)
# Після налаштування через Console — перевірте через CLI:
aws iam list-mfa-devices --user-name developer-yourname

Крок 9: Тестування Policy через IAM Policy Simulator

Перевіримо наш Policy без реального виконання:

# ЗАМІНІТЬ 123456789012 на ваш Account ID
aws iam simulate-principal-policy \
    --policy-source-arn "arn:aws:iam::123456789012:user/developer-yourname" \
    --action-names "s3:GetObject" "s3:DeleteBucket" "ec2:TerminateInstances" \
    --resource-arns "arn:aws:s3:::lab-test-bucket/file.txt" \
    --query "EvaluationResults[*].{Action:EvalActionName,Decision:EvalDecision}" \
    --output table

# ЗАМІНІТЬ 123456789012 на ваш Account ID
aws iam simulate-principal-policy `
    --policy-source-arn "arn:aws:iam::123456789012:user/developer-yourname" `
    --action-names "s3:GetObject" "s3:DeleteBucket" "ec2:TerminateInstances" `
    --resource-arns "arn:aws:s3:::lab-test-bucket/file.txt" `
    --query "EvaluationResults[*].{Action:EvalActionName,Decision:EvalDecision}" `
    --output table

Крок 10: Перевірка через CloudTrail

Усі IAM дії, які ми виконали, залоговані у CloudTrail:

# Переглянути нещодавні IAM дії
aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=Username,AttributeValue=developer-yourname \
    --region eu-central-1 \
    --query "Events[*].{Time:EventTime,Action:EventName,Source:EventSource}" \
    --output table

# Переглянути нещодавні IAM дії
aws cloudtrail lookup-events `
    --lookup-attributes AttributeKey=Username,AttributeValue=developer-yourname `
    --region eu-central-1 `
    --query "Events[*].{Time:EventTime,Action:EventName,Source:EventSource}" `
    --output table

Крок 11: ОБОВ'ЯЗКОВО — Очищення ресурсів

# Замініть yourname на ваше реальне ім'я у всіх командах нижче

# 1. Знайдіть та видаліть Access Keys
KEY_ID=$(aws iam list-access-keys --user-name developer-yourname \
    --query "AccessKeyMetadata[0].AccessKeyId" --output text)
aws iam delete-access-key --user-name developer-yourname --access-key-id $KEY_ID

# 2. Видаліть MFA пристрій (якщо налаштований)
MFA_ARN=$(aws iam list-mfa-devices --user-name developer-yourname \
    --query "MFADevices[0].SerialNumber" --output text)
[ "$MFA_ARN" != "None" ] && aws iam deactivate-mfa-device \
    --user-name developer-yourname --serial-number $MFA_ARN

# 3. Видаліть Console login profile
aws iam delete-login-profile --user-name developer-yourname

# 4. Від'єднайте Policy від User
# ЗАМІНІТЬ 123456789012 на ваш Account ID
aws iam detach-user-policy \
    --user-name developer-yourname \
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

# 5. Видаліть User з групи
aws iam remove-user-from-group \
    --user-name developer-yourname \
    --group-name Developers

# 6. Видаліть User
aws iam delete-user --user-name developer-yourname

# 7. Видаліть Policy
aws iam delete-policy \
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

# 8. Від'єднайте policies від Role
aws iam detach-role-policy \
    --role-name EC2-Lab-Role \
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access
aws iam detach-role-policy \
    --role-name EC2-Lab-Role \
    --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

# 9. Видаліть Role
aws iam delete-role --role-name EC2-Lab-Role

# 10. Від'єднайте policies від Group
aws iam detach-group-policy \
    --group-name Developers \
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
aws iam detach-group-policy \
    --group-name Developers \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# 11. Видаліть Group
aws iam delete-group --group-name Developers

# Замініть yourname на ваше реальне ім'я у всіх командах нижче

# 1. Знайдіть та видаліть Access Keys
$KEY_ID = (aws iam list-access-keys --user-name developer-yourname `
    --query "AccessKeyMetadata[0].AccessKeyId" --output text)
aws iam delete-access-key --user-name developer-yourname --access-key-id $KEY_ID

# 2. Видаліть MFA пристрій (якщо налаштований)
$MFA_ARN = (aws iam list-mfa-devices --user-name developer-yourname `
    --query "MFADevices[0].SerialNumber" --output text)
if ($MFA_ARN -and $MFA_ARN -ne "None") {
    aws iam deactivate-mfa-device `
        --user-name developer-yourname --serial-number $MFA_ARN
}

# 3. Видаліть Console login profile
aws iam delete-login-profile --user-name developer-yourname

# 4. Від'єднайте Policy від User
# ЗАМІНІТЬ 123456789012 на ваш Account ID
aws iam detach-user-policy `
    --user-name developer-yourname `
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

# 5. Видаліть User з групи
aws iam remove-user-from-group `
    --user-name developer-yourname `
    --group-name Developers

# 6. Видаліть User
aws iam delete-user --user-name developer-yourname

# 7. Видаліть Policy
aws iam delete-policy `
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access

# 8. Від'єднайте policies від Role
aws iam detach-role-policy `
    --role-name EC2-Lab-Role `
    --policy-arn arn:aws:iam::123456789012:policy/DeveloperLabS3Access
aws iam detach-role-policy `
    --role-name EC2-Lab-Role `
    --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

# 9. Видаліть Role
aws iam delete-role --role-name EC2-Lab-Role

# 10. Від'єднайте policies від Group
aws iam detach-group-policy `
    --group-name Developers `
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
aws iam detach-group-policy `
    --group-name Developers `
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# 11. Видаліть Group
aws iam delete-group --group-name Developers

Резюме

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

• IAM Users — для людей і програм. Мають password (консоль) або Access Keys (CLI/SDK). Ніколи не шеруйте.
• IAM Groups — для команд. Зручно управляти правами через Policy на рівні групи.
• IAM Roles — для сервісів AWS та cross-account доступу. Видають тимчасові credentials через STS.
• IAM Policies — JSON-документи з правилами Allow/Deny. Deny завжди перемагає Allow. За замовчуванням усе заборонено.
• Least Privilege — давайте мінімально необхідний доступ. IAM Access Analyzer допоможе знайти надлишкові права.
• MFA — обов'язкова для всіх людей, обов'язкова для root.
• Permission Boundaries — обмежують стелю прав для User/Role в одному акаунті.
• Conditions — гранулярний контроль: за IP, часом, MFA, тегами ресурсів.
• CloudTrail — логує кожен API-виклик. Незамінний для аудиту та розслідувань.
• IAM Identity Center (SSO) — рекомендований підхід для корпоративного середовища з SAML/OIDC провайдерами.
• Credential Provider Chain — AWS SDK шукає credentials у певному порядку; на EC2 та Lambda — автоматично через IAM Role.

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

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

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

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

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

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

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

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

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

Завдання 5. Компанія має 3 акаунти: dev, staging, production. 10 розробників, 2 DevOps. Вимоги: розробники — повний доступ у dev, читаючий у staging, нуль у production; DevOps — повний скрізь; нікому не можна запускати ресурси поза eu-central-1; всі delete/terminate вимагають MFA. Спроектуйте IAM-архітектуру з Organizations та SCPs. Намалюйте PlantUML схему.