Region compliance processing method and system and electronic equipment

Abstract

The invention relates to a region compliance processing method and system and electronic equipment, and the method comprises the steps: responding to a condition that a client meets a region recognition condition, and determining a target region identifier corresponding to a local region of the client; obtaining a region strategy corresponding to the target region identifier, wherein the region strategy comprises the target region identifier, a strategy version, a validity period and an allowed authentication mode; under the condition that the region strategy takes effect, obtaining a region token containing a target region identifier and a strategy version; loading an authentication module corresponding to an authentication mode allowed by the area strategy according to the effective area strategy; generating a service request carrying the area token based on the authentication module, and sending the service request to the gateway; the service request is used for enabling the gateway to execute region consistency verification according to the region token so as to route the service request to a region service cluster matched with the region token. According to the invention, cross-regional compliance operation can be realized on the same client and the same code baseline.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a regional compliance processing method, system, and electronic device. Background Technology

[0002] With the global deployment of internet products, the same product often faces different regulatory requirements and business environments when launched in different countries or regions. For example, different regions have different login authentication methods and data retention requirements.

[0003] In related technologies, to address regional compliance differences, a multi-application forking approach can be adopted, which involves maintaining independent application packages and code branches for different regions. However, this approach requires repeated development across multiple branches for every requirement change and security fix, resulting in high maintenance costs and low version iteration efficiency. Another approach uses a single application with fixed configurations, embedding all login methods in the client and controlling them through UI hiding or configuration switches. However, disallowed capabilities can still be exposed through reverse engineering or misconfiguration, thus expanding the attack surface and increasing compliance risks. Furthermore, existing solutions struggle to technically block cross-regional data access, leading to data security issues. Therefore, improving operational security for multi-region compliance under the same client and backend code baseline is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] In view of this, embodiments of this application provide a regional compliance processing method, system, and electronic device to solve at least one problem existing in the background art.

[0005] In a first aspect, embodiments of this application provide a regional compliance processing method, executed by a client, the method comprising: In response to the client meeting the region identification conditions, the target region identifier corresponding to the client's local region is determined; Obtain the regional policy corresponding to the target region identifier, wherein the regional policy includes the target region identifier, policy version, validity period, and allowed authentication methods; If the regional policy is in effect, obtain a regional token containing the target region identifier and the policy version; According to the effective regional policy, load the authentication module corresponding to the authentication method allowed by the regional policy; The authentication module generates a service request carrying the region token and sends the service request to the gateway; wherein the service request is used to enable the gateway to perform a region consistency check based on the region token, so as to route the service request to the region service cluster that matches the region token.

[0006] Secondly, embodiments of this application provide a regional compliance processing method, executed by a policy server, the method comprising: Generate and sign a regional policy, wherein the regional policy includes a target region identifier, policy version, validity period, and allowed authentication methods; wherein the allowed authentication methods are used to instruct the client to load the corresponding authentication module; The signed regional policy is then sent to the client in the corresponding region. Receive a token issuance request sent by the client, which carries the target area identifier and the policy version; The target region identifier and the policy version are verified, and after the verification is successful, a region token containing the target region identifier and the policy version is issued to the client so that the client carries the region token when initiating a service request based on the authentication module.

[0007] Thirdly, embodiments of this application provide a regional compliance processing method, executed by a gateway, the method comprising: Receive a service request sent by a client. The service request carries a regional token containing a target region identifier and a policy version of the regional policy. The service request is generated by the client according to the authentication module allowed to be loaded according to the regional policy. Perform a region consistency check based on the region token to route the service request to the region service cluster that matches the region token.

[0008] Fourthly, embodiments of this application provide a regional compliance processing method, executed by a regional service cluster, the method comprising: Receive service requests forwarded by the gateway, wherein the service request carries a regional token containing a target region identifier and a policy version of the regional policy, and the service request is generated by the client according to the authentication module allowed to be loaded according to the regional policy; If the service request is a registration request, a unique user identifier bound to the target region identifier and an access token containing the unique user identifier are generated and returned to the client, and the user data is written to the corresponding data storage resource according to the target region identifier. If the service request is a login request and also carries an access token, then extract the user's unique identifier from the access token and verify whether the target region identifier is consistent with the region identifier bound to the user's unique identifier. If they match, the service request is processed, and the user data generated during processing is written to the corresponding data storage resource according to the target area identifier. If there is a discrepancy, the business request will be rejected and an audit log will be generated.

[0009] Fifthly, embodiments of this application provide a regional compliance processing system, the system comprising: The client is configured to perform the regional compliance processing method as described in the first aspect; The policy server is configured to execute the regional compliance processing method as described in the second aspect; The gateway is configured to perform the regional compliance processing method as described in the third aspect; The regional service cluster is configured to perform the regional compliance processing method as described in the fourth aspect.

[0010] Sixthly, embodiments of this application provide an electronic device including a processor, the processor being configured to invoke instructions to cause the electronic device to execute the region compliance processing method provided in any of the foregoing aspects.

[0011] In a seventh aspect, embodiments of this application provide a storage medium having an executable program stored thereon, wherein the executable program, when executed by a processor, implements the region compliance processing method provided in any of the foregoing aspects.

[0012] This application provides a regional compliance processing method, system, and electronic device, which have at least the following technical effects: By determining the target region identifier corresponding to the client's local region, obtaining the corresponding region policy, and when the region policy is in effect, obtaining a region token containing the target region identifier and the version of the policy, and dynamically loading the authentication module allowed by the region policy on the client, the client only presents the authentication capabilities allowed in different regions. Therefore, the authentication capabilities that are not allowed will not be exposed on the client side, thereby reducing the attack surface and reducing the compliance risk caused by unauthorized functions being reverse-called. At the same time, it achieves cross-regional compliant operation on the same client and the same code baseline.

[0013] In addition, by generating a business request carrying a regional token based on the authentication module, the client sends the business request to the gateway. This regional token can provide a reliable basis for the gateway's routing decisions and consistency verification of the regional service cluster. In this way, cross-regional requests can be blocked early in the link, thereby reducing the probability of cross-regional read and write operations and improving data security. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the structure of the regional compliance processing system provided in the embodiments of this application; Figure 2 A flowchart illustrating a region compliance processing method executed by a client, as provided in an embodiment of this application; Figure 3 A schematic diagram illustrating the implementation process of client-side region identification and policy activation provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the implementation process of dynamic loading by the client provided in this application embodiment; Figure 5 A flowchart illustrating the regional compliance processing method executed by the policy server, as provided in this embodiment of the application; Figure 6 A schematic diagram illustrating the implementation process of strategy update, grayscale, and rollback provided in the embodiments of this application; Figure 7 A flowchart illustrating a region compliance processing method performed by a gateway, as provided in an embodiment of this application; Figure 8 This is a schematic diagram illustrating the implementation process of gateway routing and regional cluster selection provided in the embodiments of this application; Figure 9 A flowchart illustrating a regional compliance processing method executed by a regional service cluster, as provided in an embodiment of this application; Figure 10 A schematic diagram illustrating the implementation process of account primary key generation and physical data isolation provided in this application embodiment; Figure 11 This is a schematic diagram illustrating the interaction process of cross-regional access blocking and auditing provided in an embodiment of this application. Detailed Implementation

[0015] To make the technical solution and beneficial effects of this application more apparent and understandable, a detailed description is provided below by listing specific embodiments. The accompanying drawings are not necessarily drawn to scale, and local features may be enlarged or reduced to more clearly show the details of the local features; unless otherwise defined, the technical and scientific terms used herein have the same meanings as those in the technical field to which this application pertains.

[0016] The embodiments in this application are not exhaustive, but merely illustrative of some embodiments, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0017] In each embodiment of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of the embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0018] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0019] With the global deployment of internet products, the same product often faces different regulatory requirements and business environments when launched in different countries or regions. For example, login identifiers differ: some regions use email addresses as login identifiers, while others require or prefer mobile phone numbers, potentially involving local number range verification. Verification channels also differ: the availability and compliance requirements of SMS, email, push notifications, and one-time passwords vary across regions. Furthermore, user personal information, logs, audit data, and key materials may require storage and processing within a local area, prohibiting cross-regional access or synchronization.

[0020] In related technologies, to address regional compliance differences, one or a combination of the following methods can be used: Multi-application or multi-backend fork solution: Independent application packages or channel packages are released for different regions. The backend maintains independent service clusters and code branches for each region, and clients access the platform through different domains. Account systems and data storage are implemented separately in each region, with regional differences selected during deployment. When regional differences are implemented using this solution, authentication processes, risk control rules, and data processing logic will form multiple branches. Therefore, each requirement change and security fix requires repeated development and regression testing across multiple branches, leading to increased maintenance costs and a higher probability of differential defects.

[0021] The single-application, fixed-region selection scheme: The client provides a region selection switch or determines the access domain name solely based on system region settings; different login methods are simultaneously built into the client (both email address and phone number are present), controlled by UI hiding or configuration switches. The backend only performs simple domain name routing at the gateway layer, lacking region consistency verification. Because the client simultaneously has multiple built-in login and verification modules, controlled solely by UI or configuration switches, disallowed capabilities may still be reverse-engineered or misconfigured and exposed; thus expanding the attack surface and increasing compliance risks. Furthermore, due to the lack of region consistency verification when simply routing by domain name at the gateway layer, if tokens are replayed, routing is misconfigured, or the service mistakenly calls cross-region data sources, cross-region read / write operations may occur, further increasing compliance risks.

[0022] Multi-tenant data isolation solutions: Data isolation is performed based on tenant ID or business line ID, such as by sharding databases and tables by tenant, or by adding a tenant field to the shared database for access control. However, this solution is not equivalent to regional compliance isolation. The isolation object is mainly tenant, and the policy updates, canary deployments, and auditing links are scattered, making it difficult to ensure that different regions run under the same version of the policy. Therefore, policy consistency and traceability are insufficient.

[0023] To address the issues of compliance differences and cross-regional data access restrictions for the same internet product in different countries or regions, this application proposes a regional compliance processing method. This method centrally manages regional compliance policies and performs digital signatures on a policy server. Clients automatically select authentication capabilities based on the signature policy, enabling dynamic adaptation of multi-regional compliance for the same client under the same codebase. Compared to multi-application forking solutions, this effectively reduces maintenance costs. Furthermore, the client only loads policy-permitted functional modules; unauthorized functions are isolated at the code level, thus mitigating compliance risks. Gateways and regional service clusters perform regional consistency checks, blocking cross-regional requests early in the process, thereby reducing the probability of cross-regional read / write operations and improving data security.

[0024] To facilitate understanding, some of the terms used in this application will be explained first.

[0025] Region: An operating domain divided by country, region, or regulatory domain, such as China (CN), the European Union (EU), the United States (US), etc.

[0026] Regional signal: A set of information used to infer the region where the device is located, including SIM (Subscriber Identity Module) country code, IP address, system locale, time zone, historical cached region information, etc. The SIM country code may include MCC (Mobile Country Code) and MNC (Mobile Network Code).

[0027] Regional policy, also known as compliance policy, is a set of compliance and capability configurations defined for a specific region. It includes at least the allowed authentication methods (e.g., login identifier type, verification channel), data residency domain, routing rules, audit rules, policy version and validity period, etc.

[0028] Regional Compliance Policy Engine: A control plane service, i.e., a policy service, used to generate, distribute, and version manage regional policies, as well as to sign and perform canary release control of regional policies.

[0029] Region Token: An information carrier generated by the client or policy service, carrying the region identifier and policy version. It may include a signature, a random number, and an expiration date, and is used for backend routing and region consistency verification.

[0030] Regional consistency verification: Consistency verification is performed on the regional attributes of access tokens, user primary keys and / or target resources at the gateway, business service and data access layers. If there is any inconsistency, the access token is rejected and audited.

[0031] Physical isolation: Allocate independent database instances, object buckets, key domains and / or network domains by region to separate data in different regions at the physical resource level.

[0032] Strong logical isolation: On shared infrastructure, isolation levels equivalent to physical isolation are achieved through independent account permissions, independent keys, mandatory routing, and access control.

[0033] The regional compliance processing method provided in this application can be applied to a regional compliance processing system. For example... Figure 1 As shown, the system may include a client 10, a policy server 20, a gateway 31 (or replaced by an edge node), and a regional service cluster 30 (or regional business cluster). The policy server may constitute the control plane, and the gateway and the regional service cluster may constitute the data plane. The regional service cluster may include multiple service nodes, each of which may run on a physical machine, a virtual machine, or a container environment.

[0034] In some examples, the client may include a region identification unit, a policy loading and verification unit, a login module loading unit, an authentication channel selection unit, and a region token management unit. The region identification unit can be used to collect region signals and determine the target region identifier; the policy loading and verification unit can be used to obtain and verify region policies from the region compliance policy engine; the login module loading unit and the authentication channel selection unit can be used to dynamically load the corresponding functional modules according to the policies. The region token management unit can be used to generate and manage region tokens.

[0035] In some examples, the policy server may include a regional compliance policy engine, a policy publishing and version management module, a policy signing and key management module, a canary deployment and rollback module, and a policy hit and audit module. The regional compliance policy engine can be used to generate and manage regional policies corresponding to each regional identifier and distribute regional policies to the regional token management unit in the client; the policy publishing and version management module can be used for versioned management and distribution of policies; the policy signing and key management module can be used to digitally sign policies; the canary deployment and rollback module can be used for canary deployment and rollback of policies; and the policy hit and audit module can be used to record policy distribution and usage.

[0036] In some examples, the gateway may include a region routing module and a region consistency verification module.

[0037] In some examples, a regional service cluster may include: an authentication service, an account primary key generation module, a data source mapping module, a regional database, a regional object storage, a regional key management domain, and an audit log storage. The regional database, object storage, and key management domain are deployed separately by region, forming physical or strong logical isolation.

[0038] Next, the regional compliance processing method provided in this application will be described in detail, taking the client, policy server, gateway, and regional service cluster as the execution entities respectively.

[0039] See Figure 2 As shown in the embodiment of this application, a method for regional compliance processing executed by a client is provided, the method comprising: S101: In response to the client meeting the region identification conditions, determine the target region identifier corresponding to the client's local region; S102: Obtain the regional policy corresponding to the target region identifier. The regional policy includes the target region identifier, policy version, validity period, and allowed authentication methods. S103: If the regional policy is in effect, obtain a regional token containing the target regional identifier and the policy version; S104: Based on the effective regional policy, load the authentication module corresponding to the authentication method allowed by the regional policy; S105: Generate a service request carrying a region token based on the authentication module and send the service request to the gateway; wherein, the service request is used to enable the gateway to perform a region consistency check based on the region token in order to route the service request to the region service cluster that matches the region token.

[0040] In this embodiment, the client can be any internet application that needs to be deployed across regions, such as social applications, e-commerce applications, or financial service applications. When these applications are launched in different countries or regions, their authentication methods and / or data residency requirements need to be adapted to the compliance requirements of the current region (i.e., the local region).

[0041] In step S101 above, the client meeting the area identification conditions may include any one of the following: the client starts up for the first time, a change is detected in the public land mobile network (PLMN) accessed by the client's terminal, or a change is detected in the country code corresponding to the currently used SIM card.

[0042] Specifically, the client can trigger the region identification process in any of the following situations.

[0043] The first scenario is the client's first launch. When a user installs and opens the application for the first time, the client has not yet cached any region information and needs to determine the target region identifier of the current region through a region identification process in order to obtain the corresponding compliance policy. For example, if a user launches a social application for the first time within China, the client triggers a region identification process, determines the region identifier as "CN", and then obtains the compliance policy for the China region.

[0044] The second scenario involves detecting a change in the public terrestrial mobile network (PLMN) accessed by the client's terminal. When a user roams from China to the United States, and the PLMN accessed by the terminal switches from China Mobile's network to a US operator's network, the client detects the change in network registration status and re-triggers the area identification process to ensure that the correct compliance policy is applied in the current area.

[0045] The third scenario is when the country code corresponding to the currently used SIM card changes. When a user changes their SIM card (for example, changing a China Mobile SIM card to a SIM card from a US operator), the client can detect the change in SIM card status, read the new SIM country code, and re-identify the region.

[0046] By setting the above regional identification conditions, the client can update the regional identifier in a timely manner, ensuring that compliance policies are implemented based on the latest regional information and reducing compliance risks caused by environmental changes.

[0047] In some examples, to reliably determine the target region identifier, the step S101 above, which determines the target region identifier corresponding to the client's local region, may include: Collect signals from multiple regions; determine the confidence level of each candidate region based on the support of each region signal for multiple candidate regions and the preset weight; and determine the region identifier corresponding to the candidate region with the highest confidence level as the target region identifier.

[0048] The region identification unit in the client can be used to collect multiple region signals locally on the client. These signals include at least two of the following: SIM country code, IP address, system locale setting, time zone information, and locally stored historical region identifiers. For example, the SIM country code can be obtained through the mobile communication module, the country or region of the current IP address can be queried through the IP geolocation service, the system language locale setting and time zone information can be obtained through the operating system API, and locally cached historical region identifiers can be read.

[0049] For each regional signal, the client determines the support level of that regional signal for each candidate region in a preset regional set. This regional set can include all potentially involved country or region identifiers, such as CN, US, EU, etc. The support level can take values ​​between 0 and 1, representing the degree of consistency between the region pointed to by the regional signal and the candidate regions. For deterministic signals (such as SIM country codes), the support level is 1 if its value completely matches a candidate region, and 0 otherwise. For probabilistic signals (such as IP addresses), the probability value of the regional signal can be directly used as the support level. For ambiguous signals (such as English in the system language and region settings potentially corresponding to multiple countries), a support level less than 1 can be assigned according to preset rules.

[0050] The region identification unit can calculate a weighted score for the support of each candidate region based on preset weights corresponding to different region signals (e.g., SIM country code weight is 0.5, IP weight is 0.3, and Locale weight is 0.2). The score is then normalized to a confidence level, and the region with the highest confidence level is selected as the target region identifier. The confidence level of a region is used to characterize the probability that the region is the client's local region.

[0051] In some examples, when candidate regions indicated by different regional signals conflict, the region identifier corresponding to the candidate region with the higher preset compliance level is used as the target region identifier. For example, if regions indicated by different signals conflict, a preset compliance level table is queried to compare the compliance levels (such as the strictness of data residency requirements) of the two regions, and the region with the higher compliance level is selected as the final target region identifier to ensure compliance priority. For example, if the SIM country code indicates China while the IP indicates the United States, the region identification unit will select the region identifier corresponding to the region with stricter data residency requirements (i.e., higher compliance level) as the target region identifier.

[0052] In some examples, if the confidence level of all candidate regions is lower than a preset threshold (e.g., 0.3), a user confirmation process can be triggered. For example, the user can be prompted to manually select the current region through the interface, or a default region (e.g., the region determined by the IP address) can be selected as the client's current region according to the business strategy.

[0053] In some examples, when the identified target region identifier is inconsistent with the user's bound identity information (such as the user's unique identifier or the region declared in the user's access token), it is determined that there is a risk of cross-region access by a logged-in user. The client or backend service can take corresponding actions according to the business policy, such as rejecting the current request, requiring the user to verify their identity a second time, or forcing the user to log in again to ensure the consistency between the user's identity and the access region.

[0054] In some examples, step S102 above, which obtains the regional policy corresponding to the target region identifier, may include: The system reads the cached regional policy from the client's local cache. If the local cache does not contain a regional policy or the cached regional policy is not the latest version, it requests the latest regional policy from the policy server. The system verifies the signature, version, and validity period of the latest regional policy obtained from the policy server. If the verification passes, the system determines that the regional policy is effective and updates it to the local cache. If the verification fails, the system uses the previous effective version of the regional policy from the local cache as the effective regional policy.

[0055] After determining the target region identifier, the policy loading and verification unit in the client checks whether a region policy corresponding to that target region identifier exists in the local cache. If the region policy exists in the local cache and the current date is still within the validity period of the region policy, then the region policy is used directly. If it does not exist in the local cache, the region policy has expired, or the time remaining before expiration is less than a preset time threshold (e.g., 1 day), then a policy request is sent to the policy server to obtain the latest digitally signed region policy returned by the policy server.

[0056] A regional policy should at least include a regional identifier, policy version, validity period, and allowed authentication methods. Authentication methods may include login identifier types (e.g., mobile phone number, email address, third-party login) and verification channels (e.g., SMS, email, push notifications). Optionally, the regional policy may also include extended fields such as data residency domain identifier and gateway entry address.

[0057] In some examples, the policy loading and verification unit uses a pre-set public key to sign and verify the regional policy, and checks whether the current date is within the validity period of the regional policy and whether the policy version is the latest version. If the verification passes, the regional policy is confirmed to be effective and updated to the local cache; if the verification fails, it reverts to the previous valid version of the policy in the local cache.

[0058] Therefore, by performing signature verification, version verification, and validity period verification on the regional policy, we can prevent the policy from being tampered with and improve security. In addition, local caching and rollback mechanisms enable clients to run based on trusted regional policies.

[0059] In some examples, step S103 above, which involves obtaining a region token containing the target region identifier and the policy version when the region policy is in effect, may include: Send a token issuance request to the policy server, wherein the token issuance request carries the target area identifier and policy version; receive the area token issued by the policy server after verifying the target area identifier and policy version.

[0060] A token issuance request can be sent by the client to the policy server during the initial handshake, requesting the policy server to issue a zone token.

[0061] The policy server verifies the target region identifier and policy version, which may include: verifying whether the target region identifier matches the policy version (for example, confirming whether the policy version is the latest policy version for the region corresponding to the target region identifier), and issuing a region token after the verification is successful.

[0062] A region token can contain a region identifier and policy version, and may further include a nonce and a signature field. Once the client obtains the region token, it stores it in memory. The region token is used in subsequent requests; for example, when the client initiates a registration or login request, it retrieves the region token from memory and adds it to the request header.

[0063] Understandably, if a region token has expired, the client can re-initiate a token issuance request to obtain a new token.

[0064] In this embodiment, the client can request the policy server to issue a region token during the initial handshake. In other possible implementations, the client can generate the region token locally. For example, the client can read the latest policy version from the local cache and generate a region token containing the target region identifier and the policy version.

[0065] Figure 3 This is a schematic diagram illustrating the implementation process of client-side region identification and policy activation in an embodiment of this application. The client can perform the following steps upon initial startup or upon detecting changes in the network or SIM card slot: S201: Collection of area signals. The area signal collection may include SIM country code, IP address, system region settings, time zone information, historical cache area, and policy table default area, etc.

[0066] S202: Calculate the confidence level of candidate regions based on signals from each region and perform conflict handling to determine the target region identifier.

[0067] When multiple signals indicate conflicting areas, the area with the stricter compliance level is selected as the target area identifier according to preset rules, or a secondary confirmation process is initiated, such as manual confirmation by the user.

[0068] S203: Based on the target region identifier, determine whether the locally cached region policy is available. If yes, proceed to step S204; otherwise, proceed to step S205. For example, if the local policy package version is too old or about to expire, step S205 can be executed.

[0069] S204: Load the local cached regional policy. The loaded regional policy is the effective regional policy. After step S204, proceed to step S207.

[0070] S205: Request the latest regional policy from the policy server.

[0071] S206: Perform signature verification, version verification, and validity period verification on the obtained regional policy. If the verification fails, revert to the previous valid version policy locally. After step S206, proceed to step S207.

[0072] S207: Output the effective regional policy. The regional policy is cached locally and includes the policy version (policy_version), region ID (region_id), and validity period (valid_to).

[0073] S208: Generate or obtain a region token. The region token contains at least a region identifier (region_id) and a policy version (policy_version), and may further include a nonce and a signature field to enhance security.

[0074] In some examples, steps S201 to S202 can be used as Figure 2 An optional implementation of step S101.

[0075] In some examples, steps S203 to S207 can be used as Figure 2 An optional implementation of step S102.

[0076] For details regarding regional strategies and related content, please refer to [link / reference]. Figure 2 The related parts in the embodiments involved will not be described again here.

[0077] In some examples, regional policies allow authentication methods including login identity types and verification channels; login identity types may include one or more combinations of mobile phone number login, email login, and third-party login. Verification channels may include one or more combinations of SMS verification codes, email verification codes, push notification verification, and one-time passwords.

[0078] exist Figure 2 In step S104 shown, according to the effective regional policy, the authentication module corresponding to the authentication method allowed by the regional policy is loaded, which may include: Based on the effective regional policy, load the login module corresponding to the login identifier type and the verification module corresponding to the verification channel.

[0079] In this embodiment, when the client runs in different regions, the login module and the verification module are dynamically loaded according to the regional policy, so as to minimize the exposure of capabilities and reduce the compliance risk caused by unauthorized functions being reverse-called.

[0080] The login module is used to obtain the login identifier corresponding to the login identifier type. Specifically, this can be achieved by providing a login identifier input interface to collect the login identifier entered by the user. For example, if the regional policy allows login by mobile phone number, the client loads UI components such as a mobile phone number input box as the login module; if the regional policy allows login by email, the client loads UI components such as an email input box as the login module; if the regional policy allows third-party login, the client loads the corresponding SDK (Software Development Kit) and authorization interface as the login module. For login identifier types not allowed by the regional policy, their corresponding code modules are not instantiated, and the corresponding UI entry points are not displayed.

[0081] The verification module is used to obtain the verification credentials corresponding to the verification channel. Specifically, this can be achieved by triggering the sending of a verification code and collecting the verification code entered by the user. For example, if the regional policy allows SMS verification, the client loads the SMS verification module, which is used to perform logic such as generating and sending SMS verification codes (e.g., selecting a suitable SMS gateway and handling sending frequency limits), verification, and resending. If the regional policy allows email verification, the email verification module is loaded, which is used to perform logic such as generating and sending email content (through an email service provider) and handling verification links. If the regional policy allows push notification verification, the push verification module is loaded, which integrates with a push service provider to push verification codes or confirmation messages. Similar to the login module, for verification channels not allowed by the regional policy, their corresponding verification modules are not loaded, and the corresponding function entry points and callback interfaces are unavailable.

[0082] After obtaining the login identifier types and verification channels allowed by the regional policy, the client can dynamically load the corresponding login module according to the allowed login identifier types through the login module loading unit, and load the verification module corresponding to the verification channel according to the verification channel allowed by the policy through the verification channel selection unit.

[0083] In some examples, when generating a business request based on the login and verification modules, the business request includes a login identifier and verification credentials for authentication, along with a region token. The business request can be either a registration request or a login request.

[0084] Figure 4 This application provides a schematic diagram of the client-side dynamic loading implementation process. After obtaining the effective regional policy, the client executes the dynamic loading process, loading only the authentication capabilities allowed by the regional policy to avoid exposing unauthorized functions. Figure 4 As shown, the process of dynamic loading performed by the client includes the following steps: S301: Parse the region policy. For example, parse the set of allowed login identifiers (allowed_login_identifiers) and the set of verification channels (verification_channels) in the region policy.

[0085] S302: Determine whether email login is allowed. If yes, proceed to step S303; otherwise, proceed to step S304.

[0086] If the set of allowed login identifiers includes email identifiers, then email login is allowed; otherwise, email login is not allowed.

[0087] S303: Load the email login module. After step S303, proceed to step S309.

[0088] S304: Determine whether mobile phone login is allowed. If yes, proceed to step S305; otherwise, proceed to step S306.

[0089] For example, if the set of allowed login identifiers includes mobile phone number identifiers, then mobile phone login is allowed; otherwise, mobile phone login is not allowed.

[0090] S305: Load the mobile phone number login module. After step S305, proceed to step S309.

[0091] S306: Determine whether third-party login is allowed. If yes, proceed to step S307; otherwise, proceed to step S308.

[0092] If the set of allowed login identifiers includes a third-party login identifier, then third-party login is allowed; otherwise, third-party login is not allowed. Steps S306 to S308 are optional.

[0093] S307: Load the corresponding third-party login module. After step S307, proceed to step S309.

[0094] S308: Output a message indicating that no login method is available.

[0095] S309: Select the verification channel according to the strategy.

[0096] Select a verification channel based on the set of verification channels, such as SMS OTP (One-Time Password), email OTP / link, push confirmation, one-time password, etc., and configure the corresponding sending gateway and callback processing.

[0097] S310: Initiate a registration or login request carrying a region token.

[0098] When making a request, a region token is included in the request header or request body for backend routing and region consistency verification.

[0099] In some examples, steps S301 to S309 can be used as Figure 2 Step S104 is an optional implementation, and can also be implemented alone to constitute an independent embodiment, or combined with step S310 to constitute an independent embodiment. For related descriptions regarding regional strategies, please refer to... Figure 2 The related parts in the embodiments involved will not be described again here.

[0100] This application provides a method for handling regional compliance. By determining the target region identifier corresponding to the client's local region, obtaining the corresponding regional policy, and when the regional policy is in effect, obtaining a regional token containing the target region identifier and the policy version, and dynamically loading the authentication module allowed by the regional policy on the client, the client only presents the authentication capabilities allowed in different regions. Therefore, the unauthorized authentication capabilities will not be exposed on the client side, thereby directly reducing the attack surface and reducing the compliance risk caused by unauthorized functions being reverse-called. Furthermore, it maintains a unified code baseline for the same application, effectively reducing maintenance costs compared to multi-application fork solutions.

[0101] In addition, by generating a business request carrying a regional token based on the authentication module, the client sends the business request to the gateway. This regional token can provide a reliable basis for the gateway's routing decisions and consistency verification of the regional service cluster. In this way, cross-regional requests can be blocked early in the link, thereby reducing the probability of cross-regional read and write operations and improving data security.

[0102] The various embodiments or implementation methods described in this specification are presented in a progressive manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other.

[0103] See Figure 5 As shown in the embodiment of this application, a method for regional compliance processing executed by a policy server is provided, the method comprising: S401: Generate and sign a regional policy. The regional policy includes the target region identifier, policy version, validity period, and allowed authentication methods. The allowed authentication methods are used to instruct the client to load the corresponding authentication module. S402: Send the signed regional policy to the client in the corresponding region; S403: Receive a token issuance request sent by the client, which carries the target area identifier and policy version; S404: Verify the target region identifier and policy version, and after successful verification, issue a region token containing the target region identifier and policy version to the client so that the client can carry the region token when initiating business requests based on the authentication module.

[0104] In this embodiment, the regional policy is the compliance policy of the target region identifier corresponding to the region.

[0105] For example, the policy server can respond to the policy service administrator's operation of configuring regional policies for different regions through the management console, and generate corresponding regional policies. The regional policy includes at least: target region identifier, policy version, validity period, and authentication method. The authentication method includes, for example, login identifier type and verification channel.

[0106] The policy signing and key management module in the policy server can use a private key to digitally sign the policy content, generating a signature value, which is then appended to the regional policy. The signed regional policy can then be stored in the policy database.

[0107] In some examples, the policy server can maintain a mapping table between region identifiers and policy versions. This mapping table records the current policy version corresponding to each region identifier and can be used to respond to policy requests and token issuance requests from clients.

[0108] In step S402 above, when the policy server receives a policy request from the client, it can query the policy database based on the region identifier in the request, obtain the latest version of the region policy and signature, and assemble it into a response to return to the client.

[0109] In some embodiments, optional implementations of steps S403 to S404 can be found in [reference needed]. Figure 2 Optional implementation methods of step S103, and Figure 2 Other related parts in the embodiments involved will not be described in detail here.

[0110] In this embodiment, compliance policies for all regions are centrally managed by the policy server, enabling unified configuration and distribution of policies. Since the policies include allowed authentication methods, clients can dynamically load the corresponding authentication modules based on the current region, thereby adapting to the compliance requirements of different regions and achieving differentiated identity authentication. In addition, the signing of policies ensures that clients can only execute authorized compliance policies. Furthermore, by verifying the regional tokens before issuing them, the regional tokens obtained by the clients are trustworthy and valid, ensuring that subsequent business requests can pass the regional consistency verification of the gateway or business server, preventing policy tampering or forged requests, and improving security.

[0111] In some embodiments, the regional policy further includes a data residency domain identifier bound to the target region identifier, which indicates the data storage resources for user data. This data residency domain identifier ensures that user data is stored and processed only within compliant regions. For example, the data storage resources may include a database instance, object bucket, and / or key management domain corresponding to the target region identifier.

[0112] The data residency domain identifier can be a specific data center identifier or a logical storage domain identifier. One logical domain can correspond to multiple physical resources. The data residency domain identifier can be specified by policy administrators through the management console during regional policy configuration and bound to a specific regional identifier.

[0113] In this embodiment, after the client obtains the regional policy containing the data residency domain identifier, the client can store the data residency domain identifier locally or encapsulate it in the business request. When the client initiates a registration or login request, the gateway or business server can, based on the identifier, directly route the user data carried in the request (e.g., login identifier) ​​to a designated database instance for persistent storage, write it to a designated storage bucket, or guide the encryption operation to a designated key management domain for execution, thereby ensuring that the physical storage location of the user data strictly complies with the data residency compliance requirements of the target region. This separates data in different regions at the physical resource level, achieving physical isolation of data in different regions.

[0114] In some embodiments, the method further includes: Determine whether the client is within the testing scope of the new version policy based on the gray-scale rules; if so, send the signed regional policy carrying the first policy version to the client; if not, send the signed regional policy carrying the second policy version to the client, with the first policy version being higher than the second policy version.

[0115] A canary release rule can be set by the policy service administrator before releasing a new version of the policy. This canary release rule can be implemented based on user hashes, device hashes, or channel bucketing. For example, it can be bucketed according to the last two digits of the device ID hash value, sending the new version of the policy only to clients whose device hash values ​​fall within a specified range, while sending the old version of the policy to clients whose device hash values ​​do not fall within the specified range.

[0116] In this embodiment, grayscale rules can be applied when a client requests a policy. For example, when a client requests a policy, the policy server calculates whether the hash value of the request belongs to the grayscale bucket based on the device identifier or user information carried in the request. If it belongs to the grayscale bucket, the new version of the policy is returned; otherwise, the old version of the policy is returned.

[0117] In some embodiments, the method further includes: Obtain the running data of the latest version policy sent to the client; when the running data of the latest version policy meets the abnormal conditions, send a rollback command to the client so that the client can revert to the previous valid version policy.

[0118] The latest version policy is the latest regional policy published by the policy server for the region corresponding to the target region identifier. Its operation data may include the login success rate and error rate when the client runs the latest version policy.

[0119] When the running data of the latest policy version meets a preset anomaly threshold, such as an error rate exceeding 5% or a success rate drop exceeding 10%, a rollback command is sent to the client. The rollback command can be implemented via push notification or through a response instruction the client uses the next time it requests the policy. Upon receiving the rollback command, the client clears the locally cached abnormal version policy and re-requests the previous valid version policy, or directly uses the locally cached previous valid version policy. Thus, the rollback mechanism reduces the impact on client operation when regional policies become abnormal.

[0120] Figure 6 This diagram illustrates the implementation process of policy updates, canary deployments, and rollbacks provided in this application's embodiments. The policy server supports dynamic updates, canary deployments, and rollbacks for regional policies in case of anomalies. Figure 6 As shown, the specific process may include: S501: Generate a new version of the policy and complete its signing, then set the policy's validity period. The policy's validity period can include an effective date (valid_from) and an expiration date (valid_to).

[0121] S502: Canary release strategy. The strategy server can bucket clients based on user hash, device hash, or channel identifier, and only send the new version strategy to a subset of clients to achieve canary release and verification.

[0122] S503: The policy takes effect after the client pulls and verifies the regional policy. The client periodically or proactively pulls the latest policy package upon receiving an update notification, performs signature and validity period verification, and then makes the new policy effective. If verification fails, or if an error occurs during the new policy's execution, the client automatically reverts to the previous valid version to ensure service continuity.

[0123] S504: The policy server determines whether the new version policy has encountered any abnormalities or alarms. If so, proceed to step S505; otherwise, proceed to step S506.

[0124] S505: Rollback to old version policy. Based on the operational monitoring metrics and audit alerts of each version policy, the policy server can trigger the client to roll back the old version policy if an anomaly is detected, thereby reducing the risks that may be caused by a full release.

[0125] S506: Expand grayscale to full.

[0126] In this embodiment, since regional policies are centrally versioned and support canary releases and rollbacks, policy changes can be quickly and consistently distributed and verified in a controllable manner; thereby reducing maintenance costs caused by multiple applications or branches and improving iteration efficiency.

[0127] The various embodiments or implementation methods described in this specification are presented in a progressive manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other.

[0128] See Figure 7 As shown in the figure, this application embodiment provides a region compliance processing method executed by a gateway, the method including: S601: Receives a service request sent by the client. The service request carries a region token containing the target region identifier and the policy version of the region policy. S602: Perform regional consistency verification based on the regional token to route business requests to the regional service cluster that matches the regional token.

[0129] In this embodiment, the service request is generated by the client according to the authentication module that is allowed to be loaded according to the regional policy.

[0130] The gateway extracts the target region identifier and policy version by parsing the region token in the business request, and performs a region consistency check based on the extracted target region identifier; based on the check result, it routes the request to the corresponding region service cluster.

[0131] In some embodiments, optional implementations of step S601 can be found in [reference needed]. Figure 2 Optional implementation methods of step S105, and Figure 2 Other related parts in the embodiments involved will not be described in detail here.

[0132] In some embodiments, step S602, performing a region consistency check based on the region token to route service requests to the region service cluster matching the region token, may include: Based on the target region identifier contained in the region token, verify whether the target region identifier is consistent with the region identifier corresponding to the target region service cluster; if they are consistent, route the business request to the region service cluster that matches the region token; if they are inconsistent, reject the business request and generate an audit log.

[0133] If the target region identifier does not match the region identifier corresponding to the target region service cluster, it indicates that the business request may have been incorrectly routed or there may be a configuration deviation. The gateway rejects the business request and generates an audit log to record the abnormal event. The audit log should at least include the reason for rejection, the target region identifier, the policy version, and the source of the request.

[0134] Figure 8 This diagram illustrates the implementation process of gateway routing and regional cluster selection provided in this application embodiment. The gateway (which can be replaced by an edge node) executes a routing and verification process based on regional tokens, such as... Figure 8 As shown, the specific process may include: S701: The gateway has received a client request.

[0135] S702: Parse the zone token and access token in the request.

[0136] S703: The gateway selects the corresponding regional service cluster based on the target region identifier in the region token.

[0137] For example, a gateway can determine the address of the regional service cluster corresponding to the target region identifier in any of the following ways: determine the address of the service cluster corresponding to the target region identifier based on a pre-configured mapping table between region identifiers and regional service clusters; or, via an Anycast address, direct the request to the nearest gateway node, which then determines the corresponding regional service cluster to be forwarded to based on the target region identifier in the region token; or, determine the regional service cluster corresponding to the target region identifier based on SNI (Server Name Indication) or Host (host header or host field) rules.

[0138] S704: Perform a region consistency check. If the check passes, proceed to step S705; otherwise, proceed to step S706.

[0139] Performing a region consistency check may include determining whether the region identifier associated with the access token or user primary key carried in the request is consistent with the region identifier in the region token.

[0140] S705: The gateway forwards the request to the target area cluster.

[0141] For example, the gateway forwards the request to the authentication service or business service in the target area cluster for further processing.

[0142] S706: Deny the request and log the audit log.

[0143] In some examples, steps S702 to S706 can be used as Figure 7This can be an optional implementation of step S602, or it can be combined with step S701 to form an independent embodiment.

[0144] In this embodiment, cross-regional requests are blocked early in the link by using regional consistency verification at the gateway layer; this reduces the probability of cross-regional read / write operations and improves compliance stability. Furthermore, requests that fail verification are logged, providing a basis for subsequent compliance audits and system optimization.

[0145] The various embodiments or implementation methods described in this specification are presented in a progressive manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other.

[0146] See Figure 9 As shown in the embodiment of this application, a regional compliance processing method executed by a regional service cluster is provided, the method comprising: S801: Receive the service request forwarded by the gateway. The service request carries a regional token containing the target region identifier and the policy version of the regional policy. After step S801, either step S802 or step S803 is executed.

[0147] S802: If the business request is a registration request, generate a unique user identifier bound to the target region identifier and an access token containing the unique user identifier and return it to the client, and write the user data to the corresponding data storage resource according to the target region identifier.

[0148] S803: If the service request is a login request and also carries an access token, extract the user's unique identifier from the access token; after step S803, execute step S804.

[0149] S804: Verify whether the target region identifier is consistent with the region identifier bound to the user's unique identifier; if they are consistent, proceed to step S805; otherwise, proceed to step S806.

[0150] S805: Processes business requests and writes the generated user data to the corresponding data storage resource according to the target area identifier.

[0151] S806: Reject the business request and generate an audit log.

[0152] In this embodiment, the service request is generated by the client according to the authentication module that is allowed to be loaded according to the regional policy.

[0153] For example, the authentication service in the regional service cluster can determine whether a business request is a registration request or a login request based on the path or parameters of the business request. A registration request is used to create a new user, while a login request is used to verify the identity of an existing user.

[0154] If the business request is a registration request, the authentication service can call the primary key generation module to generate a unique user identifier (UID) bound to the target region identifier, and generate an access token containing the user's unique identifier to return to the client. Simultaneously, the authentication service sends user data (such as phone number, password hash, user primary key, and / or registration time) to the data source mapping module, which then writes the data to the corresponding data storage resource based on the target region identifier.

[0155] If the business request is a login request and carries an access token, the authentication service extracts the user's unique identifier from the access token and verifies whether the target region identifier is consistent with the region identifier bound to the user's unique identifier.

[0156] If the verification results are consistent, the login request is processed, such as verifying the user's password, updating the last login time, or logging the login information. User data generated during processing is sent to the data source mapping module and written to the corresponding data storage resource. If the verification results are inconsistent, the request is rejected and an audit log is generated.

[0157] In some embodiments, the audit log includes the target region identifier, the region identifier in the access token, the user identifier, the resource identifier, the policy version, the reason for denial, and the global tracking identifier.

[0158] In this embodiment, the regional service cluster implements regional consistency verification at the business processing layer, ensuring that all user data is only written to the data storage resources of the region corresponding to the target region identifier, thus achieving physical isolation of data writing. Furthermore, since the unique user identifier generated by the registration request is bound to the region identifier, each subsequent login request must verify regional consistency, thereby suppressing the possibility of cross-regional data access and improving data security.

[0159] In some embodiments, step S802 above, which generates a unique user identifier bound to the target area identifier, may include: Alternatively, embed the target region identifier as a prefix in the user's unique identifier; or use the hash value calculated by the hash function of the target region identifier, local serial number, and salt value as the user's unique identifier.

[0160] In this embodiment, the user's unique identifier can be generated using a distributed ID generation algorithm such as the Snowflake algorithm, with the target region identifier embedded as a prefix. For example, UID = region_prefix (region prefix) + time-ordered unique ID, enabling differentiation and routing based on the region prefix. Alternatively, the user's unique identifier can be generated through hash calculation, for example, UID = H(region_id||local_id||salt), where the double vertical bars "||" represent string concatenation. By performing a hash operation on the concatenated target region identifier, local serial number, and salt value, the user's unique identifier can be generated. Since hashing is irreversible, the region identifier and local serial number cannot be derived from the user's unique identifier, thus enhancing user privacy protection.

[0161] In some embodiments, the control plane can maintain a global user identifier (global_uid) and a regional user identifier (region_uid) used by the business plane, so that the business plane does not have any contact with the cross-region global mapping, thus achieving stronger data isolation.

[0162] In some embodiments, writing user data into the corresponding data storage resource according to the target region identifier includes: Based on the target region identifier, obtain temporary access credentials for the data storage resource from the region configuration center; use the temporary access credentials to establish a connection with the data storage resource and perform data write operations; wherein, the data storage resource includes the database instance, object bucket and / or key management domain corresponding to the target region identifier.

[0163] In this embodiment, after receiving user data (e.g., user data sent by the authentication service), the data source mapping module can apply to the regional configuration center for a temporary access credential (e.g., a database connection string or a one-time password) for the data storage resources corresponding to the target region identifier, based on the target region identifier. The module then uses the credential to establish a connection and writes the user data into the corresponding data storage resources. After writing is complete, the credential is destroyed immediately.

[0164] Figure 10 This diagram illustrates the implementation process of account primary key generation and physical data isolation provided in this application embodiment. Within each regional service cluster, account creation and data storage adhere to regional binding and isolation requirements, such as... Figure 10 As shown, the specific process may include: S901: The regional authentication service generates a unique user identifier and binds it to the regional identifier.

[0165] The authentication service creates user records and generates user primary key UIDs within this region, and the UIDs are strongly bound to the region identifier.

[0166] S902: Select the database instance, object bucket, or key domain for this region based on the region identifier.

[0167] The data source mapping module selects the local database instance, object bucket, or key domain based on the region identifier; cross-region data source connections are prohibited.

[0168] S903: User data is written to resources in this region.

[0169] User profiles, conversations, privacy settings, audit logs, and other data are written to resources within this region; if cross-regional statistics are required, a compliant data pipeline that has been anonymized or aggregated is used.

[0170] In some examples, steps S901 to S903 can be used as Figure 9 One optional implementation of step S802.

[0171] Figure 11 This is a schematic diagram illustrating the interaction process of cross-regional access blocking and auditing provided in an embodiment of this application. To prevent cross-regional access caused by configuration errors or internal calls, this embodiment performs consistency checks at the gateway layer, business service layer, and data access layer.

[0172] like Figure 11 As shown, the specific process may include: S1001: The client sends a request. This request carries a zone token and an access token.

[0173] S1002: The gateway layer verifies the region identifier in the region token and the region identifier associated with the target region service cluster.

[0174] If the verification matches, forward the request; if the verification does not match, reject the request and log the audit.

[0175] S1003: The business service layer verifies the region identifier associated with the user's unique identifier and the region identifier in the region token.

[0176] If the verification is successful, only connect to the data source in this region; otherwise, reject the request.

[0177] The data access layer only allows access to the data source mapped by the region identifier of this region, and uses temporary access credentials (such as database connection strings or one-time passwords) to restrict cross-region access.

[0178] The aforementioned audit logs may include: recording region identifiers, user identifiers, resource identifiers, policy versions, reasons for rejection, and global tracking identifiers, for use in compliance audits.

[0179] In summary, the technical solution provided by the embodiments of this application has at least the following advantages: 1. Since the client only loads allowed login / verification modules through regional policies, disallowed authentication capabilities are not exposed on the client side, thereby directly reducing the attack surface and further reducing compliance risks caused by misconfiguration and reverse calls.

[0180] 2. Since the gateway automatically routes to the corresponding regional cluster based on the regional token and performs regional consistency verification at the gateway layer, service layer, and data layer, cross-regional requests can be blocked early in the link; this reduces the probability of cross-regional read and write operations and improves compliance stability; and it can also support compliance traceability through policy hit auditing.

[0181] 3. Since the user primary key and data source mapping are generated within the region and fall into the region's dedicated storage or key domain, forming physical isolation or strong logical isolation, even if there are logical defects in the business layer, it is difficult to cross the isolation boundary of the data plane, thereby improving data security.

[0182] 4. Because regional policies are centrally versioned and support canary distribution and rollback, policy changes can be quickly and consistently distributed and verified in a controllable manner; this reduces maintenance costs associated with multiple applications / branches and improves iteration efficiency.

[0183] The various embodiments or implementation methods described in this specification are presented in a progressive manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other.

[0184] In the various embodiments described in the specification, some or all of the steps and their optional implementations can be arbitrarily combined with some or all of the steps in other embodiments, or arbitrarily combined with the optional implementations in other embodiments.

[0185] This application embodiment also provides a regional compliance processing system, the system comprising: The client is configured to execute the region compliance processing method performed by the client in the aforementioned embodiments; The policy server is configured to execute the regional compliance processing method executed by the policy server in the aforementioned embodiments; The gateway is configured to execute the region compliance processing method performed by the gateway in the foregoing embodiments; The regional service cluster is configured to execute the regional compliance processing method performed by the regional service cluster in the foregoing embodiments.

[0186] In this embodiment, the interaction flow and specific implementation details of each component of the regional compliance processing system have been described in detail in the foregoing method embodiments, and will not be repeated here. This system enables the automatic identification of compliance requirements, dynamic selection of authentication capabilities, and mandatory data isolation based on regional differences, under the same client and backend code baseline conditions.

[0187] This application also provides an electronic device, including a processor and instructions for invoking instructions to cause the electronic device to execute the steps of the region compliance processing method provided in any of the foregoing embodiments.

[0188] This application also provides a storage medium, including an executable program stored thereon, which, when executed by a processor, implements the steps of the region compliance processing method provided in any of the foregoing embodiments.

[0189] For ease of understanding, the following focuses on explaining the terminology used in this embodiment: In this application embodiment, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a Central Processing Unit (CPU), a microprocessor, a Graphics Processing Unit (GPU) (which can be understood as a type of microprocessor), or a Digital Signal Processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. The logical relationships of the aforementioned hardware circuits are fixed or reconstructable. For example, the processor is a hardware circuit implemented using an Application-Specific Integrated Circuit (ASIC) or a Programmable Logic Device (PLD), such as an FPGA. In a reconstructable hardware circuit, the processor loads a configuration document, implementing a cyclical process of hardware circuit configuration. This can be understood as the processor loading instructions to implement the functions of some or all of the above units or modules in a cyclical process. In addition, it can also be hardware circuits designed for artificial intelligence, which can be understood as a type of ASIC, such as Neural Network Processing Unit (NPU), Tensor Processing Unit (TPU), Deep Learning Processing Unit (DPU), etc.

[0190] The computer-readable storage medium provided in this embodiment can execute the regional compliance processing method of the above embodiment. Its implementation principle and technical effect are similar to those of the above embodiment, and will not be repeated here.

[0191] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0192] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0193] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0194] The various embodiments or implementation methods described in this specification are presented in a progressive manner. Each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other.

[0195] In the description of this specification, references to "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0196] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for regional compliance processing, characterized in that, The method, executed by the client, includes: In response to the client meeting the region identification conditions, the target region identifier corresponding to the client's local region is determined; Obtain the regional policy corresponding to the target region identifier, wherein the regional policy includes the target region identifier, policy version, validity period, and allowed authentication methods; If the regional policy is in effect, obtain a regional token containing the target region identifier and the policy version; According to the effective regional policy, load the authentication module corresponding to the authentication method allowed by the regional policy; The authentication module generates a service request carrying the region token and sends the service request to the gateway; wherein the service request is used to enable the gateway to perform a region consistency check based on the region token, so as to route the service request to the region service cluster that matches the region token.

2. The regional compliance processing method according to claim 1, characterized in that, The client meets any of the following area identification conditions: the client is launched for the first time, a change is detected in the public land mobile network accessed by the terminal to which the client belongs, or a change is detected in the country code corresponding to the currently used SIM card; Determining the target region identifier corresponding to the client's local region includes: Collect signals from multiple regions; wherein, the multiple regional signals include at least two of the following: SIM country code, IP address, system region setting, time zone information, and locally stored historical region identifiers; The confidence level of each candidate region is determined based on the support of each region's signal for multiple candidate regions and the preset weights. The region identifier corresponding to the candidate region with the highest confidence level is determined as the target region identifier; When candidate regions indicated by signals from different regions conflict, the region identifier corresponding to the candidate region with the higher preset compliance level is used as the target region identifier.

3. The regional compliance processing method according to claim 1, characterized in that, Obtaining the regional policy corresponding to the target region identifier includes: Read the cached region policy from the client's local storage; If the local cache does not contain a regional policy or the cached regional policy is not the latest version, then request the latest regional policy from the policy server. The latest regional policy obtained from the policy server is verified for signature, version, and validity period; If the verification passes, the regional policy is confirmed to be in effect and updated to the local cache; If the verification fails, the previous valid version of the local cached regional policy will be used as the effective regional policy.

4. The regional compliance processing method according to claim 1, characterized in that, Obtaining a region token containing the target region identifier and the policy version includes: Send a token issuance request to the policy server, the token issuance request carrying the target area identifier and the policy version; Receive the region token issued by the policy server after verifying the target region identifier and the policy version.

5. The regional compliance processing method according to any one of claims 1 to 4, characterized in that, The regional policy allows authentication methods including login identifier type and verification channel; The step of loading the authentication module corresponding to the authentication method allowed by the effective regional policy includes: According to the effective regional policy, load the login module corresponding to the login identifier type and the verification module corresponding to the verification channel.

6. A method for regional compliance processing, characterized in that, Executed by the policy server, the method includes: Generate and sign a regional policy, wherein the regional policy includes a target region identifier, policy version, validity period, and allowed authentication methods; wherein the allowed authentication methods are used to instruct the client to load the corresponding authentication module; The signed regional policy is then sent to the client in the corresponding region. Receive a token issuance request sent by the client, which carries the target area identifier and the policy version; The target region identifier and the policy version are verified, and after the verification is successful, a region token containing the target region identifier and the policy version is issued to the client so that the client carries the region token when initiating a service request based on the authentication module.

7. The regional compliance processing method according to claim 6, characterized in that, The regional policy also includes a data residency domain identifier bound to the target region identifier, which is used to indicate the data storage resources for user data.

8. The regional compliance processing method according to claim 6, characterized in that, The method further includes: Determine whether the client falls within the testing scope of the new version strategy based on the gray-scale rules; If so, then a signed regional policy carrying the first policy version is sent to the client; If not, a signed regional policy carrying a second policy version is sent to the client, where the first policy version is higher than the second policy version.

9. The regional compliance processing method according to any one of claims 6 to 8, characterized in that, The method further includes: Retrieve the runtime data of the latest version of the policy delivered to the client; When the running data of the latest version of the policy meets the abnormal conditions, a rollback command is sent to the client so that the client can revert to the previous valid version of the policy.

10. A method for regional compliance processing, characterized in that, The method, executed by the gateway, includes: Receive a service request sent by a client. The service request carries a regional token containing a target region identifier and a policy version of the regional policy. The service request is generated by the client according to the authentication module allowed to be loaded according to the regional policy. Perform a region consistency check based on the region token to route the service request to the region service cluster that matches the region token.

11. The regional compliance processing method according to claim 10, characterized in that, The step of performing a region consistency check based on the region token to route the service request to a region service cluster that matches the region token includes: Based on the target region identifier contained in the region token, verify whether the target region identifier is consistent with the region identifier corresponding to the target region service cluster; If they match, the service request will be routed to the regional service cluster that matches the regional token. If there is a discrepancy, the business request will be rejected and an audit log will be generated.

12. A method for regional compliance processing, characterized in that, The method, executed by a regional service cluster, includes: Receive service requests forwarded by the gateway, wherein the service request carries a regional token containing a target region identifier and a policy version of the regional policy, and the service request is generated by the client according to the authentication module allowed to be loaded according to the regional policy; If the service request is a registration request, a unique user identifier bound to the target region identifier and an access token containing the unique user identifier are generated and returned to the client, and the user data is written to the corresponding data storage resource according to the target region identifier. If the business request is a login request and also carries an access token, then extract the user's unique identifier from the access token and verify whether the target region identifier is consistent with the region identifier bound to the user's unique identifier. If they match, the service request is processed, and the user data generated during processing is written to the corresponding data storage resource according to the target area identifier. If there is a discrepancy, the business request will be rejected and an audit log will be generated.

13. The regional compliance processing method according to claim 12, characterized in that, Generate a unique user identifier bound to the target region identifier, including: Embed the target region identifier as a prefix in the user's unique identifier; or... The hash value calculated using the target region identifier, local serial number, and salt value through a hash function is used as the unique identifier of the user.

14. The regional compliance processing method according to claim 12, characterized in that, Write user data to the corresponding data storage resource according to the target area identifier, including: Based on the target region identifier, obtain temporary access credentials for the data storage resource from the region configuration center; The temporary access credential is used to establish a connection with the data storage resource and to perform a data write operation; The data storage resources include a database instance, object bucket, and / or key management domain corresponding to the target region identifier.

15. The regional compliance processing method according to any one of claims 12 to 14, characterized in that, The audit log includes the target region identifier, the region identifier in the access token, the user identifier, the resource identifier, the policy version, the reason for denial, and the global tracking identifier.

16. A regional compliance processing system, characterized in that, The system includes: The client is configured to perform the regional compliance processing method as described in any one of claims 1 to 5; The policy server is configured to execute the regional compliance processing method as described in any one of claims 6 to 9; The gateway is configured to perform the regional compliance processing method as described in any one of claims 10 to 11; The regional service cluster is configured to perform the regional compliance processing method as described in any one of claims 12 to 15.

17. An electronic device, characterized in that, Includes a processor, the processor being configured to invoke instructions to cause the electronic device to execute the regional compliance processing method as described in any one of claims 1 to 15.

Images