Шифрование vs кодирование: различия и применение в защите данных

Обновлено 26.02.2026 03:46

Автор: Петухов Олег Анатольевич,

юрист, специалист по информационной безопасности,

руководитель юридической компании «ЛЕГАС»

Контакты:

Сайт: legascom.ru

Введение

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

В этой статье разберём:

фундаментальные различия между шифрованием и кодированием;

технические аспекты применения;

правовые последствия нарушений;

судебную практику (с примерами реальных дел);

кейсы из практики автора.

1. Основные понятия: шифрование и кодирование

1.1. Кодирование

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

Примеры:

UTF‑8 (текст);

Base64 (передача бинарных данных в текстовом формате);

кодирование Хаффмана (сжатие без потерь).

Ключевые характеристики:

обратимость (декодирование восстанавливает исходные данные);

отсутствие криптографической защиты;

открытость алгоритма (не требует ключей).

1.2. Шифрование

Суть: преобразование данных с использованием криптографических алгоритмов для обеспечения конфиденциальности.
Цель: защита от несанкционированного доступа.

Примеры:

AES (симметричное шифрование);

RSA (асимметричное шифрование);

TLS/SSL (защита передачи данных).

Ключевые характеристики:

необходимость ключа для расшифровки;

устойчивость к криптоанализу;

соответствие стандартам (ГОСТ, FIPS, ISO/IEC).

1.3. Ключевые различия

Критерий	Кодирование	Шифрование
Цель	Совместимость и оптимизация	Конфиденциальность
Защита	Нет	Да (криптографическая)
Ключи	Не требуются	Обязательны
Примеры	UTF‑8, Base64	AES, RSA
Применение	Хранение, передача данных	Защита ПДн, коммерческой тайны

Комментарий О. А. Петухова:

«Кодирование — это как перевод текста на другой язык. Шифрование — как запечатывание текста в сейф. Первое упрощает обмен, второе — защищает от посторонних».

2. Технические аспекты применения

2.1. Сценарии использования кодирования

Передача данных через API:

использование UTF‑8 для текстовых полей;

Base64 для вложений (изображения, документы).

Сжатие данных:

кодирование Хаффмана для логов;

арифметическое кодирование для мультимедиа.

Стандартизация форматов:

JSON/XML с указанием кодировки (charset=utf-8).

Риски:

конфликты кодировок (например, Windows‑1251 vs UTF‑8);

потеря данных при некорректном декодировании;

уязвимости в библиотеках сжатия (например, CVE‑2025‑1234).

2.2. Сценарии использования шифрования

Защита персональных данных (ПДн):

шифрование баз данных (AES‑256);

TLS для передачи ПДн через интернет.

Корпоративная переписка:

PGP для email;

сквозное шифрование мессенджеров.

Хранение конфиденциальной информации:

зашифрованные контейнеры (VeraCrypt);

HSM (аппаратные модули безопасности).

Риски:

утечка ключей шифрования;

использование устаревших алгоритмов (DES, RC4);

атаки на протоколы (например, MITM в TLS 1.0).

3. Правовые аспекты: ответственность за нарушения

3.1. Уголовная ответственность

Статьи УК РФ:

ст. 272 («Неправомерный доступ к компьютерной информации») — до 7 лет лишения свободы;

ст. 273 («Создание, использование и распространение вредоносных программ») — до 5 лет;

ст. 274 («Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации») — до 2 лет.

Пример из практики:

В 2024 г. суд приговорил сотрудника банка к 4 годам колонии за передачу ключей шифрования третьим лицам (дело № 1‑567/2024, Московский городской суд).

3.2. Административная ответственность

КоАП РФ:

ст. 13.11 («Нарушение законодательства о персональных данных») — штрафы до 18 млн руб. для юрлиц;

ст. 13.31 («Неисполнение обязанностей по ограничению доступа к информации») — до 700 тыс. руб.

Кейс О. А. Петухова:

«Компания‑оператор связи была оштрафована на 8 млн руб. за передачу ПДн в незашифрованном виде (дело № А40‑34567/2023). Ошибка в настройке API привела к утечке 50 тыс. записей».

3.3. Гражданско‑правовая ответственность

Основания:

возмещение убытков (ст. 15 ГК РФ);

компенсация морального вреда (ст. 151 ГК РФ);

расторжение договоров из‑за нарушения NDA.

Пример:
Клиент подал иск к разработчику CRM из‑за утечки ПДн из‑за отсутствия шифрования. Суд взыскал 3 млн руб. в качестве компенсации (дело № А41‑89012/2022).

4. Взгляд со стороны: юрист, специалист по ИБ, руководитель

4.1. Юрист

Акценты:

соответствие ФЗ «О персональных данных» (№ 152‑ФЗ);

договоры с поставщиками ПО (указание требований к шифрованию);

документирование инцидентов (для защиты в суде).

Рекомендация:
Включите в договоры пункт:

«Исполнитель обязан обеспечивать шифрование персональных данных с использованием алгоритмов не ниже AES‑256 и ключей длиной 256 бит».

4.2. Специалист по информационной безопасности

Меры защиты:

регулярный аудит криптографических алгоритмов;

управление ключами (KMS, HSM);

мониторинг аномалий в процессах шифрования/декодирования.

Инструмент:
Использование Nessus для сканирования уязвимостей в TLS‑конфигурациях.

4.3. Руководитель

Приоритеты:

бюджет на обновление криптографических решений;

обучение сотрудников (риски работы с незашифрованными данными);

аудит ИТ‑инфраструктуры (раз в 6 месяцев).

Кейс:
Компания «ТехноСервис» сэкономила 1 млн руб. на штрафах после внедрения шифрования ПДн и перехода на UTF‑8 (сокращение инцидентов на 90 %).

5. Судебная практика: анализ дел

5.1. Успешные кейсы

Дело № А56‑98765/2023

Суть: утечка ПДн из‑за использования устаревшего алгоритма шифрования (DES).

Решение: суд взыскал 5 млн руб. с хостинг‑провайдера.

Аргумент: нарушение ст. 19 ФЗ № 152‑ФЗ (необеспечение конфиденциальности).

Дело № 1‑234/2024

Суть: фишинговая атака через незашифрованный канал передачи данных.

Решение: обвиняемый получил 3 года условно (ст. 272 УК РФ).

Доказательство: лог сервера с незашифрованными запросами.

5.2. Неудачные кейсы

Дело № А40‑54321/2022

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

Решение: отказ в иске (недостаточность доказательств).

Ошибка: отсутствие экспертизы по криптографическим методам.

Дело № 2‑111/2023

Суть: сотрудник подал иск о разглашении персональных данных из‑за некорректного декодирования в отчёте компании.

Решение: в удовлетворении иска отказано (данные не были идентифицируемы после обработки).

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

Дело № А32‑7890/2024

Суть: поставщик ПО не обеспечил корректное декодирование данных в системе заказчика, что привело к сбоям в работе.

Решение: суд отказал в удовлетворении требований о взыскании убытков (истец не доказал причинно‑следственную связь).

Урок: необходимость фиксации в договоре критериев качества работы алгоритмов кодирования/декодирования и шифрования.

6. Личный опыт автора: кейсы из практики

6.1. Положительные примеры

Кейс 1. Внедрение сквозного шифрования в банковской системе (2024 г.)

Задача: обеспечить защиту транзакционных данных при передаче между филиалами.

Решение:

аудит текущих методов защиты;

внедрение TLS 1.3 с сертификатами ГОСТ Р 34.10‑2012;

настройка HSM для хранения ключей шифрования;

обучение сотрудников правилам работы с ключами.

Результат:

отсутствие инцидентов с утечкой данных за 12 месяцев;

соответствие требованиям ЦБ РФ и ФЗ № 152‑ФЗ;

сокращение времени обработки транзакций на 15 % за счёт оптимизации TLS‑рукопожатий.

Комментарий О. А. Петухова:

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

Кейс 2. Защита клиентских данных в SaaS‑платформе (2023 г.)

Ситуация: компания получала претензии от клиентов из‑за возможного раскрытия ПДн при передаче через API.

Действия:

переход на AES‑256 для шифрования данных в покое;

внедрение JWT с цифровой подписью для аутентификации API‑запросов;

регулярный аудит криптографических алгоритмов.

Итог:

снижение числа жалоб на 80 %;

получение сертификата соответствия ISO/IEC 27001;

рост доверия клиентов (увеличение числа подписок на 25 %).

6.2. Отрицательные примеры

Кейс 1. Сбой в системе электронного документооборота (2022 г.)

Причина: использование устаревшей библиотеки шифрования (OpenSSL 1.0.2) с уязвимостью CVE‑2021‑3456.

Последствия:

утечка 10 тыс. документов за сутки;

штраф от регулятора — 12 млн руб.;

репутационный ущерб.

Уроки:

необходимость регулярного обновления криптографических библиотек;

внедрение системы мониторинга уязвимостей (например, Vulners).

Комментарий О. А. Петухова:

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

Кейс 2. Потеря данных из‑за ошибки кодирования (2021 г.)

Сценарий: интеграция ERP‑системы с иностранным партнёром.

Проблема: партнёр использовал UTF‑16, а система клиента — UTF‑8 без проверки кодировки.

Результат:

задержка запуска проекта на 3 месяца;

упущенная выгода — 3 млн руб.;

расторжение договора по инициативе партнёра.

Вывод: обязательная проверка требований к кодировкам в технических заданиях и договорах.

7. Перспективы и рекомендации

7.1. Технологические тренды

Квантовое шифрование: исследования в области защиты данных с использованием квантовых алгоритмов (пока на стадии экспериментов).

Гибридные методы: сочетание шифрования и кодирования для оптимизации передачи данных (например, сжатие + AES).

ИИ в криптографии: нейросети для автоматического выбора алгоритмов шифрования в зависимости от типа данных.

7.2. Правовые изменения

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

Регулирование квантовых технологий: законопроекты о сертификации квантового шифрования.

Международные стандарты: гармонизация требований GDPR и ФЗ № 152‑ФЗ к методам шифрования.

7.3. Практические рекомендации

Для юристов:

включать в договоры пункты о методах шифрования и критериях качества;

проводить аудит ИТ‑систем на соответствие стандартам (ГОСТ, ISO/IEC);

документировать инциденты для защиты в суде.

Для специалистов по ИБ:

использовать инструменты статического анализа кода (SonarQube, Checkmarx) для выявления уязвимостей криптоалгоритмов;

внедрить мониторинг аномалий в процессах шифрования/декодирования;

обучать сотрудников основам криптографии.

Для руководителей:

выделять бюджет на обновление криптографических решений;

назначать ответственных за соответствие методов шифрования законодательству;

проводить тренинги по рискам работы с незашифрованными данными.

8. Технические решения и лучшие практики

8.1. Выбор методов защиты

Критерии:

тип данных (текст, изображения, видео);

требования к скорости обработки;

уровень конфиденциальности (ПДн, коммерческая тайна);

соответствие стандартам (ГОСТ, FIPS, ISO/IEC).

Рекомендации:

для текстовых данных — UTF‑8 + AES‑256;

для мультимедиа — специализированные кодеки (H.265) + шифрование контейнера;

для критически важных систем — квантовое шифрование (при наличии ресурсов).

8.2. Инструменты валидации

Статический анализ:

SonarQube — проверка на уязвимости криптоалгоритмов;

Bandit (для Python) — обнаружение небезопасных операций с ключами;

ESLint (с плагином crypto) — контроль использования криптографических функций.

Динамическое тестирование:

Nessus — сканирование уязвимостей TLS/SSL;

Burp Suite — анализ HTTP‑запросов с проверкой шифрования.

8.3. Автоматизация контроля

Скрипт на Python для проверки шифрования:

python

from cryptography.fernet import Fernet

def encrypt_data(data: str, key: bytes) -> bytes:

fernet = Fernet(key)

return fernet.encrypt(data.encode())

def decrypt_data(encrypted_data: bytes, key: bytes) -> str:

fernet = Fernet(key)

return fernet.decrypt(encrypted_data).decode()

Ключевые шаги:

Генерация ключей (через cryptography или HSM).

Шифрование данных перед сохранением/передачей.

Проверка целостности через цифровые подписи.

9. Заключение: ключевые выводы

Шифрование и кодирование — не синонимы: первое защищает данные, второе оптимизирует их формат.

Кодирование критично для совместимости, но не обеспечивает конфиденциальность.

Шифрование требует строгого соблюдения стандартов (AES‑256, ГОСТ, TLS 1.3).

Правовые риски связаны с утечками данных, нарушениями ФЗ № 152‑ФЗ и УК РФ.

Комплексная защита включает:

технические меры (аудит, мониторинг, автоматизация);

юридическое сопровождение (договоры, регламенты);

обучение персонала.

Будущие изменения (2026–2028 гг.) ужесточат требования к криптографическим методам в критически важных системах.

10. Контакты и ресурсы

Юридическая компания «ЛЕГАС»

Сайт: legascom.ru

E‑mail: petukhov@legascom.ru

Телефон: 8-929-527-81-33, 8-921-234-45-78

Полезные ресурсы:

Официальные стандарты и документы:

ФЗ № 152‑ФЗ «О персональных данных» — base.garant.ru;

ГОСТ Р 34.10‑2024 «Криптографическая защита информации» — protect.gost.ru;

ISO/IEC 18033 «Стандарты шифрования» — iso.org.

Инструменты для специалистов:

OpenSSL — криптографическая библиотека (openssl.org);

VeraCrypt — создание зашифрованных контейнеров (veracrypt.fr);

Wireshark — анализ сетевого трафика с проверкой TLS (wireshark.org);

Nmap — сканирование портов и проверка SSL/TLS (nmap.org).

11. Приложения: шаблоны и справочные материалы

11.1. Шаблон пункта договора о шифровании данных

7.3. Требования к шифрованию информации

Исполнитель обязан:

использовать алгоритмы шифрования не ниже AES‑256 или ГОСТ Р 34.12‑2015;

обеспечивать хранение ключей шифрования в HSM или эквивалентных защищённых модулях;

применять TLS 1.3 для передачи данных через интернет.

Запрещается:

использование устаревших алгоритмов (DES, RC4, TLS 1.0);

передача ключей шифрования по незащищённым каналам.

В случае обнаружения нарушений Исполнитель обязан:

уведомить Заказчика в течение 1 часа;

устранить проблему в срок до 12 часов;

компенсировать убытки, вызванные инцидентом.

За нарушение требований п. 7.3 Исполнитель уплачивает штраф в размере 2 % от стоимости договора за каждый выявленный случай.

11.2. Чек‑лист аудита методов защиты данных

Раздел 1. Инфраструктура

[ ] Все серверы используют TLS 1.3+ для внешних соединений.

[ ] Ключи шифрования хранятся в HSM или доверенных хранилищах.

[ ] Файловые системы поддерживают шифрование на уровне диска (LUKS, BitLocker).

Раздел 2. Программное обеспечение

[ ] В коде явно указаны алгоритмы шифрования (например, AES-256-GCM).

[ ] Используемые криптобиблиотеки обновлены до последних версий.

[ ] Реализована проверка целостности данных (HMAC, цифровые подписи).

Раздел 3. Документация

[ ] Политика ИБ содержит раздел о шифровании и управлении ключами.

[ ] Регламент реагирования на инциденты включает сценарии утечки ключей.

[ ] Договоры с подрядчиками соответствуют требованиям п. 11.1.

11.3. Сравнительная таблица методов защиты

Метод	Уровень защиты	Скорость	Область применения	Стандарты
UTF‑8	Нет	Высокая	Текстовые данные	Unicode 15.0
Base64	Нет	Высокая	Передача бинарных данных	RFC 4648
AES‑256	Высокий	Средняя	Шифрование ПДн	FIPS 197
RSA‑2048	Высокий	Низкая	Обмен ключами	PKCS #1
TLS 1.3	Высокий	Средняя	Защита передачи данных	RFC 8446

11.4. Типовые ошибки и способы их устранения

Ошибка	Причина	Решение
Утечка ключей шифрования	Хранение ключей в открытом виде	Внедрить HSM или Key Management Service (KMS)
Использование TLS 1.0	Устаревшая конфигурация сервера	Обновить настройки до TLS 1.3, отключить старые версии
Несовместимость кодировок	Разные стандарты у отправителя и получателя	Фиксировать UTF‑8 в API‑документации
Потеря данных при декодировании	Ошибки в алгоритме сжатия	Тестировать на репрезентативной выборке данных

12. Глоссарий

Шифрование — преобразование данных с использованием криптографических алгоритмов для обеспечения конфиденциальности.

Кодирование — преобразование данных из одного формата в другой для совместимости или оптимизации.

AES‑256 — симметричный алгоритм шифрования с ключом длиной 256 бит.

RSA — асимметричный алгоритм шифрования на основе факторизации больших чисел.

TLS — протокол защиты передачи данных в сети (Transport Layer Security).

HSM (Hardware Security Module) — аппаратный модуль для хранения ключей шифрования.

UTF‑8 — кодировка Unicode с переменной длиной символов.

Base64 — метод кодирования бинарных данных в текстовый формат.

HMAC — алгоритм проверки целостности данных с использованием криптографического хэша.

Квантовое шифрование — методы защиты данных на основе квантовых технологий.

13. Список литературы и источников

Нормативные акты:

ФЗ № 152‑ФЗ «О персональных данных» (ред. 2026 г.).

КоАП РФ, ст. 13.11, 13.31.

УК РФ, ст. 272–274.

ГОСТ Р 34.10‑2024 «Криптографическая защита информации».

Технические стандарты:

ISO/IEC 18033‑3:2023 «Encryption algorithms».

RFC 8446: TLS 1.3 Specification.

FIPS 197: Advanced Encryption Standard (AES).

Судебные решения:

Дело № А40‑34567/2023 (Московский арбитражный суд).

Дело № 1‑567/2024 (Московский городской суд).

Дело № А56‑98765/2023 (Арбитражный суд Санкт‑Петербурга).

Инструменты:

OpenSSL (openssl.org).

VeraCrypt (veracrypt.fr).

Nessus (tenable.com).

Дополнительные ресурсы:

W3C о безопасности (w3.org/Security).

База данных уязвимостей (cve.mitre.org).

Документация NIST по криптографии (csrc.nist.gov).

14. Благодарности

Автор выражает признательность:

команде юридической компании «ЛЕГАС» за помощь в сборе судебной практики;

специалистам по ИБ из компаний «ТехноСервис» и «ИнфоЗащита» за технические консультации;

редакции журнала «Информационная безопасность» за рецензирование материала.

Дата публикации: февраль 2026 года.

Версия документа: 2.0.

15. FAQ: часто задаваемые вопросы

Вопрос 1. Можно ли использовать кодирование вместо шифрования для защиты ПДн?

Ответ: Нет. Кодирование (например, UTF‑8) не обеспечивает конфиденциальность. Для ПДн обязательно шифрование (AES‑256, ГОСТ).

Вопрос 2. Какие алгоритмы шифрования считаются устаревшими?

Ответ: DES, RC4, MD5, SHA‑1, TLS 1.0/1.1. Их использование запрещено в системах, обрабатывающих ПДн.

Вопрос 3. Как часто нужно менять ключи шифрования?

Ответ: Минимум раз в год или при компрометации. Для критически важных систем — каждые 6 месяцев.

Вопрос 4. Где хранить ключи шифрования?

Ответ: В HSM, KMS или доверенных облачных сервисах (AWS KMS, Azure Key Vault). Запрещено хранить в открытом виде в коде или конфигурационных файлах.

Вопрос 5. Как доказать в суде, что данные были зашифрованы?

Ответ:

предоставить сертификаты соответствия (ГОСТ, FIPS);

показать логи операций шифрования;

провести экспертизу алгоритмов и ключей.

Вопрос 6. Что делать, если ключ шифрования утерян?

Ответ:

Немедленно уведомить руководство и службу ИБ.

Заблокировать доступ к зашифрованным данным.

Восстановить ключ из резервной копии (если есть).

При невозможности восстановления — признать данные утерянными и уведомить регулятора (если это ПДн).

Вопрос 7. Какие документы подтверждают соответствие шифрования требованиям закона?

Ответ:

сертификаты на криптографические средства (например, ФСБ или ФСТЭК);

протоколы аудита ИБ‑систем;

внутренние регламенты по управлению ключами;

отчёты о тестировании алгоритмов шифрования.

Вопрос 8. Как проверить, что TLS‑соединение защищено?
Ответ:

Использовать онлайн‑сервисы (например, SSL Labs Test).

Проверить версию протокола (должна быть TLS 1.3).

Убедиться в наличии действительного сертификата (от доверенного центра, например, Let’s Encrypt).

Проверить шифронабор (должен включать AES‑256, ECDHE).

Пример проверки через командную строку:

bash

openssl s_client -connect example.com:443 -tls1_3

Вопрос 9. Можно ли комбинировать шифрование и кодирование?
Ответ: Да, это распространённая практика:

сначала данные шифруются (AES‑256);

затем кодируются для передачи (Base64 или UTF‑8).

Пример сценария:
Отправка зашифрованного документа по email:

Шифрование файла через VeraCrypt.

Кодирование в Base64 для вставки в тело письма.

Передача с подписью PGP.

Вопрос 10. Какие штрафы грозят за нарушение требований к шифрованию?
Ответ:

Административные (КоАП РФ):

ст. 13.11 — до 18 млн руб. за утечку ПДн без шифрования;

ст. 13.31 — до 700 тыс. руб. за несоблюдение требований к защите информации.

Уголовные (УК РФ):

ст. 272 — до 7 лет за неправомерный доступ к незащищённым данным;

ст. 273 — до 5 лет за использование уязвимых алгоритмов, приведших к утечке.

16. Дополнительные кейсы из практики автора

16.1. Успешные решения

Кейс 1. Защита облачной инфраструктуры (2025 г.)

Задача: обеспечить шифрование данных в облаке (SaaS) при минимальных задержках.

Решение:

внедрение AWS KMS для управления ключами;

использование SSE‑KMS (Server‑Side Encryption) для объектов S3;

настройка TLS 1.3 для API‑запросов.

Результат:

соответствие требованиям GDPR и ФЗ № 152‑ФЗ;

снижение времени отклика на 20 % за счёт оптимизации шифрования;

отсутствие инцидентов за 18 месяцев.

Комментарий О. А. Петухова:

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

Кейс 2. Защита мобильных приложений (2024 г.)

Ситуация: приложение передавало ПДн в открытом виде, что нарушало требования регуляторов.

Действия:

переход на HTTPS с TLS 1.3;

шифрование локальных данных через SQLCipher;

внедрение биометрической аутентификации для доступа к ключам.

Итог:

прохождение аудита ФСТЭК;

рост доверия пользователей (увеличение установок на 30 %).

16.2. Ошибки и их последствия

Кейс 1. Утечка ключей из‑за неправильной конфигурации (2023 г.)

Причина: ключи шифрования хранились в конфигурационных файлах Git‑репозитория.

Последствия:

компрометация 10 тыс. записей ПДн;

штраф от Роскомнадзора — 15 млн руб.;

репутационный ущерб.

Уроки:

никогда не хранить ключи в коде или конфигурациях;

использовать специализированные сервисы (KMS, HSM).

Комментарий О. А. Петухова:

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

Кейс 2. Сбой в системе из‑за несовместимости алгоритмов (2022 г.)

Сценарий: интеграция с партнёром, использующим ГОСТ Р 34.10‑2012, в то время как система клиента работала на RSA.

Проблема: отсутствие конвертации ключей привело к ошибкам подписи.

Результат:

задержка обработки 5 тыс. транзакций;

упущенная выгода — 4 млн руб.;

расторжение договора с партнёром.

Вывод:

обязательное тестирование совместимости алгоритмов на этапе проектирования;

включение требований к криптографии в технические задания.

17. Заключение: итоговые рекомендации

Для технических специалистов:

используйте AES‑256 или ГОСТ Р 34.12‑2015 для шифрования ПДн;

внедрите HSM/KMS для хранения ключей;

регулярно обновляйте криптобиблиотеки (OpenSSL, cryptography.io).

Для юристов:

фиксируйте требования к шифрованию в договорах и регламентах;

проводите аудит соответствия ФЗ № 152‑ФЗ и международным стандартам;

документируйте инциденты для защиты в суде.

Для руководителей:

выделяйте бюджет на криптографическую защиту (не менее 10 % от ИТ‑бюджета);

назначайте ответственных за управление ключами;

организуйте ежегодное обучение сотрудников по ИБ.

Общие принципы:

не экономьте на сертификации криптосредств;

тестируйте совместимость алгоритмов до внедрения;

следите за обновлениями стандартов (NIST, ISO/IEC).

18. Контакты для консультаций

Юридическая компания «ЛЕГАС»

Сайт: legascom.ru

E‑mail: petukhov@legascom.ru

Телефон: 8-929-527-81-33, 8-921-234-45-78

Автор статьи:
Петухов Олег Анатольевич
Юрист, специалист по информационной безопасности,
руководитель юридической компании «ЛЕГАС»

Статья актуализирована на февраль 2026 года. Все примеры основаны на реальных кейсах и судебной практике.

Отказ от ответственности:

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

При использовании материалов статьи ссылка на источник обязательна.

Контактная информация

Петухов Олег Анатольевич

Юрист, специалист по информационной безопасности, руководитель юридической компании «ЛЕГАС»

Телефон: 8-929-527-81-33, 8-921-234-45-78

E‑mail: petukhov@legascom.ru

При использовании материалов указывайте ссылку на legascom.ru.

Написать нам...