Модуль 1.3: Принципи безпеки

Складність: [СЕРЕДНЯ] - Фундаментальні концепції

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

Передумови: Модуль 1.2: Безпека хмарного провайдера

---

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

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

• Пояснити основні принципи безпеки: захист у глибину, мінімальні привілеї, нульова довіра та розподіл обов’язків
• Оцінити конфігурації Kubernetes відповідно до цих принципів для виявлення порушень
• Оцінити який принцип застосовується при аналізі конкретного сценарію безпеки
• Спроєктувати засоби безпеки, що реалізують кілька принципів одночасно

---

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

Принципи безпеки - це вічні правила, що керують рішеннями щодо безпеки. Технології змінюються - контейнери, Kubernetes, хмара - але ці принципи залишаються незмінними. Їх розуміння допомагає оцінити будь-яке питання безпеки, навіть для технологій, яких ви ніколи не бачили.

Питання KCSA часто перевіряють, чи можете ви застосувати ці принципи до конкретних сценаріїв. Знання принципів дає вам фреймворк для відповіді навіть на незнайомі питання.

---

Основні принципи безпеки

1. Глибинний захист

Ніколи не покладайтесь на один контроль безпеки.

┌─────────────────────────────────────────────────────────────┐
│              ГЛИБИННИЙ ЗАХИСТ                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ОДИН КОНТРОЛЬ (Крихкий)                                   │
│                                                             │
│  Фаєрвол ─────────────────────────────────→ Захищений      │
│                                               ресурс        │
│  Якщо фаєрвол впаде, ресурс відкритий                      │
│                                                             │
│  ───────────────────────────────────────────────────────── │
│                                                             │
│  БАГАТОРІВНЕВІ КОНТРОЛІ (Стійкий)                          │
│                                                             │
│  Фаєрвол → Network Policy → RBAC → Pod Security → App      │
│                                                   Auth      │
│                                                             │
│  Потрібно кілька збоїв, щоб дістатися до ресурсу           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

У контексті Kubernetes:

Рівень	Контроль безпеки
Cloud	VPC, групи безпеки, IAM
Cluster	RBAC, логування аудиту
Мережа	Network policies, service mesh
Навантаження	Pod Security Standards
Контейнер	SecurityContext, capabilities
Застосунок	Автентифікація, авторизація

2. Принцип мінімальних привілеїв

Надавайте лише мінімальний необхідний доступ.

┌─────────────────────────────────────────────────────────────┐
│              МІНІМАЛЬНІ ПРИВІЛЕЇ                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПОГАНО: Надмірно дозвільний                               │
│  ┌──────────────────────────────────────────────────────┐  │
│  │  Role: cluster-admin                                 │  │
│  │  Resources: * (все)                                  │  │
│  │  Verbs: * (всі дії)                                  │  │
│  │  "Просто дайте їм admin, щоб могли робити роботу"    │  │
│  └──────────────────────────────────────────────────────┘  │
│                                                             │
│  ДОБРЕ: Точно обмежений                                    │
│  ┌──────────────────────────────────────────────────────┐  │
│  │  Role: deployment-reader                             │  │
│  │  Resources: deployments                              │  │
│  │  Verbs: get, list, watch                             │  │
│  │  Namespace: team-a                                   │  │
│  │  "Надайте саме те, що потрібно, не більше"           │  │
│  └──────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ключові застосування:

Область	Приклад мінімальних привілеїв
RBAC	Ролі для простору імен замість кластерних
Capabilities	Скинути всі, додати лише потрібні
Мережа	Заборонити все, дозволити конкретне
Service accounts	Окремий для кожного навантаження
Доступ до файлів	Файлова система лише для читання

3. Нульова довіра

Ніколи не довіряй, завжди перевіряй.

┌─────────────────────────────────────────────────────────────┐
│              НУЛЬОВА ДОВІРА проти ПЕРИМЕТРОВОЇ БЕЗПЕКИ       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ТРАДИЦІЙНА (Замок і рів)                                  │
│  ┌────────────────────────────────────────────────┐        │
│  │  ФАЄРВОЛ                                      │        │
│  │  ┌──────────────────────────────────────────┐ │        │
│  │  │  Всередині = Довірений                   │ │        │
│  │  │  Весь внутрішній трафік дозволено         │ │        │
│  │  │  Потрапивши всередину, рухайся вільно     │ │        │
│  │  └──────────────────────────────────────────┘ │        │
│  └────────────────────────────────────────────────┘        │
│  Проблема: Атакуючий всередині має доступ до всього        │
│                                                             │
│  НУЛЬОВА ДОВІРА                                            │
│  ┌────────────────────────────────────────────────┐        │
│  │  Кожен запит перевіряється:                   │        │
│  │  • Хто робить запит?                          │        │
│  │  • Чи відповідає пристрій вимогам?            │        │
│  │  • Чи нормальний цей запит для ідентифікації? │        │
│  │  • Шифрувати весь трафік, внутрішній чи ні    │        │
│  └────────────────────────────────────────────────┘        │
│  Перевага: Порушення однієї системи не дає доступ до всіх  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Нульова довіра в Kubernetes:

Принцип	Реалізація в Kubernetes
Перевірка ідентифікації	Сильна автентифікація (OIDC, сертифікати)
Перевірка авторизації	RBAC для кожного запиту
Припущення компрометації	Network policies (заборона за замовчуванням)
Шифрування трафіку	TLS скрізь, service mesh
Обмеження радіусу ураження	Ізоляція просторами імен

4. Розділення обов’язків

Жодна людина не повинна контролювати всі аспекти критичного процесу.

┌─────────────────────────────────────────────────────────────┐
│              РОЗДІЛЕННЯ ОБОВ'ЯЗКІВ                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПОГАНО: Одна людина робить все                            │
│                                                             │
│  Розробник пише код                                         │
│      ↓                                                      │
│  Та ж людина розгортає на продакшн                         │
│      ↓                                                      │
│  Та ж людина затверджує свої зміни                         │
│                                                             │
│  Ризик: Шкідливі або помилкові зміни не виявляються       │
│                                                             │
│  ───────────────────────────────────────────────────────── │
│                                                             │
│  ДОБРЕ: Обов'язки розділені                                │
│                                                             │
│  Розробник → Code review → Сканування безпеки →            │
│  Затвердження → Інша людина/команда розгортає              │
│                                                             │
│  Перевага: Перевірки та противаги запобігають єдиній       │
│  точці компрометації                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

5. Безпечний збій

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

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕЧНИЙ ЗБІЙ проти ВІДКРИТОГО ЗБОЮ            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ВІДКРИТИЙ ЗБІЙ (Небезпечний)                              │
│  ├── Якщо сервіс авторизації недоступний, дозволити все    │
│  ├── Якщо контролер network policy впав, дозволити трафік  │
│  └── "Краще бути доступним, ніж безпечним"                 │
│                                                             │
│  БЕЗПЕЧНИЙ ЗБІЙ (Правильний)                               │
│  ├── Якщо сервіс авторизації недоступний, заборонити все   │
│  ├── Якщо контролер network policy впав, блокувати трафік  │
│  └── "Краще бути безпечним, ніж доступним"                 │
│                                                             │
│  Заборона за замовчуванням є прикладом безпечного збою:    │
│  - Network policy без правил = заборонити все              │
│  - RBAC без прив'язок = без доступу                        │
│  - Pod security admission = відхилити невідповідні поди    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Концепції безпеки

Тріада CIA

Три стовпи інформаційної безпеки:

┌─────────────────────────────────────────────────────────────┐
│                    ТРІАДА CIA                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│                   КОНФІДЕНЦІЙНІСТЬ                          │
│                        /\                                   │
│                       /  \                                  │
│                      /    \                                 │
│                     /      \                                │
│                    /   CIA  \                               │
│                   /          \                              │
│                  /____________\                             │
│          ЦІЛІСНІСТЬ            ДОСТУПНІСТЬ                  │
│                                                             │
│  КОНФІДЕНЦІЙНІСТЬ: Лише авторизований доступ до даних     │
│  • Шифрування, контроль доступу, автентифікація             │
│                                                             │
│  ЦІЛІСНІСТЬ: Дані точні та не модифіковані                │
│  • Контрольні суми, цифрові підписи, логи аудиту           │
│                                                             │
│  ДОСТУПНІСТЬ: Системи доступні коли потрібно               │
│  • Надлишковість, резервні копії, захист від DDoS           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

У Kubernetes:

Стовп	Приклади Kubernetes
Конфіденційність	Шифрування секретів, RBAC, network policies
Цілісність	Підписання образів, admission control, цілісність etcd
Доступність	Репліки, PDB, надлишковість кластера

Поверхня атаки

Сума всіх точок, де атакуючий може спробувати увійти або витягнути дані:

┌─────────────────────────────────────────────────────────────┐
│              ПОВЕРХНЯ АТАКИ KUBERNETES                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЗОВНІШНЯ ПОВЕРХНЯ АТАКИ                                   │
│  ├── Точка доступу API server                              │
│  ├── Ingress controllers                                   │
│  ├── Відкриті сервіси (LoadBalancer, NodePort)             │
│  └── SSH до вузлів                                         │
│                                                             │
│  ВНУТРІШНЯ ПОВЕРХНЯ АТАКИ                                  │
│  ├── Комунікація pod-to-pod                                │
│  ├── Токени service account                                │
│  ├── API Kubernetes з подів                                 │
│  ├── API kubelet                                           │
│  └── Доступ до etcd                                        │
│                                                             │
│  МІНІМІЗАЦІЯ ПОВЕРХНІ АТАКИ:                               │
│  • Вимкніть невикористані функції                          │
│  • Видаліть непотрібні пакети з образів                    │
│  • Використовуйте приватні кластери                        │
│  • Обмежте мережевий доступ                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Радіус ураження

Масштаб шкоди, якщо компонент скомпрометовано:

┌─────────────────────────────────────────────────────────────┐
│              ПРИКЛАДИ РАДІУСУ УРАЖЕННЯ                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ВЕЛИКИЙ РАДІУС УРАЖЕННЯ (Погано)                          │
│  • cluster-admin ServiceAccount                            │
│    → Компрометація = повний доступ до кластера              │
│  • Привілейований контейнер                                │
│    → Компрометація = доступ до вузла                        │
│  • Default ServiceAccount з доступом до секретів           │
│    → Компрометація = всі секрети простору імен              │
│                                                             │
│  МАЛИЙ РАДІУС УРАЖЕННЯ (Добре)                             │
│  • ServiceAccount для простору імен                         │
│    → Компрометація = обмежено одним простором імен          │
│  • Не-привілейований контейнер зі скинутими capabilities   │
│    → Компрометація = обмежено процесами контейнера          │
│  • Окремий ServiceAccount, без доступу до секретів         │
│    → Компрометація = мінімальний вплив                      │
│                                                             │
│  МЕТА: Мінімізувати радіус ураження на кожному рівні      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Застосування принципів до Kubernetes

Приклад: Захист веб-застосунку

┌─────────────────────────────────────────────────────────────┐
│              ПРИНЦИПИ В ДІЇ                                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  СЦЕНАРІЙ: Розгортання веб-застосунку з доступом до БД     │
│                                                             │
│  ГЛИБИННИЙ ЗАХИСТ                                          │
│  ├── Cloud: VPC з приватними підмережами                   │
│  ├── Cluster: RBAC для дозволів розгортання                │
│  ├── Мережа: Network policy лише для доступу до БД         │
│  ├── Под: Обмежений контекст безпеки                       │
│  └── Застосунок: Валідація введення, підготовлені запити   │
│                                                             │
│  МІНІМАЛЬНІ ПРИВІЛЕЇ                                       │
│  ├── ServiceAccount: Лише потрібні секрети                  │
│  ├── RBAC: Читання deployments лише у своєму просторі імен │
│  ├── Capabilities: Всі скинуті, жодної додано              │
│  ├── Мережа: Вихідний трафік лише до поду БД               │
│  └── БД: Користувач лише з SELECT, конкретні таблиці       │
│                                                             │
│  НУЛЬОВА ДОВІРА                                            │
│  ├── mTLS між веб-застосунком та БД                        │
│  ├── Network policy забороняє все крім явного дозволу      │
│  ├── Короткотривалі облікові дані БД                       │
│  └── Всі виклики API автентифіковані                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Чи знали ви?

• Глибинний захист походить з військової стратегії. Невдача лінії Мажино (один рівень) проти успішних багаторівневих захистів показує, чому кілька бар’єрів працюють.

• “Мінімальні привілеї” були формалізовані Джеромом Солтцером у 1974 році. Принцип старший за більшість операційних систем, що використовуються сьогодні.

• Нульова довіра була вперше описана у 2010 році Forrester Research, але Google BeyondCorp (2014) зробив її практичною для масштабу підприємства.

• Тріада CIA датується 1970-ми роками. Попри 50+ років існування, вона залишається фундаментом інформаційної безпеки.

---

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

Помилка	Чому це шкодить	Рішення
Один рівень безпеки	Один збій відкриває все	Глибинний захист
”Тимчасовий” admin-доступ	Тимчасовий стає постійним	Обмежений за часом та обсягом доступ
Довіра внутрішньому трафіку	Припускає безпеку периметру	Нульова довіра, network policies
Відкритий збій для доступності	Безпека вимкнена коли найбільш потрібна	Безпечний збій
Однакові облікові дані скрізь	Одна компрометація = повна компрометація	Унікальні, обмежені облікові дані

---

Тест

1. Що означає “глибинний захист”?

   Відповідь

   Використання кількох рівнів контролів безпеки, щоб якщо один рівень впаде, інші все ще забезпечували захист. Жодної єдиної точки відмови безпеки.

2. Згідно з принципом мінімальних привілеїв, як слід обмежувати ролі RBAC?

   Відповідь

   Якомога вужче. Надавайте перевагу ролям для простору імен замість ClusterRoles та надавайте лише конкретні verbs та resources, необхідні для завдання.

3. Яка різниця між “відкритим збоєм” та “безпечним збоєм”?

   Відповідь

   Відкритий збій дозволяє доступ, коли контроль безпеки виходить з ладу (небезпечно). Безпечний збій забороняє доступ, коли контроль виходить з ладу (правильно). Заборона за замовчуванням є прикладом безпечного збою.

4. Які три компоненти тріади CIA?

   Відповідь

   Конфіденційність (лише авторизований доступ), Цілісність (дані точні та не модифіковані) та Доступність (системи доступні коли потрібно).

5. Як нульова довіра відрізняється від традиційної периметрової безпеки?

   Відповідь

   Традиційна безпека довіряє всьому всередині мережевого периметру. Нульова довіра перевіряє кожен запит незалежно від джерела, припускає порушення та шифрує весь трафік.

---

Практична вправа: Застосування принципів

Сценарій: Перегляньте цю конфігурацію та визначте, який принцип безпеки порушує кожна:

# Конфігурація 1
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dev-access
subjects:
- kind: Group
  name: developers
roleRef:
  kind: ClusterRole
  name: cluster-admin
---
# Конфігурація 2
apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: webapp:latest
    securityContext:
      privileged: true
---
# Конфігурація 3
# Network policy: не визначено
# Всі поди можуть комунікувати з усіма іншими подами

Визначте порушений принцип для кожної:

Відповіді

Конфігурація 1 - Порушує мінімальні привілеї

• Розробники мають cluster-admin (повний доступ до кластера)
• Мають мати ролі для простору імен з конкретними дозволами

Конфігурація 2 - Порушує глибинний захист та мінімальні привілеї

• Привілейований режим надає повний доступ до хоста
• Великий радіус ураження при компрометації
• Має працювати не-привілейовано з мінімальними capabilities

Конфігурація 3 - Порушує нульову довіру та глибинний захист

• Весь трафік pod-to-pod дозволено за замовчуванням
• Довіряє внутрішній мережі
• Мають бути network policies заборони за замовчуванням

---

Підсумок

Принципи безпеки керують всіма рішеннями щодо безпеки:

Принцип	Основна ідея	Приклад Kubernetes
Глибинний захист	Кілька рівнів	RBAC + Network Policy + PSS
Мінімальні привілеї	Мінімальний доступ	Обмежені ролі, скинуті capabilities
Нульова довіра	Ніколи не довіряй, перевіряй	mTLS, network policies
Розділення обов’язків	Розділена відповідальність	Різні затверджувачі для продакшн
Безпечний збій	Безпечні за замовчуванням	Network policies заборони за замовчуванням

Ключові концепції:

• Тріада CIA: Конфіденційність, Цілісність, Доступність
• Поверхня атаки: Мінімізуйте точки входу
• Радіус ураження: Обмежте шкоду від компрометації

---

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

Модуль 2.1: Безпека площини управління - Захист компонентів площини управління Kubernetes.