62
Рисунок 39 - Роль CRM в процессе приема звонков
10) МССМ процесс. Система CRM участвует в процессе получения и
записи информации о коммуникации с клиентами с мастер-системой
хранения информации о коммуникациях системы (CommDB) (рисунок 40).
Рисунок 40 - Роль CRM в МССМ процессах
11) Процесс связанный с картами клиента. СRM участвует в
процессе выпуска карт (рисунок 41).
63
Рисунок 41 - Роль CRM в процессе выпуска карт
Помимо этого CRM участвует в более мелких процессах, таких как:
генерация ПИН кода по клиенту в процессинге;
процесс блокировки и разблокировки клиентов в АБС;
процесс взыскания просроченной задолженности;
процесс безопасности(обезличивание данных клиентов);
процесс CallCenter (процесс сбора и отображения данных в отчетах по
KPI сотрудников, а так же передачу информации по ключевым
показателям в другие системы для сбора отчетности);
Со стороны системы CRM SalesForce было создано более 40 сервисов,
по которым система отправляет или получает данные из любой требуемой
системы банка.
Как видно из схем, система CRM SalesForce находящаяся в облачном
сервисе не может взаимодействовать с каждой из систем банка напрямую, т.к
большая часть этих систем не имеет и не может иметь сервисов,
выставленных во внешнюю среду для взаимодействия.
Для решения этой проблемы была выбрана схема, при которой все
взаимодействие системы внутри банка между собой, а так же с системой
CRM SalesForce осуществляется через интеграционную шину, в данном
64
случае IBM ESB, которая обеспечивает легкое взаимодействие систем между
собой.
Так же, один из адаптеров шины, выставлен во внешнюю среду, через
который идет процесс взаимодействия системы CRM SalesForce с системой
IBM ESB (а далее и со всеми остальными системами).
Т.е. со стороны CRM SalesForce по всем предусмотренным сервисам
точкой интеграции является один известный адрес сервиса шины,
выставленный во внешнюю среду , а изнутри защищенный всеми средствами
, необходимыми для предотвращения несанкционированного доступа извне
во внутреннюю среду (политика разделения доступа к средам по PCI DSS,
WAF, FireWall и т.д).
Пример настройки endpoint для различных сервисов системы
(рисунок 42).
Рисунок 42 – Настройки сервисов интеграции
Как видно, для разделения сервисов используется один адрес с
разными портами на нем и разными именами сервисов URL-адресе.
65
На каждом из этих портов расположен адаптер шины (входная точка)
для обработки определенных сервисов.
По каждому выставленному сервису шины можно увидеть его WSDL
схему, для легкой интеграции с данным сервисом.
Для примера ниже представлен запрос со стороны CRM SalesForce и
ответ со стороны шины по сервису запрос данных по заявке и клиенту
(рисунок 43).
Рисунок 43 – Пример запроса и ответа по одному из сервисов
Как видно из таблицы по полям SourceName и TargetName транзакция
начинается в системе CRM SalesForce (в таблице UNDEFINED) . Далее этот
запрос поступает в адаптер шины (ADPCRMOUT), а оттуда поступает в
шину (ESB). Шина в свою очередь в соответствии с настройками сервиса
делает запрос в одну из баз данных (SRVAPPDBREQUEST)- в данном случае
в базу AppDB, содержащую данные о заявках клиентов. После получения
данных из базы начинается обратный процесс получения результата из базы
в шину, из шины в адаптер, из адаптера в CRM SalesForce.
3.4. Внедрение решения по токенизации персональных данных и их
интеграция с облачными сервисами CRM SalesForce
Хранение персональных данных на территории иностранного
государства в контексте 242-ФЗ не запрещено при условии соблюдения
условий сбора персональных данных на территории РФ и соблюдения
порядка трансграничной передачи персональных данных, установленных
законом.
Чтобы соответствовать законодательству РФ и положениям надзорного
органа после 1 сентября 2015 года нельзя напрямую использовать по схеме
66
SaaS приложения, обрабатывающие персональные данные и находящиеся за
пределами РФ, без принятия дополнительных мер. Также невозможно
предоставлять прямой доступ с российского сайта в зарубежные ИС, если
персональные данные предварительно не зафиксированные в базе на
территории РФ.
Для того чтобы выполнять закон после 1 сентября, во-первых,
необходимо перестроить архитектуру информационной системы и
обеспечить первичную запись, хранение и актуализацию персональных
данных в базах на территории РФ (создать «буферную зону»).
В инфраструктуре банка созданы и используются для хранения
различной персональной информации базы данных на СУБД Oracle12
находящиеся в ЦОД на территории РФ (рисунок 44).
Рисунок 44 – Схема серверной архитектуры
Во-вторых, необходимо хранить данные в информационной системе за
рубежом в обезличенном виде, а базы индексов, идентификаторов
соответствия и т.п. на территории России. При этом при обезличивании
данных необходимо выгружать данные из зарубежного приложения также в
обезличенном виде, формировать персонифицированные отчеты,
67
использовать формы с идентификаторами, позволяющими установить
личность субъекта только на территории РФ
В-третьих, хранить данные в информационной системе за рубежом в
зашифрованном виде, а расшифровывать данные только в приложении,
находящемся на территории России.
Зашифрованный массив данных без ключа у провайдера – не
персональные данные.
В последнее время помимо шифрования используется технология,
называемая токенизацией. При использовании данной технологии
конфиденциальные данные не передаются. Вместо данных клиента в
процессе используется специальное значение – токен. Данная технология
обладает большей степенью защищенности, так как процесс токенизации
необратим, и данные могут подвергнуться опасности лишь в случае, когда
атаке подвергнется сервер токенов. При использовании облачных серверов,
находящихся на территории других государств, токенизация является
необходимым инструментом защиты персональных данных клиентов.
Преимуществами токенизации являются:
1) снижение расходов на проверку систем безопасности;
2) минимизация изменений в приложениях;
3) хранение конфиденциальных данных в единой базе данных на
одном контролируемом сервере;
4) маскировка по умолчанию;
Базовая архитектурная модель токенизации приведена на рисунке 45.
68
Рисунок 45 – Модель токенизации
Архитектурная модель токенизации состоит из следующих этапов:
1. Сбор или генерация частей конфиденциальных данных с помощью
специального приложения;
2. Передача данных на сервер токенизации;
3. Генерация токенов на сервере токенизации и хранение их вместе с
данными в базе данных;
4. Возврат токена приложению.
Есть три пути создания сервера токенизации:
1. Установка готового сервера токенизации с поддержкой базы данных;
2. Встроенные/интегрированные решения со сторонним программным
обеспечением;
3. Полностью реализованные в базе данных.
В качестве средства токенизации в Touchbank было решено
использовать ПО Perspecsys от компании Symantec.
На рисунках 46 и 47 приведены схемы до и после токенизации:
69
Рисунок 46 – Условная схема до внедрения процесса токенизации
Рисунок 47 – Условная схема после внедрения процесса токенизации
Требования проекта токенизации:
Поддержка до 200 стандартных пользователей в 2017 году и до
20 пользователей Community Partner;
Данные должны храниться локально на серверах в РФ на
территории TouchBank;
Защита данных – токенизация;
Три среды SalesForce серверов: TST, PreProd, Prod.
Схема реализации решения по токенизации данных в TouchBank
приведена на рисунке 48.
70
Рисунок 48 – Архитектурная схема Perspecsys в инфраструктуре
TouchBank
Согласно данной схеме сервер токенизации расположен на сервере,
расположенном на территории TouchBank в РФ.
Для повышения отказоустойчивости и масштабируемости созданы 2
комплекта сервера токенизации, соединенные в кластер. Над нодами сервера
токенизации расположен балансировщик нагрузки NGINX.
Внутренние пользователи ( расположенные в домене организации )
имеют доступ до SalesForce напрямую, подключаясь сразу на сервер
балансировщика , откуда идет проброс до одной из нод сервера токенизации.
После токенизации \ растокенизации данных запрос транслируется от
сервера токенизации к серверу SalesForce. Ответ от SF к пользователю
отправляется в таком же порядке.
Внешние пользователи подключаются по защищенному каналу https
через firewall и WAF к серверу , имеющему выход во внешнюю среду.
Данный сервер, на котором расположен балансировщик NGINX транслирует
запросы пользователь на одну из нод модуля ReverseProxy , являющимся
одним из модулей сервера токенизации. Далее модуль ReverseProxy
транслирует запрос на одну из нод самого сервера токенизации. После
71
токенизации \ растокенизации данных запрос транслируется от сервера
токенизации к серверу SalesForce.
Конфигурация решения состоит из следующих компонентов Perspecsys
AppProtex:
Perspecsys AppProtex Server (Forward Gateway) *2 – Сам сервер
токенизации;
Perspecsys AppProtex Integration Server *2– сервер интеграции;
Perspecsys AppProtex Communication Server –сервер
коммуникации (почтовый сервер);
Database Inference Engine (RDBMS) – Oracle Enterprise 11g – БД.
Технические характеристики серверов приведены в таблице 4.
Таблица 4 – Технические характеристики серверов TouchBank
Сервера
CPU
RAM Memory
Storage
Notes (Physical or
Virtual)
AppProtex
Forward
Gateway
2 x 3-GHZ
(multicore)
16 GB (min)
50-100 GB
Production x2
Test x1
Dev x1
AppProtex
Integration
Server
2 x 2-GHZ
(multicore)
8 GB
250 MB
Production x2
Test x1
Dev x1
Database
Server
2 x 3 GHZ
(multicore)
16 – 32 GB
200 GB+ to
1 TB+
Физическая\вирут
альнаяпамятьзави
ситотрешения
После установки ПО Perspecsys были определены объекты и поля БД
SalesForce которые должны быть обезличены \токенизированы, для
соответствия требованиям хранения и обработки ПД в облачных сервисах.
Пример полей, требующих обезличивания приведен в Приложении В.
Для поддержания работы интеграции сервера SalesForce c ресурсами
Банка (через интеграционную шину) реализованы вызовы различными
сервисами со стороны SalesForce не сервера шины напрямую, а сервера
токенизации данных, который после растокенизации данных перенаправляет
запросы уже в шину, а далее к системам источникам.