Как стать автором
Обновить

Комментарии 49

я таки не понял, обычным пользователям чего бояться?

Пользователям, в смысле, сёрферам? Абсолютно нечего. Да и с чего бы…

НЛО прилетело и опубликовало эту надпись здесь
стоп-стоп-стоп! То есть требования ЕС на российских операторов не распространяются, а вот требования рос.законодательства, например, по переносу данных на территорию России, почему-то распространяются и на иностранные компании…
Что за несимметричный ответ? Почему тот же Гугл должен на этом терять деньги, а «десять крупнейших компаний российской экономики» — нет?
Требования на гугл распространяются потому, что он ведет бизнес в России и собирает (обрабатывает) данные российских пользователей. Требования ЕС на российских операторов не распространяются если эти операторы не ведут бизнес в ЕС и не собирают (обрабатывают) данные граждан ЕС.
Нет. Ясно же написано, что не распространяются, потому что «Российская Федерация не является участницей международных договоров с ЕС». То есть, по простому, ложили мы на эти требования
Мне просто кажется, что Жаров ерунду говорит, и никто не позволит российским операторам игнорировать
Частное предприятие по вывозу мусора в деревне Пеньково проблем с GDPR иметь не будет. Условный ozon.ru, продающий книги жителям ЕС, обязан, с точки зрения судов ЕС, подчиняться этому закону под угрозой наложения штрафа. Разумеется, ozon может попробовать не подчиняться судебным решениям. Если его не интересует дальнейший бизнес в ЕС.
Я, конечно, не специалист, так что — только предположение. Александр Жаров может говорить что угодно, но, лично мне кажется, что если Аэрофлот или РЖД захотят работать с людьми в Европе напрямую (а по другому не получится) или нанимать работников в Европе напрямую, то GDPR им не избежать. Продали билет гражданину ЕС — будьте добры соблюдать. Думаю, что воплей по этому поводу будет ещё очень много.
Верно пишите. Проще всего Аэрофлоту и РЖД завести обработку персональных данных в ЕС в таком случае.
Даже если нанимать работника в европе то избежать не удастся, это же работает и на европу тоже. И работник в европе должен будет обеспечить обработку данныых в соответствии с этими нормами, а нормы там включают в себя весьма неудобные моменты.

Российским компаниям можно не соблюдать, но когда через пару лет европейские компании при выборе партнеров обяжут быть GDPR compliant, то быстро все начнут соблюдать.

когда через пару лет европейские компании при выборе партнеров обяжут быть GDPR compliant

Если этим партнерам передаются персональные данные пользователей — то не через пару лет, а с 26 мая сего года.
GDPR не так страшен как кажется. При построении любого серьезного бизнеса он (бизнес) должен озадачиться сохранностью и безопасностью данных. В широком смысле этого слова — penetration tests, сегментирование сетей, разганичение доступа, пароли, бэкапы, DR и DR-планы, BCP, доступ в помещения, утилизация техники итд итп. (все слишком долго перечислять). Но это реально то, чем должен озаботиться любой серьезный бизнес. Без этого просто нельзя.

Кроме того в GDPR написано что компании должны предоставлять «разумный» уровень защиты. Что есть «разумный» урочень там не описано и возможны трактовки. Если вы не делаете бэкапы, то при проблемах на вас наедут за отсутствие разумной защиты данных. Если вы делаете и делаете его правильно, то это и есть та самая разумность. Отсутисвие DR-плана это не разумно. Наличие хоть какого-то (пусть и не самого лучшего) это уже разумно. Отсутствие политики апдейтов для ОС и программ это не разумно. Наличине хоть плохонькой — уже разумно.

GDPR основан на NIST SP 800-53 Rev. 4. Можно взять их Excel файл и пройтись по вопросам и для себя ответить имеется это или нет. Если нет — начать хоть что-то делать в этой области. Если имеется, но плохонько — наметить пути исправления ситуации. В конце концов когда будет аудит ответы на эти вопросы давать придется.
Там больше геморроя не с вопросами безопасности данных, а такими положениями как например data portability
Вот уходит ваш клиент к другому поставщику услуг и говорит вам, а перенесите ка все мои данные к нему, как вы это будете делать его не волнует, но право у него теперь есть, а у вас есть обязанность это сделать. Или прямо обратная ситуация.

Но как вы упомянули — главное иметь план.
А как сейчас решается вопрос ухода клиента от одного провайдера услуг к другому? Самый простой вариант — переезд из Amazon AWS в MS Azure или наоборот. А если это, скажем, из MS Dynamics 365 в SAP? А если что-то более комплексное? Будет решаться точно так же. Во-первых, на сколько я знаю из своего опыта, перенос осуществляется тем кто принимает, а не тот от которого уходят. Тот только отдает данные. Во вторых уход клиента это всегда проект с соответствующими ресурсами (финансовыми, временными и людскими). Тут же самый главный вопрос в том что нужна потенциальная возможность этого переноса данных. Т.е. чтобы не было так, чтобы провайдер сказал: «Опа! А я не могу.»

Если же мы говорим о персональных данных отдельного пользователя, то никто никого не заставит переносить файлы из Dropbox в Google Drive — это на совести самого пользователя. А вот тот же Dropbox будет обязан предоставить доступ к данным (ну он-то и не отказывается) и закрыть аккаунт если надо (тоже проблем нет).
я был месяц назад на семинаре от Datatilsyn — это орган в Норвегии регулирующий все в цифровом пространстве, там был ровно такой вопрос, «я вот из дропбокса хочу уйти в облако от майкрософт» и ответ был такой, что все файлы то они переносить не обязанны, но вот все что содержит ваши персональные данные — да. А если компания хранит данные пользователей в облаке, у тех же амазон, то надо с ними заключать договор об обработке персональных данных пользователей, и таким образом уже амазон подпадает под гдпр.
Амазон да, — попадает под GDPR, спору нет. Но ему-то переживать не о чем — там и так все давно сделано нормально.

Но перенос персональных данных единичного пользователя? Я даже догадываюсь что мне скажет тот-же Дропбокс если я им скажу, что хочу уйти в О365. Давайте рассмотрим самый простой вариант — персональные данные это данные вашего аккаунта (ФИО, кредитка итп). Для того чтобы переехать из одного сервиса в другой вам надо аккаунт и там и там. Кто будет создавать аккаунт на новом месте в О365? Пользователь? Или Дропбокс? Если пользователь, то что тогда после этого будет надо перенести Дропбоксу если уже все будет введено пользователем? Если Дропбокс, то получается он будет управлять вашим аккаунтом в О365. Не порядок.
Я вот сейчас специально почитал на тему GDPR Data Portability. Вики, конечно, не истина в последней инстанции, но таки: «Data portability is a concept to protect users from having their data stored in „silos“ or „walled gardens“ that are incompatible with one another, i.e. closed platforms, thus subjecting them to vendor lock-in. Data portability requires common technical standards to facilitate the transfer from one data controller to another, thus promoting interoperability.»

и еще "‘Data portability’, in accordance with the GDPR, is the right for an individual to require an organisation to give them back a copy of the personal data they previously provided or, crucially, to send this data to another organisation — which might be a competitor. The data has to be provided in a commonly used and machine-readable format, so that the new organisation can readily import and make use of the data."

Т.е. никто не говорит, что один вендор должен сам переносить персональные данные пользователя к другому вендору. Вот пользователь может запосить и уже вендор обязан предоставить эти данные или пользователю или другому вендору. Будет ли этот другой вендор принимать эти данные или нет — в правилах не описано. Т.е. тот же Дропбокс может и отправить персональные данные пользователя в Микософт в формате XML. То, что, скажем, Микрософту они не нужны или нужны в JSON это уже проблемы Микрософта. Микрософт может просто сказать — вы можете прислать, но мы их проигнорируем исходя из T&C продукта O365 потому, что данные мы будем принимать только от пользователя и только через установленные формы на сайт О365. Поэтому GDPR прописывает что вендор обязан предоставить данные по требованию пользователя и передать их пользователю или другому вендору и формате, понимаемым компьютерами (коих вагон и маленькая тележка). Но никто не обязывает передавать данные в некоем одном, унифицированном формате через единый интерфейс. Один обязан предоставить. Но другой совершенно не обязан это принимать если это не соответствует условиям его бизнеса.
в самом тексте GDPR написано
что дата должна быть предоставлена in a structured, commonly used and machine-readable format, xml является таким? — да, JSON? тоже да. Понятно что тут скорее вопрос к юристам, как это будет на практике толковаться.
а еще написано что
In exercising his or her right to data portability pursuant to paragraph 1, the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible.

То есть от одного поставщика услуги напрямую к другому.
Да, все верно, но «shall have the right to have» и «must be» это две большие разницы. Первое это «иметь право» и тут никто ничего не оспаривает. Второе это «обязан» Да, пользователь должен иметь право получить всю его персональную информацию и чтобы была возможность передать ее от одного к другому. Все верно, но эта фраза вовсе не означает, что принимающая сторона обязана принять эту информацию. Если у нее будет в terms & conditions написано, что она принимает информацию в определенном формате, то никто не заставит ее принять в другом формате. Тут даже до юристов не дойдет просто потому, что все прописано в T&C. Получить данные имеешь право. Провайдер может их переслать куда пользователь скажет. Примет ли это другая сторона? В правилах это не указано и слава богу!
Data subject в любом случае, как правило, будет в приоритетном положении. Непонятно, почему вы думаете, что принимающая сторона не захочет принять данные? Это ведь в интересах принимающей стороны заполучить нового пользователя, который уходит от другого сервиса и хочет перенести свои данные. Это косяк принимающей стороны, если в ее terms&conditions такой формат не предусмотрен. Пользователь вряд ли пойдет тогда к такому сервису.
Например, пользователь читал книжки на одном сервисе и решил перейти в другой, хочет при этом захватить свои предпочтения в книжках (персданные). В таком случае старый сервис может быть не заинтересован такие данные передавать, а с data portability он обязан в structured, commonly used and machine-readable format передать данные пользователю, так как это право пользователя, гарантированное GDPR.
Передать данные пользователю — да, не вопрос. Даже передать другому провайдеру услуг — тоже не вопрос. Будет ли принимающая сторона что-то делать? — это совершенно другой вопрос, не регламентируемый GDPR.

Рассмотрим случай — компания в 3000 пользователей переходит с Dynamics 365 на SAP. В этом сучае SAP очень даже заинтересован в этом деле ибо это 3000 пользователей и большие деньги.

Рассмотрим другой случай пользователь имеет закладки в книгах (персональные данные). Провайдер услуг может сделать экспорт этих данных в некоем структурированном и открытом формате согласно GDPR. С другой стороны второй провайдер может и не принять эти данные просто потому, что ему особо незачем это делать. Весь же вопрос в затратах. Если пользователь уходит к нему, значит этот пользователь чем-то заинтересован и можем сам добавиь новые закладки если надо. Провайдеру не надо это делать — он уже заполучил пользователя. Один провайдер не может передать данные пользователя пока этот пользователь не существует в обоих системах. GDPR не прописывает то, что один провайдер должен создавать ваакунт и передавать все данные за пользователя (on behalf of a user). Т.е. чтобы один провайдер передал другому что-то в обоих системах этот пользователь уже должен существовать. А раз этот пользователь существует уже у второго провайдера к кому уходят, то ему не надо беспокоиться на тему принятия персональных данных. Ему это просто незачем.

Вы путаете «право пользователя получить эти данные» (то, что прописано в GDPR) и «обязанность провайдера услуг принять и обработать эти данные от другого провайдера услуг». Это две очень большие разницы. Пользователь может получить эти данные. Второй провайдер даже может предоставить некий интерфейс, чтобы пользователь сам ввел эти данные (фио, кредитку, почту, адрес, названия книг, закладки и пр), но вот его никто не обязывает вносить эти данные за пользователя. Говорят только о потенциальной возможности обмена данными. Т.е. скажем те-же закладки — пользователь может сказать провайдеру А — хочу чтобы вы их отослали провайдеру В. Нет проблем. Провайдер А отсылает это провайдеру В. Провайдер В говорит пользователю: «Ок, чувак, тут нам прислали, но у нас нет возможности обработать эти данные потому, что наш интерфейс принимает в JSON, а нам прислали в XML. Вводи-ка ты сам это все.» А пользователь уже ушел от А к В. Все. Он ему уже платит деньги. И пользователю ничего не остается как самому все делать.

Но! (всегда есть НО) Это не значит, что такое невозможно в будущем. Все эти enterprise service bus которые разрабатываются, cloud conenctors итд итп. Все медленно, но верно идет к тому, что перенос данных таки будет автоматическим. Когда-нибудь он будет. Но не прямо сейчас и не исходя из этого GDPR. По крайней мере не из этой версии GDPR.
Прошу прощения, влезу в вашу дискуссию, т.к. не до конца понимаю, что конкретно будет переноситься. Правильно ли я понимаю, что все, что можно перенести, должно быть перенесено? Т.е. личная информация о пользователе, его настройки, метаданные?

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

Адвокат, проводивший у нас семинар по этой теме, упоминал даже «статистику, накопленную блоком управления ABS на вашем Мерседесе, при пересаживании на БМВ». Уж не знаю, сколько там было от шутки
В каких случаях это может потребоваться? Для кого это делается, для конечного пользователя? В чем смысл этого закона?
Подчеркну, что я не являюсь специалистом ни в юриспруденции, ни в области защиты данных.
Вопрос, кому именно принадлежат данные, собранные оператором данных о пользователе, в GDPR в явной форме не отвечен. Но GDPR требует от оператора, чтобы пользователю был предоставлен контроль над этими данными. www.google.de/search?q=gdpr+data+ownership
Огрубляя: данные о том, как я езжу на своем Мерседесе — это данные мои, а не концерна Даймлер-Бенц, даже если я явным или неявным образом разрешил производителю их собирать. Я должен иметь право их получить от их собирателя и распорядиться ими как мне заблагорассудится.
Получить — да. Это в законе явно прописано. Что вы с ними дальше будуте делать — ваше личное дело. Но там нет такого, что тот-же BMW вложит эти данные в машину в ABS, которую вы купите, чтобы эта статистика сохранилась и использовалась уже BMW. Вот конкретно это закон не прописывает.
Закон прописывает, что оператор данных должен передать по запросу данные как мне, так и любому другому уполномоченному мной оператору напрямую. Что с этими данными будет делать другой оператор — вопрос контракта между мной и другим оператором. Понятное дело, я не могу принудить БМВ принудить использовать эти данные. Я могу купить или не купить их машину, основываясь на их планируемом (не)использовании моих данных. Учитывая, что они продают мне (новую) машину, покрашенную в выбранный мной цвет и с выбранными мной опциями вплоть до формы колпаков на колесах, коммерческих причин отказать мне в индивидуальной прошивке бортового компьютера я на первый взгляд не вижу.
Причин нету если это коммерчески обосновано. Если не будет коммерческой выгоды использовать эти данные они имеют полное право их проигнорировать. Вот если от этого машина станет лучше ездить — тогда да. А если это «сферический конь в вакууме», то им будет глубоко плевать на то, что вы хотите чтобы они это использовали. Приведу реальный пример из собственной жизни — я хочу купить машину. Определенную марку и модель. Но мне не нравится цвет отделки салона. Я не могу прийти и сказать — дайте мне другой просто потому, что у них в наличие только определенные цвета. Тот, что мне нужен — нету. Что я делаю? Я все-таки ее покупаю. Почему? Потому что мне нужна определенная марка и модель, а цветом я могу поступиться. Т.е. производитель все равно получил от меня деньги, но при этом он не стал заморачиваться с предоставлением всех возможных цветов. Ему это было экономически невыгодно. А все это очень хорошо просчитывается. Так и тут — вы можете отказаться от покупки BMW если они не вставят ваши данные ABS от Мерседес туда, но это крайне маловероятно. :) Так и с примером выше — переход от Dropbox к O365.
На данный момент у БМВ нет даже теоретической возможности запустить рекламу «Мы научим ваш новый БМВ тормозить так же, как ваш старый Мерседес»
НЛО прилетело и опубликовало эту надпись здесь

Насколько я понимаю, ответ прост.
Пока нет никаких реальных пересечений с юрисдикцией ЕС, и вам по барабану пользователи из ЕС, можно и забить.
Но если есть желание официально сотрудничать с партнерами из ЕС (хотя бы завести счет в европейском банке для своей конторы), лучше исполнять, ибо подобные контакты для конторы являются тем самым хвостом, который ЕС может и прищемить, если что не так.

Да, если вы храните данные пользователей из стран ЕС, позволяющие их идентифицировать. Там еще вроде есть какие то дополнительные ограничения касающиеся с обработкой персональных данных несовершеннолетних, но это неточно.
Совершенно верно. Аккаунт пользователя из ЕС есть? Email в нем есть? ФИО там есть? Кредитка для оплаты там есть? Значит надо соответствовать GDPR. Но если компания маленькая (до 250 чел), то особо переживать на тему GDPR не надо.
Но если компания маленькая (до 250 чел), то особо переживать на тему GDPR не надо.

Почему?
Если более 250, то GDPR обязателен, а если меньше, то в законе существует послабление. Чуть позже могу подробнее написать.
Тоже обязателен, но с послаблениями
То есть вроде как если меньше 250 работников то некоторые положения выполнять не надо, но есть нюанс, и дальше перечисления: gdpr-info.eu/art-30-gdpr
Ну так и я написал послабление. Причем на деле получается весьма не хилое послабление ибо все понимают, что одно дело процедуры безопасности в организации в 3000 сотрудников с развитой инфраструктурой и другое дело маленькая контора, где сейчас почти все в cloud — payroll, crm, email итд. В итоге, как вы же справедливо выше и заметили, облачный провайдер попадает под gdpr. И получается, что если бизнес использует только gdpr compliant провайдеров, то в итоге ему (малому бизнесу) остается очень мало для того чтобы самому быть таким.
Вот у нас маленькая компания, человек 70, однако мы храним данные достаточно большого количества людей, десятки тысяч и мы полностью подпадаем под GDPR, без всяких послаблений. Хотя послабления там
  • Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information:
  • Each processor and, where applicable, the processor’s representative shall maintain a record of all categories of processing activities carried out on behalf of a controller

вот и все, все остальные положения обязательны для всех.
Да и эти положения нужно соблюдать даже для маленькой компании если:
  • processing it(data) carries out is likely to result in a risk to the rights and freedoms of data subjects
  • the processing is not occasional
  • the processing includes special categories of data as referred to in Article 9(1)


и собственно какие данные включены в этот article 9
  • data revealing racial or ethnic origin
  • political opinions
  • religious or philosophical beliefs, or trade union membership
  • genetic data
  • biometric data for the purpose of uniquely identifying a natural person
  • data concerning health or data concerning a natural person’s sex life or sexual orientation

То есть по факту это обязательно для всех, и у нас тут (Норвегия) достаточно большой ажиотаж по этому поводу. Все компании дружно отправляют своих сотрудников на курсы по ГДПР и выделяют достаточно большие ресурсы для того чтобы привести все в порядок.
Я в Австралии. У нас все то-же :)
То есть по факту это обязательно для всех

Снова цитируя уже пару раз упомянутого мной в треде немецкого адвоката: «Не думайте, что этот закон касается только Гугла, Амазона с Фейсбуком и вашей софтверной компании. Любой сантехник, выписывающий счета своим клиентам, оперирует их именами и адресами, а значит, должен подчиняться этому закону.»
Имя акка не идентифицирует.
Почта по большому счёту тоже — её не на паспорт выдают
Требования, чтобы кредитка оплаты была кредиткой клиента в большинстве случаев не предъявляется. Значит кредитка мамы/папы/брата/друга клиента не идентифицирует.
А можно и не хранить — в тех же мобильниках, насколько я понимаю данные кредитки у гугла, а не у разработчика каждой игрушки, в которую я платил.
Разве нет?
GDPR устанавливается обязанность соблюдать его требования при обработке персональных данных. Без привязки к сфере деятельности. Получаешь данные от пользователя(с помощью которых можно его идентифицировать) — соблюдай GDPR.
Несмотря на то, что во многих разъяснениях Еврокомиссии стоит термин «EU citizen», речь в самом законе идет, судя по всему, о резидентах ЕС.
Евробюрократия атакует.
Вместо того, чтобы тупо увеличивать бизнесу накладные расходы на связанное с GDPR бумагозаполительство и отчеторисовательство, гораздо эффекивнее было бы обойтись реальной мерой защиты персональных данных: утекли профили/учётки — крупный (действительно крупный) штраф дырявой конторе + компенсация морального вреда — пострадавшим пользователям.
Через суд, разумеется, по иску прокуратуры.
Имхо, лучше наказывать лучше по факту и провинившегося, а не заранее и всех.
Постановка вопроса у вас неверная: речь в GDPR идет не о защите данных пользователя от несанкционированного доступа (data security), а о защите пользователя от сбора избыточных данных о нем (data protection). Адвокат, который у нас на фирме обязательный семинар по GDPR проводил, употреблял емкое немецкое слово Verdatung (des Kunden).
«Избыточность данных» — оценочная категория, если нет чётких критериев, покрывающих большинство случаев.
Именно поэтому отныне и существует GDPR, который определяет, что является необходимыми, а что — избыточными для бизнеса данными клиента.
en.wikipedia.org/wiki/General_Data_Protection_Regulation#Lawful_Basis_For_Processing
— Алло.
— Алло. Здравствйуте. Меня зовут…
— Не говорите как вас зовут. Это запишется в моей голове и будет обработано. Я не ответственный за хранение персональных данных. И у нас нет такого человека, и по этому я знать не хочу как вас зовут.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий