Pull to refresh

Comments 22

> Евросоюз, Россия и Китай требуют от коммерческих компаний хранить персональные данные местных пользователей, в том числе их ключи шифрования, на территории страны

Евросоюз не требует. Покажите пункт в GDPR, который это требует делать. Там есть ограничения если европейская компания хочет передать данные за границу (где не действует GDPR и не обеспечивается должный уровень защиты, например в США, где Дикий Запад в плане работы с ПД), но даже в этом случае передача сама по себе не запрещена. А если пользователь сам вводит свои данные в фейсбуке, то фейсбук не обязан их хранить в Европе (но обязан соблюдать GDPR).

Пожалуйста, не вводите людей в заблуждение; не знаю, как дела в Китае, знаю только что такой закон есть в России.

Также, ключи шифрования сами по себе не являются персональными данными. Единственное, что мне известно, что у нас организатор распространения информации обязан по запросу их предоставлять в органы, и в некоторых странах нельзя отказываться выдавать их по решению суда.
Там есть ограничения если европейская компания
Тот факт, что у вас или вашей компании нет представительства в ЕС, не означает, что вы можете игнорировать закон. Если бы вы могли его игнорировать, это автоматически поставило бы в невыгодное положение тех, кто играет по правилам. Вы игнорируете закон на свой страх и риск (link).
Я не пишу, что можно игнорировать закон; GDPR применяется даже для иностранных компаний. Я пишу, что в ЕС нет требования хранить данные европейцев внутри ЕС. Есть требование «обеспечивать должную защиту прав пользователя» если компания передает данные пользователя другой компании за пределами ЕС. Это описано, например, в ссылке, которую я также указал в комментарии: cas.ltd/gdpr-6-personal-data-transferring-data-outside-europe
Хорошо, нет требования _обязательного_ хранения внутри ЕС, но есть ограничения на передачу данных за границу. Я изменил формулировку в статье. Вы правы, так точнее, конечно.
По ключам шифрования. Насколько я понял из слов юриста, их можно отнести к типу данных PII, если они привязаны к профилю и не анонимизированы.

«Есть ещё данные особого типа PII, сокращение для личной идентифицируемой информации (Personally Identifiable Information). Это любая информация, которая помогает идентифицировать человека. Очевидные примеры PII — полные имена и номера социального страхования. Не очень очевидный пример — IP-адрес. Действительно не очевидный — факт наличия редкого заболевания в сочетании с названием маленького городка, места жительства. И ещё много подобных примеров. Самое просто решение — представить все данные о человеке, как будто это PII. Лучше предпринять излишние меры безопасности, чем потом сожалеть. Но если вам кажется, что к некоторым данным можно относиться проще, то тщательно взвесьте, какие из них следует рассматривать как PII, а какие нет.»
Ключ шифрования позволяет идентифицировать человека только внутри компании. Это по сути то же самое что userId. Возможно, он будет считаться ПД если компания будет передавать его на сторону, но пока он внутри компании, это лишь внутренний идентификатор. Если компания удалит данные о человеке и оставить только его ключ, то тогда этот ключ в любой ситуации перестанет быть ПД.
Как мне кажется, как раз внутри компании ключ шифрования как раз и может считаться ПД (поскольку позволяет идентифицировать пользователя), а вот вне её (сам по себе) — это просто «набор бит», как и userid, впрочем.
>Если компания удалит данные о человеке и оставить только его ключ
Юрист говорит, что правильно анонимизировать данные очень сложно, так что на всякий случай лучше рассматривать подобные вещи как ПД.
А в ключе содержится userID или только сам ключ? Если только сам ключ (ну и id в таблице), то по идее ключ может оказаться и не уникальным. Т.е. у меня и у Пупкина может (совершенно случайно) оказаться один ключ шифрования. В таком случае это тоже PII?

PS: почему я считаю что он может быть не уникальным? Потому что не люблю анекдот про «Придумайте другой пароль. Такой пароль уже использует Марья Ивановна.»
Тут вопрос, какая вероятность генерации одинаковых ключей. Если она пренебрежимо мала то их можно считать уникальными, если одинаковые ключи у десятков пользователей — то другое дело. Тут, увы, математической формулы нет, и это будет как-то решаться судьей в конкретной ситуации.
UFO just landed and posted this here
Проблема в том, что такого софта крайне мало, если сказать не единицы.
UFO just landed and posted this here
Зачастую это xor 55h, профессионалы даже обработкой это не посчитают.
большую часть данных которые хранит айклауд нельзя зашифровать дополнительным слоем потому что это информация напрямую из встроенных приложений эпл. файлы в айклауд драйве можно, да
UFO just landed and posted this here
На айфонах есть возможность поставить самописное приложение
Либо обновляя сертификат подписи раз в 1-2 месяца бесплатно, либо купив сертификат разработчика на год (раньше стоило $100, сейчас хз)
Ключи должны генерироваться на конечном устройстве и никуда никогда не передаваться иначе это не ключи а проходной двор.
Давайте посмотрим правде в глаза — весть электронный ширпотреб (смартфоны, ноутбуки, ПК) проходной двор. Например, замечательная вещь Intel ME — если я правильно понимаю она может получить доступ к памяти и сетевой карте в обход ОС, антивирусов, сетевых экранов и т.п.
Есть мнение, что не сможет, если у вас какая-нибудь интегрированная сетевуха Realtek, висящая на линии PCI-E x1 (как практически все интегрированные сетевухи).
Походу нужно не аккаунт создавать, а реально валить в ЕС и мириться с высокими ценами на энергоносители, зато жить как человек.
Apple всегда хранила у себя ключи шифрования для пользователей iCloud.

Если я пользователь, то свои ключи шифрования я не доверю никому, тем более Apple. И буду передовать/хранить только зашированные данные (если они того стоят). И шифровать я их буду с использованием сертификата X509.
Здесь речь все же идет все же о шифровании Apple (или еще кем-то данных), которые поступили каким-то образом в его распоряжение, и он их шифрует. И этом смысле вполне законное требование государства доступа к этим данным.

Sign up to leave a comment.

Articles