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

Складність: [ШВИДКО] - Фундаментальне мислення

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

Передумови: Модуль 0.1: Огляд KCSA

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

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

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

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

Безпека - це не просто перелік функцій для увімкнення. Це спосіб мислення. Найкращі професіонали з безпеки не просто знають інструменти - вони інакше думають про системи, завжди запитуючи “що може піти не так?” та “як це може бути зловжито?”

Це мислення відрізняє тих, хто складає іспити з безпеки, від тих, хто насправді захищає системи. Питання KCSA розроблені для перевірки цього мислення, а не просто запам’ятованих фактів.

Мислення безпеки

Думайте як атакуючий

Щоб ефективно захищатися, ви повинні розуміти, як думають атакуючі:

┌─────────────────────────────────────────────────────────────┐
│              МИСЛЕННЯ АТАКУЮЧОГО vs ЗАХИСНИКА               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  АТАКУЮЧИЙ                    │   ЗАХИСНИК                  │
│  ─────────────────────────────┼────────────────────────────│
│  "Де слабке місце?"           │  "Де мої слабкі місця?"    │
│  "Що відкрито?"               │  "Що я залишив відкритим?" │
│  "Чи можу підвищити привілеї?"│  "Як обмежити доступ?"     │
│  "Який шлях всередину?"       │  "Які шляхи існують?"      │
│  "Чи можу закріпитися?"       │  "Як виявити зміни?"       │
│                                                             │
│  Обидва ставлять ОДНАКОВІ питання з різних кутів           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Сценарій атакуючого

Більшість атак слідують передбачуваному шаблону:

┌─────────────────────────────────────────────────────────────┐
│              ТИПОВИЙ ЛАНЦЮГ АТАКИ                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. РОЗВІДКА                                                │
│     └── Що працює? Які версії? Що відкрито?                 │
│                                                             │
│  2. ПОЧАТКОВИЙ ДОСТУП                                       │
│     └── Використання вразливості, фішинг, вкрадені дані     │
│                                                             │
│  3. ПІДВИЩЕННЯ ПРИВІЛЕЇВ                                    │
│     └── Низький привілей → високий привілей доступу          │
│                                                             │
│  4. БІЧНИЙ РУХ                                              │
│     └── Переміщення від скомпрометованої системи до інших   │
│                                                             │
│  5. ЗАКРІПЛЕННЯ                                             │
│     └── Збереження доступу навіть після виявлення            │
│                                                             │
│  6. ВПЛИВ                                                   │
│     └── Крадіжка даних, програми-вимагачі, порушення роботи │
│                                                             │
│  ЗАХИСТ: Розірвіть ланцюг на БУДЬ-ЯКОМУ кроці              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Три принципи керують майже кожним рішенням щодо безпеки:

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

Ніколи не покладайтесь на один контроль безпеки. Накладайте захисти шарами, щоб атакуючі мусили обійти кілька бар’єрів:

┌─────────────────────────────────────────────────────────────┐
│              ГЛИБИННИЙ ЗАХИСТ                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Мережевий фаєрвол  ████████████████████████████████████   │
│     │                                                       │
│     └── Kubernetes Network Policy  ███████████████████████  │
│            │                                                │
│            └── Pod Security Standards  ███████████████████  │
│                   │                                         │
│                   └── Контекст безпеки контейнера  ████████ │
│                          │                                  │
│                          └── Безпека застосунку  ██████     │
│                                 │                           │
│                                 └── Захищений ресурс ▓     │
│                                                             │
│  Якщо один рівень впаде, інші все ще захищають ресурс      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Надавайте лише мінімальні дозволи, необхідні для виконання завдання:

ПОГАНО: Дати admin-доступ "на всякий випадок"
ДОБРЕ: Дати доступ на читання до конкретних просторів імен

ПОГАНО: Запускати контейнери від root для зручності
ДОБРЕ: Запускати від не-root користувача з конкретними capabilities

ПОГАНО: Дозволити весь мережевий трафік за замовчуванням
ДОБРЕ: Заборонити все, потім дозволити лише необхідні з'єднання

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

Ніколи не довіряй, завжди перевіряй. Не вважайте нічого всередині вашої мережі безпечним:

Традиційний: "Всередині фаєрволу = довірений"
Нульова довіра:  "Перевіряй кожен запит, незалежно від джерела"

Принципи нульової довіри:
• Перевіряйте явно (автентифікуйте та авторизуйте кожен запит)
• Використовуйте мінімальні привілеї (мінімізуйте обсяг та тривалість доступу)
• Припускайте компрометацію (проектуйте так, ніби атакуючі вже всередині)

Стратегія відповідей на питання з безпеки

Питання KCSA часто перевіряють ваше мислення щодо безпеки. Ось як підходити до них:

Шаблон “Найбезпечніший”

Коли запитують про “найбезпечніший” варіант, шукайте:

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

Приклад аналізу питання

Питання: Под має комунікувати з конкретним сервісом. Який найбезпечніший підхід до мережевої політики?

A) Без мережевої політики (дозволити весь трафік)
B) Дозволити вхідний трафік від усіх подів у просторі імен
C) Дозволити вхідний трафік лише від подів з конкретними мітками
D) Дозволити вхідний трафік з будь-якого джерела

Аналіз:

Варіант A: Без обмежень - небезпечно
Варіант B: Обмеження на рівні простору імен - краще, але надто широко
Варіант C: Обмеження за мітками - найточніше
Варіант D: Будь-яке джерело - ще гірше за A

Відповідь: C - Найконкретніший, мінімальні привілеї

Фреймворк 4 C

Кожне питання KCSA відображається на один із 4 C безпеки хмарних технологій:

┌─────────────────────────────────────────────────────────────┐
│                    МОДЕЛЬ 4 C                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                     CLOUD                            │   │
│  │  Інфраструктура: ВМ, мережі, IAM, сховище          │   │
│  │  ┌─────────────────────────────────────────────┐   │   │
│  │  │                  CLUSTER                     │   │   │
│  │  │  Kubernetes: API server, etcd, RBAC, PSS    │   │   │
│  │  │  ┌─────────────────────────────────────┐   │   │   │
│  │  │  │             CONTAINER               │   │   │   │
│  │  │  │  Runtime: образи, ізоляція, caps    │   │   │   │
│  │  │  │  ┌─────────────────────────────┐   │   │   │   │
│  │  │  │  │           CODE             │   │   │   │   │
│  │  │  │  │  Застосунок: auth, deps    │   │   │   │   │
│  │  │  │  └─────────────────────────────┘   │   │   │   │
│  │  │  └─────────────────────────────────────┘   │   │   │
│  │  └─────────────────────────────────────────────┘   │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Кожен рівень має бути захищений. Слабкість будь-де        │
│  може скомпрометувати всю систему.                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Коли бачите питання, запитайте: “Про який C це питання?”

Якщо питання згадує…	Це про…
IAM, VPC, хмарний провайдер	Cloud
API server, etcd, RBAC, вузли	Cluster
Образи, runtime, capabilities	Container
Залежності, автентифікація	Code

Поширені компроміси безпеки

Безпека завжди передбачає компроміси. KCSA перевіряє ваше розуміння цих компромісів:

Безпека проти зручності

Більш безпечно                       Більш зручно
────────────────────────────────────────────────────────────
Вимагати MFA для кожної дії          Єдиний вхід скрізь
Ротація облікових даних щогодини     Ніколи не ротувати
Заборонити весь мережевий трафік     Дозволити весь трафік

KCSA запитує: Який баланс доречний для сценарію?

Безпека проти продуктивності

Більш безпечно                       Краща продуктивність
────────────────────────────────────────────────────────────
Шифрувати весь трафік (TLS)          Простий HTTP
Сканувати кожен образ при виконанні  Пропустити сканування
Логувати кожен виклик API            Мінімальне логування

KCSA запитує: Які контролі безпеки варті витрат?

Безпека проти складності

Більш безпечно                       Простіше
────────────────────────────────────────────────────────────
Network policies для кожного поду    Без network policies
RBAC для кожного типу ресурсу        cluster-admin для всіх
Окремі service accounts              Default service account

KCSA запитує: Чи додана складність забезпечує значущу безпеку?

Чи знали ви?

Термін “Нульова довіра” був створений Forrester Research у 2010 році, але концепції сягають роботи Jericho Forum над “деперіметризацією” у 2004 році.
Глибинний захист походить з військової стратегії - ідея, що кілька оборонних ліній важче прорвати, ніж одну сильну.
Більшість порушень пов’язані зі скомпрометованими обліковими даними або неправильними конфігураціями, а не з витонченими експлойтами. Базова гігієна безпеки запобігає більшості атак.
Модель 4 C - це термінологія, специфічна для Kubernetes, але концепція багаторівневої безпеки є універсальною.

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

Помилка	Чому це шкодить	Рішення
Шукати “найскладнішу” відповідь	Складність - це не безпека	Обирайте найдоречніший контроль
Ігнорувати контекст сценарію	Різні сценарії потребують різних контролів	Уважно читайте питання
Вважати “більше = краще”	Надмірна безпека створює проблеми зручності	Застосовуйте принцип мінімальних привілеїв
Забувати глибинний захист	Один контроль може впасти	Шукайте багаторівневі підходи
Не думати як атакуючий	Пропуск очевидних вразливостей	Запитуйте “як це може бути зловжито?”

Тест

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

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

Відповідь
Надання лише мінімальних дозволів, необхідних для виконання потрібного завдання, не більше.
У моделі 4 C, що охоплює найвнутрішній ‘C’ (Code)?

Відповідь
Безпека на рівні застосунку, включаючи автентифікацію, авторизацію, валідацію вводу, залежності та практики безпечного кодування.
Яка ключова відмінність між традиційною периметровою безпекою та нульовою довірою?

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

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

Практична вправа: Аналіз безпеки

Хоча KCSA - це множинний вибір, аналіз реальних конфігурацій розвиває інтуїцію безпеки.

Сценарій: Перегляньте цю специфікацію поду та визначте проблеми безпеки:

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      runAsUser: 0
      privileged: true
    ports:
    - containerPort: 80
  hostNetwork: true
  hostPID: true

Ваше завдання: Назвіть щонайменше 5 проблем безпеки.

Проблеми безпеки

runAsUser: 0 - Запуск від root всередині контейнера
privileged: true - Повні привілеї хоста, можлива втеча з контейнера
image: myapp:latest - Змінний тег, непередбачувана версія
hostNetwork: true - Под використовує мережевий простір імен хоста
hostPID: true - Под може бачити процеси хоста, уможливлює втечу
Без обмежень ресурсів - Може споживати надмірні ресурси
Без readOnlyRootFilesystem - Контейнер може писати у файлову систему

Вплив: Цей под може легко вирватися на хост та скомпрометувати весь вузол.

Підсумок

Мислення безпеки полягає у:

Думанні як атакуючий для передбачення загроз
Застосуванні основних принципів: глибинний захист, мінімальні привілеї, нульова довіра
Використанні фреймворку 4 C для категоризації проблем безпеки
Розумінні компромісів між безпекою, зручністю та складністю

Для питань KCSA:

Шукайте найконкретніший, мінімальних привілеїв варіант
Врахуйте який C стосується питання
Пам’ятайте, що багаторівнева безпека майже завжди краща
Уважно читайте - контекст має значення

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

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