Steel Shield
Steel Shield — це фреймворк зміцнення безпеки NetRecon. Він забезпечує кілька рівнів захисту для розгортань на власному сервері, гарантуючи цілісність та автентичність усіх компонентів платформи.
Огляд
Steel Shield включає чотири основні механізми безпеки:
| Функція | Призначення |
|---|---|
| Цілісність бінарних файлів | Перевірка того, що виконувані файли не були змінені |
| Закріплення сертифікатів | Запобігання атакам "людина посередині" на API-комунікації |
| Реагування на втручання | Виявлення та реагування на несанкціоновані модифікації |
| Захист під час виконання | Захист від маніпуляцій з пам'яттю та відладки |
Перевірка цілісності бінарних файлів
Кожен бінарний файл NetRecon (бекенд зонда, агенти, сервіси) має цифровий підпис. При запуску кожен компонент перевіряє власну цілісність.
Як це працює
- Під час збірки кожен бінарний файл підписується приватним ключем NetRecon
- Підпис вбудовується в метадані бінарного файлу
- При запуску бінарний файл обчислює SHA-256 хеш самого себе
- Хеш перевіряється за вбудованим підписом
- Якщо перевірка не пройшла, бінарний файл відмовляється запускатися та реєструє сповіщення
Ручна перевірка
Перевірте цілісність бінарного файлу вручну:
# Перевірка бекенда зонда
netrecon-verify /usr/local/bin/netrecon-probe
# Перевірка агента
netrecon-verify /usr/local/bin/netrecon-agent
# Очікуваний вивід:
# Binary: /usr/local/bin/netrecon-probe
# SHA-256: a1b2c3d4e5f6...
# Signature: VALID
# Signed by: NetRecon Build System
# Signed at: 2026-03-15T10:00:00Z
Перевірка Docker-образів
Docker-образи підписуються за допомогою Docker Content Trust (DCT):
# Увімкнення перевірки вмісту
export DOCKER_CONTENT_TRUST=1
# Завантаження з перевіркою підпису
docker pull netrecon/api-gateway:latest
Закріплення сертифікатів
Закріплення сертифікатів гарантує, що компоненти NetRecon спілкуються лише з легітимними серверами, запобігаючи перехопленню навіть якщо центр сертифікації скомпрометовано.
Закріплені з'єднання
| З'єднання | Тип закріплення |
|---|---|
| Агент до зонда | Закріплення відкритого ключа |
| Admin Connect до зонда | Відбиток сертифіката |
| Зонд до сервера оновлень | Закріплення відкритого ключа |
| Зонд до сервера ліцензій | Відбиток сертифіката |
Як це працює
- Очікуваний хеш відкритого ключа сертифіката вбудовується в кожен клієнтський бінарний файл
- При встановленні TLS-з'єднання клієнт витягує відкритий ключ сервера
- Клієнт обчислює SHA-256 хеш відкритого ключа
- Якщо хеш не збігається з закріпленим значенням, з'єднання відхиляється
- Невдала перевірка закріплення ініціює сповіщення безпеки
Ротація закріплень
При ротації сертифікатів:
- Нові закріплення розповсюджуються через сервер оновлень до зміни сертифіката
- Під час перехідного періоду дійсні як старі, так і нові закріплення
- Після переходу старі закріплення видаляю ться в наступному оновленні
Для розгортань на власному сервері оновіть закріплення в конфігурації:
# /etc/netrecon/security.yaml
certificate_pins:
api_gateway:
- "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=" # Поточний
- "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=" # Резервний
Реагування на втручання
Steel Shield моніторить критичні файли та конфігурації на предмет несанкціонованих змін.
Об'єкти моніторингу
| Об'єкт | Частота перевірки | Реагування |
|---|---|---|
| Бінарні файли | При запуску + кожну 1 годину | Сповіщення + опціональне вимкнення |
| Файли конфігурації | Кожні 5 хвилин | Сповіщення + відкат до резервної копії |
| Цілісність бази даних | Кожні 15 хвилин | Сповіщення + перевірка консистентності |
| TLS-сертифікати | Кожні 5 хвилин | Сповіщення при зміні |
| Системні пакети | Щоденно | Сповіщення при неочікуваних змінах |
Дії реагування
При виявленні втручання Steel Shield може:
- Журналювати — зафіксувати подію в журналі аудиту безпеки
- Сповістити — надіслати сповіщення через налаштовані канали
- Відкотити — відновити змінений файл з відомої робочої резервної копії
- Ізолювати — обмежити мережевий доступ лише до управління
- Вимкнути — зупинити сервіс для запобігання подальшій компрометації
Налаштуйте рівень реагування:
# /etc/netrecon/security.yaml
tamper_response:
level: "alert_and_revert" # Варіанти: log, alert, alert_and_revert, isolate, shutdown
notify_email: "[email protected]"
База даних цілісності файлів
Steel Shield підтримує базу даних хешів усіх захищених файлів:
# Ініціалізація бази даних цілісності
netrecon-shield init
# Перевірка цілісності вручну
netrecon-shield verify
# Очікуваний вивід:
# Checked 47 files
# Status: ALL INTACT
# Last verified: 2026-03-15T14:30:00Z
Захист під час виконання
Захист від відладки
У продакшн-режимі бінарні файли NetRecon включають засоби захисту від відладки:
- Виявлення підключених відладчиків (ptrace на Linux, IsDebuggerPresent на Windows)
- Перевірки часу для покрокового виконання
- При виявленні відладки в продакшні процес коректно завершується
Захист від відладки вимкнено в збірках для розробки для забезпечення звичайних робочих процесів відладки.
Захист пам'яті
- Конфіденційні дані (токени, ключі, паролі) зберігаються в захищених областях пам'яті
- Пам'ять очищається після використання для запобігання залишковому витоку даних
- На Linux використовується
mlockдля запобігання свопінгу конфіденційних сторінок на диск
Конфігурація
Увімкнення Steel Shield
Steel Shield увімкнено за замовчуванням у продакшн-розгортаннях. Налаштуйте в:
# /etc/netrecon/security.yaml
steel_shield:
enabled: true
binary_integrity: true
certificate_pinning: true
tamper_response: true
runtime_protection: true
integrity_check_interval: 3600 # секунди
tamper_check_interval: 300 # секунди
Вимкнення для розробки
Для середовищ розробки та тестування:
steel_shield:
enabled: false
Або вимкніть окремі функції:
steel_shield:
enabled: true
binary_integrity: false # Пропустити перевірку хешів під час розробки
runtime_protection: false # Дозволити підключення відладчика
Журнал аудиту
Усі події Steel Shield записуються до журналу аудиту безпеки:
# Перегляд останніх подій безпеки
netrecon-shield audit --last 24h
# Експорт журналу аудиту
netrecon-shield audit --export csv --output security-audit.csv
Записи журналу аудиту включають:
- Мітку часу
- Тип події (integrity_check, pin_validation, tamper_detected тощо)
- Задіяний компонент
- Результат (pass/fail)
- Вжиту дію
- Додаткові деталі
Особливості для власного хостингу
При власному хостингу зверніть увагу на:
- Власні сертифікати: якщо використовуєте власний центр сертифікації, оновіть конфігурацію закріплення сертифікатів після розгортання
- Оновлення бінарних файлів: після оновлення бінарних файлів запустіть
netrecon-shield initдля перебудови бази даних цілісності - Резервне копіювання бази даних цілісності: включіть
/etc/netrecon/integrity.dbдо вашої процедури резервного копіювання - Моніторинг сповіщень: налаштуйте сповіщення електронною поштою або вебхуком для оповіщень про втручання
Часті запитання
Q: Чи може Steel Shield давати хибнопозитивні спрацювання?
A: Хибнопозитивні спрацювання рідкісні, але можуть виникати після системних оновлень, що змінюють спільні бібліотеки. Запустіть netrecon-shield init після системних оновлень для оновлення бази даних цілісності.
Q: Чи впливає Steel Shield на продуктивність? A: Вплив на продуктивність мінімальний. Перевірки цілісності виконуються у фоновому потоці та зазвичай завершуються менш ніж за 1 секунду.
Q: Чи можна інтегрувати сповіщення Steel Shield з моєю SIEM? A: Так. Налаштуйте вивід syslog у конфігурації безпеки для пересилання подій до вашої SIEM. Steel Shield підтримує формати syslog (RFC 5424) та JSON.
Q: Чи обов'язковий Steel Shield для продакшн-розгортань? A: Steel Shield наполегливо рекомендується, але не є обов'язковим. Ви можете його вимкнути, але це прибере важливі захисні функції безпеки.
Для додаткової допомоги зверніться до [email protected].