A method and system for protecting sensitive information of a bearer network management and control system

Abstract

The application discloses a sensitive information protection method and system of a bearer network management and control system, and relates to the technical field of communication network security management. The method comprises the following steps: obtaining production data to be processed, and dividing the production data into a sensitive field subset and a non-sensitive field subset according to preset field sensitivity rules; obtaining permission level information of a current access user; a password security module dynamically generates an encryption strategy according to the permission level information; encryption processing is performed on the sensitive field subset according to the encryption strategy, and the non-sensitive field subset is kept in a plaintext state; and when it is detected that the permission level information is changed, a key invalidation operation is performed. The application adopts field information hierarchical encryption, keeps non-sensitive information in a plaintext state, meets the quick identification demand of operation and maintenance personnel, establishes a closed-loop linkage mechanism of a permission model and an encryption strategy, and automatically triggers key invalidation when the permission is changed, so that the technical problem that security compliance and operation and maintenance efficiency are difficult to balance is effectively solved, and the dynamic security protection capability of the system is improved.

Description

Technical Field

[0001] This application relates to the field of communication network security management, specifically to a method and system for protecting sensitive information in a bearer network management and control system. Background Technology

[0002] Bearer network management and control systems (such as dedicated communication network management systems for industries like power and transportation) are responsible for managing network topology, equipment configuration, and user information. They have extremely high data security requirements and must use national cryptographic algorithms to encrypt sensitive information to prevent leakage and tampering.

[0003] Currently, the bearer network management and control system mainly adopts the following methods to ensure data security: Transparent Database Encryption (TDE) encrypts the entire tablespace or data file.

[0004] The application layer uses full-field encryption, and the business code calls the password interface uniformly for all fields entering the database.

[0005] Role-based access control (RBAC) uses a permission system to control whether users can access specific data.

[0006] In actual operation, maintenance, and development, the following problems were found in the aforementioned existing technologies: First, the encryption granularity is too coarse, making it difficult to balance security and operational efficiency.

[0007] Most existing solutions employ either full encryption or full plaintext encryption. Full encryption encrypts all fields (including non-sensitive but frequently viewed information such as device IP ranges, port status, and alarm types). When troubleshooting or topology analysis, maintenance personnel must decrypt all data, resulting in slow query responses and an inability to quickly locate network segments or devices directly from plaintext information, severely impacting operational efficiency. Full plaintext encryption, on the other hand, directly exposes sensitive information (such as login credentials and routing keys). There is a lack of methods that can automatically distinguish between plaintext visibility and encrypted protection based on field attributes within a single data record.

[0008] Second, the access control and encryption strategies are disconnected, resulting in insufficient dynamic response capabilities.

[0009] Existing access control systems and password encryption systems typically operate independently. Encryption policies are often fixed during system initialization and do not dynamically adjust with changes in user permissions. For example, when an operations and maintenance personnel's permissions are downgraded, their cached decryption keys or encrypted access permissions under the old policy may still be valid, posing a time window risk. Furthermore, the access control model only controls whether data can be accessed, not the encryption strength used. Users with high and low permissions see the same level of data encryption, lacking dynamic de-identification or policy linkage mechanisms based on permission levels.

[0010] Third, the encryption strategies for sensitive fields are rigid and lack dynamic adaptation to business scenarios. Existing technologies rely heavily on hard-coding by developers or manual configuration tables when distinguishing sensitive fields. Even if some systems support automatic classification, their encryption strategies are often static and cannot dynamically adjust encryption strength or visibility based on user permission levels. In the complex metadata model of the bearer network, manual configuration is prone to omissions or misclassifications, resulting in sensitive information being unencrypted or non-sensitive information being mistakenly encrypted.

[0011] In summary, there is an urgent need for a sensitive information protection method that can automatically select the encryption range based on field attributes and dynamically adjust the encryption strategy and trigger linkage failure based on user permissions, in order to solve the problem of balancing security compliance and operation and maintenance efficiency in the bearer network management and control system. Summary of the Invention

[0012] This application provides a method and system for protecting sensitive information in a bearer network management and control system, which can solve the technical problems in the prior art, such as the ease with which permission data can be tampered with, leading to the bypassing of encryption strategies, and the difficulty in balancing security and operation and maintenance efficiency due to excessively coarse encryption granularity.

[0013] In a first aspect, embodiments of this application provide a method for protecting sensitive information in a bearer network management and control system, characterized in that the method includes: Obtain the production data to be processed, and divide the production data into sensitive data segments and non-sensitive data segments based on field sensitivity rules; Obtain the permission metadata of the currently accessing user, perform integrity verification on the permission metadata, and generate permission integrity verification information; An encryption strategy is dynamically generated based on the permission integrity verification information, and the encryption strategy includes a key parameter corresponding to the security level of the permission metadata. According to the encryption strategy, the sensitive data segments are processed using a fragmented encryption method, while the non-sensitive data segments are retained as plaintext. When a change in the permission metadata is detected, resulting in a change in the permission integrity verification information, the key index is updated based on the changed permission integrity verification information, thereby invalidating the key generated based on the old permission integrity verification information.

[0014] In conjunction with the first aspect, in one implementation, dividing the production data into sensitive and non-sensitive data segments based on field sensitivity rules includes: Read the metadata tags of the data field. If the metadata tags contain a preset sensitive identifier, the corresponding data field is divided into the sensitive data segment. Alternatively, use regular expressions to match the content features of the data field. If a preset sensitive information format is matched, the corresponding data field is divided into the sensitive data segment. The remaining data fields are divided into the non-sensitive data segments, which include device status fields, port number fields, or IP network segment fields used for troubleshooting maintenance faults.

[0015] In conjunction with the first aspect, in one implementation, the step of performing integrity verification on permission metadata and generating permission integrity verification information includes: A hash value for the permission metadata is calculated using a hash algorithm, and / or a digital signature algorithm is used to sign the digest of the permission metadata; the hash value and / or signature value are used as the permission integrity verification information. The permission integrity verification information includes a permission fingerprint, which is a hash value calculated by concatenating all direct and indirect authorizations based on the permission metadata in a standardized order.

[0016] In conjunction with the first aspect, in one implementation, the step of dynamically generating an encryption strategy based on the permission integrity verification information includes: Establish a mapping table between permission levels and encryption parameters; when the permission level indicated by the permission metadata is a low permission level, select a key of a first length or an encryption algorithm of a first security mode; when the permission level indicated by the permission metadata is a high permission level, select a key of a second length or an encryption algorithm of a second security mode. Wherein, the key length of the first length is greater than the key length of the second length, or the security level of the first security mode is higher than that of the second security mode.

[0017] In conjunction with the first aspect, in one implementation, the processing of the sensitive data fragment using a fragmented encryption method includes: If the permission metadata includes sensitive viewing permissions, a decryption key is generated to display the plaintext of the sensitive data fragment; if the permission metadata does not include sensitive viewing permissions, only the ciphertext or de-identified characters of the sensitive data fragment are displayed. The sensitive viewing permission is configured independently of the read and write permissions and is used to control the decryption visibility of sensitive segments within a field.

[0018] In conjunction with the first aspect, in one implementation, invalidating the key generated based on the old permission integrity verification information includes: A version number is generated for the encryption policy, and the version number is bound to the permission integrity verification information; when the permission metadata changes, the version number is updated and the key index corresponding to the old version number is invalidated; when a decryption request is received, the version number carried in the request is verified, and if the version number is inconsistent with the current latest policy version number, decryption is rejected.

[0019] In conjunction with the first aspect, in one implementation, the sensitive data segment includes a sensitive portion of structured data; retaining the non-sensitive data segment as plaintext includes: For sensitive data fields with a predetermined structure format, non-sensitive and sensitive components are identified according to their structure definition; the non-sensitive components are used to quickly locate or identify the business context and are retained as plaintext; the sensitive components contain business secret information and are encrypted.

[0020] The predetermined structure format includes, but is not limited to: network and host bits of an IP address, OUI and serial number of a MAC address, key and value in a configuration file key-value pair, or specific tag content in JSON / XML structured data.

[0021] In conjunction with the first aspect, in one embodiment, the method further includes: Record audit logs for all encryption, decryption, and permission change operations; protect the integrity of the audit logs by calculating and storing checksums using a hash algorithm; generate a security alarm when a checksum mismatch is detected in the audit logs.

[0022] Secondly, embodiments of this application provide a sensitive information protection system for a bearer network management and control system, the system including an application module and a cryptographic security module; The application module is used to acquire production data to be processed and divide the production data into sensitive data segments and non-sensitive data segments based on field sensitivity rules; it is also used to acquire the permission metadata of the currently accessing user and send an encrypted request carrying the permission metadata to the password security module. The cryptographic security module is used to perform integrity verification on the permission metadata and generate permission integrity verification information; it is also used to dynamically generate an encryption strategy based on the permission integrity verification information, the encryption strategy including key parameters corresponding to the security level of the permission metadata; and to process the sensitive data fragments using a fragmented encryption method according to the encryption strategy, while retaining the non-sensitive data fragments as plaintext; and when a change in the permission metadata is detected that causes a change in the permission integrity verification information, the key index is updated based on the changed permission integrity verification information, making the key generated based on the old permission integrity verification information invalid.

[0023] In conjunction with the second aspect, in one implementation, the application module is specifically used for: The metadata tags of data fields are read. If the metadata tags contain preset sensitive identifiers, they are classified into the sensitive data segment; or, regular expressions are used to match the content features of data fields. If a preset sensitive information format is matched, it is classified into the sensitive data segment. The remaining data fields are classified into the non-sensitive data segment, which includes device status fields, port number fields, or IP network segment fields used for troubleshooting maintenance faults. The password security module is specifically used to: calculate the hash value of the permission metadata using a hash algorithm, and / or sign the digest of the permission metadata using a digital signature algorithm; use the hash value and / or signature value as the permission integrity verification information; generate a version number for the encryption policy and bind the version number to the permission integrity verification information; when the permission metadata changes, update the version number and invalidate the key index corresponding to the old version number.

[0024] The beneficial effects of the technical solutions provided in this application include: By performing integrity verification on permission metadata to generate permission integrity verification information, and dynamically generating encryption policies based on this information, the credibility of the permission information driving the encryption policies is ensured, preventing the risk of encryption policies being bypassed due to tampering with permission data. Simultaneously, triggering key expiration based on changes in permission integrity verification information eliminates the security window following permission changes, enhancing the system's dynamic security protection capabilities.

[0025] By dividing production data into sensitive and non-sensitive data segments based on field sensitivity rules and employing segmented encryption, fine-grained plaintext and ciphertext coexistence within fields is achieved. Maintenance personnel can view non-sensitive segments (such as IP network segments and device status) without decryption, quickly locating faults, while sensitive segments (such as passwords and host bits) are strictly protected. This solves the technical problem of low maintenance efficiency caused by overly coarse encryption granularity in related technologies.

[0026] The key parameters (such as key length and algorithm mode) are dynamically adjusted according to the security level of the permission metadata, realizing differentiated protection of low-privilege high security and high-privilege high efficiency, which meets the diverse security needs of the bearer network management and control system in complex scenarios. Attached Figure Description

[0027] Figure 1 This is an overall flowchart of a sensitive information protection method for a bearer network management and control system provided in an embodiment of the present invention; Figure 2 This is a sequence diagram of hierarchical encryption and decryption of information within fields in step S104 of the present invention. Figure 3The transmission encryption sequence diagram based on the permission model in step S105 provided in the embodiment of the present invention. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0030] Example 1 This embodiment provides a method for protecting sensitive information in a bearer network management system, applicable to dedicated communication network management systems in industries such as power and transportation. The method is implemented based on a three-layer independent architecture: application layer, cryptographic service layer, and data layer. The application module is deployed at the application layer, the cryptographic security module at the cryptographic service layer, and the business database and cryptographic resource pool at the data layer. The cryptographic security module is deployed independently of the application module, uniformly interfaces with the cryptographic resource pool, and is responsible for national cryptographic algorithm computation, key lifecycle management, and security policy enforcement.

[0031] like Figure 1 As shown, the method mainly includes the following steps: Step S101: Obtain production data containing multiple data fields and divide the data into segments.

[0032] Specifically, the application module obtains production data to be processed from the business database or device acquisition interface. This production data is typically structured data containing multiple data fields. Based on preset field sensitivity rules, the system divides the data fields into sensitive data segments and non-sensitive data segments.

[0033] In this embodiment, data segmentation can be achieved in the following ways: read the metadata tags of the data fields, and if the tags contain preset sensitive identifiers (such as "secret", "password", "key"), then the corresponding fields are segmented into sensitive data segments; or use regular expressions to match content features, and if sensitive information formats (such as key format strings, password hash values) are matched, then the data segments are segmented into sensitive data segments; the remaining fields are segmented into non-sensitive data segments, which typically include device status fields (such as port Up / Down status), port number fields, or IP network segment fields.

[0034] It should be noted that the sensitive data fragment can be the entire sensitive field or a portion of the data within a field. For example, for a piece of device configuration data, the entire "login password" field is identified as a sensitive data fragment; while for the "IP address" field, the "host bits" can be identified as a sensitive data fragment, and the "network bits" as a non-sensitive data fragment. Optionally, the field classification rules can be customized by the administrator through the configuration interface, supporting the dynamic addition of new sensitive field identifiers.

[0035] Step S102: Obtain the permission metadata of the currently accessing user and perform integrity verification.

[0036] Specifically, when a user initiates a data access request, the system obtains the current user's permission metadata through the identity authentication module.

[0037] The permission metadata includes not only permission level information (such as READ only permission, CONFIGURE permission, APPROVE permission, or SENSITIVE_VIEW permission), but also attributes such as permission validity period, permission scope, and user group affiliation. The system performs integrity verification on the permission metadata and generates permission integrity verification information. In a preferred embodiment of this example, the integrity verification can employ one or a combination of the following methods: The HMAC-SM3 algorithm is used to calculate the hash value of the permission metadata; The SM2 algorithm is used to digitally sign the digest of the authorization metadata; All authorization dimensions are concatenated in the specified order, and then an SM3 hash value is calculated to generate an authorization fingerprint. The hash value, signature value, or authorization fingerprint all serve as authorization integrity verification information. This measure aims to ensure that the authorization information driving the encryption policy itself has not been tampered with and its source is trustworthy.

[0038] Step S103: Send an encryption request to the cryptographic security module to dynamically generate an encryption policy.

[0039] Specifically, the application module sends an encryption request carrying the permission integrity verification information to an independently deployed cryptographic security module. The cryptographic security module dynamically generates an encryption policy based on the permission integrity verification information. The encryption policy includes at least a key length, an encryption algorithm mode, or a key lifecycle.

[0040] In this embodiment, the password security module internally establishes a mapping table between permission levels and encryption parameters. The policy generation logic follows the principle of low permission and high security: when the permission level is low (e.g., READ only), a 256-bit key or the SM4-GCM encryption algorithm is selected, and the key lifespan is set to a shorter period (e.g., 1 month); when the permission level is high (e.g., APPROVE), a 128-bit key or the SM4-CBC encryption algorithm is selected, and the key lifespan is set to a longer period (e.g., 6 months).

[0041] Step S104: Invoke the password resource and perform fragmented encryption according to the encryption strategy.

[0042] Specifically, the cryptographic security module calls cryptographic resources and performs encryption processing on sensitive data fragments according to the encryption policy, while non-sensitive data fragments are kept in plaintext.

[0043] In a preferred embodiment of this invention, the cryptographic resource is a hardware cryptographic resource, including a server cryptographic machine, a signature verification server, or an encryption card. The generation, storage, and use of the key are all completed within the hardware device, and the plaintext key is not stored locally, thus meeting the requirements of the national cryptographic standard. In another embodiment, the cryptographic resource can also be a software cryptographic library. For sensitive data segments, the national cryptographic standard SM4 algorithm is used for encryption.

[0044] For sensitive data segments containing structural information, a fragmented encryption method is used, encrypting only the sensitive parts of the segment. For example, for the IP address 10.10.1.100, "10.10." is retained as the plaintext of the non-sensitive data segment, and only the sensitive data segment "1.100" is encrypted. Maintenance personnel can quickly locate the area to which the device belongs by using the plaintext network segment "10.10." without decryption.

[0045] Step S105: Monitor permission changes and perform key expiration operation.

[0046] Specifically, the system monitors user permission metadata in real time. When a change in permission metadata is detected that causes a change in the permission integrity verification information (such as a user being downgraded from configured permissions to read-only permissions, resulting in a change in the permission fingerprint, or a user leaving the company and having their permissions revoked), the password security module performs a key invalidation operation, rendering the key generated based on the old permission integrity verification information invalid.

[0047] In this embodiment, the key expiration operation can be implemented through a version number mechanism: a version number is generated for the encryption policy, and the version number is bound to the permission integrity verification information; when the permission metadata changes, the version number is updated and the key index corresponding to the old version number becomes invalid; when a decryption request is received, the version number carried in the request is verified, and if the version number is inconsistent with the current latest policy version number, decryption is rejected. This mechanism ensures that the old key becomes invalid within minutes after the permission change, eliminating the security time window risk caused by the permission synchronization delay in traditional schemes.

[0048] Step S106: Audit log recording and integrity protection.

[0049] Specifically, audit logs are recorded for all encryption, decryption, and permission change operations. An integrity checksum is calculated using the HMAC-SM3 algorithm on the audit logs and stored. A security alert is generated when a checksum mismatch is detected.

[0050] This embodiment achieves fine-grained encryption protection at the field level through the above steps, solving the problem of balancing security compliance and operational efficiency. In particular, by generating permission integrity verification information through integrity verification of permission metadata, it ensures the trustworthiness of the permission source driving the encryption policy and prevents the risk of permission tampering; and through the dynamic linkage between permission integrity verification information and encryption policy, as well as the immediate invalidation mechanism of keys after permission changes, it eliminates the security time window risk existing in traditional solutions.

[0051] Example 2 This embodiment provides a sensitive information protection system for a bearer network management and control system, used to implement the sensitive information protection method described in Embodiment 1. For example... Figure 2 As shown, the system is deployed based on a three-layer independent architecture: application layer, cryptographic service layer, and data layer. It mainly includes an application module and a cryptographic security module. The application module is deployed at the application layer, and the cryptographic security module is deployed at the cryptographic service layer; the two interact with each other through a secure communication channel.

[0052] The application module is primarily used for business logic processing and data preprocessing. Specifically, the application module includes a data classification unit, a permission management unit, and a request forwarding unit. The data classification unit acquires production data containing multiple data fields from a business database or device acquisition interface, and divides these data fields into sensitive data fragments and non-sensitive data fragments based on field sensitivity rules. In this embodiment, the sensitive and non-sensitive data fragments are the same as the data fields themselves. The division rules support field-level division and fragment-level division within fields. The classification rules support metadata tag recognition and regular expression matching, and administrators can customize sensitive field identifiers through the configuration interface. The permission management unit interfaces with the identity authentication module to obtain the permission metadata of the currently accessing user. The permission metadata includes permission level information (such as READ only permission, CONFIGURE configuration permission, etc.), permission validity period, permission scope, and user group affiliation. In this embodiment, the permission metadata is the same as the permission metadata itself. The permission information is cached in the local session, and its validity period is consistent with the user's login session. The request forwarding unit sends an encryption request to the password security module, the request carrying the permission metadata, the data to be encrypted, and the fragment classification identifier. The request forwarding unit is also used to receive the encryption result returned by the cryptographic security module, assemble the ciphertext of sensitive data fragments with the plaintext of non-sensitive data fragments, and return them to the front end for display.

[0053] The cryptographic security module, deployed independently of the business system, is primarily used for cryptographic operations, integrity verification, and key management. Specifically, the cryptographic security module includes an integrity verification unit, a policy generation unit, an encryption execution unit, and a key management unit. The integrity verification unit performs integrity verification on the permission metadata, generating permission integrity verification information. In this embodiment, the permission integrity verification information is specifically implemented as a permission fingerprint, HMAC hash value, or digital signature value calculated based on the permission metadata. This aims to ensure that the permission information driving the encryption policy itself has not been tampered with. The policy generation unit internally establishes a mapping table between permission integrity verification information and encryption parameters, and dynamically generates an encryption policy by querying the mapping table based on the received permission integrity verification information. The encryption policy includes key length, encryption algorithm mode, and key lifecycle.

[0054] In this embodiment, the policy generation unit is configured to: select a key of a first length or an encryption algorithm of a first security mode when the permission integrity verification information indicates a low permission level; and select a key of a second length or an encryption algorithm of a second security mode when the permission integrity verification information indicates a high permission level. The first length key is longer than the second length key.

[0055] The encryption execution unit is used to invoke cryptographic resources to perform encryption processing on the sensitive data fragments. The cryptographic resources can be hardware cryptographic resources or software cryptographic resources. When they are hardware cryptographic resources, they include server cryptographic machines, signature verification servers, or encryption cards; when they are software cryptographic resources, they include software cryptographic libraries or virtualized cryptographic services. For structured sensitive data fragments such as IP addresses, the encryption execution unit uses a fragmented encryption method, encrypting only the sensitive parts of the fragment (such as host bits) and retaining the non-sensitive parts (such as network bits) as plaintext.

[0056] The key management unit is responsible for the full lifecycle management of the keys. The key management unit is configured to: generate a version number for the encryption policy and bind the version number to permission integrity verification information; when changes in permission metadata cause changes in the permission integrity verification information, update the version number and invalidate the key index corresponding to the old version number; upon receiving a decryption request, verify the version number carried in the request, and if the version number is inconsistent with the current latest policy version number, refuse decryption.

[0057] Optionally, the system further includes an audit log module for recording audit logs of all encryption, decryption, and permission change operations. The audit log module is configured to: calculate and store integrity check values ​​for the audit logs using the HMAC-SM3 algorithm; and generate a security alarm when a check value mismatch is detected.

[0058] The system described in this embodiment decouples business logic from cryptographic operations by separately deploying the application module and the cryptographic security module. The application module focuses on business data classification and permission acquisition, while the cryptographic security module focuses on integrity verification, policy generation, and encryption execution. Working together, the two ensure the trustworthiness of the encryption driver source through integrity verification of permission metadata, and improve operational efficiency through field-level and fragment-level hierarchical encryption, thus meeting the compliance requirements for sensitive information protection.

[0059] Example 3 This embodiment provides the basic support process for the sensitive information protection method of the bearer network management and control system, including system initialization, user identity authentication and audit tracing, providing preconditions and post-guarantees for the core encryption process described in Embodiment 1.

[0060] First, regarding system initialization and key pre-deployment. Before implementing sensitive information protection methods, system initialization and key pre-deployment must be completed to provide a root of trust and key resources for subsequent encryption strategies. The cryptographic resource pool is deployed at the data layer, including a server cryptographic machine, a signature verification server, or an encryption card. The generation, storage, use, and destruction of keys are all completed within the cryptographic device; external systems can only call the encryption interface and cannot directly access the key materials. Optionally, the cryptographic device can be a hardware cryptographic device or a software cryptographic library.

[0061] The SM2 root certificate is imported into the cryptographic security module to establish a system trust anchor. The SM2 key pair for legitimate users is generated by the cryptographic security module, and the user's private key certificate is imported into the client's USB-KEY hardware device, achieving "one person, one certificate" identity carrier binding. The USB-KEY supports the SM2 algorithm, the private key cannot be exported, and signature operations are performed internally within the hardware.

[0062] The cryptographic security module pre-generates corresponding key indexes for four core business areas: identity authentication, authorization metadata integrity protection, data transmission encryption, and data storage encryption. Specifically, the key index generated for the authorization metadata integrity protection business is used in step S102 of Example 1 to perform integrity verification on authorization metadata and generate authorization integrity verification information. A comprehensive key lifecycle management strategy is also established. The key validity period is configurable, with a default setting ranging from 1 to 6 months, and the rotation cycle is dynamically adjusted according to the authorization level. The key validity period, automatic rotation cycle, and destruction trigger conditions are clearly defined to achieve automated and standardized key management.

[0063] Optionally, the system supports multiple sets of keys operating in parallel, with a version number mechanism used to identify the transition between old and new keys, ensuring business continuity. Furthermore, the system implements integrity protection for permission metadata. When permission configuration data is written to the database, the HMAC-SM3 algorithm is used to calculate the integrity check value of the permission data and bind it to storage. When a user logs in or authenticates permissions, the system recalculates the check value and compares it with the stored value. If they do not match, the system determines that the permission data has been illegally tampered with, refuses login, and triggers an alarm.

[0064] Secondly, regarding user authentication based on digital signatures: When a user initiates a data access request, the system executes an authentication process based on digital signatures to ensure the credibility of the access level information. The business system calls the password security module to generate a random number as a challenge code. The challenge code is 128 bits long and valid for 5 minutes to prevent replay attacks. The business system then sends the random number to the user's client.

[0065] The client uses the user's SM2 private key built into the USB-KEY to digitally sign the random number, generating a signature value. This signature value, along with the user's digital certificate, is then uploaded to the business system. The business system synchronously forwards the original random number, signature value, and user certificate to the password security module, initiating a signature verification request.

[0066] The password security module relies on a pre-installed CA root certificate to comprehensively verify the validity of user certificates, including certificate chain integrity, certificate validity period, and certificate revocation status. Upon successful verification, the user's public key is extracted from the certificate, and the signature value is verified using this public key. The password security module sends the verification result back to the business system. If the certificate is valid and the signature verification passes, the user is allowed to log in; otherwise, the login request is directly rejected, and a login failure log is recorded throughout the process.

[0067] Permission level information is cached in the session, and the session validity period is consistent with the user's login state. When the session times out or the user actively logs out, the permission information is cleared, and re-authentication is required for subsequent access. This mechanism resists brute-force attacks and man-in-the-middle attacks. Even if an attacker intercepts the communication data, they cannot obtain the private key in the USB-KEY, cannot forge a valid signature, and cannot pass authentication.

[0068] Finally, regarding end-to-end auditing and traceability: To meet compliance requirements and facilitate post-event accountability, the password security module generates standardized audit logs for all password operations, forming a comprehensive audit and traceability system. These audit logs cover all password operations, including: authentication, permission changes, encryption, decryption, signing, signature verification, session establishment and expiration, etc.

[0069] Each audit log entry includes standardized fields: operation time, user ID, operation target, operation type, operation result, request source IP, and terminal information. Logs are stored in a dual-copy mechanism: one copy in the business database and one copy in a separate audit database, preventing log loss due to single points of failure.

[0070] Audit logs are encrypted and stored using the SM4 algorithm, and an integrity checksum is calculated using the HMAC-SM3 algorithm. This checksum is stored in a data set bound to the log file. The checksum calculation covers the entire log content; any tampering with any field will result in checksum failure. The system periodically checks log integrity. If a checksum mismatch is detected, a security alert is generated, the relevant account is locked, and the security administrator is notified to intervene.

[0071] Authorized auditors, after strong authentication, can access the decrypted, complete logs. Auditor permissions are independent of business permissions; they can only view logs and cannot modify business data. Log queries support multi-dimensional filtering by time range, user ID, operation type, etc. Query results can be exported as encrypted files to prevent leakage during the export process.

[0072] This embodiment ensures full lifecycle protection of keys through system initialization, meeting compliance requirements; digital signature-based identity authentication ensures the trustworthiness of authorization information sources, preventing authorization forgery; full-process auditing and traceability meet post-event accountability needs; and log integrity protection prevents tampering. These three elements collectively support the core encryption process described in Embodiment 1, forming a complete security protection system.

[0073] Example 4 This embodiment, combined with a specific business scenario of a power transmission network management and control system, further illustrates the practical application process of the aforementioned sensitive information protection method. Based on the technical solutions described in Embodiments 1 to 3, this embodiment focuses on demonstrating how the system dynamically adjusts encryption strategies and the specific effects of hierarchical field display under different operation and maintenance scenarios. This embodiment is applied to a provincial-level power communication network management system, which is responsible for managing the device topology, configuration, and user information of the optical transmission network (OTN) within the region.

[0074] The first scenario is a routine maintenance and troubleshooting scenario. Maintenance personnel, Zhang, logs into the system via a client. After the identity authentication module verifies his digital signature, it confirms his permission level is CONFIGURE (configuration permission). Zhang initiates a device configuration query request. The production data obtained by the system includes fields such as device IP address, port number, optical power value, login password, and routing key.

[0075] The application module categorizes the login password and routing key into sensitive fields based on field sensitivity rules, and classifies the device IP address, port number, optical power value, and port status into non-sensitive fields. The password security module generates a corresponding encryption strategy based on Zhang's CONFIGURE permission level. In this embodiment, the strategy preferably uses the 128-bit SM4-CBC algorithm, with a key lifespan of 3 months.

[0076] For a subset of sensitive fields, the system uses password resources for encryption; for a subset of non-sensitive fields, they remain in plaintext. Specifically, for the structured field of the device IP address, the system employs a fragmented encryption method. For example, for the IP address 10.10.1.100, the network portion "10.10." is preserved in plaintext, while only the host portion "1.100" is encrypted. When displaying the query results on the front-end interface, Mr. Zhang can directly see the "10.10." network segment information, port status, and optical power value, quickly locating the area to which the faulty device belongs without any decryption. Sensitive fields such as login passwords are displayed as ciphertext or asterisks. Compared to a full encryption solution, the query response time is significantly reduced in this scenario, and maintenance personnel can complete most fault location work without applying for temporary decryption permissions.

[0077] The second scenario involves a user permission change linkage mechanism. When operations and maintenance personnel Zhang's permissions are downgraded from CONFIGURE to READ only due to a job reassignment, the system triggers the linkage mechanism between permissions and encryption policies. After the permission management system updates Zhang's permission level information, the password security module detects the change event and immediately executes a key invalidation operation.

[0078] Specifically, the system updates the encryption policy version number from V2.1 to V2.2 and marks the key index corresponding to the old version number V2.1 as invalid. The new encryption policy is adjusted to a higher security level, such as using the 256-bit SM4-GCM algorithm, and the key lifespan is shortened to one month. If Zhang does not log in again after the permission change and attempts to initiate a decryption request using the old session token (carrying version number V2.1), the password security module will find that the version number is inconsistent with the latest policy version number when verifying the version number, directly reject the decryption request, and return a "Permissions have changed, please log in again" prompt. This mechanism ensures that the old key becomes invalid within minutes after the permission change, eliminating the security time window risk caused by the permission synchronization delay in traditional schemes.

[0079] The third scenario involves audit tracing and integrity protection. Auditor Li needs to retrieve historical operation logs for a compliance audit. After logging in through authentication, the system confirms Li's permission level as APPROVE (approval permission). The password security module generates a corresponding audit policy, allowing Li to view the decrypted complete log content but restricting him from modifying business data.

[0080] The system retrieves logs from an independent audit database. These logs contain records of user login authentication, encryption policy generation, key usage, and permission changes. Before displaying the logs, the system calculates a log integrity checksum using the HMAC-SM3 algorithm and compares it to the stored value. If a log checksum mismatch is detected, the system immediately generates a security alert, locks the relevant account, and notifies the security administrator. After confirming the log integrity, Mr. Li can export the audit results. The exported file is encrypted to prevent data leakage during the export process. This process meets the requirements for tamper-proof and traceable audit logs in commercial cryptography application security assessments.

[0081] The fourth scenario is the fragmented encryption of structured data. For structured data such as IP addresses and MAC addresses commonly found in bearer networks, this embodiment employs a fragmented encryption strategy. Taking the IP address 192.168.10.100 as an example, the application module identifies it as a sensitive field. However, considering that maintenance personnel need to quickly locate devices through network segments, the system only encrypts the host portion "10.100," leaving the network portion "192.168." as plaintext. During storage, this field is presented as plaintext fragments concatenated with ciphertext data. Even if an external attacker obtains the database file, they cannot reconstruct the complete IP address for network scanning; while internal maintenance personnel can directly see the network segment information in their daily monitoring interface and perform topology analysis without decryption.

[0082] As can be seen from the above scenarios, the method described in this embodiment can achieve field-level hierarchical encryption, dynamic linkage between permissions and policies, and full-process audit traceability in actual bearer network management and control systems. It not only meets the compliance requirements for sensitive information protection but also solves the problem of low operational efficiency caused by traditional full-scale encryption schemes. In particular, by dynamically determining the encryption strength according to the permission level (e.g., using a 256-bit key for low permissions and a 128-bit key for high permissions), it achieves differentiated protection based on the trustworthiness of the terminal environment, possessing strong practicality and promotional value.

[0083] Example 5 This embodiment details the specific implementation and integrity protection process of the four-dimensional permission model in the bearer network management and control system, providing a permission management foundation for the sensitive information protection method described in Embodiment 1. The process described in this embodiment is mainly executed by the cryptographic security module in collaboration with the application module.

[0084] First, regarding the definition of the four-dimensional permission model: The password security module predefines four types of permission metadata, and all metadata must undergo integrity protection before being stored in the database. Specific permission dimensions include: User-User Group Association, used to define the user group to which a user belongs and its validity period; User Group-Network Element Group Authorization, used to define the operation permissions of a user group on a certain type of network element group, with permission bitmasks including READ (read-only), CONFIGURE (configuration), EXPORT (export), APPROVE (approval), and SENSITIVE_VIEW (sensitive data view); Network Element Group-Network Element Containment, used to define which network elements are specifically included under a network element group; and User-Network Element Direct Authorization, used to define exception authorization, overriding the permissions inherited by the user group. Among these, the SENSITIVE_VIEW permission bit directly controls the decryption visibility of sensitive fragments (such as IP host addresses, password values, and routing parameters) within the fields in step S104 of Example 1, as well as the strength selection of transmission encryption in step S103 of Example 1.

[0085] Secondly, regarding the integrity protection of permission metadata, when an administrator performs a permission change operation, the system executes the following process: The administrator must insert a USB-KEY to complete SM2 challenge-response authentication to ensure the operator's identity is authentic and trustworthy. The application module assembles the complete permission metadata to be changed into a standardized message and sends it to the cryptographic security module. The cryptographic security module uses a dedicated HMAC key for permission protection to calculate the HMAC-SM3 value of the message, and simultaneously requires the administrator to sign the message digest using the SM2 private key in the USB-KEY. The cryptographic security module returns the original permission metadata, HMAC value, and signature triplet to the application module, atomically writing it into the database permission table. In this embodiment, the HMAC value and signature value are the specific representations of the permission integrity verification information. Through the above dual protection mechanism, it is ensured that the permission metadata is not tampered with during storage and transmission, and that the operation is traceable.

[0086] Next, regarding the construction of the permission chain hash fingerprint, a permission chain is constructed for each user to achieve cross-dimensional association integrity protection. The specific process includes: concatenating all direct and indirect authorizations for the user in a standardized order; calculating the SM3 hash value as the permission fingerprint, which is then encrypted and cached in a high-speed cache by the cryptographic security module. Whenever any one-dimensional permission metadata changes, the permission fingerprint of the affected user is recalculated and the cache is updated. Each time a user logs in or performs a sensitive operation, the system recalculates the current fingerprint and compares it with the cache; if they do not match, the system refuses to load the permission and generates a high-risk alarm log. This mechanism can effectively detect implicit tampering with permission metadata. In this embodiment, the permission fingerprint is the aforementioned permission integrity verification information, used to drive the generation of subsequent encryption strategies and key expiration determination.

[0087] Next, regarding the cross-validation of permission validity and scope: Each time permissions are loaded or sensitive operations are executed, the application module calls the password security module to perform four types of verifications. First, a mandatory validity period verification strictly checks whether the current system time is within the interval formed by the effective and expiration times; if the permission has expired, loading is directly rejected. Second, a scope consistency verification ensures that the range of network elements authorized to a user group does not exceed the actual range of network elements contained in that group, preventing unauthorized authorization. Third, a permission conflict verification: when a user simultaneously possesses both direct and indirect authorization, if there is a conflict between the two permission bits, the direct authorization takes precedence, and the conflict is logged. Fourth, a permission chain integrity verification, combining the above permission chain hash fingerprint; if the comparison is inconsistent, loading permissions is immediately rejected, the user session is disconnected, and a high-risk alarm is triggered.

[0088] If all verifications fail, the system automatically follows steps S104 and S105 of Example 1 to perform subsequent processing operations: It notifies the password security module to revoke all active storage decryption sessions for the user, marks all transmission session keys for the user as invalid, and forces renegotiation. Simultaneously, it records in detail the reasons for verification failures, the current timestamp, and the relevant permission information, incorporating this information into regular security audits.

[0089] Finally, regarding the driving force of the permission model on the encryption strategy, the permission model defined in this embodiment directly drives steps S103 and S104 of embodiment 1. Before data is written or transmitted, the permission query interface is called to obtain the user's permission level. A lower permission level corresponds to high-security encryption parameters, and a higher permission level corresponds to moderate-security parameters. Before data is read or displayed, the permission verification interface is called to check the SENSITIVE_VIEW permission. For users without this permission, sensitive fields are always displayed as ciphertext or asterisks; for users with this permission, after secondary authentication, they can view the decrypted plaintext.

[0090] All permission change operations and verification results generate audit logs, which are encrypted, stored, and protected for integrity. This embodiment achieves fine-grained control through a four-dimensional permission model, ensures tamper-proof permission data through a triple protection mechanism of permission metadata, automatically handles permissions through cross-validation of timeliness and scope, and provides fine-grained control over the visibility of sensitive data decryption through the SENSITIVE_VIEW permission bit, forming a closed-loop linkage with field-level encryption strategies.

[0091] Example 6 This embodiment details the specific implementation process of the fragmented encryption and decryption linkage of sensitive fields in the bearer network management and control system, providing data processing details for the sensitive information protection method described in Embodiment 1. Figure 2 As shown, this embodiment is mainly executed by the application module and the cryptographic security module, and focuses on how to improve operation and maintenance efficiency while ensuring data security.

[0092] First, regarding the automatic identification and segmentation of sensitive fragments: The application module has built-in rules for identifying sensitive information within fields. It automatically segments specific network-specific field types, such as device IP addresses, configuration file key-value pairs, JSON configurations, and routing policies, into plaintext fragments and sensitive fragments. The specific segmentation process includes: the system identifies the field type; if it is an IP address, it segments it according to network and host bits; if it is a JSON configuration, it segments it according to the sensitivity of the key value. After segmentation, an ordered list of plaintext fragments and a list of sensitive fragments are generated. For example, the IP address "192.168.10.100" is segmented into the plaintext fragment "192.168." and the sensitive fragment "10.100". In this embodiment, the sensitive fragments and non-sensitive fragments correspond to the aforementioned sensitive data fragments and non-sensitive data fragments.

[0093] Secondly, regarding the dynamic selection of encryption strength based on the permission model, before sending sensitive fragments to the cryptographic security module for encryption, the application module calls the permission query interface to obtain the permission bitmask of the current writing user for the target network element. The encryption key strength is dynamically selected based on the permission level. In this embodiment, the policy configuration is as follows: when the user's permission level is READ only, a high security level is selected, and the key lifespan is set to 1 month; when the user's permission level is CONFIGURE, a medium security level is selected, and the key lifespan is set to 3 months; when the user's permission level is APPROVE or SENSITIVE_VIEW, a low security level is selected, and the key lifespan is set to 6 months.

[0094] The cryptographic security module retrieves the corresponding SM4 encryption key from the cryptographic resources based on the returned key strength level, encrypts each sensitive segment independently, generates ciphertext and a key index, and calculates the HMAC-SM3 value for the complete original string. The application module assembles the plaintext segment, ciphertext, key index, and HMAC value into a hybrid storage object and stores it in a database field, achieving physical coexistence of plaintext and ciphertext.

[0095] Next, regarding the decryption authorization verification based on the permission model, when a user reads a field, the system executes a three-step verification process. The first step is integrity verification: the application module concatenates the plaintext fragment with a ciphertext placeholder and sends it along with the HMAC value to the password security module for verification. If they do not match, it indicates that the data has been tampered with, and the system refuses to display it and generates a security alert. The second step is routine display: after the integrity verification passes, the system concatenates the plaintext fragment with the placeholder and displays it, making it visible to all users; the network segment can be identified without decryption. The third step is sensitive fragment decryption: when a user requires complete information, the system calls the permission verification interface to check the SENSITIVE_VIEW permission. If successful, the password security module decrypts the data based on the key index and returns the complete value; otherwise, the request is rejected and an audit log is recorded.

[0096] Next, regarding the temporary decryption application and approval mechanism: For users with only READ privileges, the system provides a temporary decryption application process. Users initiate a temporary decryption application, specifying the reason and the required duration, with a validity period preferably not exceeding 24 hours. This is approved by an administrator user with APPROVE privileges. Upon approval, the password security module generates a short-term temporary token, with a validity period preferably of 2 hours. Users can view sensitive fields in plaintext within the token's validity period. After the token expires or privileges are revoked, the temporary token automatically becomes invalid, and the user reverts to encrypted viewing mode.

[0097] Finally, regarding the automatic invalidation after permission changes: When the permission model changes, the system performs a series of actions: the password security module automatically clears the permission fingerprints and temporary tokens of the affected users, i.e., updates the permission integrity verification information; the application module is notified to revoke the relevant decryption sessions; subsequent decryption requests are rejected, ensuring that decryption capabilities under the old permissions are immediately terminated.

[0098] The beneficial effects of this embodiment are as follows: Fragmented encryption enables the physical coexistence of plaintext and ciphertext, balancing operational efficiency and data security. Encryption strength is dynamically bound to permission levels, ensuring high security with low permissions and high efficiency with high trust, achieving refined management. A temporary decryption mechanism meets operational needs in special scenarios, while risk is controlled through approval and tokens. A permission change-linked invalidation mechanism ensures real-time controllability of authorization, eliminating security time windows.

[0099] Example 7 This embodiment details the encryption process for critical data transmission based on a permission model in the bearer network management system, providing transmission security details for the sensitive information protection method described in Embodiment 1. For example... Figure 3 As shown, this embodiment is mainly executed collaboratively by the client, application module, and password security module, and focuses on how to achieve dynamic binding of encryption strength and permission level during data transmission.

[0100] First, regarding pre-transmission permission query and encryption strength selection: After the client establishes a connection with the business system and completes identity authentication, before transmitting important and sensitive data, the application module calls the permission query interface to obtain the current user's permission bitmask for the target network element. Transmission encryption parameters are dynamically selected based on the permission level. In this embodiment, the policy configuration is as follows: When the user's permission level is READ only, a high security level is selected, the session key length is 256 bits, the encryption algorithm is SM4-GCM, and the key lifespan is one session; when the user's permission level is CONFIGURE, a medium security level is selected, the session key length is 128 bits, the encryption algorithm is SM4-CBC, and the key lifespan is valid during the session; when the user's permission level is APPROVE or SENSITIVE_VIEW, a low security level is selected, the session key length is 128 bits, the encryption algorithm is SM4-CBC, and the key lifespan is a reusable short period.

[0101] The strength of encryption during transmission is inversely proportional to the level of access privileges. This is because lower-privilege users may have less trustworthy terminal environments, and their transmitted data may contain sensitive information, requiring stronger protection. This strategy is directly driven by the cryptographic security module and requires no manual configuration.

[0102] Secondly, regarding session key negotiation based on permission levels: The session key negotiation process includes: the client generates a temporary SM2 key pair and sends the temporary public key along with the user identifier to the business system; the business system calls the permission verification interface to confirm the user's permission level and the mapped encryption strength parameters; the business system forwards the temporary public key and parameters to the cryptographic security module; the cryptographic security module obtains the corresponding strength SM4 session key from the cryptographic resources according to the permission level, encrypts it using the temporary public key to generate ciphertext, and simultaneously generates a unique key index and associates it with the recorded session information; the cryptographic security module returns the encrypted session key and key index to the business system, which forwards it to the client; the client uses its private key to decrypt and obtain the session key, which is securely stored locally or in a USB-KEY hardware.

[0103] Next, regarding data transmission and integrity protection: The client organizes the data to be uploaded, encrypts the data using the session key, and generates ciphertext. Simultaneously, it calculates a data integrity check value using the HMAC-SM3 algorithm. The client packages the ciphertext, check value, and key index and sends it to the business system. The business system forwards it to the password security module, which retrieves the session key based on the key index, decrypts the ciphertext, and verifies its integrity. After all verifications pass, the original plaintext data is returned to the business system. When the user actively logs out or the session times out, the password security module immediately destroys the session key.

[0104] Next, regarding the impact of permission changes on transmission sessions, when the permission model changes, the password security module automatically performs the following actions: First, it marks the session key as invalid. Based on the user identifier involved in the permission change event, it searches the key index cache for all active transmission sessions of that user and marks them as invalid. Second, it notifies the business system. Through an internal messaging mechanism, it sends a session invalidation notification to the business system, forcing the affected client to re-verify permissions and re-negotiate the session key. Third, the changes take effect immediately. For any subsequent transmission decryption requests initiated by that user, the password security module, upon finding the session key invalidated, directly rejects the decryption and returns an error.

[0105] Finally, regarding the auditing of transmission encryption, standardized audit logs are generated for all transmission session establishment, key negotiation, permission level selection, and session failure events caused by permission changes. The logs record information such as the operator, target network element, permission level, session identifier, encryption strength, operation result, and timestamp, and are stored in the audit log database with HMAC-SM3 integrity protection.

[0106] The beneficial effects of this embodiment are as follows: Transmission encryption strength is dynamically bound to permission levels, ensuring high security with low permissions and high efficiency with high trust, enabling refined management. The session key negotiation process ensures secure key distribution, and hardware storage prevents key leakage. The permission change-linked invalidation mechanism ensures real-time controllability of authorization and eliminates the risk of data leakage in transit. Transmission audit logs fully record the entire session lifecycle, meeting compliance requirements.

[0107] Example 8 This embodiment uses the commercial cryptographic function transformation of a provincial power company's communication network management system (provincial OTN network management) as a practical case to fully demonstrate the specific implementation path of the technical solution of this invention in the power industry dispatch and control system. This embodiment is based on the technical solutions described in Embodiments 1 to 7 and is applied to a three-layer independent architecture: application layer, cryptographic service layer, and data layer. Specifically, the application module is deployed in the application layer, the cryptographic security module is deployed in the cryptographic service layer, and the hardware cryptographic resource pool and database are deployed in the data layer.

[0108] Regarding the system deployment architecture: The core network management system's full business modules are deployed on the application server, employing a dual-machine hot standby mode. This layer focuses on business logic processing and does not participate in cryptographic operations. All system end users are configured with a dedicated national cryptographic USB key, which contains the user's SM2 digital certificate and private key; the private key cannot be exported. The application layer communicates with the cryptographic security module via a RESTful API interface, which uses HTTPS protocol for encrypted transmission.

[0109] The cryptographic security module is deployed at the cryptographic service layer, with a built-in national cryptographic algorithm engine that fully supports SM2, SM3, and SM4 algorithms. The platform provides standardized cryptographic service interfaces upwards and connects uniformly to the hardware cryptographic resource pool downwards. The hardware cryptographic resource pool consists of two server cryptographic machines certified by the State Cryptography Administration, forming a dual-machine hot standby high-availability cluster. All key generation, storage, retrieval, and destruction operations throughout the entire lifecycle of the system are completed within the hardware cryptographic machines, ensuring that the plaintext of the keys never leaves the hardware.

[0110] The data layer comprises a business database and an audit log database. The business database uses field-level selective encryption to store data; sensitive business fields are stored in ciphertext, while non-sensitive fields are stored in plaintext. The audit log database specifically stores encrypted system operation audit logs; all logs are protected with SM3 hash integrity and are retained for one year.

[0111] Regarding the implementation of the identity authentication process: This embodiment adopts a strong identity authentication process based on SM2 digital signatures. The municipal bureau's operations and maintenance personnel initiate a login request through the client. The business system calls the password security module to generate a 128-bit high-strength random number as a challenge code, with a cache validity period set to 60 seconds. The client uses the SM2 private key stored in the USB-KEY to digitally sign the random number and uploads the signature value along with the user certificate.

[0112] The password security module verifies the validity of the certificate and the signature value. If the certificate is valid and the signature verification passes, the user is allowed to log in, a session identifier is assigned, and the session validity period is set to 2 hours. If the signature verification fails three times consecutively, the system locks the user account for 30 minutes and triggers a security alarm. If the user's certificate expires or is revoked, the system directly refuses login and prompts the user to update the certificate.

[0113] Regarding the implementation of access control information integrity protection: When system administrators perform permission adjustment operations, they must insert a USB-KEY to complete authentication. The application module sends the access control information to be stored to the password security module, which uses a dedicated HMAC key for permission protection to calculate an integrity check code. The business system binds the original access control information and the check code and stores them in the permission management database.

[0114] When the system subsequently reads permission information, it synchronously retrieves the verification value and sends it to the password security module for recalculation and comparison. If the comparison is inconsistent, it is determined that the information has been illegally tampered with, the user's permissions are refused, and an advanced security alarm is triggered. Simultaneously, the system uses the timeliness and scope cross-validation described in Example 5 to ensure the validity and scope of permissions are compliant.

[0115] Regarding the implementation of encryption for field-level data storage: Taking the storage of OTN device configuration information in a network management system as an example, the business system automatically filters out sensitive fields, such as device IP address, device login password, and configuration file content, through built-in sensitive field identification rules. Non-sensitive fields, such as device model and device operating status, are stored in plaintext.

[0116] The business system calls the permission query interface to obtain the permission bitmask of the current write user for the target network element. Based on the permission level, encryption parameters are selected. For example, for users with configuration permissions, a 128-bit SM4 algorithm is used, and the key lifespan is set to 3 months. The cryptographic security module calls the hardware cryptographic machine to perform SM4 encryption on each sensitive segment individually, and simultaneously calculates the HMAC-SM3 integrity check code for the entire group of sensitive fields.

[0117] The business system binds sensitive fields (ciphertext), plaintext non-sensitive fields, key indexes, and HMAC checksums, assembling them into a hybrid storage object, which is then uniformly stored in the business database. When maintenance personnel retrieve device information, non-sensitive fields can be directly displayed, while sensitive fields are displayed in a "plaintext fragment + ciphertext" format. To view complete sensitive information, SENSITIVE_VIEW privileges are required, and secondary authentication must be completed.

[0118] Regarding the encryption implementation of important data transmission: After the client and the business system complete identity authentication, the client initiates a device configuration data reporting operation, triggering the session key negotiation mechanism. The client generates a temporary SM2 key pair and sends the temporary public key to the cryptographic security module. The cryptographic security module generates an SM4 session key of corresponding strength according to the user's permission level. For example, for read-only users, a 256-bit SM4-GCM algorithm is used, and the session key lifespan is one session.

[0119] The password security module encrypts the session key using a temporary public key and returns it to the client. The client decrypts the session key using its private key and securely stores it inside the USB key. The client uses the session key to encrypt data, calculates the HMAC integrity check value, and packages it for transmission to the business system. The password service layer verifies the integrity and decrypts the data. When a user logs out or the session times out, the password security module immediately destroys the session key.

[0120] Regarding the implementation of end-to-end auditing and traceability: The password security module generates standardized audit logs for all password operations, covering authentication, data encryption, decryption, and key management. The logs include information such as operation time, user ID, operation type, result status, and request source IP. The audit logs are encrypted using the SM4 algorithm and supplemented with an HMAC-SM3 integrity checksum.

[0121] Authorized auditors, after undergoing strong identity verification, can query and verify audit logs. Log queries support multi-dimensional filtering, and query results can be exported as encrypted files. The audit logs are integrated with the power industry audit platform, synchronizing encrypted audit logs to the industry audit platform through a standardized interface to meet industry-specific compliance requirements.

[0122] This embodiment verifies the feasibility and practicality of the technical solution of this invention through a real-world case study in the power industry. The four-layer architecture deployment achieves complete decoupling of business logic and security, with an independently deployed hardware cryptographic resource pool ensuring that the plaintext key never leaves the hardware, fundamentally eliminating the risk of key leakage. Detailed parameter configurations provide a reference standard for similar system implementations, and a robust anomaly handling mechanism ensures the security and stability of the system under abnormal conditions.

[0123] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0124] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0125] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0126] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0127] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0129] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for protecting sensitive information in a bearer network management and control system, characterized in that, The method includes: Obtain the production data to be processed, and divide the production data into sensitive data segments and non-sensitive data segments based on field sensitivity rules; Obtain the permission metadata of the currently accessing user, perform integrity verification on the permission metadata, and generate permission integrity verification information; An encryption strategy is dynamically generated based on the permission integrity verification information, and the encryption strategy includes a key parameter corresponding to the security level of the permission metadata. According to the encryption strategy, the sensitive data segments are processed using a fragmented encryption method, while the non-sensitive data segments are retained as plaintext. When a change in the permission metadata is detected, resulting in a change in the permission integrity verification information, the key index is updated based on the changed permission integrity verification information, thereby invalidating the key generated based on the old permission integrity verification information.

2. The sensitive information protection method of the bearer network management and control system as described in claim 1, characterized in that, The division of the production data into sensitive and non-sensitive data segments based on field sensitivity rules includes: Read the metadata tags of the data field. If the metadata tags contain a preset sensitive identifier, the corresponding data field is divided into the sensitive data segment. Alternatively, use regular expressions to match the content features of the data field. If a preset sensitive information format is matched, the corresponding data field is divided into the sensitive data segment. The remaining data fields are divided into the non-sensitive data segments, which include device status fields, port number fields, or IP network segment fields used for troubleshooting maintenance faults.

3. The sensitive information protection method of the bearer network management and control system as described in claim 1, characterized in that, The process of performing integrity verification on permission metadata and generating permission integrity verification information includes: A hash value for the permission metadata is calculated using a hash algorithm, and / or a digital signature algorithm is used to sign the digest of the permission metadata; the hash value and / or signature value are used as the permission integrity verification information. The permission integrity verification information includes a permission fingerprint, which is a hash value calculated by concatenating all direct and indirect authorizations based on the permission metadata in a standardized order.

4. The sensitive information protection method of the bearer network management and control system as described in claim 1, characterized in that, The step of dynamically generating an encryption strategy based on the permission integrity verification information includes: Establish a mapping table between permission levels and encryption parameters; when the permission level indicated by the permission metadata is a low permission level, select a key of a first length or an encryption algorithm of a first security mode; when the permission level indicated by the permission metadata is a high permission level, select a key of a second length or an encryption algorithm of a second security mode. Wherein, the key length of the first length is greater than the key length of the second length, or the security level of the first security mode is higher than that of the second security mode.

5. The sensitive information protection method of the bearer network management and control system as described in claim 1, characterized in that, The process of processing the sensitive data fragments using a fragmented encryption method includes: If the permission metadata includes sensitive viewing permissions, a decryption key is generated to display the plaintext of the sensitive data fragment; if the permission metadata does not include sensitive viewing permissions, only the ciphertext or de-identified characters of the sensitive data fragment are displayed. The sensitive viewing permission is configured independently of the read and write permissions and is used to control the decryption visibility of sensitive segments within a field.

6. The sensitive information protection method of the bearer network management and control system as described in claim 1, characterized in that, The step of invalidating the key generated based on the old permission integrity verification information includes: A version number is generated for the encryption policy, and the version number is bound to the permission integrity verification information; when the permission metadata changes, the version number is updated and the key index corresponding to the old version number is invalidated; when a decryption request is received, the version number carried in the request is verified, and if the version number is inconsistent with the current latest policy version number, decryption is rejected.

7. The sensitive information protection method of the bearer network management and control system as described in any one of claims 1 to 6, characterized in that, The sensitive data fragments include sensitive portions of structured data; The retention of the non-sensitive data fragments as plaintext includes: For sensitive data fields with a predetermined structure format, non-sensitive and sensitive components are identified according to their structure definition; the non-sensitive components are used to quickly locate or identify the business context and are retained as plaintext; the sensitive components contain business secret information and are encrypted. The predetermined structure format includes, but is not limited to: network and host bits of an IP address, OUI and serial number of a MAC address, key and value in a configuration file key-value pair, or specific tag content in JSON / XML structured data.

8. The method for protecting sensitive information in a bearer network management and control system as described in any one of claims 1 to 6, characterized in that, The method further includes: Record audit logs for all encryption, decryption, and permission change operations; protect the integrity of the audit logs by calculating and storing checksums using a hash algorithm; generate a security alarm when a checksum mismatch is detected in the audit logs.

9. A sensitive information protection system for a bearer network management and control system, characterized in that, The system includes an application module and a cryptographic security module; The application module is used to acquire production data to be processed and divide the production data into sensitive data segments and non-sensitive data segments based on field sensitivity rules; it is also used to acquire the permission metadata of the currently accessing user and send an encrypted request carrying the permission metadata to the password security module. The password security module is used to perform integrity verification on the permission metadata and generate permission integrity verification information. It is also used to dynamically generate an encryption strategy based on the permission integrity verification information, wherein the encryption strategy includes a key parameter corresponding to the security level of the permission metadata; In accordance with the encryption strategy, the sensitive data segments are processed using a fragmented encryption method, while the non-sensitive data segments are preserved as plaintext. And when a change in the permission metadata is detected, resulting in a change in the permission integrity verification information, the key index is updated based on the changed permission integrity verification information, thereby invalidating the key generated based on the old permission integrity verification information.

10. The sensitive information protection system of the bearer network management and control system as described in claim 9, characterized in that, The application module is specifically used for: Read the metadata tags of the data field. If the metadata tags contain preset sensitive identifiers, they are classified into the sensitive data segment; or, use regular expressions to match the content features of the data field. If a preset sensitive information format is matched, it is classified into the sensitive data segment. The remaining data fields are grouped into the non-sensitive data segment, which includes device status fields, port number fields, or IP network segment fields used for troubleshooting maintenance faults. The cryptographic security module is specifically used to: calculate the hash value of the permission metadata using a hash algorithm, and / or sign the digest of the permission metadata using a digital signature algorithm; and use the hash value and / or signature value as the permission integrity verification information. Generate a version number for the encryption strategy and bind the version number to the permission integrity verification information; When the permission metadata changes, update the version number and invalidate the key index corresponding to the old version number.

Images