Немає центральної бази даних

У мене є клієнт, який хоче створити веб-сайт / мобільні додатки / додатки для настільних ПК, які стосуються дуже чутливих даних (більш чутливих, ніж реквізити банку / картки). Через чутливий характер даних вони не хочуть зберігати їх у центральній базі даних, але вони все ще хочуть, щоб їх програми синхронізувались (скажімо, я додаю деякі дані у свій мобільний додаток, то я хочу мати можливість перейти до своєї настільний додаток і перегляньте ті самі дані).

Я не можу придумати приємний, надійний спосіб цього зробити, і я не впевнений, що існує. Через що я тут. Хтось знає, як я міг поводитися з цими даними?

Одне з варіантів, про яке я думав, - це мати базу даних клієнта на кожному додатку, яка б якось синхронізувалась між додатками, я можу бачити, що це дуже ненадійно і все стає брудно.

Багато банальної інформації зберігається в базах даних. Насправді центральна база даних є, мабуть, найбільш безпечним способом зберігання цих даних. У великих базах даних підприємства є багато функцій, щоб робити такі речі, як шифрування конфіденційної інформації, перевіряти, хто до неї звертається, обмежувати або не дозволяти людям, включаючи DBA, переглядати дані тощо. що ви не втрачаєте дані. Майже напевно було б набагато простіше компрометувати дані, що зберігаються на мобільному пристрої чи ноутбуці якогось випадкового користувача, ніж проникнути у добре розроблену інфраструктуру безпеки та поставити під загрозу належну центральну базу даних.

Ви можете розробити систему з центральною базою даних, яка зберігає лише зашифровані дані та зберігає приватний ключ користувача на пристрої користувача. Таким чином, навіть якщо центральна база даних повністю порушена, ці дані можуть бути використані лише користувачем. Звичайно, це означає, що ви не можете відновити дані користувача, якщо вони втрачають ключ (скажімо, єдиний примірник був на їх телефоні, а їхній телефон пошкоджений). І якщо хтось скомпрометує ключ та, імовірно, свої облікові дані для входу, він зможе побачити дані.

Вам потрібно створити резервну копію декількох кроків і, консультуючись із клієнтом, розробити модель загрози . (Так, це посилання на 600-сторінкову книгу; так, я серйозно рекомендую прочитати всю справу.)

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

• Чому додатку потрібно зберігати ці конфіденційні дані?
  • Чи можете ви взагалі уникнути його зберігання?
  • Чи можна його викинути через короткий час?
  • Чи дійсно потрібно бути доступним для більш ніж одного пристрою?
  • Якщо він повинен бути доступним на декількох пристроях, чи потрібно його зберігати на більш ніж одному пристрої?
• Хто такі люди, яким дозволено переглядати конфіденційні дані кожного користувача?
  • Чи можна цей список скоротити?
• Хто такі люди, які можуть контактувати з конфіденційними даними кожного користувача, намагаючись виконувати свою роботу, але не потрібно їх знати?
  • Чи можна цей список скоротити?
  • Чи можна зробити їх недоступними без шкоди для їхньої здатності виконувати свою роботу?
  • Якщо він не може бути недоступним, чи можна принаймні зробити його незрозумілим? (Це те, що робить шифрування в рефераті: воно робить дані незрозумілими.)
• Хто такі люди, які хочуть бачити конфіденційні дані, але їх заборонено?
  • Які можливості вони мають отримати за даними?
  • Що вони хочуть зробити з даними, як тільки вони їх мають?
  • Наскільки вони будуть розлючені, якщо не отримають того, що хочуть?
  • Скільки грошей, часу, циклів процесора та людських зусиль вони готові витратити?
  • Чи їм байдуже, якщо хтось знає, що бачив дані?
  • Вони хочуть отримати доступ до конфіденційних даних конкретних користувачів , чи це зробить хтось?
  • Що вони вже знають?
  • До чого вони вже мають доступ?

Як тільки ви дізнаєтесь відповіді на ці запитання, ви опинитеся, що робити.

Майте на увазі, що на кожен набір питань може бути більше однієї відповіді, особливо тих, що стосуються зловмисників (людей, які хочуть конфіденційні дані, але вони не мають їх мати). Якщо ви не можете придумати принаймні півдюжини різних архетипних нападників, що мають різні мотивації, цілі та ресурси, ви, мабуть, щось пропустили.

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

Одним із варіантів зробити синхронізацію буде зробити це одноранговий. Це все ще потребує центрального сервера, але цей сервер не обробляє жодну з даних.

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

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

Зробіть це чиєюсь проблемою.

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

Це створює вигляд, що користувачі володіють власними даними, оскільки їм доводиться ввімкнути синхронізацію даних. Це робить додатки корисними для людей, які не хочуть, щоб жодного спільного доступу не було. І це робить когось іншого відповідальним (технічно та, можливо, юридично) за постійні головні болі щодо збереження будь-яких спільних даних.

Напевно, стурбованість вашого клієнта пов'язана з видимістю цих даних. Перше питання, яке потрібно задати своєму клієнту, - якщо дані були зашифровані, де їх можна зберігати? Потім запитайте свого клієнта, які види контролю доступу вони хочуть застосувати, перш ніж дані можуть бути розшифровані та оброблені - де можна зберігати ключ розшифровки? це окремий ключ на кожного користувача? тощо ...

Якщо ваш клієнт не хоче, щоб дані, що зберігаються де-небудь, хочуть, щоб користувач щоразу вводив його в мою руку?