Контроль доступа к персональным данным (КДП) через ШЭП: как получать согласие субъекта при интеграции с госданными

Кратко: С 2022 года любое обращение к персональным данным гражданина в государственных информационных системах Казахстана должно проходить через государственный сервис контроля доступа к персональным данным (КДП). Практически это значит: прежде чем ваша система получит из ГБД ФЛ ФИО, адрес, состав семьи или доход человека, она обязана зафиксировать законное основание и/или получить согласие субъекта — и сделать это машинно, через КДП.

КДП — это не «ещё один справочник». Это обязательный слой-посредник (гейт согласия), который стоит перед большинством сервисов персональных данных в ШЭП. Ниже — как он устроен, что происходит на уровне сообщений, и почему для интегратора это одновременно юридическая защита и техническая головная боль, которую снимает интеграционный шлюз.

Статус в SmartConnect. КДП — перспективный элемент нашего каталога ШЭП: гейт согласия подключается по запросу под конкретный сценарий интегратора по той же архитектуре, что и уже действующие адаптеры (например, ГБД ФЛ и ГБД ЮЛ). Точный состав поддержанных каналов подтверждения, форма единого API, маппинг статусов и объём журналирования фиксируются при подключении по паспорту сервиса в Smart Bridge и условиям владельца данных. Ниже мы отделяем базовый функционал шлюза от того, что настраивается под сервис.

---

1. Что такое КДП и зачем он нужен

КДП (сервис контроля доступа к персональным данным) обеспечивает информационное взаимодействие между собственниками/операторами ИС и третьими лицами — с одной стороны, и субъектом персональных данных и уполномоченным органом — с другой, при доступе к персональным данным, содержащимся в государственных ИС.

Функции сервиса (по правилам функционирования):

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

Оператор сервиса — уполномоченный орган в сфере ИИ и цифрового развития. Юридическая основа — Закон РК «О персональных данных и их защите», правила функционирования и правила интеграции с госсервисом КДП.

Актуально (2026): приказом от 5 марта 2026 г. (вступил в силу 23 марта 2026 г.) правила обновлены: в состав персональных данных прямо включены биометрические данные, введён термин «автоматизированная обработка», а получение согласия описано через три канала — (1) проактивные сервисы (биометрия, ЭЦП, бумажное подтверждение), (2) режим логирования (доступ по законному основанию без предварительного согласия), (3) подтверждение через мобильное правительство (одноразовый код). Одноразовые пароли (OTP) по сетям мобильной связи в первых двух процессах для согласия использовать нельзя.

Вывод для интегратора: КДП — это точка, где встречаются право и техника. Пропустить её нельзя: без корректно оформленного согласия/основания обращение к персональным данным незаконно, а сам вызов downstream-сервиса ГБД, как правило, не пройдёт.

---

2. Место КДП в архитектуре ШЭП

Типовой поток «получить данные о человеке» выглядит так:

Ваша ИС
   │
   ▼
[ ШЭП / Smart Bridge ]  ← единая интеграционная шина egov
   │
   ├──► КДП: getPersonDataAccessControl
   │        (согласие субъекта / фиксация основания)
   │        → возвращает подписанный токен-код доступа
   │
   └──► Целевой сервис ПДн (ГБД ФЛ, родственные связи, доход, недвижимость…)
            токен-код доступа передаётся в вызов как подтверждение согласия

Ключевая идея: КДП выдаёт подписанный «токен согласия», который затем предъявляется downstream-сервису. То есть КДП — это «турникет» перед реестрами. Именно поэтому он тесно связан с уже разобранными в блоге сервисами:

• ГБД ФЛ — интеграция с реестром физических лиц;
• ГБД ЮЛ — проверка контрагента по БИН;
• сервис родственных связей и сведения о доходах, недвижимости и т.д.

Для большинства сервисов персональных данных вызов КДП — предварительный обязательный шаг.

---

3. Как это выглядит на уровне сообщений

По публично документированным интеграционным материалам (реализация на стороне оператора реестра) взаимодействие идёт по SOAP поверх HTTPS. Основной метод — getPersonDataAccessControl.

3.1. Аутентификация вызова

• HTTP Basic Authentication (логин/пароль в заголовке);
• SOAP-заголовок с userId (в формате UUID);
• транспорт — только HTTPS.

3.2. Основные параметры запроса

Поле	Тип	Назначение
requestNumber	string	Уникальный номер запроса
uin	string	ИИН субъекта (12 цифр)
company	string	Наименование организации-инициатора
company_bin	string	БИН организации-инициатора
company_responsible	string	Организация — источник данных
employee_name	string	ФИО сотрудника-инициатора
access_name	string	Ключ(и) целевого сервиса; несколько — через ;
personal_data_name	string	Тип запрашиваемых данных (например, ИИН)
expiresIn	int	Срок жизни токена, мс
omit-sms	boolean	Пропустить SMS-подтверждение
ovt	string	JWT-токен подтверждения (обязателен при omit-sms=true)

3.3. Два способа подтвердить согласие

А. Через SMS (по умолчанию, omit-sms=false). Система отправляет субъекту сообщение с номера 1414; субъект подтверждает согласие ответом. Простой путь, но зависит от того, что у гражданина есть номер в Реестре мобильных граждан и он ответит вовремя.

Б. Через подтверждённое основание (omit-sms=true + токен ovt). Организация формирует и подписывает JWT-токен (ovt) алгоритмом ГОСТ (GG2015). В payload передаётся способ подтверждения mcheck:

• Bio — биометрия;
• Ds — электронная цифровая подпись (ЭЦП);
• Otp — одноразовый пароль;
• DID — цифровой документ / Digital ID;
• PC — бумажное подтверждение.

Плюс поля cbin (БИН, должен совпадать с company_bin), iat/exp (время выпуска и истечения; exp — минимум +1 час к iat). Для этого пути организация должна пройти регистрацию/аттестацию по альтернативным способам получения согласия.

3.4. Ответ и статусы

Ответ содержит status, а при успехе — code (подписанный JWT-код доступа) и public-key (сертификат для проверки кода).

Статус	Значение
VALID	Доступ разрешён (согласие/основание подтверждено)
INVALID	Доступ запрещён
PENDING	Ожидание ответа субъекта
TIMEOUT	Субъект не ответил в срок
NOT_FOUND	Нет номера в Реестре мобильных граждан
ERROR	Сбой (например, доставки SMS)

Полученный code затем передаётся в вызов целевого сервиса ПДн как подтверждение согласия.

3.5. Типовые коды ошибок

Код	Причина
SBF-VE-8	ИИН должен содержать 12 цифр
VAL-JSR-001	Пустое/отсутствующее обязательное поле
ScbSystemFault	Нет прав доступа у пользователя
FAULT-015	Целевой сервис недоступен
ERROR_TV_NOTRETRIEVED	Не удалось извлечь данные из JWT
ERROR_TV_BIN_NOTMATCH	cbin в JWT не совпадает с company_bin
ERROR_TV_NOTFOUND	Некорректное mcheck в JWT
ERROR_MISMATCH_BINORNAME	БИН/наименование не совпадают с реестром

⚠️ Конкретные значения полей, коды сервисов (access_name) и способы аттестации зависят от оператора реестра и вашего договора подключения. Перед боевой интеграцией сверяйтесь с актуальным WSDL и паспортом сервиса на sb.egov.kz (паспорт ORGDO-S-3243).

---

4. Что здесь обычно ломается

1. Забыли про КДП вообще. Команда интегрирует ГБД ФЛ напрямую и упирается в отказ: без токена согласия данные не отдают. КДП — не опция.
2. Ставка только на SMS. Статусы PENDING/TIMEOUT/NOT_FOUND в проде дают «отваливающиеся» запросы, если у пользователя нет номера в реестре или он не отвечает. Нужен продуманный UX ожидания и повторов.
3. Криптография ГОСТ для ovt. Путь omit-sms=true требует подписи JWT алгоритмом GG2015 и корректной работы с ключами/сертификатами — это отдельный проект сам по себе.
4. Рассинхрон cbin / БИН / наименования. Ошибки ERROR_TV_BIN_NOTMATCH и ERROR_MISMATCH_BINORNAME — классика: данные в JWT и в запросе должны точно совпадать с реестром.
5. Срок жизни токена. expiresIn и связка с downstream-вызовом: код доступа надо использовать вовремя и в правильном сервисе.
6. Отзыв согласия и уведомления. По правилам субъект может отозвать согласие и видеть, кто имеет доступ. Интеграция должна это уважать, иначе — юридический риск.

---

5. Как это упрощает интеграционный шлюз SmartConnect

SmartConnect — интеграционный шлюз, который берёт на себя «низ» интеграции с ШЭП и отдаёт разработчику чистый REST/JSON-контракт. Здесь важно отделить базовый функционал шлюза (он общий для всех сервисов каталога) от логики, которая настраивается под конкретный сервис КДП по его паспорту.

Базовый функционал шлюза — работает одинаково для любого сервиса ШЭП:

• Единый REST/JSON-фасад. Ваша система говорит на REST/JSON, а шлюз сам собирает SOAP-конверт нужного сервиса, отправляет и разбирает ответ — без самописного SOAP-кода на вашей стороне.
• Встроенная ЭЦП и защищённое хранение ключей. Подпись исходящих сообщений и проверка подписи ответов выполняется шлюзом; ключи хранятся в защищённом хранилище — вашей команде не нужно самостоятельно поднимать криптопровайдер. См. как работает ЭЦП в Казахстане.
• Гарантированная доставка. Очереди, повторные попытки с backoff при сбоях, dead-letter и история транзакций — вызовы не теряются на таймаутах госсистем, любой запрос прослеживается.
• Журналирование и аудит вызовов. Каждый вызов фиксируется в журнале транзакций шлюза — основа для контроля доступа и разбора инцидентов.
• Гранулярный доступ. Права микросервисов на конкретные сервисы настраиваются по принципу наименьших привилегий, в едином контуре безопасности.

Что настраивается под КДП по паспорту сервиса. Специфику гейта согласия — какие именно каналы подтверждения (SMS 1414 / ЭЦП / биометрия / OTP / ovt ГОСТ-JWT) подключены, форму единого вызова с оркестрацией согласия, маппинг статусов PENDING/TIMEOUT/NOT_FOUND в состояния вашего приложения и требуемый объём журналирования доступа к ПДн — SmartConnect проектирует и подключает под конкретный сценарий интегратора по паспорту сервиса КДП и условиям владельца данных. Мы не подменяем эти параметры собственными значениями и фиксируем их на этапе подключения. Цель — чтобы «турникетная» механика КДП (вызвать getPersonDataAccessControl, дождаться статус, прокинуть code в целевой сервис) была скрыта за понятным контрактом, а не переизобреталась каждой командой заново.

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

---

6. FAQ

Обязательно ли проходить через КДП, если у нас есть письменное согласие клиента? Для доступа к персональным данным в государственных ИС взаимодействие с госсервисом КДП предусмотрено правилами. Даже при наличии основания обращение фиксируется (в т.ч. в режиме логирования). Точный порядок для вашего кейса определяется НПА и условиями оператора сервиса — их и нужно брать за основу.

Что такое номер 1414? Короткий номер, с которого КДП отправляет субъекту запрос на подтверждение согласия по SMS.

Можно ли обойтись без SMS? Да, через путь omit-sms=true с подписанным JWT-токеном ovt и указанием способа подтверждения (mcheck: биометрия, ЭЦП, OTP, Digital ID, бумажный документ). Требует аттестации организации.

Может ли гражданин отозвать доступ? Да. По правилам субъект может получать сведения о том, кто имеет доступ к его данным, и отзывать согласие; в eGov Mobile для граждан появились соответствующие функции контроля.

---

7. Источники

• Паспорт сервиса «Сервис контроля доступа к персональным данным», sb.egov.kz — ORGDO-S-3243.
• Правила интеграции с государственным сервисом контроля доступа к персональным данным (ИПС «Әділет», V2200028786).
• Правила функционирования государственного сервиса контроля доступа к персональным данным (ИПС «Әділет», V2200027963).
• Обновление правил КДП, приказ от 05.03.2026 (в силе с 23.03.2026) — включение биометрии, автоматизированной обработки, каналов согласия.
• Публичная интеграционная документация оператора реестра (метод getPersonDataAccessControl, параметры, статусы, коды ошибок).

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

---

CTA: Нужен корректный «гейт согласия» КДП перед обращением к госданным в вашей системе? → Запросить подключение через SmartConnect — обсудим сценарий, каналы подтверждения и подключим по паспорту сервиса.