Защищённое и специализированное ПО: что это и когда обязательно
«Защищённое ПО» звучит как маркетинговый ярлык, но за ним стоят конкретные требования закона и регуляторов — и для части компаний это не выбор, а обязанность. Разбираем, что на самом деле имеют в виду под этим термином, кому он действительно обязателен, и как требования безопасности встраиваются в разработку, а не приклеиваются к готовому продукту в последний момент.
Разработать защищённое ПО на заказ приходится не только по требованию закона — иногда это оправдано просто здравым смыслом безопасности.
Что считается защищённым и специализированным ПО
Термин объединяет две разные, но связанные вещи:
- Защищённое ПО — система, в которой требования к безопасности не «одна из фич», а заложены в архитектуру с самого начала: шифрование данных, контроль доступа по ролям, журналирование действий, устойчивость к типовым атакам. Часто это требование внешнее — закона или регулятора, а не только желание заказчика.
- Специализированное ПО — система для узкой предметной области с собственными регуляторными или отраслевыми стандартами: медицинские информационные системы, ПО для работы с гостайной или служебной информацией, системы для объектов критической инфраструктуры.
На практике эти два понятия почти всегда идут вместе: специализированное ПО почти всегда обязано быть защищённым в силу специфики данных, с которыми оно работает.
Кому это обязательно по закону
| Ситуация | Что применяется | Что это значит для разработки |
|---|---|---|
| Обработка персональных данных клиентов | 152-ФЗ | Организационные и технические меры защиты, соразмерные объёму и категории данных |
| Обработка медицинских, биометрических данных | 152-ФЗ, специальная категория | Более строгие требования: согласие, хранение, доступ, часто — уведомление Роскомнадзора |
| Объект критической информационной инфраструктуры | 187-ФЗ | Категорирование объекта, включение в реестр, для значимых объектов — обязательные требования к защите |
| Медицинская информационная система | отраслевые требования Минздрава + 152-ФЗ | Требования к хранению медицинских данных, часто — включение в реестр отечественного ПО при работе с госструктурами |
Если ни одна из этих ситуаций не про вас — вероятно, речь не идёт об обязательном «защищённом ПО» в юридическом смысле, а о разумном базовом уровне безопасности, который стоит закладывать в любую разработку. Мы разбираем это на первом созвоне, чтобы не продавать вам сертификацию и процедуры, которые вам не обязательны.
Как требования безопасности встраиваются в разработку
Правильный порядок — заложить защиту в архитектуру на старте, а не проводить аудит безопасности перед сдачей и латать найденное. Слои защиты выстраиваются от данных наружу:
- Моделирование угроз на старте. Прежде чем писать код, разбираем, какие данные защищаем и от кого — от случайной ошибки сотрудника, от внешней атаки, от утечки через третью сторону. Это определяет, какие меры действительно нужны, а какие избыточны.
- Шифрование данных — как при хранении (в базе, в бэкапах), так и при передаче между сервисами. Часто пропускают именно бэкапы — зашифрованная база при незашифрованном бэкапе не даёт реальной защиты.
- Ролевой доступ по принципу минимальных прав. Каждый компонент системы и каждый сотрудник получает ровно тот доступ, который нужен для работы — не больше.
- Журналирование чувствительных операций. Кто, когда и к каким данным обращался — не только для расследования инцидентов, но и как требование многих регуляторных норм.
- Контроль зависимостей. Библиотеки с открытым кодом — типичный источник уязвимостей в чужом коде, который редко проверяют так же тщательно, как свой.
Особенности медицинских информационных систем
Медицинские данные — специальная категория персональных данных, поэтому требования к МИС строже базовых: более жёсткие условия хранения и передачи, часто — обязанность уведомлять Роскомнадзора об обработке, требования к резервному копированию и восстановлению без потери данных. Отдельный момент — интеграция: МИС редко существует изолированно, обычно нужна связь с внешними системами (лабораторные данные, страховые, региональные медицинские информационные системы), и на стыке систем риски безопасности растут — это стоит закладывать в архитектуру заранее, а не решать точечными патчами после того, как интеграция уже сделана.
Как выбрать подрядчика
Разработчика для такой задачи стоит выбирать по конкретным признакам, а не по общему впечатлению от презентации:
- Спрашивает про модель угроз до старта разработки, а не предлагает «добавить безопасность потом» — если этот вопрос не звучит на первом созвоне, задайте его сами.
- Честно говорит, если формальная сертификация вам не нужна, вместо того чтобы продавать процедуры, обязательные для других категорий систем.
- Показывает, как устроено журналирование и контроль доступа в предыдущих проектах — это можно спросить и увидеть, а не просто поверить на слово.
- Отдельно проговаривает требования 152-ФЗ, если система работает с персональными или медицинскими данными.
Частые вопросы
Чем защищённое ПО отличается от обычного?
В обычном ПО безопасность — одна из задач среди прочих. В защищённом ПО требования к безопасности заложены в архитектуру с самого начала и часто закреплены не только внутренними стандартами, но и внешними требованиями — законом, регулятором или отраслевым стандартом, которые нужно подтверждать документально, а не просто «иметь в виду».
Любой ли бизнес, который работает с персональными данными, обязан заказывать защищённое ПО?
152-ФЗ распространяется на всех, кто обрабатывает персональные данные, но уровень требуемой защиты сильно различается в зависимости от объёма данных, их категории (обычные, специальные — например медицинские, биометрические) и модели угроз. Небольшой базе клиентских контактов может быть достаточно организационных мер и базового технического уровня защиты; для медицинских данных или биометрии требования жёстче.
Нужна ли сертификация ФСТЭК для заказной разработки?
Не всегда. Обязательная сертификация или включение в реестр значимых объектов КИИ применяется к определённым категориям систем — например, объектам критической информационной инфраструктуры по 187-ФЗ или системам, где заказчик по своим внутренним требованиям обязан использовать сертифицированные средства защиты. Для большинства коммерческих систем достаточно следовать безопасным практикам разработки без формальной сертификации, но это стоит уточнять на старте, а не в процессе.
Что именно проверяется в безопасной разработке помимо самого кода?
Помимо код-ревью и тестов на уязвимости — модель угроз (что и от кого защищаем), контроль зависимостей (библиотеки с открытым кодом тоже могут быть источником уязвимостей), управление доступом и секретами (кто и как получает доступ к продакшену), журналирование действий с чувствительными данными и план реагирования на инциденты — что делать, если что-то всё же произошло.
Насколько дороже обходится разработка защищённого ПО по сравнению с обычным?
Дополнительная стоимость складывается не из «наценки за защищённость», а из реальных трудозатрат: моделирование угроз, более тщательное код-ревью, тестирование безопасности, документирование мер защиты. На небольших проектах это может добавить заметную долю к бюджету; на крупных системах, где безопасность закладывается в архитектуру с нуля, относительный прирост стоимости меньше, потому что переделывать ничего не приходится.
Расскажите, какие данные защищает ваша система и кто с ней работает — на созвоне за 40 минут поймём, какой уровень защиты вам действительно нужен.
Обсудить проект