Лицензирование СКЗИ: как мы помогаем клиентам

Когда ко мне обращается компания с вопросом «нам нужно лицензировать СКЗИ», я всегда начинаю не с перечня документов, а с одного простого уточнения: «расскажите, что вы реально делаете с криптографией». Потому что за пять лет практики я убедился — десятки проектов спотыкаются не на сборе бумаг, а на том, что изначально неправильно определили саму потребность в лицензировании.

Лицензирование СКЗИ — это не просто «получить бумагу». Для IT-компаний, интеграторов и медицинских организаций это вопрос законного запуска продукта, участия в проектах с регуляторными требованиями и снижения рисков при проверках. На практике сложнее всего не сам факт лицензирования, а понимание: нужна ли лицензия именно в вашем случае, какой объем работ подпадает под требования, как подготовить документы и что делать, если проект уже в работе.

Ниже — практический разбор того, как мы помогаем клиентам пройти этот путь: от первичной оценки до подготовки к лицензированию и сопровождения на этапе внедрения.

Что такое лицензирование СКЗИ простыми словами

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

Лицензирование в этой сфере требуется не «на криптографию вообще», а на конкретные виды деятельности, связанные с разработкой, производством, распространением, установкой, обслуживанием и другими работами, которые регулируются государством. Именно здесь часто возникает путаница: одна компания делает продукт, другая внедряет его, третья сопровождает, и у каждой может быть свой регуляторный статус.

На одном из проектов столкнулся с показательной ситуацией: вендор имел лицензию на разработку, интегратор считал, что ему лицензия не нужна, поскольку он «просто ставит готовое», а заказчик требовал подтверждения правомерности от обоих. При детальном разборе выяснилось, что интегратор выполнял настройку криптографических механизмов и фактически попадал под лицензируемый вид деятельности, несмотря на то что сам код не писал.

Когда лицензирование становится критичным

Обычно вопросы возникают в таких ситуациях:

• компания выводит на рынок продукт с криптографическими функциями;
• интегратор внедряет защищенное решение у заказчика;
• медицинская организация автоматизирует процессы и использует защищенные каналы связи;
• заказчик требует подтверждение правомерности работ с СКЗИ;
• нужен доступ к проектам, где есть требования к лицензии ФСБ или к сертифицированным специалистам.

Отдельно отмечу пятый пункт — за последние два года он стал встречаться заметно чаще. Тендерная документация всё активнее включает требования к наличию лицензий у участников, и формальное несоответствие здесь может стоить контракта, даже если технически компания всё делает правильно.

С какими задачами к нам приходят клиенты

На практике запросы можно разделить на несколько типовых сценариев. За каждым из них стоит конкретная бизнес-ситуация, и универсального ответа «делайте так» здесь нет.

Был случай, когда компания обратилась за сопровождением уже после того, как проиграла тендер именно по формальному признаку — в заявке не хватило подтверждения правомерности работ с СКЗИ. После разбора ситуации выяснилось, что необходимая лицензия у них фактически была, но юристы неправильно интерпретировали формулировки конкурсной документации. Досадная ошибка, которая обошлась в несколько миллионов рублей недополученной выручки.

Как мы помогаем: этап за этапом

1. Проводим первичную регуляторную диагностику

Это самый важный этап. Ошибка здесь стоит дороже всего: можно месяцами собирать документы на лицензирование, хотя на деле конкретной лицензии либо не требуется, либо требуется другой набор разрешений.

Мы смотрим:

• какой продукт или услуга предоставляется;
• есть ли в контуре СКЗИ;
• кто является разработчиком, поставщиком, интегратором и оператором;
• где и как применяется криптография;
• какие данные обрабатываются;
• есть ли взаимодействие с медицинскими системами, персональными данными, защищенными каналами и удаленным доступом.

На одном из объектов при диагностике выяснилось, что заказчик планировал лицензировать деятельность по распространению СКЗИ, хотя по факту компания выполняла установку и настройку — а это уже другой вид деятельности с иными требованиями к документам и персоналу. Если бы пошли по изначальному плану, пакет документов пришлось бы пересобирать заново.

Что дает диагностика

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

Последний пункт — границы ответственности — часто недооценивают, а зря. Когда в проекте участвуют несколько юрлиц, важно зафиксировать, кто именно выполняет лицензируемые работы. Это напрямую влияет на то, кому и какую именно лицензию оформлять.

2. Разбираем модель проекта и цепочку ответственности

В лицензировании СКЗИ очень важно понять, кто именно делает что. На словах все просто: «мы поставляем решение». На практике это может означать разный набор действий:

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

Если роли не разведены, компания может случайно взять на себя деятельность, которая требует отдельного правового статуса. Особенно это касается управления ключевой инфраструктурой — здесь регулятор смотрит наиболее пристально, поскольку компрометация ключей означает компрометацию всей защищенной системы.

На практике не раз сталкивался с ситуацией, когда интегратор в договоре прописывал «техническую поддержку», а по факту выполнял обновление криптографических модулей. С точки зрения регулятора это уже обслуживание СКЗИ, требующее соответствующей лицензии. Хорошо, если это выявляется на этапе диагностики, а не при проверке.

3. Подготавливаем к лицензированию

Когда выясняется, что лицензирование действительно необходимо, мы помогаем подготовиться системно. Обычно это включает:

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

Отдельно подчеркну про техническую базу. При проверке нужно показать не просто наличие серверов и рабочих мест, а организованную среду разработки или обслуживания СКЗИ с разграничением доступа, учетом носителей и контролем целостности. На объектах, где этим пренебрегали, приходилось в авральном режиме дооснащать помещения и настраивать режим доступа уже перед самой проверкой.

Типичная ошибка

Многие начинают с «соберем бумаги для лицензии». Но лицензирующий орган смотрит не на набор файлов как таковой, а на то, есть ли у компании фактическая готовность вести заявленный вид деятельности. Поэтому документы должны отражать реальную работу, а не быть формальной папкой.

Приходилось видеть, как компания заказывала «комплект документов под ключ» у сторонних консультантов, которые никогда не были на объекте. В результате внутренние регламенты описывали процессы, которых физически не существовало — например, журнал поэкземплярного учета СКЗИ был прописан идеально, но на месте его никто не вел. При проверке это вскрылось моментально.

4. Выстраиваем пакет документов

У клиентов чаще всего проблемы не с одним документом, а с логикой всего пакета. Бумаги должны согласовываться между собой: уставные цели, штат, должностные инструкции, приказы, положения, договоры, сведения о помещениях и оборудовании.

Мы помогаем проверить:

• нет ли противоречий между документами;
• соответствует ли кадровый состав заявляемой деятельности;
• правильно ли описаны функции сотрудников;
• хватает ли подтверждающих материалов;
• нет ли «мертвых» формулировок, которые выглядят красиво, но ничего не доказывают.

Последний пункт особенно важен. Часто встречаю в документах фразы типа «сотрудник обеспечивает информационную безопасность в соответствии с требованиями законодательства». Регулятору это ни о чем не говорит — нужна конкретика: какие именно СКЗИ обслуживает сотрудник, в каком объеме, по каким регламентам, с какой периодичностью.

5. Сопровождаем подготовку к проверкам и запросам

На практике почти всегда возникают уточнения со стороны проверяющей стороны: по сотрудникам, помещениям, оборудованию, внутренним процедурам, формулировкам в документах. Важно отвечать не быстро, а правильно.

Мы помогаем:

• сформулировать ответы на запросы;
• собрать недостающие подтверждения;
• не перегрузить ответ лишней информацией;
• не допустить противоречий между разными пояснениями.

Из практики: один из самых частых запросов при проверке — уточнение по квалификации конкретных сотрудников. Проверяющий может запросить не просто наличие диплома, а подтверждение, что сотрудник действительно выполняет заявленные функции. Здесь спасает грамотно составленная должностная инструкция и внутренние документы о назначении ответственных за СКЗИ.

Почему без отраслевой практики здесь легко ошибиться

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

Приведу пример: в одном проекте команда блестяще описала процессы разработки, но на вопрос проверяющего «покажите, где физически хранятся исходные коды криптографических модулей и кто имеет к ним доступ» возникла заминка. Оказалось, что репозиторий лежит в общем облаке без разграничения доступа, и это никак не было отражено в документах — просто потому, что при подготовке никто не подумал про этот нюанс.

Три частых заблуждения

1. «Если мы просто продаем ПО, лицензия не нужна»
Не всегда. Все зависит от того, что именно делает продукт и какие действия с ним выполняет компания. Распространение само по себе может требовать лицензии, если продукт содержит СКЗИ и компания передает его третьим лицам. А если помимо передачи дистрибутива вы еще и консультируете по настройке криптографических параметров, грань между распространением и внедрением становится совсем тонкой.

2. «Достаточно нанять одного специалиста»
Обычно недостаточно. Важна не только формальная должность, но и соответствие компетенций, функций и подтверждений. Регулятор смотрит на совокупность: образование, опыт, должностные обязанности, фактически выполняемые работы. Один специалист, даже с идеальным профилем, физически не сможет закрыть все необходимые функции, если компания ведет несколько видов деятельности со СКЗИ.

3. «Можно дооформить потом»
Иногда можно, но не всегда безопасно. Если запуск уже произошел, исправлять схему бывает сложнее и дороже. На одном проекте компания полгода работала без лицензии на обслуживание СКЗИ, полагая, что «оформят, когда потребуется». Когда потребовалось — выяснилось, что за прошедшее время накопился объем операций, который сложно корректно задокументировать задним числом без риска получить претензии.

Что особенно важно для IT-компаний и медорганизаций

Для IT-компаний

Здесь ключевая проблема — правильное описание продукта. Многие системы содержат криптографию «внутри», но не все действия с ними лицензируются одинаково. Нужно разделять:

• разработку;
• поставку;
• внедрение;
• сопровождение;
• администрирование;
• использование встроенных криптосредств.

Кроме того, важно заранее определить, кому принадлежат обязанности по обновлениям, ключевой инфраструктуре и инцидентам. Это не просто организационный момент — от распределения ответственности зависит, кому именно нужна лицензия и какого вида. Если по договору интегратор отвечает за обновление криптографических библиотек, он фактически выполняет обслуживание СКЗИ, даже если сам продукт не разрабатывал.

Для медицинских организаций

В медицине к криптографии добавляются требования к защите персональных данных, дистанционным сценариям, телемедицинским процессам и документированию действий сотрудников. Здесь ошибка в регуляторной модели может повлиять не только на ИБ, но и на легитимность самого процесса оказания услуги.

Особенно внимательно нужно смотреть на:

• удаленные медосмотры;
• передачу данных через защищенные каналы;
• хранение заключений и журналов;
• права доступа персонала;
• использование внешних платформ и облачных сервисов.

На практике самый чувствительный момент — удаленные медосмотры. Здесь криптозащита канала связи — не техническая опция, а обязательное требование, влияющее на законность всей процедуры. Если канал не защищен сертифицированными СКЗИ, а медицинская организация этого не учла, под вопросом оказываются не только штрафы за нарушение ИБ, но и правомерность самих медицинских заключений, выданных по результатам таких осмотров.

Как мы подходим к проекту: наш рабочий чек-лист

Ниже — упрощенная схема того, как выглядит работа с клиентом. Это не исчерпывающий перечень, но по нему видна логика движения: от общего понимания к точечной проверке готовности.

Чек-лист первичного анализа

• Определить продукт, услугу или проект
• Выделить все точки, где используется криптография
• Понять, кто выполняет работы фактически
• Проверить необходимость лицензии или иных разрешений
• Оценить кадровый состав
• Проверить договоры и схему взаимодействия
• Оценить документацию по процессам и безопасности
• Составить план подготовки

Обратите внимание на третий пункт — «понять, кто выполняет работы фактически». Это отличается от формального распределения ролей в договорах. Мы всегда сверяем, что написано на бумаге и что происходит на самом деле, потому что расхождения между этими двумя картинами — прямой путь к проблемам при проверке.

Чек-лист готовности к подаче

• Организационная структура подтверждает вид деятельности
• Сотрудники имеют нужную квалификацию
• Внутренние регламенты актуальны
• Помещения и техническая база описаны корректно
• Документы не противоречат друг другу
• Есть подтверждение реальной деятельности
• Подготовлены ответы на вероятные вопросы

Последний пункт — подготовка ответов на вероятные вопросы — часто выпадает из поля зрения. А между тем, за пять лет практики я могу с высокой точностью предсказать, какие именно уточнения последуют в зависимости от профиля компании и заявляемого вида деятельности. Лучше иметь заготовленные обоснования заранее, чем формулировать их в спешке, когда запрос уже пришел.

Какие ошибки встречаются чаще всего

К таблице добавлю наблюдение: первые две ошибки — «начинают без диагностики» и «не разделяют роли» — в моей практике встречаются в восьми случаях из десяти. Это системная проблема рынка: многие воспринимают лицензирование как административную процедуру, а не как юридическое оформление реальной инженерной деятельности.

Как понять, что вам уже пора разбирать тему лицензирования

Если вы узнали себя хотя бы в одном пункте, лучше не откладывать:

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

Из опыта: чем раньше начать разбор, тем дешевле и проще он проходит. Проект на стадии идеи можно скорректировать за несколько консультаций. Проект, который уже запущен и работает без лицензии, — это всегда компромиссы, временные схемы и повышенные риски.

Что дает профессиональное сопровождение

Главная ценность не в том, чтобы «собрать комплект бумаг», а в том, чтобы:

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

Для нас лицензирование СКЗИ — это не разовая услуга, а часть более широкой задачи: сделать так, чтобы IT- и медпроект был не только технологически рабочим, но и юридически жизнеспособным. Потому что проект, который работает сегодня, но может остановиться завтра из-за регуляторных рисков — это неработающий проект.

Вывод

Лицензирование СКЗИ почти всегда требует не одного ответа, а целой цепочки решений: нужно понять, что именно делает компания, где заканчивается разработка и начинается регуляторно значимая деятельность, какие документы подтверждают реальную готовность и как не создать лишние риски на ровном месте.

Если подходить к теме как к формальности, можно потерять время, деньги и контракт. Если же разбирать проект системно, лицензирование становится управляемой задачей: понятной по этапам, срокам и документам.

FAQ

Нужна ли лицензия всем, кто использует СКЗИ?

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

Можно ли сначала запустить проект, а потом заняться лицензированием?

Иногда технически можно, но это рискованный путь. Лучше заранее проверить регуляторную модель. Одно дело — пилотный проект внутри компании, другое — коммерческий запуск с внешними заказчиками. Во втором случае отсрочка может обернуться претензиями и невозможностью легализовать уже выполненные работы.

Что важнее: документы или реальная готовность компании?

И то и другое. Документы должны подтверждать фактическое состояние дел, а не жить отдельно от него. Регулятор проверяет именно соответствие бумажной картины реальности, и расхождения трактуются не в пользу заявителя.

Сколько времени занимает подготовка?

Срок зависит от исходной готовности компании: кадров, процессов, помещений, документации и сложности проекта. В моей практике были случаи, когда компания проходила весь путь за два месяца, а были проекты, где подготовка занимала полгода — потому что требовалось не только собрать документы, но и выстроить процессы, которых раньше просто не существовало.

Чем полезна предварительная диагностика?

Она помогает понять, нужна ли лицензия вообще, какие риски есть в модели работы и что нужно исправить до подачи документов. Это как инженерное обследование перед стройкой: можно начать копать сразу, но лучше сначала понять, где проходят коммуникации.

Подходит ли такой подход для медицинских проектов?

Да, и часто даже особенно важен, потому что там к криптографии добавляются требования по персональным данным, телемедицине и организации процессов. В медицине регуляторная картина почти всегда сложнее, чем в чистом IT, и ошибка в одном элементе может потянуть за собой несоответствия в смежных областях.