Government affair information management method based on cloud

Abstract

The invention relates to the technical field of government affair information management, in particular to a cloud-based government affair information management method, which comprises the following steps of: S1, adding a sensitivity label for each piece of government affair data in a cloud storage layer; s2, extracting data from the government affair database and generating a dynamic data view with an authority mark; s3, establishing a mapping relation table between routing keys and data source addresses; s4, acquiring a requester department function code, a business scene code and a target data identifier; s5, matching a target data source, and based on the authority mark in the dynamic data view, executing a desensitization operation on the sensitive field; and S6, if the genetic marker bit of the original data is true, superposing the data security classification in the original tag and the current security classification to form a new tag. According to the method, by constructing the sensitivity label and the dynamic authority control mechanism, safe inheritance and accurate access of government affair data in cross-department circulation are achieved, and the safety and compliance of data management are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of government information management, and in particular to a cloud-based government information management method. Background Art

[0002] With the acceleration of the digitalization of government affairs, a large amount of cross-departmental and multi-level government data has been aggregated to cloud platforms for unified management and shared access. To improve data utilization efficiency and business response speed, government agencies at all levels generally rely on centralized government databases under cloud computing architecture to retrieve, process and share data resources in multiple business scenarios. Due to the wide variety of data involved, diverse sources, and the inclusion of a lot of sensitive information involving privacy, finance, identity, etc., how to ensure data availability while achieving dynamic control of data access rights and effective protection of sensitive content has become one of the core challenges in the current design of government information management systems.

[0003] The existing technology suffers from the following common problems: First, there is a lack of fine-grained data permission control mechanisms, making it impossible to precisely define field-level read and write permissions based on the visitor's departmental functions and specific business scenarios. Second, there is a lack of logic for the transfer and inheritance of sensitivity labels during data transfer, resulting in sensitive information losing its original classification protection after multiple transfers. Third, data desensitization operations typically use static policies that fail to dynamically adjust based on access rights, resulting in problems with over- or under-desensitization. Therefore, a cloud-based government information management method is urgently needed to address the above issues. Summary of the Invention

[0004] Based on the above objectives, the present invention provides a cloud-based government information management method.

[0005] A cloud-based government information management method includes the following steps: S1: Add a sensitivity label to each piece of government data in the cloud storage layer. The sensitivity label includes the data confidentiality level and genetic marker bit; S2: Extract data from the government database and generate a dynamic data view with permission tags based on the department function code of the requesting department and the current business scenario code; S3: Combine the department function code and the business scenario code into a routing key and create a mapping table between the routing key and the data source address; S4: Obtain the requesting party's department function code, business scenario code, and target data identifier; S5: Query the mapping table in S3 based on the department function code and business scenario code in S4 to match the target data source. When reading data from the target data source, perform desensitization operations on sensitive fields based on the permission tags in the dynamic data view generated by S2. S6: When data is written by a new department, a new sensitivity label is generated based on the confidentiality level of the writing department. If the inherited flag bit of the original data is true, the data confidentiality level in the original label is superimposed with the current confidentiality level to form a new label.

[0006] Optionally, the S1 specifically includes: S11: When government data is first stored in the cloud storage layer, the data source department determines the initial data classification level, which is selected from a predefined classification level enumeration set, including public level L1, internal level L2, and confidential level L3; S12: Setting a genetic flag bit according to the data subject type, wherein the genetic flag bit is a Boolean identifier , whose expression is: ; in, It is a genetic flag bit. When the Boolean value is 1, it means true, and 0 means false.

[0007] Optionally, the S2 specifically includes: S21: Generate initial query conditions based on the requesting department function code and business scenario code, and initiate a data query request to the government database through the database query engine; S22: Returning the original data set that meets the query conditions from the government database, and temporarily storing the original data set in a temporary buffer area; S23: Retrieving a field-level permission control rule that matches the requesting department function code and the business scenario code from the permission control policy library, wherein the permission control rule defines the read and write permissions for each field; S24: traverse the original data set in the temporary buffer area and generate a readable or writable permission mark for each field according to the field-level permission control rule obtained in S23; S25: Integrate the processed original data set and the permission tags of the corresponding fields to form a dynamic data view.

[0008] Optionally, the S23 specifically includes: S231: Based on the requesting department function code and business scenario code, generate the permission policy query key. The expression is: ,in, Query key for permission policy; Code the departmental function of the requesting department; Encode the current business scenario; It is a string concatenation operator; S232: Query key using permission policy ,retrieve the permission control policy library in a key-value matching manner to obtain the corresponding permission control rule index; S233: According to the permission control rule index, locate the field-level permission control rule record in the permission control policy library, load the read permission value and write permission value of each data field defined in the record, and form the permission control rule.

[0009] Optionally, the S3 specifically includes: S31: Obtain a unique data source address identifier for each government data source from a pre-configured government database registry; S32: Based on the functional code of the department to which each data source belongs and the serviceable business scenario code, a routing key is formed by combining and splicing them in a predefined order. The specific expression is: ,in, Represents the generated routing key; Indicates the department function code corresponding to the data source; Indicates the business scenario code applicable to the data source; Represents string concatenation operation; S33: Mapping the routing keys generated in S32 to the corresponding data source address identifiers one by one, generating a key-value pair mapping relationship table with the routing keys as the search index and the data source addresses as the mapping results; S34: The key-value pair mapping relationship table generated in S33 is stored in the cloud configuration center.

[0010] Optionally, the S4 specifically includes: S41: receiving a data access request submitted by a requester through a government service interface, including the requester's department identity authentication credentials, business call context information, and data target parameters; S42: Parse the identity authentication credentials submitted by the requester, combine them with the verification results of the unified identity authentication platform, and extract the department function code after authentication; S43: extracting the business scenario code from the business call context information, including the current operation type, the government process node or the triggering method; S44: extracting a target data identifier from the data target parameter set, including a data table number, a data object primary key, or a tag attribute; S45: The extracted department function code, business scenario code, and target data identifier are used as structured request meta-information for future use.

[0011] Optionally, the S5 specifically includes: S51: Combine the department function code and the business scenario code obtained in S4 into a request routing key in a predetermined sequence, and use the request routing key as an index key to query the routing key and data source address mapping relationship table generated in S3 to determine the target data source address; S52: Establish a data connection channel according to the target data source address, and read the original data from the target data source based on the target data identifier provided by S4; S53: Load the original data obtained from the target data source into the dynamic data view generated by S2, and identify the read and write permissions of sensitive fields based on the permission tags corresponding to each field; S54: For the sensitive fields identified as readable or unreadable in S53, perform corresponding desensitization processing according to a predefined desensitization strategy to obtain a desensitized data view; S55: Output the desensitized data view for access by the requesting party.

[0012] Optionally, the S54 specifically includes: S541: Traverse the dynamic data view in S53, check the permission tags of each sensitive field one by one, filter out sensitive fields with a read permission tag of 0 or a write permission tag of 0 in the permission tag, and mark them as fields to be desensitized; S542: Retrieve corresponding desensitization rules from a predefined desensitization policy library based on the field type and permission tag of the field to be desensitized, including defining a replacement method, truncation length, or mask format for the field value; Specifically, if the desensitization rule is mask replacement, the field value is replaced according to the predefined mask format; If the desensitization rule is character truncation, the field value is truncate to a fixed length; If the desensitization rule is null value replacement, the field value is directly set to null; S543: Update the desensitized field value to the dynamic data view to complete the desensitization operation.

[0013] Optionally, the S6 specifically includes: S61: When a new department writes data to the government database, the department security level corresponding to the new department is obtained as the initial security level for the current data writing operation; S62: Determine the value of the inherited flag bit in the original sensitivity label of the data to be written; if the value of the inherited flag bit is true, proceed to the next step; otherwise, directly use the new department classification level as the final classification level of the new sensitivity label; S63: If the inherited flag is true, extract the data confidentiality level in the original data label, compare it with the current department confidentiality level, and sort it in descending order of sensitivity; S64: Select the highest confidentiality level from the sorting results in S63 as the final confidentiality level of the superimposed new sensitivity label; S65: Based on the final confidentiality level determined in S64, the sensitivity label of the data is updated to complete the data writing operation.

[0014] Optionally, the S63 specifically includes: S631: Obtain the confidentiality level value of the current written department and the confidentiality level value in the original data tag from the sensitivity level enumeration set; S632: Based on a predefined sensitivity level value mapping table, the obtained confidentiality level is converted into a corresponding level value. Specifically, the public level L1 corresponds to a level value of 1, the internal level L2 corresponds to a level value of 2, and the confidential level L3 corresponds to a level value of 3; S633: Compare the two level values ​​obtained in S632 and determine the level with the larger value as the confidentiality level value of the new label; S634: Reversely map the level value determined in S633 back to the corresponding sensitivity level enumeration as the final confidentiality level of the new sensitivity label.

[0015] Beneficial effects of the present invention: The present invention adds a sensitivity label containing confidentiality levels and genetic attributes to each piece of government data in the cloud storage layer, thereby realizing label inheritance and confidentiality level superposition during the flow of data between different departments, ensuring that sensitive information is not downgraded during multiple writing or sharing processes, and fundamentally improving the security and controllability of data throughout its entire life cycle.

[0016] The present invention dynamically generates data access permission tags by combining department function codes with business scenario codes, and performs differentiated desensitization processing at the field level, so that visible content can be accurately output according to the visitor's permissions during the data reading process, effectively solving the problems of extensive permission configuration and static desensitization strategies in current government systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only for the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 Schematic diagram of a government information management method according to an embodiment of the present invention; Figure 2 Schematic diagram of the process of forming a new label by superimposing according to an embodiment of the present invention. DETAILED DESCRIPTION

[0019] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments. It is also noted that, to provide a more detailed description, the following embodiments are best and preferred embodiments, and those skilled in the art may employ alternative methods for implementing certain known technologies. Furthermore, the accompanying drawings are intended only to provide a more detailed description of the embodiments and are not intended to limit the present invention.

[0020] It should be noted that references in the specification to "one embodiment," "an embodiment," "exemplary embodiments," "some embodiments," etc. indicate that the described embodiments may include specific features, structures, or characteristics, but not necessarily every embodiment will include such specific features, structures, or characteristics. Furthermore, when specific features, structures, or characteristics are described in conjunction with an embodiment, it is within the knowledge of persons skilled in the relevant art to implement such features, structures, or characteristics in conjunction with other embodiments (whether or not explicitly described).

[0021] In general, terms can be understood, at least in part, from their use in context. For example, depending at least in part on the context, the term "one or more" as used herein can be used to describe any feature, structure, or characteristic in the singular sense, or can be used to describe a combination of features, structures, or characteristics in the plural sense. Additionally, the term "based on" can be understood as not necessarily intended to convey an exclusive set of factors, but can instead, depending at least in part on the context, allow for the presence of other factors that are not necessarily explicitly described.

[0022] like Figure 1-Figure 2 As shown, a cloud-based government information management method includes the following steps: S1: Add a sensitivity label to each piece of government data in the cloud storage layer. The sensitivity label includes the data classification level and a heritable flag. The heritable flag is used to indicate the inheritance status of the sensitivity label during data transfer. S2: Extract data from the government database and generate a dynamic data view with permission tags based on the department function code of the requesting department and the current business scenario code; the permission tags include field-level read / write flags; S3: Combine the department function code and the business scenario code into a routing key and create a mapping table between the routing key and the data source address; S4: Obtain the requesting party's department function code, business scenario code, and target data identifier; S5: Query the mapping table in S3 based on the department function code and business scenario code in S4 to match the target data source. When reading data from the target data source, perform desensitization operations on sensitive fields based on the permission tags in the dynamic data view generated by S2. S6: When data is written by a new department, a new sensitivity label is generated based on the confidentiality level of the writing department. If the inherited flag bit of the original data is true, the data confidentiality level in the original label is superimposed with the current confidentiality level to form a new label.

[0023] S1 specifically includes: S11: When government data is first stored in the cloud storage layer, the data source department determines the initial data classification level, which is selected from a predefined classification level enumeration set, including public level L1, internal level L2, and confidential level L3; S12: Set the genetic flag bit according to the data subject type. The genetic flag bit is a Boolean identifier. , whose expression is: ; in, It is a hereditary flag bit, when the Boolean value is 1 it indicates true, and 0 indicates false; cross-departmental strong association types include household registration, social security or taxation; department-specific types include internal approval records or temporary statistical reports; the above steps set clear confidentiality levels and hereditary attributes in combination with the data source department and subject type at the initial stage of data entry, which not only ensures the hierarchical management and inheritance control mechanism of government data, but also provides a structured basis for subsequent dynamic permission control and label superposition.

[0024] S2 specifically includes: S21: Generate initial query conditions based on the requesting department function code and business scenario code, and initiate a data query request to the government database through the database query engine; S22: Returning the original data set that meets the query conditions from the government database, and temporarily storing the original data set in a temporary buffer area; S23: Retrieve a field-level permission control rule that matches the requesting department's function code and business scenario code from the permission control policy library. The permission control rule defines the read and write permissions for each field. S24: Traverse the original data set in the temporary buffer area and generate a readable or writable permission tag for each field according to the field-level permission control rule obtained in S23. The permission tag is expressed in the form of a two-tuple: ,in, For the Permission flags for each field; The read permission of the field is a Boolean value, 1 means readable, 0 means unreadable; The write permission of the field is a Boolean value, 1 means writable, 0 means not writable; S25: Integrate the processed original data set and the permission tags of the corresponding fields to form a dynamic data view, and pass the dynamic data view to the subsequent steps for use; the above steps generate dynamic permission tags by accurately matching department functions and business scenarios, realizing refined and scenario-based permission control of government data, effectively preventing unauthorized access and unauthorized modification of data, and significantly enhancing data security and management efficiency.

[0025] S23 specifically includes: S231: Based on the requesting department function code and the business scenario code, a permission policy query key is generated. The permission policy query key is generated by concatenating the department function code and the business scenario code in a predetermined order. The expression is: ,in, Query key for permission policy; Code the departmental function of the requesting department; Encode the current business scenario; It is a string concatenation operator; S232: Query key using permission policy ,retrieve the permission control policy library in a key-value matching manner to obtain the corresponding permission control rule index; S233: According to the permission control rule index, locate the field-level permission control rule record in the permission control policy library, load the read permission value and write permission value of each data field defined in the record, and form the permission control rule; the above steps quickly and accurately retrieve the permission control rules through a clear key-value index mechanism, effectively improving the accuracy and response efficiency of government data access permission management, and avoiding data security risks caused by permission mismatch.

[0026] Table 1 Example of permission control policy library In Table 1 above, the policy ID uniquely identifies each set of permission policy rules and is used for internal indexing; the department function code indicates the function code of the requesting department to which the permission policy applies; the business scenario code indicates the specific business usage scenario corresponding to the permission policy; the field name identifies the controlled data field in the government database; the readable permission indicates whether the field can be read by the current department in the current business scenario, 1 indicates readable, and 0 indicates unreadable; the writable permission indicates whether the field can be written by the current department in the current business scenario, 1 indicates writable, and 0 indicates unwritable.

[0027] S3 specifically includes: S31: Obtain a unique data source address identifier for each government data source from a pre-configured government database registry; S32: Based on the functional code of the department to which each data source belongs and the serviceable business scenario code, a routing key is formed by combining and splicing them in a predefined order. The specific expression is: ,in, Represents the generated routing key; Indicates the department function code corresponding to the data source; Indicates the business scenario code applicable to the data source; Represents string concatenation operation; S33: Mapping the routing keys generated in S32 to the corresponding data source address identifiers one by one, generating a key-value pair mapping relationship table with the routing keys as the search index and the data source addresses as the mapping results; S34: The key-value pair mapping relationship table generated by S33 is stored in the cloud configuration center for rapid retrieval of the target data source during subsequent data request operations. The above steps significantly improve the efficiency of data request locating data sources through a clear data source and routing key mapping relationship table, simplify the data access path, and ensure the timeliness and accuracy of data interaction.

[0028] Table 2 Key-value pair mapping relationship table In Table 2 above, the routing key is a unique identification string composed of the department function code and the business scenario code, which serves as the retrieval key for querying the data source address; the department function code is the code that identifies the department responsibility type that initiates the data request; the business scenario code is the code that identifies the business processing scenario corresponding to the current data access; the data source address represents the cloud database access address or API endpoint that actually stores government data, which is the target path for actual data pulling.

[0029] S4 specifically includes: S41: receiving a data access request submitted by a requester through a government service interface, including the requester's department identity authentication credentials, business call context information, and data target parameters; S42: Parse the identity authentication credentials submitted by the requester, combine them with the verification results of the unified identity authentication platform, and extract the department function code after authentication; S43: Extracting a business scenario code from the business call context information, including the current operation type, the government process node or triggering method, to identify the business processing scenario to which the request belongs; S44: extracting a target data identifier from the data target parameter set, including a data table number, a data object primary key, or a tag attribute, to uniquely identify the data unit to be accessed by this request; S45: The extracted department function code, business scenario code and target data identifier are used as structured request metadata and passed to subsequent steps for routing and permission processing. The above steps combine the identity authentication platform, business context information and request parameter set to achieve structured identification and standardized extraction of the requester's data access target, ensuring that the source is trustworthy, the scenario is clear, and the target is controllable in the data access process, thereby improving the security and accuracy of system data processing.

[0030] S5 specifically includes: S51: Combine the department function code and the business scenario code obtained in S4 into a request routing key in a predetermined sequence, and use the request routing key as an index key to query the routing key and data source address mapping relationship table generated in S3 to determine the target data source address; S52: Establish a data connection channel according to the target data source address, and read the original data from the target data source based on the target data identifier provided by S4; S53: Load the original data obtained from the target data source into the dynamic data view generated by S2, and identify the read and write permissions of sensitive fields based on the permission tags corresponding to each field; S54: For the sensitive fields identified as readable or unreadable in S53, perform corresponding desensitization processing according to a predefined desensitization strategy to obtain a desensitized data view; S55: Output the desensitized data view for access by the requesting party to ensure that data access complies with departmental authority requirements and security policy regulations; the above steps achieve secure transmission and precise access control of sensitive government data through clear routing positioning and precise desensitization processing based on authority tags, significantly reducing the risk of sensitive information leakage and improving the security and compliance of government information.

[0031] S54 specifically includes: S541: Traverse the dynamic data view in S53, check the permission tags of each sensitive field one by one, filter out sensitive fields with a read permission tag of 0 or a write permission tag of 0 in the permission tag, and mark them as fields to be desensitized; S542: Retrieve corresponding desensitization rules from a predefined desensitization policy library based on the field type and permission tag of the field to be desensitized, including defining a replacement method, truncation length, or mask format for the field value; Specifically, if the desensitization rule is mask replacement, the field value is replaced according to the predefined mask format. The mask replacement rule is expressed as: ;in, It is the mask of the desensitized field; is the mask character; The original length of the field value; If the desensitization rule is character truncation, the field value is truncate to a fixed length. The truncation rule is expressed as: ,in, The desensitized field value. is the original field value; The length of the characters retained after truncation; If the desensitization rule is null value replacement, the field value is directly set to null; S543: Update the desensitized field value to the dynamic data view to complete the desensitization operation. The above steps implement the corresponding desensitization strategy for different permission scenarios to achieve accurate processing of sensitive data, prevent unauthorized information leakage, and improve the security and privacy protection level in the process of government data access.

[0032] S6 specifically includes: S61: When a new department writes data to the government database, the department security level corresponding to the new department is obtained as the initial security level for the current data writing operation; S62: Determine the value of the inherited flag bit in the original sensitivity label of the data to be written; if the value of the inherited flag bit is true, proceed to the next step; otherwise, directly use the new department classification level as the final classification level of the new sensitivity label; S63: If the inherited flag is true, extract the data confidentiality level in the original data label, compare it with the current department confidentiality level, and sort it in descending order of sensitivity; S64: Select the highest confidentiality level from the sorting results in S63 as the final confidentiality level of the superimposed new sensitivity label; S65: Based on the final confidentiality level determined in S64, the sensitivity label of the data is updated to complete the data writing operation. The above steps effectively ensure the continuity and accuracy of the sensitivity label of government data during the circulation process by clearly judging the genetic attributes of the original label and reasonably superimposing the department confidentiality level, avoiding the improper downgrade of data and improving the security and standardization of the data sharing process.

[0033] S63 specifically includes: S631: Obtain the confidentiality level value of the current written department and the confidentiality level value in the original data tag from the sensitivity level enumeration set; S632: Based on a predefined sensitivity level value mapping table, the obtained confidentiality level is converted into a corresponding level value. Specifically, the public level L1 corresponds to a level value of 1, the internal level L2 corresponds to a level value of 2, and the confidential level L3 corresponds to a level value of 3; S633: Compare the two level values ​​obtained in S632 and determine the level with the larger value as the confidentiality level value of the new label; S634: Reversely map the level value determined in S633 back to the corresponding sensitivity level enumeration as the final confidentiality level of the new sensitivity label; the above steps achieve the inheritance and reasonable superposition of data confidentiality levels through numerical confidentiality level comparison, ensure the continuity and security of sensitivity during data flow, and prevent the risk of data sensitivity degradation.

[0034] The present invention encompasses any alternatives, modifications, equivalents, and solutions that fall within the spirit and scope of the present invention. To provide a thorough understanding of the present invention, specific details are described in detail below in connection with the preferred embodiments of the present invention, but those skilled in the art will be able to fully understand the present invention without these detailed descriptions. Furthermore, to avoid unnecessary confusion regarding the essence of the present invention, well-known methods, processes, procedures, components, and circuits have not been described in detail.

[0035] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A cloud-based government information management method, characterized in that: The following steps are involved: S1: Add a sensitivity label to each piece of government data in the cloud storage layer. The sensitivity label includes the data confidentiality level and genetic marker bit; S2: Extract data from the government database and generate a dynamic data view with permission tags based on the department function code of the requesting department and the current business scenario code; S3: Combine the department function code and the business scenario code into a routing key and create a mapping table between the routing key and the data source address; S4: Obtain the requesting party's department function code, business scenario code, and target data identifier; S5: Query the mapping table in S3 based on the department function code and business scenario code in S4 to match the target data source. When reading data from the target data source, perform desensitization operations on sensitive fields based on the permission tags in the dynamic data view generated by S2. S6: When data is written by a new department, a new sensitivity label is generated based on the confidentiality level of the writing department. If the inherited flag bit of the original data is true, the data confidentiality level in the original label is superimposed with the current confidentiality level to form a new label.

2. A cloud-based government information management method according to claim 1, characterized in that: Said S1 specifically includes: S11: When government data is first stored in the cloud storage layer, the data source department determines the initial data classification level, which is selected from a predefined classification level enumeration set, including public level L1, internal level L2, and confidential level L3; S12: Setting a genetic flag bit according to the data subject type, wherein the genetic flag bit is a Boolean identifier , whose expression is: ; in, It is a genetic flag bit. When the Boolean value is 1, it means true, and 0 means false.

3. A cloud-based government information management method according to claim 1, characterized in that: The S2 specifically includes: S21: Generate initial query conditions based on the requesting department function code and business scenario code, and initiate a data query request to the government database through the database query engine; S22: Returning the original data set that meets the query conditions from the government database, and temporarily storing the original data set in a temporary buffer area; S23: Retrieving a field-level permission control rule that matches the requesting department function code and the business scenario code from the permission control policy library, wherein the permission control rule defines the read and write permissions for each field; S24: traverse the original data set in the temporary buffer area and generate a readable or writable permission mark for each field according to the field-level permission control rule obtained in S23; S25: Integrate the processed original data set and the permission tags of the corresponding fields to form a dynamic data view.

4. A cloud-based government information management method according to claim 3, characterized in that: The S23 specifically includes: S231: Based on the requesting department function code and business scenario code, generate the permission policy query key. The expression is: ,in, Query key for permission policy; Code the departmental function of the requesting department; Encode the current business scenario; It is a string concatenation operator; S232: Query key using permission policy ,retrieve the permission control policy library in a key-value matching manner to obtain the corresponding permission control rule index; S233: According to the permission control rule index, locate the field-level permission control rule record in the permission control policy library, load the read permission value and write permission value of each data field defined in the record, and form the permission control rule.

5. A cloud-based government information management method according to claim 1, characterized in that: The S3 specifically includes: S31: Obtain a unique data source address identifier for each government data source from a pre-configured government database registry; S32: Based on the functional code of the department to which each data source belongs and the serviceable business scenario code, a routing key is formed by combining and splicing them in a predefined order. The specific expression is: ,in, Represents the generated routing key; Indicates the department function code corresponding to the data source; Indicates the business scenario code applicable to the data source; Represents string concatenation operation; S33: Mapping the routing keys generated in S32 to the corresponding data source address identifiers one by one, generating a key-value pair mapping relationship table with the routing keys as the search index and the data source addresses as the mapping results; S34: The key-value pair mapping relationship table generated in S33 is stored in the cloud configuration center.

6. A cloud-based government information management method according to claim 1, characterized in that: The S4 specifically includes: S41: receiving a data access request submitted by a requester through a government service interface, including the requester's department identity authentication credentials, business call context information, and data target parameters; S42: Parse the identity authentication credentials submitted by the requester, combine them with the verification results of the unified identity authentication platform, and extract the department function code after authentication; S43: extracting the business scenario code from the business call context information, including the current operation type, the government process node or the triggering method; S44: extracting a target data identifier from the data target parameter set, including a data table number, a data object primary key, or a tag attribute; S45: The extracted department function code, business scenario code, and target data identifier are used as structured request meta-information for future use.

7. A cloud-based government information management method according to claim 1, characterized in that: The S5 specifically includes: S51: Combine the department function code and the business scenario code obtained in S4 into a request routing key in a predetermined sequence, and use the request routing key as an index key to query the routing key and data source address mapping relationship table generated in S3 to determine the target data source address; S52: Establish a data connection channel according to the target data source address, and read the original data from the target data source based on the target data identifier provided by S4; S53: Load the original data obtained from the target data source into the dynamic data view generated by S2, and identify the read and write permissions of sensitive fields based on the permission tags corresponding to each field; S54: For the sensitive fields identified as readable or unreadable in S53, perform corresponding desensitization processing according to a predefined desensitization strategy to obtain a desensitized data view; S55: Output the desensitized data view for access by the requesting party.

8. A cloud-based government information management method according to claim 7, characterized in that: The S54 specifically includes: S541: Traverse the dynamic data view in S53, check the permission tags of each sensitive field one by one, filter out sensitive fields with a read permission tag of 0 or a write permission tag of 0 in the permission tag, and mark them as fields to be desensitized; S542: Retrieve corresponding desensitization rules from a predefined desensitization policy library based on the field type and permission tag of the field to be desensitized, including defining a replacement method, truncation length, or mask format for the field value; Specifically, if the desensitization rule is mask replacement, the field value is replaced according to the predefined mask format; If the desensitization rule is character truncation, the field value is truncate to a fixed length; If the desensitization rule is null value replacement, the field value is directly set to null; S543: Update the desensitized field value to the dynamic data view to complete the desensitization operation.

9. A cloud-based government information management method according to claim 1, characterized in that: The S6 specifically includes: S61: When a new department writes data to the government database, the department security level corresponding to the new department is obtained as the initial security level for the current data writing operation; S62: Determine the value of the inherited flag bit in the original sensitivity label of the data to be written; if the value of the inherited flag bit is true, proceed to the next step; otherwise, directly use the new department classification level as the final classification level of the new sensitivity label; S63: If the inherited flag is true, extract the data confidentiality level in the original data label, compare it with the current department confidentiality level, and sort it in descending order of sensitivity; S64: Select the highest confidentiality level from the sorting results in S63 as the final confidentiality level of the superimposed new sensitivity label; S65: Based on the final confidentiality level determined in S64, the sensitivity label of the data is updated to complete the data writing operation.

10. A cloud-based government information management method according to claim 9, characterized in that: The S63 specifically includes: S631: Obtain the confidentiality level value of the current written department and the confidentiality level value in the original data tag from the sensitivity level enumeration set; S632: Based on a predefined sensitivity level value mapping table, the obtained confidentiality level is converted into a corresponding level value. Specifically, the public level L1 corresponds to a level value of 1, the internal level L2 corresponds to a level value of 2, and the confidential level L3 corresponds to a level value of 3; S633: Compare the two level values ​​obtained in S632 and determine the level with the larger value as the confidentiality level value of the new label; S634: Reversely map the level value determined in S633 back to the corresponding sensitivity level enumeration as the final confidentiality level of the new sensitivity label.

Images