Паспорт автоматизированной системы (АС) — это основной учетный и нормативный документ, фиксирующий технические, функциональные и эксплуатационные характеристики информационной системы. В структуре Министерства обороны Российской Федерации (МО РФ) оформление паспорта АС регулируется строгими внутренними нормами, приказами и руководящими документами, обеспечивающими защиту гостайны, информационную безопасность и бесперебойное функционирование систем управления войсками и тылом.

Данная статья подробно рассматривает структуру паспорта АС МО РФ, роль технической поддержки (техподдержки) на всех этапах жизненного цикла системы, а также требования к документации и взаимодействию с разработчиками и эксплуатационными организациями.

Нормативно-правовая база и определяющие документы

Формирование паспорта АС в ведомстве строится на иерархии нормативных актов:

• Федеральный закон от № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (общие принципы).
• Приказ Министра обороны РФ (актуальные приказы по вопросам автоматизации, например, Приказ № 360 или актуализирующие их документы), устанавливающие порядок создания, внедрения и эксплуатации АС в МО РФ.
• Руководящие документы Главного управления автоматизации (ГУА) МО РФ (Методические рекомендации по оформлению паспорта АС, реестра АС, отчетности).
• ГОСТ 19.xxx серии (ЕСПД) и ГОСТ Р 57580-2017 (Защита информации. Процессы жизненного цикла АС) — применительно к оформлению документации.
• ФСТЭК и ФСБ руководства — по вопросам сертификации средств защиты информации (СЗИ) и аттестации объектов информатизации (ОИ).

Структура и состав Паспорта АС МО РФ

Паспорт АС является «живым» документом, обновляемым при каждом значимом изменении системы (версии ПО, конфигурации железа, топологии сети, смене ответственных лиц). Типовая структура включает следующие разделы:

Титульный лист и реквизиты учетной карточки

• Полное и сокращенное наименование АС.
• Регистрационный номер в Едином реестре АС МО РФ.
• Уровень секретности (Гриф: «Совершенно секретно», «Секретно», «Для служебного пользования» / ДСП).
• Категория объекта информатизации (ОИ) по защите информации (1, 2, 3, 4 класс).
• Данные о разработчике (ГНИВЦ, НИИ, ПО «Красная Звезда», АО «Русская электроника» и др.) и изготовителе.

Функциональное назначение и состав решаемых задач

Описание бизнес-процессов, которые автоматизирует система: управление логистикой (БМТО), оперативное управление войсками (АСУ ОУ), кадровый учет, финансово-экономическое обеспечение, медицинское обеспечение и т.д.

Техническая характеристика (Аппаратное и программное обеспечение)

• Серверная часть: модели серверов, кластерные конфигурации, объемы хранилищ (SAN/NAS), средства виртуализации (VMware, отечественные гипервизоры типа Virtuozzo/Астра).
• Клиентская часть/РАМ: типы АРМ (стационарные, мобильные, укрепрайонные), требования к минимальной конфигурации.
• Сетевая инфраструктура: схема подключения к ВСС (Военная сеть специального назначения) или КСС (Корпоративная сеть специального назначения), используемые протоколы шифрования (IPsec, TLS ГОСТ), межсетевые экраны (МСЭ), шлюзы безопасности.
• Системное и прикладное ПО: ОС (Астра Линукс Special Edition, РЕД ОС, МСВС), СУБД (PostgreSQL, Яндекс БД, Oracle, на стадиях вытеснения), middleware, версии прикладных модулей.

Средства защиты информации (СЗИ) и режим безопасности

Критически важный раздел для МО РФ. Содержит перечень сертифицированных СЗИ (антивирусы, СКЗИ, системы контроля целостности, средства разграничения доступа, ИДС/ИПС), номера сертификатов ФСТЭК/ФСБ, сроки их действия и настройки политик безопасности.

Регламент технической поддержки (Техподдержки)

Подробно рассматривается в разделе 3.

План аварийного восстановления и резервного копирования (Disaster Recovery / Backup)

• Периодичность бэкапов (полные/инкрементальные), хранение копий (горячее/холодное резервирование).
• RTO (Recovery Time Objective) и RPO (Recovery Point Objective) для критических подсистем.
• Процедуры переключения на резервный ЦОД (Центр обработки данных).

Журналы учета и отчетность

• Журнал регистрации инцидентов и запросов (ITSM-система).
• Журнал изменений (Change Management).
• Журнал доступа администраторов (привилегированные пользователи).
• Отчетность перед ГУА МО РФ (квартальная, годовая);

Техническая поддержка (Техподдержка) АС МО РФ: организационная модель и SLA

Техподдержка в Министерстве обороны выстроена по многоуровневой (эшелонированной) модели, обеспечивающей устойчивость в условиях военизированной структуры и жестких требований по тайне.

Уровни поддержки (L1 — L3 / ВПО — ЦОД — Разработчик)

Ключевые процессы ITIL/ITSM, адаптированные под МО РФ

1. Управление инцидентами (Incident Management): Восстановление работоспособности АС в минимальные сроки. Все инциденты регистрируются в единой АСУ учета инцидентов (например, на базе 1С:ITSM, Naumen, или ведомственной системы).
2. Управление проблемами (Problem Management): Выявление корневых причин повторяющихся сбоев (Root Cause Analysis). Инициирует запросы на изменение (RFC) к L3.
3. Управление изменениями (Change Management): Самый строгий процесс. Любое изменение в АС (патч ОС, настройка МСЭ, обновление СЗИ, схема БД) требует:
   • Заявки на изменение (РФС — Request For Change).
   • Экспертизы ИБ (служба безопасности/ИБ объекта).
   • Тестирования на полигоне/стенде (отдельной среде).
   • Плана отката (Rollback Plan).
   • Согласования с начальником эксплуатации АС и разработчиком.
4. Управление конфигурацией (CMDB): Ведение актуальной базы данных элементов конфигурации (CI) — серверы, лицензии, сетевое оборудование, версии ПО. Паспорт АС — главный артефакт, синхронизируемый с CMDB.
5. Управление выпусками (Release Management): Плановые обновления версии АС (например, v.3.2 -> v.3.3) проводятся строго по утвержденному графику (часто, в нерабочее время, выходные, или по команде «Внезапная проверка» / учения).

Особенности техподдержки в полевых/боевых условиях

• Автономность: Наличие локальных зеркал репозиториев обновлений ОС/СЗИ/ПО для работы без связи с внешним миром/ГУА.
• Мобильные комплекты: Развертывание АС на мобильных серверах (КУНГ, контейнерные ЦОД) с предзагруженными образами (Golden Image).
• Канонизация ПО: Запрет на установку «левого» ПО. Использование только сертифицированных версий из Реестра российского ПО.
• Кадровая устойчивость: Инструкции (Runbook) написаны так, чтобы их мог выполнить конскрипт-оператор после краткого обучения (пошаговые скриншоты, скрипты автоматизации).

Взаимодействие с Разработчиком (Вендором) в рамках ГОЗ/Договора

Техподдержка со стороны разработчика оформляется отдельным соглашением (Соглашением о техподдержке) в составе ГОЗ (Государственного оборонного заказа) или договора на этапе эксплуатации.

Обязательства разработчика (L3):

• Исправление дефектов (багов), выявленных при эксплуатации, в установленные сроки (критичность 1 — «Стоп-эксплуатация» — исправление в экстренном порядке).
• Выпуск обновлений безопасности (Security Patches) для ОС, СЗИ, прикладного ПО в срок не позднее N дней после публикации бюллетеней безопасности (ФСТЭК, ФСБ, вендоров ОС).
• Сопровождение процесса аттестации ОИ (подготовка комплектов документации для ФСТЭК/ФСБ при переаттестации).
• Обучение кадров заказчика (администраторов L2) новым версиям.
• Обеспечение совместимости с платформенным ПО (ОС, СУБД, СЗИ) актуальных версий.

Обязательства Заказчика (МО РФ / Воинская часть):

• Обеспечение доступа разработчика к стендам/полигонам (по VPN/ВСС или при выезде) в режиме «привилегированный доступ под контролем».
• Своевременная передача дампов памяти, логов, скриншотов ошибок для анализа L3.
• Проведение приемо-сдаточных испытаний (ПСИ) обновлений на стенде перед выкаткой в ПРОД.
• Оплата работ по техподдержке (если не входит в ГОЗ на создание).

Жизненный цикл Паспорта АС: актуализация и версионирование

Паспорт АС не статичен. Любое значимое событие требует внесения изменений (выпуска новой редакции или листа замены):

• Смена версии прикладного ПО (Release).
• Миграция на новую ОС / СУБД / СЗИ.
• Изменение топологии сети (новый ЦОД, новый канал ВСС).
• Переаттестация ОИ (смена класса секретности или категории ОИ).
• Смена ответственных лиц (Начальник эксплуатации, Администратор БД, Ответственный за ИБ).
• Выявление несоответствий при проверках (ГУА, Общевойсковая инспекция, Служба безопасности).

Процедура согласования новой редакции:

1. Подготовка проекта паспорта администраторами L2 / Начальником эксплуатации.
2. Согласование в Службе ИБ воинской части/органа (проверка соответствия модели угроз).
3. Согласование в Управлении автоматизации округа/родов войск (УА).
4. Утверждение Командиром (начальником) воинской части/органа — Лицо, подписывающее Паспорт.
5. Регистрация в Едином реестре АС МО РФ (через АСУ учета АС).
6. Распространение актуальной копии на все ответственные подразделения и разработчика.

Типовые проблемы и рекомендации по повышению качества поддержки

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

Решение: Жесткое требование к передаче дела (акта приема-передачи) с обязательным заполнением раздела «Журнал смен ответственных» в Паспорте. Внедрение базы знаний (Wiki/Confluence/SharePoint на КСС) с инструкциями по типовым действиям.

Задержки обновлений СЗИ и ОС из-за длительной согласования

Решение: Внедрение процедуры «Экстренного обновления безопасности» (Fast-track Change) с предварительным согласованием шаблона риска и плана отката у ИБ, позволяющей накатывать критические патчи за 24–48 часов без полного цикла ПСИ на полигоне (с обязательной пост-проверкой).

Отсутствие актуального стенда для тестирования

Решение: Развертывание изолированного контура (стенда) в виртуализированной среде, реплицирующего ПРОД-конфигурацию (анонимизированные данные). Автоматизация развертывания стенда через IaC (Terraform/Ansible) для быстрого воспроизведения ошибок L3.

Низкая компетенция операторов L1 по специфике ВС

Решение: Регулярные учения по ликвидации последствий сбоев (Game Days), включение модулей администрирования АС в программы обучения ВУС (военно-учетных специальностей) и курсов переподготовки в Учебных центрах ГУА.

Паспорт АС Министерства обороны — это не просто формальный документ для проверки, а центральный артефакт управления конфигурацией и безопасностью на протяжении всего жизненного цикла системы. Качество технической поддержки напрямую зависит от актуальности данных в Паспорте (версии ПО, схемы сети, контакты L3, настройки СЗИ).

Эффективная модель техподдержки в МО РФ строится на эшелонированности (L1-L3), жестком управлении изменениями с приоритетом информационной безопасности, автономности контуров и взаимодействии с отечественными разработчиками в рамках импортозамещения. Системное ведение Паспорта, его синхронизация с CMDB и реестром АС ГУА МО РФ являются залогом устойчивой работы автоматизированных систем управления в мирное время и в условиях применения войск.

Приложение: Чек-лист актуальности Паспорта АС (для ежеквартальной проверки)

• [ ] Соответствует ли версия ПО в Паспорте установленной на серверах (вывод rpm -qa | grep <app> / dpkg -l)?
• [ ] Актуальны ли IP-адреса, имена хостов, VLANы в схеме сети?
• [ ] Не истекли ли сроки сертификатов ФСТЭК/ФСБ у установленных СЗИ?
• [ ] Соответствуют ли ФИО ответственных лиц (Нач.экспл., Админ БД, Отв. за ИБ) приказам на назначение?
• [ ] Есть ли в Паспорте ссылки на актуальные RFC (запросы на изменения), закрытые за квартал?
• [ ] Совпадают ли RTO/RPO в Паспорте с утвержденными в Плане ВКС (восстановления)?
• [ ] Есть ли запись о последней переаттестации ОИ и сроке следующей?

Примечание: Конкретные номера приказов, наименования АС (например, АСУ «Боец», АСУ «Логистика», АС «Кадры», АСУ ОУ) и реквизиты документов ГУА МО РФ носят засекреченный характер или являются для служебного пользования (ДСП). Данная статья описывает общую методологию и типовую структуру, применяемую в ведомстве.