A database password management method, device, equipment, medium and product

Abstract

The application discloses a database password management method, device, equipment, medium and product, and relates to the technical field of big data. The method comprises the following steps: when the middleware is started, a configuration file is parsed to extract a password variable and construct an encrypted request; data is returned after being subjected to multiple security checks and encryption processing by a dynamic credential management center; the encrypted response data is decrypted by a memory sandbox of a trusted execution environment; and finally, the plaintext password is written into a non-heap memory area locked by a system call and is set as read-only. Thus, the security and efficiency of dynamic password updating are guaranteed by the dynamic credential management center and the hardware security module, the risk of password leakage in the memory and the disk is eliminated by using the trusted execution environment and the memory isolation technology, in addition, the centralized architecture of the dynamic credential management center also provides support for the disaster recovery mechanism, guarantees the stability of password acquisition, and effectively solves the technical problems existing in the current middleware password management.

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to a method, apparatus, device, medium and product for managing database passwords. Background Technology

[0002] In industries such as finance, telecommunications, and the internet, secure database password management is a crucial aspect of ensuring information system security. With the increasing prevalence of microservice architectures, enterprises typically deploy hundreds to thousands of middleware instances, each requiring database connection passwords to be stored in a configuration file. Current solutions often encrypt passwords using algorithms like AES before storing them in the configuration file, requiring decryption into plaintext in memory at runtime for use by the database connection pool.

[0003] However, in distributed systems, the frequent access to and dynamic update requirements of passwords (such as periodic rotation and emergency resets) lead to an exponential increase in password management complexity. Furthermore, attackers can reverse engineer the middleware's decryption logic or use memory scanning tools to directly capture plaintext passwords from memory, thus posing a data breach risk. In the financial industry, the leakage of database passwords can lead to the theft of business data (such as customer information and transaction records) and even trigger system-level security incidents. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and product for managing database passwords, in order to solve the problem of database password leakage risk in related technologies.

[0005] Firstly, this application provides a method for managing database passwords, including:

[0006] In response to receiving a start command from the target middleware, the configuration file of the target middleware is parsed to extract password variables that conform to a preset format; wherein, the password variables include a namespace identifier and a password item identifier;

[0007] An encrypted request carrying a digital signature is constructed based on the cryptographic variables, and the encrypted request is sent to the dynamic credential management center;

[0008] The system receives encrypted response data returned by the dynamic credential management center after responding to the encryption request; wherein the encrypted response data is obtained by the dynamic credential management center using a temporarily generated session key after completing client identity authentication, access permission verification, and decrypting the original password using the hardware security module, and the session key is encapsulated by the master key of the hardware security module.

[0009] The encrypted response data is decrypted in the memory sandbox of the trusted execution environment to obtain the plaintext database password;

[0010] Write the plaintext database password into a non-heap memory region locked by a system call, and set read-only access permissions.

[0011] In one possible design, constructing an encryption request carrying a digital signature based on the cryptographic variable and sending the encryption request to the dynamic credential management center includes:

[0012] The namespace identifier and the password item identifier are extracted from the password variables using regular expressions, and then encapsulated into a request body according to a preset data format.

[0013] The request body is signed using a hardware security module to generate a digital signature, which is then added to the request header to form the encrypted request.

[0014] The encrypted request is sent to the dynamic credential management center through an encrypted communication channel, and the interaction between the target middleware and the dynamic credential management center is recorded in the audit log. The audit log includes the operation subject, operation time, request content, and response result.

[0015] In one possible design, the encrypted response data is obtained by the dynamic credential management center after completing client authentication, access permission verification, and decrypting the original password using a hardware security module, and is encrypted using a temporarily generated session key, including:

[0016] The gateway verifies the validity of the client certificate, the authentication module confirms the client's access rights to the namespace, and the hardware security module interface is called to decrypt the stored original database password.

[0017] After obtaining the original database password, the original database password is encrypted based on the dynamically generated session key to obtain the encrypted database password;

[0018] The session key is encapsulated using the master key of the hardware security module, and the encrypted database password and the encapsulated session key are integrated into the encrypted response data.

[0019] In one possible design, the decryption of the encrypted response data in a memory sandbox within a trusted execution environment to obtain the plaintext database password includes:

[0020] In the memory sandbox of the Trusted Execution Environment, the encrypted response data is decrypted using a temporary decryption key generated by the hardware security module. During the decryption process, the access permissions of the memory area are set to be readable only by the decryption process through a memory protection hook.

[0021] After decryption is complete, the plaintext database password is retained and any remaining intermediate decryption data in memory is cleared.

[0022] One possible design also includes:

[0023] Real-time monitoring of access patterns in the non-heap memory region;

[0024] When a memory access request initiated through an unsafe pointer is detected, it is determined to be an illegal read operation, triggering a memory data overwrite and clear operation, and disconnecting all current database connections.

[0025] One possible design also includes:

[0026] Continuously monitor the health status of the dynamic credential management center; wherein the monitoring indicators of the health status include network latency, handshake success rate, and hardware security module response time;

[0027] If any of the monitoring indicators is abnormal and the duration exceeds the preset duration, the communication of the dynamic credential management center is determined to be abnormal, and the system switches to the local encrypted cache preset in the trusted execution environment to obtain the database password. During the switching process, the current database connection is kept available until the new connection is successfully verified.

[0028] In one possible design, the step of switching to a pre-configured local encrypted cache within a trusted execution environment to obtain the database password includes:

[0029] When the communication of the dynamic credential management center is determined to be abnormal, an emergency control switch is triggered to read the encrypted database password from the local encryption cache preset in the trusted execution environment; wherein, the database password in the local encryption cache is encrypted and protected by a segment key different from the master key, and the segment key is generated through the fingerprint information of the hardware security module;

[0030] After reading the encrypted database password, it is decrypted using a segmented key in a memory sandbox of a trusted execution environment to obtain the plaintext database password.

[0031] Secondly, this application provides a database password management device, comprising:

[0032] The configuration file parsing module is used to parse the configuration file of the target middleware in response to receiving the start command of the target middleware, so as to extract password variables that conform to a preset format; wherein, the password variables include namespace identifiers and password item identifiers;

[0033] The encryption request construction and sending module is used to construct an encryption request carrying a digital signature based on the cryptographic variables, and send the encryption request to the dynamic credential management center;

[0034] The encrypted response receiving module is used to receive encrypted response data returned by the dynamic credential management center after responding to the encryption request; wherein, the encrypted response data is obtained by the dynamic credential management center using a temporarily generated session key after completing client identity authentication, access permission verification and decrypting the original password using the hardware security module, and the session key is encapsulated by the master key of the hardware security module.

[0035] The decryption module is used to decrypt the encrypted response data in the memory sandbox of the trusted execution environment to obtain the plaintext database password;

[0036] The write module is used to write the plaintext database password to a non-heap memory area locked by a system call and set read-only access permissions.

[0037] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0038] The memory stores instructions that the computer executes;

[0039] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0040] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method of any one of the first aspects.

[0041] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0042] This application provides a method, apparatus, device, medium, and product for managing database passwords. The method involves parsing a configuration file to extract password variables and constructing an encryption request during middleware startup. After multiple security checks and encryption processes by a dynamic credential management center, the returned data is decrypted using a memory sandbox within a trusted execution environment. Finally, the plaintext password is written to a non-heap memory area locked by a system call and given read-only access. Thus, the dynamic credential management center and hardware security module ensure the security and efficiency of dynamic password updates. The trusted execution environment and memory isolation technology eliminate the risk of password leakage in memory and on disk. Furthermore, the centralized architecture of the dynamic credential management center provides support for a disaster recovery mechanism, ensuring the stability of password acquisition and effectively solving the technical problems existing in current middleware password management. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0044] Figure 1 An application scenario diagram corresponding to a database password management method provided in an embodiment of this application;

[0045] Figure 2 A flowchart illustrating a database password management method provided in one embodiment of this application;

[0046] Figure 3 A flowchart illustrating a database password management method provided in another embodiment of this application;

[0047] Figure 4 A schematic diagram of a database password management device provided in an embodiment of this application;

[0048] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0049] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0050] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0051] It should be noted that the database password management method, apparatus, device, medium and product of this application can be used in the field of big data technology, or in any field other than big data technology. The application field of the database password management method, apparatus, device, medium and product of this application is not limited.

[0052] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0053] In industries such as finance, telecommunications, and the internet, secure database password management is a crucial aspect of ensuring information system security. With the increasing prevalence of microservice architectures, enterprises typically deploy hundreds to thousands of middleware instances, each requiring database connection passwords to be stored in a configuration file. Current solutions often encrypt passwords using algorithms like AES before storing them in the configuration file, requiring decryption into plaintext in memory at runtime for use by the database connection pool.

[0054] However, in distributed systems, the frequent access to and dynamic update requirements of passwords (such as periodic rotation and emergency resets) lead to an exponential increase in password management complexity. Furthermore, attackers can extract the decryption logic of middleware through reverse engineering or directly capture plaintext passwords from memory using memory scanning tools, thus posing a risk of data breaches. In the financial industry, the leakage of database passwords can lead to the theft of core business data (such as customer information and transaction records) and even trigger system-level security incidents.

[0055] Therefore, how to ensure the efficiency of dynamic password updates while eliminating the risk of password leakage in memory and disk has become an urgent problem to be solved in the field of middleware password management.

[0056] Figure 1 An application scenario diagram corresponding to a database password management method provided in one embodiment of this application is shown below. Figure 1 As shown, the application scenario provided in this embodiment includes a middleware deployment server 10, a dynamic credential management center 11, and a trusted execution environment carrier 12. The middleware deployment server 10 is communicatively connected to the dynamic credential management center 11 and the trusted execution environment carrier 12, respectively. The dynamic credential management center 11 and the trusted execution environment carrier 12 have an encrypted data interaction link.

[0057] Specifically, when the operations and maintenance personnel send a start command for the target middleware to the middleware deployment server 10 via the management terminal, the middleware deployment server 10 first parses the configuration file of the target middleware and extracts a password variable that conforms to the preset naming convention. This password variable contains a namespace identifier and a password item identifier, which can accurately point to the target database password to be obtained. Subsequently, based on the extracted password variable, the middleware deployment server 10 generates an encryption request containing its own identity information and an attached digital signature, and sends the encryption request to the dynamic credential management center 11. After receiving the encryption request, the dynamic credential management center 11 completes client identity authentication and access permission verification in sequence, and then calls the built-in hardware security module to decrypt the stored original database password. Afterwards, it temporarily generates a session key, uses the session key to encrypt the original database password, forms encrypted response data, and returns it to the middleware deployment server 10. After receiving the encrypted response data, the middleware deployment server 10 transmits it to the trusted execution environment carrier 12, where the trusted execution environment carrier 12 performs the decryption operation of the encrypted response data in a dedicated memory sandbox to obtain the plaintext database password, and sends the plaintext database password back to the middleware deployment server 10. Finally, the middleware deployment server 10 writes the decrypted plaintext database password into the non-heap memory area locked by the system call, and sets read-only access permissions for the non-heap memory area to ensure the security of the database password during use, thus completing the entire dynamic acquisition and secure storage process of the database password.

[0058] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0059] Figure 2 A flowchart illustrating a database password management method provided in one embodiment of this application is shown below. Figure 2 As shown, the execution subject of this embodiment is a database password management device. This device can be implemented through a computer program, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc; alternatively, it can be implemented through a physical device that integrates or installs the relevant computer program, such as a chip or electronic device. The electronic device may be a computer or a server, etc. The database password management method provided in this embodiment includes the following steps:

[0060] S201. In response to receiving the start command of the target middleware, parse the configuration file of the target middleware to extract password variables that conform to a preset format; wherein, the password variables include namespace identifier and password item identifier.

[0061] The startup instructions include instructions for the middleware's first startup, restart, or reload after a password update.

[0062] Optionally, parsing the configuration file includes syntax parsing and content extraction. The local configuration file no longer stores any form of encrypted or plaintext password; it only stores password variables conforming to a preset format. These password variables are index information used to uniquely identify the password in the target database, specifically including namespace identifiers and password item identifiers.

[0063] The namespace identifier is used to achieve password isolation for different business modules, different environments (such as development, testing, and production environments), or different types of middleware. For example, "Finance-Tomcat-Prod" represents the Tomcat middleware namespace in the financial business production environment. The password item identifier is used to uniquely identify a specific database password under this namespace. For example, "DB-Master-01" represents the primary access password for the master database. This enables precise location and isolation control of passwords for a large number of middleware and databases in a distributed system.

[0064] Optionally, during the parsing process, other irrelevant configuration items in the configuration file (such as port number, connection timeout, etc.) can be filtered out, and only strings that conform to the above preset format can be extracted as password variables. The extracted password variables are then validated (such as whether they contain ":" separators, namespace identifiers, and whether password item identifiers are empty). If the validation fails, an exception alarm is triggered, and the database connection process of the target middleware is stopped.

[0065] S202. Construct an encryption request carrying a digital signature based on the cryptographic variables, and send the encryption request to the dynamic credential management center.

[0066] The original request data may include password variables (namespace identifier and password item identifier), the unique device identifier of the target middleware (such as server MAC address, middleware instance ID), and request timestamp (accurate to milliseconds, used to prevent request replay attacks).

[0067] Optionally, to ensure the integrity of the request data and the authenticity of the sender's identity, an asymmetric encryption algorithm (such as the RSA algorithm) can be used to digitally sign the original request data. That is, the private key of the target middleware is used to perform a hash operation on the original request data to obtain a hash value (i.e., a digital signature), and the digital signature is combined with the original request data to form a complete encrypted request.

[0068] Optionally, the private key of the target middleware is pre-stored in a secure storage area on the middleware's local machine, and the corresponding public key is pre-registered with the dynamic credential management center for subsequent identity verification.

[0069] Optionally, the target middleware sends the encrypted request to the dynamic credential management center via an encrypted communication channel (such as a TLS 1.3 encrypted channel). The establishment of an encrypted communication channel can prevent the request data from being eavesdropped on or tampered with during transmission, further ensuring transmission security.

[0070] S203. Receive the encrypted response data returned by the dynamic credential management center after responding to the encryption request; wherein, the encrypted response data is obtained by the dynamic credential management center using a temporarily generated session key after completing client identity authentication, access permission verification and decrypting the original password using the hardware security module, and the session key is encapsulated by the master key of the hardware security module.

[0071] The dynamic credential management center is responsible for the unified storage and management of the original passwords of all databases in the distributed system, and provides functions such as dynamic password updates, access control, and disaster recovery backup.

[0072] Optionally, after receiving an encryption request, the dynamic credential management center can execute the following processing steps in sequence:

[0073] First, the identity verification module of the dynamic credential management center extracts the original request data and digital signature from the encrypted request. It then decrypts the digital signature using the public key pre-registered by the target middleware, obtaining the decrypted hash value. Next, the identity verification module performs the same hashing algorithm on the original request data to obtain a new hash value. The two hash values ​​are compared; if they match, the sender is a legitimate target middleware (identity authentication passed); otherwise, the request is rejected and an exception log is recorded. Furthermore, the identity verification module also verifies the request timestamp. If the difference between the request timestamp and the current system time exceeds a preset threshold (e.g., 5 minutes), it is determined to be a request replay attack and the request is rejected outright.

[0074] Secondly, after successful identity authentication, the access control module of the dynamic credential management center queries the preset access control rule base based on the password variables (namespace identifier and password item identifier) ​​in the encrypted request and the unique device identifier of the target middleware. The access control rule base pre-configures the access permissions of each middleware instance to each password item (e.g., a certain Tomcat middleware only allows access to the "DB-Master-01" password item under the "Finance-Tomcat-Prod" namespace). If the target middleware has access permissions to the database password corresponding to the password variable, the access verification passes; otherwise, the request is rejected, and an access exception alarm is triggered.

[0075] Next, after the authorization verification is successful, the password extraction module of the dynamic credential management center retrieves the corresponding original database password (i.e., plaintext password) from the central password database based on the namespace identifier and password item identifier in the password variable. It should be noted that the original password in the central password database is not stored in plaintext, but is encrypted using a hardware security module (HSM). That is, the original password is encrypted using the master key of the hardware security module before being stored in the central password database. The hardware security module is dedicated encryption hardware that conforms to the standards of the State Cryptography Administration, and its master key is stored only internally and cannot be exported or read, effectively preventing the leakage of the original password.

[0076] Finally, to prevent the original password from being leaked during transmission, the session key generation module of the dynamic credential management center temporarily generates a symmetric session key (e.g., generated using the AES-256-GCM algorithm; the session key is only valid within the current request period and is destroyed immediately after use). Subsequently, the original password decrypted from the hardware security module is encrypted using this session key to obtain encrypted password data. In addition, the session key generation module encapsulates (i.e. encrypts) the temporary session key using the master key of the hardware security module to obtain the encapsulated session key. Finally, the encrypted password data is combined with the encapsulated session key to form encrypted response data, which is returned to the target middleware through the aforementioned encrypted communication channel.

[0077] S204. Decrypt the encrypted response data in the memory sandbox of the trusted execution environment to obtain the plaintext database password.

[0078] Optionally, upon receiving the encrypted response data, the target middleware will not decrypt it in the ordinary memory area. Instead, it will transmit the encrypted response data to a memory sandbox within its local Trusted Execution Environment (TEE). The TEE is a secure area isolated at the hardware level. Its internal memory sandbox features memory isolation, code integrity verification, and encrypted data storage. External processes (including operating system kernel processes) cannot access or tamper with the data in the memory sandbox, thus completely preventing data leakage during the decryption process.

[0079] Optionally, the decryption module in the memory sandbox can perform the following decryption operations: First, it calls the locally pre-deployed hardware security module (which is in the same system as the hardware security module of the dynamic credential management center and shares the master key), and uses the master key of the hardware security module to decrypt the encapsulated session key in the encrypted response data to obtain a temporary session key; then, it uses this temporary session key to decrypt the encrypted password data in the encrypted response data to obtain the plaintext database password. After decryption, the decryption module immediately destroys the temporary session key (by overwriting the memory area where the session key is located with random data) to avoid security risks caused by session key leakage. If an anomaly occurs during the decryption process (such as session key decryption failure, password data decryption failure, etc.), the memory sandbox will trigger a security alarm, destroy all received encrypted response data, and stop subsequent processes.

[0080] S205. Write the plaintext database password to the off-heap memory region locked by the system call and set read-only access permissions.

[0081] Optionally, to prevent the plaintext database password from being maliciously captured in memory, the target middleware's memory management module writes the plaintext database password obtained in S204 to a non-heap memory area (such as the Direct Memory area of ​​Java middleware or the shared memory area of ​​C / C++ middleware). Compared to heap memory, non-heap memory is not affected by garbage collection mechanisms and can autonomously control memory allocation and release, reducing the risk of memory data exposure due to garbage collection.

[0082] Optionally, the memory management module locks the non-heap memory region using system calls (such as the mlock() function in Linux and the VirtualLock() function in Windows) to prevent data in the non-heap memory region from being swapped to the disk's virtual memory (Swap space). Since virtual memory data is stored on the disk in plaintext, the locking process avoids the risk of password leakage due to memory swapping.

[0083] Optionally, the memory management module sets the access permission of the non-heap memory region to "read-only" through the system permission control interface (such as the chmod() function in the Linux system), that is, only the database connection pool process of the target middleware is allowed to read the plaintext password of the region, and no other process (including other non-core processes of the target middleware) has the right to read or modify it.

[0084] Optionally, when the database connection pool needs to establish a database connection using a plaintext password, it reads the password from the read-only non-heap memory area through a preset security interface, and immediately clears the interface cache after reading. When the middleware stops running or the password is updated, the memory management module will immediately release the non-heap memory area and destroy the plaintext password in it by memory overwriting.

[0085] This application provides a database password management method. During middleware startup, the method parses the configuration file to extract password variables and constructs an encryption request. After multiple security checks and encryption processes by a dynamic credential management center, the returned data is decrypted using a trusted execution environment's memory sandbox. Finally, the plaintext password is written to a non-heap memory area locked by system calls and given read-only access. Thus, the dynamic credential management center and hardware security module ensure the security and efficiency of dynamic password updates. The trusted execution environment and memory isolation technology eliminate the risk of password leakage in memory and on disk. Furthermore, the centralized architecture of the dynamic credential management center provides support for a disaster recovery mechanism, ensuring the stability of password acquisition and effectively solving the technical problems existing in current middleware password management.

[0086] As an optional implementation, based on any of the above embodiments, an encryption request carrying a digital signature is constructed based on cryptographic variables, and the encryption request is sent to the dynamic credential management center, including the following steps:

[0087] First, the namespace identifier and password item identifier are extracted from the password variable using regular expressions, and then packaged into a request body according to a preset data format.

[0088] Optionally, a preset regular expression is used to perform secondary parsing on the extracted password variables to accurately separate the namespace identifier and the password item identifier. Optionally, the namespace identifier (first group) and the password item identifier (second group) can be captured separately by group matching. For example, the namespace identifier "Finance-Tomcat-Prod" and the password item identifier "DB-Master-01" can be extracted from the password variable "${Finance-Tomcat-Prod:DB-Master-01}".

[0089] Optionally, the extracted namespace identifier and password item identifier can be encapsulated into a request body according to the unified data format (such as JSON format) preset by the dynamic credential management center. The request body may also include the device unique identifier of the target middleware (such as the server MAC address, middleware instance ID) and the request timestamp.

[0090] Secondly, the request body is signed using a hardware security module to generate a digital signature, which is then added to the request header to form an encrypted request.

[0091] Optionally, to ensure the integrity, authenticity, and legitimacy of the sender's identity in the request body, and to prevent the request body from being tampered with or forged, a hardware security module (HSM) deployed locally in the target middleware is used to sign the encapsulated request body. Specifically, the hardware security module calls a built-in asymmetric encryption algorithm (such as the RSA algorithm, with a key length of no less than 2048 bits) and uses the target middleware's private key pre-stored inside the hardware to perform a hash operation on the request body (the hash algorithm uses SHA-256 or a higher security level) to generate a unique digital signature. After signing, the digital signature is added to a specified field in the request header (such as the "X-Signature" field), and combined with the generated request body, they form a complete encrypted request.

[0092] The private key of the target middleware is stored only inside the hardware security module and cannot be exported or read, which can effectively prevent the risk of signature forgery caused by key leakage.

[0093] Finally, the encrypted request is sent to the dynamic credential management center through an encrypted communication channel, and the interaction between the target middleware and the dynamic credential management center is recorded in the audit log. The audit log includes the operation subject, operation time, request content and response result.

[0094] Optionally, the encrypted request can be sent to the designated service port of the dynamic credential management center through an encrypted communication channel (such as a TLS 1.3 encrypted channel). The establishment of the encrypted communication channel can prevent the request data from being eavesdropped, tampered with or intercepted during transmission, thus ensuring the security of data transmission.

[0095] Optionally, by enabling an audit log recording mechanism, the interaction between the target middleware and the dynamic credential management center can be recorded in detail in the audit log. The audit log must contain complete information, including: the operation subject (i.e., the instance ID of the target middleware and the unique identifier of the device), the operation time (accurate to milliseconds, consistent with the timestamp in the request body), the request content (including the digital signature digest in the request header and the de-identified data in the request body to avoid storing sensitive information in plaintext), and the response result (initially recorded as "request sent", updated to "response successful" or "response failed" and the reason for failure after receiving the response).

[0096] Optionally, the audit logs are written in an immutable manner (such as append-only storage, blockchain notarization, etc.) for subsequent security audits, troubleshooting, and compliance verification.

[0097] This application provides a database password management method that accurately extracts namespace identifiers and password item identifiers using regular expressions and encapsulates the request body in a standardized manner to ensure a clear and accurate data structure; it utilizes hardware security module signatures to enhance the security and authenticity of encrypted requests and prevent tampering; and it transmits data through an encrypted communication channel and records audit logs to ensure communication security and facilitate traceability of operations.

[0098] Figure 3 A flowchart illustrating a database password management method provided in another embodiment of this application is shown below. Figure 3 As shown, as an optional implementation, based on any of the above embodiments, the encrypted response data is obtained by the dynamic credential management center using a temporarily generated session key after completing client identity authentication, access permission verification, and decryption of the original password using the hardware security module. This includes:

[0099] S301. Verify the validity of the client certificate through the gateway, confirm the client's access rights to the namespace through the authentication module, and call the hardware security module interface to decrypt the stored original database password.

[0100] Optionally, the encryption request is received by the front-end gateway of the dynamic credential management center. The gateway module automatically verifies the validity of the client certificate carried by the target middleware: the client certificate is a preset two-way authentication certificate (issued by the dynamic credential management center, containing information such as the middleware device's unique identifier and public key). The gateway verifies the certificate's signature integrity, validity period, and revocation status through the certificate chain. If the certificate is invalid (such as expired, abnormal signature, or revoked), the request is directly intercepted, subsequent processing is rejected, and a certificate exception log is recorded.

[0101] Optionally, after the client certificate verification is successful, the gateway forwards the encrypted request to the authentication module. The authentication module queries a preset namespace permission matrix based on the namespace identifier (such as "Finance-Tomcat-Prod") extracted from the encrypted request and the unique device identifier of the target middleware. This permission matrix pre-configures the access permissions of each middleware instance to different namespaces. For example, it may only allow the Tomcat-001 instance to access the "Finance-Tomcat-Prod" namespace and prohibit access to other business namespaces. If it is confirmed that the client has access permissions to the namespace, the permission verification passes; otherwise, the request is rejected, and a namespace permission exception alarm is triggered.

[0102] Optionally, after the authorization verification is successful, the authentication module passes the password item identifier (such as "DB-Master-01") in the encryption request to the password extraction module. The password extraction module queries the corresponding encrypted storage original database password from the central password database based on the namespace identifier and the password item identifier (this password has been encrypted using the master key of the hardware security module (HSM)). Subsequently, it calls the decryption interface of the hardware security module to pass the encrypted original password to the hardware security module. The hardware security module decrypts it using the built-in master key to obtain the plaintext original database password (the entire decryption process is performed inside the hardware security module, and the original password will not be leaked to the outside of the hardware).

[0103] S302. After obtaining the original database password, encrypt the original database password based on the dynamically generated session key to obtain the encrypted database password.

[0104] Optionally, after obtaining the plaintext original database password, the session key generation module of the dynamic credential management center dynamically generates a temporary session key. The session key is generated using a symmetric encryption algorithm (such as AES-256-GCM), with a key length of no less than 256 bits. The session key has the characteristic of "one-time pad" and is only valid within the current request-response cycle. It will be destroyed immediately after encryption.

[0105] Optionally, after the session key is generated, the encryption module calls the session key to encrypt the plaintext original database password. The encryption mode used supports integrity verification (such as GCM mode with built-in authentication tags), which can prevent the encrypted database password from being tampered with. After encryption, the encrypted database password is obtained, and a corresponding integrity verification tag is generated for the target middleware to verify the integrity of the data after receiving it.

[0106] S303. The session key is encapsulated using the master key of the hardware security module, and the encrypted database password and the encapsulated session key are integrated into encrypted response data.

[0107] Optionally, to prevent the temporary session key from being leaked during transmission, the session key generation module calls the encryption interface of the hardware security module and encapsulates the temporary session key using the master key of the hardware security module. Since the master key of the hardware security module is only stored internally in the hardware and cannot be exported or read, it ensures that the encapsulated session key can only be decrypted by a hardware security module of the same architecture deployed locally on the target middleware, further enhancing the security of the session key.

[0108] Optionally, after encapsulation, the encrypted database password and integrity verification tag obtained in S302 are integrated with the encapsulated session key obtained in S303, and assembled into encrypted response data according to the response data format preset by the dynamic credential management center (such as JSON format). Finally, the encrypted response data is returned to the target middleware through an encrypted communication channel (consistent with the channel used to receive the encrypted request, such as TLS 1.3).

[0109] This application provides a database password management method that verifies client identity and access permissions through a gateway and authentication module to ensure secure access; it uses a hardware security module to decrypt the original password and dynamically generate session keys for encryption to enhance data confidentiality; in addition, it uses a master key to encapsulate the session key and integrate the data to improve the overall security protection level and ensure data security.

[0110] As an optional implementation, based on any of the above embodiments, the encrypted response data is decrypted in the memory sandbox of a trusted execution environment to obtain the plaintext database password, including the following steps:

[0111] First, in the memory sandbox of the trusted execution environment, the encrypted response data is decrypted using a temporary decryption key generated by the hardware security module. During the decryption process, the access permissions of the memory region are set to be readable only by the decryption process through a memory protection hook.

[0112] Optionally, after the encrypted response data is transmitted to the memory sandbox of the trusted execution environment, the decryption module first sends a key generation request to the locally deployed hardware security module (HSM). The hardware security module dynamically generates a temporary decryption key based on a preset encryption algorithm (such as RSA-2048). The temporary decryption key is only used for the decryption operation of the encrypted response data. After decryption is completed, it is immediately destroyed by the hardware security module and does not remain in any memory area.

[0113] Optionally, the decryption module calls the temporary decryption key to perform layered decryption operations on the encrypted response data. First, it decrypts the encapsulated session key to obtain the temporary session key; then, it decrypts the ciphertext database password using the temporary session key to obtain the plaintext database password.

[0114] Optionally, during the entire decryption process, the memory protection hook mechanism built into the memory sandbox is activated. This mechanism intercepts memory access system calls, strictly restricting access permissions to the memory region where the decryption operation takes place to "readable only by the current decryption process," prohibiting any other process (including non-decryption processes within the memory sandbox and system processes outside the trusted execution environment) from performing read, write, or modification operations on that region, thus blocking the risk of memory data theft from the underlying level. If an illegal access request is detected, the memory protection hook immediately triggers a security interrupt, terminating the decryption operation and destroying all related data.

[0115] Secondly, after decryption is complete, retain the plaintext database password and clear any remaining intermediate decryption data from memory.

[0116] Optionally, after decryption, the obtained plaintext database password is temporarily stored in a dedicated cache area within a memory sandbox for subsequent write operations to non-heap memory. This dedicated cache area is also subject to memory protection hook access control. Furthermore, all residual data generated during the decryption process, including copies of encrypted response data, the memory cache of the temporary decryption key, the intermediate decryption state of the session key, and fragments of the ciphertext password, are thoroughly erased using a dual approach of memory overwriting and physical erasure.

[0117] Optionally, by calling the secure memory operation interface provided by the trusted execution environment, the memory address where the intermediate data is located is overwritten multiple times (at least 3 times) with randomly generated scrambled data to ensure that the original intermediate data cannot be restored by the memory recovery tool. Optionally, for the temporary decryption key stored in the hardware security module cache, physical erasure is triggered by hardware instructions to completely remove key residues. After the intermediate data is cleared, the clearing effect is verified by a memory integrity verification tool to ensure that no decryption intermediate data residue remains.

[0118] Optionally, the temporary session key can be destroyed immediately after decryption. This can be achieved by overwriting the memory area containing the session key with random data, thus avoiding security risks caused by session key leakage. If an anomaly occurs during decryption, such as session key decryption failure or password data decryption failure, the memory sandbox will trigger a security alarm, destroy all received encrypted response data, and stop subsequent processes.

[0119] This application provides a database password management method that uses a temporary key from a hardware security module to decrypt passwords within a trusted execution environment memory sandbox. It also employs memory protection hooks to strictly limit the permissions of the decryption process, preventing unauthorized data access. After decryption, intermediate data is promptly cleared to avoid leakage of residual information, thus ensuring the security of plaintext database passwords.

[0120] As an optional implementation, based on any of the above embodiments, the following steps are also included:

[0121] First, the access patterns of non-heap memory regions are monitored in real time.

[0122] Optionally, after the plaintext database password is written to the locked read-only non-heap memory area, the memory access monitoring module can monitor all access behaviors to the non-heap memory area in real time.

[0123] Optionally, the monitored content includes, but is not limited to: the access subject (the process / thread ID that initiated the memory access), the access method (read / write / modify), the access pointer type (safe pointer / non-safe pointer), the access timestamp, and the access address range. Among these, a safe pointer is a preset, valid access pointer, granted only to the database connection pool process of the target middleware, and a safe pointer must pass identity verification by the trusted execution environment to become effective; a non-safe pointer refers to an access pointer that has not undergone identity verification, is not in the preset list of valid pointers, or points to an abnormal memory address.

[0124] Optionally, the memory access monitoring module captures access behavior by hooking system memory access functions (such as the mmap() and read() functions in Linux systems), and performs real-time verification of each access behavior in combination with a preset access rule base (which stores legitimate access subjects, security pointer information, allowed access methods, etc.) to ensure that all access operations comply with security specifications.

[0125] Secondly, when a memory access request is detected through an unsafe pointer, it is determined to be an illegal read operation, triggering a memory data overwrite and clear operation, and disconnecting all current database connections.

[0126] Optionally, when the memory access monitoring module captures a memory access request, it first verifies the pointer type that initiates the access. If it detects that the access request is initiated by an unsafe pointer, such as an unauthorized system process attempting to read a non-heap memory region through a custom pointer, or an abnormal pointer initiating access by breaking through permission restrictions, then the memory access request is determined to be an illegal read behavior, triggering the emergency response process.

[0127] Optionally, the plaintext database password and related cached data in the non-heap memory area can be overwritten by calling the secure memory operation interface of the trusted execution environment. Multiple overwrites using random scrambled data ensure the plaintext password cannot be recovered. Furthermore, all security pointers related to the non-heap memory area are destroyed to prevent accidental access by subsequent legitimate processes. Alternatively, the database connection pool's forced closure interface can be used to immediately disconnect all active connections between the target middleware and the database, preventing attackers from using the password to steal business data through existing connections after a plaintext password is leaked due to unauthorized read operations.

[0128] This application provides a database password management method that, through real-time monitoring of access patterns in non-heap memory regions, can promptly detect illegal read operations initiated by unsafe pointers, trigger data overwriting and clearing, and disconnect the database connection, effectively preventing password leakage and improving the security protection capability of database passwords in memory.

[0129] As an optional implementation, based on any of the above embodiments, the following steps are also included:

[0130] First, continuously monitor the health status of the dynamic credential management center; among which, the monitoring indicators of health status include network latency, handshake success rate, and hardware security module response time.

[0131] Optionally, the target middleware's built-in health monitoring module can be used to continuously monitor the communication status between the target middleware and the dynamic credential management center, as well as the service status of the central node, through timed probing (the probing period is configurable, such as 10 seconds / time).

[0132] Optionally, by sending a PING request to the health check interface of the dynamic credential management center, the round-trip time (RTT) from request to response reception is calculated, and network latency is used to reflect the smoothness of network transmission.

[0133] Optionally, the success rate of the handshake between each encryption request (including health probe requests) and the dynamic credential management center to establish a TLS encrypted connection can be statistically analyzed. The calculation method is "number of successful handshakes / total number of handshakes × 100%", and the statistical period is consistent with the probe period.

[0134] Optionally, when sending a password request to the dynamic credential management center, the time taken from receiving the request from the center to returning the relevant data after decryption by the hardware security module is recorded. The response time of the hardware security module reflects the response efficiency of the center's core service (password decryption).

[0135] Optionally, after each detection, the health monitoring module compares the actual value of each indicator with the preset normal threshold and records whether the indicator is abnormal.

[0136] Secondly, if any monitoring indicator is abnormal and the duration exceeds the preset duration, the communication of the dynamic credential management center is determined to be abnormal, and the system switches to the local encrypted cache preset in the trusted execution environment to obtain the database password. During the switching process, the current database connection is kept available until the new connection is successfully verified.

[0137] Optionally, the health monitoring module continuously tracks each detection indicator. If any monitoring indicator is detected to be abnormal, such as network latency > 500ms, handshake success rate < 99.5%, or hardware security module response time > 1000ms, and the duration of the abnormal state exceeds the preset duration (e.g., 30 seconds, which can be configured according to business needs), it is determined to be a communication abnormality or service failure of the dynamic credential management center, and the local encrypted cache switching process is immediately triggered.

[0138] Optionally, the local encrypted cache is pre-installed in the secure storage area of ​​the Trusted Execution Environment (TEE). Specifically, after the target middleware successfully obtains the plaintext database password from the dynamic credential management center for the first time, it encrypts the plaintext password using the encryption key built into the TEE (this key is only stored within the TEE and cannot be exported), generates encrypted cache data, and stores it in the local encrypted cache. Subsequently, each time a new password is successfully obtained from the dynamic credential management center (such as after password rotation), the data in the local encrypted cache is updated synchronously to ensure the timeliness of the cached data.

[0139] Optionally, the health monitoring module sends a cache switching command to the memory management module. The memory management module calls the decryption interface within the TEE and uses the TEE's built-in encryption key to decrypt the data in the local encrypted cache to obtain the plaintext database password. The decrypted plaintext password is then written to a new locked read-only non-heap memory area, replacing the password data obtained from the original center. During the switching process, the memory management module maintains the availability of all currently active database connections. Only after a new database connection established using the cached password is successfully verified (e.g., the connection is confirmed to be valid through a database connection test) will the original connection be gradually released to avoid business interruption during the switching process.

[0140] This application provides a database password management method that continuously monitors the health status of the dynamic credential management center. When the communication of the dynamic credential management center is abnormal, it can seamlessly switch to the local encrypted cache to retrieve the password and keep the current connection available until the new connection is successfully verified. This not only ensures the availability of password management but also avoids service interruption caused by switching.

[0141] As an optional implementation, based on any of the above embodiments, switching to a pre-configured local encrypted cache within a trusted execution environment to obtain the database password includes the following steps:

[0142] First, when the communication of the dynamic credential management center is determined to be abnormal, the emergency control switch is triggered to read the encrypted database password from the local encrypted cache preset in the trusted execution environment. The database password in the local encrypted cache is encrypted and protected by a segmented key that is different from the master key. The segmented key is generated through the fingerprint information of the hardware security module.

[0143] Optionally, after determining that the dynamic credential management center has communication abnormalities or service failures, the health monitoring module immediately triggers a preset emergency control switch. This emergency control switch is a hardware-level switch built into the Trusted Execution Environment (TEE). It can only be triggered when the center communication is abnormal and the duration exceeds a preset threshold. After being triggered, it will activate the access permissions of the local encrypted cache within the TEE. In the untriggered state, the local encrypted cache is in a completely closed state and cannot be accessed by any process.

[0144] Optionally, after the emergency control switch is activated, the memory management module initiates a local encrypted cache access request within the TEE to read the encrypted database password stored therein. It should be noted that the database password in the local encrypted cache is protected by a segmented key. This segmented key is completely independent of the master key used by the Dynamic Credential Management Center and the Local Hardware Security Module (HSM) (i.e., it is different from the master key used to encrypt the original password and encapsulate the session key), thus avoiding the risk of simultaneous leakage of the local cached password if the master key is leaked.

[0145] Optionally, based on the unique fingerprint information of the locally deployed hardware security module (such as the HSM device serial number, the physical identifier of the hardware encryption chip, and other tamper-proof hardware features), a key derivation algorithm (such as PBKDF2, HKDF, etc.) is used to generate the key. The entire generation process is performed inside the HSM. After the segmented key is generated, it is only stored in the secure storage area of ​​the TEE and cannot be exported to the outside of the TEE, thereby ensuring the encryption security of the locally cached password.

[0146] Secondly, after reading the encrypted database password, the plaintext database password is decrypted using a segmented key in a memory sandbox within a trusted execution environment.

[0147] Optionally, after reading the encrypted database password, the memory management module does not directly perform the decryption operation. Instead, it transmits the encrypted password data to the memory sandbox of the Trusted Execution Environment (TEE) (which is derived from the decryption sandbox of S204 and has the same memory isolation and security protection features). Subsequently, the memory sandbox uses the segmented key in the TEE secure storage area to decrypt the encrypted database password.

[0148] Optionally, during the decryption process, a memory protection hook can be used to restrict the access scope of the decryption process, allowing only the decryption process to read the encrypted password data and segmented keys, while prohibiting any other process (including non-decryption processes within the TEE) from intervening. Furthermore, intermediate data generated during the decryption process is only stored in the sandbox's temporary memory area and is not written to any persistent storage medium. Once decryption is complete, the plaintext database password can be obtained.

[0149] Optionally, after the plaintext database password is obtained, it is written to a new read-only non-heap memory area locked by system calls, replacing the original password data obtained from the center. During the switchover, the memory management module maintains the availability of all currently active database connections, and only releases the original connection gradually after the new database connection established using the cached password is successfully verified, so as to avoid business interruption during the switchover.

[0150] This application provides a database password management method that, when communication with the dynamic credential management center is abnormal, triggers an emergency control switch to read the local encrypted cache and decrypts it in a trusted execution environment memory sandbox using a segmented key different from the master key. This ensures the reliability of password acquisition in emergency situations and enhances the security of the locally cached password with the help of a unique segmented key and a trusted environment, effectively solving the password management problem in disaster recovery scenarios.

[0151] Figure 4 This is a schematic diagram of the structure of a database password management device provided in an embodiment of this application, as shown below. Figure 4 As shown, the database password management device provided in this embodiment is located in an electronic device. The database password management device 40 provided in this embodiment includes: a configuration file parsing module 41, an encryption request construction and sending module 42, an encryption response receiving module 43, a decryption module 44, and a writing module 45.

[0152] Specifically, the configuration file parsing module 41 is used to parse the configuration file of the target middleware in response to the received start command of the target middleware, so as to extract password variables that conform to the preset format; wherein, the password variables include namespace identifier and password item identifier; the encryption request construction and sending module 42 is used to construct an encryption request carrying a digital signature based on the password variables and send the encryption request to the dynamic credential management center; the encryption response receiving module 43 is used to receive the encryption response data returned by the dynamic credential management center after responding to the encryption request; wherein, the encryption response data is obtained by the dynamic credential management center using a temporarily generated session key after completing client identity authentication, access permission verification and decryption of the original password using the hardware security module, and the session key is encapsulated by the master key of the hardware security module; the decryption module 44 is used to decrypt the encryption response data in the memory sandbox of the trusted execution environment to obtain the plaintext database password; the writing module 45 is used to write the plaintext database password to the non-heap memory area locked by the system call and set read-only access permissions.

[0153] Optionally, the encryption request construction and sending module 42, when constructing an encryption request carrying a digital signature based on the cryptographic variables and sending the encryption request to the dynamic credential management center, specifically performs the following: extracting the namespace identifier and cryptographic item identifier from the cryptographic variables using regular expressions, and encapsulating them into a request body according to a preset data format; using a hardware security module to sign the request body to generate a digital signature and add it to the request header to form an encryption request; sending the encryption request to the dynamic credential management center through an encrypted communication channel, and recording the interaction between the target middleware and the dynamic credential management center in the audit log, which includes the operation subject, operation time, request content, and response result.

[0154] Optionally, the encrypted response data is obtained by the dynamic credential management center after completing client authentication, access permission verification, and decryption of the original password using the hardware security module, using a temporarily generated session key for encryption. This includes: verifying the validity of the client certificate through the gateway, confirming the client's access permissions to the namespace through the authentication module, and decrypting the stored original database password by calling the hardware security module interface; after obtaining the original database password, encrypting the original database password based on the dynamically generated session key to obtain the encrypted database password; and encapsulating the session key using the master key of the hardware security module, integrating the encrypted database password and the encapsulated session key into the encrypted response data.

[0155] Optionally, when decrypting the encrypted response data in the memory sandbox of the trusted execution environment to obtain the plaintext database password, the decryption module 44 is specifically used to: decrypt the encrypted response data in the memory sandbox of the trusted execution environment using a temporary decryption key generated by the hardware security module, and during the decryption process, set the access permissions of the memory area to be readable only by the decryption process through the memory protection hook; after the decryption is completed, retain the plaintext database password and clear the residual decryption intermediate data in memory.

[0156] Optionally, the database password management device provided in this embodiment also includes a monitoring module.

[0157] Optionally, the monitoring module is used to: monitor the access patterns of non-heap memory regions in real time; when a memory access request is detected through an unsafe pointer, it is determined to be an illegal read behavior, triggering a memory data overwrite and clear operation, and disconnecting all current database connections.

[0158] Optionally, the monitoring module is also used to: continuously monitor the health status of the dynamic credential management center; wherein the health status monitoring indicators include network latency, handshake success rate and hardware security module response time; if any monitoring indicator is abnormal and the duration exceeds the preset duration, it is determined that the communication of the dynamic credential management center is abnormal, and it switches to the local encrypted cache preset in the trusted execution environment to obtain the database password, and the current database connection remains available during the switching process until the new connection is successfully verified.

[0159] Optionally, when the monitoring module switches to the local encrypted cache preset in the trusted execution environment to obtain the database password, it specifically performs the following: when an abnormality is detected in the communication of the dynamic credential management center, it triggers an emergency control switch to read the encrypted database password from the local encrypted cache preset in the trusted execution environment; wherein, the database password in the local encrypted cache is encrypted and protected using a segmented key different from the master key, and the segmented key is generated through the fingerprint information of the hardware security module; after reading the encrypted database password, it is decrypted using the segmented key in the memory sandbox of the trusted execution environment to obtain the plaintext database password.

[0160] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, as shown below. Figure 5 As shown, the electronic device 50 provided in this embodiment includes a processor 52 and a memory 51 that is communicatively connected to the processor 52.

[0161] The memory 51 stores computer execution instructions, and the processor 52 executes the computer execution instructions stored in the memory 51 to implement the method provided in any of the above embodiments.

[0162] The program may include program code, which includes computer-executable instructions. Memory 51 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0163] In this embodiment, the memory 51 and the processor 52 are connected via a bus. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single straight line, but this does not mean that there is only one bus or one type of bus.

[0164] This application also provides a computer-readable storage medium, including computer-executable instructions stored in the computer-readable storage medium, which, when executed by a processor, are used to implement the method provided in any of the above embodiments.

[0165] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the above embodiments.

[0166] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0167] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0168] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0169] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0170] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0171] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0172] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0173] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0174] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for managing database passwords, characterized in that, include: In response to receiving a start command from the target middleware, the configuration file of the target middleware is parsed to extract password variables that conform to a preset format; wherein, the password variables include a namespace identifier and a password item identifier; An encrypted request carrying a digital signature is constructed based on the cryptographic variables, and the encrypted request is sent to the dynamic credential management center; The system receives encrypted response data returned by the dynamic credential management center after responding to the encryption request; wherein the encrypted response data is obtained by the dynamic credential management center using a temporarily generated session key after completing client identity authentication, access permission verification, and decrypting the original password using the hardware security module, and the session key is encapsulated by the master key of the hardware security module. The encrypted response data is decrypted in the memory sandbox of the trusted execution environment to obtain the plaintext database password; Write the plaintext database password into a non-heap memory region locked by a system call, and set read-only access permissions.

2. The method according to claim 1, characterized in that, The step of constructing an encryption request carrying a digital signature based on the cryptographic variables and sending the encryption request to the dynamic credential management center includes: The namespace identifier and the password item identifier are extracted from the password variables using regular expressions, and then encapsulated into a request body according to a preset data format. The request body is signed using a hardware security module to generate a digital signature, which is then added to the request header to form the encrypted request. The encrypted request is sent to the dynamic credential management center through an encrypted communication channel, and the interaction between the target middleware and the dynamic credential management center is recorded in the audit log. The audit log includes the operation subject, operation time, request content, and response result.

3. The method according to claim 1, characterized in that, The encrypted response data is obtained by the dynamic credential management center after completing client identity authentication, access permission verification, and decrypting the original password using the hardware security module, using a temporarily generated session key. It includes: The gateway verifies the validity of the client certificate, the authentication module confirms the client's access rights to the namespace, and the hardware security module interface is called to decrypt the stored original database password. After obtaining the original database password, the original database password is encrypted based on the dynamically generated session key to obtain the encrypted database password; The session key is encapsulated using the master key of the hardware security module, and the encrypted database password and the encapsulated session key are integrated into the encrypted response data.

4. The method according to claim 1, characterized in that, The step of decrypting the encrypted response data in the memory sandbox of a trusted execution environment to obtain the plaintext database password includes: In the memory sandbox of the Trusted Execution Environment, the encrypted response data is decrypted using a temporary decryption key generated by the hardware security module. During the decryption process, the access permissions of the memory area are set to be readable only by the decryption process through a memory protection hook. After decryption is complete, the plaintext database password is retained and any remaining intermediate decryption data in memory is cleared.

5. The method according to any one of claims 1-4, characterized in that, Also includes: Real-time monitoring of access patterns in the non-heap memory region; When a memory access request initiated through an unsafe pointer is detected, it is determined to be an illegal read operation, triggering a memory data overwrite and clear operation, and disconnecting all current database connections.

6. The method according to any one of claims 1-4, characterized in that, Also includes: Continuously monitor the health status of the dynamic credential management center; wherein the monitoring indicators of the health status include network latency, handshake success rate, and hardware security module response time; If any of the monitoring indicators is abnormal and the duration exceeds the preset duration, the communication of the dynamic credential management center is determined to be abnormal, and the system switches to the local encrypted cache preset in the trusted execution environment to obtain the database password. During the switching process, the current database connection is kept available until the new connection is successfully verified.

7. The method according to claim 6, characterized in that, The step of switching to a pre-configured local encrypted cache within a trusted execution environment to obtain the database password includes: When the communication of the dynamic credential management center is determined to be abnormal, an emergency control switch is triggered to read the encrypted database password from the local encryption cache preset in the trusted execution environment; wherein, the database password in the local encryption cache is encrypted and protected by a segment key different from the master key, and the segment key is generated through the fingerprint information of the hardware security module; After reading the encrypted database password, it is decrypted using a segmented key in a memory sandbox of a trusted execution environment to obtain the plaintext database password.

8. A database password management device, characterized in that, include: The configuration file parsing module is used to parse the configuration file of the target middleware in response to receiving the start command of the target middleware, so as to extract password variables that conform to a preset format; wherein, the password variables include namespace identifiers and password item identifiers; The encryption request construction and sending module is used to construct an encryption request carrying a digital signature based on the cryptographic variables, and send the encryption request to the dynamic credential management center; The encrypted response receiving module is used to receive encrypted response data returned by the dynamic credential management center after responding to the encryption request; wherein, the encrypted response data is obtained by the dynamic credential management center using a temporarily generated session key after completing client identity authentication, access permission verification and decrypting the original password using the hardware security module, and the session key is encapsulated by the master key of the hardware security module. The decryption module is used to decrypt the encrypted response data in the memory sandbox of the trusted execution environment to obtain the plaintext database password; The write module is used to write the plaintext database password to a non-heap memory area locked by a system call and set read-only access permissions.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images