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

Содержание

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

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

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

Для обеспечения безопасности учётных записей в 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).

Содержание