Модуль 5.2: Спостережуваність безпеки

Складність: [СЕРЕДНЯ] - Основні знання

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

Передумови: Модуль 5.1: Безпека образів

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

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

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

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

Ви не можете захистити те, чого не бачите. Спостережуваність безпеки — журнали, метрики, трейси та події — забезпечує видимість поведінки кластера, дозволяючи виявляти загрози, розслідувати інциденти та перевіряти засоби безпеки.

KCSA перевіряє ваше розуміння моніторингу безпеки Kubernetes, журналювання аудиту та інструментів виявлення в реальному часі.

Стовпи спостережуваності безпеки

┌─────────────────────────────────────────────────────────────┐
│              СПОСТЕРЕЖУВАНІСТЬ БЕЗПЕКИ                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЖУРНАЛИ                                                   │
│  ├── Журнали аудиту API-сервера                            │
│  ├── Журнали застосунків у контейнерах                     │
│  ├── Системні журнали рівня вузла                          │
│  └── Журнали компонентів (kubelet, etcd тощо)              │
│                                                             │
│  МЕТРИКИ                                                   │
│  ├── Швидкість та помилки запитів API                      │
│  ├── Використання ресурсів (CPU, пам'ять, мережа)          │
│  ├── Невдалі спроби автентифікації/авторизації             │
│  └── Спеціалізовані метрики безпеки                        │
│                                                             │
│  ПОДІЇ                                                     │
│  ├── Події Kubernetes (події подів тощо)                   │
│  ├── Специфічні події безпеки                              │
│  ├── Порушення політик                                     │
│  └── Сповіщення безпеки часу виконання                     │
│                                                             │
│  ТРЕЙСИ                                                    │
│  ├── Потік запитів через сервіси                           │
│  ├── Ланцюги API-викликів                                  │
│  └── Відстеження розподілених транзакцій                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Журналювання аудиту Kubernetes

Політика аудиту

┌─────────────────────────────────────────────────────────────┐
│              РІВНІ ЖУРНАЛУ АУДИТУ                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  None       - Не журналювати                               │
│  Metadata   - Журналювати лише метадані запиту             │
│  Request    - Журналювати метадані + тіло запиту           │
│  RequestResponse - Журналювати метадані + запит + відповідь│
│                                                             │
│  СТАДІЇ АУДИТУ:                                            │
│  RequestReceived  - Коли запит вперше надходить            │
│  ResponseStarted  - Після відправки заголовків відповіді   │
│  ResponseComplete - Після відправки тіла відповіді         │
│  Panic            - При паніці                             │
│                                                             │
│  ЩО ЖУРНАЛЮВАТИ:                                           │
│  • Усі невдалі спроби автентифікації                      │
│  • Доступ до секретів                                      │
│  • Зміни RBAC                                              │
│  • Створення/видалення подів                               │
│  • Привілейовані операції                                  │
│  • Exec у контейнери                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Конфігурація політики аудиту

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Журналювати невдалі автентифікації на рівні метаданих
  - level: Metadata
    users: ["system:anonymous"]
    verbs: ["*"]

  # Журналювати доступ до секретів з тілом запиту
  - level: Request
    resources:
    - group: ""
      resources: ["secrets"]

  # Журналювати exec у поди з запитом та відповіддю
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods/exec", "pods/attach"]

  # Журналювати зміни RBAC
  - level: RequestResponse
    resources:
    - group: "rbac.authorization.k8s.io"
      resources: ["*"]

  # Журналювати операції з подами
  - level: Request
    resources:
    - group: ""
      resources: ["pods"]
    verbs: ["create", "delete", "patch", "update"]

  # За замовчуванням: журналювати метадані для решти
  - level: Metadata
    omitStages:
    - "RequestReceived"

Моніторинг безпеки часу виконання

Falco

┌─────────────────────────────────────────────────────────────┐
│              FALCO — БЕЗПЕКА ЧАСУ ВИКОНАННЯ                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЩО ТАКЕ FALCO?                                            │
│  • Проєкт CNCF для безпеки часу виконання                  │
│  • Моніторить системні виклики в реальному часі            │
│  • Виявляє аномальну поведінку                             │
│  • Обізнаний про Kubernetes (контекст поду)                │
│                                                             │
│  ЯК ПРАЦЮЄ:                                               │
│  Ядро → eBPF/модуль ядра → Falco → Правила → Сповіщення  │
│                                                             │
│  ВИЯВЛЯЄ:                                                  │
│  • Запуск оболонки в контейнері                            │
│  • Доступ до чутливих файлів (/etc/shadow)                 │
│  • Мережеві з'єднання від неочікуваних процесів           │
│  • Спроби підвищення привілеїв                             │
│  • Техніки втечі з контейнера                              │
│  • Поведінка криптомайнінгу                                │
│                                                             │
│  КАНАЛИ ВИВОДУ:                                            │
│  • Syslog, stdout                                          │
│  • HTTP webhook                                            │
│  • Сповіщення Slack, email                                 │
│  • Інтеграція з SIEM                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Правила Falco

# Виявлення запуску оболонки в контейнері
- rule: Terminal shell in container
  desc: A shell was spawned in a container
  condition: >
    spawned_process and
    container and
    shell_procs and
    proc.tty != 0
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name
     shell=%proc.name pod=%k8s.pod.name)
  priority: WARNING

# Виявлення читання чутливого файлу
- rule: Read sensitive file in container
  desc: Sensitive file read in container
  condition: >
    open_read and
    container and
    sensitive_files
  output: >
    Sensitive file read in container
    (file=%fd.name user=%user.name
     container=%container.name pod=%k8s.pod.name)
  priority: WARNING

Інші інструменти безпеки часу виконання

┌─────────────────────────────────────────────────────────────┐
│              ІНСТРУМЕНТИ БЕЗПЕКИ ЧАСУ ВИКОНАННЯ             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  TETRAGON (Cilium)                                         │
│  ├── Спостережуваність безпеки на основі eBPF              │
│  ├── Виконання процесів, мережа, доступ до файлів         │
│  ├── Можливості примусового виконання                     │
│  └── Низькі накладні витрати                               │
│                                                             │
│  SYSDIG                                                    │
│  ├── Комерційна безпека часу виконання                     │
│  ├── Побудована на технології Falco                        │
│  ├── Керовані правила та відповідність                     │
│  └── Корпоративні функції                                  │
│                                                             │
│  KUBEARMOR                                                 │
│  ├── Примусове виконання на основі LSM                    │
│  ├── Політики для процесів, файлів, мережі                │
│  └── Фокус на примусовому виконанні                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Журнали аудиту Kubernetes можуть бути надзвичайними — один завантажений кластер може генерувати гігабайти щодня. Правильна фільтрація та політики збереження є необхідними.
Falco використовує eBPF для моніторингу системних викликів з мінімальними накладними витратами. Він може виявити загрози, які мережеві інструменти пропускають.
Більшість порушень виявляються зовнішніми сторонами, а не внутрішнім моніторингом. Хороша спостережуваність значно покращує час виявлення.
Журнали аудиту є необхідними для відповідності (PCI-DSS, SOC2, HIPAA) та розслідування інцидентів.

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

Помилка	Чому це шкодить	Рішення
Без журналювання аудиту	Неможливо розслідувати інциденти	Увімкнути політику аудиту
Журналювати все	Шум, вартість, сховище	Налаштувати політику аудиту
Без збереження журналів	Докази втрачені	Визначити політику збереження
Сповіщення без реагування	Втома від сповіщень	Створити рунбуки
Без моніторингу часу виконання	Пізнє виявлення	Розгорнути Falco

Перевірка знань

Які чотири рівні журналу аудиту в Kubernetes?

Відповідь
None (не журналювати), Metadata (лише метадані запиту), Request (метадані + тіло запиту), RequestResponse (метадані + запит + відповідь). Вищі рівні надають більше деталей, але потребують більше сховища.
Що моніторить Falco і як?

Відповідь
Falco моніторить системні виклики за допомогою eBPF або модуля ядра. Він застосовує правила для виявлення аномальної поведінки, такої як запуск оболонки в контейнерах, доступ до чутливих файлів, підвищення привілеїв та мережеві аномалії. Він надає контекст Kubernetes (назва поду, простір імен) зі сповіщеннями.
Чому слід журналювати доступ до секретів?

Відповідь
Секрети містять чутливі дані (паролі, API-ключі, сертифікати). Журналювання доступу допомагає виявити несанкціоновані спроби доступу, дозволяє розслідування інцидентів, підтримує вимоги відповідності та забезпечує підзвітність.
Яка різниця між журналами аудиту та моніторингом безпеки часу виконання?

Відповідь
Журнали аудиту фіксують активність API-сервера (хто що зробив через API). Моніторинг безпеки часу виконання (Falco) фіксує активність на рівні системи всередині контейнерів (процеси, доступ до файлів, мережа). Обидва потрібні для повної видимості.
Які події повинні викликати негайні сповіщення?

Відповідь
Створення привілейованих подів, exec у продакшн-поди, зміни ролі cluster-admin, анонімний доступ до API, запуск оболонки в контейнерах, доступ до чутливих файлів та автентифікація з неочікуваних джерел. Вони вказують на потенційні активні атаки.

Підсумок

Спостережуваність безпеки забезпечує виявлення загроз та реагування на інциденти:

Компонент	Призначення	Інструменти
Журнали аудиту	Активність API	Вбудовані в Kubernetes
Моніторинг часу виконання	Поведінка контейнерів	Falco, Tetragon
Агрегація журналів	Централізований аналіз	ELK, Loki, Splunk
Сповіщення	Швидке реагування	PagerDuty, Slack

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

Журналюйте релевантні для безпеки події з відповідним рівнем деталей
Моніторте поведінку часу виконання, а не лише API
Сповіщуйте про високопріоритетні події
Зберігайте журнали для розслідування
Створюйте дашборди для видимості

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

Модуль 5.3: Безпека часу виконання — Застосування політик безпеки під час виконання.