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

31

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

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

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

user2424495
источник
2
Если вы хотите, чтобы данные были синхронизированы, они все равно должны быть где-то доступны, чтобы данные могли быть загружены в ваше приложение. Вы можете разделить данные между несколькими базами данных, поэтому, если одна из них будет каким-либо образом взломана, вы не потеряете все свои данные. Если это удовлетворяет клиента, просто добавьте больше соединений с базой данных в ваше приложение и извлеките из них свои данные.
Энди
2
Это одноранговая проблема? или только 1 рабочий стол с 1 смартфоном (для каждого пространства данных)?
ebyrob
7
Вы можете обеспечить конфиденциальность в базе данных, зашифровав данные на сервере с помощью ключа, который известен только пользователю.
Филипп
26
Это похоже на схему, о которой подумал кто-то, кто не понимает безопасность. Кто бы ни придумал это требование, он должен сформулировать вопрос о защите данных в Security.SE .
jpmc26
4
@ user2424495: Если данные должны быть доступны через веб-сайт, они должны быть доступны там, где обслуживается ваш веб-сайт, который обычно является центральным сервером. Или вам нужно написать плагин для браузера, который предоставляет данные на стороне клиента.
Берги

Ответы:

60

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

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

Джастин Кейв
источник
24
@ user2424495 - Если целью является реальная безопасность, почти наверняка победит централизованное хранение данных. С точки зрения маркетинга, это может быть не ваша вина, если кто-то взломал телефон. Но это, безусловно, плохо отразится на приложении, если выяснится, что его относительно легко взломать (поскольку системы большинства людей очень плохо защищены). Я бы лучше объяснил людям, что их данные хранятся в зашифрованном виде с использованием средств безопасности военного уровня, чем надеяться, что они не будут обвинять меня в том, что их плохо защищенный телефон взломан.
Джастин Кейв
27
Пока это единственный ответ, который действительно отвечает на этот вопрос и обеспечивает наилучший возможный результат безопасности. Требования ОП были нелепы. Если данные настолько чувствительны, что идея о том, что данные доступны даже через общедоступную сеть, оскорбительна для пользователей, тогда идея приложения нереальна. Полная остановка. Клиентские устройства не защищены и не могут быть доверенными.
maple_shaft
2
@mharr, если в базе данных хранятся только зашифрованные данные (зашифрованные перед тем, как покинуть устройство), не имеет значения, что говорится в постановлении суда, физически его невозможно расшифровать без ключей шифрования, которые есть только у пользователя.
Ричард Тингл
9
@RichardTingle <tinfoil> Если не указано, что правительственное агентство уже взломало шифрование. </ Tinfoil>
Боб
3
Я никогда не говорил, что проблема не была «интересной», я нахожу вопрос и ответы до сих пор очень интригующим и вызывающим мысли. Это именно тот вопрос, который делает этот сайт великолепным. Я действительно подвергаю сомнению требования и некоторые предположения, которые, возможно, делаются относительно данных. Мое чувство пауков просто кричит мне, что эти требования и предположения о важности данных являются размышлениями раздутой и самолюбивой компании, которая воображает себя информированной и проницательной, но на самом деле продолжение ...
maple_shaft
38

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

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

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

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

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

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

zwol
источник
4
Это на самом деле не пытается ответить на вопрос или опровергнуть его, но это действительно отличный ответ на вопрос, который не задавался.
maple_shaft
11
@maple_shaft: Ну, он отвечает на вопрос, который ОП хотел задать. Поскольку этот вопрос вполне может быть связан с проблемой XY , это кажется хорошим ответом.
слеске
8

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

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

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

Philipp
источник
1
Похоже, что схема управления версиями также потребовалась бы, чтобы не отправлять все данные назад и вперед все время между двумя устройствами ...
ebyrob
Обмен p2p был бы отличным решением, если бы не было необходимости в ненужных настройках конечного пользователя, что, на мой взгляд, сделало бы использование приложения менее удобным для пользователя. Тогда возникает вопрос, хочет ли клиент выбирать между уязвимостью данных и небольшой суматохой при настройке приложения, которая во многом зависит от того, насколько точны данные и насколько важны пользователи.
Энди
1
@DavidPacker при условии, что вы настроили и обслуживаете первый сервер, каковы дополнительные шаги по настройке?
ebyrob
@ebyrob Возможно, меня неправильно поняли, но я понимаю, что сервер, предоставленный создателем приложения, не затрагивает ничего, кроме процедуры синхронизации p2p. Но данные должны быть извлечены через этот сервер с одного из клиентских устройств - и клиент должен сделать себя или свои данные доступными - это настройка, о которой я говорил.
Энди
1
@David, Philipp предлагает одноранговый обмен конфиденциальными данными, поэтому не отправлять их на центральный сервер или даже через него. Центральный сервер существует только для того, чтобы один узел мог найти другого; тогда это убирается с дороги.
Эрик Эйдт
5

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

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

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

Джеймс Мейсон
источник
1

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

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

Майкл Шоу
источник