Если бы был способ достаточно надежно разделить пользовательские идентификационные данные (имя, адрес, платежные данные, и т.д.) и конфиденциальные данные бизнес-логики пользователя (прежде всего данные для статистического анализа и построения прогностических моделей: например, что, когда и как делают люди или значимые программные агенты (в широком смысле), включая финансовые транзакции; результаты анализа видео-потока, звонков), то тогда бизнесу можно было бы меньше опасаться за конфиденциальность своих данных и экономить, используя общие удаленные серверы для обработки и хранения значимых данных бизнес-логики, нежели чем использовать in-house решения, когда данные не покидают территорию бизнеса с целью защиты конфиденциальности.То есть чтобы владельцы серверов знали, что данные бизнес-логики принадлежат юзеру “x290230x9sksfpoaopdfsafl”. Но кто этот юзер не знали бы и не имели разумно доступных способов это выяснить.
При этом, данные можно анализировать, агрегировать их с данными других пользователей привычными средствами.
В то же время сами пользователи работают со своим интерфейсом так же, как если бы была реализована стандартная схема хранения данных.
Вообще говоря, вопрос такого разделения актуален не только в части экономии средств в виду большего ухода от in-house решений, но и в части защиты приватности данных пользователей различных веб-сервисов.
Тем самым, можно рассматривать вопрос и в контексте того, каким должен (может) cтановиться веб на этапе увеличивающихся мощностей, средств наблюдения, анализа поведения, а по совокупности потенциального контроля.
Ниже будут подробности и описание возможной архитектуры.
Лично меня всегда немного тревожат онлайн-календари/планировщики.
Очевидно, что если я буду хранить намеченные встречи и действия в них, и придерживаться плана в большинстве случаев, то мой маршрут, мои действия можно будет не только примерно прогнозировать, а прямо-таки знать с большой вероятностью. А следовательно влиять на них.
И когда никому нет до меня дела — это хорошо. И если ты «не идешь против системы», той или иной, то как-будто никому и не понадобишься.
Но даже в этом случае, не покидает ощущение, что вокруг нас постепенно строится «нейрокурятник».
А мы, если этого не замечаем, как бы подобны курицам из известной присказки, которые каждый день получают пищу, тепло, и думают, что раз так было вчера, так происходит сегодня, то «совершенно очевидно», что так будет и завтра, просто потому что так было всю нашу лично-сенсорную (но отнюдь не историческую, не социальную) жизнь.
И когда никому нет до меня дела — это хорошо. И если ты «не идешь против системы», той или иной, то как-будто никому и не понадобишься.
Но даже в этом случае, не покидает ощущение, что вокруг нас постепенно строится «нейрокурятник».
А мы, если этого не замечаем, как бы подобны курицам из известной присказки, которые каждый день получают пищу, тепло, и думают, что раз так было вчера, так происходит сегодня, то «совершенно очевидно», что так будет и завтра, просто потому что так было всю нашу лично-сенсорную (но отнюдь не историческую, не социальную) жизнь.
Равным образом, например, мне бы хотелось, чтобы социальная сеть даже имея доступ к моей переписке не могла тем не менее установить, кто и с кем ее ведет.
Как известно власть развращает, а абсолютная власть развращает абсолютно. И в этом смысле в мире можно наблюдать два главных вектора развития, которые в пределе формулируются как движение к абсолютной власти немногих через рычаг автоматизированного централизованного управления и движение к миру равных, через децентрализацию, автономию и интеграцию с децентрализованным AI.
И поэтому, эта тема кажется актуальной и в краткосрочной перспективе минимизации издержек, и в долгосрочной, в снижении рисков от проблем, создаваемых вектором централизации управления социальными процессами. Чтобы мочь совершать действия, направленные на усиление вектора децентрализации.
И хочется поделиться найденным возможным решением, которое бы позволило так хранить и обрабатывать данные, чтобы идентификационные данные и данные бизнес-логики функционировали как бы отдельно. С увеличивающейся сложностью установления соответствия между ними при росте числа пользователей системы.
А также узнать мнение сообщества о том, как еще можно поступить в данном случае, для достижения схожей цели. И видятся ли какие-то изъяны, принципиально сводящие архитектуру на нет.
(кликабельно)
Например, есть две БД. Relational DBMS (RDBMS) и column-oriented DBMS (CDBMS).
Первая является “персонифицированной”. В ней хранится персональная информация пользователя, имя, адрес, платежная информация, квоты.
Вторая БД является анонимной. В ней данные бизнес-логики принадлежат пользователям (указан secret_account_id), однако структурно нет возможности сопоставить эти данные с персональной информацией пользователей — найти какому именно пользователю принадлежат те или иные данные.
При первой аутентификации пользователя в системе на стороне клиента генерируется secret_account_id и шифруется пользовательским gpg ключом.
Затем зашифрованное значение пишется в персонифицированную БД (RDBMS) в поле encrypted_secret_account_id.
В CDBMS есть поле secret_account_id, в котором значение secret account id хранится в незашифрованном виде.
И таким образом, прежде чем сделать запрос к CDBMS клиент в рамках сессии запрашивает зашифрованную строку encrypted_secret_account_id (из RDBMS/кеша), дешифрует ее с помощью приватного ключа, и делает запрос со своим secret_account_id к API, работающему с CDBMS.
При этом возникает вопрос, как сделать доступ к API СDBMS по токену, чтобы к API могли обращаться только авторизованные клиенты, но при этом:
1) чтобы владея обеими БД нельзя было понять, какой именно юзер сделал тот или иной запрос к API CDBMS в данный момент времени (и тем самым сопоставить данные).
2) чтобы мочь отозвать токен при необходимости (например, не поступила оплата). Или мочь устанавливать квоты ресурсов для аккаунта в связи с выбранным тарифом.
Одно из возможных решений видится в следующем:
— “Mock”-запросы токена для всех юзеров (или для всех пользователей с учетом деления пользователей на категории).
То есть клиент автоматически раз в период (например, раз в секунду, раз в пол секунды) делает в рамках своей сессии запрос токена даже если в действительности токен ему не нужен, и он не работает с базой в данный момент.
При этом, токен является общим для всех юзеров (либо для всех пользователей определенной категории, к которой относится запрашивающий пользователь)
Для снижения нагрузки используется кеширование или подписки (например, Fastly, websockets)
Рандомное количество раз в пределах установленных лимитов, в рандомном промежутке времени токены пересоздаются и перезаписываются в кеш.
— все запросы к базе делаются через [при прочих равных] достаточно надежный анонимайзер, например Tor.
Таким образом, владея сервером с персональной информацией пользователей и базой данных с конфиденциальными данными бизнес-логики пользователей мы сможем установить соответствие между ними с вероятностью, обратно пропорциональной количеству пользователей системы (или количеству пользователей, относящихся к какой-либо категории):
1 юзер – 100% соответствие
10 юзеров – 1/10
1000 юзеров – 1 / 1 000
100 000 юзеров – 1 / 100 000
и т.д.
При этом, необходимо озаботиться тем, чтобы API, обрабатывающее участки персональных данных, содержащиеся в данных бизнес-логики, не вычленяло и не сохраняло / не логировало персональную информацию.
То есть это должен быть open source код, который по выбору можно запустить и подключить самостоятельно (in-house, на сервере, в облаке) или использовать коробочное решение, если это оправдано спецификой данных.
В то же время можно сделать и так, чтобы автоматически выявляемые участки персональных данных (например, об участниках финансовых транзакций) подвергались шифрованию и хранились в CDBMS в зашифированном виде.
Тем самым, анализируя такие данные, например, можно было бы говорить, что аккаунт с secret_account_id «x290230x9sksfpoaopdfsafl» совершил ряд транзакций cо счета:
<85>^B^L^CgdzB9¦<94>A^A^P^@<8b>wo<98>7Q<84>UX^Bl5u?{e^@<87>K
uy<87>+U<9e><A<84> ?9<8c>)S?zhIy<8e><95>^Kx^\uU^K<99><99>\?x_W8EC^L<87>cI^ZuUE??<98>_^RI<8b>?aE<8d>b<8c><86>;<80>?<92><99><85><97>2^E?<9d> <9d><80>2a¶9,<9e>^U+<98><96>^@?O<85>o^_`m[µ?<8d><82>ja|^R?^Ra<:OaCu?acM_<9f>^N??Y^Ru^ABc?A<93>?_i¤etlNC<9d>D^S^K2?ya<8c>rnpN\?#<84> <88>y^_'SS<93>2*^CmNE^],^]GcQ°??<92><82><99>ori:O*¤oN9o±<95>C<81>0?<96>¤<9a>^E¬?|E??j*yye??eFsAe?^K3^QoU^L?i+?aI<94>¶A<84>O<9d>(O?u\#<9a><90>^\I^Z6<8f>eX'¦<9d>y<9a>aI^^UI<95>?<9b>?^?i<99>K<9d>v<98><9e>N*>Ak??yx1¬>/^XOhy{^LoR-<97>d?w·Lj^NhfhN,{<96>y?«¤^\µ?hcA?Ny
~O¬µup^Sµ0*^\?^auO*<83>?O>*?;<84>G??%^S<82>Y^S<8e>WUi«)E<94>oz; u^AuN?^WI?<92>dAuV^Bfve}?qeT»e@i|6/y<81>S^Y<97>7$e<85>^[@<81><99>$y?&?<93><83>|¬Z7<8e>^EN<95>"i{^[rcPoO<97>Io?';9bh·AahIIEJ^]?^VcE1 ?eYO[ ^K<80>^T<95>¶^]^Y §<8c>^[/?1a\OU^A<80>Wi<84>UAiv7^QUiuKI<98>?M?z?a<8e>m"^Eu<9f><8a>F| ?X
<8a>I^@^VEtie<81>m<89>«<95>}¶f<99>?x?"4^H<9d> l?ir?)C?E7<87>OE{x~N,tiIo%на подобным образом зашифрованный счет (фиатной или криптовалюты, тем или иным способом).
Можно было бы подсчитать размеры транзакций, проследить динамику по датам, но не установить факты о том, кто именно их совершал.
И при необходимости вводить дополнительное шифрование на те участки данных, которые могут позволить установить соответствие между идентификационными данными и данными бизнес-логики по каким-либо косвенным признакам. То есть проводить последовательное машинное обучение, направленное на такую фильтрацию.
Осуществляя дешифровку либо на стороне устройства клиента при работе в личном кабинете, если объемы дешифровки незначительны, либо через поднятие промежуточного open source API пользователем, опять же на выбор — in-house (нуждаясь в качественно меньшем количестве ресурсов, чем для обработки и хранения всех данных), на сервере, в облаке. В том числе предоставляя элементарный интерфейс конструктора.
То же касается сообщений в социальной сети.
Когда вместо монолитного фасада, социальная сеть делегировала бы часть операций сторонним вычислительным ресурсам.
И была бы вполне возможна гибридная схема, при которой подключаются свои вычислительные мощности, становящиеся частью их API. Которые и обрабатывали бы некоторые участки собственных персональных данных, содержащихся в данных бизнес-логики.
Тут может возникнуть вопрос зачем им это, если паровоз и так едет?
Вероятно, это могло бы нести финансовые выгоды по снижению издержек. При этом, убедить рядовых пользователей, что им необходимо платить за свою страничку в социальной сети кажется утопией. А вот начать майнить собственную криптовалюту социальной сети и в блоках хранить в зашифрованном виде персональные участки конфиденциальных сообщений пользователей кажется вполне возможным при должном уровне фильтрации текстов. Соответственно, майнеры взяли бы на себя задачи по фильтрации текстов и шифрованию на основе публичных ключей авторов сообщений, как часть своего proof-of-work. Немного модифицировав понятие транзакции в рамках такого блокчейна.
Но, конечно, это вопрос спорный, займутся ли они подобным, или что-то схожее можно было бы увидеть уже в другом формате, на следующей итерации развития децентрализованных систем и VR/AR.
*Делая оговорку, что децентрализованные социальные сети разрабатываются, и представлены, но речь идет о топовых, массовых социальных сетях и о возможности доступа к конфиденциальным данным для их анализа, а не его блокировки полным шифрованием для всех, кроме авторизованных пользователей.
И была бы вполне возможна гибридная схема, при которой подключаются свои вычислительные мощности, становящиеся частью их API. Которые и обрабатывали бы некоторые участки собственных персональных данных, содержащихся в данных бизнес-логики.
Тут может возникнуть вопрос зачем им это, если паровоз и так едет?
Вероятно, это могло бы нести финансовые выгоды по снижению издержек. При этом, убедить рядовых пользователей, что им необходимо платить за свою страничку в социальной сети кажется утопией. А вот начать майнить собственную криптовалюту социальной сети и в блоках хранить в зашифрованном виде персональные участки конфиденциальных сообщений пользователей кажется вполне возможным при должном уровне фильтрации текстов. Соответственно, майнеры взяли бы на себя задачи по фильтрации текстов и шифрованию на основе публичных ключей авторов сообщений, как часть своего proof-of-work. Немного модифицировав понятие транзакции в рамках такого блокчейна.
Но, конечно, это вопрос спорный, займутся ли они подобным, или что-то схожее можно было бы увидеть уже в другом формате, на следующей итерации развития децентрализованных систем и VR/AR.
*Делая оговорку, что децентрализованные социальные сети разрабатываются, и представлены, но речь идет о топовых, массовых социальных сетях и о возможности доступа к конфиденциальным данным для их анализа, а не его блокировки полным шифрованием для всех, кроме авторизованных пользователей.
И таким образом, возвращаясь к ситуации двух БД, становится возможным рассчитывать, что приватные данные даже попадая в удаленную БД останутся приватными как неидентифицированными с личностью (или компанией)-владельцем.
И вот, интересно было бы найти, рассмотреть какие-то еще решения для анонимности конфиденциальных данных бизнес-логики. И, возможно, опровергнуть или доработать данное.
Например, вместо mock-запросов использовать алгоритм создания валидируемого анонимного (в части связи с аккаунтом/персональной информацией) токена, с учетом квот и возможности отзыва, если такой алгоритм мог бы существовать (и может быть даже известно, что кто-то подобный алгоритм уже использует).
И может быть есть косвенно похожие/связанные p2p решения (в рамках блокчейна или в другой области), которые можно перенести сюда, на уровень стандартного централизованного проекта. Но чтобы при этом не использовалось бы тотальное шифрование, и, соответственно, можно было бы обходиться меньшим количеством вычислительных ресурсов.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Поделиться с друзьями
lolikandr
Все данные, которые отправляются в интернет на хранение, должны быть зашифрованы. Косвенные признаки идентификации пользователя могут быть очень разными.