Нет центральной базы данных

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

Я не могу придумать хороший, надежный способ сделать это, и я не уверен, что есть один. Вот почему я здесь. Кто-нибудь знает, как я мог справиться с этими данными?

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

Много важной информации хранится в базах данных. Фактически, центральная база данных, вероятно, является наиболее безопасным способом хранения этих данных. Крупные корпоративные базы данных обладают множеством функций, позволяющих выполнять такие действия, как шифрование конфиденциальной информации, аудит, кто получает к ней доступ, ограничение или предотвращение просмотра данных людьми, включая администраторов баз данных, и т. Д. У вас могут быть профессиональные эксперты по безопасности, контролирующие среду, и профессиональные администраторы баз данных, которые следят за резервным копированием, так что что вы не потеряете данные. Почти наверняка было бы намного легче скомпрометировать данные, хранящиеся на мобильном устройстве или ноутбуке случайного пользователя, чем проникнуть в хорошо спроектированную инфраструктуру безопасности и поставить под угрозу надлежащую центральную базу данных.

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

Вам необходимо выполнить резервное копирование в несколько шагов и, посоветовавшись с клиентом, разработать модель угрозы . (Да, это ссылка на 600-страничную книгу; да, я серьезно рекомендую вам прочитать все это.)

Модель угрозы начинается с постановки таких вопросов, как

• Почему приложение должно хранить эти конфиденциальные данные в первую очередь?
  • Можете ли вы вообще избежать его хранения?
  • Можно ли его выбросить через короткое время?
  • Действительно ли оно должно быть доступно более чем одному устройству?
  • Если он должен быть доступен более чем на одном устройстве, нужно ли его хранить на нескольких устройствах?
• Кто те люди, которым разрешено просматривать конфиденциальные данные каждого пользователя?
  • Можно ли сделать этот список короче?
• Кто те люди, которые могут вступать в контакт с конфиденциальными данными каждого пользователя, пытаясь выполнить свою работу, но не нуждаются в этом?
  • Можно ли сделать этот список короче?
  • Можно ли сделать данные недоступными для них без ущерба для их способности выполнять свою работу?
  • Если оно не может быть недоступным, может ли оно быть по крайней мере непостижимым? (Это то, что делает шифрование, абстрактно: оно делает данные непонятными.)
• Кто те люди, которые хотят видеть конфиденциальные данные, но не допускаются?
  • Какие возможности они имеют для получения данных?
  • Что они хотят делать с данными, когда они у них есть?
  • Насколько они будут злы, если не получат то, что хотят?
  • Сколько денег, времени, циклов процессора и человеческих усилий они готовы потратить?
  • Их волнует, знает ли кто-нибудь, что они видели данные?
  • Они хотят получить доступ к конфиденциальным данным определенных пользователей , или кто-нибудь сделает?
  • Что они уже знают?
  • К чему у них уже есть доступ?

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

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

Также имейте в виду, что злоумышленники, которые причиняют вам (и / или клиенту) больше всего неприятностей, с наибольшей вероятностью могут совершить гигантский всплеск в СМИ, если их атака окажется успешной или кто нанесет наибольший совокупный ущерб, вероятно, не злоумышленники, которые могут нанести наибольший вред отдельным пользователям, если их атака будет успешной. Компания вашего клиента рационально заботится о совокупном ущербе, но пользователи рационально заботятся о вреде себе.

Один из вариантов сделать синхронизацию - сделать это одноранговым. Для этого все еще потребуется центральный сервер, но этот сервер не будет обрабатывать какие-либо данные.

Когда устройство подключается к сети, центральный сервер получает уведомление с идентификатором пользователя. Когда второе устройство того же пользователя подключается к сети, сервер отправляет обоим устройствам IP-адреса другого. Затем устройства могут обмениваться данными напрямую. Предостережение: одно устройство должно выступать в качестве сервера, поэтому по крайней мере одно не может находиться за маршрутизатором NAT.

Не забывайте, что вам понадобится строгая аутентификация и шифрование как для механизма уведомлений, так и для однорангового обмена.

Сделать это чужой проблемой.

Храните данные локально в каждом приложении, а затем дайте пользователям возможность включить синхронизацию, используя свою учетную запись со сторонним сервисом (Dropbox, Google Drive и т. Д.). Кроме того, подумайте о шифровании любых данных, загруженных в сторонний сервис (в этом есть свои плюсы и минусы).

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

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

Если ваш клиент не хочет, чтобы данные хранились где-либо, он хочет, чтобы пользователь каждый раз вводил их мне?