Интеграционный подход к защите персональных данных: кейс реализации в 1С

Введение

Современные требования законодательства и рост киберугроз делают защиту персональных данных (ПДн) критически важной задачей для любого бизнеса. Хранение контактной информации клиентов непосредственно в оперативной базе создает высокие риски утечек и требует серьезных мер по обеспечению безопасности. В рамках реализованного проекта мы решили эту проблему, вынеся конфиденциальную информацию в специализированный изолированный контур – «1С:CRM ПДн».

Безопасность хранения данных в текущей учетной системе

Существующие риски

В качестве основной операционной системы на проекте использовалась конфигурация «1С:ERP. Управление холдингом», не предназначенная для работы с персональными данными в защищенном контуре. Следствием этого стал ряд критических рисков:

1. Отсутствие встроенных средств защиты персональных данных – в системе не было механизмов ролевого доступа на уровне записей контактной информации, шифрования данных при хранении или изоляции полей, хранящих персональные данные. Система хранила телефоны и email-адреса в открытом виде в общей базе данных, что делало их доступными для широкого круга сотрудников через стандартные отчеты и запросы.
2. Нарушение принципа минимизации и обезличивания – согласно требованиям законодательства, хранение ПДн должно быть обоснованным, а при отсутствии операционной необходимости – обезличенным. В системе клиента не было технической возможности автоматически подменять контактные данные на псевдонимы или скрывать их по умолчанию.
3. Комплаенс-риск при инцидентах безопасности и несанкционированном доступе – в случае утечки данных из учетной системы факт хранения полного набора персональных данных без соответствующих средств защиты повлек бы за собой административную и гражданско-правовую ответственность, включая крупные штрафы и репутационные потери.
4. Сложность аудита доступа к ПДн – ERP-система не предоставляла детализированных журналов о том, кто именно и когда запрашивал телефон или email контактного лица. А это противоречило требованиям законодательства о контроле за обработкой персональных данных.

Необходимость модернизации системы хранения личных данных

Несмотря на все описанные риски, полностью отказаться от хранения и обработки персональных данных в рамках проекта было невозможно. Бизнес-процесс требовал их использования для решения конкретной прикладной задачи.

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

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

• обеспечивал выполнение бизнес-функции клиента;
• не нарушал требований законодательства;
• минимизировал риски, связанные с избыточным и бесконтрольным хранением персональных данных.

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

Интеграционное решение вопроса обезличенного хранения личных данных

Выбор архитектуры

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

Было принято решение реализовать модель раздельного хранения, при которой персональные данные выводятся из «1С:ERP. Управление холдингом» в отдельную защищенную базу. При таком подходе исходная система продолжает выполнять свои учетные функции, но перестает быть хранилищем персональных данных. В то же время доступ к реальным телефонам и email-адресам осуществляется только в тот момент, когда это действительно необходимо для выполнения операции – например, при отправке опросной рассылки или при явном запросе пользователя. Таким образом, взаимодействие между системами построено по pull-модели: данные не транслируются в исходную систему автоматически, а запрашиваются только в момент необходимости.

Основные компоненты системы

Архитектура решения включает две взаимодействующие информационные системы. В роли основного операционного контура выступает «1С:ERP. Управление холдингом», в которой ведется основной учет, а также клиенты и их контактные лица. Вторым компонентом является выделенная база «1С:CRM ПДн», развернутая с учетом требований к безопасному хранению персональных данных.

В контексте данной статьи под субъектом понимается объект учета в исходной системе, обладающий контактной информацией, – контактные лица, потенциальные клиенты, партнеры с типом «физическое лицо». То есть те объекты, персональные данные которых требуют шифрования.

Общая схема интеграции «1С:ERP. Управление холдингом» и «1С:CRM ПДн»

Центральным элементом хранения в «1С:CRM ПДн» стал регистр сведений «Контактная информация объектов», спроектированный специально для этой задачи. Измерения регистра обеспечивают однозначную идентификацию записи:

1. GUID владельца контактной информации – связывает данные с конкретным субъектом в исходной системе.
2. Тип владельца контактной информации – определяет, какому справочнику принадлежат данные.
3. Тип контактной информации – хранит значение «Телефон» или «Электронная почта».
4. GUID вида контактной информации – хранит идентификатор вида контактной информации.
5. Контактные данные – само значение хранимой информации.

Такая структура регистра дает возможность хранить для каждого субъекта неограниченное количество телефонных номеров и электронных адресов, обеспечивая при этом поиск по GUID, по типу данных и по их значению.

Для обмена данными между системами в «1С:CRM ПДн» был разработан новый HTTP-сервис «Работа с контактными данными». Исходная система выступает в роли клиента, отправляющего запросы в «1С:CRM ПДн». Этот сервис является единственным каналом доступа к ПДн, что позволяет централизованно контролировать все операции с персональными данными.

Также в «1С:ERP. Управление холдингом» был спроектирован новый регистр сведений для логирования обращений к персональным данным. Он содержит измерения «Пользователь» и «Объект запроса контактной информации», что позволяет фиксировать, кто и в отношении какого субъекта инициировал получение телефона или email. Это решение обеспечивает выполнение требования по аудиту доступа к персональным данным.

Реализация задачи через pull-модель

Интеграционные механизмы

Взаимодействие между исходной системой и «1С:CRM ПДн» построено на основе HTTP-сервиса. Исходная система выступает в роли клиента, отправляющего HTTP-запросы к защищенной базе. В зависимости от сценария используются различные методы сервиса:

1. Получение контактной информации – отдельный метод HTTP-сервиса принимает GUID субъекта и тип владельца контактной информации, а также, опционально, отборы по типу и виду контактной информации. Метод выполняет обращение к регистру сведений «Контактная информация объектов» в «1С:CRM ПДн» и возвращает структурированный JSON-ответ, содержащий все запрашиваемые данные. Также разработан второй вариант того же метода для получения данных по списку объектов (например, для отображения контактных данных в табличной части). Он необходим для минимизации количества обращений к «1С:CRM ПДн».
2. Запись и обновление контактной информации – на стороне «1С:CRM ПДн» реализован метод, принимающий GUID субъекта и массив контактных данных.
3. Обратный поиск – система передает в «1С:CRM ПДн» значение контактных данных (номер телефона или email-адрес) и получает в ответ GUID субъекта, которому принадлежат эти данные. Этот сценарий используется при автоматическом распознавании отправителя входящих писем.

Интерфейс пользователя и процесс работы

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

Кнопка «Показать контактную информацию» в карточке контактного лица

При нажатии на эту кнопку система отправляет запрос в «1С:CRM ПДн» и отображает полученные данные непосредственно на форме. Пользователь видит телефонные номера и email-адреса субъекта, но эти данные не сохраняются в исходной системе и доступны только в контексте открытой формы.

Контактная информация из «1С:CRM ПДн», отображенная на форме

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

Сценарии записи и получения персональных данных через HTTP-сервис

В типовом сценарии работы с электронными письмами определение отправителя и автоматическое заполнение карточки документа происходят на основе контактной информации, хранящейся непосредственно в системе. Однако в существующих рамках стандартный механизм оказался неприменим. Вместо него был разработан альтернативный сценарий: при получении входящего письма система автоматически обращается к HTTP-сервису «1С:CRM ПДн» с запросом на поиск GUID субъекта по адресу электронной почты, указанному в письме. При успешном нахождении совпадения GUID возвращается в исходную систему, и реквизиты входящего электронного письма заполняются по полученным из закрытой базы данным. При сохранении письма адрес электронной почты удаляется из документа, чтобы персональные данные не сохранялись в исходной системе.

Поиск субъекта по email при получении входящего письма

Перспективы развития интеграционного решения

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

Заключение

Основные выводы

В рамках проекта решена задача безопасного хранения персональных данных при отсутствии соответствующих механизмов в основной учетной системе – без переработки привычного бизнес-процесса клиента:

✔ Персональные данные выведены в защищенный контур «1С:CRM ПДн», доступ к ним организован по pull-модели – только по запросу пользователя и только на время работы с формой.
✔ Реализованный HTTP-сервис охватывает все сценарии: получение, обновление и поиск контактной информации.
✔ Логирование обращений обеспечивает аудит доступа.
✔ Автоматическая обработка входящих писем адаптирована под новые условия работы без хранения конфиденциальной информации в исходной системе.

Ценность решения для бизнеса

✔ Решение обеспечивает соответствие требованиям 152-ФЗ без остановки бизнес-процессов и перестройки учетной системы.
✔ Снижены комплаенс-риски и возможные штрафные санкции.
✔ Пользователи работают в привычном интерфейсе, не замечая интеграционной сложности.
✔ Архитектура допускает масштабирование на другие объекты системы, а сам подход может быть тиражирован на аналогичные проекты.

Больше статей о нашем проектном опыте можно прочитать в разделе «Статьи».