Database trusted replication and key distribution method and system

Abstract

The application provides a database trusted replication and key issuing method and system, which comprises the following steps: a database instance is started in a trusted execution environment and generates a remote attestation report; the database instance sends the generated remote attestation report to an attestation naming service for registration; the attestation naming service verifies whether the received remote attestation report meets preset database instance registration conditions; when a master database instance is ready to send a replication log to a replica database instance, the attestation naming record of the replica database instance is queried from the attestation naming service according to the domain name of the replica database instance, and it is verified whether the attestation naming record of the replica database instance meets preset replica database instance replication conditions; when a key management system is ready to send a key to a database instance, it is verified whether the attestation naming record of the database instance meets preset key issuing conditions. The scheme can realize collaborative security control of database replication and key issuing.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method and system for trusted database replication and key distribution. Background Technology

[0002] With the development of cloud databases, distributed databases, and privacy computing, database services are typically deployed in cloud environments, container environments, or virtualization environments. In existing technologies, the primary database instance usually decides whether to send replication logs such as WAL (Write-Ahead Logging), binlog (Binary Log), and redo log to the replica database instance based on a pre-defined whitelist of accounts, certificates, or IPs (Internet Protocol). The primary database instance does not verify the current TEE (Trusted Execution Environment) status, database roles, tenant / shard ownership, and configuration compliance of the replica database instances, resulting in low data security.

[0003] KMS (Key Management System) typically determines whether to issue data keys based on IAM (Identity and Access Management) permissions, database accounts, or local derivation within the TEE. It rarely shares the same set of instance proof records that can be queried by domain name with the primary database replication access. When instance roles change, proofs expire, or configurations drift, key renewal and replication links often cannot be terminated synchronously.

[0004] As can be seen from the above, database replication and KMS key distribution provide local security capabilities at different stages. Each stage can only solve local problems in the database security chain. The trust judgments on which the two rely are independent of each other, resulting in low data security. A collaborative control method for "database replication + key distribution" has not yet been formed. Summary of the Invention

[0005] This invention provides a method and system for trusted database replication and key distribution to solve the technical problem that the trust determination of database replication and key distribution are independent of each other.

[0006] To address the aforementioned technical problems, this invention provides a method for trusted database replication and key distribution, comprising the following steps:

[0007] S1. The database instance starts in the Trusted Execution Environment and generates a remote proof report. The database instance includes a primary database instance and a replica database instance. The remote proof report includes the database domain name, database role, shard identifier, tenant identifier, replication permissions, database software integrity metric, database configuration integrity metric, Trusted Execution Environment platform information, Trusted Execution Environment patch level, remote proof report generation time, database replication channel public key, and data key receiving public key.

[0008] S2. The database instance sends the generated remote proof report to the proof-type naming service for registration.

[0009] S3. The proof-type naming service verifies whether the received remote proof report meets the preset database instance registration conditions; if the verification passes, it publishes a proof-type naming record associated with the database instance domain name; if the verification fails, it refuses to publish a proof-type naming record associated with the database instance domain name, or publishes a rejection status record.

[0010] S4. When the primary database instance prepares to send replication logs to the replica database instance, it queries the proof naming service for the replica database instance's proof naming record based on the replica database instance's domain name, and verifies whether the replica database instance's proof naming record meets the preset replica database instance replication conditions. If the verification passes, the primary database instance establishes a secure replication channel using the database replication channel public key in the replica database instance's proof naming record and sends replication logs to the replica database instance. If the verification fails, the primary database instance refuses to send replication logs to the replica database instance.

[0011] S5. When the key management system is preparing to send a key to the database instance, it queries the proof naming service for the database instance based on the database instance domain name and verifies whether the proof naming record of the database instance meets the preset key distribution conditions. If the verification is successful, the key management system uses the data key in the proof naming record of the database instance to receive the public key encapsulating the key and sends the encapsulated key to the database instance. If the verification fails, the key management system refuses to send the key to the database instance.

[0012] Preferably, the database instance registration conditions include: a list of allowed database software integrity metrics, a list of allowed database configuration integrity metrics, allowed trusted execution environment platform types, minimum trusted execution environment patch level, specified tenant-shard binding relationship, allowed database roles, allowed replication permissions, required audit policies, required encryption policies, valid timeframe for remote proof report generation, and public key usage constraints.

[0013] Preferably, the proof-type naming record includes at least a remote proof report record, a version number, a database policy record, a record validity period, and a revocation status.

[0014] Preferably, the replication conditions for the replica database instance include: the record validity period of the replica database instance has not expired; the replica database instance runs in a compliant and trusted execution environment; the software integrity metric of the replica database matches the database policy record of the primary database instance; the configuration integrity metric of the replica database conforms to the replication policy; the role of the replica database instance is a role that is allowed to receive replication logs; the shard identifier of the replica database is consistent with the shard identifier of the primary database; the tenant identifier of the replica database is consistent with the tenant identifier of the primary database; the public key of the replication channel of the replica database instance is bound to the remote proof report; and the proof-type naming record of the replica database instance has not been revoked.

[0015] Preferably, step S4 includes the following steps: after each replication heartbeat cycle or after sending a preset number of logs, the primary database instance re-queries the proof-type naming record of the replica database instance and verifies whether the proof-type naming record of the replica database instance meets the preset replica database instance replication conditions. If the verification fails, physical replication is paused or logical replication is disconnected.

[0016] Preferably, step S5 includes the following steps: the key management system verifies whether the database instance is running in a trusted execution environment, whether the database software integrity metric is in the allowed list, whether the database configuration integrity metric meets the encryption policy, whether the tenant identifier is consistent with the tenant requesting the key, whether the shard identifier is consistent with the shard of the requested key, whether the database role is allowed to receive the key sent by the key management system, whether the proof-type naming record is within the validity period, whether the data key receiving public key is included in the remote proof report, and whether the proof-type naming record has not been revoked.

[0017] Preferably, step S5 includes the following steps: when the key management system issues a key, it writes the proof-type naming record version number, public key fingerprint, tenant identifier, shard identifier, and database instance role into the key lease metadata.

[0018] Preferably, the method further includes the following steps: S6, the database instance periodically refreshes the remote proof report and sends the updated remote proof report to the proof naming service for re-registration.

[0019] Preferably, the system includes a database instance, a proof-based naming service, and a key management system, wherein the system is used to execute a database trusted replication and key distribution method as described in any of the preceding embodiments.

[0020] The present invention provides a database trusted replication and key distribution method and system, which has the following technical effects:

[0021] First, implement coordinated security control for database replication and key distribution. The master database instance and KMS determine whether to send replication logs and whether to distribute data keys based on the same database instance domain name's proof-type naming record, thus resolving the problem of fragmented judgment between the two sensitive paths.

[0022] Second, improve the security of the database replication chain. The primary database instance does not send replication logs to replica database instances that have not passed the proof-based naming service verification, reducing the risk of data leakage.

[0023] Third, it enhances the security of key distribution. KMS only distributes data keys to database instances that have been verified through a proof-based naming service, thus improving the security of key distribution. Attached Figure Description

[0024] Figure 1 This is a flowchart of a database trusted replication and key distribution method provided in an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, advantages, and features of the present invention clearer, the following detailed description of a database trusted replication and key distribution method and system proposed by the present invention, in conjunction with the accompanying drawings, is provided. It should be noted that the drawings are all in a very simplified form and use non-precise proportions, and are only used to facilitate and clearly illustrate the objectives of the embodiments of the present invention.

[0026] In the description of this invention, the terms "first," "second," and other qualifiers are added for convenience of description and reference, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with qualifiers such as "first" and "second" may explicitly or implicitly include one or more of that feature.

[0027] like Figure 1 As shown, this invention provides a method for trusted database replication and key distribution, including the following steps:

[0028] S1. The database instance starts in the Trusted Execution Environment (TEE) and generates a remote verification report. The database instance includes a primary database instance and replica database instances. The remote verification report includes the database domain name, database role, shard identifier, tenant identifier, replication permissions, database software integrity metric, database configuration integrity metric, TEE platform information, TEE patch level, remote verification report generation time, database replication channel public key, and data key receiving public key. The database instance in the TEE can load database programs, configuration files, extension plugins, audit policies, and encryption policies. The TEE can measure the database programs, configuration, and runtime environment to obtain database software integrity metrics, database configuration integrity metrics, database plugin integrity metrics, and audit policy integrity metrics. The database instance can generate the database replication channel public key and data key receiving public key.

[0029] S2. The database instance sends the generated remote proof report to the proof-of-concept naming service for registration. The proof-of-concept naming service is a functional module set up on the server. The proof-of-concept naming service can perform database instance registration, record revocation, replication admission and rejection events, KMS key issuance and write-back events, and generate shared request trace identifiers to form a cross-component associative audit chain.

[0030] S3. The proof-type naming service verifies whether the received remote proof report meets the preset database instance registration conditions; if the verification passes, it publishes a proof-type naming record associated with the database instance domain name; if the verification fails, it refuses to publish a proof-type naming record associated with the database instance domain name, or publishes a rejection status record.

[0031] Preferably, the database instance registration conditions include: a list of allowed database software integrity metrics, a list of allowed database configuration integrity metrics, allowed trusted execution environment platform types, minimum trusted execution environment patch level, specified tenant-shard binding relationship, allowed database roles, allowed replication permissions, required auditing policies, required encryption policies, the valid range of remote proof report generation time, and public key usage constraints. Verifying multiple constraints improves the security of the registration results.

[0032] Preferably, the proof-type naming record includes at least a remote proof report record (including database instance domain name record, replication channel public key record, and data key receiving public key record, etc., all information originating from the same source as the remote proof report), a version number, a database policy record, a record validity period, and a revocation status. By recording these detailed information items, it can be used for auditing.

[0033] S4. When the primary database instance prepares to send replication logs to the replica database instance, it queries the proof naming service for the replica database instance based on the replica database instance domain name, and verifies whether the proof naming record of the replica database instance meets the preset replication conditions of the replica database instance. If the verification is successful, the primary database instance establishes a secure replication channel using the database replication channel public key in the proof naming record of the replica database instance, and sends replication logs to the replica database instance. If the verification fails, the primary database instance refuses to send replication logs to the replica database instance.

[0034] Preferably, the replication conditions for the replica database instance include: the record validity period of the replica database instance has not expired; the replica database instance runs in a compliant and trusted execution environment; the software integrity metric of the replica database matches the database policy record of the primary database instance; the configuration integrity metric of the replica database conforms to the replication policy; the role of the replica database instance is a role that is allowed to receive replication logs; the shard identifier of the replica database is consistent with the shard identifier of the primary database; the tenant identifier of the replica database is consistent with the tenant identifier of the primary database; the public key of the replication channel of the replica database instance is bound to the remote proof report; and the proof-type naming record of the replica database instance has not been revoked. Verifying multiple constraints can improve the security of data replication.

[0035] Preferably, step S4 includes the following steps: after each replication heartbeat cycle or after sending a preset number of logs, the primary database instance re-queries the proof-type naming record of the replica database instance and verifies whether the proof-type naming record of the replica database instance meets the preset replica database instance replication conditions. If the verification fails, physical replication is paused or logical replication is disconnected without waiting for the next data connection relationship to be established, thereby improving the execution efficiency of the primary database instance.

[0036] S5. When the key management system is preparing to send a key to the database instance, it queries the proof naming service for the database instance based on the database instance domain name and verifies whether the proof naming record of the database instance meets the preset key distribution conditions. If the verification is successful, the key management system uses the data key in the proof naming record of the database instance to receive the public key encapsulating the key and sends the encapsulated key to the database instance. If the verification fails, the key management system refuses to send the key to the database instance.

[0037] Preferably, step S5 includes the following steps: the key management system verifies whether the database instance is running in a trusted execution environment, whether the database software integrity metric is in the allowed list, whether the database configuration integrity metric meets the encryption policy, whether the tenant identifier matches the tenant requesting the key, whether the shard identifier matches the shard of the requested key, whether the database role is allowed to receive the key sent by the key management system, whether the proof-of-concept naming record is within its validity period, whether the data key receiving public key is included in the remote proof report, and whether the proof-of-concept naming record has not been revoked. Verification of multiple constraints improves the security of the issued key.

[0038] Preferably, when issuing keys, the key management system writes the proof-of-name record version number, public key fingerprint, tenant identifier, shard identifier, and database instance role into the key lease metadata to improve the timeliness of key issuance. Database instance decryption or lease renewal requires proof that the current proof-of-name record version is consistent with the lease; after the proof-of-name service is revoked or upgraded, the old lease automatically expires and renewal is refused.

[0039] Preferably, the method further includes the following steps: S6, the database instance periodically refreshes the remote proof report and sends the updated remote proof report to the proof-based naming service for re-registration. The proof-based naming service updates or revokes records when the following occurs: the TEE patch level no longer meets the policy, the database software version is no longer allowed, the database configuration changes, the database role changes, the tenant or shard binding relationship changes, the remote proof report of the database instance expires, the database instance goes offline, or the audit policy or encryption policy no longer meets the requirements. The primary database instance automatically stops replication or stops key renewal before the next replication heartbeat or log transmission, and the KMS automatically stops replication or key renewal before the next issuance or renewal, respectively, to improve data security.

[0040] Preferably, the remote proof report includes the database replication channel public key, the data key receiving public key, and a key usage digest, and calculates the associated root hash; the proof-type naming record includes the associated root hash; when the master database instance is about to send replication logs to the replica database instance, or when the key management system is about to send a key to the database instance, the associated root hash needs to be verified to prevent public key replacement or misuse.

[0041] Based on the same technical concept as the aforementioned trusted database replication and key distribution method, this embodiment provides a trusted database replication and key distribution system, including a database instance, a proof-type naming service, and a key management system. The system is used to execute any of the aforementioned trusted database replication and key distribution methods.

[0042] In summary, the database trusted replication and key distribution method and system provided by this invention have the following technical effects:

[0043] First, implement coordinated security control for database replication and key distribution. The master database instance and KMS determine whether to send replication logs and whether to distribute data keys based on the same database instance domain name's proof-type naming record, thus resolving the problem of fragmented judgment between the two sensitive paths.

[0044] Second, improve the security of the database replication chain. The primary database instance does not send replication logs to replica database instances that have not passed the proof-based naming service verification, reducing the risk of data leakage.

[0045] Third, it enhances the security of key distribution. KMS only distributes data keys to database instances that have been verified through a proof-based naming service, thus improving the security of key distribution.

[0046] The above description is only a description of preferred embodiments of the present invention and is not intended to limit the scope of the present invention in any way. Any changes or modifications made by those skilled in the art based on the above disclosure shall fall within the protection scope of the present invention.

Claims

1. A method for trusted database replication and key distribution, characterized in that, Includes the following steps: S1. The database instance starts in the Trusted Execution Environment and generates a remote proof report. The database instance includes a primary database instance and a replica database instance. The remote proof report includes the database domain name, database role, shard identifier, tenant identifier, replication permissions, database software integrity metric, database configuration integrity metric, Trusted Execution Environment platform information, Trusted Execution Environment patch level, remote proof report generation time, database replication channel public key, and data key receiving public key. S2. The database instance sends the generated remote proof report to the proof-type naming service for registration. S3. The proof-type naming service verifies whether the received remote proof report meets the preset database instance registration conditions; if the verification passes, it publishes a proof-type naming record associated with the database instance domain name; if the verification fails, it refuses to publish a proof-type naming record associated with the database instance domain name, or publishes a rejection status record. S4. When the primary database instance prepares to send replication logs to the replica database instance, it queries the proof naming service for the replica database instance's proof naming record based on the replica database instance's domain name, and verifies whether the replica database instance's proof naming record meets the preset replica database instance replication conditions. If the verification passes, the primary database instance establishes a secure replication channel using the database replication channel public key in the replica database instance's proof naming record and sends replication logs to the replica database instance. If the verification fails, the primary database instance refuses to send replication logs to the replica database instance. S5. When the key management system is preparing to send a key to the database instance, it queries the proof naming service for the database instance based on the database instance domain name and verifies whether the proof naming record of the database instance meets the preset key distribution conditions. If the verification is successful, the key management system uses the data key in the proof naming record of the database instance to receive the public key encapsulated key and sends the encapsulated key to the database instance. If the verification fails, the key management system refuses to send the key to the database instance.

2. The database trusted replication and key distribution method as described in claim 1, characterized in that, The database instance registration conditions include: a list of allowed database software integrity metrics, a list of allowed database configuration integrity metrics, allowed trusted execution environment platform types, minimum trusted execution environment patch level, specified tenant and shard binding relationship, allowed database roles, allowed replication permissions, required audit policies, required encryption policies, the valid range of remote proof report generation time, and public key usage constraints.

3. The database trusted replication and key distribution method as described in claim 1, characterized in that, The proof-type named record includes at least a remote proof report record, a version number, a database policy record, a record validity period, and a revocation status.

4. The database trusted replication and key distribution method as described in claim 3, characterized in that, The replication conditions for the replica database instance include: the record validity period of the replica database instance has not expired; the replica database instance runs in a compliant and trusted execution environment; the software integrity metric of the replica database matches the database policy record of the primary database instance; the configuration integrity metric of the replica database conforms to the replication policy; the role of the replica database instance is a role that is allowed to receive replication logs; the shard identifier of the replica database is consistent with the shard identifier of the primary database; the tenant identifier of the replica database is consistent with the tenant identifier of the primary database; the public key of the replication channel of the replica database instance is bound to the remote proof report; and the proof-type naming record of the replica database instance has not been revoked.

5. The database trusted replication and key distribution method as described in claim 1, characterized in that, Step S4 includes the following steps: After each replication heartbeat cycle or after sending a preset number of logs, the primary database instance re-queries the proof-type naming record of the replica database instance and verifies whether the proof-type naming record of the replica database instance meets the preset replica database instance replication conditions. If the verification fails, physical replication is paused or logical replication is disconnected.

6. The database trusted replication and key distribution method as described in claim 1, characterized in that, Step S5 includes the following steps: the key management system verifies whether the database instance is running in a trusted execution environment, whether the database software integrity metric is in the allowed list, whether the database configuration integrity metric meets the encryption policy, whether the tenant identifier is consistent with the tenant requesting the key, whether the shard identifier is consistent with the shard of the requested key, whether the database role is allowed to receive the key sent by the key management system, whether the proof-type naming record is within the validity period, whether the data key receiving public key is included in the remote proof report, and whether the proof-type naming record has not been revoked.

7. The database trusted replication and key distribution method as described in claim 1, characterized in that, Step S5 includes the following steps: When the key management system issues a key, it writes the proof-type naming record version number, public key fingerprint, tenant identifier, shard identifier, and database instance role into the key lease metadata.

8. The database trusted replication and key distribution method as described in claim 1, characterized in that, The method further includes the following steps: S6, the database instance periodically refreshes the remote proof report and sends the updated remote proof report to the proof naming service for re-registration.

9. A database trusted replication and key distribution system, characterized in that, The system includes a database instance, a proof-based naming service, and a key management system, which is used to execute a database trusted replication and key distribution method according to any one of claims 1-8.

Images