Ways to protect user data?

Question

Database

Greetings!
Let's assume that some user data "live" in the database. It is necessary to depersonalize and protect this data as much as possible. An important condition is the ability to work with this data (sort, search), i.e. this is not a file whose contents can be encrypted and put, but why decrypt with a client key. What ways do you know? The easiest way is, of course, to store a minimum of information about the user himself, thereby “clearing” the data, but at least you need to know the email (for example, for registration).

Answer 1

What is not needed - do not store. What needs to be stored:
— encrypt. (alternatively, you can use transparent encryption, as in Oracle or MS-SQL - nothing will change for applications).
- store hashes.
- store tokens (links) (separate tables for matching (token-data), the data of which will be encrypted).

Answer 2

In addition to the above, try to isolate them, store them on a separate DB server (so that nothing spins on it, through which they can break) and either strictly limit access to the rights of the DBMS (if the DBMS allows this), or disable direct access to the database altogether (only with localhost), and working with it - through its own API (at least in the form of a simple PHP script) which can have functions only for the necessary operations.
For example, count all users from the city of Uryupinsk. (gives out a figure, but does not give the user data itself).
If you need to get data from the database (for example, all user data), the same API can issue them, but not more than 100 users per day for one operator. This is enough to work, but it will not be possible to "suck out" the entire database through "SELECT * FROM table".

Answer 3

Leave in the database / files in open form only the data that needs to be searched (make them indexes). Searching through encrypted data without indexes is hardly possible.
Encrypt / decrypt the rest of the data by key, or if the data only needs a compliance check (passwords), then MD5 or a similar hash.

Answer 4

One option is to split personal data into key-value tables, where the key is a randomly generated value, the value is an element of personal data (phone number, passport data, address, etc.). Further, these tables, if desired, can be moved by moving them, for example, to a separate "as if-more-protected" instance. With special paranoia, the foreign key to personal data, which is stored in the table with the user, can be encrypted and re-encrypted in accordance with the specified policy. Thus, a request for a selection of personal data begins to look like this:

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

Answer 5

You can encrypt by columns. Those. Each column has a separate key. In this case, you can search, though only by an integer value, and not using LIKE.
Something like this:
select * from user where email = AES_ENCRYPT($email,$email_key)
We store the keys somewhere in a secluded place.

Answer 6

Maybe encrypt the database? Then no one else will. :)

Answer 7

Too blurry. What are we protecting ourselves from?