Klustron Log File Encryption Feature Introduction and Test Cases
Klustron Log File Encryption Feature Introduction and Test Cases
Note:
Unless specifically stated otherwise, the version numbers mentioned in the text can be substituted with any released version number. For a list of all released versions, please visit: http://doc.klustron.com/zh/Release_notes.html
Objective of this Article:
The primary focus of this article is to introduce the feature of database log file encryption. It covers how to install the log file encryption plugin in Klustron, the steps to enable log file encryption settings, and then conducts tests on the usage of log file encryption. These tests include directly comparing the data content of encrypted and unencrypted log files at the operating system level. Finally, the article also examines and verifies that log encryption does not affect data synchronization among storage nodes, demonstrating that the encryption of logs is transparent to data synchronization.
01 The Purpose and Features of Klustron Log Files
The binary log (Binlog) of Klustron is a crucial component for recording changes made to the database. Its purpose and features are as follows:
1.1 Purpose of Binlog
a) Data Recovery and Backup: Binlog logs all change operations in the database, including INSERT, UPDATE, and DELETE actions. This makes Binlog a key tool for restoring the database to a previous state. By analyzing Binlog, you can restore the database to a specific point in time, facilitating data recovery and backup.
b) Database Replication: Binlog plays a pivotal role in database replication. The primary database transmits Binlog events to the secondary database, achieving Master-Slave Replication. This allows the secondary database to stay synchronized with the primary database, serving purposes such as read operation load balancing, failover, and data distribution.
c) Data Auditing and Tracking: Binlog can be used to track change operations in the database for data auditing and monitoring. It records who modified what data in the database and when.
d) Data Migration: Binlog can also be used for data migration between different MySQL servers. By applying Binlog events to the target database, data can be copied from one server to another.
1.2 Features of Binlog
a) Records All Change Operations: Binlog records every change operation in the database in binary format, including SQL statements and their corresponding data. This makes it very powerful for restoring the database to any point in time.
b) Scalability: Binlog can be configured to log events in different ways, including full statement events, row events, and mixed mode. This provides Binlog with greater flexibility in various scenarios.
c) Asynchronous Logging: Binlog is logged asynchronously, meaning it does not significantly impact the write performance of the database. Write operations return immediately, while Binlog events are logged in the background asynchronously.
d) Customizability: Administrators can configure various parameters of Binlog, such as size, retention period, and naming conventions, to meet different needs and strategies.
e) Security: Binlog files are typically located on the server and protected by access permissions to prevent unauthorized access.
f) Versatile Use: Binlog is used not only for backup and recovery but also for real-time replication, data synchronization, data migration, performance analysis, and data auditing, among other purposes.
It is important to note that while Binlog is highly useful, it also requires careful use and management. Proper configuration and maintenance of Binlog are key steps to ensuring the stability and security of the database.
02 Klustron Binlog Encryption Features
Klustron's binary log (Binlog) is typically not encrypted in its original form. The Binlog records database modifications such as INSERT, UPDATE, DELETE operations, facilitating database replication, backup, and recovery purposes. However, encrypting Binlog data is a useful security measure to prevent unauthorized access or leakage of sensitive information.
Features of Binlog Encryption:
a) Data Protection: Since the Binlog contains critical change history of the database, encryption helps protect sensitive data from unauthorized access and leaks.
b) Enhanced Security: Encrypting the Binlog enhances the overall security of the database system. Even if attackers gain access to Binlog files, they cannot easily decrypt the contents.
c) Compliance Requirements: For organizations that need to meet specific compliance requirements (such as GDPR, HIPAA, etc.), encrypting Binlog data may be necessary.
d) Performance Overhead: Encrypting and decrypting data can introduce some performance overhead, especially under high load conditions. Therefore, a balance between security and performance needs to be considered.
e) Management and Maintenance: Implementing Binlog encryption requires managing keys and certificates, as well as ensuring the encryption components are correctly configured and operational. This necessitates additional administrative and maintenance efforts.
03 Klustron Installation of Encryption Plugin and Enabling Binlog Encryption
3.1 Connect to the storage node to check if Binlog log file encryption is currently enabled.
[root@kunlun2 ~]# su – Kunlun
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57005/kunlun-storage-1.2.1/dba_tools/
[kunlun@kunlun2 dba_tools]$ ./imysql.sh 57005
mysql> show variables like '%binlog_encryption%';
mysql> show binary logs;
Binlog log files are not encrypted at the moment.
3.2 Install the encryption plugin on the storage node and create a directory for storing the encryption keyring file at /kunlun/mysql-keyring/.
[root@kunlun2 ~]# su - kunlun
[kunlun@kunlun2 ~]$ mkdir /kunlun/mysql-keyring/
3.3 Modify the configuration file on all storage nodes, incorporating the following changes:
[kunlun@kunlun2 ~]$ vi /kunlun/storage_datadir/57003/data/57003.cnf
early-plugin-load=keyring_file.so
keyring_file_data=/kunlun/mysql-keyring/keyring
binlog_encryption=on
3.4 All storage node configuration files need modifications, for instance, the following two files are also modified as per step 3.3.
[kunlun@kunlun2 ~]$ vi /kunlun/storage_datadir/57005/data/57005.cnf
[kunlun@kunlun2 ~]$ vi /kunlun/storage_datadir/57007/data/57007.cnf
3.5 After modifying the configuration files, restart the storage nodes.
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57003/kunlun-storage-1.2.1/dba_tools
[kunlun@kunlun2 ~]$ ./stopmysql.sh 57003
[kunlun@kunlun2 ~]$ ./startmysql.sh 57003
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57005/kunlun-storage-1.2.1/dba_tools
[kunlun@kunlun2 ~]$ ./stopmysql.sh 57005
[kunlun@kunlun2 ~]$ ./startmysql.sh 57005
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57007/kunlun-storage-1.2.1/dba_tools
[kunlun@kunlun2 ~]$ ./stopmysql.sh 57007
[kunlun@kunlun2 ~]$ ./startmysql.sh 57007
3.6 Verify the successful installation of the encryption plugin after restarting the storage nodes.
[kunlun@kunlun2 ~]$ mysql -h 192.168.56.113 -P57003 -upgx -ppgx_pwd
mysql> select * from information_Schema.plugins where plugin_name like '%keyring_file%'\G
mysql> show global variables like '%keyring%';
3.7 Check that the keyring file has been generated, completing the installation of the encryption plugin.
[kunlun@kunlun2 ~]$ ls -l /kunlun/mysql-keyring
3.8 Verify that the Binlog encryption settings have been successfully enabled.
[root@kunlun2 ~]# su – Kunlun
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57005/kunlun-storage-1.2.1/dba_tools/
[kunlun@kunlun2 dba_tools]$ ./imysql.sh 57005
mysql> show variables like '%binlog_encryption%';
mysql> show binary logs;
The encryption plugin has been successfully installed and Binlog log file encryption enabled.
04 Binlog Log File Encryption Test Case
This section presents a test case for Binlog log file encryption. After enabling Binlog log file encryption, it compares the content of the log files when encryption is not enabled versus when it is enabled. The comparison involves directly viewing the file contents at the operating system level for both types of logs.
4.1 Connect to the storage node to check if Binlog log file encryption is currently enabled.
[root@kunlun2 ~]# su – Kunlun
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57005/kunlun-storage-1.2.1/dba_tools/
[kunlun@kunlun2 dba_tools]$ ./imysql.sh 57005
mysql> show variables like '%binlog_encryption%';
mysql> show binary logs;
4.2 By directly viewing the unencrypted binlog log system file from the operating system level (unencrypted file: biglog.000012), one can directly see the plaintext information of the data stored in the file.
[root@kunlun2 ~]# su - kunlun
[kunlun@kunlun2 ~]$ hexdump -C /kunlun/storage_logdir/57005/binlog/binlog.000012
4.3 By directly viewing the encrypted binlog log system file from the operating system level (encrypted file: biglog.000014), it is observed that the data stored in the file is encrypted and the file's data information cannot be accessed.
[root@kunlun2 ~]# su - kunlun
[kunlun@kunlun2 ~]$ hexdump -C /kunlun/storage_logdir/57005/binlog/binlog.000014
Viewing the encrypted binlog log system file shows ciphertext, preventing access to the plaintext data information and ensuring the security of the binlog log data.
05 Binlog Log Encryption Transparency Test Case for Storage Node Data Synchronization
After the encryption of Binlog logs, when accessing the database from a compute node, such as creating tables and inserting data into them, it's important to verify that Binlog log encryption does not affect data synchronization among storage nodes. The synchronization should be transparent, with tables and data being able to sync across all database storage nodes.
5.1 Connect to the database, create a database user, create a test database, and grant permissions to the user.
[root@kunlun1 ~]# su - kunlun
[kunlun@kunlun1 ~]$ psql -h 192.168.56.112 -p 47001 postgres
create user kunlun_user1 with password 'kunlun';
create database testdb_binlog;
grant all privileges on database testdb_binlog to kunlun_user1;
\c testdb_encypt kunlun_user1
5.2 Create an 'emp' data table and insert data into it.
CREATE TABLE emp (
empid int,
empname varchar(50),
salary int
);
insert into emp (empid,empname,salary) values(1001,'test',5000);
insert into emp (empid,empname,salary) values(1002,'admin',8000);
insert into emp (empid,empname,salary) values(1003,'operator',10000);
insert into emp (empid,empname,salary) values(1004,'auditor',12000);
insert into emp (empid,empname,salary) values(1005,'viewer',9000);
insert into emp (empid,empname,salary) values(1006,'test2',6000);
5.3 Connect to the storage node on 57005 to view the data in the 'emp' table.
[root@kunlun2 ~]# su - kunlun
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57005/kunlun-storage-1.2.1/dba_tools
[kunlun@kunlun2 dba_tools]$ ./imysql.sh 57005
mysql> use testdb_binlog_$$_public
mysql> select * from emp;
5.4 Connect to the storage node on 57007 to view the data in the 'emp' table.
[root@kunlun2 ~]# su - kunlun
[kunlun@kunlun2 ~]$ cd /kunlun/instance_binaries/storage/57007/kunlun-storage-1.2.1/dba_tools
[kunlun@kunlun2 dba_tools]$ ./imysql.sh 57007
mysql> use testdb_binlog_$$_public
mysql> select * from emp;
By viewing the tables and data across various storage nodes, it is verified that Binlog log encryption does not affect the data synchronization among storage nodes. The synchronization is transparent, with tables and data being able to sync across all database storage nodes.
The Binlog encryption test is completed.