Как отделить личность человека из своих личных данных?

https://stackoverflow.com/questions/3691348

02-10-2019
|

Вопрос

Я пишу приложение, какую основную цель состоит в том, чтобы сохранить список покупок пользователей.

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

Я изначально придумал следующую схему:

 ------------------------------ + ------------ user_hash | Предмет |. Цена ---------------- + -------------- + ------------ A45CD654FE810 | Стриптиз-клуб | 400.00 A45CD654FE810 |. Ferrari |. 1510800.00 54da2241211c2 |. Пиво |. 5,00 54DA2241211C2 |. iPhone |. 399.00

Пользователь входит в систему с именем пользователя и паролем.
Из пароля рассчитать user_hash (Возможно, с солей и т. Д.).
Используйте хеш для доступа к данным пользователя с обычными SQL-запросами.

Учитывая достаточно пользователей, должно быть почти невозможно сказать, сколько денег потратил особый пользователь, просто зная его имя.

Это разумная вещь, которую нужно сделать, или я полностью глупо?

Решение

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

Нет абсолютно никакого способа предотвращения этого.

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

Теперь, что сказано, что многие компании разделяют сотрудников по разработке и производству. Цель состоит в том, чтобы удалить разработку от непосредственного контакта с Live (IE: REAL) DATA. Это имеет ряд преимуществ с безопасностью и надежностью данных в верхней части кучи.

Единственный реальный недостаток в том, что немного Разработчики считают, что они не могут устранить проблему без доступа до доступа. Однако это просто не правда.

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

Точка всего этого в том, что это проблема персонала; И не тот, который действительно может быть решен с техническими средствами.

ОБНОВИТЬ

Другие здесь, похоже, отсутствуют очень важный и жизненно важный кусок головоломки. А именно, что данные вводятся в систему по причине. Эта причина почти повсемена, так что его можно поделиться. В случае отчета об расходе, что данные вводятся, так что бухгалтерский учет может знать, кто для оплаты.

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

И из-за того, что данные должны быть связаны вместе без всех задействованных сторон, стоящих там, чтобы ввести код безопасности, чтобы «выпустить» данные, то DBA будет абсолютно сможет просматривать журналы запроса, чтобы выяснить, кто является тем, кто является кем. И очень легко я могу добавить независимо от того, сколько хеш-следов вы хотите бросить в него. Triple Des тоже не спасет вас.

В конце дня все, что вы сделали, делает развитие сложнее с абсолютно нулевой полезной безопасностью. Я не могу подчеркнуть этого достаточно: единственный способ скрыть данные от DBA, либо 1. Эти данные Только Будьте доступны тем человеком, который вошел в него или 2. Для него не существует в первую очередь.

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

Другие советы

Боюсь, что если ваше приложение может связать человека к своим данным, любой разработчик / админ может.

Единственное, что вы можете сделать, затрудняет выполнение ссылки, замедлить разработчик / admin, но если вы затрудняете ссылку пользователей к данным, вы сделаете его уже сложнее для вашего сервера.

Идея на основе идеи @no:

Вы можете иметь классический вход в систему пользователя / пароль в своем приложении (Hashed Password, или что-то еще), а специальный «проход», используемый для сохранения ваших данных. Этот «проход» не будет храниться в вашей базе данных.

Когда ваш клиент входит в ваше приложение, мне придется предоставить пользователю / пароль / пропуск. Пользователь / пароль проверяется с базой данных, и проход будет использоваться для загрузки / записи данных.

Когда вам нужно написать данные, вы делаете хеш из вашего «имя пользователя / пароль», и храните его в качестве ключа, связывающего свой клиент к вашим данным.

Когда вам нужно загрузить данные, вы делаете хеш из вашего «имена пользователя / пароля», и загрузите все данные, соответствующие этому хэш.

Таким образом, невозможно сделать связь между вашими данными и вашим пользователем.

В другой руке, (как я сказал в комментарии к @no) Остерегайтесь столкновения. Отказ Плюс, если ваш пользователь пишут плохой «проход», вы не можете это проверить.

Обновление: Для последней части у меня была другая идея, вы можете хранить в вашей базе данных HASH вашего «Pass / Password», таким образом, вы можете проверить, хорошо ли ваш «проход».

Создайте таблицу пользователей с:
1. user_id: столбец идентификации (автоматически сгенерированный ID)
2. имя пользователя
3. Пароль: Убедитесь, что он хэш!
Создайте таблицу продукта, как в вашем примере:
1. user_hash.
2. пункт
3. цена

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

Теперь вам нужен способ использовать user_id в user_hash и сохранить его защищенным.

Если вы сделаете это клиенту, так как @NO предложил, клиент должен иметь user_id. Большое охранное отверстие (особенно если это веб-приложение), хеш может быть легко подделан и алгоритм свободно доступен для общественности.
Вы можете иметь его как функцию в базе данных. Плохая идея, поскольку база данных имеет все части, чтобы связать записи.
Для веб-сайтов или приложений клиента / сервера вы можете получить его на стороне сервера. Гораздо лучше, но у одного разработчика имеет доступ к алгоритму и данным хеширования.
Попросите другого разработчика пишут алгоритм хеширования (который у вас нет доступа к) и придерживайтесь на другом сервере (который у вас также нет доступа к) как службу TCP / WEB. Затем ваш серверный код будет передавать идентификатор пользователя и вернуть хеш. У вас не будет алгоритма, но вы можете отправить все идентификаторы пользователей, чтобы вернуть все свои хеси. Не много преимуществ № 3, хотя сервис может иметь вход в систему и такому попытаться минимизировать риск.
Если это просто приложение Client-Database, у вас есть только выбор № 1 и 2. Я настоятельно рекомендую добавить другой слой [Business], который является стороной Server, отдельно от сервера базы данных.

Редактировать:Это перекрывает некоторые из предыдущих точек. У 3 серверов:

Сервер аутентификации: Сотрудник A имеет доступ. Поддерживает таблицу пользователя. Имеет веб-сервис (с зашифрованными коммуникациями), который принимает комбинацию пользователя / пароль. Пароль хэшей, выглядит User_id в таблице, генерирует user_hash. Таким образом, вы не можете просто отправить всех user_ids и вернуть хеши. Вы должны иметь пароль, который не сохраняется никуда не хранится и доступен только во время процесса аутентификации.
Основная база данных сервера: Сотрудник B имеет доступ. Только магазины user_hash. Нет пользователя, без паролей. Вы можете связать данные, используя user_hash, но фактическая информация о пользователе - где-то еще.
Сервер сайта: Сотрудник B имеет доступ. Получает информацию для входа в систему, проходит к серверу аутентификации, возвращает HASH назад, а затем утилизирует информацию о входе. Сохраняет хэш в сессии для написания / запроса к базе данных.

Таким образом, сотрудник A имеет user_id, имя пользователя, пароль и алгоритм. Сотрудник B имеет user_hash и данные. Если сотрудника B не модифицирует сайт для хранения RAW User / Password, он не имеет способа связать с реальными пользователями.

Использование профилирования SQL, сотрудника A получит USER_ID, имя пользователя и пароль HASH (поскольку user_hash генерируется позже в коде). Сотрудник B будет получать user_hash и данные.

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

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

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

Это заканчивается социальной проблемой, а не технологической проблемой. Лучшие решения будут социальным решением. После затвердевания ваших систем для защиты от несанкционированного доступа (хакеров и т. Д.) Вы, вероятно, получите лучший пробег, работая над установлением доверия к своим пользователям и реализации системы политики и процедур в отношении безопасности данных. Включите определенные штрафы для сотрудников, которые неправильно используют информацию о клиентах. Поскольку единственное нарушение доверия клиентов достаточно, чтобы испортить вашу репутацию, и вытеснить всех своих пользователей, искушение неправильного использования эти данные с помощью «с доступом высшего уровня» меньше, чем вы можете подумать (поскольку обвал компании обычно обычно перевешивает любую выгоду).

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

По этой причине, когда вы не определите медицинские записи (для использования в исследованиях и таком), вы должны убрать рождения для людей более 89 лет (потому что люди, которые старые, достаточно редки, чтобы особый родитель мог указать на одного человека) И удалить любое географическое кодирование, которое определяет площадь, содержащую менее 20 000 человек. (Видеть http://privacy.med.miami.edu/glossary/xd_deyentified_health_info.htm.)

AOL выяснил трудный способ, когда они выпустили данные поиска, что люди могут быть идентифицированы, просто узнав, что поиски связаны с анонимным человеком. (Видеть http://www.fi.muni.cz/kd/events/cikhaj-2007-jan/slides/kumpost.pdf.)

Похоже, вы правы на треке с этим, но вы только что думаете об этом (или я просто не понимаю этого)

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

Используйте возвращенную строку в качестве соли при наращивании хеша пользователя (снова я бы использовал UserID или имя пользователя в качестве ввода для Hahh Builder, потому что они не изменится, как пароль пользователя или электронная почта)

Свяжите все пользовательские действия с пользовательским хэшем.

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

Я думаю, что вы ответили вам на вопрос с вашим начальным постом.

На самом деле, есть способ, которым вы могли бы сделать то, о чем вы говорите ...

У вас может быть введите его имя и пароль в форму, которая запускает чисто клиентский скрипт, который генерирует хеш на основе имени и PW. Этот хеш используется в качестве уникального идентификатора для пользователя и отправляется на сервер. Таким образом, сервер знает только пользователя Hash, а не по имени.

Ибо это работать, однако, хеш должен быть отличаться от обычного пароля HASH, и пользователь потребуется для ввода их имени / пароля дополнительное время до того, как сервер будет иметь какую-либо «память» того, что купил этот человек.

Сервер может вспомнить, что человек купил в течение длительности их сеанса, а затем «забыть», потому что база данных не будет содержать связь между учетными записями пользователей и конфиденциальной информацией.

редактировать

В ответ на тех, кто говорит хеширование на клиенте, является риском безопасности: это не если вы делаете это правильно. Следует предположить, что хеш-алгоритм известен или понимается. Сказать в противном случае, составляет «безопасность посредством безвестности». Hashing не включает в себя какие-либо частные ключи, а динамические хэши могут быть использованы для предотвращения вмешательства.

Например, вы берете хеш-генератор, как это:

http://baagoe.com/en/randommusines/javascript/mash.js.

// From http://baagoe.com/en/RandomMusings/javascript/
// Johannes Baagoe <baagoe@baagoe.com>, 2010
function Mash() {
  var n = 0xefc8249d;

  var mash = function(data) {
    data = data.toString();
    for (var i = 0; i < data.length; i++) {
      n += data.charCodeAt(i);
      var h = 0.02519603282416938 * n;
      n = h >>> 0;
      h -= n;
      h *= n;
      n = h >>> 0;
      h -= n;
      n += h * 0x100000000; // 2^32
    }
    return (n >>> 0) * 2.3283064365386963e-10; // 2^-32
  };

  mash.version = 'Mash 0.9';
  return mash;
}

Смотри как n Изменения, каждый раз, когда вы хешаете строку, вы получаете что-то другое.

Хэш имена пользователя + пароль с использованием нормального хэш-алго. Это будет совпадать с ключом «секретный» таблиц в базе данных, но ничего не будет сочетать в базе данных.
Добавьте Hashed Pass в имя пользователя и хеш с вышеуказанным алгоритмом.
Кодирование базы 16 var n И добавить его в оригинальное хеш с характером разделителя.

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow