Входит в Tactise Group
Получить консультацию
Общество с ограниченной ответственностью «Тэктис»
(ООО «Тэктис»)
РУКОВОДСТВО ПО ЭКСПЛУАТАЦИИ
«ИНДОРА» — цифровая платформа производственной безопасности
Аннотация

Настоящий документ является руководством по эксплуатации программного обеспечения «ИНДОРА» — цифровой платформы производственной безопасности, разработанной ООО «Тэктис» (Tactise Group). Документ предназначен для системных администраторов и специалистов по информационным технологиям, осуществляющих установку, конфигурирование, техническое обслуживание и поддержку Системы на предприятиях Российской Федерации.
Документ разработан в соответствии с требованиями руководящего документа РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов» и стандарта ГОСТ 19.503-79 ЕСПД «Руководство системного программиста. Требования к содержанию и оформлению», а также с учётом действующей нормативной базы Российской Федерации в области информационной безопасности (152-ФЗ, 187-ФЗ, приказы ФСТЭК России).


1. Введение

1.1. Область применения

Настоящий документ распространяется на программное обеспечение «ИНДОРА» — интегрированную систему обеспечения безопасности работ (ИСОБР 2.0), правообладателем которой является ООО «Тэктис». Аббревиатура ИНДОРА расшифровывается как: Изоляции, Наряды-Допуски, Оценка Рисков, Аудиты.
Документ описывает действия, необходимые для развёртывания и конфигурирования Системы в инфраструктуре заказчика; управления учётными записями, ролями и правами доступа; настройки функциональных модулей и интеграций; обеспечения резервного копирования, мониторинга и информационной безопасности; технического обслуживания и устранения нештатных ситуаций.

1.2. Уровень подготовки администратора
Администратор Системы ИНДОРА должен обладать следующими знаниями и навыками:
  • администрирование серверных ОС семейства Linux (Astra Linux SE, РЕД ОС, Альт Сервер, Ubuntu LTS) и/или Microsoft Windows Server 2019+;
  • администрирование СУБД PostgreSQL 13+ (включая Postgres Pro) или Microsoft SQL Server 2019+;
  • базовая работа с веб-серверами Nginx и Apache HTTP Server;
  • сетевое администрирование (TCP/IP, DNS, маршрутизация, межсетевые экраны, TLS/SSL);
  • контейнеризация (Docker, Docker Compose), оркестрация (Kubernetes 1.27+) — для кластерных инсталляций;
  • принципы информационной безопасности, управление доступом, ведение журналов аудита;
  • работа с системами мониторинга (Zabbix, Prometheus, Grafana) — желательно.

1.3. Связь с другими документами комплекта

 Документ

 Назначение

 Описание функциональных характеристик ПО

 Описание модулей и возможностей Системы для Минцифры России

 Руководство пользователя

 Работа конечных пользователей с функциональными модулями

 Руководство по установке

 Подробные инструкции по инсталляции для конкретных конфигураций

 Описание интеграционного API

 Техническое описание REST API для разработчиков интеграций

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

 Модель угроз, требования к защите информации

 Лицензионный договор

 Условия использования ПО


1.4. Краткое описание возможностей Системы

«ИНДОРА» — цифровая платформа производственной безопасности, охватывающая полный цикл управления промышленной безопасностью: оформление и согласование нарядов-допусков, изоляция источников опасной энергии (LOTO), управление рисками, проведение аудитов, регистрация и расследование инцидентов, ведение производственных журналов, передача смены, управление компетенциями персонала и подрядными организациями. На момент подготовки документа ПО используют более 15 000 активных пользователей; платформа применяется на объектах масштабом до 80 000 сотрудников.
Платформа реализована полностью на отечественном или программном стеке (TypeScript, C++/Perl, PostgreSQL, Nginx) и поддерживает работу в среде российских операционных систем (Astra Linux SE, РЕД ОС, Альт Сервер). Подтверждена эксплуатация на предприятиях ОАО «Ямал СПГ», ООО «ИНК», СПГ-завода Ленинградской области, объектах розничной торговли (под NDA, 800 торговых точек). ООО «Тэктис» является резидентом инновационного центра «Сколково» с 2024 года.


2. Назначение и область применения Системы

2.1. Назначение ПО ИНДОРА

ПО «ИНДОРА» предназначено для комплексной цифровизации процессов охраны труда, промышленной безопасности, контроля опасных работ и управления операционными рисками на промышленных предприятиях. Система обеспечивает соблюдение требований российской нормативно-правовой базы (116-ФЗ, 248-ФЗ, 426-ФЗ, 63-ФЗ, Трудовой кодекс РФ) и общепризнанных международных стандартов в области HSE (ISO 45001:2020, ISO 31000:2018, ISO 19011:2018, ISSOW, OIAC, OSHA, OLF).

2.2. Целевые отрасли применения

Целевыми отраслями применения ПО являются:
  • Производство СПГ и нефтегаз
  • Металлургическая промышленность
  • Горнодобывающая промышленность
  • Химическая промышленность
  • Энергетика и атомная отрасль
  • Розничная торговля
2.3. Задачи, решаемые администратором Системы

  • развёртывание Системы (single-server, двухзвенная, HA-кластер, контейнерное развёртывание);
  • конфигурирование функциональных модулей и интеграционных коннекторов;
  • управление учётными записями, ролями, правами доступа, делегированием полномочий;
  • настройка интеграции с корпоративными системами (Active Directory, 1С, SAP, OSIsoft PI System, СКУД, BI);
  • обеспечение резервного копирования и восстановления данных;
  • мониторинг работоспособности компонентов и реагирование на инциденты;
  • обеспечение информационной безопасности в соответствии с требованиями ФСТЭК России и 152-ФЗ;
  • применение обновлений ПО, миграций баз данных, расширение и масштабирование инфраструктуры.


3. Условия применения

3.1. Минимальная конфигурация (до 500 одновременных пользователей)

 Компонент

 Минимум

 Рекомендация

 CPU сервера приложений

 4 ядра, 2.5 ГГц

 8 ядер, 3.0+ ГГц

 RAM сервера приложений

 8 ГБ

 16 ГБ

 Диск ОС и приложения

 40 ГБ SSD

 80 ГБ SSD

 CPU сервера БД

 4 ядра, 2.5 ГГц

 8 ядер, 3.0+ ГГц

 RAM сервера БД

 16 ГБ

 32 ГБ

 Диск под БД

 200 ГБ SSD

 500 ГБ NVMe SSD

 Файловое хранилище

 100 ГБ

 500 ГБ+ (зависит от объёма вложений)

 Сеть

 100 Мбит/с

 1 Гбит/с


3.2. Производственная конфигурация (15 000+ пользователей, HA)

Для обслуживания 15 000+ пользователей рекомендуется кластерная архитектура высокой доступности. Конкретные параметры уточняются на этапе предпроектного обследования у специалистов ООО «Тэктис».

 Роль

 Число узлов

 CPU

 RAM

 Диск

 Сервер приложений (app tier)

 3+

 16 ядер

 32 ГБ

 100 ГБ SSD

 PostgreSQL primary

 1

 16 ядер

 64 ГБ

 1 ТБ NVMe

 PostgreSQL replica

 2

 16 ядер

 64 ГБ

 1 ТБ NVMe

 Балансировщик / прокси

 2

 4 ядра

 8 ГБ

 40 ГБ

 Файловое хранилище

 1+

 4 ядра

 8 ГБ

 2–10 ТБ

 Кэш (Redis Sentinel)

 2

 4 ядра

 16 ГБ

 40 ГБ

 Узлы очереди задач

 2

 4 ядра

 8 ГБ

 40 ГБ


3.3. Требования к АРМ администратора и пользователя

 Характеристика

 Требование

 ОС АРМ администратора

 Windows 10/11, Astra Linux, РЕД ОС, Альт Рабочая станция

 CPU / RAM АРМ

 2+ ядра, 2.0+ ГГц; 4 ГБ ОЗУ (рекомендовано 8 ГБ)

 Диск АРМ

 20 ГБ свободного пространства

 Браузеры

 Google Chrome, Яндекс Браузер, Mozilla Firefox, Microsoft Edge, Apple Safari (актуальные версии за последние 2 года)

 Разрешение экрана

 1280×768 и выше

 Мобильные клиенты

 Android, iOS — мобильное приложение ИНДОРА; поддерживается офлайн-режим аудитов

 ПО для УКЭП/УНЭП

 КриптоПро CSP 5.0+, Рутокен Плагин, ViPNet CSP, Signal-COM CSP — на стороне пользователя


3.4. Поддерживаемое системное ПО

 Категория

 Поддерживаемые продукты

 Операционные системы

 Astra Linux Special Edition 1.7+ (ФСТЭК); РЕД ОС 7.3+; Альт Сервер 10+; Ubuntu Server LTS 22.04 / 24.04; RHEL / CentOS Stream 8, 9; Windows Server 2019, 2022

 СУБД

 PostgreSQL 13–16 (рекомендуется); Postgres Pro Standard / Enterprise 15+; Microsoft SQL Server 2019, 2022

 Веб-серверы и прокси

 Nginx 1.18+; Apache HTTP Server 2.4+

 Оркестрация контейнеров

 Docker 20+, Docker Compose; Kubernetes 1.27+

 Кэш / очередь

 Redis 6+; альтернативы — Memcached


3.5. Сетевые требования и используемые порты

 Порт

 Протокол

 Направление

 Назначение

 443

 TCP / HTTPS

 Внешний → сервер

 Доступ пользователей (TLS 1.2 / 1.3)

 80

 TCP / HTTP

 Внешний → сервер

 Редирект на HTTPS (опционально)

 5432

 TCP

 App → СУБД

 PostgreSQL

 1433

 TCP

 App → СУБД

 Microsoft SQL Server

 6379

 TCP

 App → кэш

 Redis (при использовании)

 22

 TCP / SSH

 АРМ → сервер

 Административный доступ (white-list IP)

 9090 / 10050

 TCP

 Мониторинг

 Prometheus / Zabbix Agent


TLS и DNS
Обязательно использование сертификатов TLS 1.2 или TLS 1.3. Для государственных и критически важных объектов рекомендуется применение сертификатов российских удостоверяющих центров с поддержкой алгоритмов ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. В корпоративной DNS-зоне рекомендуется выделить поддомен формата indora.company.ru, разрешаемый в IP-адрес балансировщика.


4. Описание архитектуры Системы

4.1. Общая архитектура

Система реализована по архитектурному принципу «клиент-сервер». Клиентская часть — одностраничное TypeScript-приложение (SPA), исполняющееся в браузере; серверная часть — набор взаимодействующих сервисов на C++ и Perl, предоставляющих REST API и обрабатывающих бизнес-логику всех модулей. Хранение данных обеспечивается СУБД (PostgreSQL или MS SQL Server); статические файлы и пользовательские вложения размещаются на отдельном файловом хранилище.

4.2. Технологический стек и роли компонентов

 Компонент

 Назначение

 Nginx / Apache

 Терминация TLS, маршрутизация, раздача статики фронтенда, балансировка нагрузки между app-нодами

 TypeScript SPA (фронтенд)

 Пользовательский интерфейс в браузере; взаимодействие с бэкендом через REST API

 C++ / Perl сервисы (бэкенд)

 Бизнес-логика модулей: наряды-допуски, риски, аудит, LOTO, CMS, инциденты и др.; REST API

 PostgreSQL / MS SQL Server

 Хранение структурированных данных: пользователи, роли, наряды, аудиты, риски, журналы

 Файловое хранилище

 Вложения, фотографии аудитов, печатные формы, сгенерированные отчёты

 Redis / кэш

 Кэш сессий, часто запрашиваемых справочников, ускорение работы

 Очередь задач

 Асинхронная обработка: уведомления, фоновая генерация отчётов, фоновые операции

 Балансировщик

 Распределение запросов между app-нодами, health-checks, sticky-сессии


4.3. Схемы развёртывания

4.3.1. Одиночный сервер
Все компоненты — обратный прокси, app-сервисы, СУБД и файловое хранилище — размещаются на одном физическом или виртуальном сервере. Применяется для пилотных проектов до 200 пользователей.

4.3.2. Двухзвенная архитектура
Сервер приложений (Nginx + app-сервисы + файловое хранилище) и сервер СУБД разнесены на разные физические узлы. Поддерживает до 2 000 пользователей.

4.3.3. HA-кластер (рекомендуется для 15 000+ пользователей)
  • перед app-нодами установлен балансировщик нагрузки (Nginx / HAProxy);
  • 3+ app-ноды работают параллельно, обращаются к общему PostgreSQL primary и репликам для чтения;
  • PostgreSQL развёрнут в режиме потоковой репликации (streaming replication): 1 primary + 2 replica;
  • файловое хранилище — выделенный NFS-сервер или S3-совместимое объектное хранилище;
  • Redis Sentinel обеспечивает отказоустойчивость кэша.

4.3.4. Контейнерное развёртывание (Kubernetes 1.27+)
Компоненты упакованы в Docker-образы, оркестрация выполняется средствами Kubernetes. Горизонтальное масштабирование app-tier обеспечивается через Horizontal Pod Autoscaler (HPA). Хранение состояния (БД, файлы) выносится за пределы кластера через Persistent Volumes или внешние сервисы.


6. Управление учётными записями и ролями

6.1. Встроенные роли (RBAC)

 Роль

 Ключевые права

 Администратор системы

 Управление пользователями, ролями, конфигурацией, интеграциями, журналами безопасности

 Аудитор

 Создание и проведение аудитов, ведение чек-листов, назначение CAPA-мероприятий, контроль исполнения

 Мастер / производитель работ

 Выдача и согласование нарядов-допусков, проведение инструктажа на рабочем месте

 Исполнитель / подрядчик

 Просмотр и принятие выданных нарядов-допусков, подтверждение выполнения, фотофиксация

 Специалист HSE

 Управление реестром рисков и опасностей, формирование Bow-Tie диаграмм, регистрация инцидентов

 Диспетчер

 Мониторинг активных работ на интерактивной карте, контроль SIMOPS, передача смены

 Руководитель работ

 Создание и контроль нарядов, управление персоналом, принятие решений по конфликтам

 Читатель (viewer)

 Только просмотр без права редактирования


6.2. Создание пользователя через CLI

 sudo -u indora /opt/indora/bin/indora-cli user create \

    --login ivanov.ii \

    --email i.ivanov@company.ru \

    --name "Иванов Иван Иванович" \

    --role executor \

    --department "Цех № 5"


6.3. Интеграция с Active Directory (LDAP)

Система поддерживает автоматическую аутентификацию через Active Directory с маппингом групп AD на роли ИНДОРА. Рекомендуемая схема: создание сервисной учётной записи AD `indora-svc` с правами только на чтение, групп безопасности `indora-<роль>` и включение пользователей в соответствующие группы. Пример конфигурации:

 [auth]

 type = ldap

 

 [ldap]

 server = ldaps://dc.company.ru

 port = 636

 base_dn = DC=company,DC=ru

 bind_dn = CN=indora-svc,OU=ServiceAccounts,DC=company,DC=ru

 bind_password = ПАРОЛЬ_СЕРВИСНОЙ_УЧЁТНОЙ_ЗАПИСИ

 user_filter = (&(objectClass=user)(sAMAccountName=%s))

 

 # Маппинг групп AD → роли ИНДОРА

 group_map.CN=indora-admins,OU=Groups,DC=company,DC=ru = admin

 group_map.CN=indora-masters,OU=Groups,DC=company,DC=ru = master


6.4. SSO: SAML 2.0 и OIDC

Для предприятий с корпоративным IdP (Keycloak, Microsoft AD FS, Solar IdM, ПАК «Рутокен Облако») реализована поддержка SAML 2.0 и OpenID Connect. Пример конфигурации SAML:

 [auth]

 type = saml

 

 [saml]

 idp_metadata_url = https://adfs.company.ru/FederationMetadata/2007-06/FederationMetadata.xml

 sp_entity_id = https://indora.company.ru

 sp_acs_url   = https://indora.company.ru/auth/saml/callback

 sp_slo_url   = https://indora.company.ru/auth/saml/logout


6.5. Подключение УКЭП и УНЭП

Для подписания юридически значимых документов (закрытие наряда-допуска, передача смены) Система поддерживает усиленную квалифицированную (УКЭП) и усиленную неквалифицированную (УНЭП) электронные подписи. На стороне пользователя — установка криптопровайдера (КриптоПро CSP 5.0+, Рутокен Плагин и др.) и браузерного расширения. На стороне сервера задаются разрешённые криптопровайдеры и обязательность УКЭП для критичных операций:

 [signature]

 allowed_providers = cryptopro,rutoken

 require_qualified_signature_for_permit_close = true

 require_qualified_signature_for_shift_handover = true


6.6. Делегирование, временные роли, совмещение
  • делегирование полномочий — передача прав конкретного пользователя другому на период отпуска или командировки;
  • временные роли — назначение роли на ограниченный период с автоматическим отзывом по истечении срока;
  • совмещение ролей — пользователю может быть назначено несколько ролей одновременно (например, Мастер + специалист HSE).
7. Конфигурирование функциональных модулей


Большинство параметров модулей настраиваются администратором через раздел «Настройки» административного веб-интерфейса. Часть параметров, влияющих на безопасность и производительность, задаётся в конфигурационном файле /etc/indora/indora.conf или через переменные окружения.

7.1. Модуль «Наряды-допуски»

  • настройка типов работ (газоопасные, огневые, высотные, в замкнутых пространствах, под напряжением) с привязкой класса опасности и требований к компетенциям;
  • настройка маршрутов согласования (последовательные/параллельные шаги, тайм-ауты автоэскалации, роли согласующих);
  • шаблоны рутинных операций с автоматическим предложением шаблонов по типу работы;
  • контроль конфликтующих работ (SIMOPS) с заданием радиуса проверки и запрещённых сочетаний типов работ.

7.2. Модуль «Управление рисками»

  • настройка матрицы рисков (вероятность 5 × тяжесть 5) с цветовым кодированием зон и пороговыми значениями;
  • подключение библиотеки из более чем 20 000 мер контроля рисков; добавление отраслевых и корпоративных мер;
  • заполнение реестра опасностей; настройка иерархии «опасность → риск → меры контроля» (ИМК).

7.3. Модуль «Аудит» и CAPA

  • создание чек-листов аудитов с группами критериев, шкалами и взвешиванием;
  • настройка частоты и графика аудитов, маршрутов согласования протоколов;
  • конфигурирование процесса CAPA: ответственные, сроки, автоматические уведомления о просрочках.

7.4. Модуль LOTO

  • настройка типов опасных энергий и ресурсов изоляции (замки, бирки, индивидуальные коды);
  • сертификация LOTO-операторов; ведение реестра сертификатов с автоматическим контролем срока действия.

7.5. Модуль CMS (управление компетенциями)

  • классы компетенций, сроки действия удостоверений и медицинских осмотров;
  • автоматический отзыв роли сотрудника при утрате хотя бы одной критической компетенции;
  • контроль допусков подрядного персонала (включая алкотестирование и предсменный осмотр).

7.6. Другие модули

 Модуль

 Ключевые настройки администратора

 Инциденты (HIT)

 Классификаторы происшествий, состав комиссии расследования, методики анализа первопричин (5 Why, диаграмма Исикавы, Bow-Tie)

 Передача смены

 Перечень источников автоматической агрегации (модули НД, аудит, инциденты, АСУ ТП), правила подписания УКЭП/УНЭП

 Журналы предприятия

 Перечень журналов, реквизиты подписания, политика хранения

 Подрядчики

 Реестр подрядных организаций, контроль допусков и компетенций подрядного персонала

 MOC (Management of Change)

 Маршруты согласования изменений в процессах, оборудовании, регламентах

 Карты работ

 Интеграция с картографическими сервисами, отображение активных работ и конфликтов



8. Интеграции и REST API

8.1. REST API

Система предоставляет REST API для интеграции с внешними системами. Базовый URL: https://indora.company.ru/api/v1. Поддерживаемые методы аутентификации — JWT-токен (для пользовательских сессий) и API-ключи (для машинных интеграций и сервис-аккаунтов).

 Метод

 Эндпоинт

 Описание

 POST

 /api/v1/auth/login

 Получить JWT-токен

 GET

 /api/v1/permits

 Список нарядов-допусков

 POST

 /api/v1/permits

 Создать новый наряд-допуск

 PUT

 /api/v1/permits/{id}/approve

 Согласовать наряд

 GET

 /api/v1/users

 Список пользователей

 GET

 /api/v1/risks

 Реестр рисков

 GET

 /api/v1/audits

 Список аудитов

 GET

 /api/v1/incidents

 Список инцидентов

 GET

 /api/v1/health

 Статус работоспособности Системы


8.2. Rate limiting на уровне Nginx

 # В http-блоке /etc/nginx/nginx.conf:

 limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

 limit_req_zone $http_authorization zone=api_key:10m rate=100r/s;

 

 # В location /api/:

 limit_req zone=api burst=50 nodelay;


8.3. Вебхуки и событийная шина

Система отправляет HTTP-уведомления (вебхуки) на внешние URL при наступлении событий. Подпись HMAC-SHA256 обеспечивает верификацию на стороне получателя. Примеры событий-триггеров: permit.created, permit.approved, permit.closed, incident.registered, audit.capa_overdue, user.competence_expired, loto.isolation_applied.

8.4. Интеграция с 1С, SAP, OSIsoft PI System, СКУД

Готовые коннекторы для синхронизации справочной информации с 1С и SAP внедряются за 2–4 недели. Интеграция с OSIsoft PI System используется для модулей «Передача смены» и «Управление рисками» (получение данных датчиков оборудования). Кейс ОАО «Ямал СПГ» подтверждает работоспособность интеграции с PI System в промышленном масштабе.

 [integration.1c]

 enabled = true

 type = odata

 url = http://1c-server.company.ru/erpbase/odata/standard.odata/

 username = indora_integration

 sync_interval_minutes = 60

 sync_entities = users,departments,equipment

 

 [integration.pi_system]

 enabled = true

 pi_server_url = https://pi.company.ru/piwebapi

 tags_config = /etc/indora/pi_tags.yaml


8.5. Корпоративная почта (SMTP)

 [mail]

 enabled = true

 smtp_host = mail.company.ru

 smtp_port = 587

 smtp_user = indora@company.ru

 smtp_from = ИНДОРА <indora@company.ru>

 smtp_tls   = starttls



9. Резервное копирование и восстановление

9.1. Стратегия резервного копирования

 Параметр

 Значение

 RPO (Recovery Point Objective)

 ≤ 15 минут (при WAL-архивировании)

 RTO (Recovery Time Objective)

 ≤ 2 часа (полное восстановление)

 Полный бэкап

 Ежедневно, в 02:00

 Инкрементальный (WAL / Log)

 Каждые 15 минут

 Хранение локальных бэкапов

 7 суток

 Хранение архивных бэкапов

 30 суток (удалённое хранилище / НХД)

 Тестовое восстановление

 Еженедельно (автоматизированный прогон)


9.2. Резервное копирование PostgreSQL

Логический бэкап выполняется утилитой pg_dump (формат custom, сжатие, верификация). Физический бэкап и основа для PITR — pg_basebackup с потоковой передачей WAL. Для облачных и S3-совместимых хранилищ рекомендуется WAL-G.

 # Логический бэкап (cron 0 2 * * *)

 pg_dump -U indora_user -F c -b -v \

    -f /backup/indora/indora_$(date +%Y%m%d_%H%M%S).dump indora_db

 

 # Физический базовый бэкап

 pg_basebackup -U replicator -D /backup/basebackup_$(date +%Y%m%d) -Fp -Xs -P

 

 # postgresql.conf для WAL-архивирования

 wal_level = replica

 archive_mode = on

 archive_command = 'test ! -f /backup/wal/%f && cp %p /backup/wal/%f'

 max_wal_senders = 3


9.3. Резервное копирование MS SQL Server

 BACKUP DATABASE [indora_db]

 TO DISK = N'/backup/mssql/indora_full_$(дата).bak'

 WITH INIT, NAME = N'INDORA Full Backup', STATS = 10;

 

 BACKUP DATABASE [indora_db]

 TO DISK = N'/backup/mssql/indora_diff.bak' WITH DIFFERENTIAL, INIT;

 

 -- Каждые 15 минут через SQL Agent Job:

 BACKUP LOG [indora_db] TO DISK = N'/backup/mssql/indora_log.bak' WITH INIT;


9.4. Файловое хранилище и конфигурация

 # Файлы вложений

 rsync -avz --delete /var/indora/files/ backup-server:/backup/indora/files_$(date +%Y%m%d)/

 

 # Конфигурация

 tar -czf /backup/indora/config_$(date +%Y%m%d).tar.gz \

    /etc/indora/ /etc/nginx/sites-available/indora.conf /etc/ssl/certs/indora.crt


9.5. Восстановление: типовые сценарии

Сценарий 1 — потеря данных БД: остановить indora-app и indora-worker; удалить повреждённую БД; восстановить из дампа через pg_restore; запустить службы; проверить /api/health. Сценарий 2 — PITR (восстановление на конкретный момент): остановить PostgreSQL; восстановить базовую копию; настроить recovery_target_time в postgresql.auto.conf и создать recovery.signal; запустить PostgreSQL — WAL воспроизведётся автоматически.

9.6. Тестирование бэкапов

Еженедельный автоматизированный прогон тестового восстановления на изолированном сервере. После восстановления — проверка количества записей в ключевых таблицах (permits, users, audits, risks) и сверка с production. Результат фиксируется в журнале регламентного обслуживания.


10. Мониторинг и журналирование

10.1. Встроенные возможности

  • GET /api/health — health-check всех компонентов с детализацией;
  • GET /api/metrics — метрики в формате Prometheus (включается в конфигурации);
  • audit log — журнал действий пользователей в БД и/или /var/log/indora/audit.log;
  • журналы приложения: /var/log/indora/app.log, /var/log/indora/error.log.

10.2. Ключевые метрики и пороги

 Метрика

 Warning

 Critical

 Среднее время отклика API (мс)

 > 500

 > 2 000

 Доля HTTP-ошибок 5xx

 > 1%

 > 5%

 Число активных соединений с СУБД

 > 80% max

 > 95% max

 Глубина очереди задач

 > 100

 > 500

 Задержка обработки очереди (с)

 > 60

 > 300

 Загрузка CPU сервера

 > 70%

 > 90%

 Использование RAM

 > 80%

 > 95%

 Использование диска

 > 70%

 > 85%


10.3. Интеграция с системами мониторинга

Prometheus собирает метрики с эндпоинта /api/metrics с интервалом 15 секунд. Grafana отображает рекомендуемые дашборды: «ИНДОРА Overview», «API Latency», «PostgreSQL», «Queue». Альтернативно используется Zabbix с шаблоном UserParameter, опрашивающим health-check и индикаторы очереди. Логи направляются в ELK / OpenSearch через Filebeat с парсингом многострочных стек-трейсов.

10.4. Журнал аудита действий пользователей

Все критически важные действия фиксируются в таблице audit_log и/или файле /var/log/indora/audit.log: вход/выход и неудачные попытки входа; создание, согласование, выдача, продление и закрытие нарядов-допусков; изменение ролей и блокировка пользователей; изменение конфигурации и интеграций; удаление записей и массовые операции; изменения парольной политики и API-ключей. Журнал доступен через CLI indora-cli audit log с фильтрами по пользователю, периоду и категории, а также экспортом в CSV для регуляторных проверок.


11. Информационная безопасность

11.1. Нормативная база

 Нормативный акт

 Применимость

 152-ФЗ «О персональных данных»

 Обязательно — система обрабатывает ПДн сотрудников

 187-ФЗ «О безопасности КИИ»

 Объекты КИИ (нефтегаз, металлургия, энергетика)

 Приказ ФСТЭК № 21

 Обязательно — меры защиты ИСПДн

 Приказ ФСТЭК № 31

 При интеграции с АСУ ТП критически важных объектов

 Приказ ФСТЭК № 117 (заменил № 17 с 01.03.2026)

 Защита информации в государственных ИС

 Приказ ФСТЭК № 239

 Значимые объекты КИИ (ЗОКИИ)

 63-ФЗ «Об электронной подписи»

 Использование УКЭП и УНЭП


11.2. Модель нарушителя

 Категория

 Меры противодействия

 Внешний злоумышленник (Н1) — Интернет

 TLS, rate limiting, WAF, блокировка по IP, аудит входов

 Внутренний пользователь (Н2)

 RBAC, журнал аудита, принцип минимальных привилегий

 Привилегированный пользователь (Н3)

 Разделение обязанностей, детальный аудит, контроль действий

 Подрядчик (Н4)

 Роль «Исполнитель», временные аккаунты, ограничение по времени и зоне работ

 Технический персонал (Н5)

 MFA, разделение доступа к серверам и БД, контроль целостности (AIDE)


11.3. Парольная политика

 [security.password_policy]

 min_length = 12

 require_uppercase = true

 require_lowercase = true

 require_digits = true

 require_special_chars = true

 password_history = 10

 password_expiry_days = 90

 lockout_threshold = 5

 lockout_duration_minutes = 30


11.4. Защита канала и приложения

  • обязательное использование TLS 1.2/1.3 для всех клиент-серверных соединений;
  • поддержка КриптоПро TLS и российских УЦ для ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012;
  • параметризованные запросы и ORM на стороне бэкенда; экранирование вывода — защита от SQL-инъекций и XSS;
  • хэширование паролей bcrypt / argon2; шифрование чувствительных данных в БД;
  • Content Security Policy (CSP), X-Frame-Options: DENY, X-Content-Type-Options: nosniff;
  • CSRF-токены для изменяющих операций; cookie сессий с SameSite=Strict;
  • rate limiting эндпоинта входа (например, 5 запросов в минуту с одного IP).

11.5. Многофакторная аутентификация (MFA)

Поддерживаются методы TOTP (Google Authenticator, Яндекс Ключ), SMS, email-код. Рекомендуется включать MFA в обязательном порядке для административных и аудиторских ролей.

11.6. Доверенная среда — Astra Linux SE

Для объектов, требующих максимального уровня защиты информации, развёртывание выполняется на Astra Linux Special Edition с включённым режимом мандатного контроля доступа (MAC) и применением ФСТЭК-сертифицированных сборок. Дополнительно применяются: ограничение прав сервисной учётной записи indora; политика SELinux/AppArmor; контроль целостности бинарных файлов и конфигурации (AIDE, OSSEC).


12. Обновление и масштабирование

12.1. Минорное обновление (патч)

 /opt/indora/scripts/backup.sh                       # 1. Резервная копия

 sudo systemctl stop indora-app indora-worker         # 2. Остановка сервисов

 sudo dpkg -i indora-server-1.x.y.deb                 # 3. Установка пакета

 sudo -u indora /opt/indora/bin/indora-cli db migrate # 4. Миграции БД

 sudo systemctl start indora-app indora-worker       # 5. Запуск

 curl -k https://indora.company.ru/api/health         # 6. Проверка


12.2. Мажорное обновление

Шаги: изучить Release Notes и Migration Guide, предоставляемые ООО «Тэктис»; протестировать обновление на staging-окружении с копией продуктивной БД; согласовать окно обслуживания; выполнить полный бэкап; провести обновление по Migration Guide; выполнить расширенное функциональное тестирование; перевести пользователей. При проблемах — откат: установка предыдущего пакета и восстановление БД из бэкапа, сделанного перед обновлением.

12.3. Горизонтальное масштабирование

Добавление новой app-ноды выполняется без остановки системы. Новый сервер развёртывается по стандартной процедуре установки (без локальной БД — указывается адрес общей PostgreSQL), затем добавляется в upstream Nginx балансировщика и применяется reload конфигурации:

 upstream indora_backend {

      least_conn;

      server app-node-01:8080;

      server app-node-02:8080;

      server app-node-03:8080;       # ← новая нода

      keepalive 32;

 }

 sudo nginx -s reload


12.4. Репликация PostgreSQL

Потоковая репликация (streaming replication): на master задаются wal_level = replica, max_wal_senders = 5, hot_standby = on; в pg_hba.conf разрешается соединение реплики; создаётся пользователь replicator; на сервере реплики выполняется pg_basebackup с флагом -R для автоматической настройки. Реплики используются для запросов чтения, разгружая основной узел.

12.5. Развёртывание в Kubernetes

Для крупных производственных кластеров применяется Kubernetes 1.27+. Deployment app-tier поддерживает rolling-update, readinessProbe на /api/health, ограничения ресурсов (requests/limits) и HorizontalPodAutoscaler на основе целевой загрузки CPU. Состояние выносится за пределы кластера: PostgreSQL разворачивается на отдельных узлах, файловое хранилище — через Persistent Volumes или S3-совместимый бэкенд.
13. Действия в нештатных ситуациях

13.1. СУБД недоступна

Признаки: 503/500 при обращении к веб-интерфейсу; в /var/log/indora/error.log — ошибки соединения с PostgreSQL. Диагностика и восстановление:

 sudo systemctl status postgresql

 psql -U indora_user -h localhost -d indora_db -c "SELECT 1;"

 sudo tail -100 /var/log/postgresql/postgresql-15-main.log

 

 sudo systemctl restart postgresql         # перезапуск при зависании

 df -h /var/lib/postgresql               # проверка свободного места

 psql -U postgres -c "SELECT count(*), state FROM pg_stat_activity GROUP BY state;"


13.2. Очередь задач зависла

Признаки: уведомления не отправляются, отчёты не генерируются, статистика не обновляется. Действия:

 sudo systemctl status indora-worker

 sudo -u indora /opt/indora/bin/indora-cli queue stats

 sudo journalctl -u indora-worker -n 100 --no-pager

 

 sudo systemctl restart indora-worker

 sudo -u indora /opt/indora/bin/indora-cli queue purge --status=stuck --older-than=2h


13.3. 502 Bad Gateway / интерфейс недоступен

Последовательность проверок: статус Nginx → лог /var/log/nginx/error.log → статус indora-app → прослушивание порта 8080 → перезапуск цепочки systemctl restart indora-app && systemctl reload nginx.

13.4. Электронная подпись (УКЭП) не работает

Проверить установку криптопровайдера (КриптоПро CSP 5.0+, Рутокен Плагин), браузерного расширения и валидность сертификата в системном хранилище. Убедиться, что используется поддерживаемый браузер. На стороне сервера — проверить настройки секции [signature] в /etc/indora/indora.conf. При сохранении проблемы — эскалация в техподдержку поставщика криптопровайдера и/или ООО «Тэктис».

13.5. Высокая нагрузка на сервер

Диагностика: top / htop, iostat -x 1 5, vmstat 1 5. Выявление «тяжёлых» запросов:

 psql -U postgres -d indora_db -c "

 SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state

 FROM pg_stat_activity

 WHERE (now() - query_start) > interval '5 minutes' AND state != 'idle';


13.6. Сбор диагностики и эскалация

Для обращения в техподдержку необходимо собрать: версию ПО (indora-cli version), последние 500 строк app.log и error.log, журналы systemd indora-app и indora-worker, системную информацию (uname, df, free, top), статус PostgreSQL (версия, размер БД, активные соединения), санированную копию конфигурации (без паролей). Регламент SLA технической поддержки ООО «Тэктис»:

 Уровень

 Описание

 Реакция

 P1 — Критический

 Система полностью недоступна, угроза данным

 ≤ 2 часа (телефон + email)

 P2 — Высокий

 Серьёзная деградация функциональности

 ≤ 4 часа (email + телефон)

 P3 — Средний

 Проблема затрагивает часть пользователей

 ≤ 8 рабочих часов (email)

 P4 — Низкий

 Незначительная ошибка, вопрос настройки

 ≤ 2 рабочих дня (email)



14. Регламентное обслуживание

14.1. Ежедневные задачи

 №

 Задача

 Действие

 1

 Работоспособность Системы

 GET /api/health; systemctl status indora-app indora-worker

 2

 Контроль ночного бэкапа

 Проверить наличие нового дампа; журнал /var/log/indora/backup.log

 3

 Журнал ошибок

 tail -100 /var/log/indora/error.log — нет критических ошибок

 4

 Дисковое пространство

 df -h /var/indora /backup /var/lib/postgresql — свободно > 20%

 5

 Очередь задач

 indora-cli queue stats — задержка < 60 с

 6

 Дашборд мониторинга

 Grafana / Zabbix — отсутствие красных алертов


14.2. Еженедельные задачи

  • тестовое восстановление из бэкапа на изолированном сервере (скрипт test_backup.sh);
  • анализ журнала аудита за неделю; обращать внимание на массовые выгрузки и изменения прав;
  • проверка неактивных пользователей: indora-cli users list --last-login-before=7d;
  • проверка просроченных компетенций: indora-cli cms report --expired;
  • применение security-патчей ОС (apt-get / dnf upgrade — только security).

14.3. Ежемесячные задачи

  • инвентаризация пользователей: сверка с HR-системой, деактивация уволенных;
  • аудит прав доступа — соответствие ролей должностным обязанностям;
  • ротация API-ключей по сроку и для уволенных сотрудников;
  • проверка TLS-сертификата (> 30 дней до истечения);
  • VACUUM ANALYZE базы данных; очистка старых логов и временных файлов.

14.4. Ежеквартальные и ежегодные задачи

  • применение очередного обновления Системы в согласованное окно обслуживания;
  • нагрузочное тестирование staging-окружения; контроль достаточности ресурсов;
  • внутренний аудит ИБ: парольная политика, конфигурация TLS, журналы аудита;
  • полное тестирование плана аварийного восстановления (DRP) на стенде;
  • проверка репликации PostgreSQL (pg_stat_replication);
  • ежегодно — перевыпуск TLS-сертификата, инвентаризация ИТ-активов, пересмотр политики безопасности, проверка лицензии, обучение администраторов.


15. Контактная информация и поддержка

15.1. Правообладатель

 Параметр

 Значение

 Полное наименование

 Общество с ограниченной ответственностью «Тэктис»

 Сокращённое наименование

 ООО «Тэктис»

 Торговая марка

 Tactise Group

 Сайт правообладателя

 https://tactise.com

 Сайт продукта

 https://indora.tactise.com

 Адрес штаб-квартиры

 Москва, Варшавское шоссе, д. 1, стр. 6, БЦ W-Plaza 2

 Телефон

 +7 (499) 704-53-56

 Телефон (приёмная)

 +7 (499) 705-78-29

 Email

 info@tactise.com

 Резидент Сколково

 с 2024 года


15.2. Состав технической поддержки

  • помощь в использовании Системы — консультирование администраторов и пользователей;
  • предоставление обновлений ПО и сопровождение процесса обновления;
  • диагностика и устранение дефектов; локализация ошибок и выпуск исправлений;
  • техническая поддержка 24/7 — по условиям соответствующего пакета сопровождения.


16. Перечень нормативных документов

 Обозначение

 Наименование

 РД 50-34.698-90

 Методические указания. Информационная технология. Требования к содержанию документов АС

 ГОСТ 19.503-79

 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению

 ГОСТ 19.101-77

 ЕСПД. Виды программ и программных документов

 ГОСТ 34.201-89

 Виды, комплектность и обозначения документов при создании АС

 ГОСТ 34.602-89

 Техническое задание на создание автоматизированной системы

 116-ФЗ от 21.07.1997

 О промышленной безопасности опасных производственных объектов

 152-ФЗ от 27.07.2006

 О персональных данных

 187-ФЗ от 26.07.2017

 О безопасности критической информационной инфраструктуры РФ

 63-ФЗ от 06.04.2011

 Об электронной подписи

 248-ФЗ от 31.07.2020

 О государственном контроле (надзоре)

 426-ФЗ от 28.12.2013

 О специальной оценке условий труда

 ПП РФ № 1236 от 16.11.2015

 Об установлении запрета на допуск иностранного ПО

 Приказ ФСТЭК № 21 от 18.02.2013

 Меры по обеспечению безопасности ПДн

 Приказ ФСТЭК № 31 от 14.03.2014

 Требования к защите информации в АСУ ТП КВО

 Приказ ФСТЭК № 117 (заменил № 17 в 2025 г.)

 Требования к защите информации в государственных ИС

 Приказ ФСТЭК № 239 от 25.12.2017

 Требования по обеспечению безопасности значимых объектов КИИ

 Приказ Минкомсвязи № 518 от 19.09.2019

 Включение ПО ИНДОРА в Реестр российских программ

 Приказ Минцифры № 486 от 22.09.2020

 Классификатор программ для ЭВМ и баз данных

 ISO 45001:2020

 Система менеджмента охраны здоровья и обеспечения безопасности труда

 ISO 31000:2018

 Менеджмент риска — принципы и руководящие указания

 ISO 19011:2018

 Руководство по аудиту систем управления


17. Перечень сокращений

 Сокращение

 Расшифровка

 АРМ

 Автоматизированное рабочее место

 АСУ ТП

 Автоматизированная система управления технологическими процессами

 БД / СУБД

 База данных / Система управления базами данных

 ГИС

 Государственная информационная система

 ЗОКИИ

 Значимый объект критической информационной инфраструктуры

 ИБ

 Информационная безопасность

 ИМК

 Иерархия мер контроля (Hierarchy of Controls)

 ИСОБР

 Интегрированная система обеспечения безопасности работ

 КИИ

 Критическая информационная инфраструктура

 НД

 Наряд-допуск

 ОПО

 Опасный производственный объект

 ПДн

 Персональные данные

 ПО

 Программное обеспечение

 СИЗ

 Средства индивидуальной защиты

 СКУД

 Система контроля и управления доступом

 ТОиР

 Техническое обслуживание и ремонт

 УКЭП / УНЭП

 Усиленная квалифицированная / неквалифицированная электронная подпись

 ФСТЭК

 Федеральная служба по техническому и экспортному контролю

 CAPA

 Corrective and Preventive Actions

 CMS

 Competence Management System

 HSE

 Health, Safety and Environment

 HA / HPA

 High Availability / Horizontal Pod Autoscaler

 HIT

 Hazard Identification and Tracking

 JWT / HMAC

 JSON Web Token / Hash-based Message Authentication Code

 LOTO

 Lockout-Tagout

 MFA

 Multi-Factor Authentication

 MOC

 Management of Change

 PITR

 Point-in-Time Recovery

 RBAC

 Role-Based Access Control

 REST API

 Representational State Transfer API

 RPO / RTO

 Recovery Point Objective / Recovery Time Objective

 SIMOPS

 Simultaneous Operations

 SLA

 Service Level Agreement

 TLS

 Transport Layer Security

 WAL

 Write-Ahead Log (PostgreSQL)