A multi-domain security interaction method and system for a regional low-carbon service center

Abstract

The present application relates to the field of computer data processing, and particularly relates to a regional low-carbon service center multi-domain security interaction method and system. The method comprises the following steps: obtaining multi-domain interaction source data, forming a multi-domain interaction request image through source domain, terminal type and business module identification; performing data classification, sensitive field identification and access subject permission matching to obtain data security level, field processing strategy and access control result; then performing inter-domain isolation relationship matching and cross-domain mapping to generate cross-domain interaction path and security mapping strategy, and completing interface packaging, field desensitization, encryption processing and integrity digest generation to obtain cross-domain security interaction data packet; subsequently performing request routing, micro-service running state matching, target service instance selection, digest verification, permission review and audit monitoring linkage to generate interaction strategy update result. The present application effectively improves the interaction security of the regional low-carbon service center in the multi-domain environment and the consistency of the data link.

Description

Technical Field

[0001] This invention relates to the field of computer data processing, and in particular to a multi-domain secure interaction method and system for a regional low-carbon service center. Background Technology

[0002] In the field of computer data processing, existing solutions for regional low-carbon service centers typically revolve around multi-domain interactive source data access, business module call request forwarding, unified permission data verification, data platform interface calls, and microservice runtime status monitoring. These solutions support business access processes through source domain identification, terminal type identification, and business module identification. When handling cross-domain interactions, these solutions often disperse multi-domain interaction request profiling, data security levels, field processing strategies, and access control results across different processing stages. This results in limitations such as insufficient correlation between cross-domain interaction paths and security mapping strategies, separation of field anonymization and interface encapsulation, and a lack of a unified carrier object for encryption processing and integrity digest generation. Existing methods largely rely on access subject permission matching before interface calls and audit records after interface calls, which can easily lead to discontinuities in the connection between request routing, target service instance selection, returned data verification, and audit records.

[0003] In scenarios where the management information zone, internet zone, IoT access zone, mobile access zone, data platform zone, unified permission zone, and microservice operation zone of a regional low-carbon service center all interact, there are differences in source domain, target domain, terminal type, and business module among internal network customer files, internal network energy meter data, external network IoT device data collection, personal computer access requests, mobile terminal access requests, and business module call requests. Existing solutions are prone to problems during cross-domain access, such as unclear boundaries of allowed interaction field sets, delayed processing of sensitive customer information, insufficient binding of important enterprise data with cross-domain interaction paths, and lack of correspondence between digest verification and permission review. These issues make it difficult to meet the requirements for continuous processing of cross-domain secure interaction data packets, cross-domain service call results, and secure interaction results.

[0004] For the joint processing of cross-domain interaction paths, security mapping policies, cross-domain secure interaction data packets, and audit logs, existing technologies generally handle interface encapsulation, field anonymization, encryption, integrity digest generation, request routing, microservice runtime status matching, target service instance selection, and interaction policy updates in a fragmented manner, lacking a consistent process from multi-domain interaction request profiling to interaction policy update results. In this scenario, abnormal events, response times, service call status, encrypted digest information, and audit log rules are difficult to continuously transmit within the same interaction chain, leading to instability in the correspondence between interface identifiers, data security levels, field processing policy identifiers, and audit identifiers during cross-domain interaction. Summary of the Invention

[0005] To address the above problems, this invention provides a multi-domain security interaction method for regional low-carbon service centers, comprising:

[0006] S100: Obtain multi-domain interaction source data from the regional low-carbon service center, perform source domain identification, terminal type identification, and business module identification processing to obtain a multi-domain interaction request profile;

[0007] S200. Based on the multi-domain interaction request profile, perform data classification, sensitive field identification, and access subject permission matching to obtain data security level, field processing strategy, and access control results.

[0008] S300. Based on the data security level, field processing strategy and access control results, perform inter-domain isolation relationship matching and cross-domain mapping processing to obtain cross-domain interaction path and security mapping strategy;

[0009] S400. Based on the cross-domain interaction path and security mapping strategy, perform interface encapsulation, field desensitization, encryption processing and integrity digest generation processing to obtain a cross-domain secure interaction data packet;

[0010] S500: Based on the cross-domain secure interaction data packet, perform request routing, microservice running status matching and target service instance selection processing to obtain the cross-domain service call result;

[0011] S600. Based on the cross-domain service call result, perform summary verification, permission review, field restoration, and result desensitization to obtain a secure interaction result;

[0012] S700. Based on the security interaction result, perform audit recording and monitoring linkage processing to obtain the interaction policy update result.

[0013] Furthermore, the multi-domain interactive source data includes intranet customer profiles, intranet electricity meter data, extranet IoT device collection data, PC access requests, mobile access requests, unified permission data, business module call requests, and microservice running status data; the source domains include management information region, internet region, IoT access domain, mobile access domain, data platform domain, unified permission domain, and microservice running domain.

[0014] Furthermore, the multi-domain interaction request profile includes source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data object identifier, request action, unified permission result, service link identifier, isolation mapping status, and request time; the multi-domain interaction request profile is obtained by associating PC-side access requests, mobile-side access requests, unified permission data, data platform interface records, API gateway records, service gateway records, isolation device mapping records, and microservice running status data.

[0015] Furthermore, the data security level includes password data, business application configuration data, important enterprise data, sensitive customer information, and general data; the sensitive fields identified include system ledgers, maintenance personnel ID numbers, contact person names, mailing addresses, contact numbers, and email addresses; the field processing strategies include prohibiting field transmission, field cropping, field anonymization, field encryption, returning statistical results, and returning the original field.

[0016] Furthermore, if the data security level is password data or business application configuration data, the access control result is to prohibit cross-domain transmission; if the data security level is important enterprise data, the access control result is to access the isolated device mapping channel, encrypt the data, and generate an integrity digest; if the data security level is sensitive customer information, the access control result is to anonymize the results or return statistical results; if the data security level is general data, the access control result is to call a unified API interface and record audit logs.

[0017] Furthermore, the cross-domain interaction path includes the same-domain API gateway call path, the isolation device mapping path from the Internet region to the management information region, the API gateway path from the mobile access domain to the Internet region, the IoT platform path from the IoT access domain to the data acquisition module, and the unified API interface path from the data middle platform to the business module; the security mapping strategy includes the mapping relationship from the source domain to the target domain, the mapping interface identifier, the set of allowed interaction fields, the field processing strategy identifier, the encryption processing method, the digest verification method, the return result type, and the audit record rules.

[0018] Furthermore, the cross-domain secure interaction data packet includes a request identifier, a source domain identifier, a target domain identifier, an access subject identifier, a terminal type, a business module identifier, an interface identifier, a data security level, a field processing policy identifier, a set of allowed interaction fields, a set of encrypted fields, a digest value, a timestamp, a service link identifier, and an audit identifier; the encryption processing is performed using the SM4 algorithm; and the integrity digest generation is performed using the SM3 algorithm digest processing.

[0019] Furthermore, the microservice runtime status data includes service health status, which includes service instance availability, interface response time, interface error rate, and abnormal event status; the target service instance selection process includes matching the data security level, cross-domain interaction path, security mapping strategy, and service health status to obtain the target service instance.

[0020] Furthermore, the audit record and monitoring linkage processing includes recording interaction request profiles, cross-domain interaction paths, security mapping policies, encrypted digest information, service call status, abnormal events, and response times to generate cross-domain interaction audit data. Based on the cross-domain interaction audit data and microservice runtime status data, abnormal interaction identification, interface risk assessment, and service status linkage adjustment are performed to obtain interaction policy update results. The interaction policy update results include field processing policy adjustment results, security mapping policy adjustment results, service instance routing weight adjustment results, interface blocking results, result anonymization adjustment results, and audit record rule adjustment results.

[0021] Furthermore, a multi-domain security interaction system for a regional low-carbon service center includes: a request profiling module, a security classification module, a cross-domain mapping module, a data packet encapsulation module, a routing invocation module, a result verification module, and an audit update module; the system is used to execute the method described in any one of the above embodiments.

[0022] The key innovations of this invention include:

[0023] (1) Integrate the multi-domain interaction request profile, data security level, field processing strategy, cross-domain interaction path and security mapping strategy into the interface encapsulation, field desensitization, encryption processing and integrity summary generation processing, so that the cross-domain interaction path, security mapping strategy and field processing strategy form the same processing object in the cross-domain security interaction data packet.

[0024] (2) Based on cross-domain secure interaction data packets, request routing, microservice running status matching and target service instance selection are performed, so that data security level, field processing strategy identifier, cross-domain interaction path and security mapping strategy participate in the generation process of cross-domain service call results.

[0025] (3) Based on the results of secure interaction, audit records and monitoring are linked, and summary verification, permission review, field restoration, result desensitization, service call status, abnormal events and response time are incorporated into the generation process of interaction policy update results.

[0026] The following are its main beneficial effects:

[0027] (1) To address the problem of insufficient association between cross-domain interaction paths and security mapping strategies in existing technologies, cross-domain security interaction data packets carry request identifiers, source domain identifiers, target domain identifiers, interface identifiers, data security levels, field processing strategy identifiers, allowed interaction field sets, encrypted field sets, digest values, and audit identifiers, thereby ensuring that the paths, fields, encryption, digests, and audit records in the cross-domain access process maintain a corresponding relationship.

[0028] (2) In view of the problem of field desensitization and interface encapsulation in the existing technology, by performing field desensitization, encryption and integrity summary generation simultaneously during the interface encapsulation process, sensitive customer information, important enterprise data and general data can complete field boundary processing before entering the cross-domain service call result.

[0029] (3) To address the problem of discontinuous connection between request routing and microservice running status matching in the existing technology, request routing, microservice running status matching and target service instance selection are driven by cross-domain secure interaction data packets, so that the target service instance selection process simultaneously references data security level, cross-domain interaction path and security mapping strategy.

[0030] (4) To address the problem of insufficient correspondence between digest verification and permission review in the existing technology, digest verification, permission review, field restoration and result desensitization are performed based on the cross-domain service call results, so that the returned data, access subject, field processing strategy and security interaction results are completed in the same review link.

[0031] (5) To address the problem of scattered audit records and interaction policy update results in the existing technology, the audit records and monitoring are linked by security interaction results, so that the interaction policy update results are associated with field processing strategies, security mapping strategies, target service instance selection, result desensitization and audit record rules. Attached Figure Description

[0032] Figure 1 A flowchart illustrating a multi-domain security interaction method for a regional low-carbon service center provided in this application embodiment;

[0033] Figure 2 This is a structural block diagram of a multi-domain security interaction system for a regional low-carbon service center, provided as an embodiment of this application. Detailed Implementation

[0034] Example 1: Refer to Figure 1 This is a flowchart illustrating a multi-domain security interaction method for a regional low-carbon service center provided by an embodiment of the present invention. The process may include at least steps S100-S700:

[0035] S100: Obtain multi-domain interaction source data from the regional low-carbon service center, perform source domain identification, terminal type identification, and business module identification processing to obtain a multi-domain interaction request profile;

[0036] S200. Based on the multi-domain interaction request profile, perform data classification, sensitive field identification, and access subject permission matching to obtain data security level, field processing strategy, and access control results.

[0037] S300. Based on the data security level, field processing strategy and access control results, perform inter-domain isolation relationship matching and cross-domain mapping processing to obtain cross-domain interaction path and security mapping strategy;

[0038] S400. Based on the cross-domain interaction path and security mapping strategy, perform interface encapsulation, field desensitization, encryption processing and integrity digest generation processing to obtain a cross-domain secure interaction data packet;

[0039] S500: Based on the cross-domain secure interaction data packet, perform request routing, microservice running status matching and target service instance selection processing to obtain the cross-domain service call result;

[0040] S600. Based on the cross-domain service call result, perform summary verification, permission review, field restoration, and result desensitization to obtain a secure interaction result;

[0041] S700. Based on the security interaction result, perform audit recording and monitoring linkage processing to obtain the interaction policy update result.

[0042] S100: Obtain multi-domain interaction source data from the regional low-carbon service center, perform source domain identification, terminal type identification, and business module identification processing to obtain a multi-domain interaction request profile;

[0043] In this step, the request profiling module accesses the front-end, middle-end, and back-end layers of the regional low-carbon service center to obtain multi-domain interactive source data. This multi-domain interactive source data includes intranet customer profiles, intranet electricity meter data, data collected by external IoT devices, access requests from personal computers (PCs), mobile devices, unified permission data, business module call requests, and microservice runtime status data. The request profiling module consists of an access unit, a source domain identification unit, a terminal type identification unit, a business module identification unit, a profiling association unit, and a recording unit. The access unit connects to the PC, mobile device, IoT platform, data middle-end, unified permission domain, Application Programming Interface Gateway (API Gateway), service gateway, isolation device mapping channel, and microservice runtime domain, respectively. Multi-domain interactive source data acquisition and processing are triggered when a business access request enters the regional low-carbon service center, IoT devices send collected data, the data middle-end interface is called, unified permission data undergoes verification feedback, or microservice runtime status data is updated.

[0044] Specifically, the access unit first organizes the access format of the multi-domain interaction source data. This organization includes writing request time, request action, access subject identifier, and interface identifier for PC access requests, mobile access requests, and business module call requests; writing data object identifier and data source record for intranet customer files, intranet energy meter data, and extranet IoT device collected data; writing unified permission results for unified permission data; and writing service link identifier and service operation record for microservice running status data. The request time is the time record of the request entering the regional low-carbon service center, and the request action includes querying, calling, uploading, returning, and recording. The access subject identifier is the identity record corresponding to the access subject in the unified permission data; the interface identifier is the interface record corresponding to the request entry point in the API gateway, service gateway, or data platform interface record; and the data object identifier is the data object record of intranet customer files, intranet energy meter data, and extranet IoT device collected data in the data platform or IoT platform.

[0045] Furthermore, the source domain identification unit performs source domain identification processing on the multi-domain interactive source data that has completed the access format processing. The source domains include the management information zone, the internet zone, the IoT access zone, the mobile access zone, the data platform zone, the unified permission zone, and the microservice runtime zone. The source domain identification processing matches the data entry location, interface call location, data storage location, and service runtime location. When internal network customer files and internal network electricity meter data have management information zone storage records in the data platform interface records, the source domain identifier corresponding to the management information zone is written. When external network IoT device data enters through the IoT platform, the source domain identifier corresponding to the IoT access zone is written. When a mobile terminal access request enters through a mobile application entry point, the source domain identifier corresponding to the mobile access zone is written. When a PC terminal access request enters through the front-end layer, the source domain identifier corresponding to the internet zone is written. When unified permission data comes from the unified permission zone, the source domain identifier corresponding to the unified permission zone is written. When microservice runtime status data comes from the microservice runtime zone, the source domain identifier corresponding to the microservice runtime zone is written. If the same request is associated with both the data platform interface record and the isolation device mapping record, the source domain identification unit will simultaneously write the source domain identifier and the target domain identifier, and record the isolation mapping status as associated, not associated, or abnormally associated.

[0046] Furthermore, the terminal type identification unit performs terminal type identification processing on PC access requests, mobile access requests, and data collected from external IoT devices. The terminal type includes PC, mobile, and IoT device. The terminal type identification processing reads the terminal field from the request entry point, device identifier, access channel, and business module call request. When the request entry point is from a PC page, the terminal type is written as PC. When the request entry point is from a mobile application, the terminal type is written as mobile. When data is sent via the IoT platform and carries a device identifier, the terminal type is written as IoT device. If the terminal field is missing, the terminal type identification unit retrieves API gateway records, service gateway records, and IoT platform access records for supplementary matching; if the supplementary matching still fails to form a terminal type, the recording unit generates an exception event and writes the terminal type to a pending review status, without outputting a complete profile to the subsequent profile association unit.

[0047] Furthermore, the business module identification unit performs business module identification processing on business module call requests. The business modules include integrated dashboards, operations management, production management, operation monitoring, performance evaluation, analysis reports, basic support, data collection, and mobile applications. The business module identification processing reads the interface identifier, page entry point, service link identifier, and data object identifier. When the interface identifier is associated with a dashboard page, the business module identifier is written to the integrated dashboard. When the interface identifier is associated with customer management, site management, equipment management, or opportunity management, the business module identifier is written to operations management. When the interface identifier is associated with maintenance teams, work order centers, or alarm centers, the business module identifier is written to production management. When the interface identifier is associated with video surveillance or online equipment monitoring, the business module identifier is written to operation monitoring. When the interface identifier is associated with performance management or examination management, the business module identifier is written to performance evaluation. When the interface identifier is associated with operations analysis or statistical analysis, the business module identifier is written to analysis reports. When the interface identifier is associated with user permission management, to-do items, or message centers, the business module identifier is written to basic support. When the interface identifier is associated with monitoring, alarms, or video information collection, the business module identifier is written to data collection. When the interface identifier originates from the mobile application entry point, the business module identifier is written into the mobile application.

[0048] Understandably, the profile association unit associates the source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data object identifier, request action, unified permission result, service link identifier, isolation mapping status, and request time to form a multi-domain interaction request profile. The source domain identifier indicates the location where the request or data enters the regional low-carbon service center; the target domain identifier indicates the location where the requested data or service is located; the access subject identifier indicates the access subject record in the unified permission data; the business module identifier indicates the business module to which the request belongs; the service link identifier indicates the service call link record in the microservice runtime domain; and the isolation mapping status indicates the association status formed between the management information region and the internet region through the isolation device mapping channel. The multi-domain interaction request profile is written to the profile database when all fields are complete and is simultaneously output to the "multi-domain interaction request profile" in S200. When there is a missing field, source domain conflict, terminal type conflict, business module identifier conflict, or abnormal isolation mapping status, the recording unit generates an abnormal event, retains the original multi-domain interaction source data, abnormal fields, and request time, and writes the abnormal event into the microservice running status data for reference in subsequent audit records and monitoring linkage processing.

[0049] In one engineering implementation, the operation and maintenance service provider accesses the online monitoring page of the device in the operation monitoring via a mobile terminal, requesting to view the intranet energy meter data and the external IoT device data collected at a certain site. The access unit receives the mobile terminal access request, unified permission data, data platform interface records, API gateway records, service gateway records, and microservice operation status data. The source domain identification unit writes the mobile terminal access request into the source domain identifier corresponding to the mobile access domain, writes the intranet energy meter data into the target domain identifier corresponding to the management information region, and writes the external IoT device data collected into the data source record corresponding to the IoT access domain. The terminal type identification unit identifies the request entry as a mobile terminal. The business module identification unit writes the business module identifier into the operation monitoring based on the interface identifier corresponding to the device online monitoring. The profile association unit merges the access subject identifier, terminal type, business module identifier, interface identifier, data object identifier, unified permission result, service link identifier, and isolation mapping status into a multi-domain interaction request profile, and passes the multi-domain interaction request profile to S200 for data classification, sensitive field identification, and access subject permission matching processing.

[0050] In summary, this step integrates interaction records scattered across PCs, mobile devices, IoT platforms, data middleware, unified permission domains, API gateways, service gateways, isolation device mapping channels, and microservice runtime domains into a multi-domain interaction request profile. This profile associates the source domain, terminal type, and business module before business processing, forming a unified input for subsequent data classification, sensitive field identification, and access subject permission matching. This step establishes a preliminary identification foundation for secure interactions between the management information zone, internet zone, IoT access domain, mobile access domain, data middleware domain, unified permission domain, and microservice runtime domain.

[0051] S200. Based on the multi-domain interaction request profile, perform data classification, sensitive field identification, and access subject permission matching to obtain data security level, field processing strategy, and access control results.

[0052] In this step, the security classification module receives the multi-domain interaction request profile output by S100 and uses it as the input source for this step. The security classification module consists of a data classification unit, a sensitive field identification unit, an access subject permission matching unit, a field processing strategy generation unit, and an access control result generation unit. The multi-domain interaction request profile includes source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data object identifier, request action, unified permission result, service link identifier, isolation mapping status, and request time. The data classification unit reads the data object identifier, source domain identifier, target domain identifier, and business module identifier to perform data classification processing; the sensitive field identification unit reads the data object identifier and interface identifier to perform sensitive field identification processing; and the access subject permission matching unit reads the access subject identifier, business module identifier, interface identifier, and unified permission result to perform access subject permission matching processing.

[0053] Specifically, the data classification and processing are performed according to the data source, data content, and storage location corresponding to the data object identifier. The data security levels include password data, business application configuration data, important enterprise data, sensitive customer information, and general data. Password data refers to data records corresponding to user passwords within a unified access control domain. Business application configuration data consists of database passwords and business application configuration records. Important enterprise data includes data records corresponding to system ledgers and maintenance personnel's ID numbers. Sensitive customer information includes data records corresponding to contact person names, mailing addresses, phone numbers, and email addresses. General data refers to ordinary business data. When the source domain is identified as a unified permission domain and the data object identifier corresponds to user password data, the data classification unit writes the data security level into the password data; when the data object identifier corresponds to a database password or business application configuration record, it writes the data security level into the business application configuration data; when the source domain is identified as a management information region or data platform domain and the data object identifier corresponds to a system ledger or maintenance personnel ID number, it writes the data security level into important enterprise data; when the data object identifier corresponds to a contact person's name, mailing address, contact number, or email address, it writes the data security level into sensitive customer information; and when none of the above classifications match and the data object identifier corresponds to ordinary business data, it writes the data security level into general data.

[0054] Furthermore, the sensitive field identification process is triggered after the data classification process is completed. The sensitive field identification unit extracts the system ledger, maintenance personnel ID number, contact person name, mailing address, contact number, and email address from the data fields corresponding to the data object identifier, and writes the extraction results into the sensitive field record. The system ledger refers to the ledger fields associated with sites, equipment, and operation records in the regional low-carbon service center. The maintenance personnel ID number is a field associated with the maintenance personnel identity record in production management, operation monitoring, or mobile applications. The contact person name, mailing address, contact number, and email address are fields associated with sensitive customer information in intranet customer files or business module call requests. If the aforementioned fields do not exist in the fields corresponding to the data object identifier, the sensitive field identification unit writes a record with no sensitive fields. If the data object identifier is missing or the field name does not match the interface identifier, the sensitive field identification unit generates an abnormal event and writes the abnormal field, interface identifier, and request time into the microservice running status data.

[0055] Furthermore, the access subject permission matching process is executed by the access subject permission matching unit. This unit associates the access subject identifier, business module identifier, interface identifier, request action, and unified permission result. The access subject identifier is the identity record in the unified permission data corresponding to the user, IoT device, or microservice caller. The unified permission result is the result record formed after the unified permission domain verifies the access subject identifier, business module identifier, and interface identifier. The request action includes querying, calling, uploading, returning, and recording. When the unified permission result matches the business module identifier, interface identifier, and request action, the access subject permission matching unit writes a permission matching record; when the unified permission result is missing, the interface identifier exceeds the range corresponding to the business module identifier, or the request action is inconsistent with the unified permission result, it writes a permission mismatch record and simultaneously generates an exception event.

[0056] Understandably, the field processing strategy generation unit generates field processing strategies based on data security level, sensitive field records, and permission matching records. The field processing strategies include prohibiting field transmission, field pruning, field anonymization, field encryption, returning statistical results, and returning the original field. If the data security level is password data or business application configuration data, the field processing strategy is to prohibit field transmission. If the data security level is important enterprise data, and the sensitive field record contains system ledgers or maintenance personnel ID numbers, the field processing strategy is to prune and encrypt fields. If the data security level is sensitive customer information, and the sensitive field record contains contact person names, mailing addresses, contact phone numbers, or email addresses, the field processing strategy is to anonymize fields or return statistical results. If the data security level is general data, and the permission matching record shows permission matching, the field processing strategy is to return the original field. If the permission matching record shows permission mismatch, the field processing strategy is to prohibit field transmission.

[0057] Furthermore, the access control result generation unit generates access control results based on data security level, field processing strategy, and permission matching records. If the data security level is password data or business application configuration data, the access control result is written as prohibiting cross-domain transmission. If the data security level is important enterprise data, the access control result is written as access through the isolation device mapping channel, encryption processing, and integrity digest generation. If the data security level is sensitive customer information, the access control result is written as result anonymization or statistical result return. If the data security level is general data, the access control result is written as the unified application programming interface (API) interface call and audit record. If the permission matching record shows a permission mismatch, the access control result is written as the interface blocking record, and the access subject identifier, business module identifier, interface identifier, request action, and request time are written as the abnormal event status.

[0058] In one engineering embodiment, the mobile access request originates from the mobile access domain, the business module is identified as "operation monitoring," and the data object identifier is associated with both intranet electricity meter data and external IoT device data. After receiving the multi-domain interaction request profile generated by S100, the security classification module writes the data security level corresponding to the intranet electricity meter data into general data, and the data security level corresponding to the external IoT device data into general data. If the same request is associated with a system ledger, the data classification unit writes the data security level corresponding to the system ledger into important enterprise data. The sensitive field identification unit checks the fields corresponding to the data object identifier; if it finds the contact person's name and phone number, it writes the sensitive field record corresponding to the customer's sensitive information. The access subject permission matching unit reads the unified permission result, confirms that the access subject identifier matches the interface identifier corresponding to "operation monitoring," and writes the permission matching record. The field processing strategy generation unit trims and encrypts the fields written to the system ledger, desensitizes the fields for the contact person's name and phone number, and returns the original fields for general data. The access control result generation unit writes the system ledger corresponding results into the isolation device mapping channel access, encryption processing and integrity summary generation, writes the customer sensitive information corresponding results into the result desensitization, and writes the general data corresponding results into the unified API interface call and audit record.

[0059] The data security level, field processing policy, and access control results output in this step are written into the security classification record by the security classification module and passed to S300. The data security level participates in inter-domain isolation relationship matching in S300, the field processing policy participates in cross-domain mapping processing in S300, and the access control results participate in the generation of cross-domain interaction paths and security mapping policies in S300. If an abnormal event occurs in this step, the abnormal event is synchronously written into the microservice runtime status data and used as input for audit records and monitoring linkage processing in S700.

[0060] In summary, this step converts the multi-domain interaction request profile generated by S100 into data security level, field processing strategy, and access control result. The data security level, field processing strategy, and access control result are bound before cross-domain mapping, ensuring clear data boundaries for subsequent inter-domain isolation relationship matching. The access subject permission matching process associates the unified permission result with the business module identifier, interface identifier, and request action, forming a secure input for generating subsequent cross-domain interaction paths.

[0061] S300. Based on the data security level, field processing strategy and access control results, perform inter-domain isolation relationship matching and cross-domain mapping processing to obtain cross-domain interaction path and security mapping strategy;

[0062] In this step, the cross-domain mapping module receives the data security level, field processing policy, and access control result output by S200, and uses these as the input source for this step. The cross-domain mapping module consists of an inter-domain isolation relationship matching unit, a cross-domain path generation unit, a security mapping policy generation unit, a mapping interface verification unit, and an exception recording unit. The inter-domain isolation relationship matching unit reads the data security level, source domain identifier, target domain identifier, and isolation mapping status to determine whether the request involves cross-domain access between management information zones, internet zones, IoT access zones, mobile access zones, data platform zones, unified permission zones, and microservice runtime zones. The cross-domain path generation unit reads the access control result and interface identifier to generate a cross-domain interaction path. The security mapping policy generation unit reads the field processing policy and cross-domain interaction path to generate a security mapping policy. The mapping interface verification unit reads the isolation device mapping record, application programming interface (API) gateway record, service gateway record, and data platform interface record to verify the mapping interface identifier in the cross-domain interaction path.

[0063] Specifically, the inter-domain isolation relationship is the access boundary record between the source domain identifier and the target domain identifier. The access boundary record includes same-domain access records, isolation records from the management information region to the internet region, isolation records from the internet region to the management information region, access records from the mobile access domain to the internet region, access records from the IoT access domain to the data acquisition module, access records from the data platform domain to the business module, and verification records from the unified permission domain to the business module. The inter-domain isolation relationship matching unit writes the same-domain access record when the source domain identifier and the target domain identifier are the same; when the source domain identifier is the internet region or mobile access domain and the target domain identifier is the management information region, it reads the isolation mapping status and isolation device mapping record; when the source domain identifier is the IoT access domain and the target domain identifier is the data acquisition module, it reads the IoT platform path record; when the target domain identifier is the data platform domain and the business module identifier comes from the integrated dashboard, operation management, production management, operation monitoring, performance evaluation, analysis reports, basic support, data acquisition, or mobile application, it reads the unified API interface record from the data platform to the business module.

[0064] Further, the cross-domain path generation unit generates cross-domain interaction paths based on access control results. These cross-domain interaction paths include same-domain API gateway call paths, isolation device mapping paths from the Internet region to the management information region, API gateway paths from the mobile access domain to the Internet region, IoT platform paths from the IoT access domain to the data acquisition module, and unified API interface paths from the data platform to the business module. If the access control result prohibits cross-domain transmission, the cross-domain path generation unit does not generate cross-domain interaction paths, and the exception recording unit writes them into the interface blocking record. If the access control result includes isolation device mapping channel access, encryption processing, and integrity digest generation, the cross-domain path generation unit writes the isolation device mapping path from the Internet region to the management information region into the path record. If the access control result is result anonymization or statistical result return, the cross-domain path generation unit writes the unified API interface path from the data platform to the business module into the path record and marks the return result type. If the access control result is unified API interface call and audit record, the cross-domain path generation unit writes either the same-domain API gateway call path or the unified API interface path from the data platform to the business module into the path record.

[0065] Further, the security mapping policy generation unit generates a security mapping policy based on the field processing policy. The security mapping policy includes a mapping relationship from the source domain to the target domain, a mapping interface identifier, a set of allowed interactive fields, a field processing policy identifier, an encryption method, a digest verification method, a return result type, and audit record rules. The mapping relationship is formed by the source domain identifier and the target domain identifier. The mapping interface identifier is formed by API gateway records, service gateway records, isolation device mapping records, or data platform interface records. The set of allowed interactive fields is jointly defined by field trimming, field anonymization, statistical result return, and original field return in the field processing policy. The field processing policy identifier corresponds to the field processing policy output by S200. The encryption method is written when the field processing policy is for field encryption. The digest verification method is written when the access control result includes an integrity digest generation. The return result type is written based on result anonymization, statistical result return, or original field return. The audit record rules are written based on the data security level, interface identifier, request action, and request time.

[0066] Understandably, the mapping interface verification unit verifies the cross-domain interaction path and security mapping policy. This verification action is automatically triggered after the cross-domain path generation unit writes the path record. The mapping interface verification unit reads the mapping interface identifier and checks if it exists in the API gateway record, service gateway record, isolation device mapping record, or data platform interface record. If the mapping interface identifier exists and matches the source domain identifier and target domain identifier, the security mapping policy generation unit outputs the security mapping policy. If the mapping interface identifier is missing, the source domain identifier conflicts with the target domain identifier, or the isolation mapping status is abnormally associated, the exception recording unit writes an exception event and writes the data security level, field processing policy, access control result, source domain identifier, target domain identifier, interface identifier, and request time into the microservice runtime status data. This exception event serves as input for audit recording and monitoring linkage processing in the S700.

[0067] In one engineering embodiment, the mobile access request originates from the mobile access domain, the business module is identified as operation monitoring, and the access control result includes access to the isolation device mapping channel, encryption processing, and integrity digest generation. After receiving the data security level, field processing policy, and access control result output by S200, the cross-domain mapping module reads the source domain identifier, target domain identifier, and isolation mapping status. It writes the API gateway path from the mobile access domain to the Internet region into the access segment, the isolation device mapping path from the Internet region to the management information region into the cross-domain segment, and the unified API interface path from the data platform to the business module into the data call segment. The cross-domain path generation unit merges the access segment, cross-domain segment, and data call segment into a cross-domain interaction path. The security mapping policy generation unit generates the allowed interaction field set, field processing policy identifier, encryption method, digest verification method, return result type, and audit record rules based on field trimming, field desensitization, field encryption, and statistical result return. After checking the API gateway record, isolation device mapping record, and data platform interface record, the mapping interface verification unit outputs the cross-domain interaction path and security mapping policy to S400.

[0068] The cross-domain interaction path and security mapping policy output in this step are written into the cross-domain mapping record by the cross-domain mapping module and passed to S400. The cross-domain interaction path serves as the path input for interface encapsulation in S400, and the security mapping policy serves as the policy input for field desensitization, encryption, and integrity digest generation. The cross-domain interaction path includes the domains and mapping channels through which the request passes, and the security mapping policy includes records related to fields, interfaces, encryption, digests, returns, and auditing. If an abnormal event is generated in this step, the abnormal event is synchronously written into the microservice runtime status data and participates in abnormal interaction identification and interface risk assessment in S700.

[0069] In summary, this step transforms the data security level, field processing policy, and access control results output by S200 into cross-domain interaction paths and security mapping policies. The cross-domain interaction paths establish correspondences between the source domain, target domain, API gateway, service gateway, isolation device mapping channel, and data platform interface. The security mapping policy writes the allowed interaction field set, field processing policy identifier, encryption method, digest verification method, return result type, and audit record rules into the same policy record, providing direct input for the generation of cross-domain secure interaction data packets for S400.

[0070] S400. Based on the cross-domain interaction path and security mapping strategy, perform interface encapsulation, field desensitization, encryption processing and integrity digest generation processing to obtain a cross-domain secure interaction data packet;

[0071] In this step, the data packet encapsulation module receives the cross-domain interaction path and security mapping policy output by S300, and uses the cross-domain interaction path and security mapping policy as the input source for this step. The data packet encapsulation module consists of an interface encapsulation unit, a field desensitization unit, an encryption processing unit, an integrity digest generation unit, a data packet generation unit, and an encapsulation record unit. The cross-domain interaction path includes the same-domain Application Programming Interface (API) gateway call path, the isolation device mapping path from the Internet region to the management information region, the API gateway path from the mobile access domain to the Internet region, the IoT platform path from the IoT access domain to the data acquisition module, and the unified API interface path from the data middle platform to the business module. The security mapping policy includes the mapping relationship from the source domain to the target domain, the mapping interface identifier, the set of allowed interaction fields, the field processing policy identifier, the encryption processing method, the digest verification method, the return result type, and the audit record rules. The interface encapsulation unit first reads the mapping interface identifier and cross-domain interaction path, determines the interface entry point for the request to enter the API gateway, service gateway, or isolation device mapping channel, and writes the request identifier, source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, and service link identifier into the interface encapsulation record.

[0072] Specifically, the interface encapsulation process is triggered when the security mapping policy has a mapping interface identifier and the cross-domain interaction path has a path record. The interface encapsulation unit encapsulates the same-domain API gateway call path into a same-domain interface record according to the source-to-target domain mapping relationship; encapsulates the isolation device mapping path from the Internet region to the management information region into an isolation device mapping interface record; encapsulates the API gateway path from the mobile access domain to the Internet region into a mobile access interface record; encapsulates the IoT platform path from the IoT access domain to the data acquisition module into an IoT platform interface record; and encapsulates the unified API interface path from the data platform to the business module into a data platform interface record. The interface encapsulation record includes a request identifier, a mapping interface identifier, an interface identifier, a service link identifier, and an audit identifier. If the mapping interface identifier is missing, the encapsulation record unit generates an exception event and writes the cross-domain interaction path, security mapping policy, interface identifier, request time, and exception event into the microservice runtime status data.

[0073] Further, the field anonymization unit reads the allowed interactive field set, the field processing strategy identifier, and the return result type, and performs field anonymization processing on the fields to be interacted with. The allowed interactive field set is a data field record generated by S300 according to the field processing strategy that allows cross-domain interaction. The field processing strategy identifier corresponds to field transmission prohibition, field pruning, field anonymization, field encryption, statistical result return, and original field return. The field anonymization processing is performed on sensitive customer information, including contact person name, mailing address, contact number, and email address. When the field processing strategy identifier is field anonymization, the field anonymization unit writes the sensitive customer information into the anonymized field set and writes the return result type into the result anonymization. When the field processing strategy identifier is statistical result return, the field anonymization unit removes the detail field from the allowed interactive field set and writes the return result type into the statistical result return. When the field processing strategy identifier is field pruning, the field anonymization unit retains the corresponding field according to the allowed interactive field set and writes the unallowed field into the pruning field record. When the field processing strategy is identified as returning the original field, the field desensitization unit retains the field corresponding to the ordinary business data and writes the return result type to the original field return.

[0074] Further, the encryption processing unit reads the data security level, encryption method, field processing policy identifier, and allowed interaction field set, and encrypts the encrypted field set. The data security level includes password data, business application configuration data, important enterprise data, sensitive customer information, and general data. When the data security level is password data or business application configuration data, the encryption processing unit does not generate cross-domain transmission fields and writes the field processing policy identifier into the field prohibition transmission. When the data security level is important enterprise data, the encryption processing unit writes the fields corresponding to the system ledger and the ID numbers of maintenance personnel into the encrypted field set. When the data security level is sensitive customer information, the encryption processing unit writes the fields corresponding to the contact person's name, mailing address, contact number, and email address that still require cross-domain interaction after field anonymization into the encrypted field set. The encryption method is SM4 algorithm processing, which is executed by the encryption processing unit on the encrypted field set, and the encrypted field records are written into the encrypted field set position of the cross-domain secure interaction data packet.

[0075] Further, the integrity digest generation unit reads the request identifier, interface identifier, allowed interaction field set, timestamp, service link identifier, and audit identifier, and performs integrity digest generation processing. The digest verification method is SM3 algorithm digest processing. The timestamp is the time record written by the data packet encapsulation module when generating the cross-domain secure interaction data packet. The integrity digest generation unit associates the request identifier, interface identifier, allowed interaction field set, timestamp, and service link identifier to generate a digest value, and writes the digest value into the cross-domain secure interaction data packet. If the allowed interaction field set is empty, the integrity digest generation unit does not generate a digest value, and the encapsulation record unit writes the prohibited transmission fields, interface identifier, data security level, and request time into the exception event. If the encryption processing method and digest verification method are missing, the encapsulation record unit generates an exception event and passes the exception event to the microservice running status data.

[0076] Understandably, the data packet generation unit combines interface encapsulation records, de-identified field sets, encrypted field sets, digest values, and audit identifiers into a cross-domain secure interaction data packet. The cross-domain secure interaction data packet includes a request identifier, source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data security level, field processing policy identifier, allowed interaction field set, encrypted field set, digest value, timestamp, service link identifier, and audit identifier. The request identifier is used to distinguish a cross-domain interaction request; the source domain identifier and target domain identifier are used to record the cross-domain direction; the access subject identifier is used to record the subject in the unified permission data; the terminal type is used to record PC, mobile, or IoT device; the business module identifier is used to record integrated dashboards, operation management, production management, operation monitoring, performance evaluation, analysis reports, basic support, data collection, or mobile applications; the interface identifier is used to record API gateways, service gateways, isolation device mapping channels, or data platform interfaces; and the audit identifier is used by the S700 for audit recording and monitoring linkage processing.

[0077] In one engineering embodiment, the cross-domain interaction path corresponding to the mobile access request includes the API gateway path from the mobile access domain to the Internet region, the isolation device mapping path from the Internet region to the management information region, and the unified API interface path from the data platform to the operation monitoring. After receiving the cross-domain interaction path and security mapping policy, the interface encapsulation unit writes the mobile access request into the mobile access interface record, the isolation device mapping path into the isolation device mapping interface record, and the data platform interface into the data platform interface record. The field desensitization unit reads the set of allowed interaction fields, and after discovering that the contact name and contact number are sensitive customer information, performs field desensitization processing and writes the processed fields into the desensitized field set. The encryption processing unit reads the system ledger corresponding to the enterprise's important data, writes the system ledger into the encrypted field set, and performs SM4 algorithm processing. The integrity digest generation unit reads the request identifier, interface identifier, set of allowed interaction fields, timestamp, and service link identifier, performs SM3 algorithm digest processing, and generates a digest value. The data packet generation unit combines the request identifier, source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data security level, field processing policy identifier, allowed interaction field set, encrypted field set, digest value, timestamp, service link identifier, and audit identifier into a cross-domain secure interaction data packet.

[0078] The cross-domain secure interaction data packet output in this step is written into the encapsulation record by the data packet encapsulation module and passed to S500. In S500, this cross-domain secure interaction data packet serves as input for request routing, microservice runtime status matching, and target service instance selection. The request identifier, source domain identifier, target domain identifier, interface identifier, and service link identifier participate in request routing; the data security level, field processing policy identifier, allowed interaction field set, encrypted field set, and digest value participate in microservice runtime status matching; the audit identifier participates in audit recording and monitoring linkage processing in S700. If an abnormal event is generated in this step, the abnormal event is synchronously written into the microservice runtime status data and participates in abnormal interaction identification and interface risk assessment in S700.

[0079] In summary, this step converts the cross-domain interaction path and security mapping policy output by S300 into a cross-domain secure interaction data packet. This cross-domain secure interaction data packet binds the interface, fields, encryption, digest, and audit records into the same data structure. This cross-domain secure interaction data packet provides complete interactive input for S500's request routing and target service instance selection.

[0080] S500: Based on the cross-domain secure interaction data packet, perform request routing, microservice running status matching and target service instance selection processing to obtain the cross-domain service call result;

[0081] In this step, the routing invocation module receives the cross-domain secure interaction data packet output by S400 and uses it as the input source for this step. The routing invocation module consists of a request routing unit, a microservice runtime status matching unit, a target service instance selection unit, a call execution unit, and a call record unit. The cross-domain secure interaction data packet includes a request identifier, source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data security level, field processing policy identifier, allowed interaction field set, encrypted field set, digest value, timestamp, service link identifier, and audit identifier. The request routing unit reads the request identifier, source domain identifier, target domain identifier, interface identifier, and service link identifier to determine the routing entry point for the cross-domain secure interaction data packet to enter the Application Programming Interface (API) gateway, service gateway, or isolation device mapping channel. The microservice runtime status matching unit reads the microservice runtime status data, extracts the service health status, and matches the service health status with the data security level, cross-domain interaction path, and security mapping policy. The target service instance selection unit selects a target service instance based on the matching result, and then hands the target service instance over to the call execution unit to initiate a cross-domain service call.

[0082] Specifically, the request routing process is triggered when the cross-domain secure interaction data packet contains a request identifier, source domain identifier, target domain identifier, interface identifier, and service link identifier. The request routing unit first reads the source domain identifier and target domain identifier to determine whether the request belongs to a same-domain call or a cross-domain call. When the source domain identifier and target domain identifier are the same, the request routing unit selects the same-domain API gateway call path. When the source domain identifier is a mobile access domain and the target domain identifier is an Internet region, the request routing unit selects the API gateway path from the mobile access domain to the Internet region. When the source domain identifier is an Internet region and the target domain identifier is a management information region, the request routing unit selects the isolation device mapping path from the Internet region to the management information region. When the source domain identifier is an IoT access domain and the target domain identifier is a data acquisition module, the request routing unit selects the IoT platform path from the IoT access domain to the data acquisition module. When the target domain is identified as the data platform domain and the business module is identified as a comprehensive dashboard, operations management, production management, operation monitoring, performance evaluation, analysis report, basic support, data collection, or mobile application, the request routing unit selects the unified API interface path from the data platform to the business module. If the interface identifier is inconsistent with the service link identifier in the cross-domain secure interaction data packet, the call recording unit writes an exception event and does not output the routing result to the target service instance selection unit.

[0083] Furthermore, the microservice runtime status matching process is executed by the microservice runtime status matching unit. The microservice runtime status data includes service health status, which includes service instance availability status, interface response time, interface error rate, and exception event status. The service instance availability status is the record of the target service instance in the microservice runtime domain being callable, uncallable, or pending review. The interface response time is the interface return time recorded in the service gateway. The interface error rate is the proportion of error records for the same interface identifier in consecutive call records. The exception event status is the association status of exception events written in S100, S200, S300, or S400 in the microservice runtime status data. The microservice runtime status matching unit matches data security level, cross-domain interaction path, security mapping strategy, and service health status. When the data security level is important enterprise data or sensitive customer information, the matching action reads the isolation device mapping path, encrypted field set, digest value, and audit identifier. When the data security level is general data, the matching action reads the unified API interface path and audit record rules. When the field processing policy is marked as "field transmission prohibited", the matching action stops and the blocking record is written to the interface by the calling record unit.

[0084] Furthermore, the target service instance selection process is executed by the target service instance selection unit. The target service instance is a service instance in the microservice runtime domain corresponding to the interface identifier, business module identifier, and service link identifier. The target service instance selection unit writes the corresponding service instance into the target service instance list when the service instance's availability status is callable, the interface response time has a record, and the interface error rate has not triggered an abnormal event. When multiple service instances exist, the target service instance selection unit first matches the business module identifier, then the interface identifier, and subsequently matches the data security level and field processing strategy identifier. For important enterprise data, the target service instance selection unit selects service instances that have associated records with the isolation device mapping path, encrypted field set, and digest value. For sensitive customer information, the target service instance selection unit selects service instances that have associated records with result anonymization, statistical result return, or field anonymization. For general data, the target service instance selection unit selects service instances that have associated records with unified API interface calls and audit records. When a service instance is in an uncallable state, has a missing interface response time, or has an interface error rate that triggers an abnormal event, the call record unit writes the service instance's abnormal record and writes the service link identifier, interface identifier, abnormal event, and request time into the microservice runtime status data.

[0085] Understandably, the call execution unit initiates a cross-domain service call after the target service instance is generated. The cross-domain service call is executed according to the routing result output by the request routing unit. When the routing result is an API gateway path, the call execution unit sends the cross-domain secure interaction data packet to the target service instance through the API gateway. When the routing result is a service gateway path, the call execution unit sends the cross-domain secure interaction data packet to the target service instance through the service gateway. When the routing result is an isolation device mapping path, the call execution unit sends the cross-domain secure interaction data packet to the target service instance corresponding to the management information region through the isolation device mapping channel. When sending, the call execution unit retains the request identifier, digest value, timestamp, service link identifier, and audit identifier, and writes the call status, return data identifier, service call status, exception event, and response time returned by the target service instance into the cross-domain service call result. If the target service instance does not return a call status, the call recording unit writes a service call exception record and passes the service call exception record to the microservice runtime status data.

[0086] In one engineering embodiment, a mobile access request is processed via S400 to form a cross-domain secure interaction data packet. The source domain identifier in this packet is the mobile access domain, the target domain identifier is the management information region, the business module identifier is operation monitoring, the data security level includes important enterprise data and sensitive customer information, and the field processing strategy identifier includes field pruning, field desensitization, and field encryption. The request routing unit reads the source domain identifier, target domain identifier, and interface identifier, then writes the API gateway path from the mobile access domain to the Internet region into the access routing record, and writes the isolation device mapping path from the Internet region to the management information region into the cross-domain routing record. The microservice operation status matching unit reads the service health status and checks the service instance availability status, interface response time, interface error rate, and abnormal event status. The target service instance selection unit selects the target service instance that has an association record with operation monitoring, the isolation device mapping path, the encrypted field set, and the digest value. The call execution unit sends the cross-domain secure interaction data packet through the API gateway and the isolation device mapping channel, and receives the call status, returned data identifier, and response time returned by the target service instance, forming a cross-domain service call result.

[0087] The cross-domain service call result output in this step is written into the call record by the routing call module and passed to S600. The cross-domain service call result includes a request identifier, interface identifier, target service instance, service call status, return data identifier, exception event, and response time. The request identifier, interface identifier, and return data identifier are used as inputs for digest verification in S600; the target service instance and service call status are used as inputs for permission verification in S600; and the exception event and response time are used as inputs for audit recording and monitoring linkage processing in S700. If this step generates an interface blocking record, service instance exception record, or service call exception record, these records are synchronously written into the microservice runtime status data and participate in abnormal interaction identification, interface risk assessment, and service status linkage adjustment in S700.

[0088] In summary, this step converts the cross-domain secure interaction data packets output by S400 into cross-domain service call results. The request routing process maps the source domain identifier, target domain identifier, interface identifier, and service link identifier to the API gateway, service gateway, or isolation device mapping channel. The microservice runtime status matching and target service instance selection process combines data security level, cross-domain interaction path, security mapping strategy, and service health status for judgment, providing a basis for S600's digest verification, permission review, field restoration, and result anonymization.

[0089] S600. Based on the cross-domain service call result, perform summary verification, permission review, field restoration, and result desensitization to obtain a secure interaction result;

[0090] In this step, the result verification module receives the cross-domain service call result output by S500 and uses it as the input source for this step. The result verification module consists of a digest verification unit, an authorization verification unit, a field restoration unit, a result anonymization unit, a secure interaction result generation unit, and a verification record unit. The cross-domain service call result includes a request identifier, an interface identifier, a target service instance, a service call status, a returned data identifier, an exception event, and a response time. The digest verification unit reads the request identifier, interface identifier, returned data identifier, and the digest value written by S400, and performs digest verification processing. The authorization verification unit reads the access subject identifier, business module identifier, interface identifier, data security level, field processing policy identifier, and service call status, and performs authorization verification processing. The field restoration unit reads the encrypted field set, the allowed interaction field set, and the returned data identifier, and performs field restoration processing. The result anonymization unit reads the customer sensitive information, the returned result type, and the field processing policy identifier, and performs result anonymization processing.

[0091] Specifically, the digest verification process is triggered when the service call status is "call completed" and the returned data identifier exists. The digest verification unit reads the request identifier, interface identifier, allowed interaction field set, timestamp, service link identifier, and digest value from the cross-domain secure interaction data packet, and reads the returned data identifier from the cross-domain service call result. The digest verification unit performs SM3 algorithm digest processing on the returned data corresponding to the returned data identifier and compares the newly generated digest record with the digest value. If the comparison matches, the digest verification unit writes a digest verification passed record. If the comparison does not match, the review record unit writes an exception event and writes the request identifier, interface identifier, returned data identifier, digest value, service link identifier, and response time into the microservice runtime status data. Return data that fails digest verification does not enter the field restoration unit and result desensitization unit.

[0092] Specifically, the permission review process is triggered after the summary verification pass record is generated. The permission review unit reads the access subject identifier, business module identifier, interface identifier, data security level, and field processing strategy identifier, and calls the unified permission result for review. The access subject identifier is the identity record corresponding to the user, IoT device, or microservice call subject in the unified permission data. The business module identifier is a comprehensive dashboard, operation management, production management, operation monitoring, performance evaluation, analysis report, basic support, data collection, or mobile application. The data security level includes password data, business application configuration data, important enterprise data, sensitive customer information, and general data. If the unified permission result is consistent with the access subject identifier, business module identifier, interface identifier, and data security level, the permission review unit writes a permission review pass record. If the unified permission result is missing, or the access subject identifier is inconsistent with the business module identifier, interface identifier, and data security level, the review record unit writes a permission review exception record and writes the permission review exception record into the microservice running status data.

[0093] Specifically, the field restoration process is triggered when both the digest verification pass record and the permission review pass record exist. The field restoration unit reads the encrypted field set, the allowed interaction field set, the field processing policy identifier, and the returned data identifier. The encrypted field set is the set of fields written into the cross-domain secure interaction data packet by S400 after processing with the SM4 algorithm. The allowed interaction field set is the set of fields formed by S300 according to the security mapping policy. When the field processing policy identifier is "field encryption," the field restoration unit performs field restoration processing corresponding to the SM4 algorithm on the encrypted field set and writes the restored fields into the restored field record. When the field processing policy identifier is "field pruning," the field restoration unit only retains the fields in the allowed interaction field set and writes the unauthorized fields into the pruning field record. When the field processing policy identifier is "original field return," the field restoration unit reads the field corresponding to the general data and writes it into the original field return record. When the field processing policy identifier is "field transmission prohibited," the field restoration unit stops processing, and the review record unit writes the interface blocking result.

[0094] Understandably, the result anonymization process is triggered when the returned result type is result anonymization or statistical result return. The result anonymization unit reads customer sensitive information, field processing strategy identifier, and returned data identifier. The customer sensitive information includes contact person name, mailing address, contact number, and email address. When the field processing strategy identifier is field anonymization, the result anonymization unit anonymizes the contact person name, mailing address, contact number, and email address, and writes the anonymization result record. When the field processing strategy identifier is statistical result return, the result anonymization unit reads the returned result type corresponding to the statistical result return, removes the detail fields from the returned data, and writes them to the statistical result return record. When the field processing strategy identifier is original field return and the data security level is general data, the result anonymization unit does not change the ordinary business data fields and writes them to the original field return record. If the customer sensitive information is not anonymized, the review record unit writes an exception event and writes the exception event, access subject identifier, interface identifier, data security level, and response time to the microservice runtime status data.

[0095] In one engineering embodiment, a mobile access request is processed by S500 to generate a cross-domain service call result. The business module identifier in the cross-domain service call result is "Running Monitoring," and the target service instance has returned system ledger, contact person's name, contact number, and general business data corresponding to online device monitoring. The digest verification unit first reads the request identifier, interface identifier, returned data identifier, and digest value. It then performs SM3 algorithm digest processing on the returned data corresponding to the returned data identifier and writes it to the digest verification pass record. The permission review unit reads the access subject identifier, the business module identifier corresponding to "Running Monitoring," the interface identifier, and the data security level, compares them with the unified permission result, and writes it to the permission review pass record. The field restoration unit reads the encrypted field set corresponding to the system ledger, performs SM4 algorithm field restoration processing, and retains the allowed system ledger fields according to the allowed interaction field set. The result desensitization unit reads the contact person's name and contact number, performs result desensitization processing on sensitive customer information, and retains the general data fields corresponding to online device monitoring. The secure interaction result generation unit combines the digest verification pass record, permission review pass record, restored field record, desensitized result record, original field return record, and response time into a secure interaction result.

[0096] The security interaction results output in this step are written into the review record by the result review module and then transmitted to S700. The security interaction results include request identifier, interface identifier, target service instance, digest verification record, permission review record, restored field record, anonymized result record, original field return record, abnormal event, and response time. The digest verification record, permission review record, abnormal event, and response time serve as inputs for auditing records and monitoring linkage processing in S700. The restored field record, anonymized result record, and original field return record participate in the generation of the interaction policy update result in S700. If this step generates a digest verification exception record, permission review exception record, or result anonymization exception record, these records are synchronously written into the microservice runtime status data and participate in abnormal interaction identification and interface risk assessment in S700.

[0097] In summary, this step converts the cross-domain service call results output by S500 into secure interaction results. The digest verification, permission review, field restoration, and result anonymization processes perform closed-loop verification of the returned data, access subject, data security level, and field processing strategy. These secure interaction results provide a verified data foundation for the audit logs and monitoring linkage processing of S700.

[0098] S700. Based on the security interaction result, perform audit recording and monitoring linkage processing to obtain the interaction policy update result.

[0099] In this step, the audit update module receives the security interaction result output by S600 and calls the microservice running status data, abnormal events, cross-domain interaction paths, security mapping policies, encrypted digest information, and service call status written in S100 to S600. The audit update module consists of an audit recording unit, a monitoring linkage unit, an abnormal interaction identification unit, an interface risk assessment unit, a service status linkage adjustment unit, and a policy update unit. The security interaction result includes request identifier, interface identifier, target service instance, digest verification record, permission review record, restored field record, de-identification result record, original field return record, abnormal events, and response time. The audit recording unit reads the security interaction result and associates it with the interaction request profile formed by S100, the cross-domain interaction path and security mapping policy formed by S300, the encrypted digest information formed by S400, and the service call status formed by S500 to generate cross-domain interaction audit data.

[0100] Specifically, the audit record processing is automatically triggered after the secure interaction result is generated. The audit record unit writes the request identifier, access subject identifier, terminal type, business module identifier, interface identifier, source domain identifier, target domain identifier, data security level, field processing strategy identifier, cross-domain interaction path, security mapping strategy, digest verification record, permission review record, service call status, abnormal events, and response time into the cross-domain interaction audit data. The interaction request profile records the source domain, terminal type, and business module when the request enters the regional low-carbon service center. The cross-domain interaction path records the application programming interface gateway, service gateway, isolation device mapping channel, IoT platform path, and data middleware interface path traversed by the request. The security mapping strategy records the allowed set of interaction fields, encryption processing method, digest verification method, return result type, and audit record rules. The encrypted digest information records the encrypted field set, digest value, and timestamp. If there are digest verification anomaly records, permission review anomaly records, or result desensitization anomaly records in the secure interaction result, the audit record unit writes the corresponding anomaly event into the cross-domain interaction audit data and simultaneously writes it into the microservice running status data.

[0101] Furthermore, the monitoring linkage process is executed by the monitoring linkage unit. The monitoring linkage unit reads cross-domain interaction audit data and microservice runtime status data, and extracts the service health status. The service health status includes the service instance availability status, interface response time, interface error rate, and abnormal event status. The monitoring linkage unit associates the request identifier, interface identifier, target service instance, response time, and abnormal event status with the same service link identifier. If the same interface identifier is continuously written with abnormal event status in adjacent requests, the monitoring linkage unit writes the corresponding interface identifier into the interface to be evaluated record. If the same target service instance exhibits an uncallable state, missing response time, or service call anomaly record, the monitoring linkage unit writes the corresponding target service instance into the service instance to be adjusted record. If no abnormal events are found in the security interaction result, the monitoring linkage unit writes normal monitoring records.

[0102] Furthermore, the abnormal interaction identification process is executed by the abnormal interaction identification unit. This unit reads the summary verification record, permission review record, anonymization result record, abnormal events, and response time from the cross-domain interaction audit data, and combines this information with microservice runtime status data for identification. When the summary verification record is abnormal, the abnormal interaction identification unit generates a summary abnormal interaction record. When the permission review record is abnormal, the abnormal interaction identification unit generates a permission abnormal interaction record. When the anonymization result record is missing and the data security level is customer sensitive information, the abnormal interaction identification unit generates a result anonymization abnormal record. When the service call status is abnormal or the response time is missing, the abnormal interaction identification unit generates a service call abnormal record. The summary abnormal interaction record, permission abnormal interaction record, result anonymization abnormal record, and service call abnormal record are all written into the cross-domain interaction audit data and transmitted to the interface risk assessment unit.

[0103] Furthermore, the interface risk assessment process is executed by the interface risk assessment unit. The interface risk assessment unit reads the abnormal records output by the abnormal interaction identification unit and associates them with the interface identifier, data security level, field processing strategy identifier, cross-domain interaction path, and security mapping strategy. If the data security level corresponding to the abnormal record is important enterprise data, and the cross-domain interaction path includes an isolation device mapping channel, the interface risk assessment unit writes the corresponding interface identifier into the high-risk interface record. If the data security level corresponding to the abnormal record is sensitive customer information, and the field processing strategy identifier includes field desensitization or statistical result return, the interface risk assessment unit writes the corresponding interface identifier into the desensitization review interface record. If the data security level corresponding to the abnormal record is general data, and the abnormal event originates from the service call status, the interface risk assessment unit writes the corresponding interface identifier into the service review interface record. If the access control result corresponding to the abnormal record is prohibited cross-domain transmission, the interface risk assessment unit writes the corresponding interface identifier into the interface blocking candidate record.

[0104] Furthermore, the service status linkage adjustment process is executed by the service status linkage adjustment unit. This unit reads the service instance record to be adjusted, the interface record output by the interface risk assessment unit, and the microservice runtime status data. When a service instance's availability status is "uncallable," the service status linkage adjustment unit generates a service instance routing weight adjustment result and removes the corresponding target service instance from the selection range of target service instances corresponding to important enterprise data and sensitive customer information. When an interface error rate triggers an abnormal event status, the service status linkage adjustment unit generates an interface blocking result and writes the corresponding interface identifier into the interface blocking record. When an interface response time is missing, the service status linkage adjustment unit generates a service instance routing weight adjustment result and writes the service instance routing weight adjustment result into the microservice runtime status data. When a service instance's availability status is "callable" and the abnormal event status is empty, the service status linkage adjustment unit retains the original service call status record.

[0105] Understandably, the policy update unit generates interactive policy update results based on cross-domain interaction audit data, interface risk assessment results, and service status linkage adjustment results. The interactive policy update results include field processing policy adjustment results, security mapping policy adjustment results, service instance routing weight adjustment results, interface blocking results, result anonymization adjustment results, and audit record rule adjustment results. Field processing policy adjustment results are generated based on field anonymization anomaly records, statistical result return records, and original field return records. Security mapping policy adjustment results are generated based on source domain identifier, target domain identifier, cross-domain interaction path, and abnormal events. Service instance routing weight adjustment results are generated based on target service instance, service instance availability status, interface response time, and interface error rate. Interface blocking results are generated based on interface blocking candidate records and interface risk assessment results. Result anonymization adjustment results are generated based on customer sensitive information, anonymization result records, and result anonymization anomaly records. Audit record rule adjustment results are generated based on audit identifier, abnormal events, response time, and request time.

[0106] In one engineering embodiment, a mobile access request is processed by S600 to generate a secure interaction result. This secure interaction result includes a digest verification pass record, a permission review pass record, a restored field record from the system ledger, a de-identified record of the contact person's name and phone number, a record of the original field returned by the device online monitoring, and a response time. The audit recording unit associates the secure interaction result with the interaction request profile, cross-domain interaction path, security mapping strategy, encrypted digest information, and service call status to generate cross-domain interaction audit data. The monitoring linkage unit reads the service health status corresponding to the target service instance and checks the service instance availability status, interface response time, interface error rate, and abnormal event status. If a digest verification anomaly record subsequently appears for the same interface identifier, the abnormal interaction identification unit generates a digest anomaly interaction record, and the interface risk assessment unit writes the interface identifier into the high-risk interface record. The service status linkage adjustment unit generates a service instance routing weight adjustment result based on the high-risk interface record. The policy update unit generates an interaction policy update result based on the service instance routing weight adjustment result, the field processing strategy adjustment result, and the audit recording rule adjustment result.

[0107] The interaction policy update result output in this step is written into the policy record by the audit update module and fed back to the subsequent multi-domain interaction request processing process. The field processing policy adjustment result is written back to the field processing policy generation process in S200, the security mapping policy adjustment result is written back to the cross-domain mapping processing process in S300, the service instance routing weight adjustment result and interface blocking result are written back to the target service instance selection processing process in S500, the result desensitization adjustment result is written back to the result desensitization processing process in S600, and the audit record rule adjustment result continues to serve as the input for the subsequent audit record processing in this step. If this step generates an interface blocking result, the interface blocking result is synchronously written into the microservice running status data and enters the interaction request profile generation process along with the multi-domain interaction source data after the subsequent request enters S100.

[0108] In summary, this step transforms the security interaction results output by S600 into cross-domain interaction audit data and interaction policy update results. The linked audit recording and monitoring process merges and records interaction request profiles, cross-domain interaction paths, security mapping policies, encrypted digest information, service call status, abnormal events, and response times. The interaction policy update results are written back to the corresponding processing procedures of S200, S300, S500, and S600, forming a closed-loop operational foundation for multi-domain security interaction.

[0109] Example 2: Figure 2 This diagram illustrates a structural block diagram of a multi-domain security interaction system for a regional low-carbon service center according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0110] The request profiling module 01 is used to acquire multi-domain interaction source data from the regional low-carbon service center, perform source domain identification, terminal type identification, and business module identification processing to obtain a multi-domain interaction request profile. Specifically, the request profiling module receives intranet customer files, intranet electricity meter data, extranet IoT device data, personal computer access requests, mobile terminal access requests, unified permission data, business module call requests, and microservice running status data, and reads request time, request action, access subject identifier, interface identifier, and data object identifier from the multi-domain interaction source data. The request profiling module identifies the source domain according to the management information region, internet region, IoT access domain, mobile access domain, data platform domain, unified permission domain, and microservice running domain; identifies the terminal type according to personal computer, mobile terminal, and IoT device; and identifies the business module according to comprehensive dashboard, operation management, production management, operation monitoring, performance evaluation, analysis reports, basic support, data collection, and mobile applications. After the request profiling module generates identification records for the source domain, terminal type, and business module, it associates the source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data object identifier, request action, unified permission result, service link identifier, isolation mapping status, and request time into a multi-domain interaction request profile, and then transmits the multi-domain interaction request profile to the security classification module. If the source domain, terminal type, or business module is missing, the request profiling module records the abnormal event and request time, and retains the corresponding multi-domain interaction source data.

[0111] The security classification module 02, connected to the request profiling module, receives the multi-domain interaction request profile, performs data classification, sensitive field identification, and access subject permission matching processing to obtain data security level, field processing strategy, and access control result. Specifically, the security classification module receives the multi-domain interaction request profile output by the request profiling module and reads the source domain identifier, target domain identifier, access subject identifier, business module identifier, interface identifier, data object identifier, and unified permission result. The security classification module classifies the data to be interacted into password data, business application configuration data, important enterprise data, sensitive customer information, and general data according to the data source, data content, and storage location corresponding to the data object identifier, thus obtaining the data security level. The security classification module identifies system ledgers, maintenance personnel ID numbers, contact person names, mailing addresses, contact numbers, and email addresses from the fields corresponding to the data object identifier, generating sensitive field records. The security classification module compares the access subject identifier, business module identifier, interface identifier, request action, and unified permission result to generate access subject permission matching records, and generates field processing strategies and access control results based on the data security level, sensitive field records, and access subject permission matching records. The security classification module transmits the data security level, field processing strategy, and access control result to the cross-domain mapping module. If the unified permission result is missing or the interface identifier is inconsistent with the business module identifier, the security classification module records the abnormal event and writes it into the access control result.

[0112] The cross-domain mapping module 03, connected to the security classification module, receives the data security level, field processing policy, and access control results, performs inter-domain isolation relationship matching and cross-domain mapping processing, and obtains the cross-domain interaction path and security mapping policy. Specifically, the cross-domain mapping module receives the data security level, field processing policy, and access control results output by the security classification module, and calls the source domain identifier, target domain identifier, interface identifier, service link identifier, and isolation mapping status from the multi-domain interaction request profile. The cross-domain mapping module performs inter-domain isolation relationship matching according to the access boundary records between the source domain identifier and the target domain identifier, forming same-domain access records, management information region to Internet region isolation records, Internet region to management information region isolation records, mobile access domain to Internet region access records, IoT access domain to data acquisition module access records, data middle platform domain to business module call records, and unified permission domain to business module verification records. The cross-domain mapping module generates the following paths based on access control results: same-domain application programming interface (API) gateway call paths, isolation device mapping paths from the Internet region to the management information region, API gateway paths from the mobile access domain to the Internet region, IoT platform paths from the IoT access domain to the data acquisition module, and unified API paths from the data middle platform to the business module. It also generates security mapping policies based on field processing strategies. The cross-domain mapping module transmits the cross-domain interaction paths and security mapping policies to the data packet encapsulation module. If the access control result prohibits cross-domain transmission, the cross-domain mapping module records the interface blocking result and stops generating cross-domain interaction paths.

[0113] The data packet encapsulation module 04, connected to the cross-domain mapping module, receives the cross-domain interaction path and security mapping policy, and performs interface encapsulation, field desensitization, encryption, and integrity digest generation to obtain a cross-domain secure interaction data packet. Specifically, the data packet encapsulation module receives the cross-domain interaction path and security mapping policy output by the cross-domain mapping module, and reads the mapping interface identifier, allowed interaction field set, field processing policy identifier, encryption method, digest verification method, return result type, and audit record rules. The data packet encapsulation module performs interface encapsulation according to the application programming interface gateway, service gateway, isolation device mapping channel, IoT platform path, and data middle platform interface path in the cross-domain interaction path, forming an interface encapsulation record. The data packet encapsulation module processes the allowed interaction field set according to the field processing policy identifier, desensitizes the contact person's name, mailing address, contact number, and email address in sensitive customer information, performs field trimming and encryption processing on the system ledger and maintenance personnel's ID number in important enterprise data, and generates original field return records for general data. The data packet encapsulation module generates a digest value based on the request identifier, interface identifier, allowed interaction field set, timestamp, and service link identifier. It then combines the request identifier, source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data security level, field processing policy identifier, allowed interaction field set, encrypted field set, digest value, timestamp, service link identifier, and audit identifier into a cross-domain secure interaction data packet. The data packet encapsulation module then transmits this cross-domain secure interaction data packet to the routing call module. If the allowed interaction field set is empty or the mapped interface identifier is missing, the data packet encapsulation module records the exception event and writes it into the microservice runtime status data.

[0114] The routing invocation module 05, connected to the data packet encapsulation module, receives the cross-domain secure interaction data packet, performs request routing, microservice runtime status matching, and target service instance selection processing to obtain the cross-domain service invocation result. Specifically, the routing invocation module receives the cross-domain secure interaction data packet output by the data packet encapsulation module and reads the request identifier, source domain identifier, target domain identifier, interface identifier, data security level, field processing strategy identifier, digest value, service link identifier, and audit identifier. The routing invocation module selects the following paths based on the source domain identifier and target domain identifier: the same-domain application programming interface gateway invocation path, the application programming interface gateway path from the mobile access domain to the Internet region, the isolation device mapping path from the Internet region to the management information region, the IoT platform path from the IoT access domain to the data acquisition module, or the unified application programming interface path from the data middle platform to the business module. The routing invocation module reads the microservice runtime status data and performs microservice runtime status matching based on the service instance availability status, interface response time, interface error rate, and abnormal event status. The routing invocation module selects a target service instance based on the business module identifier, interface identifier, data security level, and field processing strategy identifier, and sends a cross-domain secure interaction data packet to the target service instance. The routing invocation module receives the invocation status, returned data identifier, service invocation status, exception event, and response time returned by the target service instance, generates a cross-domain service invocation result, and transmits the cross-domain service invocation result to the result verification module; if the service instance's availability status is uncallable, the routing invocation module records the service instance exception record.

[0115] The result verification module 06, connected to the routing call module, receives the cross-domain service call result, performs digest verification, permission verification, field restoration, and result anonymization processing to obtain a secure interaction result. Specifically, the result verification module receives the cross-domain service call result output by the routing call module and reads the request identifier, interface identifier, target service instance, service call status, return data identifier, exception event, and response time. The result verification module calls the digest value, allowed interaction field set, encrypted field set, data security level, field processing policy identifier, and audit identifier in the cross-domain secure interaction data packet to perform digest verification on the return data corresponding to the return data identifier. The result verification module performs permission verification on the access subject identifier, business module identifier, interface identifier, data security level, and unified permission result, and performs field restoration and result anonymization processing when both the digest verification record and the permission verification record pass. The result verification module restores the encrypted field set, prunes fields outside the allowed interaction field set, anonymizes sensitive customer information, and generates original field return records for general data. The result verification module combines the summary verification record, permission verification record, restored field record, de-identified result record, original field return record, abnormal event, and response time into a secure interaction result, and transmits the secure interaction result to the audit update module; if the summary verification record or permission verification record is abnormal, the result verification module records the abnormal event and writes it into the microservice running status data.

[0116] The audit update module 07, connected to the result verification module, receives the security interaction results, performs audit recording and monitoring linkage processing, and obtains the interaction policy update results. Specifically, the audit update module receives the security interaction results output by the result verification module and associates them with multi-domain interaction request profiles, cross-domain interaction paths, security mapping policies, encrypted digest information, service call status, and microservice running status data. The audit update module writes the request identifier, access subject identifier, terminal type, business module identifier, interface identifier, source domain identifier, target domain identifier, data security level, field processing policy identifier, cross-domain interaction path, security mapping policy, digest verification record, permission verification record, service call status, abnormal events, and response time into the cross-domain interaction audit data. The audit update module performs monitoring linkage processing based on the cross-domain interaction audit data and service health status, identifies abnormal digest interaction records, abnormal permission interaction records, abnormal result anonymization records, and abnormal service call records, and performs interface risk assessment based on the interface identifier, data security level, field processing policy identifier, cross-domain interaction path, and security mapping policy. The audit update module generates field processing strategy adjustment results, security mapping strategy adjustment results, service instance routing weight adjustment results, interface blocking results, result anonymization adjustment results, and audit record rule adjustment results based on the interface risk assessment results and microservice runtime status data. These are combined into an interaction strategy update result. The audit update module then sends the interaction strategy update result back to the security classification module, cross-domain mapping module, routing call module, and result review module, and writes the interface blocking result into the microservice runtime status data.

Claims

1. A multi-domain security interaction method for a regional low-carbon service center, characterized in that, include: S100: Obtain multi-domain interaction source data from the regional low-carbon service center, perform source domain identification, terminal type identification, and business module identification processing, and associate the source domain identifier, target domain identifier, access subject identifier, terminal type, business module identifier, interface identifier, data object identifier, request action, unified permission result, service link identifier, isolation mapping status, and request time to obtain a multi-domain interaction request profile. S200. Based on the multi-domain interaction request profile, the data is classified according to the data source, data content and storage location corresponding to the data object identifier, and the data security level is divided into password data, business application configuration data, important enterprise data, sensitive customer information and general data. Sensitive field identification and access subject permission matching are performed. Based on the data security level, sensitive field records, and permission matching records, a field processing strategy is generated. The field processing strategy includes prohibiting field transmission, field pruning, field desensitization, field encryption, returning statistical results, and returning the original field. Based on the data security level, field processing strategy, and permission matching records, an access control result is generated. S300. Based on the data security level, field processing policy, and access control results, perform inter-domain isolation relationship matching and cross-domain mapping processing to obtain the cross-domain interaction path and security mapping policy; the security mapping policy includes the mapping relationship from the source domain to the target domain, the mapping interface identifier, the set of allowed interaction fields, the field processing policy identifier, the encryption processing method, the digest verification method, the return result type, and the audit record rules; S400. Based on the cross-domain interaction path and security mapping strategy, perform interface encapsulation, field desensitization, encryption processing and integrity digest generation processing to obtain a cross-domain secure interaction data packet; The cross-domain secure interaction data packet includes a request identifier, a source domain identifier, a target domain identifier, an access subject identifier, a terminal type, a business module identifier, an interface identifier, a data security level, a field processing policy identifier, a set of allowed interaction fields, a set of encrypted fields, a digest value, a timestamp, a service link identifier, and an audit identifier; S500: Based on the cross-domain secure interaction data packet, perform request routing and microservice running status matching processing, match the data security level, cross-domain interaction path, security mapping strategy and service health status, select the target service instance, and obtain the cross-domain service call result; S600. Based on the cross-domain service call result, perform summary verification, permission review, field restoration, and result desensitization to obtain a secure interaction result; S700. Based on the security interaction result, perform audit recording and monitoring linkage processing to obtain the interaction policy update result; The interactive policy update results include field processing policy adjustment results, security mapping policy adjustment results, service instance routing weight adjustment results, interface blocking results, result anonymization adjustment results, and audit log rule adjustment results. The field processing policy adjustment results are written back to the field processing policy generation process in S200, the security mapping policy adjustment results are written back to the cross-domain mapping processing process in S300, the service instance routing weight adjustment results and interface blocking results are written back to the target service instance selection processing process in S500, and the result anonymization adjustment results are written back to the result anonymization processing process in S600.

2. The multi-domain security interaction method for regional low-carbon service centers according to claim 1, characterized in that, The multi-domain interactive source data includes intranet customer profiles, intranet electricity meter data, extranet IoT device data, PC access requests, mobile access requests, unified permission data, business module call requests, and microservice running status data; the source domains include management information region, internet region, IoT access domain, mobile access domain, data platform domain, unified permission domain, and microservice running domain.

3. The multi-domain security interaction method for regional low-carbon service centers according to claim 1, characterized in that, The sensitive fields identified include system ledgers, maintenance personnel ID numbers, contact person names, mailing addresses, contact phone numbers, and email addresses.

4. The multi-domain security interaction method for regional low-carbon service centers according to claim 1, characterized in that, If the data security level is password data or business application configuration data, the access control result is to prohibit cross-domain transmission; if the data security level is important enterprise data, the access control result is to access the isolated device mapping channel, encrypt the data, and generate an integrity digest; if the data security level is sensitive customer information, the access control result is to anonymize the results or return statistical results. If the data security level is general data, the access control result is a unified API interface call and audit log.

5. The multi-domain security interaction method for regional low-carbon service centers according to claim 1, characterized in that, The cross-domain interaction paths include the same-domain API gateway call path, the isolation device mapping path from the Internet region to the management information region, the API gateway path from the mobile access domain to the Internet region, the IoT platform path from the IoT access domain to the data acquisition module, and the unified API interface path from the data middle platform to the business module.

6. The multi-domain security interaction method for regional low-carbon service centers according to claim 1, characterized in that, The encryption process is performed using the SM4 algorithm; the integrity digest generation is performed using the SM3 algorithm digest process.

7. The multi-domain security interaction method for regional low-carbon service centers according to claim 2, characterized in that, The microservice runtime status data includes service health status, which includes service instance availability, interface response time, interface error rate, and abnormal event status.

8. A multi-domain security interaction system for a regional low-carbon service center, characterized in that, include: Request profiling module, security classification module, cross-domain mapping module, data packet encapsulation module, route invocation module, result verification module, and audit update module; The system is used to perform the method according to any one of claims 1-7.

Images