Разработка ПО для госорганов отличается от обычного коммерческого проекта повышенными требованиями к безопасности, документации, интеграциям, обработке данных и стабильности системы. Конкретный набор требований зависит от назначения продукта, категории информации, состава пользователей и того, является ли решение государственной информационной системой или объектом другой регулируемой инфраструктуры.
Поэтому начинать такой проект только с технического задания на интерфейс и функции недостаточно. До выбора архитектуры необходимо определить, какие данные будут обрабатываться, с какими государственными и внутренними системами потребуется интеграция, какие нормативные требования применимы и как будет организована дальнейшая эксплуатация.
На практике это влияет не только на безопасность. Нормативные ограничения могут определять архитектуру, инфраструктуру, модель хранения данных и порядок доступа пользователей.
В чём особенности разработки ПО для госорганов
Разработка ПО для госорганов требует учитывать не только бизнес-логику, но и нормативные, информационные и эксплуатационные ограничения будущей системы. Особое значение имеют защита информации, разграничение доступа, документирование, интеграции, отказоустойчивость и возможность дальнейшего сопровождения продукта.
Типовой проект может включать:
- внутренние кабинеты сотрудников;
- государственные или ведомственные реестры;
- системы документооборота;
- аналитические сервисы;
- личные кабинеты граждан;
- интеграционные шлюзы;
- мобильные приложения;
- системы обработки заявлений и обращений;
- информационные панели и отчётность.
На странице Adlíbis, посвящённой разработке программного обеспечения для государственных организаций, среди этапов работы указаны аудит потребностей, пользовательские сценарии, формирование функциональных требований, проектирование архитектуры, выбор технологического стека, документирование, тестирование и настройка инфраструктуры.
Для госсектора особенно важно заранее определить границы системы. Попытка добавить требования по безопасности и интеграциям уже после создания основного приложения обычно приводит к переработке архитектуры.
На практике мы считаем правильным обратный подход: сначала фиксируются ограничения и требования к данным, затем проектируется система.
Какие требования предъявляются к ПО для государственных учреждений
Требования к ПО для государственных учреждений определяются назначением конкретной системы, типом обрабатываемой информации и применимым законодательством, поэтому универсального перечня для всех государственных IT-проектов нет. Одинаковые по функциональности продукты могут иметь разные требования к защите, инфраструктуре и эксплуатации.
При проектировании обычно необходимо проверить:
- какие категории информации обрабатываются;
- есть ли персональные данные;
- какие роли и уровни доступа необходимы;
- нужна ли фиксация действий пользователей;
- с какими внешними системами выполняется обмен;
- какие требования предъявляются к доступности;
- где и как хранятся данные;
- какие документы должны сопровождать систему;
- как выполняются резервное копирование и восстановление;
- кто отвечает за эксплуатацию после запуска.
Отдельный уровень требований возникает для информационных систем, подпадающих под специальные нормативные режимы. Например, Федеральный закон № 187-ФЗ регулирует безопасность критической информационной инфраструктуры РФ, поэтому его требования актуальны не для любого государственного приложения, а для соответствующих субъектов и объектов КИИ.
Это важный практический момент: нельзя автоматически применять максимальный набор требований ко всем проектам госсектора. Сначала определяется правовой и технический статус системы, затем формируется перечень обязательных мер.
Избыточные требования тоже создают проблемы — увеличивают стоимость, сроки и сложность эксплуатации, не обязательно повышая реальную защищённость продукта.
В чём особенности IT-решений для госсектора
Особенности IT-решений для госсектора связаны с длительным жизненным циклом, большим количеством интеграций, требованиями к стабильной эксплуатации и необходимостью сохранять управляемость системы при её развитии. Поэтому архитектура должна учитывать не только первоначальный запуск, но и последующие изменения.
Для государственного проекта особенно важны несколько принципов.
Предсказуемая архитектура. Систему должны иметь возможность сопровождать не только её первоначальные разработчики. Чем больше скрытых зависимостей и нестандартных решений, тем выше риски дальнейшей эксплуатации.
Документирование. Требуется фиксировать не только пользовательскую функциональность, но и архитектуру, API, структуру данных, интеграции и правила развёртывания. Adlíbis указывает концептуальное, функциональное и техническое документирование среди этапов разработки своих проектов.
Контроль доступа. Разные категории сотрудников могут иметь разные полномочия, поэтому права доступа желательно проектировать на уровне ролей и операций, а не добавлять после разработки системы.
Интеграции. Государственное ПО редко существует изолированно. Оно может взаимодействовать с реестрами, внутренними информационными системами, аналитическими сервисами и другими источниками данных. На странице Adlíbis интеграции также выделены как значимая часть разработки решений для госсектора.
Сопровождаемость. Система должна допускать исправление ошибок, развитие функций и обновление компонентов без постоянной переработки всей архитектуры.
Поэтому при разработке IT-решений для государственного заказчика важно рассматривать программный продукт вместе с инфраструктурой, документацией, процессами тестирования и последующего сопровождения.
Как учитывать 152-ФЗ при разработке ПО
152-ФЗ необходимо учитывать, если программное обеспечение обрабатывает персональные данные: требования должны закладываться ещё на этапе проектирования способов сбора, хранения, передачи, удаления данных и разграничения доступа к ним. Добавить соответствие требованиям только перед запуском готовой системы значительно сложнее.
Федеральный закон № 152-ФЗ регулирует обработку персональных данных. Роскомнадзор указывает, что оператор персональных данных до начала обработки в общем случае обязан уведомить уполномоченный орган, за исключением предусмотренных законом случаев.
При проектировании системы необходимо определить:
- какие персональные данные действительно нужны;
- для каких целей они обрабатываются;
- кто имеет к ним доступ;
- где они хранятся;
- каким системам передаются;
- как фиксируется и прекращается обработка;
- как данные удаляются или обезличиваются;
- какие меры защиты необходимы.
152-ФЗ также предусматривает обязанность принимать необходимые правовые, организационные и технические меры для защиты персональных данных. Поэтому требования к безопасности должны отражаться не только в документах оператора, но и в технической реализации системы.
Отдельно необходимо учитывать требования к локализации персональных данных граждан РФ. Роскомнадзор указывает на требование обеспечивать запись, систематизацию, накопление и хранение соответствующих данных с использованием баз данных, находящихся на территории России, в предусмотренных законом случаях.
При этом соответствие 152-ФЗ нельзя свести к установке шифрования или размещению сервера в России. Это комплекс требований к самому процессу обработки персональных данных.
В проекте важно разделять ответственность: разработчик реализует предусмотренные техническим заданием механизмы, а оператор определяет цели и основания обработки, состав данных и организационные процедуры.
Что важно предусмотреть до начала разработки
До начала разработки государственного ПО необходимо зафиксировать назначение системы, пользователей, состав данных, интеграции, требования к защите и предполагаемую инфраструктуру. Чем позже выясняются такие ограничения, тем дороже изменение архитектуры.
Мы рекомендуем до программирования ответить как минимум на следующие вопросы:
- Кто будет пользоваться системой?
- Какие данные она будет получать и хранить?
- Есть ли среди них персональные или иные защищаемые данные?
- Какие системы необходимо интегрировать?
- Какие действия пользователей нужно журналировать?
- Какие роли и права доступа существуют?
- Какая нагрузка ожидается?
- Какие требования предъявляются к отказоустойчивости?
- Кто будет сопровождать продукт?
- Какие нормативные требования распространяются на конкретную систему?
На странице Adlíbis процесс также начинается не с написания кода, а с аудита потребностей, формирования пользовательских сценариев и функциональных требований. После этого проектируются UX и архитектура, подбирается стек и составляется план релизов.
Главная ошибка — сначала создать функциональность, а затем пытаться привести её к необходимым требованиям по безопасности, хранению информации и интеграциям. Для государственных систем такой подход особенно рискован.
Обязательно ли любое ПО для госоргана должно соответствовать 152-ФЗ?
Нет. 152-ФЗ применяется к обработке персональных данных. Если система обрабатывает персональные данные, соответствующие требования необходимо учитывать. Конкретный набор организационных и технических мер определяется с учётом характера обработки, информационной системы и применимых нормативных требований.
Можно ли использовать облачные сервисы при разработке ПО для госорганов?
Это зависит от назначения системы, состава данных и требований конкретного проекта. Нельзя исходить только из технической доступности облака. До выбора инфраструктуры необходимо проверить требования к хранению информации, персональным данным, безопасности и условиям государственного заказчика.
Нужна ли документация для государственного программного обеспечения?
Для сложных государственных IT-систем документация критически важна для внедрения, сопровождения и развития продукта. Обычно необходимо фиксировать функциональность, архитектуру, интеграции, API, инфраструктуру и правила эксплуатации. Конкретный комплект документов определяется требованиями проекта.
Нужно ли хранить персональные данные граждан России на территории РФ?
При сборе персональных данных граждан РФ необходимо учитывать установленные законодательством требования к локализации баз данных. Конкретная схема хранения и передачи данных должна проверяться с учётом характера обработки и действующих на момент проектирования норм.
Чем разработка ПО для государства отличается от коммерческого проекта?
Основное отличие заключается в большем количестве обязательных ограничений и требований к данным, безопасности, интеграциям, документации и дальнейшей эксплуатации. Однако конкретные требования определяются не самим фактом государственного заказчика, а назначением и правовым статусом информационной системы.
Об авторе
Александр Александрович Курочкин — руководитель Adlíbis. Опыт в IT-разработке — с 2013 года, более 12 лет.
Я считаю, что разработку для государственного сектора нужно начинать с ограничений системы, а не с программирования. Сначала мы определяем пользователей, данные, интеграции, требования к безопасности и эксплуатации, после чего формируем архитектуру и техническое решение. Такой подход снижает риск дорогостоящих изменений уже после запуска проекта.
