Tourism data access control method and system, terminal and medium
By constructing a contextual expression vector and a risk perception mechanism, access risks are dynamically assessed and temporary access tokens are generated, solving the dynamic and security issues of access control in the cultural tourism IoT environment. This enables the identification, adjustment, and traceability of access behavior, improving the security and management efficiency of data access.
Patent Information
- Application Number
- CN202511714737.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-21
- Publication Date
- 2026-02-13
AI Technical Summary
In the existing cultural tourism IoT environment, the access control system lacks the ability to comprehensively judge the context of access requests, the intention of visitors’ behavior, and the dynamic changes of the IoT environment. This makes it difficult for the system to accurately judge risks when facing high concurrency, cross-device, and cross-organization data access. It is also unable to effectively manage short-term authorization and cross-domain data use, resulting in problems such as permission residue, data overreach, or untraceable access trajectories.
By constructing context expression vectors, risk perception mechanisms, dynamic path decision-making logic, boundary token authorization mechanisms, and behavior auditing systems, a complete access control closed loop is formed. Through access request context vectors in a unified format, joint evaluation models, temporary access tokens, and behavior auditing, access behavior can be identified, adjusted, and traced.
It enables dynamic risk assessment and access control in the cultural tourism IoT environment, improves the flexibility and security of access control, ensures data security, and is suitable for refined management in scenarios with multiple devices, multiple subjects, and highly sensitive data.
Smart Images

Figure CN121530671A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of data monitoring and management, and more particularly to a method, system, terminal, and medium for access control of cultural and tourism data. Background Technology
[0002] As the intelligent transformation of the cultural and tourism industry continues to deepen, various types of IoT devices have been widely deployed in cultural and tourism venues such as scenic spots, museums, and theme parks, including high-definition video surveillance terminals, mobile tour guide terminals, smart ticketing recognition systems, tourist behavior collection devices, and intelligent customer service robots.
[0003] These devices have played a positive role in enhancing the tourist experience, assisting in operational scheduling, and optimizing service quality. However, they also generate a large amount of real-time, multi-dimensional, and high-frequency data, which often contains sensitive information such as tourist identity, travel routes, consumption records, and device location information. Due to the complexity of cultural and tourism data and the large number of stakeholders, access is no longer limited to internal scenic area employees but also includes OTA platforms, partner merchants, event organizers, and government regulatory agencies, resulting in frequent and diverse access requests. Existing access control systems mostly employ role- or attribute-driven static configuration mechanisms, lacking the ability to comprehensively assess the context of access requests, visitor intent, and dynamic changes in the IoT environment. This makes it difficult for the system to accurately assess risks when facing high concurrency, cross-device, and cross-organizational data access. Furthermore, traditional permission models cannot effectively manage short-term authorizations and cross-domain data use; even after authorization ends, there may still be residual permissions, unauthorized data access, or untraceable access trajectories. Especially in the cultural and tourism IoT environment, data flow paths are complex, and access devices are widely distributed. Existing solutions generally lack context awareness and real-time risk adjustment capabilities, and have not established a unified management mechanism for permission lifecycles and access behavior. These shortcomings prevent the system from ensuring data security while meeting flexible business needs.
[0004] Therefore, there is an urgent need to propose an access control method for cultural tourism IoT scenarios that has the ability to dynamically model contexts, assess risks, and control boundaries, so as to make access behavior identifiable, adjustable, and traceable, and provide practical technical support for the secure use of cultural tourism data. Summary of the Invention
[0005] This invention proposes a control method, system, terminal, and medium for the cultural tourism Internet of Things environment. By constructing a context expression vector, risk perception mechanism, dynamic path decision logic, boundary token authorization mechanism, and behavior auditing system, a complete access control closed loop is formed.
[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: In a first aspect of the present invention, a method for access control of cultural and tourism data is provided, comprising the following steps: Cultural and tourism data is collected in the cultural and tourism platform. The cultural and tourism data includes visitor data, requested data resources, visitor role, terminal device number that initiated the request, request time, request initiation location area number, and the type of requested data and its corresponding data sensitivity level. The above cultural and tourism data is encoded and concatenated into an access request context vector in a unified format. A context-based dynamic risk assessment mechanism is introduced, and a joint assessment model of risk and data sensitivity is constructed to jointly assess the real-time elements of the access context, output the access risk level, and reflect the comprehensive risk of the access request. Construct an access path decision model, calculate access control decision scores through a comprehensive scoring function, and generate identifiers for visitor access requests based on the scoring results, such as denying access, entering the boundary permission process, and entering the regular access process. For access requests with access boundary permission process identifiers, a structured temporary access token is generated based on the request context, and its authorization conditions are clearly defined. After the token is generated, the platform encrypts and signs it and stores it in the permission token database. The database service uses a unique token ID for indexing. In subsequent accesses, the access control gateway verifies the token attached to the request. If the request does not meet the token conditions, the access permission is revoked and recorded. Actual verification is performed based on the boundary permission token, checking user ID matching, data resource matching, device ID consistency, access time validity, region validity, and access frequency limit in sequence. When all verification conditions are met, access control operations are executed, and the complete access behavior chain is recorded.
[0007] Preferably, the data sensitivity level is mapped from the type of the requested data, and the data sensitivity level includes a level code. , representing low, medium, and high sensitivity, respectively.
[0008] As a preferred option, a scenario correction rule term is introduced into the joint risk and data sensitivity assessment model to adaptively adjust the risk according to the regional characteristics and equipment status in the cultural and tourism environment, so that the risk assessment has dynamic scenario adaptive capability.
[0009] Preferably, the access path decision model outputs the access path that the current access request should enter. The access path includes: a regular access path that can be passed directly, an access path that requires additional boundary control, and an access denied path that is blocked by the system.
[0010] As a preferred approach, based on the calculated value of the comprehensive scoring function, two levels of policy thresholds are set: a low-risk tolerance threshold and a high-risk blocking threshold. The final access path selection rules are as follows: Access is denied if the calculated value of the comprehensive scoring function is greater than or equal to the high-risk tolerance threshold. When the calculated value of the comprehensive scoring function is greater than or equal to the low-risk tolerance threshold and less than the high-risk tolerance threshold, the boundary permission process is initiated. When the calculated value of the comprehensive scoring function is less than the low-risk tolerance threshold, the normal access process begins.
[0011] Preferably, the temporary access token includes the visitor ID bound to the token, the data resources that can be accessed under this authorization, the device ID that initiated the request, the valid time interval, and the geographical region of access, wherein the valid time interval is generated by extending a tolerance window before and after the time period to which it belongs.
[0012] As a preferred approach, for regular access paths, verification is performed only based on the role and permission table; for denied paths, a denial response is immediately returned and the process is terminated; for boundary access paths, the verification conditions must be met before the data release stage can begin.
[0013] In a second aspect of the invention, a cultural tourism data access control system is also provided, comprising: The data acquisition and processing module is used to collect cultural and tourism data in the cultural and tourism platform. The cultural and tourism data includes visitor data, requested data resources, visitor role, terminal device number that initiated the request, request occurrence time, request initiation location area number, and the type of requested data and its corresponding data sensitivity level. The above cultural and tourism data is encoded and concatenated into an access request context vector in a unified format. The risk and data sensitivity assessment module is used to introduce a context-based dynamic risk assessment mechanism, build a joint assessment model for risk and data sensitivity, and jointly assess the real-time elements of the access context to output the access risk level, reflecting the comprehensive risk of the access request. The access path determination module is used to build an access path decision model. It calculates the access control decision score through a comprehensive scoring function and generates identifiers for denying access, entering the boundary permission process, and entering the regular access process for the visitor's access request based on the score results. The permission token generation module is used to generate a structured temporary access token based on the request context for access requests with access boundary permission process identifiers, and to explicitly limit its authorization conditions. After the token is generated, the platform encrypts and signs it and stores it in the permission token database. The database service uses a unique token ID for indexing. In subsequent accesses, the access control gateway verifies the token attached to the request. If the request does not meet the token conditions, the access permission is revoked and recorded. The access control enforcement module is used to perform actual verification based on the boundary permission token. It sequentially checks the user ID matching, data resource matching, device ID consistency, access time validity, region validity, and access frequency limit. When all verification conditions are met, the access control operation is executed, and the complete access behavior chain is recorded.
[0014] A third aspect of the present invention provides an electronic device comprising: The system includes a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, performs any of the aforementioned cultural and tourism data access control methods.
[0015] In a fourth aspect, the present invention provides a storage medium storing a computer program that can be executed by one or more processors and can be used to implement the cultural and tourism data access control method described in any of the preceding claims.
[0016] The present invention provides a method, system, terminal, and medium for access control of cultural and tourism data, which, compared with the prior art, brings the following significant advantages: This invention proposes a data access control method for the cultural tourism IoT environment. It forms a complete access control closed loop by constructing a context expression vector, a risk perception mechanism, dynamic path decision logic, a boundary token authorization mechanism, and a behavior auditing system. First, this invention establishes a context expression model for access requests, uniformly encoding elements such as visitor identity, device type, time period, geographical region, and data sensitivity level to provide the system with computable context input. Second, considering the real-time nature and complexity of cultural tourism scenarios, a joint risk and data sensitivity assessment model is designed, incorporating dynamic correction factors such as regional congestion and device stability into the calculation to quantitatively determine access risks under different access environments. Third, this invention proposes an access path decision model based on risk scoring, data sensitivity, and visitor role level. By setting asymmetric penalty items and dual threshold intervals, it dynamically selects access paths, effectively distinguishing between regular access, boundary access, and access denial. For access requests requiring temporary authorization, this invention generates temporary permission tokens with multiple constraints on time, space, terminal, and access intensity, realizing a controllable and revocable authorization process. Finally, during the access execution phase, this invention designs an access control execution and behavior auditing mechanism based on token verification to verify, record, and trace access behavior in real time, forming a system-level security closed loop. Through this system, this invention not only overcomes the shortcomings of existing permission systems—static, coarse-grained, and untraceable—but also, by introducing a risk-driven boundary permission mechanism, enables access control to possess dynamic responsiveness and environmental adaptability. This makes it particularly suitable for refined data security management in the cultural and tourism industry, especially in scenarios involving multiple devices, multiple entities, and highly sensitive data. Attached Figure Description
[0017] Figure 1 This is a flowchart of a cultural and tourism data access control method according to the present invention.
[0018] Figure 2 This is a framework diagram of a cultural tourism data access control system according to the present invention.
[0019] Figure 3 This is a schematic diagram of an electronic device according to the present invention. Detailed Implementation
[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0021] Please see Figure 1 As shown, in a first aspect of the present invention, this application proposes a method for access control of cultural and tourism data, comprising the following steps: Step 1: Collect cultural and tourism data from the cultural and tourism platform. This data includes visitor data, requested data resources, visitor roles, the terminal device ID initiating the request, the request time, the region ID of the request originating from, and the type of requested data and its corresponding data sensitivity level. Encode this cultural and tourism data and concatenate it into a unified format access request context vector; specifically including: This step aims to perform contextual modeling on each access request, extract its key access information, and identify the data types and sensitivity levels involved in the request. Since there are numerous data types in the cultural and tourism scenario, such as scenic area video surveillance, tourist orders, and merchant promotions, and the requesting entities include tourists, staff, and partners, and the time, location, and device type of the request vary considerably, it is necessary to construct an access request expression with a unified format that can be directly used by subsequent calculation modules.
[0022] After receiving the access request, the system extracts the following basic information from each module: Visitor data is recorded as a variable. The identifier originates from the account number returned by the identity authentication module, which can be a visitor login ID, staff employee ID, or a third-party merchant ID assigned by the platform; the requested data resource identifier is denoted as... The visitor role is determined by information such as the resource path and call parameters in the access interface; the visitor role is denoted as... The information is returned by the access control system, such as "Visitor," "Staff," or "Merchant"; the terminal device ID that initiated the request is recorded as... The device code is extracted from the access channel to identify mobile terminals, POS machines, information guide devices, etc.; the time of the request is recorded as... The receiving time is determined by the system server; the request initiation location area number is denoted as... The type of data requested is determined by the access gateway or hotspot number and its geographic mapping relationship. The system through Path rule matching or resource tag mapping recognition, such as video, order, and text categories; the corresponding data sensitivity level is denoted as... ,Depend on Mapped from, its value is a level code. , representing low, medium, and high sensitivity, respectively.
[0023] The above fields are processed as follows: for , , , For identifier-type fields, the system converts them into integer codes using a number mapping table for subsequent vector concatenation; access time The time period type (e.g., nighttime, peak hours, public holidays) is mapped using a table lookup method before encoding; Visitor role It is a finite enumeration set, directly mapped to role number; data type With sensitivity level The mapping is given by the platform configuration table, for example: "monitoring class" corresponds to "Order Category" "Introduction" corresponds to .
[0024] Finally, the system encodes the above fields and concatenates them into a unified access request vector, denoted as: ; in, The access request context vector is a real vector of length 7; The visitor role number is an integer obtained from the role type mapping table; Encode visitor numbers, by Derived through identity system number mapping; The terminal device is assigned a unique identifier, which is obtained from the terminal access record mapping table. Data resource numbers are encoded and converted according to resource path matching rules; The requested area code is derived from the device location mapping table; Numbering time periods by timestamps Mapped to obtain; Data sensitivity level is determined by data type. The mapping table is provided.
[0025] For example, if tourist ID "1023" requests camera video data with ID "SC002" via mobile phone at night on a holiday, it can be identified that: , mapped to ; , mapped to ; , mapped to ; , mapped to ; , mapped to ; , mapped to (On holidays and at night); , mapped to .
[0026] The final vector formed is: .
[0027] This step transforms reliably collectable multi-source information from the actual system into a unified form of access request expression through structured extraction and standardized coding. This enhances the system's contextual expression capability while maintaining the consistency and scalability of model inputs, facilitating deployment and reproduction.
[0028] Step Two: Introduce a context-based dynamic risk assessment mechanism to construct a joint assessment model of risk and data sensitivity. This model is used to jointly assess real-time elements of the access context, outputting the access risk level and reflecting the comprehensive risk of the access request. Specifically, this includes: This step plays a core role in "risk perception and quantification" in the entire invention scheme and is a key link in access control strategy decision-making.
[0029] The task of this step is to determine whether an access request is acceptable in the current context by jointly evaluating real-time elements of the access context (visitor identity, access time, access terminal, access area, and data sensitivity) without relying on large-scale behavioral history. Compared to traditional permission systems that rely solely on roles and static rules, the innovation of this step lies in introducing a context-based dynamic risk assessment mechanism. This mechanism considers unique characteristics of the cultural tourism IoT scenario, such as time period, regional density, and terminal trustworthiness, in its risk calculation. Furthermore, it incorporates regularization terms in the risk calculation formula to correct abnormal access behavior in specific scenarios, enabling the system to maintain stable risk assessment capabilities even in complex multi-terminal environments.
[0030] In the risk assessment process, several risk contribution functions are first defined based on different access characteristics. Considering the characteristics of the cultural tourism IoT, three main sources of risk are identified: role risk, time risk, and terminal risk. Role risk measures the prior security coefficient of data accessed by different visitor roles; time risk reflects the potential for violations during the time period in which the access occurs; and terminal risk is used to assess the differences in the credibility of accessing devices. In addition, access behavior in cultural tourism scenarios is also affected by regional congestion and device signal stability. For example, frequent access to camera data in areas with high tourist density typically carries a higher risk of data leakage. Therefore, the system introduces an innovative scenario correction rule to dynamically adjust the overall risk score, ensuring that the risk model remains sensitive to changes in the actual environment.
[0031] The overall risk scoring model is designed as follows: ; in, Access risk level, range in This section reflects the overall risk of access requests. to For risk weighting coefficients, satisfying Its value is preset by the security policy and can be adjusted according to the scenario, such as during holidays or peak periods. The weighting was increased to enhance the influence of the time period factor; This represents a role-based risk function, where the system sets a fixed risk coefficient for different roles, such as for tourists. Staff members Managers ; The system represents a time-based risk function, mapping time periods such as day and night and holidays to risk factors. For example, visits at night or after park closure are set as risk factors. Access during weekdays is set to ; This represents a terminal trustworthiness risk function. The system sets a score based on device registration information and location verification results. For example, the risk value for a fixed tour guide device is... Personal mobile devices are .
[0032] in This is a scenario correction rule item, used to adaptively adjust risks based on regional characteristics and equipment status in a cultural and tourism environment. Its expression is: ; in, Indicates the current region The number of devices currently performing access operations is counted in real time by the edge nodes; This indicates the maximum safe concurrent access capacity of the region, which is set by the system during the deployment phase; This represents the device signal stability coefficient, calculated in real time by the device status monitoring module. Devices with high stability have lower values, while unstable devices have higher values. This value is... Fluctuations within a certain range are used to characterize additional risk corrections in cases of "local access congestion" or "signal anomalies". The weighting coefficient for the correction term is generally taken as... to Between these parameters, a dynamic correction item is used to control the degree of impact of the correction rules. The innovation of this design lies in the introduction of a dynamic correction item unique to the cultural tourism IoT scenario into the risk scoring for the first time. This allows the risk assessment to not only consider the static relationship between visitors and resources, but also reflect environmental changes and equipment load status in real time, thereby improving the timeliness and accuracy of risk perception.
[0033] For example, in area B of the scenic area, where there are many tourists, when the system detects that the number of devices accessing camera data in that area has reached 90% of the security capacity, The value is approximately 0.9, while if a tourist uses a mobile terminal ( The access was initiated by ) and the data type is highly sensitive video ( ), then in setting In the case of correction item Approximately The risk formula is calculated as follows: R=0.3×0.7+0.3×0.8+0.2×0.6+0.2×3 / 3+0.2×0.63=0.896; The risk value of this access request is evident. This indicates that the request is at an extremely high risk level, and the subsequent path decision module should automatically trigger the boundary permission authorization mechanism.
[0034] The calculation results access risk level It not only includes the independent risk contribution of each element in the access request context, but also modifies the rule items. The solution dynamically incorporates real-time changes in the cultural tourism IoT environment. It boasts three innovative features: first, it achieves fusion calculation of multi-source factors through a context-weighted risk aggregation model; second, it introduces regional congestion and equipment stability as risk correction factors for the first time, enabling dynamic scenario adaptation in risk assessment; and third, it employs a lightweight, interpretable computing structure that can run in real-time at the edge gateway without relying on complex training models. This risk assessment method, based on dynamic contextual features and scenario correction, provides a more flexible and real-time security foundation for cultural tourism data access control compared to traditional static strategies.
[0035] Step 3: Construct an access path decision model, calculate access control decision scores using a comprehensive scoring function, and generate identifiers for visitor access requests based on the scoring results, indicating whether access is denied, a boundary access process is initiated, or a regular access process is initiated; specifically including: This step occupies a central position in the entire system of this invention, and its main function is to calculate the risk score based on the previous step. Combined with the sensitivity level of the request data extracted in the first step Visitor role level This process determines which access path the current access request should take. These paths include: a direct, regular access path; an access path requiring additional boundary control; and a blocked access path. This step not only acts as an intermediary between "risk perception" and "permission execution," but also introduces a dynamic policy scheduling mechanism unique to this invention's scenario into the access control strategy. This ensures that the control logic is not only secure but also adaptable to the flexible operational needs of the cultural and tourism scenario.
[0036] In cultural and tourism scenarios, different types of data, different roles and equipment combinations will create drastically different access risks and permission boundaries. For example, tourists accessing monitoring equipment during peak hours should trigger the highest level of alert, while staff accessing the same data during working hours should have their authorization process simplified.
[0037] The core design innovation of this step lies in the use of a control decision scoring system. To unify and integrate the above three factors, an asymmetric penalty term is introduced. This is used to impose heavier penalties on specific combinations of "high-risk + low-level role" behaviors, thereby achieving a risk control preference that is more in line with the business logic of cultural and tourism scenarios. This preference is reflected in the fact that the system adopts stricter restriction policies when tourists access highly sensitive resources during unsafe times, while granting a certain risk tolerance window for trusted roles.
[0038] The comprehensive scoring function is defined as follows: ; in, This indicates the access control decision score, ranging from... ; , , For the weight parameters, satisfying This is used to balance the impact of risk score, data sensitivity, and role level on decision-making. An initial value of [value missing] is recommended. , , It can be adjusted according to the system strategy during operation.
[0039] The asymmetric risk penalty function is a key innovation of this step, and its definition is as follows: ; This item is used to give extra weight to the score for requests from visitors with low-level roles (such as tourists) who access highly sensitive data and have a high risk score. The weight of the penalty term is generally set to 1. , For example, to trigger a penalty threshold. Exceeding this value triggers a penalty. This design reflects the system's practical requirements for "asymmetric trust," even with risk scoring. The threshold is not extremely high, but if the visitor's role level is very low and the data sensitivity level is high, additional security controls will be implemented.
[0040] For example: a tourist ( ) Request to access a highly sensitive ( The video surveillance data has a risk score of [missing information]. When the system parameters are set to , , , , In this case, first calculate : ; Substitute these values into the overall scoring formula: ; Overall score of the request It is located in the middle to high range.
[0041] Based on the scoring results, the system sets two levels of policy thresholds: a low-risk tolerance threshold. High-risk lockdown threshold The final access path selection rules are as follows: ; Therefore, this access request will be classified as "entry into boundary access control process". The output of this step is the access control path identifier. This variable does not participate in the calculation but is an enumerated flag for control flow transitions, with values including "normal access", "boundary access", and "access denied". This flag is used by subsequent modules to determine whether to generate a boundary access token and further control the scope of permissions.
[0042] Step 4: For access requests with entry boundary permission flow identifiers, a structured temporary access token is generated based on the request context, explicitly defining its authorization conditions. After generation, the platform encrypts and signs the token and stores it in the permission token database. The database service uses a unique token ID for indexing. In subsequent accesses, the access control gateway verifies the token attached to the request. If the request does not meet the token conditions, access permission is revoked and recorded. Specifically, this includes: This step plays a key role in "temporary access control" within the overall architecture of this invention. Its goal is to generate a structured temporary access token based on the request context, after the third step has determined that the access request needs to enter the "boundary access path". It also clearly defines the authorization conditions to ensure that the system can effectively avoid problems such as excessive data exposure, permission residue and resource abuse while meeting certain access requirements.
[0043] In cultural and tourism scenarios, different roles often have numerous temporary needs for accessing sensitive data. For example, during holidays and events, tour guide systems may grant tourists access to some real-time data, or partner merchants may access tourists' preference and behavioral data after authorization. These accesses must possess characteristics such as "boundaries, revocation, and trusted device binding." The token generation method proposed in this step is specifically designed to address these non-persistent access characteristics in the cultural and tourism industry, particularly by integrating multi-factor control mechanisms such as terminal trust, access frequency limits, spatial binding, and time windows.
[0044] This step requires that the access path identifier variable output in the previous step has a value of "boundary access permission" before the system can proceed to the token generation process. The access request context vector obtained in step one is also needed as the basis for token construction. The variables have been defined and processed in the preceding steps and are all encoded numerical fields; additionally, the access risk score generated in the second step must be used. This parameter is used to dynamically constrain the access strength of this authorization.
[0045] The token generation process is completed within the system platform's permission module, with the specific implementation handled by the backend middleware service. This service constructs a structured data record based on the aforementioned input fields and issues it as a token structure with an encrypted signature. To ensure reproducibility and executability, the acquisition and processing of each field are described in detail below.
[0046] Visitor ID With character level All of these originate from the user authentication module and are returned via the permission service interface after the user completes login. They are typically numbered and encoded using a user ID mapping table; the access terminal device number is also included. Device registration identifiers attached to the access request or automatically labeled by the access gateway's device binding table, such as smart navigation device number, APP registration ID, etc.; data resource number. The identifier comes from the access API path or parameter, and is uniformly encoded by the interface gateway; region number. The access point ID (such as a Wi-Fi hotspot or edge node number) of the access request is mapped to a unified region number on the platform. During deployment, the system binds each device to a region in the background; time period number. The timestamp of when the server received the request is used to obtain the time block it belongs to by looking up a table, such as the corresponding number for tags like "Holiday - Nighttime"; data sensitivity level. The access risk score is derived from the preset sensitivity level of the resource type. This is the result of the second step algorithm calculation, and its value range is... .
[0047] Based on the above information, a structured temporary access token is generated. Its basic structure is as follows: ; The token field has the following meanings: Indicates the visitor ID to which the token is bound; This indicates the data resources that can be accessed under this authorization; This indicates that the request must be initiated by the device. Indicates the valid time interval, by... The time period is generated by extending a tolerance window forward and backward by one hour, for example, by adding one hour forward and backward. The authorized time period is ; This indicates the geographical region from which the access must originate. The system will verify the location of the access gateway during the token verification phase.
[0048] The innovative design lies in embedding risk scoring-driven access strength control parameters into the token. In other words, the higher the risk, the fewer the frequency of accesses or the smaller the amount of data accessed. The calculation expression is: ; in Indicates the maximum number of times (or the number of data blocks) can be accessed. Configure the maximum access limit for the system, for example, set it to ,when At times ,when At times The higher the risk, the more restricted the access capability becomes. This design not only enhances the system's constraints on high-risk behaviors but also avoids the deficiency of "only making permission judgments without intensity control".
[0049] After the token is generated, it is encrypted and signed by the platform and stored in the permission token database. The database service uses a unique token ID for indexing. In subsequent accesses, the access control gateway verifies the token attached to the request, including field consistency, timeliness, regional consistency, access device consistency, and the validity of the access count. If the request does not meet any of the above conditions, the system returns a permission verification failure and records it in the audit log.
[0050] For example: a tourist ( On holiday evenings ( Use a registered mobile device ( Access to highly sensitive camera data , Its risk score is System Configuration ,calculate: ; The final generated token structure is as follows: ; Indicates visitor ID Only device serial numbers can be used In area code Within, time interval Access resource number between And allows a maximum of [number] visits. Second-rate.
[0051] Step 5: Perform actual verification based on the boundary permission token, sequentially checking user ID matching, data resource matching, device ID consistency, access time validity, region validity, and access frequency restrictions. When all verification conditions are met, execute access control operations and record the complete access behavior chain; specifically including: This step is the final execution stage of the entire cultural tourism data access control method. Its core task is to process the boundary permission token generated in the previous step. Perform actual verification and based on the access path identifier. Access control operations are performed while the complete access behavior chain is recorded. This step not only approves or denies data access but also ensures that the entire system can be traced for accountability, audited for security, and detected for anomalies later through a behavior recording mechanism. It is a crucial part of making the method of this invention closed-loop. Unlike the simplified approach of traditional systems that only record whether the request is approved, this step has an innovative structural design in the three dimensions of verification, execution, and recording, making each step of the access behavior context-interpretable and technically reproducible.
[0052] via boundary permission token (Including visitor ID) Resource Number Terminal number Authorized area number Time window and access frequency limit Access path identifier (Values can be one of three enumeration types: "Regular Access", "Boundary Access", or "Access Denied"); Access Context Vector ; and risk score Upon receiving an access request, the system first reads the token store in the database and matches it with the requester's ID. The token is verified against the token ID carried in the request. The platform's permission module extracts information such as device ID, region ID, and timestamp from the access logs and compares it item by item with the corresponding fields in the token. All of this data is collected in real time by the platform infrastructure: for example, timestamps. Terminal ID is obtained from the access time recorded by the server. The area code is automatically included in the request header by the access device. The access frequency is obtained by the IoT edge gateway through device location mapping during access, and the access frequency is accumulated in real time by the system behavior statistics module to ensure that each access can be verified through structured data.
[0053] The system follows a three-stage process of "verification-execution-logging" when executing control logic. In the verification stage, the system sequentially checks six constraints: user ID matching, data resource matching, device ID consistency, access time validity, region validity, and access frequency limit. The specific judgment logic is executed by the access control module, which verifies the request by comparing the current request attributes in memory with the token in the database. This is implemented using fields. For example, if the time period in the request is... The token authorization time interval is If the current access count has been reached, the verification is successful; otherwise, the verification is unsuccessful. If the access limit is exceeded, access is directly denied. For regular access paths, the system only verifies based on the role and permission table; for denied paths, the system immediately returns a denial response and terminates the process; while for boundary access paths, all six verifications mentioned above must be completed before data access can proceed. Access control decisions are made through a logical variable. The representation is defined as follows: ; in This indicates that access is permitted, and the system enters the resource retrieval phase, returning data from the corresponding data source (such as the monitoring server, tourist order database, tour guide service API, etc.). This indicates that access has been blocked; the system refuses to respond to the request and logs the error reason. This judgment logic is entirely completed automatically by the access control middleware, without relying on manual intervention, and has high real-time performance and determinism.
[0054] After access control is completed, the system immediately enters the behavior logging phase. To ensure the integrity of subsequent auditing and traceability, this step designs a multi-field behavior log entry. Its structure is defined as follows: ; in, For the complete access context; Assess risk level; This is the system path determination result; This is a token object (if this access is a boundary path access, record the entire record; otherwise, this field is empty). Indicates the execution result; This is the access timestamp. Log data is written to the log database through the permission auditing module, and a summary record is simultaneously synchronized on the edge nodes for real-time monitoring. Each log entry contains a unique identifier and signature information to prevent subsequent tampering. Log data collection and writing are implemented by the system event listening service, which automatically generates log entries by capturing event signals (including "allow events" and "deny events") from the access control module.
[0055] To better illustrate the system's feasibility, a concrete example can be given: Suppose a tourist ( )serial number Using mobile devices ( On holiday evenings ( Attempt to access scenic area surveillance video data ( The system path was determined to be "borderline access," and the risk score was [missing information]. The token generated in the previous step This indicates that the visitor is only allowed two visits within Area 3, between 7 and 9 PM, using device 9. If this is the user's first visit, the system compares the token and finds all fields match. The system allows access and returns the result to the client; it also records log entries: ; If the tourist initiates a third visit, the visit frequency has exceeded the limit. The system will determine the limitations in real time. Access is blocked, and the violation type "frequency exceeding privileges" is marked in the log.
[0056] In a second aspect of the invention, a cultural tourism data access control system is also provided, comprising: The data acquisition and processing module is used to collect cultural and tourism data in the cultural and tourism platform. The cultural and tourism data includes visitor data, requested data resources, visitor role, terminal device number that initiated the request, request occurrence time, request initiation location area number, and the type of requested data and its corresponding data sensitivity level. The above cultural and tourism data is encoded and concatenated into an access request context vector in a unified format. The risk and data sensitivity assessment module is used to introduce a context-based dynamic risk assessment mechanism, build a joint assessment model for risk and data sensitivity, and jointly assess the real-time elements of the access context to output the access risk level, reflecting the comprehensive risk of the access request. The access path determination module is used to build an access path decision model. It calculates the access control decision score through a comprehensive scoring function and generates identifiers for denying access, entering the boundary permission process, and entering the regular access process for the visitor's access request based on the score results. The permission token generation module is used to generate a structured temporary access token based on the request context for access requests with access boundary permission process identifiers, and to explicitly limit its authorization conditions. After the token is generated, the platform encrypts and signs it and stores it in the permission token database. The database service uses a unique token ID for indexing. In subsequent accesses, the access control gateway verifies the token attached to the request. If the request does not meet the token conditions, the access permission is revoked and recorded. The access control enforcement module is used to perform actual verification based on the boundary permission token. It sequentially checks the user ID matching, data resource matching, device ID consistency, access time validity, region validity, and access frequency limit. When all verification conditions are met, the access control operation is executed, and the complete access behavior chain is recorded.
[0057] This application provides an electronic device; Figure 3 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application, such as... Figure 3 As shown, the electronic device 300 includes: a processor 301, at least one communication bus 302, a user interface 303, at least one external communication interface 304, and a memory 305. The communication bus 302 is configured to enable communication between these components. The user interface 303 may include a display screen, and the external communication interface 304 may include standard wired and wireless interfaces. The processor 301 is configured to execute a program of a control method stored in the memory to implement the steps of the control method provided in the above embodiment.
[0058] It should be noted that the descriptions of the above storage medium and electronic device embodiments are similar to the descriptions of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.
[0059] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.
[0060] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, object, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, object, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, object, or apparatus that includes that element.
[0061] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.
[0062] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.
[0063] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.
[0064] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.
[0065] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a controller to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.
[0066] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for access control of cultural and travel data, characterized in that, Comprise the following steps: Collecting tourism data in the tourism platform, the tourism data including visitor data, requested data resources, visitor roles, terminal device numbers initiating requests, request occurrence times, request initiation location area numbers, and requested data types and corresponding data sensitivity levels, encoding the tourism data to splice into a uniform format of access request context vectors; Introducing a context dynamic risk assessment mechanism to construct a joint assessment model of risk and data sensitivity for joint assessment of real-time elements of access context, outputting access risk levels to reflect the comprehensive risk of access requests; Building an access path decision model to calculate access control decision scores through a comprehensive scoring function, and generating identifiers for rejected access, entering boundary permission processes, and entering regular access processes for visitors' access requests based on scoring results; For access requests with entering boundary permission process identifiers, a structured temporary access token is generated based on the request context, and the authorization conditions are clearly defined. After token generation, the platform performs encryption signature and stores it in the permission token database. The database service uses a unique token ID for indexing. In subsequent access, the access control gateway verifies the token attached to the request. If the request does not meet the token conditions, access permissions are revoked and recorded; According to the boundary permission token, verify the user number, data resource, device number consistency, access time legality, region legality, and access frequency limit in sequence. When all verification conditions are met, perform access control operations and record the complete access behavior chain.
2. The method of claim 1, wherein, The data sensitivity level is mapped from a type to which the requested data belongs, and includes level codes respectively representing low, medium, and high sensitivity.
3. The method of claim 1, wherein, In the joint assessment model of risk and data sensitivity, scene correction rules are introduced to adaptively adjust the risk according to the regional characteristics and device status in the tourism environment, enabling the risk assessment to have dynamic scene adaptation capabilities.
4. The method of claim 1, wherein, In the access path decision model, the access path that the current access request should enter is output, including: a direct regular access path, an access path requiring additional boundary control, and a rejected access path blocked by the system.
5. The method of claim 1, wherein, According to the comprehensive scoring function calculation value, set two policy threshold values: a low-risk tolerance threshold and a high-risk lockout threshold. The final access path selection rule is as follows: If the comprehensive scoring function calculation value is greater than or equal to the high-risk tolerance threshold, reject access; If the comprehensive scoring function calculation value is greater than or equal to the low-risk tolerance threshold and less than the high-risk tolerance threshold, enter the boundary permission process; If the comprehensive scoring function calculation value is less than the low-risk tolerance threshold, enter the regular access process.
6. The method of claim 1, wherein, The temporary access token includes the visitor number bound to the token, the data resources accessible under this authorization, the device number initiating the request, the valid time interval, and the geographic area of access. The valid time interval is generated by expanding one tolerance window forward and backward from the corresponding time period.
7. The method of claim 1, wherein, For regular access paths, only role permission tables are checked; for rejected paths, immediately return a rejection response and terminate the process; for boundary access paths, the data release stage must be completed after the verification conditions are met.
8. A data access control system for cultural tourism, characterized in that, Comprise: A data collection and processing module is configured to collect cultural and travel data in a cultural and travel platform, wherein the cultural and travel data includes visitor data, requested data resources, visitor roles, terminal equipment numbers initiating requests, request occurrence times, request initiation location area numbers, and types of requested data and corresponding data sensitivity levels. The cultural and travel data is encoded and spliced into a uniform format of an access request context vector. A risk and data sensitivity evaluation module is configured to introduce a context dynamic risk evaluation mechanism and construct a joint evaluation model of risk and data sensitivity, which is used to jointly evaluate real-time elements of an access context and output an access risk level to reflect the comprehensive risk of an access request. An access path judgment module is configured to construct an access path decision model, calculate an access control decision score through a comprehensive scoring function, and generate an identification of a denied access, an entering boundary permission process, and an entering regular access process for a visitor's access request according to the score result. A permission token generation module is configured to generate a structured temporary access token based on a request context for an access request with an entering boundary permission process identification, and explicitly limit the authorization conditions. After the token is generated, the platform performs encryption signature and stores it in a permission token database. The database service uses a unique token ID for indexing. In subsequent access, the access control gateway verifies the token attached to the request. If the request does not meet the token conditions, the access permission is revoked and the record is recorded. An access control execution module is configured to perform actual verification based on the boundary permission token, and sequentially check user number matching, data resource matching, device number consistency, access time legality, area legality, and access frequency limitation. When all the check conditions are met, the access control operation is performed, and the complete access behavior chain is recorded.
9. An electronic device, comprising: The storage medium stores a computer program that can be executed by one or more processors to implement the cultural and travel data access control method according to any one of claims 1 to 7. The storage medium stores a computer program that can be executed by one or more processors to implement the cultural and travel data access control method according to any one of claims 1 to 7.
10. A storage medium, characterized by