Шифрование каналов связи с сервером персональных данных по 152-ФЗ

152-ФЗ требует защищать персональные данные не только там, где они хранятся, но и на пути от пользователя или сотрудника до сервера — то есть шифровать каналы связи. Если данные лежат в зашифрованном виде на диске, но передаются по открытому каналу, злоумышленник может перехватить их «на лету», и формально это тоже будет утечкой, за которую отвечает оператор персональных данных.

Разве шифрования на сервере недостаточно?

Недостаточно, потому что это защита разных этапов жизни данных. Шифрование на диске (шифрование «при хранении») защищает базу от кражи носителя или несанкционированного доступа к файлам на самом сервере. А данные ведь ещё нужно туда доставить: клиент вводит номер телефона в форму на сайте, менеджер открывает карточку клиента в 1С, бухгалтер выгружает реестр сотрудников. На всех этих отрезках информация движется по сети — и если канал не защищён, её можно перехватить между отправителем и сервером, даже не взламывая саму базу.

Именно поэтому в нормативных документах, на которые опирается 152-ФЗ, отдельно прописаны требования к защите каналов передачи: это не «дополнительная опция», а обязательный элемент системы защиты персональных данных наравне с антивирусом, разграничением доступа и резервным копированием.

Какие технологии обычно используют для защиты канала?

Чаще всего применяют комбинацию нескольких инструментов:

• TLS/SSL — протокол, который шифрует трафик между браузером или приложением и сервером. Именно он отвечает за замочек в адресной строке браузера и префикс https;
• VPN — защищённый туннель для удалённого подключения сотрудников к внутренней сети или серверу компании;
• SSH — протокол для безопасного удалённого администрирования серверов, шифрует сессию администратора;
• сертифицированные СКЗИ — средства криптографической защиты информации, прошедшие сертификацию ФСБ, для наиболее чувствительных сценариев.

Интересный и широко известный факт: протокол, который лёг в основу современного TLS, изначально назывался SSL и был разработан ещё в 1990-х годах компанией Netscape для защиты онлайн-платежей в браузере. С тех пор он несколько раз переработан, но базовая идея — шифровать соединение между клиентом и сервером — осталась той же и стала стандартом де-факто для всего интернета.

Обязательно ли использовать именно сертифицированные ФСБ СКЗИ?

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

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

Как быть, если сотрудники работают с сервером персональных данных удалённо?

Это одна из самых частых зон риска. Сотрудник подключается к серверу компании из дома, из кафе, через мобильный интернет — и если подключение идёт напрямую, без VPN, по незащищённому Wi-Fi, канал становится уязвимым местом всей системы защиты. Даже самый надёжный сервер не спасёт, если пароль администратора или сессия передаются открытым текстом.

Базовый набор мер для удалённой работы обычно включает:

• обязательное подключение через VPN перед доступом к серверу с персональными данными;
• использование SSH с ключами доступа вместо простых паролей для администрирования;
• запрет доступа к серверу по незащищённым протоколам вроде обычного FTP или HTTP без шифрования;
• двухфакторную аутентификацию для входа в систему удалённого доступа.

Что грозит компании, если канал связи оказался незащищён?

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

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

Как понять, что канал связи с сервером защищён правильно?

Есть несколько практических индикаторов, которые можно проверить самостоятельно или с помощью технического специалиста:

• сайт и все формы, где вводятся персональные данные, работают только по https, без возможности переключиться на незащищённый http;
• доступ администраторов к серверу возможен только через VPN или SSH с ключами, а не по прямому подключению с паролем;
• используемые версии протоколов TLS актуальны — устаревшие версии SSL и ранние версии TLS считаются небезопасными и не должны применяться;
• сертификаты TLS действительны и обновляются вовремя, а не просрочены.

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

Как с этим помогает «Клауд АйСи»?

Для компаний, которым важно закрыть требования 152-ФЗ, но нет собственного штата специалистов по информационной безопасности, «Клауд АйСи» предоставляет серверы и облачные сервисы с уже настроенными защищёнными каналами связи: подключение по протоколам с актуальным шифрованием, поддержка VPN для удалённого администрирования и корректно настроенные сертификаты для сайтов и сервисов. Это снимает с бизнеса часть технической нагрузки и позволяет сосредоточиться на самих бизнес-процессах, а не на тонкостях настройки криптографии.

С чего начать, если защита каналов ещё не настроена?

Разумный порядок действий такой: сначала определить уровень защищённости информационной системы и составить (или актуализировать) модель угроз, затем на основе этого выбрать конкретные технические средства — VPN, TLS, SSH, при необходимости сертифицированные СКЗИ. После внедрения стоит провести проверку настроек и включить регулярный контроль в общий план мероприятий по защите персональных данных, наравне с резервным копированием и контролем доступа.

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