Distributed saas ticket system data isolation and permission management method and system

Abstract

The application discloses a distributed SaaS ticket system data isolation and permission management method and system; the method comprises the following steps: constructing a SaaS tenant system; adapting a mixed data isolation architecture of a venue tenant according to the constructed SaaS tenant system to realize data isolation; the mixed data isolation architecture comprises a storage layer isolation design, an independent database instance is allocated to each tenant to store core business data, and a tenant identifier is used to store public data to a shared database; a layered permission model is designed according to the constructed SaaS tenant system to realize permission management; the layered permission model adopts a three-level layered mode configuration, and realizes permission control through a dynamic strategy engine. The application can realize strict isolation and accurate permission management of data in a multi-tenant environment, maintain efficient operation of the system, and avoid data confusion and privacy leakage.

Description

Technical Field

[0001] This application relates to the technical field of data management and security, specifically to a method and system for data isolation and access control in a distributed SaaS ticketing system. Background Technology

[0002] In the field of distributed SaaS ticketing systems, with the continuous development and diversification of ticketing business, the application of the SaaS model in ticketing systems is becoming increasingly widespread. The SaaS model brings many conveniences to ticketing systems, such as reducing software procurement and maintenance costs for enterprises, improving system scalability and flexibility, and enabling ticketing companies of different sizes to choose suitable services according to their own needs. At the same time, the SaaS model also promotes the digital transformation of the ticketing industry, drives the integration of ticketing systems with other business systems, and improves the operational efficiency and service quality of the entire industry.

[0003] In traditional SaaS ticketing systems, various methods have been employed to address data isolation and access control issues. On one hand, for data isolation, some systems use a single database with multiple tables, storing data from different tenants in different tables within the same database, distinguishing them by table names or field identifiers. On the other hand, some systems use multiple independent databases, allocating a separate database for each tenant to achieve physical data isolation. Regarding access control, a common approach is Role-Based Access Control (RBAC), assigning different permissions to different roles to restrict user access to system resources.

[0004] However, these existing technologies have significant drawbacks. While a single database with multiple tables is simple to implement, it is prone to data contamination, potential security risks between data from different tenants, and query and maintenance efficiency decreases significantly as data volume increases. Multiple independent databases, while achieving physical isolation, increase the complexity and cost of database management. Role-based access control (RBAC) lacks flexibility and struggles to handle complex and ever-changing business scenarios and dynamic permission requirements. For example, in complex scenarios involving franchisees and revenue-sharing mechanisms, it cannot meet the granular requirements of distributed SaaS ticketing systems for data isolation and permission management. Summary of the Invention

[0005] To achieve strict data isolation and precise access management in a multi-tenant environment, while maintaining efficient system operation and avoiding data confusion and privacy leaks, this application provides a data isolation and access management method and system for a distributed SaaS ticketing system.

[0006] Firstly, this application provides a method for data isolation and access control in a distributed SaaS ticketing system, including:

[0007] The SaaS tenant system is constructed, including: establishing venues as the main tenant entities and assigning them unique identifiers; forcibly associating each tenant with franchisee attribute information, including the franchisee's unique identifier, franchisee name, and franchisee level; controlling the tenant lifecycle through enabled, disabled, or pending approval status, and automatically freezing the corresponding data access permissions in the disabled status.

[0008] The SaaS tenant system is adapted to the venue tenants' hybrid data isolation architecture to achieve data isolation. The hybrid data isolation architecture includes a storage layer isolation design, which allocates an independent database instance to each tenant to store core business data, including order, user, and revenue sharing records. Public data is stored in a shared database using tenant identifier sharding, including ticketing templates and city dictionaries.

[0009] A hierarchical permission model is designed based on the constructed SaaS tenant system to achieve permission management. The hierarchical permission model adopts a three-level hierarchical configuration and implements permission control through a dynamic policy engine. The three-level hierarchical configuration includes: service provider administrator permissions cover the entire lifecycle management of tenants and global configuration modification; franchisee administrator permissions are limited to data access of tenants whose identifiers match theirs; and tenant administrator permissions are limited to data operations and configuration adjustments within the current tenant. The dynamic policy engine implements permission control by including a dual permission verification process: initial permission verification based on roles and additional condition verification based on attributes.

[0010] By adopting the above scheme, the venue is established as the main tenant and assigned a unique identifier, and the franchisee attribute information is forcibly associated, thereby realizing centralized management and personalized services for each franchise venue; a hybrid data isolation architecture is adopted, which allocates an independent database to store core business data for tenants and uses tenant identifiers to shard public data to a shared database, thereby achieving effective data isolation; a three-level hierarchical mode is adopted to configure a hierarchical permission model and a dual permission verification process is carried out through a dynamic policy engine to achieve fine-grained permission management, and different permission subjects access corresponding data according to their permission scope.

[0011] Preferably, the construction of the SaaS tenant system further includes: personalized and standardized configuration for each tenant entity; including: establishing a dedicated configuration table for each tenant to store personalized parameters, the dedicated configuration table including: brand configuration fields for storing venue identification, interface color scheme and SMS signature, business rule fields for setting ticket refund time limit and revenue settlement cycle, and function switch fields for controlling the activation status of third-party payment access or membership points function; and setting up a shared configuration library to uniformly store the basic configuration rules followed by all tenants.

[0012] By adopting the above approach, a dedicated configuration table is created for each tenant to store personalized parameters, which can meet the tenant's personalized needs in terms of brand, business rules, and function switches. Setting up a shared configuration library to uniformly store the basic configuration rules followed by all tenants can ensure service compliance and achieve a balance between personalization and standardization in tenant-level software system configuration.

[0013] Preferably, the construction of the SaaS tenant system further includes: constructing an account management system; the construction of the account management system includes: generating accounts using tenant identifiers and username naming rules; restricting the permissions of sub-accounts to not exceed those of the parent account through a hierarchical inheritance mechanism; and automatically locking all associated accounts and retaining the data until a preset cleanup period after a tenant is deactivated.

[0014] By adopting the above scheme, generating accounts using tenant identifiers and username naming rules can avoid cross-tenant account conflicts. The hierarchical inheritance mechanism restricts the permissions of sub-accounts from exceeding those of the parent account, ensuring reasonable allocation of permissions. Automatically locking all associated accounts and retaining data until the preset cleanup cycle after a tenant is deactivated can prevent invalid tenants from occupying resources, while ensuring compliant data storage.

[0015] Preferably, the data isolation implementation further includes: setting transparent routing; including: passing tenant context information through the request chain, the tenant context information including tenant identifier and franchisee identifier; and automatically adapting database routing, cache key prefix and message queue partition according to the tenant context.

[0016] By adopting the above scheme, tenant context information containing tenant identifier and franchisee identifier is transmitted throughout the request chain, realizing tenant context penetration; database routing, cache key prefix and message queue partition are automatically adapted according to the tenant context, enabling automatic database routing, avoiding cross-tenant cache pollution, ensuring that tenant messages are consumed independently and do not compete for resources with other tenants, thereby achieving data isolation.

[0017] Preferably, the storage layer isolation design further includes an encrypted storage step, comprising:

[0018] Generate an independent encryption key for each tenant; perform differentiated encryption processing on tenant data that is sensitive data; among them, the revenue sharing amount data that is sensitive data uses asymmetric encryption and can only be decrypted by a preset role.

[0019] By adopting the above scheme, an independent encryption key is generated for each tenant to strengthen the encryption of sensitive data; asymmetric encryption is used for the revenue sharing data and decryption is only allowed for preset roles to ensure the security of sensitive data and the controllability of access.

[0020] Preferred options also include:

[0021] Perform audit tracking and audit log management; including: storing intra-tenant operation logs and cross-tenant operation logs in separate databases and audit centers respectively; the audit logs support tracing specific operation trajectories by operation type, user identity or time range, and record verification credential information.

[0022] By adopting the above solution, the operation logs within a tenant and the operation logs across tenants are stored separately to avoid interference between log data; and the management audit logs support tracing specific operation trajectories and recording verification credential information by operation type, user identity or time range, thus meeting compliance audit requirements.

[0023] Preferred options also include:

[0024] Data access protection includes: intercepting cross-tenant data access operations, forcibly attaching tenant IDs and prohibiting requests with empty or forged tenant IDs; and performing secondary verification of access permissions by sending CAPTCHAs for sensitive data access operations.

[0025] By adopting the above scheme, cross-data access operations are intercepted to prevent tenant data from being accessed illegally across tenants; secondary verification is performed on sensitive data access operations to further ensure the security of sensitive data access and enhance the protection capabilities of tenant data access.

[0026] Secondly, this application provides a distributed SaaS ticketing system data isolation and access control system, including:

[0027] The SaaS tenant system construction module is used to build the SaaS tenant system, including: establishing the venue as the main tenant and assigning a unique identifier; forcibly associating each tenant with the franchisee attribute information, which includes the franchisee's unique identifier, franchisee name, and franchisee level; controlling the tenant's lifecycle through enabled, disabled, or pending review status, and automatically freezing the corresponding data access permissions in the disabled status;

[0028] The data isolation module is used to adapt the hybrid data isolation architecture of the venue tenants according to the constructed SaaS tenant system to achieve data isolation. The hybrid data isolation architecture includes a storage layer isolation design, which allocates an independent database instance to each tenant to store core business data, including order, user and revenue sharing records; and uses tenant identifiers to shard public data to a shared database, including ticketing templates and city dictionaries.

[0029] The permission management module is used to design a hierarchical permission model based on the constructed SaaS tenant system to achieve permission management. The hierarchical permission model adopts a three-level hierarchical configuration and implements permission control through a dynamic policy engine. The three-level hierarchical configuration includes: service provider administrator permissions covering the entire lifecycle management of tenants and global configuration modification; franchisee administrator permissions are limited to data access of tenants whose identifiers match theirs; and tenant administrator permissions are limited to data operations and configuration adjustments within the current tenant. The dynamic policy engine implements permission control through a dual permission verification process: initial permission verification based on roles and additional condition verification based on attributes.

[0030] By adopting the above solution, the tenant entity is clearly defined and associated with the franchisee attributes, effectively managing the tenant lifecycle, achieving physical isolation of core business data and logical isolation of public data, and implementing three-tiered access control and dual access verification for service providers, franchisees, and tenants, ensuring data security and reasonable access allocation.

[0031] Thirdly, this application provides a computer-readable storage medium including a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to perform the method described above.

[0032] Fourthly, this application provides a computer device, the computer device including a memory, a processor and a program stored in the memory and executable thereon, the program being executed by the processor to implement the steps of the method described above.

[0033] In summary, this application has the following beneficial effects:

[0034] 1. Based on the SaaS service model, a SaaS tenant system is built, establishing venues as the main tenant entities and assigning them unique identifiers to avoid the separation of tenant and venue identifiers. The association of franchisee attribute information solidifies the "venue-franchisee" attribution relationship. Tenant lifecycle management through status control prevents invalid tenants from consuming resources, thereby achieving centralized management and personalized services for each franchise venue. Adapting to a hybrid data isolation architecture, independent databases are allocated to tenants to store core business data, while public data is stored in shards using tenant identifiers, avoiding data confusion, reducing database management complexity and cost, and ensuring data isolation. A hierarchical permission model is designed, employing a three-level hierarchical configuration and a dynamic policy engine for dual permission verification, enabling fine-grained adaptation to permission requirements and meeting complex and ever-changing business scenarios and dynamic permission needs.

[0035] 2. Generating an independent encryption key for each tenant and performing differentiated encryption on sensitive tenant data can enhance data security. Asymmetric encryption of revenue sharing data and limiting decryption to preset roles further ensures controllable access to sensitive data, thereby preventing the leakage of sensitive data, especially revenue sharing data.

[0036] 3. Implement audit log management and data access protection to enhance security and auditing, complete closed-loop risk control, and ensure the efficient operation of the system. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating the data isolation and access control method of the distributed SaaS ticketing system described in a specific embodiment;

[0038] Figure 2 This is a schematic diagram of the role-based access control model structure in the data isolation and access control method of the distributed SaaS ticketing system described in a specific embodiment;

[0039] Figure 3 This is a schematic diagram of the data isolation and access control system of the distributed SaaS ticketing system described in a specific embodiment. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0041] For distributed SaaS ticketing systems (including WeChat mini programs or apps that provide ticketing transactions, public account information publishing, and customer service, OpenAPI interfaces that connect with third-party ticketing platforms, and SaaS ticketing transaction systems that include online and on-site transaction systems, user systems, basic inventory management systems, order systems, coupon systems, and reconciliation and settlement systems), this application supports multi-tenancy, such as different cinemas, performance organizers, and event organizers sharing the system. To ensure that multi-tenant data is not leaked and that business data is accessed in a controlled manner according to permissions, this application mainly adopts a system construction, data isolation, and layered access control scheme, which achieves the effect of improving the data isolation and access control of distributed SaaS ticketing systems. The following is a further detailed description of this application.

[0042] like Figure 1 As shown in the figure, this application discloses a data isolation and permission management method for a distributed SaaS ticketing system, which specifically includes the following steps: building a SaaS tenant system, adapting a hybrid data isolation architecture, and designing a hierarchical permission model.

[0043] S1. Build a SaaS tenant system.

[0044] Considering that the distributed SaaS ticketing system supports multi-tenant sharing, in order to achieve data security among multiple tenants and controllable access to business data according to permissions, a SaaS-based service model is designed, in which the venue is regarded as a SaaS tenant entity; the service provider is the main operator of the venue, and the franchisee is an important attribute in the tenant system. They are closely integrated with the venue entity and together constitute a service node in the service provider network, realizing centralized management and personalized services for each franchise venue.

[0045] Specifically, the first step is to establish the venue as the tenant entity and assign it a unique identifier. This includes treating each venue as an independent SaaS tenant and assigning it a unique identifier. This unique identifier can be a numerical code, a combination of letters, or something similar, such as "venue 001," to avoid separating the tenant from the venue identifier and to ensure that each venue has a clear identity within the system.

[0046] Secondly, the system mandates the association of franchisee attribute information with each tenant. This means that franchisee attributes are forcibly associated in the tenant's core table, with fields including franchisee attribute information. This franchisee attribute information includes: a unique franchisee identifier (e.g., Franchisee ID), a franchisee name, and a franchisee level. The unique franchisee identifier can be a specific string of numbers or letters, such as "Franchisee A01"; the franchisee name is the franchisee's specific name, such as "XX Ticketing Franchisee"; and the franchisee level can be categorized as provincial, municipal, or based on franchisee size. By forcibly associating franchisee attributes, the system ensures a solidified venue-franchisee affiliation, and that franchisees exist only as tenant attributes, not as separate data isolation units. This prevents data complexity caused by isolating franchisee data separately and ensures data isolation for franchisees within the corresponding venue.

[0047] Finally, tenant status management is configured to control the tenant lifecycle through enabled, disabled, or pending approval statuses. In the disabled state, corresponding data access permissions are automatically frozen. Service providers can set tenant statuses based on their actual circumstances. When a tenant is disabled, the system automatically freezes all data access permissions for that tenant to prevent invalid tenants from consuming resources. For example, if a venue has not conducted business for an extended period, the service provider can set its tenant status to disabled.

[0048] S2. Adapt the hybrid data isolation architecture of the venue tenants to the constructed SaaS tenant system to achieve data isolation.

[0049] Specifically, based on the SaaS tenant system, a hybrid data isolation architecture (physical and logical isolation) was designed to adapt to venue tenants in order to achieve multi-tenant data isolation. Physical isolation was designed for core data (such as orders, users, and revenue sharing records) to ensure that the core data of each venue tenant is not leaked, thus achieving the security and independence of core business data. Logical isolation was designed for non-core data (such as ticket templates, city dictionaries, card usage rules, and validity periods) to achieve the sharing and efficient utilization of public data and reduce the database construction cost of a single tenant.

[0050] Specifically, a storage layer isolation design is implemented, allocating an independent database instance to each tenant to store core business data. Each tenant's independent database instance is like an independent data warehouse, accessible only to the corresponding tenant account. For example, venue 001's order, user, and revenue sharing records are all stored in its independent database instance. Public data is stored in a shared database using tenant identifier sharding. The shared database is analogous to a public data warehouse, with different tenants' public data sharded and stored within it based on their tenant identifiers. For example, ticketing templates for different venues are stored in different areas of the shared database according to their tenant identifiers. During queries, the venue tenant identifier is automatically appended to ensure that only the template corresponding to that tenant is returned.

[0051] Taking revenue sharing data isolation as an example, the tenant revenue sharing details table is stored in the tenant's independent database, with fields including tenant identifier and franchisee identifier; the franchisee revenue sharing summary table is stored in the service provider's shared database, and is stored in shards according to franchisee identifier and time, and is automatically generated by aggregating the revenue sharing details of each tenant.

[0052] In addition, to further enhance the regionality of venues, secondary identifier fields such as venue ID and city code can be forcibly included in the database tables corresponding to the shared database. When the amount of data for a single city reaches a preset threshold, a secondary regional sharding operation will be performed.

[0053] Based on the hybrid data isolation architecture adapted to venue tenants, the core data and public data of a single tenant are stored in an appropriate manner, thereby achieving core data isolation between different tenants.

[0054] S3. Design a hierarchical permission model based on the constructed SaaS tenant system to achieve permission management.

[0055] To flexibly respond to complex and ever-changing business scenarios and dynamic permission requirements, a hierarchical permission model is designed. Specifically, a three-level hierarchical model is designed to clarify the permission scope of different subjects, and then a dynamic policy engine is used to achieve fine-grained permission control.

[0056] Specifically, a three-tiered configuration model is adopted, clearly defining the subjects and scope of permissions at each level.

[0057] The three-tiered hierarchical configuration includes: First, a service provider administrator as the primary permission holder, with defined permissions covering tenant lifecycle management, global configuration modification, and auditing of all tenant data. This means the service provider administrator's permissions cover the entire tenant lifecycle and global configuration modification, allowing access to all tenant data. Second, a franchisee administrator as the primary permission holder, with defined permissions for viewing their tenant data, summarizing franchisee revenue, and monitoring tenant status. This means the franchisee administrator's permissions are limited to accessing tenant data matching their identifier. Third, a tenant administrator as the primary permission holder, with defined permissions for managing tenant accounts, modifying business configurations, and operating tenant data. This means the tenant administrator's permissions are limited to data operations and configuration adjustments within the current tenant. Additionally, a four-tiered hierarchical model can be used, such as adding an intermediate-level administrator role.

[0058] Access control implemented through a dynamic policy engine includes a dual access verification process: initial access verification based on roles and additional access verification based on attributes.

[0059] The initial permission verification based on roles uses the RBAC basic permission configuration as a scope to determine whether the current operation exceeds the permissions of the current role, such as... Figure 2 As shown, for each (venue) tenant, the tenant administrator (user) creates a corresponding tenant role and establishes a user-role association table. Different roles are set with corresponding permissions, and a role-permission association table is established. For example, the venue employee 1 (user) corresponding to venue 001 (tenant) has a role 1 (store manager), and role 1 is bound to and granted permissions A, B, C, and D; the venue employee 2 (user) corresponding to venue 002 (tenant) has roles 2 (store clerk) and 3 (store clerk), and role 2 is bound to and granted permission C, and role 2 is bound to and granted permission D.

[0060] In addition to role-based initial permission verification, the system also utilizes an ABAC dynamic policy engine to implement attribute-based additional condition verification. The ABAC policy engine matches conditions in real time based on operation attributes. Specifically, different attributes (such as subject attributes (user ID, tenant ID, franchisee ID), resource attributes (orders / ticketing / revenue sharing), and environment attributes (read / write / delete)) correspond to dynamically set policy rules. For example, policy rule 1: Franchisee administrators can only view the revenue sharing summary of their tenants; policy rule 2: Venue administrators cannot modify orders older than 30 days. The policy execution process is as follows: when a request arrives, the subject, resource, and environment attributes are extracted, relevant policies are matched according to the policy engine, policies are executed according to priority (negative policies take precedence over positive policies), and a final decision (allow or deny) is returned.

[0061] The above dual permission verification process, which combines role-based initial permission verification and attribute-based additional condition verification, specifically includes the following steps: When a user initiates a request, the system first performs role-based initial permission verification to determine whether the user's role has the corresponding basic permissions. Then, it performs attribute-based additional condition verification, i.e., verification based on attribute matching conditions. Only after both verifications pass will the system automatically attach data permission conditions and execute data operations.

[0062] The above solution addresses the issues of data isolation and access control in complex scenarios for existing franchisees, improves the efficiency and flexibility of database management, and enhances the precision of data isolation and access control in the distributed SaaS ticketing system.

[0063] In a specific embodiment, to further enhance the user experience and data security of the distributed SaaS ticketing system, making the system more flexible and efficient, it is also possible to add personalized and standardized configurations and an account management system. Personalized and standardized configurations can meet the individual needs of tenants while ensuring service compliance and consistency; the account management system ensures the uniqueness and security of accounts within a tenant, as well as the reasonable management of account lifecycles. The method for constructing the SaaS tenant system also includes:

[0064] Personalized and standardized configurations are made for each tenant entity.

[0065] Specifically, a dedicated configuration table is created for each tenant to store personalized parameters. The dedicated configuration table includes: a brand configuration field for storing venue identification, interface color scheme and SMS signature; a business rule field for setting ticket refund time limit and revenue settlement cycle; and a function switch field for controlling the activation status of third-party payment access or membership points function. A shared configuration library is set up to uniformly store the basic configuration rules followed by all tenants.

[0066] For example, "Venue 001" can be set with a unique logo, a red color scheme for the ticketing page, and "Venue 001 Ticketing" in the SMS signature. It can also be set to allow ticket refunds within 7 days, monthly settlement with franchisees, and enable membership points and support Alipay payment. In terms of basic configuration, it can include ticketing encryption algorithms, order timeout time, etc.

[0067] Establish an account management system.

[0068] Specifically, the account management system includes: generating accounts using tenant identifiers and username naming rules; users are users of the SaaS system platform, defining a set of related roles. In the current business scenario, users are venue employees, allowing the same user to work across tenants, with different roles for different tenants, thus working for one or more venues. However, to avoid cross-tenant account conflicts, each user must be bound to the current tenant to generate a corresponding user account, such as "Venue 001_Operator 01". Tenant super administrators can create sub-accounts, such as venue operators and accountants, and restrict sub-account permissions to not exceed those of the parent account through a hierarchical inheritance mechanism; automatically locking all associated accounts and retaining data until a preset cleanup period after a tenant is deactivated; for example, after a tenant is deactivated, all associated accounts are automatically locked, and data is retained for 180 days before being cleaned up according to compliance requirements.

[0069] In one specific embodiment, to further enhance the data isolation and security performance of the distributed SaaS ticketing system, transparent routing settings and encrypted storage steps were added. Transparent routing settings enable the system to automatically adapt the database, cache, and message queue based on the tenant context, improving system response speed and resource utilization efficiency. Encrypted storage design enhances the security of tenant data, particularly the protection of sensitive data, meeting the system's data security requirements. The method further includes:

[0070] Transparent routing settings; specifically including: tenant context penetration and middleware auto-adaptation.

[0071] The request entry point (API gateway) identifies tenants through request headers, stores the tenant ID and franchisee ID locally, and transmits tenant context information throughout the entire request chain. This tenant context information includes the tenant identifier and franchisee identifier to ensure the tenant identifier is not lost throughout the service call chain. Based on the tenant context, database routing, cache key prefixes, and message queue partitions are automatically adapted; that is, the system automatically routes to the corresponding data storage node based on the tenant identifier, maintaining consistent tenant isolation rules across database, cache, and message queue components. For example, taking an order query for Venue 001 as an example, when a user (the administrator of Venue 001) initiates an order query request through their user account, the front end carries the tenant identifier in the request header. After the API gateway intercepts the request, it parses and extracts the tenant identifier, directly routing to the tenant database without needing to consider tenant routing.

[0072] The storage layer isolation design process also includes encrypted storage steps, specifically including:

[0073] A unique encryption key is generated for each tenant and stored in KMS in encrypted form by the service provider’s master key (MK).

[0074] Specifically, tenant data classified as sensitive data undergoes differentiated encryption processing. Revenue sharing amount data, which is considered sensitive data, uses asymmetric encryption, allowing decryption only by preset roles (e.g., only the tenant's financial account and service provider account can decrypt it). Tenant user mobile phone numbers, which are also considered sensitive data, are encrypted using AES-256. For example, the revenue sharing amount for "Venue 001" uses an asymmetric encryption algorithm, and only the venue's financial account and service provider account can decrypt it.

[0075] In a specific embodiment, to further improve the data isolation and access control system of the distributed SaaS ticketing system, audit trails and audit log management are added to assist data traceability and achieve closed-loop risk control. Through audit trails and log management, the operation process is traceable, enabling traceability personnel to promptly detect abnormal data exports or unauthorized access. The method also includes:

[0076] Perform audit tracking and audit log management; including: storing intra-tenant operation logs and cross-tenant operation logs in separate databases and audit centers respectively; the audit logs support tracing specific operation trajectories by operation type, user identity or time range, and record verification credential information.

[0077] Specifically, tenant operation logs are stored in a separate database for each tenant, recording all user operations within that tenant, such as ticket sales operations by venue operators and accounting operations by finance staff. Cross-tenant operation logs are stored in the service provider's audit center, recording operations such as franchisees viewing multi-tenant data and service providers modifying tenant configurations, and the data is retained for N years. Logs can be retrieved by ID and operation type, allowing traceability of the creator / modifier, time, and IP address of each data entry, meeting compliance audit requirements.

[0078] In one specific embodiment, to improve system data security and prevent unauthorized access and data leakage, the method further includes:

[0079] Data access protection includes: intercepting cross-tenant data access operations, forcibly attaching the tenant ID and prohibiting requests with empty or forged tenant IDs; for example, when a cross-tenant data access request enters the system, the MyBatis interceptor will forcibly attach the tenant ID, and if the tenant ID is empty or forged, the API gateway will prohibit the request.

[0080] For sensitive data access operations, a secondary verification of access permissions is completed by sending a verification code; for example, when a tenant super administrator performs sensitive operations such as modifying the revenue sharing rules or deleting an order, a dual verification of mobile phone verification code and email verification will be used.

[0081] like Figure 3As shown in the figure, this application provides a distributed SaaS ticketing system data isolation and access control system, specifically including:

[0082] The SaaS tenant system construction module 101 is used to build a SaaS tenant system, including: establishing the venue as the tenant entity and assigning a unique identifier; forcibly associating each tenant with the franchisee attribute information, which includes the franchisee's unique identifier, franchisee name, and franchisee level; controlling the tenant's lifecycle through enabled, disabled, or pending review status, and automatically freezing the corresponding data access permissions in the disabled status.

[0083] Data isolation module 102 is used to adapt the hybrid data isolation architecture of venue tenants according to the constructed SaaS tenant system to achieve data isolation; the hybrid data isolation architecture includes a storage layer isolation design, allocating an independent database instance to each tenant to store core business data, the core business data including order, user and revenue sharing records; and using tenant identifiers to shard public data to a shared database, the public data including ticketing templates and city dictionaries;

[0084] The permission management module 103 is used to design a hierarchical permission model based on the constructed SaaS tenant system to achieve permission management. The hierarchical permission model adopts a three-level hierarchical configuration and implements permission control through a dynamic policy engine. The three-level hierarchical configuration includes: service provider administrator permissions cover the entire lifecycle management of tenants and global configuration modification; franchisee administrator permissions are limited to data access of tenants whose identifiers match theirs; and tenant administrator permissions are limited to data operations and configuration adjustments within the current tenant. The dynamic policy engine implements permission control by including a dual permission verification process of initial permission verification based on roles and additional condition verification based on attributes.

[0085] In one specific embodiment, the system further includes:

[0086] The security and audit enhancement module 104 is used to store intra-tenant operation logs and cross-tenant operation logs in an independent database and an audit center, respectively. The audit logs support tracing specific operation trajectories by operation type, user identity, or time range, and record verification credential information. It is also used to intercept cross-tenant data access operations, forcibly attach the tenant ID, and prohibit requests with empty or forged tenant IDs. For sensitive data access operations, it completes secondary verification of access permissions by sending a verification code.

[0087] This application also discloses a computer-readable storage medium.

[0088] Specifically, the computer-readable storage medium stores a computer program that can be loaded by a processor and executed, such as the data isolation and access control method of the distributed SaaS ticketing system described above. The computer-readable storage medium includes, for example, various media that can store program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0089] This application also discloses a computer device.

[0090] Specifically, the computer device includes a memory and a processor, and the memory stores a computer program that can be loaded by the processor and executed to implement the data isolation and access control method of the distributed SaaS ticketing system described above.

[0091] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for data isolation and access control in a distributed SaaS ticketing system, characterized in that, include: The SaaS tenant system is constructed, including: establishing venues as the main tenant entities and assigning them unique identifiers; forcibly associating each tenant with franchisee attribute information, including the franchisee's unique identifier, franchisee name, and franchisee level; controlling the tenant lifecycle through enabled, disabled, or pending approval status, and automatically freezing the corresponding data access permissions in the disabled status. The SaaS tenant system is adapted to the venue tenants' hybrid data isolation architecture to achieve data isolation. The hybrid data isolation architecture includes a storage layer isolation design, which allocates an independent database instance to each tenant to store core business data, including order, user, and revenue sharing records. Public data is stored in a shared database using tenant identifier sharding, including ticketing templates and city dictionaries. A hierarchical permission model is designed based on the constructed SaaS tenant system to achieve permission management. The hierarchical permission model adopts a three-level hierarchical configuration and implements permission control through a dynamic policy engine. The three-level hierarchical configuration includes: service provider administrator permissions cover the entire lifecycle management of tenants and global configuration modification; franchisee administrator permissions are limited to data access of tenants whose identifiers match theirs; and tenant administrator permissions are limited to data operations and configuration adjustments within the current tenant. The dynamic policy engine implements permission control through a dual permission verification process: initial permission verification based on roles and additional condition verification based on attributes. The data isolation implementation also includes: setting transparent routing; including: passing tenant context information throughout the request chain, the tenant context information including tenant identifier and franchisee identifier; automatically adapting database routing, cache key prefix and message queue partition according to the tenant context; The storage layer isolation design also includes encrypted storage steps, including: Generate a unique encryption key for each tenant; perform differentiated encryption processing on tenant data that is sensitive data; among them, the revenue sharing amount data that is sensitive data uses asymmetric encryption and can only be decrypted by a preset role; It also includes: conducting audit trails and managing audit logs; including: storing intra-tenant operation logs and cross-tenant operation logs in separate databases and audit centers respectively; the audit logs support tracing specific operation trajectories by operation type, user identity, or time range, and recording verification credential information; It also includes: data access protection, including: intercepting cross-tenant data access operations, forcibly attaching tenant IDs and prohibiting requests with empty or forged tenant IDs; and completing secondary verification of access permissions by sending verification codes for sensitive data access operations.

2. The data isolation and access control method for a distributed SaaS ticketing system according to claim 1, characterized in that, The construction of the SaaS tenant system also includes: personalized and standardized configuration for each tenant entity; including: establishing a dedicated configuration table for each tenant to store personalized parameters, the dedicated configuration table including: brand configuration fields for storing venue identification, interface color scheme and SMS signature, business rule fields for setting ticket refund time limit and revenue settlement cycle, and function switch fields for controlling the activation status of third-party payment access or membership points function; setting up a shared configuration library to uniformly store the basic configuration rules followed by all tenants.

3. The data isolation and access control method for a distributed SaaS ticketing system according to claim 1, characterized in that, The construction of the SaaS tenant system also includes: building an account management system; the construction of the account management system includes: generating accounts using tenant identifiers and username naming rules; restricting the permissions of sub-accounts to not exceed those of the parent account through a hierarchical inheritance mechanism; automatically locking all associated accounts and retaining data until a preset cleanup period after a tenant is deactivated.

4. A distributed SaaS ticketing system data isolation and access control system, characterized in that, include: The SaaS tenant system construction module is used to build the SaaS tenant system, including: establishing the venue as the main tenant and assigning a unique identifier; forcibly associating each tenant with the franchisee attribute information, which includes the franchisee's unique identifier, franchisee name, and franchisee level; controlling the tenant's lifecycle through enabled, disabled, or pending review status, and automatically freezing the corresponding data access permissions in the disabled status; The data isolation module is used to adapt the hybrid data isolation architecture of venue tenants to achieve data isolation based on the constructed SaaS tenant system. The hybrid data isolation architecture includes a storage layer isolation design, allocating an independent database instance to each tenant to store core business data, including order, user, and revenue sharing records; and storing public data in a shared database using tenant identifier sharding, including ticketing templates and city dictionaries. The data isolation implementation also includes setting transparent routing, including: passing tenant context information throughout the request chain, including tenant identifiers and franchisee identifiers; and automatically adapting database routing, cache key prefixes, and message queue partitions based on the tenant context. The access control module is used to design a hierarchical access control model based on the constructed SaaS tenant system to achieve access control. The hierarchical access control model adopts a three-tier configuration and implements access control through a dynamic policy engine. The three-tier configuration includes: service provider administrator permissions covering the entire lifecycle management of tenants and global configuration modifications; franchisee administrator permissions limited to data access by tenants matching their identifiers; and tenant administrator permissions limited to data operations and configuration adjustments within the current tenant. The dynamic policy engine implements access control through a dual access verification process: initial access verification based on roles and additional condition verification based on attributes. The storage layer isolation design also includes encrypted storage steps, including: Generate a unique encryption key for each tenant; perform differentiated encryption processing on tenant data that is sensitive data; among them, the revenue sharing amount data that is sensitive data uses asymmetric encryption and can only be decrypted by a preset role; The security and audit enhancement module is used for audit tracing and audit log management; it includes: storing intra-tenant operation logs and cross-tenant operation logs in separate databases and the audit center respectively; the audit logs support tracing specific operation trajectories by operation type, user identity, or time range, and recording verification credential information; it is also used to intercept cross-tenant data access operations, forcibly attach tenant IDs and prohibit requests with empty or forged tenant IDs; and for sensitive data access operations, it completes secondary verification of access permissions by sending verification codes.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the method as described in any one of claims 1 to 3.

6. A computer device, characterized in that, The computer device includes a memory, a processor, and a program stored in and executable on the memory, the program being executed by the processor to implement the steps of the method as described in any one of claims 1 to 3.

Images