Безпека є однією з найбільш обговорюваних і водночас найбільш неправильно зрозумілих тем хмарних обчислень. З одного боку, хмарні провайдери інвестують мільярди доларів у захист своєї інфраструктури та отримують безліч міжнародних сертифікатів безпеки. З іншого боку, переважна більшість реальних інцидентів безпеки в хмарних середовищах відбувається не через вразливості провайдерів, а через хиби у конфігурації, управлінні доступом та недотримання вимог з боку самих клієнтів.
Розуміння принципів хмарної безпеки — від моделі відповідальності та управління ідентифікацією до стандартів відповідності та сучасних загроз — є обов’язковою компетентністю для будь-якого фахівця, що працює з хмарними системами.
Одна з найважливіших концептуальних основ хмарної безпеки — модель спільної відповідальності (Shared Responsibility Model). Її суть полягає в тому, що відповідальність за безпеку хмарного середовища розподіляється між провайдером і клієнтом залежно від обраної моделі послуги.
Жоден хмарний провайдер не бере на себе повну відповідальність за безпеку. Так само клієнт не є абсолютно незахищеним — певний базовий рівень захисту завжди забезпечує провайдер. Межа відповідальності проходить в різних місцях залежно від того, використовується IaaS, PaaS чи SaaS.
Принцип: провайдер відповідає за безпеку самої хмари (security of the cloud), клієнт — за безпеку у хмарі (security in the cloud).
| Шар стеку | IaaS | PaaS | SaaS |
|---|---|---|---|
| Дані | Клієнт | Клієнт | Клієнт |
| Застосунок | Клієнт | Клієнт | Провайдер |
| Середовище виконання | Клієнт | Провайдер | Провайдер |
| Операційна система | Клієнт | Провайдер | Провайдер |
| Мережа (логічна) | Клієнт | Провайдер | Провайдер |
| Гіпервізор | Провайдер | Провайдер | Провайдер |
| Фізичні ресурси | Провайдер | Провайдер | Провайдер |
Відповідальність провайдера (завжди):
Відповідальність клієнта (завжди):
Відповідальність клієнта (в моделі IaaS додатково):
Помилкова думка № 1: «Ми перейшли в хмару — тепер про безпеку дбає провайдер»
Реальність: Клієнт завжди залишається відповідальним за конфігурацію своїх ресурсів. AWS, Azure та Google можуть гарантувати, що їхні датацентри захищені від фізичного проникнення, але вони не можуть захистити клієнта від власних помилок конфігурації.
Приклад (Capital One, 2019): Зловмисник отримав несанкціонований доступ до 106 мільйонів записів клієнтів банку через неправильно налаштований WAF в AWS. Інфраструктура AWS не була зламана — проблема була у конфігурації клієнта. Збиток перевищив $80 млн.
Приклад (Twitch, 2021): Витік 125 ГБ внутрішніх даних компанії. Причина — неправильно налаштований сервер в AWS і відсутня мережева ізоляція між сервісами.
Висновок: Перехід до хмари не спрощує безпеку — він змінює де і як потрібно забезпечувати захист.
IAM (Identity and Access Management) — це сукупність політик, процесів і технологічних рішень, що визначають хто має доступ до системи і що цей суб’єкт може робити з конкретними ресурсами.
IAM включає три фундаментальні процеси:
Принцип мінімальних привілеїв (Principle of Least Privilege — PoLP):
Кожен користувач, система або застосунок повинні мати лише мінімальний набір прав, необхідних для виконання їхніх конкретних завдань — не більше.
Приклад порушення: Розробник отримує права адміністратора всього AWS-акаунту лише тому, що «так зручніше». Якщо його облікові дані будуть скомпрометовані — зловмисник отримує повний доступ до всіх ресурсів компанії.
Правильний підхід: Розробник отримує права на читання специфічних S3-кошиків та запуск конкретних EC2-екземплярів — лише те, що потрібно для його роботи.
Принцип розподілу обов’язків (Separation of Duties):
Критичні операції не повинні виконуватись однією особою без контролю. Наприклад, той, хто видає доступ до ресурсів, не повинен бути тим, хто перевіряє права доступу.
Принцип «нульової довіри» (Zero Trust):
Концепція безпеки, за якою жодному суб’єкту — ні всередині мережі, ні зовні — не надається довіра за замовчуванням. Кожен запит автентифікується та авторизується незалежно від його джерела.
Девіз: «Ніколи не довіряй — завжди перевіряй» (Never trust, always verify)
RBAC (Role-Based Access Control) — Управління доступом на основі ролей:
Найпоширеніша модель. Права призначаються не окремим користувачам, а ролям (наприклад, «Розробник», «Адміністратор БД», «Тільки читання»). Користувачі призначаються на певні ролі.
Приклад в AWS: Замість призначення 50 дозволів кожному розробнику — створюється роль «Developer» з 10 необхідними дозволами, і всі розробники отримують цю роль.
ABAC (Attribute-Based Access Control) — Управління доступом на основі атрибутів:
Доступ визначається на основі атрибутів суб’єкта, ресурсу та середовища. Наприклад: «Користувач може читати документ, якщо його відділ = ‘Finance’ І документ позначений тегом department=’Finance’ І поточний час — робочі години».
Більш гнучкий, ніж RBAC, але складніший в адмініструванні.
MFA (Multi-Factor Authentication) — метод автентифікації, що вимагає підтвердження ідентичності мінімум двома незалежними факторами з різних категорій:
| Категорія | Опис | Приклади |
|---|---|---|
| Знання (Knowledge) | Щось, що знає лише користувач | Пароль, PIN, відповідь на секретне запитання |
| Possession | Щось, чим володіє користувач | SMS-код, TOTP-додаток (Google Authenticator), апаратний ключ (YubiKey) |
| Inherence | Щось, чим є користувач (біометрія) | Відбиток пальця, розпізнавання обличчя |
Чому MFA критично важливий: За даними Microsoft, MFA блокує 99.9% автоматизованих атак на облікові записи. Навіть якщо пароль користувача витік, зловмисник не зможе увійти без другого фактора.
Приклад: Навіть якщо хакер отримає логін та пароль адміністратора AWS з темного вебу — без апаратного ключа YubiKey або TOTP-коду він не зможе увійти в консоль.
SSO (Single Sign-On) — механізм, що дозволяє користувачеві одноразово автентифікуватись і отримати доступ до множини систем без повторного введення облікових даних.
Приклад: Співробітник входить у корпоративний портал вранці — і автоматично має доступ до Jira, Confluence, AWS Console, Slack та salesforce без повторного логіну.
Федерація ідентичності (Identity Federation): розширення SSO між організаціями або між корпоративними системами (Active Directory) та хмарними платформами через стандарти:
Приклад: Компанія використовує Microsoft Active Directory. Через Azure AD Federation співробітники заходять до AWS Console зі своїми корпоративними обліковими даними — централізовано, без окремих AWS-паролів.
| Можливість | AWS IAM | Azure AD (Entra ID) | Google Cloud IAM |
|---|---|---|---|
| Ролі та групи | ✅ | ✅ | ✅ |
| MFA | ✅ | ✅ | ✅ |
| Умовний доступ | Через IAM Conditions | ✅ Потужний | Через IAM Conditions |
| SSO | AWS IAM Identity Center | Azure AD SSO | Google Cloud Identity |
| Федерація | SAML, OIDC | SAML, OIDC | SAML, OIDC |
| Service Accounts (для сервісів) | IAM Roles | Managed Identities | Service Accounts |
Service Accounts / Managed Identities — особливо важливий механізм: дозволяє надавати права не людям, а сервісам і застосункам, без збереження статичних ключів у коді.
Навіть якщо хмарний провайдер абсолютно надійний — дані в хмарі можуть бути скомпрометовані через:
Шифрування гарантує, що навіть у разі фізичного або логічного доступу зловмисника до носія — дані будуть нечитабельними без ключа шифрування.
Дані у спокої (Data at Rest):
Дані, що зберігаються на носіях — дисках, об’єктному сховищі, в базах даних.
Приклад: Amazon S3 за замовчуванням шифрує всі об’єкти за допомогою SSE-S3 (ключі AWS) або SSE-KMS (ключі клієнта в AWS KMS).
Дані в транзиті (Data in Transit):
Дані, що передаються по мережі між клієнтом і хмарою або між хмарними сервісами.
Приклад: Взаємодія між браузером користувача та AWS API завжди здійснюється по HTTPS (TLS 1.3). Трафік між мікросервісами у VPC також може бути зашифрований взаємним TLS (mTLS).
KMS (Key Management Service) — спеціалізований хмарний сервіс для безпечного зберігання та управління ключами шифрування.
Ключові функції KMS:
Сервіси KMS провідних провайдерів:
Ієрархія ключів (приклад AWS KMS):
Майстер-ключ (CMK — Customer Master Key)
└── Ключ шифрування даних (DEK — Data Encryption Key)
└── Зашифровані дані
Опції управління ключами:
| Опція | Хто управляє ключами | Рівень контролю | Приклад |
|---|---|---|---|
| SSE-S3 | AWS (автоматично) | Мінімальний | Стандартне шифрування S3 |
| SSE-KMS | Клієнт через AWS KMS | Середній | Клієнт контролює доступ до ключа |
| SSE-C | Клієнт (власний ключ) | Максимальний | Клієнт надає ключ при кожному запиті |
| BYOK | Клієнт (Bring Your Own Key) | Максимальний | Власний HSM клієнта |
PKI (Public Key Infrastructure) — інфраструктура відкритих ключів для управління цифровими сертифікатами TLS:
Compliance (відповідність) — підтвердження того, що організація дотримується специфічних законодавчих вимог, галузевих стандартів або контрактних зобов’язань щодо захисту даних та безпеки інформаційних систем.
Невідповідність стандартам може призвести до:
GDPR (General Data Protection Regulation) — регламент Євросоюзу 2018 року, що встановлює вимоги до обробки персональних даних громадян ЄС.
Ключові вимоги GDPR:
| Вимога | Суть | Наслідки для хмари |
|---|---|---|
| Законна підстава обробки | Дані можна обробляти лише за наявності однієї з 6 законних підстав (згода, договір тощо) | Необхідно документувати мету збирання даних |
| Право на забуття | Суб’єкт може вимагати видалення своїх даних | Хмарна архітектура повинна дозволяти повне видалення даних |
| Мінімізація даних | Збирати лише дані, необхідні для конкретної мети | Не зберігати «на всяк випадок» |
| Обмеження передачі | Персональні дані ЄС не можуть передаватись у треті країни без додаткових гарантій | Вибір регіону датацентру провайдера |
| Повідомлення про витік | При витоку даних — повідомлення наглядового органу протягом 72 годин | Потрібні інструменти виявлення інцидентів |
| DPO | При масштабній обробці — призначення Офіцера захисту даних | Організаційна вимога |
Вимоги GDPR до хмарних рішень:
ISO 27001 — міжнародний стандарт для систем управління інформаційною безпекою (ISMS). На відміну від GDPR (закон), ISO 27001 є добровільним, але широко визнаним стандартом у галузі.
Структура ISO 27001:
Ключові домени контролів ISO 27001 (Annex A):
ISO 27017 та ISO 27018 — розширення 27001 спеціально для хмарних середовищ та захисту персональних даних у хмарі.
Всі три провайдери (AWS, Azure, GCP) пройшли сертифікацію ISO 27001/27017/27018, що підтверджує відповідність їхньої інфраструктури міжнародним стандартам безпеки.
SOC 2 (System and Organization Controls 2) — стандарт аудиту, розроблений Американським інститутом сертифікованих бухгалтерів (AICPA). Оцінює організацію за п’ятьма Критеріями довіри (Trust Service Criteria):
SOC 2 Type I — перевірка дизайну контролів на певний момент часу
SOC 2 Type II — перевірка ефективності контролів протягом тривалого (зазвичай 6–12 місяців) — більш значущий
| Стандарт | Сфера застосування | Вимоги |
|---|---|---|
| PCI DSS | Платіжні картки | 12 основних вимог до обробки даних карток; рівні відповідності залежать від обсягу транзакцій |
| HIPAA | Охорона здоров’я (США) | Захист електронних медичних даних (ePHI); вимагає BAA-угоди з хмарним провайдером |
| FedRAMP | Держпослуги (США) | Хмарні сервіси для урядових організацій США |
| DORA | Фінансовий сектор ЄС | Цифрова операційна стійкість; набрав чинності у 2025 р. |
| NIST CSF | Будь-яка галузь (США) | Фреймворк кібербезпеки; 5 функцій: Identify, Protect, Detect, Respond, Recover |
Важливо розуміти: те, що провайдер (AWS, Azure) сертифікований за ISO 27001 або PCI DSS, не означає, що клієнт автоматично відповідає цим стандартам. Сертифікат провайдера покриває лише його рівень відповідальності. Клієнт повинен самостійно забезпечити відповідність у своїй частині стеку.
Приклад: AWS має сертифікат PCI DSS. Але якщо е-commerce компанія зберігає номери карток у незашифрованому вигляді у своїй базі даних на AWS — вона порушує PCI DSS, незалежно від сертифікатів AWS.
Організація Cloud Security Alliance (CSA) щорічно публікує список найбільш критичних загроз для хмарних обчислень — «Top Threats to Cloud Computing». Ключові з них:
Загроза: Є найпоширенішою причиною витоків даних у хмарі. Відкриті S3-кошики, незахищені API-ендпоінти, надмірно дозвільні rules у security groups.
Відомі інциденти:
Методи захисту:
Загроза: Спільні облікові записи, відсутність MFA, надмірні привілеї, невидалені облікові записи звільнених співробітників.
Методи захисту:
Загроза: API без автентифікації або з слабкою автентифікацією, передача чутливих даних у параметрах URL, відсутність rate limiting.
Методи захисту:
Загроза: Публікація ключів API у відкритих репозиторіях (GitHub), фішинг, брутфорс.
Статистика: Дослідники щороку знаходять мільйони AWS-ключів у публічних GitHub-репозиторіях. Зловмисники сканують нові коміти у реальному часі — компрометація відбувається за секунди після публікації.
Методи захисту:
Загроза: Перевантаження інфраструктури потоком фіктивних запитів з метою зробити сервіс недоступним для легітимних користувачів.
Масштаб: У 2023 році Google відбив найбільшу зафіксовану DDoS-атаку інтенсивністю 398 мільйонів запитів/секунду (атака тривала 2 хвилини).
Методи захисту:
Загроза: Зловмисні або ненавмисні дії власних співробітників або підрядників.
Методи захисту:
Загроза: Компрометація сторонніх бібліотек або залежностей, що використовуються у хмарному застосунку.
Приклад (SolarWinds, 2020): Фіктивне оновлення ПЗ SolarWinds Orion містило бекдор. 18 000 організацій, включно з урядом США, встановили це оновлення.
Методи захисту:
Defense in Depth («Ешелонована оборона») — стратегія безпеки, за якої застосовується декілька незалежних рівнів захисту. Компрометація одного рівня не означає компрометацію всієї системи.
┌─────────────────────────────────────────────────────┐
│ Периметр: DDoS-захист, WAF, CDN filtering │
│ ┌────────────────────────────────────────────────┐ │
│ │ Мережа: VPC, Security Groups, NACLs │ │
│ │ ┌───────────────────────────────────────────┐ │ │
│ │ │ Ідентифікація: IAM, MFA, SSO │ │ │
│ │ │ ┌────────────────────────────────────┐ │ │ │
│ │ │ │ Дані: Шифрування at-rest/transit │ │ │ │
│ │ │ │ ┌─────────────────────────────┐ │ │ │ │
│ │ │ │ │ Застосунок: WAF, SAST/DAST │ │ │ │ │
│ │ │ │ └─────────────────────────────┘ │ │ │ │
│ │ │ └────────────────────────────────────┘ │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
Моніторинг та реагування (SIEM, SOC)
Системи виявлення та реагування на загрози:
| Інструмент | Провайдер | Функція |
|---|---|---|
| AWS CloudTrail | AWS | Аудит-лог всіх API-викликів |
| AWS GuardDuty | AWS | ML-детектор аномалій і загроз |
| AWS Security Hub | AWS | Централізоване управління безпекою |
| Azure Defender for Cloud | Azure | CSPM + захист ресурсів |
| Azure Sentinel | Azure | SIEM/SOAR платформа |
| Google Security Command Center | GCP | Централізований моніторинг безпеки |
| Google Chronicle | GCP | SIEM великого масштабу |
Реальні кейси — найкращий спосіб зрозуміти, де теорія перетворюється на мільйонні збитки та репутаційні катастрофи. Нижче — добірка гучних інцидентів, кожен з яких ілюструє конкретну категорію помилок.
Масштаб: дані ~106 мільйонів клієнтів США та Канади; штраф — $80 млн (OCC, США).
Що сталось: Колишня інженер AWS Пейдж Томпсон скористалась вразливістю у Web Application Firewall, який Capital One розгорнув в AWS. WAF мав надмірно широкі права IAM-ролі — це класичний надмірний привілей. Через атаку SSRF (Server-Side Request Forgery) вона змогла отримати тимчасові AWS credentials цієї ролі та вивантажити дані з S3-кошиків: імена, адреси, кредитні рейтинги, номери SSN.
Категорія помилок: порушення принципу мінімальних привілеїв (PoLP) + відсутність моніторингу аномальних API-запитів.
Висновок: Інфраструктура AWS не була зламана. Провайдер = не винен. Клієнт = відповідальний за конфігурацію своїх IAM-ролей.
Масштаб: вкрадені зашифровані сховища паролів 25+ мільйонів користувачів; збитки оцінюються в сотні мільйонів.
Що сталось: Зловмисники спочатку отримали доступ до хмарного середовища LastPass (AWS S3) через скомпрометованого DevOps-інженера. Потім, через домашній комп’ютер того ж інженера, вони вкрали закриті ключі шифрування, необхідні для розшифрування корпоративних сховищ у AWS. Домашня машина була заражена через вразливість у Plex Media Server.
Категорія помилок: відсутність ізоляції між корпоративними і особистими пристроями; надмірний доступ окремого інженера до master-ключів; відсутність апаратного HSM для зберігання критичних ключів.
Висновок: Ланцюжок атаки пройшов через найслабшу ланку — особистий пристрій поза корпоративним контролем. Навіть найсильніше хмарне шифрування не рятує, якщо ключі зберігаються неналежним чином.
Масштаб: повний доступ до внутрішніх IT-систем; хакер опублікував скріншоти з AWS, GCP, HackerOne-звітів.
Що сталось: 18-річний хакер зв’язався з підрядником Uber через WhatsApp, представившись IT-підтримкою. Підрядник мав вірні логін/пароль (злитий раніше), але вхід блокував MFA. Зловмисник атакував техніку MFA Fatigue (Prompt Bombing): надсилав десятки push-сповіщень підряд. Виснажений підрядник зрештою підтвердив один. Після входу хакер знайшов у корпоративній мережі PowerShell-скрипт із вшитим паролем адміністратора Thycotic (PAM-систему), що дало доступ вже до всього.
Категорія помилок: слабкий тип MFA (push-сповіщення без контексту); жорстко вписані паролі у скриптах; відсутність обмежень на кількість MFA-запитів.
Висновок: MFA — не срібна куля. Push-based MFA вразливий до Prompt Bombing. FIDO2/WebAuthn-ключі (наприклад, YubiKey) цього методу атаки не мають.
Масштаб: дані про місцезнаходження ~2,15 мільйона автомобілів японських клієнтів були публічно доступні з 2013 по 2023 рік.
Що сталось: Хмарне середовище Toyota Connected Corp. містило S3–сумісне сховище з телематичними даними автомобілів. Кошик був виставлений публічно через неправильну конфігурацію хмарної бази даних. Факт стався під час аудиту, ініційованого самою Toyota після іншого інциденту. Жодних активних систем контролю конфігурацій (CSPM) не було.
Категорія помилок: відсутність CSPM; відсутність регулярних аудитів; принцип «відкрито за замовчуванням» замість «закрито за замовчуванням».
Висновок: Звичайний скан AWS Config або Prowler виявив би цю проблему за лічені хвилини. 10 років даних — ціна відсутності автоматизованого контролю конфігурацій.
Масштаб: ~38 мільйонів записів від 47 різних організацій (включно з American Airlines, Ford, Indiana Department of Health).
Що сталось: Microsoft Power Apps дозволяв будувати порталові застосунки зі зв’язком до Dataverse. За замовчуванням таблиці Dataverse, підключені до порталу, були публічно доступні через API без автентифікації. Організації не підозрювали про це, бо інтерфейс не підкреслював цей ризик. Дослідники з UpGuard виявили відкриті дані: вакцинаційні записи, ПІБ, email-адреси.
Категорія помилок: небезпечні значення за замовчуванням у продукті провайдера + відсутність перевірки налаштувань приватності у замовників.
Висновок: Microsoft виправив проблему — закрив доступ за замовчуванням і додав автоматичне сканування. Але відповідальність за перевірку публічних ендпоінтів лежить і на клієнті.
Масштаб: ~18 000 організацій встановили заражене оновлення; серед жертв — Міністерство фінансів США, Microsoft, FireEye, НАТО.
Що сталось: Група Cozy Bear (APT29, ймовірно ФСБ РФ) проникла в CI/CD-систему SolarWinds та впровадила бекдор SUNBURST у легітимне оновлення Orion (версія 2020.2). Оновлення пройшло перевірку підпису і розповсюдилось як офіційний реліз. Бекдор спав 2 тижні після інсталяції, потім виходив на зв’язок через легітимно виглядаючий DNS-трафік, маскуючись під нормальну активність SolarWinds. Виявлено лише через 9 місяців.
Категорія помилок: відсутність захисту CI/CD-pipeline; відсутність верифікації цілісності артефактів збірки (SBOM); слабкий моніторинг на мережевому рівні.
Висновок: Найнебезпечніший вектор атаки — ті, яким ви довіряєте. Довіреним програмним забезпеченням від вендора. Тому SBOM (Software Bill of Materials), підписання артефактів і перевірка хеш-сум у CI/CD стали стандартом де-факто після цього інциденту.
| Інцидент | Рік | Вектор атаки | Корінна причина | Масштаб |
|---|---|---|---|---|
| Capital One | 2019 | SSRF + надмірний IAM | Порушення PoLP | 106 млн записів, штраф $80 млн |
| LastPass | 2022 | Компрометація особистого пристрою | Відсутність ізоляції, слабкий KMS | 25+ млн сховищ паролів |
| Uber | 2022 | MFA Fatigue + пароль у скрипті | Слабкий тип MFA, hardcoded secrets | Повний доступ до всіх систем |
| Toyota | 2023 | Відкрите хмарне сховище | Відсутність CSPM, погані defaults | 2,15 млн авто, 10 років витоку |
| Microsoft/Power Apps | 2021 | Відкritий API без автентифікації | Небезпечні defaults провайдера | 38 млн записів, 47 організацій |
| SolarWinds | 2020 | Атака на CI/CD (supply chain) | Відсутність захисту pipeline + SBOM | 18 000 організацій, уряд США |
Shared Responsibility Model є фундаментальною концепцією хмарної безпеки: провайдер захищає фізичну інфраструктуру, клієнт — відповідає за конфігурацію, IAM та захист своїх даних. Переважна більшість реальних інцидентів відбувається через помилки клієнта.
IAM є першою лінією захисту хмарних ресурсів. Принципи мінімальних привілеїв, MFA та Zero Trust є обов’язковими вимогами, а не опціональними рекомендаціями.
Шифрування даних як у спокої, так і в транзиті є стандартом де-факто. Управління ключами шифрування через KMS дозволяє клієнту зберігати повний контроль навіть при зберіганні даних у хмарі провайдера.
Стандарти відповідності (GDPR, ISO 27001, SOC 2, PCI DSS) є обов’язковими для більшості галузей. Сертифікат провайдера є необхідною, але не достатньою умовою відповідності — клієнт несе власну частину відповідальності.
Найпоширеніша загроза — неправильна конфігурація хмарних ресурсів. Стратегія Defense in Depth, CSPM-інструменти та моніторинг через SIEM/CloudTrail є ключовими засобами виявлення та запобігання інцидентам.