Steel Shield

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

Огляд

Steel Shield включає чотири основні механізми безпеки:

Функція	Призначення
Цілісність бінарних файлів	Перевірка того, що виконувані файли не були змінені
Закріплення сертифікатів	Запобігання атакам "людина посередині" на API-комунікації
Реагування на втручання	Виявлення та реагування на несанкціоновані модифікації
Захист під час виконання	Захист від маніпуляцій з пам'яттю та відладки

Перевірка цілісності бінарних файлів

Кожен бінарний файл NetRecon (бекенд зонда, агенти, сервіси) має цифровий підпис. При запуску кожен компонент перевіряє власну цілісність.

Як це працює

1. Під час збірки кожен бінарний файл підписується приватним ключем NetRecon
2. Підпис вбудовується в метадані бінарного файлу
3. При запуску бінарний файл обчислює SHA-256 хеш самого себе
4. Хеш перевіряється за вбудованим підписом
5. Якщо перевірка не пройшла, бінарний файл відмовляється запускатися та реєструє сповіщення

Ручна перевірка

Перевірте цілісність бінарного файлу вручну:

# Перевірка бекенда зонда
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 до зонда	Відбиток сертифіката
Зонд до сервера оновлень	Закріплення відкритого ключа
Зонд до сервера ліцензій	Відбиток сертифіката

Як це працює

1. Очікуваний хеш відкритого ключа сертифіката вбудовується в кожен клієнтський бінарний файл
2. При встановленні TLS-з'єднання клієнт витягує відкритий ключ сервера
3. Клієнт обчислює SHA-256 хеш відкритого ключа
4. Якщо хеш не збігається з закріпленим значенням, з'єднання відхиляється
5. Невдала перевірка закріплення ініціює сповіщення безпеки

Ротація закріплень

При ротації сертифікатів:

1. Нові закріплення розповсюджуються через сервер оновлень до зміни сертифіката
2. Під час перехідного періоду дійсні як старі, так і нові закріплення
3. Після переходу старі закріплення видаляються в наступному оновленні

Для розгортань на власному сервері оновіть закріплення в конфігурації:

# /etc/netrecon/security.yaml
certificate_pins:
  api_gateway:
    - "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="  # Поточний
    - "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="  # Резервний

Реагування на втручання

Steel Shield моніторить критичні файли та конфігурації на предмет несанкціонованих змін.

Об'єкти моніторингу

Об'єкт	Частота перевірки	Реагування
Бінарні файли	При запуску + кожну 1 годину	Сповіщення + опціональне вимкнення
Файли конфігурації	Кожні 5 хвилин	Сповіщення + відкат до резервної копії
Цілісність бази даних	Кожні 15 хвилин	Сповіщення + перевірка консистентності
TLS-сертифікати	Кожні 5 хвилин	Сповіщення при зміні
Системні пакети	Щоденно	Сповіщення при неочікуваних змінах

Дії реагування

При виявленні втручання Steel Shield може:

1. Журналювати — зафіксувати подію в журналі аудиту безпеки
2. Сповістити — надіслати сповіщення через налаштовані канали
3. Відкотити — відновити змінений файл з відомої робочої резервної копії
4. Ізолювати — обмежити мережевий доступ лише до управління
5. Вимкнути — зупинити сервіс для запобігання подальшій компрометації

Налаштуйте рівень реагування:

# /etc/netrecon/security.yaml
tamper_response:
  level: "alert_and_revert"  # Варіанти: log, alert, alert_and_revert, isolate, shutdown
  notify_email: "security@yourcompany.com"

База даних цілісності файлів

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)
• Вжиту дію
• Додаткові деталі

Особливості для власного хостингу

При власному хостингу зверніть увагу на:

1. Власні сертифікати: якщо використовуєте власний центр сертифікації, оновіть конфігурацію закріплення сертифікатів після розгортання
2. Оновлення бінарних файлів: після оновлення бінарних файлів запустіть netrecon-shield init для перебудови бази даних цілісності
3. Резервне копіювання бази даних цілісності: включіть /etc/netrecon/integrity.db до вашої процедури резервного копіювання
4. Моніторинг сповіщень: налаштуйте сповіщення електронною поштою або вебхуком для оповіщень про втручання

Часті запитання

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 наполегливо рекомендується, але не є обов'язковим. Ви можете його вимкнути, але це прибере важливі захисні функції безпеки.

Для додаткової допомоги зверніться до support@netreconapp.com.