Модуль 1.1: Чотири C безпеки хмарних технологій

Складність: [СЕРЕДНЯ] - Основний фреймворк

Час на виконання: 25-30 хвилин

Передумови: Модуль 0.2: Мислення безпеки

Що ви зможете робити

Після завершення цього модуля ви зможете:

Пояснити модель 4 C (Cloud, Cluster, Container, Code) та як кожен рівень будується на попередньому
Оцінити до якого рівня безпеки належить дана вразливість або неправильна конфігурація
Оцінити чи засіб безпеки адресує правильний рівень у ієрархії 4 C
Спроєктувати багаторівневий підхід до безпеки, використовуючи 4 C як організаційний фреймворк

Чому цей модуль важливий

4 C - це фундаментальна ментальна модель безпеки хмарних технологій. Кожне рішення з безпеки в Kubernetes відображається на один з цих рівнів. Опануйте цей фреймворк, і ви матимете структурований спосіб думати про будь-яке питання безпеки на іспиті KCSA.

Документація Kubernetes сама використовує цю модель, і вона безпосередньо з’являється у питаннях іспиту. Це не просто теорія - це офіційний спосіб категоризації безпеки хмарних технологій.

Модель 4 C

┌─────────────────────────────────────────────────────────────┐
│                    4 C БЕЗПЕКИ                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│      Кожен рівень будується на безпеці рівня нижче.        │
│      Порушення на будь-якому рівні компрометує всі          │
│      рівні вище нього.                                     │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                     CLOUD                            │   │
│  │  Фундамент інфраструктури                           │   │
│  │  ┌─────────────────────────────────────────────┐   │   │
│  │  │                  CLUSTER                     │   │   │
│  │  │  Компоненти та конфігурація Kubernetes       │   │   │
│  │  │  ┌─────────────────────────────────────┐   │   │   │
│  │  │  │             CONTAINER               │   │   │   │
│  │  │  │  Безпека образів та runtime         │   │   │   │
│  │  │  │  ┌─────────────────────────────┐   │   │   │   │
│  │  │  │  │           CODE             │   │   │   │   │
│  │  │  │  │  Безпека застосунку        │   │   │   │   │
│  │  │  │  └─────────────────────────────┘   │   │   │   │
│  │  │  └─────────────────────────────────────┘   │   │   │
│  │  └─────────────────────────────────────────────┘   │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Безпека на одному рівні НЕ МОЖЕ компенсувати             │
│  небезпеку на рівні нижче.                                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Критичне розуміння

Ви можете бути захищені лише настільки, наскільки захищений ваш найслабший рівень.

Якщо ваш рівень Cloud скомпрометований (хтось має ваші root-облікові дані AWS), не має значення, наскільки добре ви налаштували RBAC або безпеку контейнерів Kubernetes - атакуючий контролює все.

Рівень 1: Cloud (Інфраструктура)

Зовнішній рівень - ваш фундамент інфраструктури.

Що він включає

Компонент	Проблеми безпеки
Хмарний провайдер	AWS, GCP, Azure, локальна інфраструктура
Обчислення	ВМ, фізичні сервери
Мережа	VPC, підмережі, фаєрволи
Ідентифікація	IAM-ролі, сервісні облікові записи
Сховище	Блочне сховище, об’єктне сховище

Ключові контролі безпеки

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕКА РІВНЯ CLOUD                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ІДЕНТИФІКАЦІЯ ТА ДОСТУП                                   │
│  ├── IAM-політики (мінімальні привілеї)                    │
│  ├── MFA для привілейованих облікових записів               │
│  └── Ротація ключів сервісних облікових записів             │
│                                                             │
│  МЕРЕЖА                                                     │
│  ├── Ізоляція VPC                                          │
│  ├── Групи безпеки / фаєрволи                              │
│  ├── Приватні підмережі для площини управління              │
│  └── TLS для всього зовнішнього трафіку                    │
│                                                             │
│  ОБЧИСЛЕННЯ                                                 │
│  ├── Шифровані кореневі томи                               │
│  ├── Незмінна інфраструктура                               │
│  └── Регулярне оновлення / патчі                           │
│                                                             │
│  ДАНІ                                                       │
│  ├── Шифрування у спокої                                   │
│  ├── Шифрування при передачі                               │
│  └── Логування доступу                                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Спільна відповідальність Cloud

Хто за що відповідає залежить від моделі розгортання:

┌─────────────────────────────────────────────────────────────┐
│              МОДЕЛЬ СПІЛЬНОЇ ВІДПОВІДАЛЬНОСТІ                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  КЕРОВАНИЙ KUBERNETES (EKS, GKE, AKS)                       │
│  ├── Хмарний провайдер: Площина управління, інфраструктура │
│  └── Ви: Робочі навантаження, RBAC, network policies, поди │
│                                                             │
│  САМОКЕРОВАНИЙ KUBERNETES                                   │
│  ├── Хмарний провайдер: Лише фізична інфраструктура        │
│  └── Ви: Все інше (площина управління, вузли тощо)         │
│                                                             │
│  ЛОКАЛЬНА ІНФРАСТРУКТУРА                                    │
│  └── Ви: Все (від фізичної безпеки до застосунку)          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Рівень 2: Cluster (Kubernetes)

Рівень платформи Kubernetes - компоненти та конфігурація.

Що він включає

Компонент	Проблеми безпеки
Площина управління	API server, etcd, scheduler, controller-manager
Вузли	kubelet, kube-proxy, середовище виконання контейнерів
Автентифікація	Ідентифікація користувачів та сервісних облікових записів
Авторизація	RBAC, admission control
Секрети	Управління секретами Kubernetes

Ключові контролі безпеки

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕКА РІВНЯ CLUSTER                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  API SERVER                                                  │
│  ├── TLS для всієї комунікації API                         │
│  ├── Сильна автентифікація (OIDC, сертифікати)              │
│  ├── RBAC-авторизація                                      │
│  └── Ввімкнене логування аудиту                            │
│                                                             │
│  ETCD                                                        │
│  ├── Шифрування у спокої                                   │
│  ├── TLS для комунікації peer/client                       │
│  └── Обмежений мережевий доступ                            │
│                                                             │
│  ВУЗЛИ                                                       │
│  ├── Безпечна конфігурація kubelet                          │
│  ├── Вимкнені порти лише для читання                       │
│  └── Режим авторизації Node                                │
│                                                             │
│  РОБОЧІ НАВАНТАЖЕННЯ                                        │
│  ├── Pod Security Standards                                 │
│  ├── Network Policies                                       │
│  └── Квоти ресурсів                                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Рівень 3: Container (Runtime)

Рівень контейнерів - образи та ізоляція runtime.

Що він включає

Компонент	Проблеми безпеки
Образи	Базові образи, вразливості, походження
Runtime	containerd, CRI-O, gVisor
Ізоляція	Namespaces, cgroups, seccomp
Capabilities	Можливості Linux, привілейований режим

Ключові контролі безпеки

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕКА РІВНЯ CONTAINER                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ОБРАЗИ                                                     │
│  ├── Використовуйте мінімальні базові образи (distroless)  │
│  ├── Скануйте на вразливості                               │
│  ├── Підписуйте та перевіряйте образи                      │
│  └── Використовуйте незмінні теги (не :latest)             │
│                                                             │
│  RUNTIME                                                     │
│  ├── Запускайте від не-root користувача                     │
│  ├── Файлова система лише для читання                      │
│  ├── Скиньте всі capabilities, додайте лише потрібні       │
│  └── Використовуйте профілі seccomp/AppArmor               │
│                                                             │
│  ІЗОЛЯЦІЯ                                                    │
│  ├── Уникайте привілейованих контейнерів                   │
│  ├── Вимкніть hostPID, hostNetwork, hostIPC                 │
│  └── Розгляньте ізольовані runtime (gVisor, Kata)          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ризик втечі з контейнера

Чому безпека контейнерів має значення:

┌─────────────────────────────────────────────────────────────┐
│              ШЛЯХ ВТЕЧІ З КОНТЕЙНЕРА                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Неправильно налаштований контейнер                        │
│  │                                                          │
│  ├── privileged: true                                      │
│  │   └── Повний доступ до пристроїв та ядра хоста          │
│  │                                                          │
│  ├── hostPID: true                                         │
│  │   └── Може бачити процеси хоста та надсилати сигнали    │
│  │                                                          │
│  ├── hostNetwork: true                                     │
│  │   └── Може отримати доступ до мережі та сервісів вузла  │
│  │                                                          │
│  └── Все це → ВТЕЧА З КОНТЕЙНЕРА → КОМПРОМЕТАЦІЯ ВУЗЛА     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Рівень 4: Code (Застосунок)

Найвнутрішній рівень - ваш застосунок та його залежності.

Що він включає

Компонент	Проблеми безпеки
Залежності	Бібліотеки, пакети, ланцюг постачання
Автентифікація	Автентифікація користувачів, токени
Авторизація	Контроль доступу на рівні застосунку
Обробка даних	Валідація введення, шифрування
Секрети	API-ключі, облікові дані бази даних

Ключові контролі безпеки

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕКА РІВНЯ CODE                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  БЕЗПЕЧНЕ КОДУВАННЯ                                         │
│  ├── Валідація введення                                    │
│  ├── Кодування виводу                                      │
│  ├── Параметризовані запити (запобігання SQL-ін'єкціям)     │
│  └── Безпечна робота з пам'яттю                            │
│                                                             │
│  ЗАЛЕЖНОСТІ                                                  │
│  ├── Сканування на відомі вразливості (SCA)                │
│  ├── Фіксація версій                                      │
│  ├── Перевірка цілісності (контрольні суми, підписи)       │
│  └── Мінімізація залежностей                               │
│                                                             │
│  СЕКРЕТИ                                                     │
│  ├── Ніколи не вписуйте секрети в код                      │
│  ├── Використовуйте змінні середовища або сховища секретів │
│  ├── Регулярно ротуйте облікові дані                       │
│  └── Використовуйте короткотривалі токени                  │
│                                                             │
│  АВТЕНТИФІКАЦІЯ/АВТОРИЗАЦІЯ                                  │
│  ├── Сильні механізми автентифікації                        │
│  ├── Управління сесіями                                    │
│  └── Принцип мінімальних привілеїв                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Як рівні взаємодіють

Безпека каскадує вниз

Порушення на нижчому рівні компрометує всі рівні вище:

┌─────────────────────────────────────────────────────────────┐
│              КАСКАД ВПЛИВУ ПОРУШЕННЯ                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Порушення CLOUD (витік облікових даних AWS)                │
│  └── Атакуючий може:                                       │
│      ├── Отримати доступ до будь-якого Cluster              │
│      ├── Змінити будь-який Container                        │
│      └── Прочитати будь-який Code/Дані                      │
│                                                             │
│  Порушення CLUSTER (admin-доступ Kubernetes)                │
│  └── Атакуючий може:                                       │
│      ├── Розгорнути шкідливі Containers                    │
│      └── Отримати доступ до секретів Code                   │
│      (але інфраструктура Cloud залишається захищеною)       │
│                                                             │
│  Порушення CONTAINER (втеча з контейнера)                   │
│  └── Атакуючий може:                                       │
│      └── Отримати доступ до Code на тому ж вузлі           │
│      (але інші вузли можуть бути безпечні)                  │
│                                                             │
│  Порушення CODE (вразливість застосунку)                    │
│  └── Атакуючий може:                                       │
│      └── Отримати доступ до даних/секретів застосунку       │
│      (інші контейнери захищені)                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Застосування глибинного захисту

Захищайте кожен рівень незалежно:

Навіть якщо атакуючий скомпрометує рівень Code через
вразливість, належна безпека Container (не-root,
скинуті capabilities) обмежує його дії.

Навіть якщо він вирветься з Container, належна безпека
Cluster (RBAC, network policies) обмежує бічний рух.

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

Чи знали ви?

Модель 4 C походить з офіційної документації Kubernetes. Це не просто навчальний фреймворк - це те, як проєкт Kubernetes думає про безпеку.
Cloud є фундаментом не просто так. У 2023 році неправильні конфігурації cloud IAM були відповідальні за більше порушень, ніж будь-який інший окремий фактор.
Втечі з контейнерів напрочуд поширені, коли контейнери працюють у привілейованому режимі. Вразливість runc CVE-2019-5736 дозволяла втечу з контейнера через шкідливий образ.
Вразливості коду, такі як Log4Shell (CVE-2021-44228), показали, як одна залежність може скомпрометувати мільйони систем, незалежно від безпеки інфраструктури.

Поширені помилки

Помилка	Чому це шкодить	Рішення
Зосередження лише на рівні Cluster	Ігнорує ризики Cloud та Container	Захищайте всі чотири рівні
Вважати, що хмарний провайдер все забезпечує	Спільна відповідальність варіюється	Знайте свої обов’язки
Запуск привілейованих контейнерів	Легка втеча з контейнера	Використовуйте Pod Security Standards
Не сканувати залежності	Вразливості коду поширюються	Впровадьте SCA-сканування
Сприймати рівні як незалежні	Порушення каскадують	Проектуйте глибинний захист

Тест

Які 4 C безпеки хмарних технологій у порядку від зовнішнього до внутрішнього?

Відповідь
Cloud, Cluster, Container, Code. Від інфраструктури до застосунку.
Якщо атакуючий скомпрометує рівень Cluster, які рівні постраждають?

Відповідь
Рівні Container та Code вище нього. Рівень Cloud нижче залишається захищеним (хоча атакуючий може запитувати хмарні ресурси через кластер).
Який рівень включає Kubernetes RBAC?

Відповідь
Рівень Cluster. RBAC - це механізм авторизації Kubernetes.
Що означає “безпека каскадує вниз” у моделі 4 C?

Відповідь
Порушення на нижчому рівні (наприклад, Cloud) компрометує всі рівні вище нього (Cluster, Container, Code). Ви можете бути захищені лише настільки, наскільки захищений ваш найслабший рівень.
У моделі спільної відповідальності для керованого Kubernetes, за що зазвичай відповідає клієнт?

Відповідь
Робочі навантаження, конфігурація RBAC, мережеві політики, безпека подів, управління секретами та безпека застосунку. Хмарний провайдер управляє інфраструктурою площини управління.

Практична вправа: Категоризація контролів безпеки

Сценарій: Ваша команда захищає нове розгортання Kubernetes. Категоризуйте кожен контроль безпеки у правильний рівень.

Контроль безпеки	Рівень (Cloud/Cluster/Container/Code)
Правила фаєрволу VPC	?
RBAC roles та bindings	?
Запуск від не-root користувача	?
Валідація введення в API	?
Шифрування etcd	?
Сканування вразливостей образів	?
IAM-роль для сервісного облікового запису	?
Network policies	?

Відповіді

Контроль безпеки	Рівень
Правила фаєрволу VPC	Cloud - Мережа інфраструктури
RBAC roles та bindings	Cluster - Авторизація Kubernetes
Запуск від не-root користувача	Container - Безпека runtime
Валідація введення в API	Code - Безпека застосунку
Шифрування etcd	Cluster - Сховище даних Kubernetes
Сканування вразливостей образів	Container - Безпека образів
IAM-роль для сервісного облікового запису	Cloud - Ідентифікація інфраструктури
Network policies	Cluster - Мережа Kubernetes

Підсумок

Чотири C безпеки хмарних технологій:

Рівень	Обсяг	Ключові контролі
Cloud	Інфраструктура	IAM, VPC, шифрування, фаєрволи
Cluster	Kubernetes	RBAC, PSS, etcd, логування аудиту
Container	Runtime	Образи, не-root, capabilities
Code	Застосунок	Auth, залежності, секрети

Ключові принципи:

Безпека каскадує - порушення нижчого рівня компрометує верхні рівні
Глибинний захист - захищайте кожен рівень незалежно
Спільна відповідальність - знайте, за що ви відповідаєте
Найслабша ланка - ви захищені лише настільки, наскільки ваш найслабший рівень

Наступний модуль

Модуль 1.2: Безпека хмарного провайдера - Глибоке занурення у рівень Cloud, спільну відповідальність та безпеку інфраструктури.