Если бы был способ достаточно надежно разделить пользовательские идентификационные данные (имя, адрес, платежные данные, и т.д.) и конфиденциальные данные бизнес-логики пользователя (прежде всего данные для статистического анализа и построения прогностических моделей: например, что, когда и как делают люди или значимые программные агенты (в широком смысле), включая финансовые транзакции; результаты анализа видео-потока, звонков), то тогда бизнесу можно было бы меньше опасаться за конфиденциальность своих данных и экономить, используя общие удаленные серверы для обработки и хранения значимых данных бизнес-логики, нежели чем использовать 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 (нуждаясь в качественно меньшем количестве ресурсов, чем для обработки и хранения всех данных), на сервере, в облаке. В том числе предоставляя элементарный интерфейс конструктора.


И таким образом, возвращаясь к ситуации двух БД, становится возможным рассчитывать, что приватные данные даже попадая в удаленную БД останутся приватными как неидентифицированными с личностью (или компанией)-владельцем.

И вот, интересно было бы найти, рассмотреть какие-то еще решения для анонимности конфиденциальных данных бизнес-логики. И, возможно, опровергнуть или доработать данное.

Например, вместо mock-запросов использовать алгоритм создания валидируемого анонимного (в части связи с аккаунтом/персональной информацией) токена, с учетом квот и возможности отзыва, если такой алгоритм мог бы существовать (и может быть даже известно, что кто-то подобный алгоритм уже использует).

И может быть есть косвенно похожие/связанные p2p решения (в рамках блокчейна или в другой области), которые можно перенести сюда, на уровень стандартного централизованного проекта. Но чтобы при этом не использовалось бы тотальное шифрование, и, соответственно, можно было бы обходиться меньшим количеством вычислительных ресурсов.