A role-based dynamic desensitization rendering method and system for application presentation layer

Abstract

The application relates to the technical field of information security and data privacy protection, and discloses a role-based dynamic desensitization rendering method and system for an application display layer; the method is used for solving the problems of the traditional method, such as the lack of multi-role dynamic control, rule caliber consistency and centralized maintainability; the method is characterized in that: firstly, in the unified entrance, a work number, a role, a tenant, an environment and a sub-pool identifier are acquired in session initialization, and context is transparently transmitted; in the back end, a field path is generated by field strategy mapping in a response serialization stage, a display value field is output, and a desensitization metadata area carrying a rule version, an invalid time and verification information is generated; after the front end intercepts the response, the metadata integrity is verified, the rule version is inquired from a strategy center and aligned according to the role, the display value is replaced according to the field path and the priority during rendering, the rule inquiry adopts cache and expiration refreshing, the strategy center supports gray release, rollback and audit trace.

Description

Technical Field

[0001] This invention relates to the field of information security and data privacy protection technology, specifically to a method and system for dynamic desensitization rendering of application presentation layers based on roles. Background Technology

[0002] In business scenarios such as telecommunications, finance, government affairs, and healthcare, application systems need to provide sensitive data such as user identity information, contact information, account information, and addresses to personnel in different positions, including customer service, operations, risk control, and auditing, for verification and processing. Due to differences in job responsibilities and permissions, the same field often has different visibility requirements under different roles. For example, some roles only need to view the anonymized display value to complete verification, while a few high-privilege roles are only allowed to view the complete plaintext under compliant authorization conditions. If plaintext data is directly rendered at the page display layer, it is easily obtained on the terminal side through methods such as screenshots, screen recordings, browser debugging tools, malicious script injection, and cached storage, which can lead to internal unauthorized access, unauthorized propagation, and compliance risks. At the same time, secondary propagation links such as exporting, printing, and copying can also amplify the impact of leakage, making it difficult to audit accountability and risk closure. In existing technologies, common data masking methods mainly include database-level masking, backend interface-level masking, and frontend script masking. Database-level masking often alters the underlying data structure, affecting data analysis, traceability verification, and cross-business reuse. It also makes it difficult to dynamically switch the display granularity based on the access role on the same data source. Backend interface-level masking typically requires writing customized logic on each interface or business object. As the number of fields and pages increases, issues such as duplicate rules, inconsistent definitions, and scattered configurations that are difficult to manage uniformly arise. Furthermore, in complex response bodies such as nested objects and array lists, rule matching and performance overhead are more difficult to control. While frontend script masking offers flexible deployment, the masking logic and strategies are exposed to the client environment, posing a risk of being bypassed or tampered with. If metadata or strategies are maliciously modified, sensitive fields may be displayed incorrectly or masking may fail. Additionally, in weak network conditions or when the policy center is unavailable, the lack of consistency verification and degradation mechanisms can easily lead to abnormal page rendering or display misalignment. Therefore, the industry urgently needs a more suitable approach to protect sensitive information on the display side for engineering implementation. This approach should be able to dynamically determine de-identification rules based on roles and consistently render complex response bodies without increasing the coupling of business code. It should also have capabilities such as centralized rule management, versioned release and rollback, conflict priority handling, policy distribution cache consistency, integrity verification, and audit trails. This would reduce the risk of plaintext exposure and secondary propagation on the terminal side and improve the compliance and maintainability of sensitive data display in multiple roles and scenarios. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a role-based dynamic desensitization rendering method and system for application presentation layers. It solves the problems of traditional methods in terms of multi-role dynamic control, consistency of rule definitions and centralized maintainability, as well as the ease with which the front end can bypass the method, leading to plaintext exposure and difficulties in auditing and tracing.

[0004] To reduce the risk of plaintext exposure on terminals and improve compliance and maintenance efficiency, this invention provides the following technical solution: A method for dynamic, role-based desensitization rendering of application presentation layers includes: S1: Obtain the login ID and role information corresponding to the access request, establish a session identifier and environment identifier, and write them into the request context; S2: When generating a business response, the backend marks the response fields according to the field policy mapping, forming the field path, policy identifier, and version information, and returns them along with the response; S3: The front end intercepts the response and parses the field path and policy identifier, initiates a rule query to the policy center according to the role, and completes the version consistency verification. S4: During the page binding and rendering phase, replace the display value of the corresponding field according to the rules described above. When multiple rules are encountered for the same field, they are selected in order of priority. S5: Rule retrieval and updates adopt a caching and expiration refresh mechanism, and rule release is carried out in a pooled and tenanted environment according to the gray-scale and rollback process.

[0005] In a preferred embodiment, the process includes obtaining the login ID and role information corresponding to the access request, establishing a session identifier and an environment identifier, and writing them into the request context, including: Verify login credentials and parse employee ID based on authentication service verification parameters; The system queries the permissions service to obtain the roles and permissions of tenants, reads the configuration to determine the environment, and generates session and link identifiers. The pool is determined by the gray list of employee IDs. In case of an anomaly, the central pool is used by default. The context is injected and verified through the gateway. The backend only receives the gateway source and records the audit.

[0006] In a preferred embodiment, when generating the business response, the backend marks the response fields according to the field policy mapping, forming the field path, policy identifier, and version information, which are returned along with the response, including: Serialization interception reads tenant, environment, pool, role and session link and locks the rule version, and retrieves policy entries by field policy mapping table; Iterate through the response object to generate field paths and match strategies by root object segment, hierarchical segment and array segment. Annotations only supplement missing strategies and take priority by version and scope of effect. The de-identified fields on the client side are displayed as paths, while the original values ​​are stored on the server side. The de-identified metadata area contains the rule version and verification information.

[0007] In a preferred embodiment, the frontend intercepts the response and parses the field path and policy identifier, initiates a rule query to the policy center according to the role, and completes version consistency verification, including: Verify the de-identified metadata based on the tenant and environment loading validation parameters; if it fails, discard it and skip the query. Determine the policy center route by tenant, environment and pool, generate cache keys by role and rule version, retrieve cache if version matches, otherwise merge queries and align by metadata version; Rules are written to the cache and the earliest expiration time is used; field path association rules are written to the response context.

[0008] In a preferred embodiment, during the page binding and rendering phase, the display value of the corresponding field is replaced according to the rules. When multiple rules for the same field are encountered, they are selected in order of priority, including: During the rendering phase, the display value field is located according to the field path. The rule object is first taken from the response context. If it is missing, the version is checked and then the rule is retrieved from the cache. If the version is not consistent with the rule, it will not be replaced. When multiple rules correspond to the same field, the effective rule is determined according to priority and conflict order. In case of conflict, the rule is selected according to the scope of effect and rule version. If no rule can be selected, it is not replaced. Replace the displayed values ​​with the visibility mode and mask parameters and write them to the view data source. Do not store the original values. Export the view data and record the link identifier and rule version.

[0009] In a preferred embodiment, rule retrieval and updates employ a caching and expiration refresh mechanism, and rule publishing is carried out in a pooled and tenant-specific environment using a canary and rollback process, including: Generate cache keys based on tenant, environment, pool, role summary, policy set summary, and rule version. If the versions are consistent and the expiration time has not yet expired, retrieve the cache; otherwise, merge the query and refresh according to the returned expiration time. Render the transaction locking rule version; do not replace it if it cannot be aligned or if there is no available cache. The strategy center first distributes gray-scale pools according to version flow and then distributes them according to the list of employee IDs. After verification, it rolls out to the main pool. In case of an anomaly, it switches back according to the version pointer and triggers a re-check and alignment. Rules are partitioned by tenant and environment and isolated by pool. Incremental updates are synchronized to the cache, and missing rules are loaded from the source and periodically corrected.

[0010] On the other hand, a role-based dynamic desensitization rendering system for application presentation layers includes: Enterprise unified entry and WEB touchpoint layer module: Receives access requests and verifies login status, parses employee ID to generate session and link identifiers, routes by grayscale list, and transmits context such as tenant environment pooling to the backend; Permissions Service Module: Returns the set of roles, organization affiliation, and permission list corresponding to the logged-in employee ID, providing a basis for policy matching and supporting role-based differentiated de-identified display; Gateway pass-through module: responsible for context field injection, validation and pass-through. The backend only receives the gateway context to ensure link consistency and traceability. Backend business service and response serialization interception module: Maps and marks paths according to field policies and generates de-identified metadata. The client only displays the field output values, while the original values ​​are retained in a controlled manner on the backend. Field policy mapping table and desensitized metadata specification module: associates field paths with policy identifiers, sensitivity levels, data types, versions, and validity periods, and standardizes the path expression and field set of desensitized metadata; Strategy Center Module: Maintains the relationship between policies and roles, supports inheritance and priority conflict handling, and provides versioned canary release, rollback and tenant environment isolation; Front-end de-identified rendering engine module: intercepts the response in the unified request component, parses the de-identified metadata, queries and verifies the strategy by session and version, and replaces the displayed value by field path during rendering, prohibiting the original value from being displayed. The caching and expiration refresh module prioritizes querying the cache and refreshes it upon expiration, reducing requests and stabilizing the rendering process. It uses a cache layer to handle queries and ensures consistency through incremental and full synchronization. Rule storage and synchronization module: Entity stores versioned rules, cache layer handles queries, incremental synchronization of rule changes, automatic loading of missing cache, periodic full synchronization correction and traceability; The canary release and rollback module: It performs canary release verification by worker number in the canary pool. If it passes the verification, it is rolled to the main pool in the order of the pools. If there is an error, it is rolled back and the version pointer is synchronized. Audit and Alarm Module: Records the display format, rule version, and link identifier of sensitive fields accessed by roles, and associates them with policy changes and abnormal alarms to form a traceable chain of evidence.

[0011] Compared with existing technologies, the present invention provides a method and system for dynamic desensitization rendering of application presentation layers by role, which has the following beneficial effects: 1. This invention, by solidifying contextual terms such as employee ID, role, tenant, environment, and pool during the session initialization phase, allows the backend to generate de-identified metadata according to field paths and lock rule versions during response serialization interception. The client only receives data fields used for display, while the original values ​​are stored on the server in a controlled manner. After intercepting the response, the frontend first performs integrity and version verification, then queries the policy center for rules according to roles and adopts caching and expiration refresh mechanisms. When multiple rules exist for the same field, the effective rule is determined according to role inheritance relationship and priority. During the rendering phase, the display value is replaced according to the field path without storing the original value. The policy center supports canary release and rollback by tenant, environment, and pool, and forms a closed-loop management system combined with auditing and alarms, thereby achieving de-identification protection with dynamic control over sensitive fields of multiple roles, consistent display terms, and full-link traceability.

[0012] 2. This invention extracts the masking control from the page code into a versionable configuration through a field strategy mapping table, and marks the response fields according to a unified field path during the backend serialization stage. This allows the frontend to locate and replace the displayed value according to the field path without needing to be aware of the internal structure of the business object. At the same time, it introduces rule version locking, cache refresh driven by expiration time, and pooled canary release and rollback mechanism. This allows rule changes to be verified step by step in different tenants, different environments and different pools and switched in a controlled manner according to the version. This reduces the inconsistency of front-end and back-end paths and the uncertainty of online changes caused by rule drift. Thus, it realizes centralized governance of masking rules, controllable release of changes and consistent execution across platforms for display-side masking management. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of a method for dynamic desensitization rendering of application presentation layers by role according to the present invention; Figure 2 This is a schematic diagram of the structure of a role-based dynamic desensitization rendering system for application presentation layers according to the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0015] Example 1: Figure 1 A role-based dynamic desensitization rendering method for application presentation layers is presented, including: S1: Obtain the login ID and role information corresponding to the access request, establish a session identifier and environment identifier, and write them into the request context; S2: When generating a business response, the backend marks the response fields according to the field policy mapping, forming the field path, policy identifier, and version information, and returns them along with the response; S3: The front end intercepts the response and parses the field path and policy identifier, initiates a rule query to the policy center according to the role, and completes the version consistency verification. S4: During the page binding and rendering phase, replace the display value of the corresponding field according to the rules described above. When multiple rules are encountered for the same field, they are selected in order of priority. S5: Rule retrieval and updates adopt a caching and expiration refresh mechanism, and rule release is carried out in a pooled and tenanted environment according to the gray-scale and rollback process.

[0016] S1: Obtain the login ID and role information corresponding to the access request, establish a session identifier and environment identifier, and write them into the request context. The specific implementation is as follows: When a user accesses a business page through the unified enterprise portal, the WEB touchpoint layer performs session initialization processing, receives the login credentials carried by the browser, and verifies the validity period and signature information of the credentials based on the verification parameters issued by the authentication service. If the verification fails, the session initialization is terminated and the user is returned to an unlogged-in state. If the verification passes, the credentials are parsed to obtain the login ID. The touchpoint layer uses the login ID to query the permission service to obtain the role set, organization affiliation identifier, permission list, and tenant identifier. The tenant identifier is used to distinguish the rule spaces of different tenants. Subsequently, the touchpoint layer reads the environment parameters from the configuration center according to the tenant identifier and determines the environment identifier. At the same time, it generates a session identifier and a link identifier. The link identifier is used to associate with subsequent interface calls, policy center queries, and audit records. The touchpoint layer loads canary deployment rules according to the deployment configuration of the pool and tenant. The deployment rules use the employee ID list as the judgment condition. If the employee ID matches the list, the session is routed to the canary pool; otherwise, it is routed to the central pool. If the canary configuration is unavailable or the local cache expires and has not been refreshed, the session is routed to the central pool by default. The touchpoint layer summarizes the login employee ID, role set, organization identifier, permission list, tenant identifier, environment identifier, pool identifier, session identifier, and link identifier to form a request context, which is then passed through the gateway to the backend interface. The gateway performs injection or validation on the context fields. The backend only receives the context fields from the gateway and performs format and consistency checks on the session identifier and link identifier before writing them into the server context. The touchpoint layer records access audit logs based on the link identifier, and the logs are associated with the employee ID, tenant, environment, pool, session, link, and interface identifier. During the response serialization stage, the backend reads the tenant, environment, pool, and role information from the server context for field policy mapping and de-identified metadata marking. During the response interception stage, the frontend reuses the session identifier and link identifier to initiate a rule query to the policy center.

[0017] S2: When generating the business response, the backend marks the response fields according to the field policy mapping, forming the field path, policy identifier, and version information, which are returned along with the response. Specifically, the implementation is as follows: After the backend completes business data query and object assembly, it enters the response serialization interception stage. It reads tenant, environment, pool, and role information from the server request context to determine the field policy scope used in this response. At the same time, it reads the session identifier and link identifier to associate the response marker with the access link. The backend loads policy entries from the field policy mapping table according to the tenant and environment and locks the rule version. The field policy mapping table is configured and published by the management end and is version managed. The table maintains the correspondence between field path and policy identifier, sensitivity level, data type, effective scope, and expiration time. The locked rule version is written as the version scope of this response to the de-identified metadata area and returned with the response. The serialization component performs a structural traversal of the object to be returned, generating locatable field paths according to the unified field path rules of the front-end and back-end. Each field path consists of the response root object name, attribute hierarchy segment, and array position segment. The attribute hierarchy segment expands according to the object nesting order, and the array position segment is generated according to the element's position in the array or list. The serialization component matches the field path in the field policy mapping table. When a match is found, a desensitized metadata record is generated. This record includes the field path, policy identifier, sensitivity level, data type, effective scope, and expiration time, as well as session and link identifiers for association. When a field declares desensitized attributes via annotations, the serialization component reads the annotation parameters and merges them with the mapping table entries. Annotations are used to supplement missing policy identifiers in the mapping table but not to overwrite already effective entries. During the merging process, priority entries are first determined by rule version, then by effective scope. If conflicts still exist, the mapping table entries take precedence. When a field is marked as a field whose anonymized value is only displayed on the client side, the serialization component writes the corresponding display value field into the external output structure and places the display value field into the corresponding hierarchical position according to the field path rules, so that the front end can complete the location based on the field path; the original field value is not included in the external serialization result, but is only retained in the server-side memory object or server-side context for backend verification and business processing, and is not written to the external response extension area or external logs; in the case of nested objects or batch list output scenarios, the display value field is output synchronously with the object hierarchy, and the array position segment is consistent with the actual position of the element to maintain the stability of the field path positioning relationship; After serialization interception, the backend aggregates the de-identified metadata records into a de-identified metadata area, writes it to the extension area of ​​the response root node, and writes the rule version, generation timestamp, and integrity verification information corresponding to this response. The integrity verification information is generated based on the current tenant and environment configuration, obtaining verification parameters from the authentication service or configuration center, and overwriting key fields such as field paths, policy identifiers, rule versions, and expiration times in the de-identified metadata area. After receiving the response, the frontend extracts the field paths, policy identifiers, and rule versions from the de-identified metadata area, initiates a rule query to the policy center, completes alignment verification according to the rule version, and verifies the integrity verification information.

[0018] S3: The frontend intercepts the response and parses the field path and policy identifier, initiates a rule query to the policy center according to the role, and completes version consistency verification. The specific implementation is as follows: During application initialization, the frontend configures response interception for the unified network request component and loads integrity verification parameters from the configuration center according to tenant and environment. After the interface response is returned, the interception logic reads the de-identified metadata area of ​​the response root node and extracts field paths, policy identifiers, rule versions, expiration times, generation timestamps, and integrity verification information. The frontend verifies the de-identified metadata area based on the integrity verification parameters, covering key fields such as field paths, policy identifiers, rule versions, and expiration times. If the verification fails, the de-identified metadata area is discarded and the policy center query is skipped, and the page renders the displayed value fields according to the default display rules. After the verification passes, the de-identified metadata is merged and deduplicated according to the policy identifier, the policy identifier set is sorted in a fixed order, and a policy identifier set summary is generated for subsequent cache matching and rule version alignment. The frontend reads the login ID, role set, tenant, environment, pool, session identifier, and link identifier from the session context, and determines the access address and routing partition of the policy center based on the tenant, environment, and pool. The frontend generates a cache key using the tenant, environment, pool, role set summary, policy identifier set summary, and rule version, and prioritizes reading the rule object from the local memory cache. If the cache is not expired and the cache version matches the rule version, the cached result is used directly; otherwise, an online query is initiated. The online query request carries the login ID, role set, tenant, environment, pool, policy identifier set, rule version, session identifier, and link identifier, and concurrent queries with the same cache key are merged. If the online query fails, a cached rule object with the same version and not expired is used first. If no available cache is available, the displayed value fields are rendered according to the default display rules. After the strategy center returns the rule details, the front end performs alignment verification according to the rule version. If the versions are inconsistent, the query is re-initiated based on the rule version carried in the de-identified metadata area. If alignment still fails, the page renders the display value fields according to the default display rules. If the versions are consistent, the rule details are converted into rule objects. The rule objects record the strategy identifier, visibility mode, mask parameters, role inheritance relationship, priority, and conflict handling order. The front end writes the rule objects to the local memory cache and sets an expiration time. The expiration time is the earlier of the expiration time of the strategy center's return value and the de-identified metadata area. At the same time, the rule version and link identifier are recorded for location and audit association. After the cache is written, the reference relationship between the field path and the rule object is written to the data context of this response, so that the display value fields can be located and replaced according to the field path in the subsequent data binding and component rendering stages.

[0019] S4: During the page binding and rendering phase, the display values ​​of the corresponding fields are replaced according to the rules described above. When multiple rules are encountered for the same field, they are selected in order of priority. The specific implementation is as follows: After the front-end completes the rule query and establishes the rule object reference relationship, it takes the interface response data, the de-identified metadata area and the rule object reference table as inputs to the same rendering process and enters the page data binding and component rendering stage; when rendering starts, a rendering context is established, the de-identified metadata area and the rule object reference table are associated with the rendering context, and the link identifier is retained for rendering audit association; The rendering engine locates the display value fields item by item according to the field paths registered in the de-identified metadata area. The field paths are parsed according to attribute level segments and array position segments. The display value fields are generated and output by the backend in the response structure according to the field path rules. The rendering engine locates the corresponding display value fields according to the same rules and uses them as writable targets. The rendering engine first reads the rule object corresponding to the field path from the data context of this response. If the rule object is missing, the rule details are retrieved from the local memory cache according to the policy identifier, and the version of the retrieved rule is verified to be consistent with the version carried in the de-identified metadata area. If a rule object with a consistent version cannot be obtained, no replacement is performed, and the page completes the rendering according to the current value of the display value field. When a field path corresponds to multiple rule objects, the rendering engine selects the effective rule based on the priority and conflict handling order within the rule objects. In cases of conflicting priorities, the effective scope is compared first, followed by the rule version. The effective scope information is written to the rule object along with the rule details returned by the strategy center. If the determination still cannot be made, the default display path is used. After determining the effective rule, the rendering engine replaces the display value field according to the visibility mode and writes the replacement result to the view layer rendering data structure. When the visibility mode is full display, the original value of the display value field is preserved. When the visibility mode is partial display, a partial replacement is performed according to the mask parameter, which indicates the reserved segment and mask character. When the visibility mode is not display, the display value field is replaced with a fixed mask placeholder value. During the replacement process, only the view layer rendering data structure is updated; no data is written to local persistent storage, no output to the front-end log interface, no original value is written to the export data source, and no original value field corresponding to the back-end controlled field form is written. During export, the view layer rendering data structure is used as the data source, and the original response body is not referenced. After the rendering transaction is completed, the view layer uses the replaced rendering data structure as the data source for component binding, and subsequent page interactions and component re-rendering directly reuse this data structure; the rendering engine records the set of processed field paths, rule versions and link identifiers, writes them to the front-end rendering audit log, and establishes a correlation with the version switching records during rule refresh and canary release processes.

[0020] S5: Rule retrieval and updates employ a caching and expiration refresh mechanism. Rule deployment is carried out in a pooled and tenant-specific environment using a canary and rollback process. The specific implementation is as follows: After loading the rule objects required for rendering, the frontend sets the policy center rule query to local cache priority mode. The frontend generates a cache key using the tenant, environment, pool, role set summary, policy identifier set summary, and rule version. The policy identifier set is sorted in a fixed order before generating the summary. Cache entries record the rule version and expiration time; if the version is consistent and the expiration time has not yet arrived, the cache is used directly. If a match is not found or the conditions are not met, an online query is initiated to the policy center, requesting the login ID, role set, tenant, environment, pool, policy identifier set, rule version, session identifier, and link identifier. Both expired and refreshed requests are merged according to the cache key. Only one in-transit request is retained for the same cache key, and the results of other requests are reused. After the strategy center returns the rule details, the front end aligns according to the rule version. When a match is found, the result is written to the cache, and the returned expiration time is used as the refresh basis. When there is no match, the default display path is entered, and the display value is not replaced. When the cache expires, a refresh is triggered. After the refresh, the version is matched to determine whether to replace the cache. If the version has not changed, the original entry is retained. Rendering transactions are locked based on the rule version. The refresh only affects subsequent requests. When the refresh fails, the non-expired cache is used first. If no cache is available, the default display path is entered. The strategy center implements versioned management for rule releases. After the management side submits a rule change, the strategy center generates a new rule version and records the version flow. The new version rule is first distributed to the rule space corresponding to the grayscale pool. During the grayscale verification phase, a specified worker ID routing strategy is adopted. The grayscale worker ID list is maintained and distributed by the management side. The WEB touchpoint layer loads and caches this list according to the tenant and environment. When initializing the session routing, the login worker ID is matched. Requests that match the list are routed to the grayscale pool, allowing the front-end rule query to obtain the new version rule. Requests that do not match the list are routed to the main pool and continue to be used. Stable version rules: After successful gray-scale verification, the strategy center rolls out the rules to the main pool in pool order. During the rollout, the rule cache pointers in the pools are updated first, and then the service configuration is switched to make the new version effective externally, ensuring that the rule query chain is not interrupted during the release. If an anomaly occurs during release or verification, the strategy center switches back to the previous stable version based on the version record and updates the version pointers of the gray-scale pool and the main pool synchronously. If the front end detects that the version returned by the strategy center is inconsistent with the version in the de-identified metadata area after the rollback, the rule query is re-initiated according to the version alignment logic until a stable version rule is obtained. To achieve rule space isolation, the policy center partitions and stores rules according to tenant and environment dimensions. Different tenants or environments use independent namespaces and version pipelines. Within a namespace, rules are further differentiated into gray-scale pools and main pools based on pooling. Rule storage employs incremental near-real-time synchronization and periodic full synchronization mechanisms. Entity databases, such as MySQL, serve as the source of versioned rules, while caching layers, such as Redis, serve as the carrier for rule queries. When a rule is added or changed, the policy center synchronizes the incremental changes to the caching layer. When the caching layer lacks target rule data, the corresponding rule is loaded from the entity database and written to the caching layer. Periodic full synchronization is used to perform consistency correction on the caching layer and retain version traceability records. In subsequent accesses, the frontend uses the rule version carried in the de-identified metadata area to complete version alignment and rule retrieval, thereby obtaining a traceable and stable source of rules under tenant-specific, environment-specific, and pool-specific conditions.

[0021] In this embodiment, when a user accesses a business page through the unified enterprise portal, the WEB touchpoint layer verifies the login credentials and parses the login ID. It then obtains the role set, permission list, and tenant identifier from the permission service, determines the environment identifier and pool identifier, generates a session identifier and a link identifier, and writes them into the request context. This is then passed through the gateway to the backend. During the response serialization interception phase, the backend loads field policy mappings according to the tenant and environment and locks the rule version. It traverses the response object to generate field paths, forming a desensitized metadata area containing field paths, policy identifiers, rule versions, expiration times, and integrity verification information, which is returned with the response. Simultaneously, the client only displays the field output display value field. After intercepting the response, the frontend verifies the integrity of the desensitized metadata, merges it according to the policy identifier, and queries the policy center for rules based on the rule version. After version alignment, it writes the data into the cache and establishes a reference relationship between the field path and the rule object. During the rendering phase, the display value field is located according to the field path, and the display value is replaced according to the visibility mode and priority and written into the view layer data structure. Both export and storage use the replaced data. Rule queries prioritize caching and refresh upon expiration. The policy center performs versioned canary releases and rollbacks by tenant, environment, and pool, forming a traceable closed loop for de-identified display.

[0022] Example 2: Figure 2 A role-based dynamic desensitization rendering system for application presentation layers is presented, including: Enterprise unified entry and WEB touchpoint layer module: Receives access requests and verifies login status, parses employee ID to generate session and link identifiers, routes by grayscale list, and transmits context such as tenant environment pooling to the backend; Permissions Service Module: Returns the set of roles, organization affiliation, and permission list corresponding to the logged-in employee ID, providing a basis for policy matching and supporting role-based differentiated de-identified display; Gateway pass-through module: responsible for context field injection, validation and pass-through. The backend only receives the gateway context to ensure link consistency and traceability. Backend business service and response serialization interception module: Maps and marks paths according to field policies and generates de-identified metadata. The client only displays the field output values, while the original values ​​are retained in a controlled manner on the backend. Field policy mapping table and desensitized metadata specification module: associates field paths with policy identifiers, sensitivity levels, data types, versions, and validity periods, and standardizes the path expression and field set of desensitized metadata; Strategy Center Module: Maintains the relationship between policies and roles, supports inheritance and priority conflict handling, and provides versioned canary release, rollback and tenant environment isolation; Front-end de-identified rendering engine module: intercepts the response in the unified request component, parses the de-identified metadata, queries and verifies the strategy by session and version, and replaces the displayed value by field path during rendering, prohibiting the original value from being displayed. The caching and expiration refresh module prioritizes querying the cache and refreshes it upon expiration, reducing requests and stabilizing the rendering process. It uses a cache layer to handle queries and ensures consistency through incremental and full synchronization. Rule storage and synchronization module: Entity stores versioned rules, cache layer handles queries, incremental synchronization of rule changes, automatic loading of missing cache, periodic full synchronization correction and traceability; The canary release and rollback module: It performs canary release verification by worker number in the canary pool. If it passes the verification, it is rolled to the main pool in the order of the pools. If there is an error, it is rolled back and the version pointer is synchronized. Audit and Alarm Module: Records the display format, rule version, and link identifier of sensitive fields accessed by roles, and associates them with policy changes and abnormal alarms to form a traceable chain of evidence.

[0023] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for dynamic desensitization rendering of application presentation layers based on roles, characterized in that, include: S1: Obtain the login ID and role information corresponding to the access request, establish a session identifier and environment identifier, and write them into the request context; S2: When generating a business response, the backend marks the response fields according to the field policy mapping, forming the field path, policy identifier, and version information, and returns them along with the response; S3: The front end intercepts the response and parses the field path and policy identifier, initiates a rule query to the policy center according to the role, and completes the version consistency verification. S4: During the page binding and rendering phase, replace the display value of the corresponding field according to the rules described above. When multiple rules are encountered for the same field, they are selected in order of priority. S5: Rule retrieval and updates adopt a caching and expiration refresh mechanism, and rule release is carried out in a pooled and tenanted environment according to the gray-scale and rollback process.

2. The method for dynamic desensitization rendering of application presentation layers according to claim 1, characterized in that, Obtain the login ID and role information corresponding to the access request, establish a session identifier and environment identifier, and write them into the request context, including: Verify login credentials and parse employee ID based on authentication service verification parameters; The system queries the permissions service to obtain the roles and permissions of tenants, reads the configuration to determine the environment, and generates session and link identifiers. The pool is determined by the gray list of employee IDs. In case of an anomaly, the central pool is used by default. The context is injected and verified through the gateway. The backend only receives the gateway source and records the audit.

3. The method for dynamic desensitization rendering of application presentation layers according to claim 1, characterized in that, When generating the business response, the backend marks the response fields according to the field policy mapping, forming the field path, policy identifier, and version information, which are returned along with the response, including: Serialization interception reads tenant, environment, pool, role and session link and locks the rule version, and retrieves policy entries by field policy mapping table; Iterate through the response object to generate field paths and match strategies by root object segment, hierarchical segment and array segment. Annotations only supplement missing strategies and take priority by version and scope of effect. The client-side de-identified fields output display values ​​according to the path, the original values ​​are retained on the server, and the de-identified metadata area is written with the rule version and verification information.

4. The method for dynamic desensitization rendering of application presentation layers according to claim 1, characterized in that, The frontend intercepts the response and parses the field path and policy identifier, initiates a rule query to the policy center according to the role, and completes version consistency verification, including: Verify the de-identified metadata based on the tenant and environment loading validation parameters; if it fails, discard it and skip the query. Determine the policy center route by tenant, environment and pool, generate cache keys by role and rule version, retrieve cache if version matches, otherwise merge queries and align by metadata version; Rules are written to the cache and the earliest expiration time is used; field path association rules are written to the response context.

5. A method for dynamic desensitization rendering of application presentation layers according to claim 1, characterized in that, During the page binding and rendering phase, the display values ​​of the corresponding fields are replaced according to the rules described above. When multiple rules are encountered for the same field, they are selected in order of priority, including: During the rendering phase, the display value field is located according to the field path. The rule object is first taken from the response context. If it is missing, the version is checked and then the rule is retrieved from the cache. If the version is not consistent with the rule, it will not be replaced. When multiple rules correspond to the same field, the effective rule is determined according to priority and conflict order. In case of conflict, the rule is selected according to the scope of effect and rule version. If no rule can be selected, it is not replaced. Replace the displayed values ​​with the visibility mode and mask parameters and write them to the view data source. Do not store the original values. Export the view data and record the link identifier and rule version.

6. The method for dynamic desensitization rendering of application presentation layers according to claim 1, characterized in that, Rule retrieval and updates employ a caching and expiration refresh mechanism. Rule deployment is carried out in a pooled and tenant-specific environment using a canary rollout process, including: Generate cache keys based on tenant, environment, pool, role summary, policy set summary, and rule version. If the versions are consistent and the expiration time has not yet expired, retrieve the cache; otherwise, merge the query and refresh according to the returned expiration time. Render the transaction locking rule version; do not replace it if it cannot be aligned or if there is no available cache. The strategy center first distributes gray-scale pools according to version flow and then distributes them according to the list of employee IDs. After verification, it rolls out to the main pool. In case of an anomaly, it switches back according to the version pointer and triggers a re-check and alignment. Rules are partitioned by tenant and environment and isolated by pool. Incremental updates are synchronized to the cache, and missing rules are loaded from the source and periodically corrected.

7. A role-based dynamic desensitization rendering system for application presentation layers, used to implement the role-based dynamic desensitization rendering method for application presentation layers as described in any one of claims 1-6, characterized in that, include: Enterprise unified entry and WEB touchpoint layer module: Receives access requests and verifies login status, parses employee ID to generate session and link identifiers, routes by grayscale list, and transmits context such as tenant environment pooling to the backend; Permissions Service Module: Returns the set of roles, organization affiliation, and permission list corresponding to the logged-in employee ID, providing a basis for policy matching and supporting role-based differentiated de-identified display; Gateway pass-through module: responsible for context field injection, validation and pass-through. The backend only receives the gateway context to ensure link consistency and traceability. Backend business service and response serialization interception module: Maps and marks paths according to field policies and generates de-identified metadata. The client only displays the field output values, while the original values ​​are retained in a controlled manner on the backend. Field policy mapping table and desensitized metadata specification module: associates field paths with policy identifiers, sensitivity levels, data types, versions, and validity periods, and standardizes the path expression and field set of desensitized metadata; Strategy Center Module: Maintains the relationship between policies and roles, supports inheritance and priority conflict handling, and provides versioned canary release, rollback and tenant environment isolation; Front-end de-identified rendering engine module: intercepts the response in the unified request component, parses the de-identified metadata, queries and verifies the strategy by session and version, and replaces the displayed value by field path during rendering, prohibiting the original value from being displayed. The caching and expiration refresh module prioritizes querying the cache and refreshes it upon expiration, reducing requests and stabilizing the rendering process. It uses a cache layer to handle queries and ensures consistency through incremental and full synchronization. Rule storage and synchronization module: Entity stores versioned rules, cache layer handles queries, incremental synchronization of rule changes, automatic loading of missing cache, periodic full synchronization correction and traceability; The canary release and rollback module: It performs canary release verification by worker number in the canary pool. If it passes the verification, it is rolled to the main pool in the order of the pools. If there is an error, it is rolled back and the version pointer is synchronized. Audit and Alarm Module: Records the display format, rule version, and link identifier of sensitive fields accessed by roles, and associates them with policy changes and abnormal alarms to form a traceable chain of evidence.

Images