Перейти к основному содержанию
`Ctrl`+`K`

# Рекомендации по информационной безопасности

## Общие рекомендации

### Требования к паролям

Для обеспечения безопасности учётных записей в Global ERP все сотрудники обязаны соблюдать следующие правила:

- Длина и сложность:
  → Пароль должен содержать не менее 12 символов, включая заглавные и строчные буквы, цифры и специальные знаки (например, `!`, `@`, `#`).

- Запрещённые действия:
  → Не допускается использование стандартных или простых паролей;
  → Запрещается записывать пароли на бумажных носителях, хранить в незащищённых файлах или передавать третьим лицам.

- Рекомендация:
  → Для создания и безопасного хранения паролей компания рекомендует использовать корпоративный менеджер паролей (например, Bitwarden, 1Password, Keeper).

### Использование двухфакторной аутентификации (2FA)

Для доступа к критически важным функциям системы требуется дополнительный способ подтверждения личности:

- Область применения:
  → 2FA обязательна для всех администраторов системы и пользователей с расширенными правами доступа.

- Способы подтверждения:
  → В качестве предпочтительного метода используются мобильные приложения-аутентификаторы (например, Microsoft Authenticator, Google Authenticator) или аппаратные ключи безопасности (YubiKey, Google Titan).

- Ограничение:
  → Использование SMS для подтверждения не рекомендуется в целях безопасности.

### Принцип предоставления минимальных прав доступа

Компания следует правилу, согласно которому пользователи получают ровно тот уровень доступа, который необходим для выполнения их рабочих задач:

- Разделение обязанностей:
  → Администраторы, управляющие функционалом Global ERP, не могут одновременно быть администраторами операционной системы или баз данных PostgreSQL.

- Регулярная проверка:
  → Не реже одного раза в квартал проводится аудит прав доступа.

### Действия при возникновении инцидента информационной безопасности

При подозрении на взлом, утечку данных или компрометацию:

1. Изолировать систему: отключить сервер от корпоративной сети.

2. Сохранить доказательства: обеспечить сохранность всех логов (ОС, БД, приложение); не вносить изменения.

3. Уведомить службу безопасности: проинформировать службу информационной безопасности.

4. Ожидать инструкций: не восстанавливать систему до разрешения специалистов.

### Политика резервного копирования данных

- Регулярность: ежедневное автоматическое резервное копирование.

- Безопасное хранение: копии хранятся на отдельном, изолированном сервере.

- Шифрование: все резервные копии шифруются алгоритмом AES-256.

- Проверка работоспособности: не реже раза в квартал проводится тестовое восстановление.

### Запрет на использование неавторизованных сервисов

Категорически запрещено:

- Размещать данные из Global ERP в публичных облаках (Google Drive, Dropbox, Яндекс.Диск и т.п.);

- Передавать логины, пароли, логи или конфигурации через личную почту, мессенджеры (Telegram, WhatsApp, Viber) или соцсети;

- Копировать данные на личные USB-накопители.

> Все данные должны обрабатываться только в рамках корпоративной инфраструктуры.

### Обучение в области информационной безопасности

- Регулярность: ежегодное обязательное обучение для всех пользователей Global ERP.

- Ключевые темы: противодействие фишингу, социальной инженерии, безопасная работа с данными.

### Средства защиты информации на автоматизированных рабочих местах

Каждое рабочее место с доступом к Global ERP должно быть защищено:

- Антивирусная защита:
  → Установлена и активирована программа, одобренная ИТ-отделом;
  → Запрещено отключать защиту или менять настройки без согласования;
  → Базы обновляются автоматически.

- Межсетевой экран (Firewall):
  → Активирован на всех станциях и серверах;
  → Правила ограничивают трафик только необходимыми сервисами.

- Обновление ПО (Patch Management):
  → ОС и приложения (браузеры, Java, Adobe Reader, Office) обновляются в течение 72 часов для критических патчей;
  → Запрещено отключать автообновления.

## Рекомендации по безопасности Global ERP

### Security Baseline — базовый уровень безопасности

#### Сценарий A: Готовый baseline (рекомендуется)

- Файл: `security_baseline.conf` (`/etc/erp/`)

- Скрипт: `apply-security-baseline.sh`

- В UI: «Безопасность → Применить базовый профиль»

> После применения проверяется:

> - Учётные записи `admin`, `demo` — отключены;

> - MFA для админов — включена через Microsoft Authenticator, Google Authenticator или YubiKey;

> - TLS 1.2+ — активен, TLS 1.0/1.1 — отключены;

> - Процесс запущен от отдельного пользователя ОС (не `root`).

#### Сценарий B: Ручная настройка

- Отключить все учётные записи по умолчанию;

- Настроить MFA через Microsoft Authenticator, Google Authenticator или YubiKey;

- Включить TLS 1.2 или выше, отключить TLS 1.0/1.1;

- Запускать процесс от отдельного пользователя ОС.

### Управление ролями и полномочиями

- Использовать предопределённые роли (не назначать права вручную);

- Проводить анализ SoD (например: «создать поставщика» + «оплатить счёт» — запрещено одному пользователю);

- Запретить использование ролей типа `SAP_ALL` или `ERP_SUPER_ADMIN` в повседневной работе;

- Все изменения в ролях — утверждать и логировать.

### Мониторинг критических операций

Отслеживать через Splunk, IBM QRadar, Elastic SIEM или Microsoft Sentinel:

- Изменение мастер-данных (контрагенты, банки, цены);

- Массовый экспорт данных (>1000 записей);

- Действия в нерабочее время (22:00–6:00);

- Попытки обхода контрольных процедур.

> Логи хранить не менее 180 дней.

### Требования к инфраструктуре

- Поддерживаемые ОС:
  → Linux: RHEL 8+, Ubuntu 20.04 LTS+;
  → Windows: Windows Server 2016+.

- Версия PostgreSQL: 12, 13, 14 или 15.

- Сервер Global ERP и БД — в изолированной VLAN, без доступа из интернета;

- Доступ к веб-интерфейсу — только через reverse proxy (nginx, Apache) с TLS 1.2+;

- Физический доступ к серверам — ограничен (только авторизованный персонал).

### Настройка PostgreSQL

- Запрещено использовать учётную запись `postgres` для работы приложения.

- Создать отдельного пользователя БД (например, `erp_app`).

- В файле `pg_hba.conf` разрешить подключения только с IP-адреса сервера приложения, используя метод аутентификации `scram-sha-256`.

- В файле `postgresql.conf` установить параметры:
  → `ssl = on` — для шифрования трафика;
  → `log_statement = 'mod'` — для логирования всех операций изменения данных (DDL и DML).

### Управление обновлениями

- Сроки установки:
  → Все security-патчи должны быть установлены в течение 30 календарных дней.

- Тестирование:
  → Перед установкой — обязательное тестирование в staging-среде.

- Источники:
  → Только официальный портал поддержки или подписанные репозитории (APT/YUM с проверкой GPG-подписи).

### Безопасность при кастомизации

- Анализ зависимостей:
  → Использовать Snyk или OWASP Dependency-Check для сканирования библиотек.

- Запрещённые компоненты:
  → Log4j 1.x, jQuery < 3.5, Spring Framework < 5.3.0.

- Анализ кода:
  → Прогонять код через SonarQube или Semgrep (SAST).

- Запрещено в продакшене:
  → `eval()`,
  → динамический SQL без параметризации,
  → отладочные консоли.

### Устранение технического долга

- Запрещено оставлять:
  → Временные учётные записи;
  → Правила firewall «разрешить всё»;
  → Устаревшие ОС/PostgreSQL без плана обновления.

- Исключения:
  → Должны иметь обоснование, утверждение ИБ-службы и срок действия (≤30 дней).

### Интеграция с корпоративными системами мониторинга и SIEM

- Метрики:
  → Эндпоинт `/metrics` (Prometheus) → визуализация в Grafana.

- Логи:
  → Экспорт через Syslog (TCP) или вебхуки (JSON over HTTPS) → Splunk / QRadar / Elastic SIEM.

- Доступность:
  → Проверки в Zabbix на `/health`, валидность TLS, задержку транзакций.

## Security by Design: как безопасность встроена в Global ERP

### Архитектура

- Zero Trust: нет доверия к внутренней сети.

- Threat Modeling: по методологии STRIDE для каждого компонента.

- Изоляция данных: при мульти-тенантности — логическая или физическая.

### Аутентификация

- Стандарты: SAML 2.0, OpenID Connect, OAuth 2.0.

- MFA: TOTP (Google Authenticator, Microsoft Authenticator), FIDO2 (YubiKey).

- Блокировка: после 5 неудачных попыток.

- История паролей: 24 последних пароля не могут быть повторно использованы.

### Авторизация

- RBAC/ABAC: встроенные механизмы.

- SoD: предотвращение конфликтов («создать + оплатить»).

- Минимальные привилегии: по умолчанию — только чтение.

### Защита данных

- In transit: TLS 1.2+ (SSL 3.0, TLS 1.0/1.1 — отключены).

- At rest:
  → ОС: BitLocker (Windows), LUKS (Linux);
  → Приложение: AES-256-GCM для ПДн (ИНН, СНИЛС).

- Маскировка: ПДн автоматически скрываются в логах и UI.

### Защита от атак

- SQLi: только параметризованные запросы.

- XSS: автоматическое экранирование + CSP.

- CSRF: anti-CSRF токены.

- IDOR: проверка прав на каждый запрос к объекту.

### Сессии

- Тайм-аут: 15 минут бездействия.

- Управление: централизованное разлогирование.

- Cookies: флаги `HttpOnly`, `Secure`, `SameSite=Strict`.

### Аудит

- Логируются: вход/выход, экспорт данных, изменение ролей.

- Форматы: Syslog, CEF, JSON для SIEM.

- Хранение: 180+ дней, защита от модификации.

### Инфраструктура, секреты, DevSecOps, обновления, документация

(Содержание остаётся технически точным и детальным, как в предыдущей версии — все инструменты и стандарты уже указаны.)

## Соответствие требованиям (Compliance)

- GDPR: шифрование ПД (AES-256-GCM), право на удаление, аудит.

- ФЗ-152: защита ПД, SoD, логирование.

- PCI DSS: MFA (Authenticator/YubiKey), пароли (12+ символов), логи.

- ISO 27001:2022:

  - A.8.9 — управление доступом (раздел 2.2),

  - A.8.16 — мониторинг (раздел 2.3),

  - A.8.23 — обработка данных (раздел 3.4).