Salesforce и 152-ФЗ (закон о ПДн)

Salesforce и 152-ФЗ (закон о ПДн)

Коллеги, добрый день
Работаем в Salesforce и храним там данные клиенту. Хотим реализовать требования 152-ФЗ к персональным данным.
Интересует, проходил ли кто-то уже этот путь, к какой компании порекомендуете обратиться, какие будут нюансы(понимаю, что нюансов сотни )?

Пока начали прорабатывать этот вопрос ctconsult.

Ramzai
Коллеги, добрый день
Работаем в Salesforce и храним там данные клиенту. Хотим реализовать требования 152-ФЗ к персональным данным.
Интересует, проходил ли кто-то уже этот путь, к какой компании порекомендуете обратиться, какие будут нюансы(понимаю, что нюансов сотни )?

Пока начали прорабатывать этот вопрос ctconsult.

Путей несколько, все так или иначе уродуют систему.
Если вы энтерпрайзн - Perspecsys или CypherCloud, если поменьше DFG-152 от CT. Второй попроще, не знаю как там нынче обстоит с API - как поддерживается токенизация при работе с данными через API, при их обработке в скриптами на странице их сохранении в Visualforc-e.

cidr8n
DFG-152 от CT

cidr8n, можешь поподробнее рассказать про этот продукт (я даже не против рекламы) если имеешь к нему отношение. Что за зверь, что позволяет, на каких принципах построен.

Dmitry Shnyrev
cidr8n
DFG-152 от CT

cidr8n, можешь поподробнее рассказать про этот продукт (я даже не против рекламы) если имеешь к нему отношение. Что за зверь, что позволяет, на каких принципах построен.

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

В отличие от кровавоэнтерпрайзных собратьев, делпет подмену на уровне презентации - увидел токен - полез в базу, заменил. Похожий процесс токенизации при сохранении.
Помимо этого есть куча аспектов типа работы через апи, поиска, сортировки, фильтров - детали реализации этих частей мне незнакомы, увы.

Преимущества у доступности относительно собратьев, можно развернуть "в облаке" на территории РФ. Вендор местный - договориться проще чем с индусами :)

cidr8n
делпет подмену на уровне презентации

Я правильно понял что это на клиенте, т.е. в браузере вся магия происходит?

Dmitry Shnyrev
cidr8n
делпет подмену на уровне презентации

Я правильно понял что это на клиенте, т.е. в браузере вся магия происходит?

Ога.
плюс будет проще если данные хранятся за DMZ - нужный клиент будет иметь доступ к данным.

cidr8n
DMZ

Что-то новое, никогда не сталкивался с таким понятием.

Dmitry Shnyrev
cidr8n
DMZ

Что-то новое, никогда не сталкивался с таким понятием.

Да, это я выпендрился :-\
В общем, когда сам сервис с перс. данными развернут во внутренней сети и "извне" недоступен.

Dmitry Shnyrev
cidr8n
DFG-152 от CT

cidr8n, можешь поподробнее рассказать про этот продукт (я даже не против рекламы) если имеешь к нему отношение. Что за зверь, что позволяет, на каких принципах построен.

Дмитрий, DFG-152 со стороны пользователя выглядит как плагин для гугла. Юзер в нём логинится, и его персональные данные, введённые на стандартных макетах уходят на наш сервер. Только пока действительна сессия DFG, пользователь видит их как данные. Иначе - как токены. Токены же и хранятся непосредственно в полях аккаунтов, контактов и проч. Можно запустить процесс токенизации уже имеющихся в системе персональных данных. Есть блок настроек для определения объектов, данные которых нужно токенизировать. В целом вот такой функционал.

Вопрос такой, если массово работать с записями у которых данные затокенизированны к примеру в больших батчах? К примеру мне надо сверить определённое поле с шаблоном, потом изменить и заапдейтить? Что по лимитам?

DevNull
Вопрос такой, если массово работать с записями у которых данные затокенизированны к примеру в больших батчах? К примеру мне надо сверить определённое поле с шаблоном, потом изменить и заапдейтить? Что по лимитам?

Все зависит от контекста выполнения. Если батч, то он выполняется на стороне форса и для манипуляции с токенизированными данными нужно будет явно "растокенизировать", обработать и затокенизировать обратно.
Все отдельными вызовами веб-сервиса. Не уверен что сервисы реализованы в DFG, но такое есть в Perspecsys и Cipher.

А, да, еще это нарушит сам закон, ибо это будет трансграничной передачей данных в бэк форса, если подкопаться. Хотя согласно какой-то там редакции закона оно возможно при условии первичного их сохранения на территории РФ - без юриста не разобраться :-\

Ну, собсно да. Вообще у нас есть список ограничений на использование, не знаю, опубликован или нет.

Tellen
у нас есть

Tellen, ты имеешь отношение к данного продукту?
Можешь рассказать про опыт его вреднения и практического использования. Если ваша компания заинтересована и можете набрать материала на статью (чтобы было интересно и нам разработчикам и вашим потенциальным клиентам) то можно ее будет выложить на блоге - польза будет всем.

Скажем так - у меня очень часто интересуются про возможности использования SF для русских проектов и мне сразу приходится людей отсылать к изучению данного закона и пробллем с ним со стороны SF. Если вся информация о данной проблеме и пути ее решения будет собрана в одном месте, то я смогу людей отсылать к этому источнику - ну а кем эти люди могут стать в перспективе можно узнать у маркетологов

Дмитрий, я имею весьма косвенное отношение к данному продукту...наверное...короче, я не разрабатывал, но поучаствовал)От имени компании говорить не уполномочен, но проект коммерческий, есть официальный сайт же с контактами http://www.dfg152.ru
Вот реально не знаю, готов и заинтересован ли кто-то из ребят излагать это в виде статьи, могу только сказать что по ходу внедрения, идёт активная доработка, ибо это новая для нас стезя. Заказчики весьма чувствительны к тому, что каким-то образом затрагивает их данные в системе, и всегда возникает куча вопросов, порой очевидных и бестолковых. И это при том, что у нас малоинвазивное решение, то есть минимально влияет на систему. Могу представить, какие могут возникнуть проблемы при внедрении чего нибудь, что требует большего вмешательства.

Мда, жаль, что сложилась такая ситуация вокруг salesforce в россии.
Вот очередной показательный пример - прямо подтверждение моих слов вчера общался с человеком по поводу использования SF в качестве базы для русского проекта. В итоге после долгого обсуждения пришли к выводу что проще переключиться на альтернативные CRM, которые предоставляют возможность развернуться на своем сервере или хотябы имеют датацентры в россии. С этим законом все преимущества SF + костыли теряются. Я пока не думаю что все эти костыли, описанные выше помогут вернуть всю мощь CRM.

Кстати вот мне еще интересно - как будут проверять что клиенты SF (да и любой другой платформы) выполняют требования закона? Неужели будут разбирать код проекта? Или есть какие еще механизмы. Ну чисто теоретически взять настроить зеркалирование базы данных на местный сервер, но системой пользоваться как обычно. Придут товарищи и спросят - где вы храните и обрабатываете персональные данные? А мы - вот, здесь, на локальном сервере а то что вы видете в браузере это очень сложный механизм токинезирования и детокенизирования написанный на Cobol еще в 1990 кода и разработчик уже давно у нас не работает и все скомпилорованно, а исходники нечаянно удалили в 1995 году.
Вот вас накажут что вы не хотите или не можете предоставить доступ к исходному коду или доступ на орг в нашем случае или за реальный факт хранения персональных данных на серверах SF. - Я пока только вижу возможность получения бампа базы данных от самого SF по требованию, но разве будет SF сливать базы данных с любых оргов непонятно кому и непонятно по каким местным законам?

Ну, насколько я знаю, по DFG у нас всё сертифицировано на официальном уровне, приходила инквизиция и выдала лицензию, что типа да, наше решение защищает данные согласно этого закона. Так что с юридической точки зрения, если пользователь имеет учётную запись в DFG, то он согласно нашей лицензии, закона не нарушает. Он просто не сможет сохранить данные в форсе, если не залогинен в плагине.
Сам закон, конечно, политический ангажированный, но вполне может так быть, что дабы показать серьёзность намерений, будет найден какой нибудь козёл отпущения и показательно покаран по всей строгости этого закона. Как в тот раз было со школьным учителем которого на пиратской винде спалили.

Ну так это в корне меняет дело, если решение утверждено на уровне проверяющих!
Это сильный плюс в карму данного решения.

А какова цена?

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

Зачем делать из этого коммерческую тайну? Закрадывается только одна мысль - соДрать побольше с больших клиентов!!!

Dmitry Shnyrev
Зачем делать из этого коммерческую тайну? Закрадывается только одна мысль - соДрать побольше с больших клиентов!!!

Как будто это что-то плохое :)

Tellen
Не знаю, это к отделу продаж. Скорее всего какая нибудь гибкая схема ценообразования в зависимости от количества пользователей. Всё под грифом коммерческой тайны, все дела.

Просто интересно знать порядок цен

Dmitry Shnyrev
Зачем делать из этого коммерческую тайну? Закрадывается только одна мысль - соДрать побольше с больших клиентов!!!

Да всё что связано с ценообразованием на продукты компании является коммерческой тайной по моему. Я думаю так везде, нет?
Я вот честно, даже ценами на лицензии сейлсфорса не интересовался) Далёк я от всего этого. Опять же, можно связаться с отделом продаж с сайта DFG, вдруг вам скажут?

Я вот помню на старой работе пытались мы датчики заказать у фирмы производителя. Так там чтобы хотя бы порядок цен узнать, нужно было 2раунда переговоров выдержать, чтобы нас как потенциальных клиентов определили. Видимо, такая паранойя в бизнесе чем то оправдана.

cidr8n
Путей несколько, все так или иначе уродуют систему.
Если вы энтерпрайзн - Perspecsys или CypherCloud, если поменьше DFG-152 от CT. Второй попроще, не знаю как там нынче обстоит с API - как поддерживается токенизация при работе с данными через API, при их обработке в скриптами на странице их сохранении в Visualforc-e.

CypherCloud это полная задница, не советую.

Отличный отзыв

Dmitry Shnyrev
Отличный отзыв :D

Нет, ну а как называть ситуацию, когда простой Login через SOAP напрямую работает, а через CipherCloud - нет. И при этом support утверждает, что все норма.

Тему подняли на Habrahabr.
http://habrahabr.ru/post/271023/
Предлагаю следить за развитие.

Самое интересное это вывод который сразу же сформулировали в первом комментарии

Ну то есть я правильно понял, что всем пофиг где еще хранятся данные, главное чтобы была не шифрованная копия в России?
То есть как бы сложив два и два можно получить что кто там что и куда это все равно, главное чтобы можно было изъять данные при необходимости без лишних запросов?

Т.е. получается что основная цель не "хранить ТОЛЬКО в РФ", а "хранить ТАКЖЕ в РФ". Интересно получается. Это сильно упростит нам жизнь если так.

Буквально на следующей странице опять статья
http://habrahabr.ru/company/itpark/blog/271061/

М-да, тяжко вам там.

ДА тяжело нам тут
Такая замечательнеая технология Salesforce, а пользоваться тут некому - либо цены либо законы мешают.

Interesting information? Help us, post link to social media..