Когда речь заходит о защите персональных данных, разговор быстро скатывается к шифрованию - и тут же возникает путаница. Одни считают, что зеленый замок в адресной строке браузера уже все решает, другие уверены, что закон требует ставить дорогое сертифицированное ПО на каждый сервер с базой клиентов. Обе крайности неверны. Криптографическая защита персональных данных - это отдельный класс мер, обязательный далеко не всегда, а строго в определенных случаях, и путать обычный TLS-сертификат с сертифицированными СКЗИ ФСБ - частая причина и лишних расходов, и реальных штрафов при проверке.
Разбираемся, где проходит граница между шифрование есть и криптографическая защита выполнена по закону, когда без сертифицированных средств криптографической защиты информации не обойтись, сколько это стоит и как законно снизить требования, изменив модель угроз, а не покупая лицензии про запас.
Что закон понимает под криптографической защитой персональных данных
Закон о персональных данных обязывает оператора принимать технические меры для защиты данных от неправомерного доступа, но сам не расписывает, какое именно программное обеспечение ставить. Конкретный состав мер и требования к шифрованию персональных данных определяют подзаконные акты: постановление Правительства № 1119 от 1 ноября 2012 года устанавливает уровни защищенности, а приказы ФСТЭК и ФСБ - конкретные технические и организационные меры для каждого уровня.
Само по себе применение шифрования закон описывает в общих чертах: оператор обязан принять меры, соразмерные угрозам, а не выполнить формальный чек-лист. Отсюда и распространенная ошибка - воспринимать требование как жесткое да или нет для всех подряд, хотя на деле объем мер каждый раз считается заново, под конкретную систему и конкретные данные, а не берется из чужого технического задания.
Здесь и возникает первая путаница. В обиходе шифрованием называют все подряд: HTTPS-сертификат на сайте, зашифрованный диск на ноутбуке бухгалтера, пароль на архиве с базой клиентов. С точки зрения закона это разные вещи. Обычное шифрование - общая мера безопасности, которую разумно применять в любом случае, независимо от того, что говорит нормативный акт. А термин СКЗИ, средство криптографической защиты информации, обозначает конкретный класс продуктов, прошедших сертификацию ФСБ России и включенных в соответствующий реестр. К таким продуктам на российском рынке относятся, например, КриптоПро CSP и ВипНет CSP.
Разница принципиальная. Сайт может использовать бесплатный SSL-сертификат, шифровать трафик между браузером посетителя и сервером - и это правильно, безопасно, но с точки зрения профильных приказов ФСТЭК и ФСБ это не применение СКЗИ. Применение сертифицированного средства криптографической защиты - отдельное организационное решение, которое принимается не потому, что так удобнее, а потому, что того требует модель угроз для конкретной информационной системы персональных данных, если у вас есть основания считать, что она у вас есть.
Когда криптография обязательна: угрозы и уровни защищенности
Обязательность сертифицированной криптографии не зависит от размера компании или суммы годового оборота. Она зависит от трех вещей: какие данные обрабатываются, какой уровень защищенности присвоен информационной системе и какой тип угроз актуален именно для нее.
Постановление 1119 делит информационные системы на четыре уровня защищенности - от УЗ-4, самого мягкого, до УЗ-1, самого строгого. Уровень определяется сочетанием трех параметров: категорией персональных данных (специальные, биометрические, общедоступные или иные), числом субъектов, чьи данные обрабатываются, и типом актуальных угроз. Актуальный тип угроз, в свою очередь, фиксируется в модели угроз - документе, который оператор обязан составить сам или заказать у подрядчика, а не скопировать из интернета. Как ее готовят и какие ошибки в ней чаще всего находят на проверках, разобрано отдельно в материале про модель угроз безопасности персональных данных - его стоит прочитать до того, как решать вопрос с криптографией, потому что именно этот документ, а не желание сэкономить или перестраховаться, формально обосновывает выбор мер защиты.
Логика простая: чем выше уровень защищенности, тем больше вероятность, что среди обязательных мер появится требование использовать сертифицированные средства криптографической защиты. Для УЗ-1 и УЗ-2, где обрабатываются специальные категории данных - о здоровье, судимости, национальности - или речь идет о больших объемах данных при угрозах, связанных с недекларированными возможностями программного обеспечения, применение СКЗИ практически неизбежно. Для УЗ-3 и УЗ-4, характерных для типового сайта-визитки или интернет-магазина с формой заказа, чаще достаточно организационных мер и обычного шифрования канала связи.
Определить свой уровень - отдельная задача, для которой нужно последовательно пройти все критерии постановления 1119, и подробно об этом написано в материале как определить уровень защищенности по ПП-1119. Без этого шага любой разговор про обязательность криптографии беспредметен: сначала уровень, потом решение про СКЗИ, а не наоборот.
| Ситуация | Нужен сертифицированный СКЗИ | Что обычно требуется |
|---|---|---|
| Сайт-визитка, форма обратной связи, ФИО и телефон | Как правило нет | HTTPS, ограничение доступа к базе, резервные копии |
| Интернет-магазин без приема оплаты на своей стороне | Как правило нет | HTTPS, разграничение прав в CRM, журнал доступа |
| Медицинская информационная система, данные о здоровье | Как правило да | СКЗИ класса КС1-КС2 для каналов передачи и удаленного доступа |
| Биометрическая идентификация, Face ID, отпечаток | Да | Сертифицированное СКЗИ, согласование с оператором ЕБС |
| Информационная система для госзаказчика | Да | Класс определяется техническим заданием, обычно КС2-КС3 |
Обычный TLS и сертифицированный СКЗИ ФСБ: в чем разница
TLS-сертификат, который сегодня стоит на любом уважающем себя сайте, защищает данные пользователя при передаче между браузером и сервером - от момента, когда посетитель набирает номер телефона в форме заказа, до момента, когда эти данные попадают в базу. Для большинства сайтов это разумная и достаточная мера, и требования к шифрованию персональных данных на уровне организационных мер прямо ее подразумевают.
Сертифицированное СКЗИ - другая история. Приказ ФСБ России от 10 июля 2014 года № 378 определяет состав мер по защите персональных данных с использованием средств криптографической защиты и делит СКЗИ на классы: КС1, КС2, КС3, КВ и КА, от простого к сложному. Класс подбирается под конкретную модель угроз: КС1 закрывает угрозы, для реализации которых нарушителю не нужен физический доступ к системе, КС2 и КС3 учитывают более серьезные сценарии вплоть до сговора с сотрудниками оператора, а КВ и КА применяются там, где цена ошибки измеряется не штрафом, а последствиями для безопасности в более широком смысле - в государственных и критически важных системах.
Более полный разбор технических требований к шифрованию на уровне сайта, включая настройку самого TLS, приведен в материале SSL и шифрование: требования ФСТЭК и ФСБ к сайтам с персональными данными.
Разница на практике выглядит так. Обычный сайт с формой заявки использует TLS - и этого достаточно, потому что угрозы для него типовые, а модель угроз, если она составлена честно, не выявляет ничего, что требовало бы более серьезных мер. Медицинский портал с личным кабинетом пациента, где хранится диагноз и назначения, обрабатывает специальные категории данных, и для удаленного доступа врача к этой системе через интернет уже может потребоваться сертифицированный СКЗИ - не потому что так удобнее, а потому что через незащищенный сертифицированными средствами канал передаются данные, разглашение которых способно причинить субъекту прямой вред.
Есть и промежуточный вариант, который на практике встречается чаще всего: организация использует TLS для сайта и добавляет СКЗИ только там, где данные покидают периметр компании - при удаленном подключении сотрудников к базе, при передаче данных подрядчику, при резервном копировании в облако. Точечное применение вместо тотального - разумный подход, если он подтвержден моделью угроз, а не выбран наугад.
Кому криптография нужна на практике
Правила выше выглядят абстрактно, пока не разложить их по типам бизнеса, с которыми обычно работает 152fzpro.ru.
Интернет-магазин собирает имя, телефон, адрес доставки и, если повезло с эквайрингом, не видит номер карты вообще - его принимает платежный шлюз банка. В такой конфигурации уровень защищенности обычно УЗ-3 или УЗ-4, тип угроз третий, то есть не связанный с недекларированными возможностями программного обеспечения, и достаточно TLS, разграничения доступа в админке и резервных копий. Требовать от владельца небольшого магазина сертифицированный СКЗИ на сервере - оверинжиниринг, за который платит сам магазин, а не безопасность его клиентов.
Клиника или медицинский центр работает со специальными категориями данных - диагнозами, результатами анализов, историей болезни. Здесь ситуация обратная: даже небольшая клиника с личным кабинетом пациента рискует получить УЗ-2 или УЗ-1, и вопрос СКЗИ встает всерьез, особенно если есть удаленный доступ врачей или обмен данными с лабораторией.
Школа или детский сад обрабатывает данные детей, но чаще всего это иные категории - ФИО, дата рождения, класс, а не биометрия и не диагнозы. Требования к шифрованию здесь обычно ближе к сценарию интернет-магазина, чем к сценарию клиники, если, конечно, в здании не установлена система прохода по отпечатку пальца или система распознавания лиц на входе - тогда данные становятся биометрическими, и разговор о криптографии начинается заново.
Самозанятый или небольшая студия с базой из полусотни клиентов в CRM обычно попадает в самый мягкий уровень защищенности, и требование ставить сертифицированное СКЗИ для такого объема данных избыточно, что не отменяет обязанности вести базовую гигиену: пароли, доступ по ролям, актуальные обновления. Минимальный набор требований для такого случая разобран в материале самозанятый и персональные данные клиентов.
Сайт вакансий или HR-сервис, который принимает резюме, получает не только контакты, но иногда и данные о здоровье или судимости, если это указано в самом резюме соискателя. Отдельно хранить и обрабатывать такие поля стоит осторожнее, чем остальную базу кандидатов, потому что именно они поднимают уровень защищенности всей системы, а не только одной анкеты.
Страховая компания, финтех-сервис или любой оператор, работающий по требованию крупного корпоративного заказчика, часто получает требование о СКЗИ не от закона напрямую, а от технического задания партнера - банки и госструктуры нередко закладывают конкретный класс криптозащиты в договор еще до того, как встал вопрос о фактическом уровне защищенности исполнителя.
Сколько стоит сертифицированное СКЗИ для персональных данных
Бюджет на криптографическую защиту редко укладывается в одну цифру, потому что складывается из нескольких статей, и часть из них - не разовая покупка, а повторяющиеся расходы.
Лицензия на сертифицированное СКЗИ для рабочей станции или сервера - первая и самая заметная статья. Для распространенных на рынке продуктов вроде КриптоПро CSP цена лицензии на одно рабочее место обычно измеряется несколькими тысячами рублей, а на сервер - существенно дороже, и цена растет вместе с классом защиты: КС1 дешевле, чем КС2 или КС3.
Вторая статья - аппаратные средства, если того требует модель угроз: токены и смарт-карты для хранения ключей, иногда аппаратные модули криптографии для серверной инфраструктуры. Это разовая закупка, но с горизонтом замены в несколько лет.
Третья статья - внедрение и настройка. СКЗИ не ставится по инструкции из интернета за час: нужен специалист, который свяжет его с существующей инфраструктурой, настроит ключевое хозяйство, проверит совместимость с остальным программным обеспечением. Разброс в стоимости работ здесь самый большой и зависит от того, донастраивается готовая система или проектируется новая.
Четвертая статья - продление и поддержка. Сертификаты соответствия и лицензии на СКЗИ не выдаются навсегда, продукт нужно обновлять, а иногда и переаттестовывать систему при существенном изменении инфраструктуры.
Пятая, часто забываемая статья - обучение и организационные меры вокруг СКЗИ: назначение ответственного за криптографическую защиту, регламент работы с ключами, журнал учета носителей ключевой информации. Без этого даже правильно купленное и установленное СКЗИ не защитит от претензий на проверке, потому что инспектора интересует не только факт наличия программы, но и порядок ее эксплуатации.
Сопоставив все статьи, разумно сначала честно ответить на вопрос, нужен ли сертифицированный СКЗИ вообще - для этого и существует модель угроз, - и только потом переходить к выбору конкретного продукта и бюджета на его внедрение.
Отдельно стоит сказать о разнице между разовым и постоянным бюджетом. Разовая закупка лицензий и настройка выглядят пугающе на старте, но именно повторяющиеся статьи - продление, поддержка, замена токенов при увольнении сотрудников - в перспективе двух-трех лет обычно перевешивают первоначальную цену внедрения. Закладывать в бюджет только покупку без учета обслуживания - типичная причина, по которой компании потом экономят на продлении и приходят к проверке с просроченным сертификатом соответствия.
Как снизить требования, изменив модель угроз
Самый частый вопрос от бизнеса звучит не как поставить СКЗИ, а как обойтись без него законно. Ответ есть, и он не про поиск лазейки, а про честную работу с документами.
Модель угроз - не формальность для проверяющих, а инструмент, который определяет, какие меры защиты действительно нужны системе. Если модель составлена шаблонно, под копирку с чужого сайта, она либо завышает требования и заставляет платить за лишнее, либо занижает их и создает риск при проверке. В обоих случаях цена ошибки - деньги: либо переплата за СКЗИ, который не нужен по факту архитектуры системы, либо штраф за отсутствие мер, которые нужны были, но их не увидели.
Снижение требований законным путем работает так. Часть мер, формально относящихся к криптографии, можно закрыть архитектурными решениями, которые убирают саму угрозу, а не маскируют ее. Если данные не хранятся на стороне оператора, а передаются напрямую в сертифицированную систему подрядчика - например, платежные данные уходят к процессинговому центру, а не оседают в базе интернет-магазина, - оператор снимает с себя часть требований просто потому, что у него больше нет соответствующего актива для защиты. Если удаленный доступ к базе закрыт для всех, кроме доверенной сети офиса, а не открыт в интернет, тип актуальных угроз в модели меняется, и вместе с ним меняется набор обязательных мер.
Пример из практики: небольшой сервис онлайн-записи хранил в одной таблице контакты клиентов и комментарии администратора о состоянии здоровья, которые вносились для удобства персонала. Формально это превращало всю базу в систему со специальными категориями данных и поднимало требования сразу на два уровня. После того как поле с комментариями вынесли в отдельную таблицу с ограниченным доступом, а модель угроз пересчитали заново, требование о сертифицированном СКЗИ осталось только для этой узкой части системы, а не для всего сервиса.
Разграничение категорий данных - еще один рабочий инструмент. Если система хранит вперемешку общие контактные данные и данные о здоровье, весь массив автоматически подтягивается под требования для специальных категорий. Разнесение по разным базам с разным уровнем доступа иногда позволяет закрыть повышенными мерами только действительно чувствительный сегмент, а не всю систему целиком.
Все это работает только при одном условии: изменения должны быть реальными, а не нарисованными в документе. Проверяющий, который видит модель угроз, где на бумаге данные не покидают периметр, а по факту сотрудники работают через личную почту и облачные диски без всякого контроля, зафиксирует нарушение куда охотнее, чем если бы модель отражала реальность и требовала СКЗИ. Разобраться, что вообще считается информационной системой персональных данных в вашем случае и какие у нее границы, стоит с базового материала классификация ИСПДн и определение категории системы.
Типичные ошибки при внедрении СКЗИ
На практике поставщики доработок и штатные айтишники наступают на одни и те же грабли.
Первая ошибка - подмена сертифицированного средства обычным шифрованием. Штатное шифрование диска в операционной системе или встроенное шифрование облачного провайдера - хорошая мера безопасности, но не СКЗИ в смысле профильных приказов, если оно не сертифицировано отдельно. Указывать его в документах как выполнение требования о криптографической защите - ошибка, которая всплывает на первой же серьезной проверке.
Вторая ошибка - покупка лицензии без настройки ключевого хозяйства. Программа стоит на сервере, но ключи генерируются и хранятся без соблюдения регламента, без назначенного ответственного, без журнала. Формально СКЗИ есть, по факту процесс не выстроен, и это тоже фиксируется как нарушение.
Третья ошибка - несоответствие класса СКЗИ реальной модели угроз. Иногда ставят избыточно мощный класс просто на всякий случай, тратя бюджет без необходимости. Иногда наоборот - берут самый дешевый вариант, который не закрывает угрозы, зафиксированные в собственном же документе компании.
Четвертая ошибка - забытое продление. Сертификат соответствия на СКЗИ имеет срок действия, лицензия требует продления, а на практике про это вспоминают только тогда, когда приходит запрос от регулятора.
Пятая ошибка - криптография без остальных организационных мер. СКЗИ не работает в вакууме: если у системы нет модели угроз, не назначен ответственный за защиту персональных данных, не ведется учет носителей, наличие даже самого сертифицированного программного обеспечения не спасает при проверке, потому что инспектор смотрит на комплекс мер, а не на один пункт.
Шестая ошибка - расчет на то, что провайдер хостинга или облако сами все закроют по умолчанию. Инфраструктурный провайдер обычно отвечает за физическую защиту и часть организационных мер на своей стороне, но применение сертифицированного СКЗИ для конкретной информационной системы персональных данных - обязанность оператора, и переложить ее на подрядчика одним пунктом в договоре не получится, если функции сторон не разграничены письменно и подробно.
Что делать: порядок действий
Прежде чем покупать лицензии, разумно пройти шаги по порядку, а не с середины.
- Определить, есть ли у компании информационная система персональных данных вообще, и какие данные она обрабатывает - специальные, биометрические, общедоступные или иные.
- Составить или актуализировать модель угроз, честно оценив реальные каналы передачи и хранения данных, а не переписав образец из интернета.
- Определить уровень защищенности по постановлению 1119, опираясь на модель угроз, категорию данных и число субъектов.
- Проверить, требует ли определенный уровень применения сертифицированных средств криптографической защиты, и если да - для каких именно процессов, а не для всей инфраструктуры целиком.
- Там, где криптография не обязательна, закрыть риски организационными мерами и стандартным TLS, не покупая лишнего.
- Там, где она обязательна, подобрать класс СКЗИ под конкретную угрозу, а не под максимальный запас прочности, и заложить бюджет не только на лицензию, но и на внедрение, обучение и продление.
- Закрепить порядок работы с ключами и назначить ответственного - без этого даже правильно выбранное СКЗИ не защитит на проверке.
Для многих компаний вопрос решается не покупкой софта, а точной перепиской документов и настройкой сайта под фактическую архитектуру данных, а не под усредненный шаблон - с этого обычно начинается доработка сайта и документов под требования 152-ФЗ.
Частые вопросы
Достаточно ли обычного SSL-сертификата вместо криптозащиты?
Для большинства сайтов - да, обычный TLS-сертификат защищает передачу данных между браузером и сервером и покрывает организационные требования к шифрованию. Но это не сертифицированное СКЗИ ФСБ: если модель угроз для конкретной системы требует именно сертифицированного средства криптографической защиты, обычный TLS его не заменяет.
Когда сертифицированный СКЗИ обязателен по закону?
Зависит от уровня защищенности по постановлению 1119: для УЗ-1 и УЗ-2, где обрабатываются специальные категории данных - о здоровье, судимости, национальности, - применение СКЗИ практически неизбежно. Для УЗ-3 и УЗ-4, характерных для типового сайта-визитки или интернет-магазина, обычно достаточно организационных мер и TLS.
Сколько стоит внедрение СКЗИ для персональных данных?
Бюджет складывается из нескольких статей: лицензия на рабочее место или сервер, аппаратные токены при необходимости, настройка и внедрение специалистом, а также регулярное продление сертификатов и лицензий. Повторяющиеся статьи - продление, поддержка, замена токенов при увольнении сотрудников - в перспективе двух-трех лет обычно перевешивают цену первоначального внедрения.
Можно ли законно снизить требования к криптозащите?
Да, изменив архитектуру, а не документы для вида: если данные не хранятся у оператора, а уходят напрямую в сертифицированную систему подрядчика, или удаленный доступ закрыт для всех, кроме доверенной сети, тип актуальных угроз в модели меняется вместе с набором обязательных мер. Изменения должны быть реальными, а не нарисованными на бумаге.
