Способы защиты пользовательских данных?

Question

[Фёдор]

Приветствую!

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

Answer 1

[Петр]

То, что не нужно — не хранить. То, что нужно хранить:
— шифровать. (как вариант, можно использовать прозрачное шифрование, как в Oracle или MS-SQL — для приложений ничего не изменится).
— хранить хэши.
— хранить токены (ссылки) (отдельные таблицы для соответствия (токен-данные), данные которых будут шифроваться).

Answer 2

[Ярослав]

Дополнительно к вышесказанному — попробовать изолировать их, хранить на отдельном сервере DB (чтобы на нем ничего не крутилось, через что поломать могут) и либо строго залимитировать доступ правами СУБД (если субд позволяет такое), либо вообще прямой доступ к базе отключить (только с локалхоста), а работа с ней — через свой API (хотя бы в виде простого PHP скрипта) который может иметь функции только для нужных операций.

Например, посчитать всех пользователей из города Урюпинск. (выдает цифру, но не дает сами данные по пользователям).
Если нужно именно получение данных из базы (напр всех данных по пользователю), тот же API может выдавать их, но не более 100 пользователей за день для одного оператора. Этого достаточно для работы, но нельзя будет «высосать» всю базу через «SELECT * FROM table».

Answer 3

[moonsly]

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

Answer 4

[mrstrictly]

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

select a.*, p.* from account a join personal_data p on a.encrypted_pdata_fk = encrypt(p.id, <соль>):

Answer 5

[Всеволод]

Можно зашифровать по столбцам. Т.е. на каждый столбец отдельный ключ. В таком случае можно искать, правда только по целому значению, а не с помощью LIKE.
Примерно так:
select * from user where email = AES_ENCRYPT($email,$email_key)

Ключи храним где-то в укромном месте.

Answer 6

[kenny_opennix]

Может быть зашифровать базу данных? тогда уже никто не доберется :)

Answer 7

[joneleth]

Слишком размыто. От чего защищаемся-то?

Comments

[Фёдор]

От компрометации сервера, базы, приложения. От всего, в общем :)

[joneleth]

От всего == ни от чего. В правильно заданном вопросе содержится половина ответа. Определите четко задачу. Вы оператор персональных данных? Вам требуется соответствие закону?
Если у вас руководству просто «безопасность» ударила в голову, ну обратите внимание на индустриальные стандарты, тот же PCI.

[Фёдор]

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

[joneleth]

Вы сейчас описали, наверное, все сервисы в интернете. Вы же не думаете, что у них у всех должны быть одинаковые меры по безопасности?
Допустим, у вас архитектура LAMP (а может нет?). Начинаем гуглить: Linux security best practice, Apache security best practice итд.
Обязательна установка обновлений, антивирус если нужно, правильно настроенный файрвол итп.
Далее, возможно ли физически снять и унести сервер? Если да, то что вы этому можете противопоставить?
Если само приложение дырявое, то никакие меры не помогут, соответственно нужно пройтись по нему стандартными сканнерами, потом сесть, продумать возможные атаки, проверить, работают ли они, пофиксить. Потом можно заказать security audit.

Нету рецепта одного на всех, нужно думать головой.

[Фёдор]

Это всё довольно очевидно. Меня больше интересовали способы вроде тех, что предложили выше, то есть на уровне базы данных и приложения. Для простоты, предположим, что сервер точно будет скомпрометирован. В таком случае, как её лучше шифровать, какими алгоритмами, где и как хранить ключи (очевидно, где-то в другом месте), как снизить расходные ресурсы на это, какие базы данных лучше для этого подходят? Если есть опыт — поделитесь, пожалуйста. Статьи и книги тоже подойдут :)

[joneleth]

Есть опыт. Никак.