Модуль 6.3: Оцінка безпеки
Складність:
[СЕРЕДНЯ]- Концептуальні знанняЧас на виконання: 25-30 хвилин
Передумови: Модуль 6.2: CIS Benchmarks
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Порівняти типи оцінок: сканування вразливостей, тести на проникнення, аудити безпеки та моделі загроз
- Оцінити стан безпеки Kubernetes за допомогою структурованих методологій оцінки
- Оцінити результати оцінок безпеки для пріоритизації виправлень за ризиком
- Спроєктувати постійну програму оцінки безпеки для середовищ Kubernetes
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Оцінки безпеки оцінюють стан безпеки вашого Kubernetes через систематичний аналіз, тестування та перевірку. Розуміння типів оцінок та процесів допомагає визначити прогалини, пріоритизувати покращення та продемонструвати безпеку зацікавленим сторонам.
KCSA перевіряє ваше розуміння моделювання загроз, оцінок безпеки та процесів аудиту.
Типи оцінок
Розділ «Типи оцінок»┌─────────────────────────────────────────────────────────────┐│ ТИПИ ОЦІНКИ БЕЗПЕКИ │├─────────────────────────────────────────────────────────────┤│ ││ ОЦІНКА ВРАЗЛИВОСТЕЙ ││ ├── Автоматичне сканування відомих вразливостей ││ ├── Сканування образів, сканування конфігурацій ││ ├── Низький бар'єр навичок ││ └── Приклади: Trivy, kube-bench ││ ││ ТЕСТУВАННЯ НА ПРОНИКНЕННЯ ││ ├── Активні спроби експлуатації ││ ├── Імітує реального зловмисника ││ ├── Потребує кваліфікованих тестувальників ││ └── Приклади: kube-hunter, ручне тестування ││ ││ АУДИТ БЕЗПЕКИ ││ ├── Перевірка політик, процедур, конфігурацій ││ ├── Може включати інтерв'ю та перевірку документів ││ ├── Орієнтований на відповідність ││ └── Приклади: аудит SOC 2, внутрішній аудит ││ ││ МОДЕЛЮВАННЯ ЗАГРОЗ ││ ├── Систематичний аналіз потенційних загроз ││ ├── Аналіз на етапі проєктування або часу виконання ││ ├── Визначає шляхи атак ││ └── Приклади: STRIDE, дерева атак ││ ││ ВПРАВА RED TEAM ││ ├── Повна імітація зловмисника ││ ├── Тестує виявлення та реагування ││ ├── Високо кваліфікована команда ││ └── Поєднує кілька технік ││ │└─────────────────────────────────────────────────────────────┘Моделювання загроз
Розділ «Моделювання загроз»Фреймворк STRIDE
Розділ «Фреймворк STRIDE»┌─────────────────────────────────────────────────────────────┐│ МОДЕЛЬ ЗАГРОЗ STRIDE │├─────────────────────────────────────────────────────────────┤│ ││ STRIDE = Поширені категорії загроз ││ ││ S - SPOOFING (Підробка) ││ ├── Видання себе за когось/щось інше ││ ├── K8s: Фальшивий ServiceAccount, вкрадені облікові дані││ └── Контроль: Сильна автентифікація, mutual TLS ││ ││ T - TAMPERING (Підробка даних) ││ ├── Модифікація даних або коду ││ ├── K8s: Зміна образу, зміни конфігурації ││ └── Контроль: Підписування, перевірки цілісності, RBAC ││ ││ R - REPUDIATION (Відмова від дій) ││ ├── Заперечення виконаних дій ││ ├── K8s: Видалення журналів аудиту ││ └── Контроль: Журналювання аудиту, незмінні журнали ││ ││ I - INFORMATION DISCLOSURE (Витік інформації) ││ ├── Несанкціонований доступ до інформації ││ ├── K8s: Відкритість секретів, перелік API ││ └── Контроль: Шифрування, RBAC, мережеві політики ││ ││ D - DENIAL OF SERVICE (Відмова в обслуговуванні) ││ ├── Робить систему недоступною ││ ├── K8s: Виснаження ресурсів, переповнення API ││ └── Контроль: Обмеження ресурсів, обмеження швидкості ││ ││ E - ELEVATION OF PRIVILEGE (Підвищення привілеїв) ││ ├── Отримання несанкціонованого доступу ││ ├── K8s: Втеча з контейнера, ескалація RBAC ││ └── Контроль: Мінімальні привілеї, безпека подів ││ │└─────────────────────────────────────────────────────────────┘Поширені шляхи атак Kubernetes
Розділ «Поширені шляхи атак Kubernetes»┌─────────────────────────────────────────────────────────────┐│ ПОШИРЕНІ ШЛЯХИ АТАК KUBERNETES │├─────────────────────────────────────────────────────────────┤│ ││ ЗОВНІШНІЙ → ПОЧАТКОВИЙ ДОСТУП ││ ├── Відкритий дашборд (без автентифікації) ││ ├── Вразливий застосунок ││ ├── Вкрадені облікові дані ││ ├── Ланцюг постачання (шкідливий образ) ││ └── Неправильно налаштований ingress ││ ││ ПОД → ГОРИЗОНТАЛЬНЕ ПЕРЕМІЩЕННЯ ││ ├── Токен ServiceAccount → доступ до API ││ ├── Сканування мережі → інші поди ││ ├── Змонтовані секрети → облікові дані ││ └── Спільні томи → доступ до даних ││ ││ ПОД → ПІДВИЩЕННЯ ПРИВІЛЕЇВ ││ ├── Привілейований контейнер → доступ до хоста ││ ├── Монтування hostPath → файлова система хоста ││ ├── RBAC → створення привілейованого поду ││ └── Втеча з контейнера → компрометація вузла ││ ││ ВУЗОЛ → КОМПРОМЕТАЦІЯ КЛАСТЕРА ││ ├── Доступ до kubelet → всі поди на вузлі ││ ├── Доступ до etcd → всі дані кластера ││ ├── Облікові дані вузла → хмарний провайдер ││ └── Переміщення на інші вузли ││ │└─────────────────────────────────────────────────────────────┘Тестування на проникнення
Розділ «Тестування на проникнення»kube-hunter
Розділ «kube-hunter»# Віддалене сканування (ззовні кластера)kube-hunter --remote 10.0.0.1
# Внутрішнє сканування (зсередини поду)kube-hunter --pod
# Сканування мережіkube-hunter --cidr 10.0.0.0/24
# Активна експлуатація (використовувати обережно!)kube-hunter --active
# Формати виводуkube-hunter --report jsonkube-hunter --report yamlОцінка ризиків
Розділ «Оцінка ризиків»┌─────────────────────────────────────────────────────────────┐│ ОЦІНКА РИЗИКІВ │├─────────────────────────────────────────────────────────────┤│ ││ РИЗИК = ЙМОВІРНІСТЬ × ВПЛИВ ││ ││ ФАКТОРИ ЙМОВІРНОСТІ: ││ ├── Мотивація суб'єкта загрози ││ ├── Складність атаки ││ ├── Існуючі контролі ││ ├── Рівень відкритості ││ └── Історичні дані ││ ││ ФАКТОРИ ВПЛИВУ: ││ ├── Чутливість даних ││ ├── Критичність системи ││ ├── Фінансовий вплив ││ ├── Репутаційний вплив ││ └── Регуляторний вплив ││ ││ МАТРИЦЯ РИЗИКІВ: ││ │ Низький │ Середній │ Високий │ ││ ─────────────┼─────────────┼─────────────┼─────────────│ ││ Висока ймов. │ Середній │ Високий │ Критичний │ ││ Середня ймов.│ Низький │ Середній │ Високий │ ││ Низька ймов. │ Низький │ Низький │ Середній │ ││ ││ РЕАГУВАННЯ: ││ Критичний → Негайна дія ││ Високий → Дія протягом днів ││ Середній → Дія протягом тижнів ││ Низький → Прийняти або планувати на майбутнє ││ │└─────────────────────────────────────────────────────────────┘Метрики безпеки
Розділ «Метрики безпеки»┌─────────────────────────────────────────────────────────────┐│ МЕТРИКИ БЕЗПЕКИ │├─────────────────────────────────────────────────────────────┤│ ││ МЕТРИКИ ВРАЗЛИВОСТЕЙ ││ ├── Загальна кількість вразливостей за серйозністю ││ ├── Середній час виправлення (MTTR) ││ ├── Вразливості поза SLA ││ └── Нові проти закритих вразливостей ││ ││ МЕТРИКИ ВІДПОВІДНОСТІ ││ ├── Відсоток проходження CIS benchmark ││ ├── Порушення політик ││ ├── Невдалі admissions ││ └── Оцінка відповідності з часом ││ ││ ОПЕРАЦІЙНІ МЕТРИКИ ││ ├── Покриття журналів аудиту ││ ├── Частота ротації секретів ││ ├── Покриття сканування образів ││ └── Покриття мережевих політик ││ ││ МЕТРИКИ ІНЦИДЕНТІВ ││ ├── Середній час виявлення (MTTD) ││ ├── Середній час реагування (MTTR) ││ ├── Інциденти за категорією ││ └── Відсоток хибних спрацювань ││ ││ ВІДСТЕЖУЙТЕ З ЧАСОМ: ││ • Тренди важливіші за абсолютні числа ││ • Порівнюйте з базовими лініями та цілями ││ • Регулярно звітуйте керівництву ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
STRIDE був розроблений у Microsoft у 1999 році і залишається одним із найширше використовуваних фреймворків моделювання загроз.
-
Тестування на проникнення керованого Kubernetes вимагає схвалення хмарного провайдера. AWS, GCP та Azure мають специфічні політики щодо тестування їхньої інфраструктури.
-
Більшість знахідок безпеки — це неправильні конфігурації, а не zero-day. Регулярні оцінки конфігурацій знаходять більше проблем, ніж тестування на проникнення.
-
Моделювання загроз найбільш ефективне на ранньому етапі — дешевше виправити проблеми безпеки під час проєктування, ніж після розгортання.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Рішення |
|---|---|---|
| Без моделі загроз | Пропуск ризиків | Моделювати перед побудовою |
| Тестування лише щорічно | Прогалини накопичуються | Безперервна оцінка |
| Без відстеження метрик | Неможливо виміряти покращення | Побудувати дашборди |
| Ігнорування низьких знахідок | Ланцюги до критичних | Пріоритизувати та планувати все |
| Без відстеження виправлень | Знахідки залишаються відкритими | Використовувати систему відстеження |
Перевірка знань
Розділ «Перевірка знань»-
Що означає STRIDE?
Відповідь
Spoofing (Підробка), Tampering (Підробка даних), Repudiation (Відмова від дій), Information Disclosure (Витік інформації), Denial of Service (Відмова в обслуговуванні) та Elevation of Privilege (Підвищення привілеїв). Це фреймворк моделювання загроз, який категоризує поширені загрози безпеки для систематичного визначення потенційних атак. -
Яка різниця між оцінкою вразливостей та тестуванням на проникнення?
Відповідь
Оцінка вразливостей використовує автоматизовані інструменти для визначення відомих вразливостей без їх експлуатації. Тестування на проникнення активно намагається експлуатувати вразливості для демонстрації реального впливу. Оцінка вразливостей є ширшою, але поверхнішою; тестування на проникнення є глибшим, але більш зосередженим. -
Чому моделювання загроз виконується на етапі проєктування?
Відповідь
Дешевше та легше вирішити проблеми безпеки під час проєктування, ніж після розгортання. Моделювання загроз визначає шляхи атак на ранньому етапі, коли зміни коштують менше. Це також забезпечує врахування безпеки з самого початку, а не її додавання пізніше. -
Що робить знахідку “Критичною” проти “Високої”?
Відповідь
Ризик = Ймовірність x Вплив. Критичні знахідки мають як високу ймовірність, так і високий вплив — вони легко експлуатуються та можуть спричинити значну шкоду. Високі знахідки можуть мати трохи нижчу ймовірність або вплив, але все ще потребують термінової уваги. -
Які докази зазвичай потребують аудитори?
Відповідь
Експорти конфігурацій (RBAC, політики), журнали аудиту, що показують роботу засобів безпеки, звіти сканування (вразливості, відповідність), документацію (політики, процедури) та іноді інтерв'ю з персоналом. Докази повинні демонструвати, що контролі існують та є ефективними з часом.
Підсумок
Розділ «Підсумок»Оцінки безпеки оцінюють та покращують безпеку Kubernetes:
| Тип оцінки | Призначення | Частота |
|---|---|---|
| Моделювання загроз | Визначення шляхів атак | Етап проєктування, великі зміни |
| Сканування вразливостей | Пошук відомих проблем | Безперервно |
| Тестування на проникнення | Доказ можливості експлуатації | Щоквартально/щорічно |
| Аудит безпеки | Перевірка відповідності | Щорічно |
Ключові практики:
- Використовуйте STRIDE для систематичного визначення загроз
- Поєднуйте автоматичне та ручне тестування
- Відстежуйте знахідки та прогрес виправлення
- Вимірюйте метрики безпеки з часом
- Оновлюйте моделі загроз зі зміною систем
Вітаємо!
Розділ «Вітаємо!»Ви завершили навчальну програму KCSA! Ви вивчили:
- Основи хмарної безпеки (4 C)
- Безпеку компонентів Kubernetes
- Контролі безпеки (RBAC, PSS, секрети, мережеві політики)
- Моделювання загроз та поверхні атак
- Безпеку платформи та інструменти
- Фреймворки відповідності та оцінки
Наступні кроки:
- Переглянути сфери, де відчуваєте себе менш впевнено
- Практикуватися з практичними вправами
- Складати практичні іспити
- Запланувати іспит KCSA
Бажаємо успіхів із сертифікацією!