Хеширование персональных данных позволяет заменить исходное значение результатом криптографического преобразования. Компании применяют этот механизм при проверке записей, сопоставлении клиентов и аутентификации. Однако даже стойкий алгоритм не гарантирует, что по полученному значению нельзя установить конкретного человека. Для казахстанского бизнеса вопрос особенно актуален после принятия в сентябре 2026 года специальных Правил применения методов маскирования и хеширования.
Когда хеширование действительно защищает данные
Хеш-функция преобразует исходную строку в значение фиксированной длины. Например, организация может вычислять хеш идентификатора вместо хранения самого идентификатора в отдельной аналитической таблице. При корректном применении криптографической функции вычислить исходный текст непосредственно по хешу практически невозможно. Но это не исключает подбор известных или вероятных исходных значений с последующим сравнением результатов.
Особенно уязвимы предсказуемые данные: ИИН, номера телефонов и другие идентификаторы, имеющие ограниченный набор возможных комбинаций. Если злоумышленник может последовательно вычислять хеши потенциальных значений, совпадение выдаст исходный идентификатор. Поэтому утверждение «данные захешированы, значит раскрыть личность невозможно» юридически и технически необоснованно.
Что изменилось в законодательстве Казахстана в 2026 году
Пункт 2 статьи 23 Закона РК «О персональных данных и их защите» предусматривает применение маскирования и хеширования в цифровых объектах. Приказом Заместителя Премьер-Министра — Министра искусственного интеллекта и цифрового развития РК от 3 сентября 2026 года № 535/НҚ утверждены специальные Правила. Приказ зарегистрирован 4 сентября 2026 года за № 39824 и опубликован в Эталонном контрольном банке НПА 9 сентября 2026 года. В соответствии с пунктом 4 приказа он вступает в силу по истечении десяти календарных дней после первого официального опубликования.
По пункту 9 Правил хеширование цифровых данных осуществляется с применением алгоритма в соответствии с СТ РК ГОСТ Р 34.11-2015. Это существенная деталь: внутренний ИТ-регламент должен оцениваться не только по общепринятой практике, но и по прямо названному национальному стандарту. Самовольная замена предусмотренного нормативным актом алгоритма популярной зарубежной реализацией без проверки соответствия создает правовой риск.
Пункт 10 Правил называет применение хеширования при хранении данных, если исходные значения не требуются, при проверке и сопоставлении данных, аутентификации и использовании персональных идентификаторов в цифровых системах. Пункт 11 требует выполнить преобразование до соответствующих операций, пункт 13 — использовать затем хешированное значение. При проектировании системы следует проверять, для каких конкретно операций исходные данные все же необходимы: механическое уничтожение оригинала без оценки функциональности может нарушить бизнес-процесс.
Хеширование — не то же самое, что обезличивание
Закон РК связывает обезличивание с невозможностью определить принадлежность персональных данных субъекту. Если у оператора остается таблица соответствий, исходная база либо иной доступный способ соотнести хеш с клиентом, одной замены идентификатора недостаточно для вывода о полном обезличивании. Даже без таблицы соответствий одинаковые детерминированные хеши позволяют связать записи между собой. Это создает риск повторной идентификации при объединении наборов данных.
Различайте три ситуации. При маскировании скрывается часть отображаемых сведений; при хешировании создается вычисляемое значение; при реальном обезличивании необходимо исключить определение принадлежности данных конкретному человеку. Правовой режим определяется не названием технической операции, а фактической возможностью идентификации и контекстом обработки.
Типичные ошибки при внедрении
Первая ошибка — вычислять одинаковые незащищенные хеши ИИН или телефонов во всех системах. Это позволяет сопоставлять сведения между разными базами. Вторая — хранить исходную таблицу и хеши в одном доступном контуре без разделения полномочий. Третья — считать соль универсальным способом защиты: индивидуальная соль затрудняет массовый перебор, но может мешать прямому сопоставлению записей; секретный ключ в конструкции типа HMAC снижает риск внешнего перебора, однако должен быть надежно защищен и отдельно оценен на соответствие применимым требованиям РК.
Четвертая ошибка — не регистрировать операции. Согласно пункту 14 Правил журнал должен содержать дату и время, вид операции, перечень хешированных данных, примененный метод, результат проверки корректности, сведения об исполнителе и, при наличии, об ответственном за организацию обработки. Журнал не должен превращаться в новый источник утечки: в нем следует фиксировать необходимую информацию без ненужного дублирования исходных идентификаторов.
Что проверить собственнику системы и ИТ-подрядчику
Руководителю полезно получить письменное описание целей хеширования и категорий данных, архитектуру потоков информации, описание алгоритмов и проверку соответствия стандарту, матрицу доступа, порядок хранения секретов, журналы операций и акты тестирования. Отдельно необходимо установить, какие подразделения и подрядчики могут связать хеш с человеком, передаются ли наборы данных третьим лицам и как прекращается доступ после окончания договора.
В договоре с разработчиком стоит закрепить требования к методам обработки, доступу к промышленной базе, тестированию на повторную идентификацию, сохранению журналов, устранению уязвимостей и уведомлению о выявленных инцидентах. Отсутствие таких условий затрудняет распределение договорной ответственности, хотя само по себе не освобождает собственника и оператора от предусмотренных законом обязанностей.
Как подтвердить соблюдение требований при проверке или споре
Полезны утвержденная политика обработки данных, техническое задание, описание конфигурации системы, отчеты проверок, доступные журналы операций, документы об изменении алгоритмов, подтверждения обучения персонала и сведения о доступе подрядчиков. При утечке значение имеет не декларация об использовании хешей, а реальная возможность подобрать значения, связать записи или получить исходную базу.
Оценка должна содержать обстоятельства инцидента, тип данных, модель угроз, возможности предполагаемого нарушителя и конкретные меры защиты. Техническое заключение не заменяет юридический анализ законности обработки, основания передачи данных, соблюдения прав субъекта и обязанностей при нарушении безопасности.
Практический пример: сопоставление клиентских баз
Компания решила выявить повторяющиеся записи клиентов в двух сервисах и передала подрядчику хешированные телефонные номера. Если оба сервиса использовали одинаковый алгоритм без дополнительной защиты, подрядчик может не видеть сами номера, но распознавать совпадающих клиентов. При наличии справочника известных номеров возрастает и риск восстановления значений путем подбора. Безопасный вариант требует проектирования ограниченного механизма сопоставления, договорного ограничения целей, защиты ключей и анализа возможности повторной идентификации. Конкретное решение должно одновременно отвечать требованиям приказа № 535/НҚ и задачам информационной безопасности.
Вопросы и ответы
Является ли хеш ИИН персональными данными?
Может являться, если по нему с учетом других доступных сведений возможно определить лицо или связать записи с определяемым человеком. Формат хеша сам по себе не решает вопрос.
Обязан ли бизнес использовать определенный стандарт?
Пункт 9 Правил, утвержденных приказом № 535/НҚ, прямо отсылает к СТ РК ГОСТ Р 34.11-2015. Применимость и реализацию следует проверять по конкретной системе.
Достаточно ли хеширования без ведения журнала?
Нет. Пункт 14 Правил предусматривает фиксацию определенного набора сведений об операциях хеширования.
Можно ли передавать хеши подрядчику без правового оформления?
Автоматического исключения из требований о защите персональных данных нет. Необходимо оценить идентифицируемость, законное основание обработки, объем доступа и договорные условия.
Как доказать риск повторной идентификации?
Помогают независимая техническая оценка, тесты на устойчивость к подбору, схема сопоставления баз, анализ доступа к исходным данным и документирование результатов.
Записаться на платную консультацию
Стоимость консультации — от 20 000 тенге, в зависимости от сложности вопроса.
Чтобы записаться, перейдите по ссылке ниже и выберите удобный способ связи.
