Experience Sharing: OpenGauss 5 0 0 fully encrypted database application test

Mondo Technology Updated on 2024-01-29

Introduction:

Last year, when I learned about the security features of the OpenGauss database, I learned that the full density state and other query-only features, in fact, OpenGauss was in the early 10.Version 0 introduces the all-dense equivalent query feature, and the following tries to opengauss 50.The use of the full secret state of version 0 is recorded for reference.

Fully Dense Database:

The introduction of the fully dense database on the official website is as follows:

The encrypted database is intended to solve the privacy protection problem of the whole life cycle of data, so that no matter what business scenario and environment the system is in, the data is always in the ciphertext state in all aspects of transmission, computing and storage. When the data ownerComplete data encryption on the client sideAfter it is sent to the server, the attacker still cannot obtain effective value information when the attacker steals user data with the help of system vulnerabilities, so as to protect data privacy.

See the official website: The key point is that OpenGauss encrypts the data on the client side, as shown in the figure below, in order to ensure that it is ciphertext in the transmission, calculation and storage process, and it is intercepted or stolen by the destroyer in time, and only the encrypted data can be seen to avoid data leakage.

The data security of the cloud database can be ensured through the fully encrypted data, and attackers cannot obtain valid data from the server. Based on this, it can provide technical support for cloud service providers to win customer trust.

Application of Fully Dense Database:

The application of a fully encrypted database can be roughly divided into the following steps: key creation, encryption table creation, and full encryption query.

1.Key Creation:

Determine the key storage path:

Add environment variables: Make sure that the path where you plan to store the key file exists and that the user of the database created by the system (in this case, OMM) has the editing permission, as shown in the following figure

For simplicity, you can grant permissions with the following statement:

chmod -r 777 opt software opengauss add environment variable:

export localkms file path= opt software opengauss is executed and the file is generated:

gsql to connect to a fully dense database, gsql -p 5432 -d postgres -r c

where -c indicates that the secret state switch is turned on.

Create a user key, where the key includes CMK and CEK. The CMK is the master key and is used to encrypt the CEK;Whereas, CEK is the data key, which is used to encrypt data. The creation of CEK depends on the CMK, so you need to create the CMK first and then create the CEK.

Create a cmk:

create client master key imgcmk with (key_store = localkms, key_path = "key_path_value", algorithm = rsa_2048);Create Client Master Key: Currently, the key store supports only localkms, and the algorithm supports RSA 2048, RSA3072, and SM2

Create cek:

create column encryption key imgcek with values (client_master_key = imgcmk, algorithm = aead_aes_256_cbc_hmac_sha256);create column encryption key

Important note: Since SM2, SM3, SM4 and other algorithms belong to China's national cryptography standard algorithms, they need to be used in conjunction with each other in order to avoid legal risks. If you specify the SM4 algorithm to encrypt the CEK when you create the CMK, you must specify the SM4 SM3 algorithm to encrypt the data when you create the CEK.

Query the key created:

select * from gs_client_global_keys;

select column_key_name,column_key_distributed_id ,global_key_id,key_owner from gs_column_keys;

Encrypted table creation:

Create another database user:

create user fishinwater identified by "***";(The actual password is hidden).

2.Create an encrypted table:

create table creditcard_info (id_number int, name text encrypted with (column_encryption_key = imgcek, encryption_type = deterministic),credit_card varchar(19) encrypted with (column_encryption_key = imgcek, encryption_type = deterministic));

Note: For columns that need to be encrypted, say encrypted with ......The optional value of encryption type value is [ deterministic |randomized], in this case, deterministic.

Looking at the dense table created above, you can see that the last two columns are encrypted:

d creditcard_info

Insert into creditcard info values (1,.'joe','6217986500001288393');insert into creditcard_info values (2, 'joy','6219985678349800033');I won't take a screenshot, it's just a simple insert statement.

3.Fully Dense Equivalent Query:

Turn on the dense state switch.

If the secret state switch is turned on, the "-C" parameter is used when connecting, and if JDBC is connected, the value of the parameter enable ce is set to 1: (enable CE=1).

If the secret state switch is turned on, the data can be queried normally, as follows:

select * from creditcard_info;

You can also query with an encrypted field in the where condition:

select * from creditcard_info where name = 'joe';

Turn off the dense state switch:

gsql -p 5432 -d postgres r If the "-c" parameter is not included, the queried data is ciphertext and encrypted columns cannot be used in the where condition.

If you use an encrypted column in the condition, the following error message will be reported:

Queried ciphertext data:

4.Other database user queries:

If a user who has been granted the query permission (in this case, Fishinwater) cannot query encrypted data even if the encryption switch is enabled, the following error message is displayed: error(client): failed to decrypt column encryption key

However, it is normal to only query non-encrypted columns, and there are no drawings due to space limitations.

When the secret switch is not turned on, the ciphertext is queried, which is the same as the effect of the user who created the secret key without punching the secret switch, and the accompanying diagram is no longer explained.

It should be noted that there are quite a few constraints to the use of fully encrypted databases, and compared to previous versions, OpenGauss 50.The constraints of version 0 have changed, and will not be repeated in this article, you can refer to the official website description.

Conclusion:

The fully encrypted database provides more options for the protection of users' sensitive privacy data, and will be regarded as an important feature of OpenGauss as an important feature of OpenGauss and provide an important technical foundation for the further growth of OpenGauss in today's increasingly important information protection and data security.

Recommended in the pastOfficially announced!OpenGauss Summit 2023 invites you to attend.

Related Pages