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

Question

Я пишу приложение, главная цель которого - сохранить список пользователей покупок.

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

Первоначально я придумал следующую схему:

 
    --------------+------------+----------- 
    user_hash  | item  | price 
    --------------+------------+----------- 
    a45cd654fe810 | Strip club |  400.00 
    a45cd654fe810 | Ferrari | 1510800.00 
    54da2241211c2 | Beer  |  5.00 
    54da2241211c2 | iPhone  |  399.00 

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

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

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

Answer 1

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

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

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

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

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

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

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

---

UPDATE

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

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

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

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

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

Answer 2

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

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

---

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

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

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

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

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

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

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

---

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

Answer 3

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

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

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

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

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

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

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

http://baagoe.com/en/RandomMusings/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 изменения, каждый раз, когда вы хэш строки вы получаете что-то другое.

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

• сервер аутентификации: Сотрудник А имеет доступ. Поддерживает таблицу пользователя. Имеет веб-сервис (с зашифрованной связью), который использует комбинацию пользователя/пароля. Hashes password, ищет user_id в таблице, генерирует user_hash. Таким образом, вы не можете просто отправить все user_id и вернуть хеши. У вас должен быть пароль, который не хранится нигде и доступен только во время процесса аутентификации.
• Главный сервер базы данных: Сотрудник B имеет доступ. Сохраняет только user_hash. Нет идентификатора пользователя, нет паролей. Вы можете связать данные с помощью user_hash, но фактическая информация пользователя находится где-то в другом месте.
• Сайт сервера: Сотрудник B имеет доступ. Получает информацию о входе в систему, переходит на сервер аутентификации, получает хеш-назад, а затем располагает информацией о входе в систему. Сохраняет хэш в сеансе для записи/запроса в базу данных.

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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