Secure access method and device

Abstract

The embodiment of the invention provides a secure access method and device. The method comprises the following steps: receiving a target access request; matching bills for the target storage area from historical bills obtained by the client before the current moment and stored on the client; under the condition that the target bill is matched, the target storage area is accessed according to the target bill and the target access request, a target access result is obtained, a historical verification record of the data server before the current moment is stored in the data server, and the historical verification record is used for indicating the verification condition of the data server on the received bill; and the data server is used for verifying the target bill according to the historical verification record and executing the target access request according to the verification result of the target bill. According to the method and the device, the problem of relatively low access efficiency of secure access of the client to the data server is solved, and the effect of improving the access efficiency of secure access of the client to the data server is achieved.

Description

Technical Field

[0001] The embodiments of the present application relate to the computer field, and more specifically, to a secure access method and device. Background Art

[0002] For data security considerations, it is particularly important to perform security authentication on the client when the client accesses the data on the data server. Therefore, a method is currently provided in which a ticket is provided by a verification server, and the ticket is used to help the data server perform security authentication on the client that needs to access the data on the data server, thereby maintaining data security on the data server. However, as the interaction between the client and the data server becomes more frequent, the frequent security authentication process that follows hinders the client's access to the data server, and the client's secure access to the data server is less efficient. Summary of the invention

[0003] The embodiments of the present application provide a secure access method and device to at least solve the problem of low access efficiency of secure access by a client to a data server in the related art.

[0004] According to an embodiment of the present application, a secure access method is provided, which is applied to a client and includes:

[0005] A target access request is received, wherein the target access request is used to request access to a target storage area of ​​a data server; in response to the target access request, a ticket is matched for the target storage area from a historical ticket stored on the client and obtained by the client before the current moment, wherein the historical ticket is obtained by the client from a verification server before the current moment; in the case of matching the target ticket, the target storage area is accessed according to the target ticket and the target access request to obtain a target access result, wherein the data server stores a historical verification record of the data server before the current moment, the historical verification record is used to indicate the verification status of the received historical ticket by the data server, the data server is used to verify the target ticket according to the historical verification record and execute the target access request according to the verification result of the target ticket; in the case of no ticket matching or the target access result is used to indicate that the target storage area is not accessed, a reference ticket matching the target storage area is requested from the verification server; the target storage area is accessed according to the reference ticket and the target access request, wherein the data server is used to verify the reference ticket and execute the target access request according to the verification result of the reference ticket.

[0006] Optionally, matching the ticket for the target storage area from historical tickets stored on the client and obtained by the client before the current moment includes: extracting the ticket corresponding to the target storage area from the storage area with a corresponding relationship and the historical tickets to obtain an extraction result; determining a matching result for the ticket matching the target storage area based on the extraction result and permission information of the extracted alternative ticket, wherein the permission information is used to indicate the access rights to the data server corresponding to the alternative ticket.

[0007] Optionally, the extracting of the ticket corresponding to the target storage area from the storage area having a corresponding relationship and the historical ticket to obtain the extraction result includes: calculating the target index corresponding to the target storage area according to the hash function of the client; searching for the target index in the historical index included in the client, wherein the historical index corresponds one-to-one to the historical ticket, and the historical index is used to indicate the storage location of the historical ticket on the client and the storage location of the permission information corresponding to the historical ticket on the client; when the target index is found, extracting the historical ticket from the reference storage location indicated by the target index as the alternative ticket, and extracting the permission information of the alternative ticket from the reference storage location.

[0008] Optionally, determining the matching result of the ticket matching the target storage area based on the extraction result and the permission information of the extracted alternative ticket includes: detecting whether the alternative ticket is valid at the current moment based on the validity time of the alternative ticket, wherein the permission information includes the validity time; in case it is detected that the alternative ticket is valid at the current moment, determining the matching result as matching the alternative ticket as the target ticket; in case the extraction result is used to indicate that no ticket is extracted or it is detected that the alternative ticket is invalid at the current moment, determining the matching result as no ticket is matched.

[0009] Optionally, accessing the target storage area according to the target ticket and the target access request includes: searching for a target key corresponding to the target ticket, wherein the target ticket is encrypted using a data key of the data server, and the target key is recorded in the target ticket; encrypting the client information in the target access request using the target key to obtain a reference access request carrying the encrypted client information, wherein the target access request includes the client information and request information, the reference access request includes the encrypted client information and the request information, the client information is used to indicate the initiation time of the client and the target access request, and the request information is used to request access to the target storage area of ​​the data server; sending the reference access request and the target ticket to the data server;

[0010] Wherein, the data server is used to search the target verification record of the target ticket from the historical verification record when the target ticket is received; when the target verification record of the target ticket is found and the target verification record is used to indicate that the target ticket verification has passed, execute the request information target access request; when the target verification record cannot be found or the target verification record is used to indicate that the target ticket verification has not passed, verify the target ticket according to the data key and the encrypted client information reference access request to obtain an update verification record; when the update verification record is used to indicate that the target ticket verification has passed, execute the request information target access request and store the update verification record in the data server; when the update verification record is used to indicate that the target ticket verification has not passed, send the target access result indicating that the target storage area has not been accessed to the client.

[0011] Optionally, the method also includes: detecting whether the historical ticket has reached the update time; when detecting that the ticket to be updated in the historical ticket has reached the update time, detecting the reference storage area corresponding to the ticket to be updated; requesting the verification server for an update ticket that matches the reference storage area; searching for a reference index corresponding to the reference storage area in the historical index included in the client, wherein the historical index corresponds one-to-one to the historical ticket, and the historical index is used to indicate the storage location of the historical ticket on the client and the storage location of the permission information corresponding to the historical ticket on the client; recording the update ticket and the permission information of the update ticket to the storage location indicated by the reference index.

[0012] Optionally, the method further includes: the data server subscribing to ticket update information of the verification server, wherein the ticket update information is used to indicate changes in permissions of the tickets distributed by the verification server; and the data server updating the historical verification record according to the ticket update information.

[0013] According to another embodiment of the present application, a secure access method device is provided, which is applied to a client, and the device includes: a receiving module, which is used to receive a target access request, wherein the target access request is used to request access to a target storage area of ​​a data server; a responding module, which is used to respond to the target access request and match a ticket for the target storage area from historical tickets stored on the client and obtained by the client before the current moment, wherein the historical ticket is obtained by the client from a verification server before the current moment; a first access module, which is used to access the target storage area according to the target ticket and the target access request in the case of matching the target ticket, and obtain a target access result, wherein the data server stores the historical tickets of the target storage area. a historical verification record of the data server before the current moment, the historical verification record being used to indicate the verification status of the received ticket by the data server, the data server being used to verify the target ticket according to the historical verification record and to execute the target access request according to the verification result of the target ticket; a first request module being used to request a reference ticket matching the target storage area from the verification server when no ticket is matched or the target access result is used to indicate that the target storage area is not accessed; a second access module being used to access the target storage area according to the reference ticket and the target access request, wherein the data server being used to verify the reference ticket and to execute the target access request according to the verification result of the reference ticket.

[0014] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when run.

[0015] According to another embodiment of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0016] Through the present application, after receiving a target access request for requesting access to a target storage area of ​​a data server, the client will match a ticket for the target storage area from the historical tickets obtained by the client before the current moment and stored on the client, thereby reducing unnecessary operations of obtaining tickets from the verification server while retaining the ticket authentication mechanism. Then, when the target ticket is matched, the target storage area is accessed according to the target ticket and the target access request. The data server stores the historical verification records of the data server before the current moment. Since the historical verification records indicate the verification status of the received ticket by the data server, the data server can verify the target ticket according to the historical verification records and execute the target access request according to the verification result of the target ticket. That is to say, after receiving the ticket, the data server will also reuse the verification records of the previously received ticket while retaining the ticket authentication mechanism, thereby reducing unnecessary ticket verification operations and further improving the access efficiency of the client to the data server. Therefore, the problem of low access efficiency of the client's secure access to the data server can be solved, thereby achieving the effect of improving the access efficiency of the client's secure access to the data server. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a hardware structure block diagram of a server device of a secure access method according to an embodiment of the present application;

[0018] Figure 2 is a flowchart of a secure access method according to an embodiment of the present application;

[0019] Figure 3 is a schematic diagram of an efficient and reliable authentication method based on Kafka according to an embodiment of the present application;

[0020] Figure 4 It is a flowchart of an efficient and reliable authentication method based on Kafka according to an embodiment of the present application;

[0021] Figure 5 It is a structural block diagram of a secure access device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0023] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0024] The method embodiments provided in the embodiments of the present application can be executed in a server device or a similar computing device. Taking running on a server device as an example, Figure 1 1 is a hardware structure block diagram of a server device of a secure access method according to an embodiment of the present application. Figure 1 As shown, the server device may include one or more ( Figure 1 The server device includes a processor 102 (only one is shown) (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the server device may also include a transmission device 106 and an input / output device 108 for communication functions. A person skilled in the art can understand that Figure 1 The structure shown is only for illustration and does not limit the structure of the above server device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0025] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the secure access method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the server device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0026] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the server device. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0027] In this embodiment, a secure access method is provided. Figure 2 is a flowchart of a secure access method according to an embodiment of the present application. Figure 2 As shown, the process includes the following steps:

[0028] Step S202, receiving a target access request, wherein the target access request is used to request access to a target storage area of ​​a data server;

[0029] Step S204, in response to the target access request, matching a ticket for the target storage area from historical tickets stored on the client and obtained by the client before the current moment, wherein the historical tickets are obtained by the client from the verification server before the current moment;

[0030] Step S206, when the target ticket is matched, the target storage area is accessed according to the target ticket and the target access request to obtain the target access result, wherein the data server stores the historical verification records of the data server before the current moment, and the historical verification records are used to indicate the verification status of the received historical tickets by the data server, and the data server is used to verify the target ticket according to the historical verification records and execute the target access request according to the verification result of the target ticket;

[0031] Step S208, when no ticket is matched or the target access result indicates that the target storage area is not accessed, requesting a reference ticket matching the target storage area from the verification server;

[0032] Step S210: access the target storage area according to the reference ticket and the target access request, wherein the data server is used to verify the reference ticket and execute the target access request according to the verification result of the reference ticket.

[0033] Through the above steps, after receiving the target access request for requesting access to the target storage area of ​​the data server, the client will match the ticket for the target storage area from the historical tickets obtained by the client before the current moment stored on the client, thereby reducing unnecessary operations of obtaining tickets from the verification server while retaining the ticket authentication mechanism. Then, when the target ticket is matched, the target storage area is accessed according to the target ticket and the target access request. The data server stores the historical verification records of the data server before the current moment. Because the historical verification records indicate the verification status of the received ticket by the data server, the data server can verify the target ticket according to the historical verification records and execute the target access request according to the verification result of the target ticket. That is to say, after receiving the ticket, the data server will reuse the verification record of the previously received ticket while retaining the ticket authentication mechanism, thereby reducing unnecessary ticket verification operations and further improving the access efficiency of the client to the data server. Therefore, the problem of low access efficiency of the client's secure access to the data server can be solved, thereby achieving the effect of improving the access efficiency of the client's secure access to the data server.

[0034] In the embodiment provided in step S202, the target access request is used to request access to the target storage area of ​​the data server, and the target access request includes but is not limited to requesting to read the data stored in the target storage area, or requesting to write the data into the target storage area. For example, the target access request may be but is not limited to requesting to access the data under Topic A in the Kafka cluster, or may be a request to write the data carried in the request to Topic B.

[0035] Optionally, in an embodiment of the present application, the target access request includes but is not limited to being generated internally by the client, or being sent to the client by other devices connected to the client.

[0036] Optionally, in an embodiment of the present application, the data server includes but is not limited to a server for storing data, and the data server includes but is not limited to a server for storing data from one or more clients and providing data reading services for these clients. The data range that each client can read is determined by the user.

[0037] In the embodiment provided in step S204, it includes but is not limited to opening a storage area on the client for storing historical tickets, or the client is connected to an external storage device, and the storage device is used to store historical tickets.

[0038] Optionally, in an embodiment of the present application, the historical tickets stored by the client include but are not limited to storing only the latest tickets for each storage area acquired by each client, or storing all tickets for each storage area acquired by each client within a period of time before the current moment, etc. This application does not make specific limitations on this.

[0039] Optionally, in an embodiment of the present application, the verification server includes but is not limited to verifying the access rights of each client to each storage area of ​​each data server. The verification server may, but is not limited to, distribute to the client a ticket that has a corresponding relationship with the client and the storage area requested by the client upon confirming that the identity of the client being authenticated is secure and that the client has access rights to the storage area requested to be accessed.

[0040] Optionally, in the embodiments of the present application, including but not limited to, starting to store all tickets obtained from the verification server after the client starts to receive access requests, and managing the stored historical tickets in accordance with a certain cache cleaning mechanism. For example, for tickets that have not been used for a long time (based on the last use time) or are used very infrequently (based on frequency of use statistics), they are deleted from the cache. At the same time, in order to prevent the cache data from growing indefinitely, an upper limit on the cache capacity is set. When the cache size exceeds the upper limit, some tickets are cleaned up according to a certain priority (such as a comprehensive judgment based on the frequency of use and the last use time) to free up space.

[0041] Optionally, in an embodiment of the present application, the ticket matching for the target storage area from the historical tickets stored on the client and obtained by the client before the current moment can be finely matched based on the metadata of the ticket, but not limited to. In the client, the tickets are stored by category, and different types of tickets (for different services or storage areas) are stored in different data structures. A hash table can be used, where the key is the service ID or storage area ID, and the value is the ticket set related to the service or storage area. Each set can be further sorted or filtered according to the metadata such as the validity period, permission range and usage frequency of the ticket. The client implements a fine matching algorithm, which first locates the correct ticket set based on the storage area ID contained in the target access request, and then filters out the most suitable ticket based on the metadata such as the validity period, permission range, and usage frequency of the ticket. For example, the algorithm can give priority to tickets with long validity periods, high usage frequencies and permissions to access the target storage area. Then, according to the usage of the ticket and the system status, the client can dynamically adjust the matching strategy. For example, when the system detects that the access frequency of a storage area suddenly increases, it can preferentially load and match the tickets related to the storage area, and even request new tickets in advance to ensure the validity of the tickets during high-frequency access. This approach focuses on fine-grained matching based on ticket metadata to ensure that the most appropriate ticket is used for each request. It is suitable for scenarios with high requirements for security and permission control. This approach may involve more data processing and policy calculation, but it can provide more accurate ticket usage in large and complex environments.

[0042] Optionally, in an embodiment of the present application, the ticket matching for the target storage area from the historical tickets stored on the client and obtained by the client before the current moment can also be, but not limited to, fast matching based on a cache elimination strategy, and the client uses a cache elimination strategy to manage the ticket cache. Under this strategy, the most recently used tickets will be preferentially stored at the front end of the cache, and the less used tickets may be gradually eliminated. When the client receives a target access request, the client will start looking for matching tickets from the front end of the cache. In this way, the most recently used and possibly still valid tickets will be considered first. If the ticket at the front end cannot be matched, the algorithm will continue to search backward until a matching ticket is found or the entire cache is traversed. In order to improve matching efficiency and system response time, the client can implement an intelligent preloading mechanism. When the ticket is used, the client not only updates its position in the cache, but also analyzes the usage pattern, predicts which tickets may be frequently used in the future, and preloads these tickets to the cache front end. The use of fast matching based on the cache elimination strategy emphasizes the cache elimination strategy and fast matching, which is more suitable for scenarios requiring fast response and high concurrent access. Through intelligent preloading and fast search, it can find available tickets in a short time.

[0043] In the embodiment provided in step S206, the information carried by the target access request includes but is not limited to the client information of the client requesting to access the data server (which may include the client ID and the time when the client initiates the access request) and the information of the target storage area requested to be accessed, etc. Among them, the client information of the client carried by the target access request includes but is not limited to the information encrypted with the key corresponding to the data server (and the key is known to the data server).

[0044] Optionally, in an embodiment of the present application, the target ticket includes but is not limited to recording the key assigned by the verification server to the client for secure access to the client and the data server. The data server itself does not record the key and must obtain it from the target ticket when the key is needed.

[0045] Optionally, in an embodiment of the present application, accessing the target storage area according to the target ticket and the target access request includes but is not limited to the client sending the found target ticket together with the target access request to the data server. The request may also include the client identifier, the request type (read / write) and the detailed information of the target storage area. After receiving the request, the data server first checks its internal historical verification record to see if there is already a verification result for this ticket. The historical verification record is usually a cache, which contains the ticket identifier (such as a serial number or a hash value), the verification result (success / failure) and the verification time. If the verification record of the ticket is found in the verification cache, and the record shows that the verification is passed, and the time of the record and the validity period of the ticket meet the requirements, the data server will directly allow access without the need to perform the complete ticket verification process again. If the ticket verification fails or there is no record in the cache, access may be denied or a complete ticket verification may be performed. The data server can also communicate with the verification server in real time through a secure channel to review the validity and authority of the ticket.

[0046] Optionally, in an embodiment of the present application, the historical verification record includes but is not limited to recording the bill, the verification result corresponding to the bill, and the client information corresponding to the bill. For example, in an application scenario where the client accesses a Kafka cluster, a bill verification cache (i.e., the aforementioned historical verification record) can be established on the Kafka Broker side (i.e., the aforementioned data server), and its data structure can be a bill hash table, where the key is the unique identifier of the bill provided by the client (such as the serial number or hash value of the bill), and the value is the bill verification result (such as verification passed or failed) and related client information (such as client subject name, permission level, etc.) and verification time. Considering the memory usage of the cache and the frequency of data updates, the data structure can be compressed and optimized. The following is an optional Kafka Broker-side cache structure definition:

[0047] H 1 ={K→(V result , V clientInfo , V timestamp )};

[0048] K represents the unique identifier of the ticket provided by the client, which can be a serial number or a hash value; V result Indicates the ticket verification result (Boolean value, indicating pass or fail); V clientInfo Represents relevant client information, including client subject name, permission level, etc.; V timestamp Indicates the verification time.

[0049] In the embodiment provided in step S208, when no ticket is matched, it means that the client has not accessed the target storage area within the first valid time period before the current moment. It may be that the client has never accessed the target storage area, or the time interval from the last time the client accessed the target storage area to the current moment has exceeded the time limit of the reused ticket that the data server can receive. Therefore, the client needs to request a reference ticket that matches the target storage area from the verification server.

[0050] Optionally, in an embodiment of the present application, when the target access result is used to indicate that the target storage area is not accessed, it means that there is a problem with the target ticket, so the client also needs to request the verification server for a reference ticket that matches the target storage area.

[0051] Optionally, in an embodiment of the present application, after requesting a reference ticket matching the target storage area from the verification server, the reference ticket is included in the historical tickets for storage, but is not limited to.

[0052] Optionally, in an embodiment of the present application, requesting a reference ticket matching the target storage area from the verification server includes but is not limited to encrypting client information using a client key of the client to obtain encrypted information, wherein the client information is used to indicate the client; sending a ticket request and the encrypted information to the verification server, wherein the ticket request is used to request to obtain a backup ticket set of the client, wherein the backup ticket set includes the reference ticket;

[0053] Among them, the verification server is used to: when receiving the ticket request and encrypted information, use the client key to decrypt the encrypted information to obtain the client information; according to the client information and the target access request, search for the generation record corresponding to the target storage area and the client in the ticket generation record stored in the verification server, wherein the ticket generation record is used to store the situation that the verification server generates and distributes the tickets corresponding to each storage area for each client before the current moment; when the target generation record is found, search for the ticket corresponding to the client in the ticket generation record as a standby ticket set and send it to the client; when the target generation record is not found, query the access rights of the client to the storage area according to the client information; when it is found that the client has the access rights to the target storage area, generate one or more standby tickets corresponding to all the access rights of the client as a standby ticket set and send them to the client. Through the above steps, the ticket generation record is stored in the verification server, which helps to reduce repeated ticket generation work, reduce the time required for the client to request tickets, and further improve the efficiency of the client's secure access to the data server. In addition, allowing the verification server to generate one or more standby tickets according to all the access rights of the client provides a wider range of access capabilities for the client and enhances the flexibility of the system.

[0054] In the embodiment provided in step S210, including but not limited to when the client has access rights to the target storage area, the reference ticket is used to indicate that the client is allowed to access the target storage area, then the client can access the target storage area according to the reference ticket and the target access request; when the client does not have access rights to the target storage area, the reference ticket is empty or the reference ticket is used to indicate that the client is not allowed to access the target storage area, then the client will not be able to access the target storage area.

[0055] As an optional embodiment, matching tickets for a target storage area from historical tickets stored on the client and obtained by the client before the current moment includes: extracting tickets corresponding to the target storage area from storage areas and historical tickets having a corresponding relationship to obtain extraction results; determining a matching result for matching tickets for the target storage area based on the extraction results and permission information of the extracted alternative tickets, wherein the permission information is used to indicate access rights to the data server corresponding to the alternative tickets.

[0056] Optionally, in an embodiment of the present application, historical tickets include but are not limited to being stored in the form of a historical ticket table, which records each historical ticket and the storage area corresponding to each historical ticket. More specifically, it is possible but not limited to create a hierarchical ticket cache structure on the Kafka client in the application scenario of the Kafka cluster. The first layer can be a topic (Topic)-ticket (Ticket) hash table, in which the key is the Kafka Topic (corresponding to the aforementioned storage area), and the value is the corresponding ticket and its related metadata (such as the ticket validity period, acquisition time, update time, etc.). For the tickets corresponding to each Topic in the second layer, a cache strategy tag (such as the most recent use time, frequency of use, etc.) can be further used to assist in cache management. The following is an optional Kafka client cache structure definition:

[0057] First level hash table:

[0058] H 2 ={T i →(T ticket , T metadata )}; where T i Indicates the name of the i-th Kafka Topic, T ticket Represents the corresponding bill, T metadata Represents the metadata of the ticket, including the ticket validity period, acquisition time, update time, etc.

[0059] Second-level cache strategy tags:

[0060] T metadata ={T expiry , T acquisitionTime , T updateTime , T cachePolicyMarker}; where T expiry Indicates the validity period of the bill, T acquisitionTime Indicates the time of obtaining the ticket, T updateTime Indicates the update time of the ticket, T cachePolicyMarker It can be the most recent usage time T laztUzedTime and usage frequency T usageFrequency A combination of other parameters.

[0061] Optionally, the ticket and its metadata stored in the ticket cache may be compressed and encrypted to reduce storage space usage and improve data security. For example, assuming that the size of the original ticket and its metadata is S original , the compressed size is S compressed , the compression ratio can be expressed as The compression ratio can be flexibly determined according to the size of the storage space and the amount of data of the bills and their metadata to be stored. Assuming that the original data is Doriginal , the encrypted data is D emcypted , the encryption algorithm used is E, the key is K, then D encrypted =E(D original , K); when using the bill, you need to use the corresponding decryption algorithm D and decryption key to decrypt: D original =D(D encrypted ,K), you can flexibly select the encryption and decryption algorithm according to your needs. Encrypting the historical bills and then saving them improves the security of the data. When obtaining the historical bills, you can use the key and the corresponding decryption algorithm to decrypt the historical bills.

[0062] Optionally, in an embodiment of the present application, the ticket corresponding to the target storage area extracted from the storage area and historical tickets with a corresponding relationship is not necessarily a reusable ticket. It is necessary to judge the availability of the extracted ticket based on the permission information of the extracted ticket, and then determine the matching result of the ticket matching the target storage area.

[0063] As an optional embodiment, extracting tickets corresponding to a target storage area from storage areas and historical tickets having a corresponding relationship to obtain an extraction result includes: calculating a target index corresponding to the target storage area according to a hash function of the client; searching for the target index in the historical index included in the client, wherein the historical index corresponds one-to-one to the historical ticket, and the historical index is used to indicate the storage location of the historical ticket on the client and the storage location of the permission information corresponding to the historical ticket on the client; when the target index is found, extracting the historical ticket from the reference storage location indicated by the target index as an alternative ticket, and extracting the permission information of the alternative ticket from the reference storage location.

[0064] Optionally, in an embodiment of the present application, when the client stores historical tickets and permission information corresponding to the historical tickets in the form of a hash table, if it is necessary to query whether there are tickets corresponding to the target storage area in the historical tickets, it is necessary to calculate the target index corresponding to the target storage area according to the client's hash function, that is, calculate the key corresponding to the target storage area, and search for the value corresponding to the key according to the key and key pair value table. The value corresponding to the key should include historical tickets and permission information corresponding to the historical tickets. With this method, alternative tickets and permission information corresponding to the alternative tickets can be obtained safely and accurately.

[0065] Through the above steps, by using the hash function to calculate the target index corresponding to the target storage area, the ticket and permission information related to the storage area can be quickly located. The characteristic of the hash function is that it can quickly map data to a specific index location. By using the hash function, the search time is greatly shortened and the search efficiency is improved.

[0066] As an optional embodiment, determining a matching result of a ticket matching the target storage area based on the extraction result and the permission information of the extracted alternative ticket includes: detecting whether the alternative ticket is valid at the current moment based on the validity time of the alternative ticket, wherein the permission information includes the validity time; when it is detected that the alternative ticket is valid at the current moment, determining the matching result as matching the alternative ticket as the target ticket; when the extraction result is used to indicate that no ticket is extracted or it is detected that the alternative ticket is invalid at the current moment, determining the matching result as no ticket is matched.

[0067] Optionally, in an embodiment of the present application, in order to improve the access efficiency of the client's secure access to the data server while taking security into consideration, the historical tickets stored in the client are not permanently valid, but will adopt a setting of an effective time. For example, in the application scenario of the Kafka cluster, when the client accesses a KafkaTopic for the first time, it requests a ticket from the verification server according to the conventional authentication process, and stores the ticket and its metadata in the ticket cache. When accessing the same Topic subsequently, the client first checks the ticket cache. If a valid ticket is found (judged by checking whether the ticket validity period and related permissions match the topic requirements), the ticket is directly used to authenticate with the KafkaBroker (ie, the data server) without requesting the verification server again. If the ticket found is invalid, it is still necessary to request a ticket from the verification server and save the newly obtained ticket.

[0068] Through the above, by detecting the validity period of the candidate ticket, it is ensured that only the ticket that is still valid at the current moment can be confirmed as the matched target ticket. This avoids the use of expired or invalid tickets for access, and enhances the security and reliability of the system.

[0069] As an optional embodiment, accessing a target storage area according to a target ticket and a target access request includes: searching for a target key corresponding to the target ticket, wherein the target ticket is encrypted using a data key of a data server, and the target key is recorded in the target ticket; encrypting the client information in the target access request using the target key to obtain a reference access request carrying the encrypted client information, wherein the target access request includes the client information and the request information, the reference access request includes the encrypted client information and the request information, the client information is used to indicate the initiation time of the client and the target access request, and the request information is used to request access to the target storage area of ​​the data server; sending the reference access request and the target ticket to the data server;

[0070] Among them, the data server is used to: search for the target verification record of the target ticket from the historical verification records when the target ticket is received; execute the request information target access request when the target verification record of the target ticket is found and the target verification record is used to indicate that the target ticket verification has passed; when the target verification record cannot be found or the target verification record is used to indicate that the target ticket verification has not passed, verify the target ticket based on the data key and the encrypted client information reference access request to obtain an updated verification record; when the updated verification record is used to indicate that the target ticket verification has passed, execute the request information target access request and store the updated verification record in the data server; when the updated verification record is used to indicate that the target ticket verification has not passed, send a target access result to the client to indicate that the target storage area has not been accessed.

[0071] Optionally, in an embodiment of the present application, when the client requests a ticket from the verification server, the verification server will send to the client a target ticket including a target key encrypted using a data key and a target key encrypted using a reference key, wherein the reference key is sent to the client by the verification server after preliminarily verifying the identity of the client, and is specifically used for encrypted interaction between the client and the verification server; therefore, after receiving the target key encrypted using the reference key, the client can use a known reference key to decrypt the target key, and when caching historical tickets, the historical tickets, the target keys corresponding to the historical tickets, and the permission information of the historical tickets will be saved together, so that when accessing the target storage area according to the target ticket and the target access request, the target key corresponding to the target ticket can be found.

[0072] Optionally, in an embodiment of the present application, in the application scenario of the Kafka cluster, when the Kafka Broker (i.e., the aforementioned data server) receives the client's ticket for verification, it first checks the ticket verification cache (i.e., the aforementioned historical verification record). If the corresponding ticket verification record is found and the verification result is passed, and the client information matches the current request (such as the permission level meets the subject access requirements), the client is directly allowed to access without re-verifying the ticket. If it is not found in the cache or the verification result is not passed, it is verified according to the conventional ticket verification process, that is, the target ticket is verified according to the data key and the encrypted client information to obtain an updated verification record. More specifically, the data server will use its own data key to decrypt the target ticket, obtain the target key, and then use the target key to decrypt the encrypted client information to obtain the client information, and obtain the updated verification record according to the above decryption process. In the case where the update verification record is used to indicate that the target ticket verification is passed, the client is allowed to access and the update verification record is stored in the data server; in the case where the update verification record is used to indicate that the target ticket verification is not passed, the target access result indicating that the target storage area has not been accessed is sent to the client.

[0073] Through the above content, the data server first tries to find the target verification record of the target ticket from its historical verification records. If it can be found and the verification status of the target ticket is passed, the data server directly executes the request information without having to go through the complete ticket verification process again, thereby reducing the verification load of the data server and improving the processing speed. In addition, when the verification record of the target ticket cannot be found in the historical verification record, or the verification record indicates that the ticket has not passed the verification, the data server will use the data key and encrypted client information to verify the ticket and obtain an updated verification record. This process ensures that even if the cache fails or the ticket status changes, the data server can accurately determine the validity of the ticket, thereby making correct access control decisions and enhancing the security and reliability of the system.

[0074] As an optional implementation, the present application also provides an efficient and reliable authentication method based on Kafka. Figure 3 is a schematic diagram of an efficient and reliable authentication method based on Kafka according to an embodiment of the present application, Figure 4 : is a flow chart of an efficient and reliable authentication method based on Kafka according to an embodiment of the present application. Figure 3 and Figure 4 As shown, the key distribution center can be deployed on the Kafka node in the Kafka cluster. The interaction process between the client and the Kafka Broker (i.e., the data server) and the verification server is roughly as follows:

[0075] 1) The client initiates an access request to the Kafka Broker and first searches for the corresponding ticket in its own ticket cache. If a valid ticket is found, the ticket is included in the request and sent to the Kafka Broker.

[0076] 2) After receiving the request, Kafka Broker checks the ticket verification cache. If there is a verification record of the ticket in the cache and the client information matches, the client is directly allowed to access the relevant Topic partition for message production or consumption operations; otherwise, the regular ticket verification process is carried out.

[0077] 3) After the regular ticket verification process, if the verification passes, Kafka Broker updates the ticket verification cache and provides services to the client. If the verification fails, Kafka Broker denies client access and decides whether to notify the client to re-obtain the ticket and re-verify the ticket based on the situation (such as the error type).

[0078] Combination Figure 3 The detailed interactive process of the client re-obtaining and verifying the ticket is as follows:

[0079] 1. The client sends the client ID, target service (i.e. target storage area) ID, network address, and TGT (authentication server ticket including reference key) validity period to the authentication service.

[0080] 2. The authentication service checks whether the client ID exists in the Kafka Broker (the aforementioned data server) cache, that is, it detects whether the client has access to the Kafka Broker.

[0081] 3. If the authentication service checks and confirms that the client ID is in the Kafka Broker cache, the authentication service will generate two pieces of information, TGS Session Key (the reference key mentioned above) and TGT, and send them to the client cache:

[0082] 4. The client uses the local key to decrypt the TGS Session Key. If the information is successfully decrypted, the authentication is successful. If the information cannot be decrypted, the authentication fails.

[0083] 5. The client directly forwards the TGT sent by the authentication service to the ticket granting service. In addition, the client also encrypts the A information containing its own information with the TGS Session Key and sends it to the ticket granting service.

[0084] 6. The Ticket Granting Service uses its own key to decrypt the TGS Session Key from the TGT, and then uses the TGSSession Key to decrypt the client information from the A information. After the Ticket Granting Service decrypts all the information, it will perform an identity check and perform authentication:

[0085] i. Compare the client ID with the client ID in the TGT.

[0086] ii. Compare the timestamp from A message with the timestamp of TGT.

[0087] iii. Check whether the TGT is expired.

[0088] iv. Check if the A information is already in the cache of the Ticket Granting Service (to avoid replay attacks).

[0089] 7. When all checks pass, the ticket granting service will generate two pieces of information, Kafka Session Key and KafkaTicket, and send them to the client:

[0090] i. Randomly generate a key used by the client and server to interact, namely the Kafka Session Key (the target key mentioned above). This information is encrypted by the TGS Session Key.

[0091] ii. Generate a message containing the client ID, target service (i.e. target storage area) ID, TGS Session Key, etc., encrypted by the Kafka service key (i.e. the aforementioned data key). This message cannot be decrypted by the client and is called Kafka Ticket.

[0092] 8. The client uses the TGS Session Key to decrypt the Kafka Session Key. If the information is successfully decrypted, the authentication is successful. If the information cannot be decrypted, the authentication fails.

[0093] 9. The client forwards the Kafka Ticket sent by the ticket granting service to the server (the aforementioned data server). In addition, the client also encrypts the A information containing its own information with the Kafka Session Key and sends it to the server.

[0094] 10. The server uses its own key (the aforementioned data key) to decrypt the Kafka Ticket information, obtains the Kafka Session Key, and then uses the Kafka Session Key to decrypt the user's A information. After the information is decrypted, the server also needs to do some information checks:

[0095] i. Compare the client ID in the A message with the client ID in the Kafka Ticket.

[0096] ii. Compare the timestamp from A’s message with the timestamp in the Kafka Ticket.

[0097] iii. Check whether the Kafka Ticket is expired.

[0098] iv. Check if the A message is already in the cache of the Kafka service (to avoid replay attacks).

[0099] At this point, all authentications have been passed, the client and the server have completed identity authentication, and subsequent information communication can be carried out.

[0100] As an optional embodiment, the method also includes: detecting whether the historical ticket has reached the update time; when it is detected that the ticket to be updated in the historical ticket has reached the update time, detecting the reference storage area corresponding to the ticket to be updated; requesting the verification server for an update ticket that matches the reference storage area; searching for a reference index corresponding to the reference storage area in the historical index included in the client, wherein the historical index corresponds one-to-one to the historical ticket, and the historical index is used to indicate the storage location of the historical ticket on the client and the storage location of the permission information corresponding to the historical ticket on the client; recording the update ticket and the permission information of the update ticket to the storage location indicated by the reference index.

[0101] Optionally, in the embodiments of the present application, including but not limited to configuring a valid time for each historical ticket, the historical ticket can only be reused within the valid time. In order to further improve access efficiency, it is necessary to obtain an update ticket for each historical ticket as far as possible before the valid time arrives, so that the ticket obtained when the ticket is used is valid. The update timing is the timing when the historical ticket needs to obtain the corresponding update ticket.

[0102] Optionally, in the embodiments of the present application, including but not limited to when the ticket is close to the end of its validity period (such as the remaining validity period is less than a certain threshold, such as the remaining validity period accounts for 10% of the total validity period), it is considered that the historical ticket has been detected to have reached the update time, and the client uses an asynchronous method to request a new ticket from the verification server. After obtaining the new ticket, the ticket information in the cache is updated, including the update time, validity period, etc. At the same time, in order to avoid performance degradation caused by frequent updates, a minimum update interval is set. Even if the ticket is close to its validity period but within the minimum update interval, it will not be updated temporarily.

[0103] Through the above steps, the client periodically checks whether the historical ticket has reached the renewal time, which helps to avoid using expired or expiring tickets for access, ensuring the timeliness and validity of the tickets. This dynamic update mechanism reduces access failures and system delays caused by ticket expiration, and improves service continuity and user experience.

[0104] As an optional embodiment, the method further includes: the data server subscribing to the ticket update information of the verification server, wherein the ticket update information is used to indicate the change of the authority of the ticket distributed by the verification server; the data server updates the historical verification record according to the ticket update information.

[0105] Optionally, in an embodiment of the present application, the historical verification records stored in the data server also need to be continuously maintained based on usage. On the one hand, after the verification is passed, it is necessary to update the ticket verification cache, that is, the verification time in the historical verification record, and store the verification results and client information in the cache. On the other hand, when the verification server updates the ticket (such as due to key updates or permission changes) or revokes the ticket, the Broker end (i.e., the data server) receives the notification in time through the message notification mechanism with the verification server (such as subscribing to the ticket update notification service of the verification server), and updates the ticket verification cache to ensure the consistency of the cache.

[0106] In addition, to prevent expired or invalid information in the cache from causing security vulnerabilities, the records in the ticket verification cache are checked regularly (e.g., at regular intervals). For records whose verification time has not been updated for a long time (which may indicate that the client has not accessed for a long time or an abnormal situation has occurred), they are re-verified or deleted from the cache.

[0107] At the same time, the data server can establish a cache synchronization mechanism with other related components (such as other Brokers in the Kafka cluster). When the cache of a Broker is updated, the update information is synchronized to other Brokers that may be affected according to a certain strategy.

[0108] Through the above steps, the data server can obtain the changes in the ticket permissions in real time, including the increase, decrease or revocation of permissions, by subscribing to the ticket update information of the verification server. This ensures that the data server can make correct decisions based on the latest permission information when processing access requests, significantly enhancing the security of the system and preventing unauthorized access that may occur due to expired or changed permissions.

[0109] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0110] In this embodiment, a secure access device is also provided, which is applied to a client. The device is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0111] Figure 5 is a structural block diagram of a secure access device according to an embodiment of the present application, such as Figure 5 As shown, the device comprises:

[0112] A receiving module 502 is used to receive a target access request, wherein the target access request is used to request access to a target storage area of ​​a data server;

[0113] A response module 504 is used to respond to the target access request and match a ticket for the target storage area from the historical tickets stored on the client and obtained by the client before the current time, wherein the historical tickets are obtained by the client from the verification server before the current time;

[0114] The first access module 506 is used to access the target storage area according to the target ticket and the target access request to obtain the target access result when the target ticket is matched, wherein the data server stores the historical verification record of the data server before the current moment, and the historical verification record is used to indicate the verification status of the received ticket by the data server, and the data server is used to verify the target ticket according to the historical verification record and execute the target access request according to the verification result of the target ticket;

[0115] A first request module 508, configured to request a reference ticket matching the target storage area from the verification server if no ticket is matched or the target access result indicates that the target storage area is not accessed;

[0116] The second access module 510 is used to access the target storage area according to the reference ticket and the target access request, wherein the data server is used to verify the reference ticket and execute the target access request according to the verification result of the reference ticket.

[0117] Through the above-mentioned device, after receiving the target access request for requesting access to the target storage area of ​​the data server, the client will match the ticket for the target storage area from the historical tickets obtained by the client before the current moment stored on the client, thereby reducing unnecessary operations of obtaining tickets from the verification server under the premise of retaining the ticket authentication mechanism, and then accessing the target storage area according to the target ticket and the target access request when the target ticket is matched. The data server stores the historical verification records of the data server before the current moment, because the historical verification records indicate the verification status of the received ticket by the data server, so the data server can verify the target ticket according to the historical verification records and execute the target access request according to the verification result of the target ticket. That is to say, after receiving the ticket, the data server will also reuse the verification record of the previously received ticket under the premise of retaining the ticket authentication mechanism, thereby reducing unnecessary ticket verification operations and further improving the access efficiency of the client to the data server. Therefore, the problem of low access efficiency of the client's secure access to the data server can be solved, and the effect of improving the access efficiency of the client's secure access to the data server can be achieved.

[0118] Optionally, the response module includes: an extraction unit, used to extract the ticket corresponding to the target storage area from the storage areas and historical tickets with corresponding relationships to obtain an extraction result; a determination unit, used to determine the matching result of the ticket matching the target storage area based on the extraction result and the permission information of the extracted alternative ticket, wherein the permission information is used to indicate the access rights to the data server corresponding to the alternative ticket.

[0119] Optionally, the extraction unit is further used to: calculate the target index corresponding to the target storage area according to the hash function of the client; search for the target index in the historical index included in the client, wherein the historical index corresponds one-to-one to the historical ticket, and the historical index is used to indicate the storage location of the historical ticket on the client and the storage location of the permission information corresponding to the historical ticket on the client; when the target index is found, extract the historical ticket from the reference storage location indicated by the target index as an alternative ticket, and extract the permission information of the alternative ticket from the reference storage location.

[0120] Optionally, the determination unit is further used to: detect whether the alternative bill is valid at the current moment based on the validity time of the alternative bill, wherein the authority information includes the validity time; when it is detected that the alternative bill is valid at the current moment, determine the matching result as matching the alternative bill as the target bill; when the extraction result is used to indicate that the bill is not extracted or it is detected that the alternative bill is invalid at the current moment, determine the matching result as no bill is matched.

[0121] Optionally, the first access module includes: a search unit, used to search for a target key corresponding to a target ticket, wherein the target ticket is encrypted using a data key of a data server, and the target key is recorded in the target ticket; an encryption unit, used to encrypt the client information in a target access request using the target key, and obtain a reference access request carrying the encrypted client information, wherein the target access request includes client information and request information, the reference access request includes encrypted client information and request information, the client information is used to indicate the initiation time of the client and target access request, and the request information is used to request access to a target storage area of ​​the data server; a sending unit, used to send the reference access request and the target ticket to the data server;

[0122] Among them, the data server is used to: search for the target verification record of the target ticket from the historical verification records when the target ticket is received; execute the request information target access request when the target verification record of the target ticket is found and the target verification record is used to indicate that the target ticket verification has passed; when the target verification record cannot be found or the target verification record is used to indicate that the target ticket verification has not passed, verify the target ticket based on the data key and the encrypted client information reference access request to obtain an updated verification record; when the updated verification record is used to indicate that the target ticket verification has passed, execute the request information target access request and store the updated verification record in the data server; when the updated verification record is used to indicate that the target ticket verification has not passed, send a target access result to the client to indicate that the target storage area has not been accessed.

[0123] Optionally, the device also includes: a first detection module, used to detect whether the historical ticket has reached the update time; a second detection module, used to detect the reference storage area corresponding to the ticket to be updated when it is detected that the ticket to be updated in the historical ticket has reached the update time; a second request module, used to request the verification server for an update ticket that matches the reference storage area; a search module, used to search for a reference index corresponding to the reference storage area in the historical index included in the client, wherein the historical index corresponds one-to-one to the historical ticket, and the historical index is used to indicate the storage location of the historical ticket on the client and the storage location of the permission information corresponding to the historical ticket on the client; a recording module, used to record the update ticket and the permission information of the update ticket to the storage location indicated by the reference index.

[0124] Optionally, the device also includes: a subscription module, used by the data server to subscribe to the ticket update information of the verification server, wherein the ticket update information is used to indicate the change of permissions of the tickets distributed by the verification server; an update module, used by the data server to update the historical verification record according to the ticket update information.

[0125] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0126] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0127] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0128] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0129] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0130] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0131] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0132] An embodiment of the present application also provides a computer program, which includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in any one of the above method embodiments.

[0133] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0134] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0135] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A secure access method, characterized in that: Applied to a client, the method comprises: receiving a target access request, wherein the target access request is used to request access to a target storage area of ​​a data server; in response to the target access request, matching a ticket for the target storage area from historical tickets stored on the client and obtained by the client before the current moment, wherein the historical tickets are obtained by the client from a verification server before the current moment; In the case of matching the target ticket, accessing the target storage area according to the target ticket and the target access request to obtain a target access result, wherein the data server stores a historical verification record of the data server before the current moment, the historical verification record is used to indicate the verification status of the received ticket by the data server, and the data server is used to verify the target ticket according to the historical verification record and execute the target access request according to the verification result of the target ticket; In case that no ticket is matched or the target access result indicates that the target storage area is not accessed, requesting a reference ticket matching the target storage area from the verification server; The target storage area is accessed according to the reference ticket and the target access request, wherein the data server is used to verify the reference ticket and execute the target access request according to the verification result of the reference ticket.

2. The method according to claim 1, characterized in that The matching of the ticket for the target storage area from the historical tickets stored on the client and obtained by the client before the current moment includes: Extracting the ticket corresponding to the target storage area from the storage area having a corresponding relationship and the historical tickets to obtain an extraction result; A matching result of a matching ticket for the target storage area is determined according to the extraction result and the permission information of the extracted candidate ticket, wherein the permission information is used to indicate the access permission to the data server corresponding to the candidate ticket.

3. The method according to claim 2, characterized in that The extracting the ticket corresponding to the target storage area from the storage area having a corresponding relationship and the historical ticket to obtain the extraction result includes: Calculating a target index corresponding to the target storage area according to a hash function of the client; Searching for the target index in a history index included in the client, wherein the history index corresponds to the history ticket one by one, and the history index is used to indicate a storage location of the history ticket on the client and a storage location of permission information corresponding to the history ticket on the client; In the case where the target index is found, a historical ticket is extracted from a reference storage location indicated by the target index as the candidate ticket, and permission information of the candidate ticket is extracted from the reference storage location.

4. The method according to claim 2, characterized in that: The step of determining the matching result of the target storage area matching ticket according to the extraction result and the permission information of the extracted candidate ticket includes: Detecting whether the candidate ticket is valid at the current moment according to the validity time of the candidate ticket, wherein the authority information includes the validity time; In the case where it is detected that the candidate bill is valid at the current moment, determining that the matching result is that the candidate bill is matched as the target bill; In the case where the extraction result indicates that no bill has been extracted or it is detected that the candidate bill is invalid at the current moment, the matching result is determined to be that no bill can be matched.

5. The method according to claim 1, characterized in that The accessing the target storage area according to the target ticket and the target access request comprises: Searching for a target key corresponding to the target ticket, wherein the target ticket is encrypted using a data key of the data server, and the target key is recorded in the target ticket; Using the target key to encrypt the client information in the target access request, to obtain a reference access request carrying the encrypted client information, wherein the target access request includes the client information and request information, the reference access request includes the encrypted client information and the request information, the client information is used to indicate the client and the initiation time of the target access request, and the request information is used to request access to the target storage area of ​​the data server; sending the reference access request and the target ticket to the data server; Wherein, the data server is used to search the target verification record of the target ticket from the historical verification record when the target ticket is received; execute the request information when the target verification record is used to indicate that the target ticket verification has passed; when the target verification record cannot be found or the target verification record is used to indicate that the target ticket verification has not passed, verify the target ticket according to the data key and the encrypted client information to obtain an updated verification record; when the updated verification record is used to indicate that the target ticket verification has passed, execute the request information and store the updated verification record in the data server; when the updated verification record is used to indicate that the target ticket verification has not passed, send the target access result indicating that the target storage area has not been accessed to the client.

6. The method according to claim 1, characterized in that The method further comprises: Detecting whether the historical ticket has reached the update time; When it is detected that the to-be-updated bill in the historical bills reaches the update time, detecting the reference storage area corresponding to the to-be-updated bill; requesting from the verification server an update ticket matching the reference storage area; Searching for a reference index corresponding to the reference storage area in a history index included in the client, wherein the history index corresponds to the history ticket one-to-one, and the history index is used to indicate a storage location of the history ticket on the client and a storage location of permission information corresponding to the history ticket on the client; The update ticket and the permission information of the update ticket are recorded in the storage location indicated by the reference index.

7. The method according to claim 1, characterized in that The method further comprises: The data server subscribes to the ticket update information of the verification server, wherein the ticket update information is used to indicate the change of the authority of the ticket distributed by the verification server; The data server updates the historical verification record according to the ticket update information.

8. A secure access device, characterized in that: Applied to a client, the device comprises: A receiving module, used for receiving a target access request, wherein the target access request is used for requesting access to a target storage area of ​​a data server; a response module, configured to respond to the target access request and match a ticket for the target storage area from historical tickets stored on the client and obtained by the client before the current moment, wherein the historical tickets are obtained by the client from the verification server before the current moment; A first access module, configured to access the target storage area according to the target ticket and the target access request to obtain a target access result when a target ticket is matched, wherein the data server stores a historical verification record of the data server before the current moment, the historical verification record is used to indicate the verification status of the received ticket by the data server, and the data server is used to verify the target ticket according to the historical verification record and execute the target access request according to the verification result of the target ticket; A first request module, configured to request a reference ticket matching the target storage area from the verification server when no ticket is matched or the target access result indicates that the target storage area is not accessed; The second access module is used to access the target storage area according to the reference ticket and the target access request, wherein the data server is used to verify the reference ticket and execute the target access request according to the verification result of the reference ticket.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in any one of claims 1 to 7 when executed by a processor.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in any one of claims 1 to 7 are implemented.

Images