Модуль 1.2: Безпека хмарного провайдера
Складність:
[СЕРЕДНЯ]- Фундаментальні знанняЧас на виконання: 25-30 хвилин
Передумови: Модуль 1.1: Чотири C безпеки хмарних технологій
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Пояснити модель спільної відповідальності та що належить вам, а що — хмарному провайдеру
- Оцінити засоби безпеки хмарного провайдера (IAM, VPC, шифрування), релевантні для Kubernetes
- Оцінити ризик неправильно налаштованих меж безпеки хмарного рівня для робочих навантажень кластера
- Порівняти стандартні налаштування безпеки керованих Kubernetes (EKS, GKE, AKS) між провайдерами
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Кожен кластер Kubernetes працює на інфраструктурі - будь то AWS, GCP, Azure або ваш власний центр обробки даних. Безпека цієї інфраструктури є фундаментом для всього іншого. Розуміння моделі спільної відповідальності є критичним, оскільки вона визначає за що ви відповідаєте порівняно з тим, що забезпечує хмарний провайдер.
Нерозуміння цієї межі є однією з найпоширеніших причин порушень безпеки у хмарі.
Модель спільної відповідальності
Розділ «Модель спільної відповідальності»Безпека хмари - це партнерство. Ви та ваш хмарний провайдер маєте свої обов’язки:
┌─────────────────────────────────────────────────────────────┐│ МОДЕЛЬ СПІЛЬНОЇ ВІДПОВІДАЛЬНОСТІ │├─────────────────────────────────────────────────────────────┤│ ││ "Безпека хмари" проти "Безпека в хмарі" ││ ││ ┌──────────────────────┬────────────────────────────────┐ ││ │ ХМАРНИЙ ПРОВАЙДЕР │ ВИ (КЛІЄНТ) │ ││ │ ВІДПОВІДАЛЬНІСТЬ │ ВІДПОВІДАЛЬНІСТЬ │ ││ ├──────────────────────┼────────────────────────────────┤ ││ │ │ │ ││ │ Фізична безпека │ Дані │ ││ │ Обладнання │ Управління ідентифікацією │ ││ │ Мережева інфра │ Конфігурація застосунку │ ││ │ Гіпервізор │ Конфігурація мережі │ ││ │ Обчислення/сховище │ Патчі ОС (IaaS) │ ││ │ Глобальна мережа │ Фаєрволи/групи безпеки │ ││ │ │ Вибір шифрування │ ││ │ │ Цілісність даних клієнта │ ││ │ │ │ ││ └──────────────────────┴────────────────────────────────┘ ││ ││ Межа зміщується залежно від типу сервісу (IaaS/PaaS) ││ │└─────────────────────────────────────────────────────────────┘Як зміщується відповідальність
Розділ «Як зміщується відповідальність»┌─────────────────────────────────────────────────────────────┐│ ВІДПОВІДАЛЬНІСТЬ ЗА МОДЕЛЛЮ СЕРВІСУ │├─────────────────────────────────────────────────────────────┤│ ││ ЛОКАЛ. IaaS PaaS SaaS ││ ──────── ──── ──── ──── ││ Дані ВИ ВИ ВИ ВИ ││ Застосунок ВИ ВИ ВИ Провайдер ││ Runtime ВИ ВИ Провайдер Провайдер ││ ОС ВИ ВИ Провайдер Провайдер ││ Віртуалізація ВИ Провайдер Провайдер Провайдер ││ Обладнання ВИ Провайдер Провайдер Провайдер ││ Мережа ВИ Провайдер Провайдер Провайдер ││ Фізична ВИ Провайдер Провайдер Провайдер ││ ││ Більше керовано = менше відповідальності, але менше ││ контролю ││ │└─────────────────────────────────────────────────────────────┘Безпека керованого Kubernetes
Розділ «Безпека керованого Kubernetes»Керовані сервіси Kubernetes (EKS, GKE, AKS) змінюють модель відповідальності:
Що забезпечує провайдер
Розділ «Що забезпечує провайдер»┌─────────────────────────────────────────────────────────────┐│ КЕРОВАНИЙ KUBERNETES - ОБСЯГ ПРОВАЙДЕРА │├─────────────────────────────────────────────────────────────┤│ ││ ПЛОЩИНА УПРАВЛІННЯ ││ ├── Доступність та оновлення API server ││ ├── Доступність та резервне копіювання etcd ││ ├── Controller manager ││ ├── Scheduler ││ └── Мережева безпека площини управління ││ ││ ІНФРАСТРУКТУРА ││ ├── Фізична безпека центрів обробки даних ││ ├── Мережева магістраль ││ ├── Обслуговування обладнання ││ └── Безпека гіпервізора ││ ││ ВІДПОВІДНІСТЬ ││ ├── SOC 2 Type II ││ ├── ISO 27001 ││ └── Різні регуляторні сертифікації ││ │└─────────────────────────────────────────────────────────────┘Що забезпечуєте ви
Розділ «Що забезпечуєте ви»┌─────────────────────────────────────────────────────────────┐│ КЕРОВАНИЙ KUBERNETES - ВАШ ОБСЯГ │├─────────────────────────────────────────────────────────────┤│ ││ КОНФІГУРАЦІЯ КЛАСТЕРА ││ ├── Політики RBAC ││ ├── Мережеві політики ││ ├── Pod Security Standards ││ ├── Admission controllers ││ └── Конфігурація політики аудиту ││ ││ РОБОЧІ НАВАНТАЖЕННЯ ││ ├── Образи контейнерів ││ ├── Контексти безпеки подів ││ ├── Конфігурація застосунку ││ └── Управління секретами ││ ││ РОБОЧІ ВУЗЛИ (варіюється за провайдером) ││ ├── Безпека ОС вузла ││ ├── Конфігурація групи вузлів ││ └── Оновлення вузлів (часто автоматизовано) ││ ││ ДАНІ ││ ├── Дані вашого застосунку ││ ├── Управління ключами шифрування ││ └── Резервне копіювання та відновлення ││ │└─────────────────────────────────────────────────────────────┘Cloud IAM для Kubernetes
Розділ «Cloud IAM для Kubernetes»Управління ідентифікацією та доступом (IAM) є критичним для безпеки хмари:
Основи IAM
Розділ «Основи IAM»┌─────────────────────────────────────────────────────────────┐│ ОСНОВНІ КОНЦЕПЦІЇ IAM │├─────────────────────────────────────────────────────────────┤│ ││ ПРИНЦИПАЛ ХТО запитує доступ? ││ ├── Users Ідентифікації людей ││ ├── Groups Колекції користувачів ││ ├── Roles Ідентифікації для прийняття ││ └── Service Accts Ідентифікації машин ││ ││ ДІЯ ЩО вони намагаються зробити? ││ ├── Read Get, List, Describe ││ ├── Write Create, Update, Delete ││ └── Admin Повний контроль, зміни IAM ││ ││ РЕСУРС ЯКИЙ ресурс задіяний? ││ ├── Конкретний arn:aws:s3:::my-bucket/file.txt ││ ├── Шаблон arn:aws:s3:::my-bucket/* ││ └── Усі * (небезпечно!) ││ ││ УМОВА ЗА ЯКИХ обставин? ││ ├── За часом Лише в робочі години ││ ├── За IP Лише з корпоративної мережі ││ └── Вимога MFA Лише з другим фактором ││ │└─────────────────────────────────────────────────────────────┘Інтеграція Kubernetes з IAM
Розділ «Інтеграція Kubernetes з IAM»Cloud IAM інтегрується з Kubernetes двома ключовими способами:
┌─────────────────────────────────────────────────────────────┐│ IAM + ІНТЕГРАЦІЯ KUBERNETES │├─────────────────────────────────────────────────────────────┤│ ││ 1. ДОСТУП ДО КЛАСТЕРА ││ Cloud IAM контролює, хто може отримати доступ ││ ││ Користувач → Cloud IAM → API Server → Kubernetes RBAC ││ ││ Приклад (AWS EKS): ││ - IAM user/role автентифікується в AWS ││ - aws-auth ConfigMap відображає IAM на групи K8s ││ - RBAC авторизує дії в кластері ││ ││ 2. ІДЕНТИФІКАЦІЯ РОБОЧИХ НАВАНТАЖЕНЬ ││ Поди можуть приймати IAM-ролі хмари ││ ││ Pod → ServiceAccount → Cloud IAM Role → AWS API ││ ││ Приклад (GKE Workload Identity): ││ - K8s ServiceAccount анотовано з GCP SA ││ - Под автоматично отримує облікові дані GCP ││ - Статичні облікові дані не потрібні ││ │└─────────────────────────────────────────────────────────────┘Переваги Workload Identity
Розділ «Переваги Workload Identity»Чому використовувати workload identity замість статичних облікових даних?
| Статичні облікові дані | Workload Identity |
|---|---|
| Довготривалі секрети | Короткотривалі токени |
| Зберігаються в кластері | Автоматично ротуються |
| Однакові для всіх подів | Ідентифікація для кожного поду |
| Ручна ротація | Керується провайдером |
| Ризик розкриття | Мінімальний радіус ураження |
Контролі безпеки інфраструктури
Розділ «Контролі безпеки інфраструктури»Мережева безпека
Розділ «Мережева безпека»┌─────────────────────────────────────────────────────────────┐│ МЕРЕЖЕВА БЕЗПЕКА ХМАРИ │├─────────────────────────────────────────────────────────────┤│ ││ VPC (Virtual Private Cloud) ││ ├── Ізольований мережевий простір ││ ├── Власний діапазон IP-адрес ││ └── Фундамент для інших мережевих контролів ││ ││ ПІДМЕРЕЖІ ││ ├── Публічні підмережі → Ресурси з доступом до інтернету ││ ├── Приватні підмережі → Внутрішні ресурси ││ └── Площина управління → Часто в підмережі провайдера ││ ││ ГРУПИ БЕЗПЕКИ ││ ├── Фаєрволи зі збереженням стану ││ ├── Лише правила дозволу (неявна заборона) ││ └── Застосовуються до екземплярів/ENI ││ ││ МЕРЕЖЕВІ ACL ││ ├── Фаєрволи без збереження стану ││ ├── Правила дозволу та заборони ││ └── Застосовуються до підмереж ││ ││ Найкраща практика: Приватні підмережі для робочих вузлів, ││ публічні лише для балансувальників навантаження за потреби ││ │└─────────────────────────────────────────────────────────────┘Шифрування
Розділ «Шифрування»┌─────────────────────────────────────────────────────────────┐│ РІВНІ ШИФРУВАННЯ │├─────────────────────────────────────────────────────────────┤│ ││ ШИФРУВАННЯ ПРИ ПЕРЕДАЧІ ││ ├── TLS для комунікації з API server ││ ├── TLS між вузлами та площиною управління ││ ├── TLS для peer-комунікації etcd ││ └── Service mesh для шифрування pod-to-pod ││ ││ ШИФРУВАННЯ У СПОКОЇ ││ ├── Шифрування EBS/дисків (ключі провайдера) ││ ├── Шифрування etcd (секрети Kubernetes) ││ ├── Шифрування об'єктного сховища (S3, GCS) ││ └── Ключі, керовані клієнтом (CMK) для більшого контролю ││ ││ УПРАВЛІННЯ КЛЮЧАМИ ││ ├── Cloud KMS для зберігання ключів ││ ├── Патерн конвертного шифрування ││ ├── Політики ротації ключів ││ └── Логування аудиту використання ключів ││ │└─────────────────────────────────────────────────────────────┘Розгляд багатоорендності
Розділ «Розгляд багатоорендності»Коли кілька команд або застосунків спільно використовують інфраструктуру:
┌─────────────────────────────────────────────────────────────┐│ РІВНІ ІЗОЛЯЦІЇ БАГАТООРЕНДНОСТІ │├─────────────────────────────────────────────────────────────┤│ ││ НАЙСИЛЬНІША: Окремі хмарні облікові записи ││ ├── Повна ізоляція радіусу ураження ││ ├── Окремі межі IAM ││ ├── Незалежний біллінг ││ └── Для: Продакшн проти не-продакшн, різні клієнти ││ ││ СИЛЬНА: Окремі кластери ││ ├── Ізоляція на рівні кластера ││ ├── Окремий RBAC ││ ├── Без спільної площини управління ││ └── Для: Різні рівні безпеки, команди ││ ││ ПОМІРНА: Ізоляція просторами імен ││ ├── RBAC для кожного простору імен ││ ├── Мережеві політики між просторами імен ││ ├── Квоти ресурсів ││ └── Для: Різні застосунки, середовища ││ ││ СЛАБКА: Один простір імен (не рекомендовано) ││ └── Без ізоляції між робочими навантаженнями ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
85% порушень безпеки у хмарі пов’язані з людськими помилками - зазвичай неправильно налаштований IAM або відкриті сховища, а не витончені атаки.
-
Workload Identity повністю усуває потребу в статичних облікових даних. GKE Workload Identity, EKS IAM Roles for Service Accounts (IRSA) та AKS Workload Identity реалізують цей патерн.
-
Модель спільної відповідальності була вперше популяризована AWS, але тепер є галузевим стандартом для всіх основних хмарних провайдерів.
-
Приватні кластери (без публічної точки доступу API) все частіше стають стандартом для продакшн-розгортань Kubernetes, вимагаючи доступу через VPN або bastion.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Рішення |
|---|---|---|
| Вважати, що хмарний провайдер все захищає | Ви відповідаєте за конфігурацію | Знайте модель спільної відповідальності |
| Статичні облікові дані для подів | Довготривалі секрети можуть витекти | Використовуйте workload identity |
| Публічна точка доступу API server | Відкритий для атак з інтернету | Використовуйте приватні кластери |
| Надмірно дозвільні IAM-політики | Занадто великий радіус ураження | Застосовуйте мінімальні привілеї |
| Не шифрувати etcd | Секрети зберігаються відкритим текстом | Увімкніть шифрування у спокої |
Тест
Розділ «Тест»-
У моделі спільної відповідальності, хто відповідає за конфігурацію RBAC Kubernetes у керованому Kubernetes?
Відповідь
Клієнт (ви). Хмарні провайдери управляють інфраструктурою площини управління, але ви конфігуруєте, як вона використовується (RBAC, мережеві політики тощо). -
Що таке workload identity?
Відповідь
Функція, яка дозволяє подам Kubernetes приймати IAM-ролі хмари без статичних облікових даних. ServiceAccount поду відображається на хмарну ідентифікацію, забезпечуючи короткотривалі, автоматично ротовані облікові дані. -
Чому робочі вузли повинні бути у приватних підмережах?
Відповідь
Для зменшення поверхні атаки. Робочі вузли не потребують прямого доступу до інтернету (вони можуть використовувати NAT для вихідного трафіку). Приватні підмережі запобігають прямому вхідному доступу з інтернету. -
Яке шифрування слід увімкнути для секретів Kubernetes, що зберігаються в etcd?
Відповідь
Шифрування у спокої для etcd. За замовчуванням секрети лише кодуються base64, але не шифруються. Увімкнення шифрування у спокої захищає секрети, якщо сховище etcd буде скомпрометоване. -
У багатоорендному середовищі, що забезпечує найсильнішу ізоляцію?
Відповідь
Окремі хмарні облікові записи забезпечують найсильнішу ізоляцію з незалежними межами IAM та повним розділенням радіусу ураження. Окремі кластери забезпечують сильну ізоляцію в межах облікового запису.
Практична вправа: Категоризація відповідальності
Розділ «Практична вправа: Категоризація відповідальності»Сценарій: Ви розгортаєте новий застосунок у керованому Kubernetes (наприклад, EKS). Класифікуйте кожне завдання безпеки:
| Завдання безпеки | Провайдер чи клієнт? |
|---|---|
| Оновлення Kubernetes API server | ? |
| Створення RBAC-ролей для розробників | ? |
| Увімкнення шифрування etcd | ? |
| Забезпечення фізичного доступу до центру обробки даних | ? |
| Налаштування мережевих політик | ? |
| Оновлення ОС робочих вузлів | ? |
| Управління секретами вашого застосунку | ? |
| Забезпечення високої доступності API server | ? |
Відповіді
| Завдання безпеки | Відповідальність |
|---|---|
| Оновлення Kubernetes API server | Провайдер - Вони управляють площиною управління |
| Створення RBAC-ролей для розробників | Клієнт - Ви конфігуруєте доступ |
| Увімкнення шифрування etcd | Клієнт (зазвичай) - Ви вирішуєте налаштування шифрування |
| Забезпечення фізичного доступу до ЦОД | Провайдер - Фізична безпека |
| Налаштування мережевих політик | Клієнт - Ви конфігуруєте мережу навантажень |
| Оновлення ОС робочих вузлів | Клієнт (але часто автоматизовано) |
| Управління секретами вашого застосунку | Клієнт - Дані вашого застосунку |
| Забезпечення високої доступності API server | Провайдер - Доступність площини управління |
Підсумок
Розділ «Підсумок»Безпека хмарного провайдера - це розуміння меж:
| Концепція | Ключові моменти |
|---|---|
| Спільна відповідальність | Провайдер захищає “хмару”, ви захищаєте “в хмарі” |
| Керований Kubernetes | Провайдер забезпечує площину управління, ви - навантаження |
| IAM | Фундамент всього доступу до хмари, інтегрується з Kubernetes |
| Workload Identity | Усуває статичні облікові дані для подів |
| Мережева безпека | Приватні підмережі, групи безпеки, шифрування при передачі |
| Багатоорендність | Обліковий запис > Кластер > Простір імен за силою ізоляції |
Пам’ятайте: Хмарний провайдер дає вам безпечні будівельні блоки. Зібрати їх безпечно - це ваша робота.
Наступний модуль
Розділ «Наступний модуль»Модуль 1.3: Принципи безпеки - Глибинний захист, мінімальні привілеї та інші фундаментальні принципи безпеки.