Безпека AWS: IAM, VPC та спільна відповідальність

Модель спільної відповідальності

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

Ця межа змінюється залежно від типу служби:

• IaaS (EC2): ви керуєте ОС, середовищем виконання, застосунком і даними
• PaaS (RDS, Lambda): AWS керує ОС і середовищем виконання; ви керуєте застосунком і даними
• SaaS (Amazon WorkMail): AWS керує майже всім; ви керуєте доступом і даними

Неправильна конфігурація вашої сторони межі — публічно доступний S3-бакет, надмірно дозволена роль IAM, група безпеки, відкрита для 0.0.0.0/0 — є вашою відповідальністю, незалежно від того, наскільки захищена інфраструктура AWS.

IAM: найкритичніший засіб контролю безпеки AWS

AWS Identity and Access Management (IAM) контролює, хто і що може робити у кожній службі AWS. Правильне налаштування IAM є найбільш ефективним кроком для забезпечення безпеки AWS.

Захист облікового запису root

Обліковий запис root AWS має необмежений доступ до всього і не може бути обмежений політиками. Захистіть його:

• Увімкніть апаратну MFA для облікового запису root одразу після створення облікового запису
• Ніколи не створюйте ключі доступу для root
• Використовуйте root лише для завдань, які конкретно його вимагають (налаштування виставлення рахунків, параметри облікового запису, зміни тарифного плану підтримки)
• Налаштуйте сповіщення про виставлення рахунків через CloudWatch, щоб помічати несподіване використання

Користувачі IAM, ролі та політики

Для реальних користувачів надавайте перевагу IAM Identity Center (раніше SSO) із федеративними ідентичностями з вашого корпоративного каталогу замість окремих користувачів IAM. Для машинних ідентичностей (інстанси EC2, функції Lambda, завдання ECS) завжди використовуйте ролі IAM замість жорстко закодованих ключів доступу — ролі надають тимчасові облікові дані, які ротуються автоматично.

Пишіть політики згідно з принципом найменших привілеїв:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-bucket/*"
  }]
}

Використовуйте IAM Access Analyzer для виявлення надмірно дозволених політик і зовнішнього доступу до ваших ресурсів. Регулярно запускайте звіти про облікові дані (aws iam generate-credential-report) для аудиту невикористаних ключів доступу та користувачів.

Політики контролю служб (SCPs)

В AWS Organizations, SCPs діють як максимальні межі дозволів для цілих облікових записів або OU. Використовуйте їх для застосування захисних бар'єрів на рівні всієї організації:

• Забороніть вимкнення CloudTrail
• Обмежте, які регіони можна використовувати
• Запобігайте створенню публічних S3-бакетів
• Вимагайте MFA для чутливих операцій

VPC: мережева ізоляція в AWS

Virtual Private Cloud (VPC) — це ваша приватна мережа в AWS. Проектуйте її з урахуванням безпеки від самого початку:

Дизайн підмереж

Розділіть ресурси на рівні публічних, приватних і мережі даних підмереж:

• Публічні підмережі: лише балансувальники навантаження та NAT-шлюзи — більше нічого
• Приватні підмережі: сервери застосунків, функції Lambda, завдання ECS — без прямого доступу до інтернету
• Підмережі даних: бази даних RDS, ElastiCache та інші сховища даних — жодного шляху до інтернету

Ресурси в приватних підмережах отримують доступ до інтернету через NAT-шлюз (лише вихідний). Вхідний інтернет-трафік має надходити лише через балансувальник навантаження в публічній підмережі.

Групи безпеки та NACL

Групи безпеки — це stateful-міжмережеві екрани, прикріплені до окремих ресурсів — якщо ви дозволяєте вхідний порт 443, зворотний трафік дозволяється автоматично. Застосовуйте принцип найменших привілеїв: де можливо, вказуйте конкретні ідентифікатори груп безпеки як джерело замість IP-діапазонів.

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

Журнали потоків VPC

Увімкніть журнали потоків VPC для всіх підмереж і надсилайте їх до CloudWatch Logs або S3. Журнали потоків фіксують вихідні/цільові IP, порти, протоколи та рішення про прийняття/відхилення — необхідні для криміналістики та виявлення аномалій.

Журналювання та моніторинг: стек видимості безпеки

• CloudTrail: записує кожен виклик API AWS — хто що зробив, коли та звідки. Увімкніть у всіх регіонах, увімкніть валідацію файлів журналів і надсилайте до S3-бакета з SCP, що запобігає видаленню. Це обов'язково.
• AWS Config: записує зміни конфігурації ресурсів AWS та оцінює їх відповідно до правил відповідності
• Amazon GuardDuty: виявлення загроз на основі машинного навчання з аналізом CloudTrail, журналів потоків VPC та DNS-журналів для виявлення компрометації облікових даних, компрометації інстансів і розвідки
• AWS Security Hub: агрегує результати з GuardDuty, Config, Inspector та сторонніх інструментів в єдиній консолі з оцінюванням за стандартом CIS

Безпека S3

Публічно доступні S3-бакети залишаються однією з найпоширеніших причин витоків хмарних даних. Застосовуйте захист на рівні облікового запису:

• Увімкніть S3 Block Public Access на рівні облікового запису — це перекриває будь-які налаштування на рівні бакета
• Увімкніть шифрування за замовчуванням (SSE-S3 або SSE-KMS) для всіх бакетів
• Увімкніть S3 Object Lock для бакетів, що містять журнали аудиту, щоб запобігти видаленню
• Використовуйте політики бакетів для примусового застосування лише HTTPS: aws:SecureTransport: false → Deny
• Регулярно перевіряйте дозволи бакетів за допомогою Macie для виявлення чутливих даних