Data resource access method and device, equipment and medium
The two types of access tickets are generated and verified by the security application server, which solves the problem that a single ticket in the zero-trust network access system is prone to tampering, improves the security and reliability of access, and ensures legal access to business data resources.
Patent Information
- Application Number
- CN202410063871.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-01-16
- Publication Date
- 2025-07-18
AI Technical Summary
In the zero-trust network access system, a single access ticket of the terminal device is easily acquired and tampered by the attacker, resulting in a reduction in the security and reliability of business resource access.
The security application server generates and issues two types of access bills. The first type of bills passes through a high-security transmission channel, and the second type of bills passes through a low-security transmission channel. It is verified and prevented from tampering, ensuring the accuracy of bill verification.
It improves the security and reliability of access to business data resources in the zero-trust network access system, promptly discovers and prevents ticket tampering and interrupts illegal access.
Smart Images

Figure CN120337236A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular, to a method, apparatus, device, and medium for accessing data resources. Background Art
[0002] Nowadays, zero-trust network access systems have been basically widely popularized in the office environments of various enterprises. In a zero-trust network access system, when a user requests access to business resources in a certain site (for example, Site A) through a terminal device, the server needs to generate a unique access ticket for accessing the business resources according to a single access ticket generation method and return it to the terminal device. After receiving this access ticket sent by the server, the terminal device can access the business resources in Site A through this access ticket.
[0003] However, the inventors have found in practice that zero-trust network access systems are often subject to various malicious attacks launched by attackers. For example, when the terminal device stores the unique access ticket for accessing business resources, once an illegal entity (i.e., the attacker) illegally obtains this single access ticket and combines it with reverse analysis of the components in the terminal device, it may directly analyze the access security vulnerabilities in the zero-trust network access system, resulting in the phenomenon that the business resources are illegally accessed directly using this single access ticket, thereby reducing the security and reliability of accessing business resources. Summary of the Invention
[0004] The embodiments of this application provide a method, apparatus, device, and medium for accessing data resources, which can improve the security and reliability when accessing business data resources in a zero-trust network access system.
[0005] On the one hand, the embodiments of this application provide a method for accessing data resources, which is executed by a security application server and includes:
[0006] Receiving a ticket acquisition request for business data resources sent by a security application client. When obtaining the device application data information of the terminal device where the security application client is located based on the ticket acquisition request, generating a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and returning the first access ticket and the second access ticket as resource access tickets to the security application client, so that when the security application client recognizes that the resource access ticket includes a first type of access ticket and a second type of access ticket, sending the first type of access ticket to an access proxy in the security application client through a first data transmission channel, and sending device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through a second data transmission channel; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel;
[0007] The receiving access agent receives the ticket verification requests sent by the smart gateway, and respectively performs ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification requests, so as to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; the smart gateway is deployed between the service client in the terminal device and the service server storing service data resources;
[0008] When the first ticket verification result indicates that the first ticket to be verified is the first access ticket and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, it notifies the smart gateway that when obtaining the resource access request sent by the service client intercepted by the access agent, forward the resource access request to the service server; the resource access request is used to instruct the service server to authorize the service client to access the service data resources.
[0009] An embodiment of the present application provides a data resource access method on the one hand. The method is executed by a terminal device running a secure application client, and includes:
[0010] Send a ticket acquisition request for service data resources to the secure application server;
[0011] Receive the resource access ticket returned by the secure application server, and perform ticket identification on the first access ticket and the second access ticket carried in the resource access ticket to obtain a ticket identification result; the first access ticket and the second access ticket are generated by the secure application server based on the device application data information of the terminal device where the secure application client is located carried in the ticket acquisition request;
[0012] When the ticket identification result indicates that the first access ticket is the first type of access ticket, send the first type of access ticket to the access agent in the secure application client through the first data transmission channel;
[0013] When the ticket identification result indicates that the second access ticket is the second type of access ticket, obtain the device auxiliary information associated with the terminal device, and send the second type of access ticket and the device auxiliary information to the access agent through the second data transmission channel, so that when the access agent obtains the first type of access ticket and the second type of access ticket, use the first type of access ticket as the first ticket to be identified and the second type of access ticket as the second ticket to be identified, generate a ticket verification request based on the first ticket to be identified, the second ticket to be identified and the device auxiliary information, and send the ticket verification request to the secure application server through the smart gateway; the smart gateway is deployed between the service client in the terminal device and the service server storing service data resources.
[0014] One aspect of the embodiments of the present application provides a data resource access device, which runs on a secure application server and includes:
[0015] A ticket generation module, configured to receive a ticket acquisition request for business data resources sent by a secure application client. When obtaining the device application data information of the terminal device where the secure application client is located based on the ticket acquisition request, generate a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and return the first access ticket and the second access ticket to the secure application client as resource access tickets, so that when the secure application client recognizes that the resource access ticket includes a first type of access ticket and a second type of access ticket, send the first type of access ticket to the access proxy in the secure application client through a first data transmission channel, and send the device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through a second data transmission channel; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel.
[0016] A ticket verification module, configured to receive a ticket verification request sent by the access proxy through an intelligent gateway, and perform ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request respectively, to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; the intelligent gateway is deployed between the business client in the terminal device and the business server storing the business data resources.
[0017] A result notification module, configured to, when the first ticket verification result indicates that the first ticket to be verified is the first access ticket and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, notify the intelligent gateway to forward the resource access request sent by the business client intercepted by the access proxy to the business server when the intelligent gateway obtains the resource access request; the resource access request is used to instruct the business server to authorize the business client to access the business data resources.
[0018] One aspect of the embodiments of the present application provides a data resource access device, which runs on a terminal device running a secure application client and includes:
[0019] A first sending module, configured to send a ticket acquisition request for business data resources to a secure application server.
[0020] A ticket recognition module, configured to receive the resource access ticket returned by the secure application server, and perform ticket recognition on the first access ticket and the second access ticket carried in the resource access ticket to obtain a ticket recognition result; the first access ticket and the second access ticket are generated by the secure application server based on the device application data information of the terminal device where the secure application client is located carried in the ticket acquisition request.
[0021] A first transmission module, configured to, when the bill recognition result indicates that the first access bill is a first type of access bill, send the first type of access bill to an access proxy in a security application client through a first data transmission channel;
[0022] A second transmission module, configured to, when the bill recognition result indicates that the second access bill is a second type of access bill, obtain device auxiliary information associated with the terminal device, and send the second type of access bill and the device auxiliary information to the access proxy through a second data transmission channel, so that when the access proxy obtains the first type of access bill and the second type of access bill, the first type of access bill is used as a first bill to be recognized, and the second type of access bill is used as a second bill to be recognized, generate a bill verification request based on the first bill to be recognized, the second bill to be recognized, and the device auxiliary information, and send the bill verification request to a security application server through an intelligent gateway; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel; the intelligent gateway is deployed between a service client in the terminal device and a service server storing service data resources.
[0023] An embodiment of the present application provides a computer device on the one hand, including a memory and a processor, the memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program to enable the computer device to execute the method provided in the above-mentioned aspect of the embodiment of the present application.
[0024] An embodiment of the present application provides a computer-readable storage medium on the one hand. A computer program is stored in the computer-readable storage medium, and the computer program is suitable for being loaded and executed by a processor to enable a computer device with a processor to execute the method provided in the above-mentioned aspect of the embodiment of the present application.
[0025] According to one aspect of the present application, there is provided a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are 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 to enable the computer device to execute the method provided in the above-mentioned aspect.
[0026] In an embodiment of the present application, the security application server may receive a ticket acquisition request for business data resources sent by a security application client. When obtaining the device application data information of the terminal device where the security application client is located based on the ticket acquisition request, the security application server may generate a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and may return the first access ticket and the second access ticket to the security application client as resource access tickets, so that when the security application client recognizes that the resource access ticket includes a first type of access ticket and a second type of access ticket, the security application client sends the first type of access ticket to the access proxy in the security application client through a first data transmission channel, and sends the device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through a second data transmission channel; wherein, the security transmission level of the first data transmission channel here is higher than that of the second data transmission channel; wherein, the security application server simultaneously issues the first type of access ticket and the second type of access ticket, and transmits the second type of access ticket through the second data transmission channel with a lower security transmission level. This means that the second type of access ticket will not be encrypted or will be encrypted at a low level. In this way, when an attacker intends to tamper with the access ticket, the attacker will be misled into thinking that the second type of access ticket is the first type of access ticket issued by the server, inducing the attacker to tamper with the second type of access ticket, so as to judge the attacker's tampering behavior during the subsequent verification process of the second type of access ticket. Further, the security application server may receive a ticket verification request sent by the access proxy through the intelligent gateway, and respectively verify the first ticket to be verified and the second ticket to be verified carried in the ticket verification request to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; further, when the first ticket verification result indicates that the first ticket to be verified is the first access ticket and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, the security application client may notify the intelligent gateway to forward the resource access request to the business server when the intelligent gateway obtains the resource access request intercepted by the access proxy sent by the business client. Specifically, when verifying the second type of access ticket, the relevant information for generating the second type of access ticket may be compared with the above-mentioned device auxiliary information. When the comparison result indicates inconsistency, the security application server may effectively discover the attacker's tampering behavior with the second type of access ticket, thereby disabling the access permission of the access object and interrupting the connection between the access proxy and the intelligent gateway, and further interrupting this access.It can be seen that by issuing the first access ticket and the second access ticket, the security application server can effectively detect the tampering behavior of the attacker against the ticket and the illegal access behavior against the business data resource. When the tampering behavior is detected, security defense measures can be taken in a timely manner to interrupt the access session, thus ensuring the security and reliability of the access object when accessing the business data resource. Brief Description of the Drawings
[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0028] Figure 1 It is a schematic structural diagram of a network architecture provided by an embodiment of the present application;
[0029] Figure 2 It is a schematic diagram of the data processing flow for network access based on a zero-trust network access system provided by an embodiment of the present application;
[0030] Figure 3 It is a schematic diagram of a scenario for data interaction provided by an embodiment of the present application;
[0031] Figure 4 It is a schematic flowchart of a data resource access method provided by an embodiment of the present application;
[0032] Figure 5 It is a schematic diagram of generating a resource access ticket provided by an embodiment of the present application;
[0033] Figure 6 It is a schematic diagram of performing ticket verification and obtaining a ticket verification result provided by an embodiment of the present application;
[0034] Figure 7 It is a schematic flowchart of another data resource access method provided by an embodiment of the present application;
[0035] Figure 8 It is a schematic diagram of a security application client processing a resource access ticket provided by an embodiment of the present application;
[0036] Figure 9 It is a schematic diagram of an access proxy processing a resource access ticket provided by an embodiment of the present application;
[0037] Figure 10 It is a timing diagram of a data resource access method provided by an embodiment of the present application;
[0038] Figure 11 It is a schematic structural diagram of a data resource access device provided by an embodiment of the present application;
[0039] Figure 12 It is a schematic structural diagram of another data resource access device provided by an embodiment of the present application;
[0040] Figure 13 It is a schematic structural diagram of a computer device provided by an embodiment of the present application;
[0041] Figure 14 It is a schematic structural diagram of a data processing system provided by an embodiment of the present application. Detailed implementation manners
[0042] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.
[0043] Before the data resource access method in the embodiments of the present application is described in detail, the technical terms involved in the present application are first explained.
[0044] Trusted application: An application carrier that a user terminal trusted by a security application client can access an internal business system, which may include any application that can be installed on the user terminal, including applications of the operating system and applications that the user can install by themselves, such as Outlook, WeChat, or Office, etc. The application feature information of the trusted application includes information such as the application name, the Message-Digest Algorithm (MD5) value of the application, and the signature information. For example, the trusted application can be an application client such as a social client, an office client, a retrieval client (such as a browser client), a multimedia client (such as a video client), an entertainment client (such as a game client), an education client, a live broadcast client, a news client, or a shopping client (such as an e-commerce client).
[0045] Reachable area: The end user can access the list of internal sites set by the enterprise through the zero-trust network. According to the zero-trust network access policy configured for the user, the internal sites in the list of internal sites that the user can access are the reachable areas of the user. In the embodiments of the present application, the access object (i.e., the end user) can initiate an access request for the business data resources in the target business site (i.e., the reachable area) through the client (i.e., the business client) corresponding to the business application (i.e., the above-mentioned trusted application).
[0046] Login Credential: After the end - user successfully logs in to the secure application client, it is an encrypted string specified by the secure application server for this user, representing the user's login authorization information, including user information and authorization validity period. The login credential is encrypted and stored in the secure application client.
[0047] Network Request Credential: Also known as verification credential or ticket, etc., it is the authorization information issued by the secure application server for a single business access request, used to identify the authorization status of the network request. When intercepting a business access request, the secure application client or the secure application server issues a verification credential for it. The access proxy carries this verification credential to initiate an access to the intelligent gateway. The intelligent gateway will forward the business access request to the corresponding business server only after the verification credential corresponding to the business access request passes the verification on the secure application server. In the embodiments of this application, the login credential can be the first access ticket and the second access ticket generated by the secure application server.
[0048] Zero - Trust Access Control Policy: Also known as zero - trust network access policy, it consists of trusted applications that the end - user can use and reachable areas that can be accessed. For the trusted applications and reachable areas within the user's zero - trust network access policy, the user can access any reachable area through any trusted application. The granularity of the zero - trust network access policy is the logged - in user, and different zero - trust policies are allowed to be formulated for different logged - in users. In the embodiments of this application, after the user logs in to the secure application client through the terminal, the secure application client, the secure application server, and the intelligent gateway can form a zero - trust network access system, and at the same time, a zero - trust access control policy (i.e., the above - mentioned zero - trust policy) is configured in the zero - trust network access system.
[0049] Access Proxy: The access proxy is a terminal proxy for initiating secure access deployed on the controlled terminal device. It is responsible for initiating requests for authenticating the trusted identity of the access subject. After verifying that the identity is trusted, it can establish an encrypted access connection with the access gateway (also known as intelligent gateway / zero - trust gateway), and it is also the policy enforcement point for access control. Among them, in the embodiments of this application, the access proxy can be a component in the secure application client.
[0050] Zero - Trust Gateway: Also known as intelligent gateway, it is deployed at the entrance of enterprise application programs and data resources, and is responsible for verifying and forwarding each session request for accessing enterprise resources. Among them, in the embodiments of this application, it can correspond to the intelligent gateway deployed between the access proxy and the secure application server, and can forward the ticket verification request to the secure application server.
[0051] Access Subject: In a network, it refers to the party initiating an access, i.e., the person / device / application accessing the intranet business resources, which is a digital entity composed of factors such as people, devices, and applications either singly or in combination. In the embodiments of this application, the access subject can be a digital entity composed of the following access objects / terminal devices / business applications or a combination thereof.
[0052] Access Object: In a network, it refers to the party being accessed, i.e., the enterprise intranet business resources, including applications, systems (development and testing environments, operation and maintenance environments, production environments, etc.), data, interfaces, functions, etc. In the embodiments of this application, it can be the business data resources accessed by the access subject.
[0053] Direct Access: In a zero-trust network access architecture, when an application initiates a network access request to a site, after the full-flow proxy hijacks the traffic, it initiates a network access to the target site via the full-flow proxy, that is, initiates a direct connection access. The full-flow proxy sends the network response of the target site to the application. This access mode is called direct access. Among them, in the embodiments of this application, the way that the access proxy directly sends the resource access request to the business server to obtain business data resources when it obtains the resource access request can be called direct access.
[0054] Proxy Access: In a zero-trust network access architecture, when an application initiates a network access request to a site, after the full-flow proxy hijacks the traffic, the full-flow proxy forwards the traffic to the intelligent gateway. The intelligent gateway proxies the access to the target business site. After the access, the intelligent gateway sends the network response of the target site to the full-flow proxy, and the full-flow proxy forwards the network response of the target site to the application. This access mode is called proxy access. Among them, in the embodiments of this application, the way that the access proxy forwards the resource access request to the intelligent gateway when it obtains the resource access request, and then the intelligent gateway sends the resource access request to the business server to obtain business data resources can be called proxy access.
[0055] Service Addressing: In a distributed cascaded deployment mode, different services are deployed on different servers. The process of finding the server connection addresses where the background services concerned by different business modules of the client are deployed is service addressing.
[0056] White-Box Cryptography Technology: White-box cryptography technology is a cryptographic technology that can resist white-box attacks. White-box cryptography technology can be divided into two categories from the implementation method: static white-box and dynamic white-box. In the embodiments of this application, white-box cryptography technology is used to encrypt resource access tickets.
[0057] Sensitive information: user login information including user ID, password, etc., as well as login credentials (big ticket) and network access credentials (small ticket). In the embodiment of the present application, it can include a first access ticket and a second access ticket.
[0058] Business module: A collection of multiple files that complete certain specific functions. The concept of module can not only describe the product more clearly, but also more conveniently specify the content to be installed and uninstalled. For example, we can specify to install only a "threat response" module or an "application software management" module. In the embodiment of the present application, it can be a module in the security application client for obtaining device auxiliary information of the terminal device. Among them, the device auxiliary information here may include but is not limited to the machine information, software and hardware information, and login user information of the terminal device.
[0059] Persistence library: Data persistence is a general term for converting the data structure or object model in memory into a relational model, XML, JSON, binary stream, etc., as well as converting the storage model into the data model in memory. The persistence library is a storage medium for relational models, XML, JSON, binary streams, etc. converted from the data structure or object model in memory and stored in the local disk file or data file of the device. It can be implemented using encrypted files, embedded databases, etc.
[0060] Policy: A set of rules issued by the administrator on the management side for enterprise terminal management. Including patch repair, zero-trust network management and control, security reinforcement strategy, etc. The policy may contain sensitive information such as tickets, timeliness, and validity times. Among them, in the embodiment of the present application, it may refer to the zero-trust network access policy.
[0061] Network session: The process of information exchange between a user and a business system, such as the process of sending or receiving data after a client establishes a network link with a server. This includes the establishment and termination of a connection, or the sending and receiving of data. In the embodiment of the present application, the process of a business client in a terminal device establishing a network connection with a business server and obtaining business data resources from the business server can be referred to as a network session.
[0062] Access session: Based on network session, and contains a set of related features. Access session is an abstract concept that is bound to a combination of equipment, personnel, network attributes, process attributes, and endpoint attributes for each network session that accesses enterprise intranet business resources (including business applications, core systems, asset data, functional interfaces, etc.). In the embodiment of the present application, the process of the access object initiating a resource access request for a business data resource can be called an access session.
[0063] Dynamic and static characteristics of application processes: Application processes have static and dynamic characteristics. Among them, static characteristics refer to the absolute path of the executable file of the application process, the hash of the process executable file, the application signature, the application copyright information, etc. Dynamic characteristic information includes information such as which system account starts the process and the command line for starting the process. Among them, in the application embodiment, the request parameters in the ticket acquisition request sent by the security application client to the security application server may include the dynamic and static characteristics of the application process.
[0064] Certificate pinning: A security measure mainly used to prevent man-in-the-middle attacks, commonly used in mobile devices, PCs, and other types of clients. The pinning requires the client to only accept specific server certificates or certificate chains to ensure that the client communicates with the expected server and avoids communicating with potential attackers. Among them, in the application embodiment of the present application, when there is data interaction between the security application server and the security application client (for example, the security application server sends the first access ticket to the security application client), the security application server and the security application client will mutually verify certificates, that is, the security application client will verify the certificate of the security application server, and the security application server will verify the certificate of the security application client. Only when the verification is successful at the same time, the security application server and the security application client establish a connection. Thus, the communication channel between the security application server and the security application client is highly secure, thereby avoiding attackers' attack operations on the first access ticket (for example, tampering with the first access ticket).
[0065] Please refer to Figure 1 , Figure 1 is a schematic structural diagram of a network architecture provided by an embodiment of the present application. As Figure 1 shown, the network architecture may include a user terminal cluster 100, a server 101, an intelligent gateway 102, and a service server cluster 103. The user terminal cluster may include one or more user terminals, and the number of user terminals is not limited here. As Figure 1 shown, the user terminal cluster may specifically include user terminals 100a, 100b,..., 100n. Among them, the user terminals in the user terminal cluster 100 may be various intelligent terminals with service data access functions such as smart phones, tablet computers, notebook computers, desktop computers, palm computers, mobile internet devices (MIDs), wearable devices (such as smart watches, smart bracelets, etc.), intelligent computers, and intelligent vehicles. As Figure 1 shown, the user terminals 100a, 100b,..., 100n may be respectively connected to the above-mentioned server 101 through a network, so that each user terminal can perform data interaction with the server 101 through this network connection.
[0066] It should be understood that Figure 1 each user terminal in the user terminal cluster shown can be installed with a service application and a target application (i.e., a security application client, for example, an iOA client). When the security application client runs on each user terminal, it can respectively perform data interaction with the server 101 shown above Figure 1 shown.
[0067] The service application (i.e., the service application client) here can be a social client, an office client, a retrieval client (for example, a browser client), a multimedia client (for example, a video client), an entertainment client (for example, a game client), an education client, a live broadcast client, a news client, a shopping client (for example, an e-commerce client), and other application clients. Among them, the service application (i.e., the trusted application) here refers to the application carrier through which the access user corresponding to the security application client can access the target service resource through the user terminal shown Figure 1 shown (for example, user terminal 100a), including the application name, application MD5 (an information digest strategy), signature information, etc.
[0068] As Figure 1 shown, the server 101 in the embodiment of the present application can be the server corresponding to the security application client, that is, a security application server (for example, an iOA server). The server 101 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.
[0069] Among them, in the embodiment of the present application, after the user logs in to the security application client through the user terminal (for example, user terminal 100a), the security application client, the security application server 101, and the intelligent gateway 102 can form a zero-trust security application system (or a zero-trust network access system) to provide security guarantees for enterprise resource access services. The server 101 (i.e., the security application server) is used to provide services such as policy distribution, resource access ticket issuance and verification, submission of unknown processes for inspection, and security detection for the zero-trust security application system. The intelligent gateway 102 is deployed at the entrance of enterprise application programs and data resources, and is responsible for the verification, authorization, and forwarding of each session request for accessing enterprise resources. In a possible implementation manner, the security application server 101 and the intelligent gateway 102 can be implemented through the same device. For example, they can be deployed on the same server. Of course, they can also be deployed on different devices, and the embodiment of the present application does not limit this.
[0070] Among them, it should be understood that the business server cluster 103 is used to provide enterprise resources for users accessing the enterprise business system. The business server cluster 103 may include one or more business servers, and the number of business servers is not limited here. Among them, the business server cluster 103 may specifically include business servers 103a, 103b, …, 103n, etc. Among them, the business servers in the business server cluster 103 may be independent physical servers, or server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.
[0071] In the embodiment of the present application, after a user (for example, user A) logs in to the security application client through the user terminal, when the user initiates a resource access request for business data resources (for example, document A) in a certain business server (for example, browser B), when the access proxy in the security application client intercepts the resource access request, it will initiate an authentication request (that is, a request for obtaining a network access credential / access ticket) to the security application client. Further, the security application client will authenticate the access permission of the user A based on the relevant parameters (such as user identity information, terminal device information, etc.) in the authentication request. When it is determined that the user A has the access permission, it will send a ticket acquisition request to the security application server. Further, the security application server will obtain the relevant parameters in the ticket acquisition request, and then configure a resource access ticket for the user A based on the configured zero-trust network access policy, and then return it to the security application client. It should be understood that the security application client forwards the resource access ticket to the access proxy, so that the access proxy generates a ticket verification request based on the resource access ticket and forwards the ticket verification request to the intelligent gateway. Further, the intelligent gateway sends the ticket verification request to the security application server, and then the security application server verifies the ticket in the ticket verification request. It should be understood that when the ticket verification is successful, the access proxy will forward the above resource access request to the intelligent gateway, so that the intelligent gateway forwards the resource access request to the above business server B, and then obtains the business data resources (for example, document A).
[0072] It can be understood that Figure 1 it only exemplarily represents the possible network architecture of the technical solution of the present application and does not limit the specific architecture of the technical solution of the present application, that is, the technical solution of the present application can also provide other forms of network architecture.
[0073] Further, please refer to Figure 2 , Figure 2It is a schematic diagram of a data processing flow for network access based on a zero-trust network access system provided by an embodiment of the present application. As Figure 2 shown, (1) The access subject initiates a resource access request for the access object through an application installed in the terminal device; (2) The security application client installed in the terminal device can hijack the resource access request through the access proxy and initiate an authentication request to the security application client, that is, apply to the security application client for a network access credential (i.e., a resource access ticket) for the current resource access request. The request parameters in the authentication request include the source IP or domain name, source port, destination IP or domain name, destination port, and the process identification number PID (Process ID) corresponding to the application, etc.; (3) The security application client collects the MD5 of the process, process path, process last modification time, copyright information, signature information, etc. through the process PID sent by the access proxy; (4) The security application client applies to the security application server for a ticket based on the MD5 of the process, process path, process last modification time, copyright information, signature information, etc., and the source IP or domain name, source port, destination IP or domain name, and destination port of the network request passed by the access proxy, etc. The security application server audits the parameters in the ticket application request. If the audit passes, it generates a resource access ticket and sends the resource access ticket, the maximum number of uses of the ticket, and the ticket validity period to the security application client; (5) The security application client sends the collected application process to the security application server to send the application process to the virus detection service in the cloud through the submission service in the security application server for virus detection; (6) The security application client sends the received resource access ticket, the maximum number of uses of the ticket, and the ticket validity period as a response to the access proxy; (7) The access proxy first initiates an Https request to the zero-trust gateway, and includes the resource access ticket passed by the security application client in the Authorization header field; (8) The zero-trust gateway sends a ticket verification request to the security application server; (9) The security application server sends the verification result to the zero-trust gateway. If the verification is successful, the zero-trust gateway successfully establishes a connection with the business server; (10) The access proxy sends the original resource access request to the zero-trust gateway, and the zero-trust gateway forwards it to the corresponding business server; (11) The business server returns the corresponding business data resource to the zero-trust gateway; (12) The zero-trust gateway forwards the business data resource to the access proxy; (13) The access proxy returns the business data resource to the terminal device. In addition, if the resource access ticket verification fails in (8), the connection between the access proxy and the zero-trust gateway is interrupted.
[0074] As Figure 2 shown in, there are multiple service modules set in the security application server, such as a policy center, a ticket center, a submission service, a security detection service, etc.
[0075] Among them, as Figure 2 shown, the policy center is used to configure and distribute zero-trust network access policies. When configuring zero-trust network access policies, the security application server can communicate with the security application management terminal (i.e., the interruption corresponding to the enterprise administrator), and display the corresponding page in the display interface of the security application management terminal, facilitating the enterprise administrator to configure policies on the page. After the configuration is completed, the zero-trust network access policy is distributed to the security application client, so that the security application client can manage the user's network resource access according to the zero-trust network access policy. The enterprise administrator can configure policies on the policy management page. For example, different accessible business systems can be set for different users or user groups for trusted application configuration, business system configuration, etc.; the enterprise administrator can configure the sites accessible to users on the add resource page.
[0076] Among them, as Figure 2 shown, the ticket center is to respond to the ticket application request of the security application client to return the resource access ticket, and to verify the resource access ticket after receiving the ticket verification request sent by the zero-trust gateway.
[0077] The submission inspection service sends the processes of the applications uploaded by the security application client to the virus detection service in the cloud for virus detection. The security detection service specifically includes an identity authentication module, a device trust module, and an application detection module. The identity authentication module is used to authenticate the user identity, the device trust module is used to verify the terminal device hardware information and the device security status, and the application detection module is used to detect whether the application process is secure, such as whether there are vulnerabilities, whether there are virus trojans, etc. When the security detection center passes the detection in all dimensions, it sends a resource access ticket to the security application client. At the same time, the submission inspection service also continuously performs virus killing on the process. When a virus is detected in the process, it notifies the security application client to perform an asynchronous blocking operation to interrupt the use of the resource access ticket.
[0078] For easy understanding, further, please refer to Figure 3 , Figure 3 which is a schematic diagram of a scenario for data interaction provided by an embodiment of the present application. As Figure 3 shown, the user terminal 30A in the embodiment of the present application can be the user terminal corresponding to the accessing user (for example, the above-mentioned user A), and this user terminal 30A can be any one of the user terminals in the corresponding embodiment of the above Figure 1 , for example, the user terminal 100a. Among them, a security application client (such as the security application client 301a shown in Figure 3 ) runs on this user terminal, and an access proxy component (such as Figure 3The access proxy 301b) shown. It should be understood that separating the security application client 301a and the access proxy 301b here is for the sake of logical process differentiation. Figure 3 The security application server 30B shown can be the server corresponding to the security application client, and this security application server 30B can be the Figure 1 server 101 in the above. Figure 3 The intelligent gateway 30C shown can be a network interconnection device associated with the security application client, and can correspond to Figure 1 the intelligent gateway 102 shown. Figure 3 The service server 30D shown can be the service server corresponding to the service application accessed by the access user (i.e., user A).
[0079] It should be understood that in the embodiments of the present application, user A can access the security application client 301a running on the user terminal 30A through the user account (e.g., user account 1) created by the managing user (e.g., user B) of the security application client 301a. When user A initiates a resource access request for document A in browser B through a business application (or business client, e.g., browser B) in user terminal 30A, when the access proxy 301b running on the security application client 301a intercepts the resource access request, it will execute step S31 and send an authentication request for the resource access request to the security application client 301a. In other words, the access proxy applies for an access credential for the current network request to the security application client 301a. At this time, when the security application client 301a obtains the relevant parameters in the authentication request based on the authentication request, it simultaneously obtains the terminal device information of the user terminal 30A. In the embodiments of the present application, the terminal device information can be referred to as device application data information. In addition, the security application client 301a will verify the access permission of user A, and then generate a ticket acquisition request. Further, execute step S32, and the security application client 301a sends a ticket acquisition request to the security application server 30B. The security application server 30B authenticates the access permission of user A. When it is determined that user A has access permission, it can obtain a zero-trust network access policy, and then based on the zero-trust network access policy and the above device application data information, determine the ticket generation influencing factors, and then can configure a resource access ticket for user A. Here, the resource access ticket can include a first access ticket and a second access ticket, and the zero-trust network access policy here can be configured by the managing user of the security management client for user A. Further, execute step S33, and the security application server 30B returns the resource access request to the security application client 301a. It should be understood that the security application client 301a can identify the first access ticket and the second access ticket in the resource access request to determine the ticket types of the first access ticket and the second access ticket. Further, when the security application client 301a identifies that the first access ticket is a first type of access ticket and the second access ticket is a second type of access ticket, it executes step S34, and the security application client 301a sends the resource access ticket to the access proxy 301b. Specifically, the security application client 301a encrypts the first type of access ticket and transmits it to the access proxy 301b through a highly secure transmission channel, and does not encrypt or performs low-level encryption on the second type of access ticket, and transmits it to the access proxy 301b through a low-security channel. Here, it should be understood that the highly secure transmission channel in the embodiments of the present application can be referred to as the first data transmission channel, and the low-security transmission channel can be referred to as the second data transmission channel.Further, after receiving the resource access ticket, the access proxy 301b generates a ticket verification request and executes step S35 to send the ticket verification request to the intelligent gateway 30C. Further, the intelligent gateway 30C executes step S36 to send the ticket verification request to the security application server 30B. The security application server 30B receives the ticket verification request, executes step S37 to verify the tickets in the ticket verification request respectively to obtain a ticket verification result, and after the ticket verification result indicates that the ticket verification is passed, executes step S38 to send a request forwarding notice to the intelligent gateway 30C. Further, when the intelligent gateway 30C obtains the resource access request forwarded by the access proxy, it executes step S39 to send the resource access request to the service server 30D. Further, the service server 30D executes step S40 to return the service data resource (the above-mentioned document A) to the intelligent gateway 30C, so that the intelligent gateway 30C executes step S41 to send the service data resource (the above-mentioned document A) to the access proxy 301b, so that user A can obtain the service data resource (the above-mentioned document A) through the terminal 30A.
[0080] It should be noted that in the embodiments of the present application, when the user terminal (for example, the user terminal 30A shown above) obtains relevant user information (for example, the information of the above-mentioned user A), a prompt interface, a pop-up window or a voice prompt message can be displayed, and the prompt interface, the pop-up window or the voice prompt message is used to prompt the user terminal that it is currently collecting its relevant data, so that the present application only starts to execute the relevant steps of obtaining the information of user A after obtaining the confirmation operation issued by the user for the prompt interface or the pop-up window, otherwise (that is, when the confirmation operation issued by the user for the prompt interface or the pop-up window is not obtained), the relevant steps of obtaining the information of the user A are ended. In other words, the user information collected in the present application is collected with the consent and authorization of the user, and the collection, use and processing of the relevant user information need to comply with the relevant laws, regulations and standards of the relevant countries and regions. Figure 3
[0081] The above Figure 3 is only a description of the overall data interaction scenario of a data resource access method, and the specific process will be further elaborated in the subsequent Figures 4 to 10 embodiments.
[0082] For ease of understanding, please refer to Figure 4 , Figure 4 which is a schematic flowchart of a data resource access method provided by an embodiment of the present application. As Figure 4 shown, this method can be executed by a security application server, and the security application server can correspond to the server 101 shown above. Figure 1 The method can specifically include the following steps S101-step S103.
[0083] Step S101: Receive a ticket acquisition request for business data resources sent by a security application client. When device application data information of the terminal device where the security application client is located is obtained based on the ticket acquisition request, generate a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and return the first access ticket and the second access ticket as resource access tickets to the security application client, so that when the security application client identifies that the resource access ticket includes a first type of access ticket and a second type of access ticket, send the first type of access ticket to the access proxy in the security application client through a first data transmission channel, and send device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through a second data transmission channel;
[0084] Among them, the security transmission level of the first data transmission channel is higher than that of the second data transmission channel.
[0085] Among them, it can be understood that the ticket acquisition request is generated by the security application client based on the device application data information and the access verification data information of the access object; the access verification data information is determined when the security application client verifies the access data information carried in the resource access request when the access proxy intercepts the resource access request for the business data resources sent by the access object through the business client and the information verification is successful; the device application data information is obtained by the security application client from the business client when the access verification data information is obtained;
[0086] Among them, the access object can correspond to the above-mentioned access user (for example, User A), and the business client can be a certain application client, such as a video client, a game client, and a browser client, etc. The business client will not be limited here.
[0087] Among them, when the security application client obtains the authentication request sent by the access proxy, it will obtain the request parameters in the authentication request (for example, request parameter 1), and the request parameter 1 can include, but is not limited to, the source IP or domain name, source port, destination IP or domain name, destination port, process identification number PID (Process ID) corresponding to the application, etc. The above-mentioned access data information can include the information in the above-mentioned request parameter 1.
[0088] In addition, it should be understood that when the security application client applies for a resource access ticket, it also needs to collect information such as terminal information, logged-in user information (i.e., access verification data information), and application feature information. Among them, the terminal information can specifically be the terminal unique identifier, terminal software and hardware information, compliance detection results, etc. The logged-in user information (i.e., access verification data information) is specifically the username, user ID, etc. of the user who logs in to the security application client. The application feature information can specifically be the source IP or domain name, source port, destination IP or domain name, destination port, and information such as the MD5 of the process, process path, recent modification time of the process, copyright information, and signature information collected according to the process PID corresponding to the application. Among them, the logged-in user is the user who logs in to the security application client, that is, the above-mentioned access object. Further, the security application client can send a ticket acquisition request for business data information to the security application server based on the access verification data information and device application data information (i.e., the above-mentioned terminal information, the user ID and username of the logged-in user, and application feature information).
[0089] Specifically, the security application server can receive the ticket acquisition request for business data resources sent by the security application client, and obtain the business access policy configured for the access object in the business access database based on the ticket acquisition request; further, the security application server can obtain the device application data information of the terminal device from the ticket acquisition request, and determine the ticket generation influencing factors associated with the access object based on the business access policy and the device application data information; in addition, the security application server can also generate a first access ticket and a second access ticket based on the ticket generation influencing factors, the device application data information, and the access verification data information, and can return the first access ticket and the second access ticket to the security application client as the resource access ticket.
[0090] Among them, the above-mentioned ticket generation influencing factors refer to the factors for the security application server to determine whether to respond to the resource access ticket.
[0091] Among them, in the embodiments of the present application, the above-mentioned business access policy can be Figure 2The zero-trust network access policy formulated by the enterprise administrator based on people / devices / applications in the corresponding embodiment. Here, the zero-trust network access policy will be further described. The enterprise administrator can group the users in the enterprise. For example, the users in the enterprise can be divided into Group 1, Group 2, and Group 3, and information such as the user accounts, user positions, and user working years of each group of users is recorded. At the same time, the business sites that each group of users can access and the business resources corresponding to the business sites are configured for each group of users. Here, the business sites can include, but are not limited to, sites that can obtain business resources such as QQ Browser, WeChat, and Enterprise WeChat, etc. It should be understood that the configured business sites here are trusted applications, and in addition, the business resources corresponding to the business sites are reachable areas. It should be understood that the enterprise administrator can also classify the sensitivity of each business site. For example, the above QQ Browser can be configured as a non-sensitive site, and Enterprise WeChat and WeChat can be configured as high-sensitive sites. In addition, the enterprise administrator can also configure the user permissions of the enterprise users. For example, the users in Department A can be configured as high-privilege users, and the users in Department B can be configured as ordinary users (i.e., low-privilege users).
[0092] After the security application server determines the ticket generation influencing factors associated with the access object based on the service access policy and device application data information, the specific implementation manners of generating the first access ticket and the second access ticket based on the ticket generation influencing factors, device application data information, and access verification data information can include the following four cases.
[0093] In an implementable embodiment, it should be understood that the access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes the resource feature information used to characterize the service data resources; the ticket generation influencing factors include the resource sensitivity of the service data resources; the resource sensitivity is determined based on the configured resource sensitivity of the matched resource configuration characteristic information when the resource feature information matches the resource configuration characteristic information in the service access policy;
[0094] Among them, the object information of the access object can include, but is not limited to, the user name and user ID for the access object to log in to the security client, etc. The device information of the terminal device can include, but is not limited to, the model, manufacturer, firmware version, recall information and security vulnerabilities, processor information, memory, and hard disk capacity of the terminal device, etc. The client information of the service client can include, but is not limited to, the MD5 of the application process, the process path, the recent modification time of the process, etc. Among them, the service client can be a certain application client, such as a video client, a game client, and a browser client, etc.
[0095] Among them, the resource feature information can be the feature information of the access object for accessing business data resources. For example, if the business data resource accessed by the access object is Document A, at this time, the resource feature information can be the document name and document size of Document A, etc. Correspondingly, the sensitivity of the business data resource can refer to the sensitivity of the above-mentioned Document A. As described above, the enterprise administrator can classify the sensitivity for each business site. Suppose Document A is the attendance sheet of the enterprise. At this time, the enterprise administrator can search for the resource configuration feature information that matches Document A in the zero-trust network access policy. For example, the resource configuration feature information can be: the document associated with attendance is a non-sensitive resource. At this time, it can be determined that Document A is a non-sensitive resource. Suppose again that this Document A is the financial status statement of the enterprise. At this time, the enterprise administrator can search for the resource configuration feature information that matches Document A in the zero-trust network access policy. For example, the resource configuration feature information can be: the document associated with finance is a highly sensitive resource. At this time, it can be determined that Document A is a highly sensitive resource.
[0096] Specifically, the security application server can obtain the object information, device information, and client information in the access verification data information from the ticket acquisition request, and can perform the first identity authentication on the access object based on the object information, device information, and client information, and then obtain the first identity authentication result; further, when the first identity authentication result indicates that the access object has access rights, the security application server can perform a sensitivity detection on the resource sensitivity in the ticket generation influencing factors based on the resource sensitivity threshold indicated by the service access policy, and can send the authentication indication information for performing the second identity authentication on the service object to the security application client when it detects that the resource sensitivity in the ticket generation influencing factors reaches the resource sensitivity threshold; further, the security application server can receive the secondary access data information sent by the service client through the security application client, and then, when it determines that the secondary access data information is consistent with the access verification data information, can generate a first access ticket based on the first ticket generation policy and device application data information indicated by the service access policy, and can generate a second access ticket based on the second ticket generation policy and device application data information indicated by the service access policy.
[0097] Among them, it should be understood that the above has elaborated on the access verification data information in detail. At this time, it can be in Figure 2The authentication module in the security detection service of the security application server in the corresponding embodiment can verify the object information in the access verification data information, the device feasibility module can verify the device information, and the application detection module can verify the client information. In this way, the security of the access object, the terminal device, and the application can be effectively ensured, thereby ensuring the reliability of the access process. Further, the resource sensitivity threshold here can be a highly sensitive resource, and any business data resource that is a highly sensitive resource is a resource that reaches the resource sensitivity threshold. It can be understood that at this time, the security application server can receive the secondary access data information sent by the business client through the security application client, and then, when it is determined that the secondary access data information is consistent with the access verification data information, it can generate a first access ticket based on the first ticket generation policy indicated by the business access policy and the device application data information, and can generate a second access ticket based on the second ticket generation policy indicated by the business access policy and the device application data information. It should be understood that when the resource sensitivity of the business data resource reaches the resource sensitivity threshold, the access object will exit the security application client, and the access user will then log in again and send secondary access verification data information to the security application server, and then the security application client will perform secondary authentication. Only when the secondary authentication passes will the first access ticket and the second access ticket be generated. Such a secondary authentication mechanism can further effectively ensure the security and reliability of the access object's access to the business data resource.
[0098] In an implementable embodiment, it should be understood that the access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the business client; the device application data information includes the permission characteristic information used to represent the access permission of the access object; the factors affecting ticket generation include the permission level of the access permission; the permission level is determined based on the configured permission level of the matched permission configuration characteristic information when the permission characteristic information matches the permission configuration characteristic information in the business access policy;
[0099] Among them, the specific explanations of the object information of the access object, the device information of the terminal device, and the client information of the service client included in the access verification data information can be referred to the above explanations of the access verification data information, and will not be elaborated here. In addition, the permission feature information can be information that can characterize the access permission of the access object, and can include, but is not limited to, the account name of the access object, the working years of the access object, and the job position of the access object, etc. As mentioned above, in addition, the enterprise administrator can configure the user permissions of the enterprise users. For example, the users in department A can be configured as high-permission users, and the users in department B can be configured as ordinary users (i.e., low-permission users). At this time, the enterprise administrator can search for the resource configuration feature information matching document A in the zero-trust network access policy. For example, the permission configuration feature information can be: the users in department A are high-permission users, and at this time, the permission level of the access object can be determined to be high-permission.
[0100] Specifically, the security application server can obtain the object information, device information, and client information in the access verification data information from the ticket acquisition request, and can perform the first identity authentication on the access object based on the object information, device information, and client information to obtain the first identity authentication result; further, when the first identity authentication result indicates that the access object has the access permission, the security application server can perform a level detection on the permission level in the ticket generation influencing factors based on the permission level threshold indicated by the service access policy, and when it is detected that the permission level in the ticket generation influencing factors reaches the permission level threshold, the security application server can generate a first access ticket based on the third ticket generation policy and the device application data information indicated by the service access policy, and generate a second access ticket based on the fourth ticket generation policy and the device application data information indicated by the service access policy.
[0101] Among them, it should be understood that the process of performing the first identity authentication on the access object has been described in detail above, and will not be elaborated here. It should be understood that this can effectively ensure the security of the access object, terminal device, and application, thereby ensuring the reliability of the access process. Further, the permission level threshold here can be high-permission, and any access object whose permission level is detected as high-permission reaches the permission level threshold. It can be understood that at this time, the security application server can receive the secondary access data information sent by the service client through the security application client, and then when it is determined that the secondary access data information is consistent with the access verification data information, the security application server can generate a first access ticket based on the third ticket generation policy and the device application data information indicated by the service access policy, and can generate a second access ticket based on the fourth ticket generation policy and the device application data information indicated by the service access policy.
[0102] In an implementable embodiment, it should be understood that the access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes the access behavior information used to characterize the access behavior of the access object; the factors affecting ticket generation include the behavior deviation degree between the access behavior information and the normal access behavior baseline; the normal access behavior baseline is formed by the security application server collecting and recording the historical access behavior information of the access object; the behavior deviation degree is determined by comparing the access behavior information with the normal access behavior baseline.
[0103] Among them, for the specific explanation of the access verification data information including the object information of the access object, the device information of the terminal device, and the client information of the service client, reference can be made to the above explanation of the access verification data information, and it will not be elaborated here. In addition, the access behavior information includes, but is not limited to, the time, frequency, etc. of the access object accessing the business data resource. For example, the access object (e.g., User A) accesses Document A K times, and the access time is 3:00:00. Among them, the security application server continuously collects the set of access times of User A accessing Document A. Assuming that the access times in this set of access times are all distributed between 8:00:00 and 18:00:00. The normal access behavior baseline formed at this time can be the access behavior time baseline.
[0104] Optionally, the normal access behavior baseline here can also be formed by the security application server collecting and recording the access behavior of access objects with the same attributes as the access object (e.g., User A); among them, the same attributes here can refer to the user cluster in the same work position as User A (e.g., User Group C). The security application server can continuously collect the behavioral feature information of the access behavior of the users in User Group C, and then record the access times of User Group C to the business data resource (e.g., Document A). At this time, the normal access behavior baseline formed by the access behavior of User Group C can be the access time baseline of User Group C.
[0105] Specifically, the security application server can obtain the object information, device information, and client information in the access verification data information from the ticket acquisition request, and can perform first identity authentication on the access object based on the object information, device information, and client information to obtain a first identity authentication result; further, when the first identity authentication result indicates that the access object has access authority, the security application server can compare the behavior deviation degree in the ticket generation influencing factors with the behavior deviation degree threshold indicated by the service access policy to obtain a first comparison result; further, when the first comparison result indicates that the behavior deviation degree in the ticket generation influencing factors reaches the behavior deviation degree threshold, the security application server can send authentication instruction information for performing second identity authentication on the service object to the security application client; further, the security application server can receive the secondary access data information sent by the service client through the security application client, and when it is determined that the secondary access data information is consistent with the access verification data information, the security application server can generate a first access ticket based on the fifth ticket generation policy and the device application data information indicated by the service access policy, and generate a second access ticket based on the sixth ticket generation policy and the device application data information indicated by the service access policy.
[0106] Among them, it should be understood that the process of performing the first identity authentication on the access object has been described in detail above, and it will not be elaborated here. It should be understood that this can effectively ensure the security of the access object, the terminal device, and the application, thereby ensuring the reliability of the access process. Further, assuming that the normal access behavior baseline here is the baseline formed by the above access time, at this time, the behavior deviation degree can refer to the difference in access time. At this time, the deviation degree threshold configured in the zero-trust network access policy can be 3 hours. Assume that the access time of the normal access behavior baseline is 8:00:00 - 18:00:00, and the access time of the access object is 3:00:00. At this time, it can be determined that the behavior deviation degree of the access behavior of the access object is 5 hours, that is, it reaches the behavior deviation degree threshold. It can be understood that at this time, the security application server can receive the secondary access data information sent by the service client through the security application client. Furthermore, when it is determined that the secondary access data information is consistent with the access verification data information, it can generate the first access ticket based on the fifth ticket generation policy and the device application data information indicated by the service access policy, and can generate the second access ticket based on the sixth ticket generation policy and the device application data information indicated by the service access policy. It should be understood that when the deviation degree between the access behavior of the access object and the behavior baseline of the normal access behavior reaches the behavior deviation degree threshold, the access object will exit the security application client, and the access user will then log in again and send the secondary access verification data information to the security application server. Furthermore, the security application client performs secondary authentication. Only when the secondary authentication passes, the first access ticket and the second access ticket will be generated. Such a secondary authentication mechanism can further effectively ensure the security and reliability of the access object to access the service data resources.
[0107] In an implementable embodiment, it should be understood that the access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes the environmental status information used to characterize the environmental status of the terminal device; the ticket generation influencing factors include the environmental status information;
[0108] Among them, the specific explanation of the access verification data information including the object information of the access object, the device information of the terminal device, and the client information of the service client can refer to the above explanation of the access verification data information, and it will not be elaborated here. In addition, the environmental status information of the terminal device environmental status may include, but is not limited to, the device security level of the terminal device, the network location of the terminal device, and whether there are vulnerabilities in the terminal device, etc.
[0109] Specifically, the security application server can obtain the object information, device information, and client information in the access verification data information from the ticket acquisition request, and can perform the first identity authentication on the access object based on the object information, device information, and client information to obtain the first identity authentication result. Further, when the first identity authentication result indicates that the access object has access rights, the security application server can compare the environmental status information in the ticket generation influencing factors with the environmental status threshold indicated by the service access policy to obtain a second comparison result. Further, when the second comparison result indicates that the environmental status information in the ticket generation influencing factors reaches the environmental status threshold, the security application server can send authentication instruction information for performing the second identity authentication on the service object to the security application client. In addition, the security application server can receive the secondary access data information sent by the service client through the security application client, and when it is determined that the secondary access data information is consistent with the access verification data information, it can generate a first access ticket based on the seventh ticket generation policy and the device application data information indicated by the service access policy, and generate a second access ticket based on the eighth ticket generation policy and the device application data information indicated by the service access policy.
[0110] It should be understood that the process of performing the first identity authentication on the access object has been described in detail above, and it will not be elaborated here. It should be understood that this can effectively ensure the security of the access object, the terminal device, and the application, thereby ensuring the reliability of the access process. Further, the above enterprise administrator can configure the environmental status threshold based on the zero-trust network access policy. Here, the environmental status threshold can be that the terminal device has security vulnerabilities, and the network location is outside the company corresponding to the enterprise, etc. Assuming that the device status of the terminal device at this time is that it has two security vulnerabilities, it can be determined that the device environmental status of the terminal device reaches the environmental status threshold. It can be understood that at this time, the security application server can receive the secondary access data information sent by the service client through the security application client. Then, when it is determined that the secondary access data information is consistent with the access verification data information, it can generate a first access ticket based on the seventh ticket generation policy and the device application data information indicated by the service access policy, and generate a second access ticket based on the eighth ticket generation policy and the device application data information indicated by the service access policy. It should be understood that when the environmental status of the terminal device changes to reach the environmental status threshold, the access object will exit the security application client, and the access user will log in again, and send secondary access verification data information to the security application server, and then the security application client will perform secondary authentication. Only when the secondary authentication passes, the first access ticket and the second access ticket will be generated. Such a secondary authentication mechanism can further effectively ensure the security and reliability of the access object accessing the service data resource.
[0111] Among them, further, taking the security application server generating the first access ticket and the second access ticket as an example, the specific process can be as follows. The security application server can use the device application data information as the first basic data field, and then perform a first marking operation on the first basic data field to obtain a first marked field, and can generate a first type of access ticket based on the first ticket generation policy indicated by the service access policy, and can use the first type of access ticket as the first access ticket; further, the security application server can use the device application data information as the second basic data field, and then perform a second marking operation on the second basic data field to obtain a second marked field, and can generate a second type of access ticket based on the second ticket generation policy indicated by the service access policy, and can use the second type of access ticket as the second access ticket.
[0112] It should be understood that the above device application data information includes the unique identifier of the terminal, the terminal software and hardware information, the compliance detection result, the name and account information of the logged-in user (i.e., the access object), the source IP or domain name, the source port, the destination IP or domain name, the destination port, and the MD5, process path, recent modification time of the process, copyright information, signature information, etc. of the process collected according to the process PID corresponding to the application. Therefore, the first basic data field is the above device application data information, and the above information can be arranged arbitrarily. In addition, the above first marking operation can be to mark the header field in the first basic data field. For example, the header field is marked as 0. It should be understood that at this time, the first marked field is the field with the header field marked as 0.
[0113] Similarly, the above second basic data field is the above device application data information, and the above information can be arranged arbitrarily. Similarly, the above second marking operation can be to mark the header field in the second basic data field. For example, the header field is marked as 1. It should be understood that at this time, the second marked field is the field with the header field marked as 1.
[0114] It should be understood that the above process is executed in the ticket center of the security application server as shown in Figure 2 Furthermore, the ticket center contains the first ticket generation policy and the second ticket generation policy indicated by the service access policy (for example, the zero-trust network access policy). Among them, the first ticket generation policy and the second ticket generation policy can be the same policy or different policies. Specifically, the first ticket generation policy can be OAuth2.0, and the second ticket generation policy can be JWT (JSON Web Token). It should be understood that both OAuth2.0 and JWT refer to methods for configuring network access credentials (i.e., resource access tickets) for access with access permissions. Among them, in the embodiments of the present application, the first ticket generation policy and the second ticket generation policy are not limited.
[0115] Among them, it should be noted that the above-mentioned first type of access ticket and the second type of access ticket have similar appearance features, such as the same length, and are both composed of specific uppercase and lowercase letters, numbers, or special characters. In addition, a ticket identification strategy for identifying the first type of access ticket and the second type of access ticket will be jointly agreed upon between the security application server and the security application client (including the access proxy). Specifically, when the security application server receives a ticket verification request subsequently, it can parse the ticket in the ticket verification request to perform ticket identification. For example, identification can be performed based on the above-mentioned first marker field and second marker field. Specifically, a ticket containing the first marker field can be identified as the first type of access ticket, and a ticket containing the second marker field can be identified as the second type of access ticket. Among them, the specific process of the security application server parsing the ticket in the ticket verification request to perform ticket identification will be elaborated in detail in the subsequent embodiments and will not be elaborated here.
[0116] It should be noted that the security application client will also perform ticket identification on the resource access ticket, and the specific process will be elaborated in detail in the subsequent embodiments. In addition, the specific process of the security application client sending the first type of access ticket to the access proxy through the first data transmission channel and sending the second type of access ticket to the access proxy through the second data transmission channel will also be elaborated in detail in the subsequent embodiments.
[0117] Among them, optionally, the number of the above-mentioned second type of access tickets can be multiple and is configured by the service data policy (i.e., the zero-trust network access policy), and the number of the second type of access tickets will not be limited in the embodiments of the present application.
[0118] Specifically, please refer to Figure 5 , Figure 5 which is a schematic diagram of generating a resource access ticket provided by the embodiments of the present application. After the security application server receives a resource access request, the security application server obtains the resource access request (i.e., application process information) initiated by the access object from the device data information in the resource access request, and then issues an access ticket based on the above-mentioned ticket generation influencing factors, device application data information, and access verification data information. As shown in the figure, the policy center determines Process 1 for the process PID in the device application data information, and generates Ticket A corresponding to Process 1, Ticket B corresponding to Process 1, …, and Ticket N corresponding to Process 1. Among them, generating Ticket A corresponding to Process 1 is the first type of access ticket, and Ticket B corresponding to Process 1, …, and Ticket N corresponding to Process 1 are the second type of access tickets. It should be understood that Process 1 can represent information such as the access time of the access object to the business data resource and the resource name of the business data resource.
[0119] Optionally, the process in which the above security application server generates the first type of access ticket based on the third ticket generation policy and generates the second type of access ticket based on the fourth ticket generation policy, the process in which the security application server generates the first type of access ticket based on the fifth ticket generation policy and generates the second type of access ticket based on the sixth ticket generation policy, and the process in which the security application server generates the first type of access ticket based on the seventh ticket generation policy and generates the second type of access ticket based on the eighth ticket generation policy can all refer to the process in which the security application server generates the first type of access ticket based on the first ticket generation policy and generates the second type of access ticket based on the second ticket generation policy, which will not be elaborated here.
[0120] Further, the security application server issues the above ticket as a resource access ticket to the security application client. The relevant processing of the security application client will be elaborated in detail in the subsequent embodiments and will not be elaborated here.
[0121] Step S102: Receive the ticket verification request sent by the access proxy through the intelligent gateway, and perform ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request respectively, to obtain the first ticket verification result associated with the first ticket to be verified and the second ticket verification result associated with the second ticket to be verified.
[0122] It should be understood that the intelligent gateway is deployed between the service client in the terminal device and the service server storing the service data resources, and can refer to Figure 2 the zero-trust gateway in the corresponding embodiment.
[0123] It should be understood that after receiving the ticket verification request sent by the access proxy through the intelligent gateway, a ticket identification operation can be performed. Specifically, the security application server can obtain the first ticket to be identified and the second ticket to be identified from the ticket verification request; further, the security application server can perform a first ticket identification operation on the first ticket to be identified based on the ticket identification policy to obtain a first ticket identification result; it should be understood that if the first ticket identification result indicates that the first marked field is identified in the first ticket to be identified, it can be determined that the first ticket to be identified is the first type of access ticket, and the first type of access ticket is used as the first ticket to be verified; further, the security application server can perform a second ticket identification operation on the second ticket to be identified based on the ticket identification policy to obtain a second ticket identification result; it should be understood that if the second ticket identification result indicates that the second marked field is identified in the second ticket to be identified, it can be determined that the second identified ticket is the second type of access ticket, and the second type of access ticket is used as the second ticket to be verified.
[0124] Among them, it should be understood that the above-mentioned bill recognition strategy is jointly agreed upon by the security application client and the security application server. For example, in the above step S101, the first type of access bill includes a first marker field (i.e., the field with the header field marker of 0) and a second marker field (i.e., the field with the header field marker of 1). The bill recognition strategy is specifically expressed as recognizing the bill containing the first marker field as the first type of access bill, and recognizing the bill containing the second marker field as the second type of access bill.
[0125] Specifically, please refer to Figure 6 , Figure 6 which is a schematic diagram provided by an embodiment of the present application for performing bill verification and obtaining a bill verification result. As Figure 6 shown, this method can be executed by a security application server, and the security application server can be Figure 3 the security application server 30B in the corresponding embodiment. The method can specifically include the following steps S201 - step S208.
[0126] Step S201, perform a first information parsing operation on the first bill to be verified to obtain first configuration verification information associated with the first type of access bill;
[0127] Among them, the first configuration verification information may include the above-mentioned terminal device data information, that is, the unique identifier of the terminal, terminal software and hardware information, compliance detection results, the name and account information of the logged-in user (i.e., the access object), source IP or domain name, source port, destination IP or domain name, destination port, and information such as the MD5 of the process, process path, process last modification time, copyright information, and signature information collected according to the process PID corresponding to the application. It may also include information such as the maximum number of uses of the first bill to be verified and the bill validity period.
[0128] Step S202, perform bill verification on the first bill to be verified based on the first configuration verification information to obtain a first bill verification result;
[0129] Among them, if the first bill verification result indicates that the first configuration verification information passes the verification, it can be determined that the first bill to be verified is the first access bill; specifically, the security application server will detect the above-mentioned first configuration verification information at the security detection location. If it is verified that the user information in the first configuration verification information is trustworthy, the process PID is secure, and the compliance detection passes, it is determined that the first configuration verification information has legality, and at the same time, it is synchronously verified whether the bill validity period of the first bill to be verified has expired and whether the bill still has the number of uses. If all the above information passes the verification, it can be determined that the first bill to be verified is the first access bill. Conversely, if any one item fails to pass the verification, it can be determined that the first bill to be verified is not the first access bill.
[0130] Step S203: Perform a second information parsing operation on the second bill to be verified to obtain second configuration verification information associated with the second type of access bill;
[0131] Among them, the second configuration verification information may include the above-mentioned terminal device data information, that is, the unique identifier of the terminal, terminal software and hardware information, compliance detection results, the name and account information of the logged-in user (i.e., the access object), source IP or domain name, source port, destination IP or domain name, destination port, and information such as the MD5 of the process, process path, process last modification time, copyright information, and signature information collected according to the process PID corresponding to the application. It may also include information such as the maximum number of uses of the second bill to be verified and the valid time of the bill.
[0132] Step S204: Perform bill verification on the second bill to be verified based on the second configuration verification information and device auxiliary information to obtain a second bill verification result;
[0133] Among them, the device auxiliary information is obtained by the security application client from the terminal registry based on the information acquisition component after receiving the resource access bill. The terminal registry includes the machine information, software and hardware information of the terminal device, and the login information of the access object (i.e., the account, id, etc. of the access object).
[0134] Among them, if the second bill verification result indicates that the second configuration verification information passes the verification and the second configuration verification information is consistent with the device auxiliary information, it can be determined that the second bill to be verified is the second access bill. Specifically, the security application server will detect the above-mentioned second configuration verification information at the security detection. If it is verified that the user information in the second configuration verification information is trustworthy, the process PID is safe, and the compliance detection passes, it is determined that the second configuration verification information is legal, and the valid time of the second bill to be verified and whether the bill still has the number of uses are synchronously verified. In addition, the information in the device auxiliary information and the second configuration verification information will be compared. If the comparison result is consistent and the above information passes the verification, it can be determined that the second bill to be verified is the second access bill. Otherwise, if any item fails, it can be determined that the second bill to be verified is not the second access bill.
[0135] Step S205: If the first bill verification result indicates that the first bill to be verified is the first access bill and the second bill verification result indicates that the second bill to be verified is the second access bill, notify the intelligent gateway to forward the resource access request to the business server when the intelligent gateway obtains the resource access request sent by the service client intercepted by the access proxy;
[0136] It should be understood that if the first ticket verification result indicates that the first ticket to be verified is the first access ticket, and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, this means that the resource access ticket issued by the security application server and the ticket to be verified forwarded by the security application client through the access proxy and the intelligent gateway have not been tampered with by the attacker during the transmission process, that is, the access process is safe. Therefore, the access proxy can send the resource access request to the intelligent gateway, and the intelligent gateway forwards it to the business server, so that the business server returns the business data resources to the intelligent gateway. Furthermore, the intelligent gateway returns the business data resources to the business client through the access proxy, so that the access object obtains the business data resources. This means that the resource access process is completely completed and the access process is safe and reliable.
[0137] Step S206, if the first ticket verification result indicates that the first ticket to be verified is the first access ticket, and the second ticket verification result indicates that the second ticket to be verified is not the second access ticket, then notify the security application client to interrupt the connection between the access proxy and the intelligent gateway;
[0138] Among them, the second ticket verification result indicates that the second ticket to be verified is not the second access ticket, that is, the above-mentioned second configuration verification information verification fails, or the device auxiliary information is inconsistent with the second configuration verification information. This means that the resource access ticket issued by the security application server and the ticket to be verified forwarded by the security application client through the access proxy and the intelligent gateway may be tampered with by the attacker during the transmission process, that is, the access process is not safe. Therefore, the security application server takes security defense measures, including notifying the security application client to interrupt the connection between the access proxy and the intelligent gateway, forcing the access object to exit the application (i.e., the application that initiates the resource access request), and other operations. Among them, in the embodiments of the present application, the specific operations of the above-mentioned security defense operations will not be limited.
[0139] It should be understood that the above also verifies the ticket validity period and the maximum number of times the ticket is used of the second ticket to be verified. If the ticket has expired or the maximum number of times it is used is 0, the verification will fail. Therefore, the security application server takes the security defense measures as described above.
[0140] Step S207: if the first ticket verification result indicates that the first ticket to be verified is not the first access ticket, and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, then notify the security application client to interrupt the connection between the access proxy and the intelligent gateway;
[0141] Among them, the first bill verification result indicates that the first bill to be verified is not the first access bill, that is, the above-mentioned first configuration verification information fails the verification. This means that when the security application server issues a resource access bill, and the security application client forwards the bill to be verified through the access proxy and the intelligent gateway, there is a possibility that it is tampered with by an attacker during the transmission process, that is, this access process is insecure. Therefore, the security application server takes the security defense measures as in step S206 above.
[0142] It should be understood that the above also verifies the validity time of the first bill to be verified and the maximum number of uses of the bill. If the bill has expired or the maximum number of uses is 0, the verification will also fail at this time. Therefore, the security application server takes the security defense measures as above.
[0143] Step S208, if the first bill verification result indicates that the first bill to be verified is not the first access bill, and the second bill verification result indicates that the second bill to be verified is not the second access bill, then notify the security application client to interrupt the connection between the access proxy and the intelligent gateway.
[0144] It should be understood that the first bill verification result indicates that the first bill to be verified is not the first access bill, and the second bill verification result indicates that the second bill to be verified is not the second access bill. This also means that when the security application server issues a resource access bill, and the security application client forwards the bill to be verified through the access proxy and the intelligent gateway, there is a possibility that it is tampered with by an attacker during the transmission process, that is, this access process is insecure. Therefore, the security application server takes the security defense measures as in step S206 above.
[0145] Optionally, if the security application server fails to parse the second bill to be verified when parsing the second bill to be verified, then the second access bill may be tampered with by an attacker. At this time, the security application server takes the security defense measures as in step S206 above.
[0146] Optionally, in the embodiment of the present application, when the security application server receives a bill verification request and then performs bill identification on the bill carried in the bill verification request, once the above-mentioned second type of access bill is identified, the security application server may notify the security application client to restrict the access permission of the access object, and may take further security defense operations such as further identity verification on the access object.
[0147] Step S103, when the first bill verification result indicates that the first bill to be verified is the first access bill, and the second bill verification result indicates that the second bill to be verified is the second access bill, notify the intelligent gateway to forward the resource access request sent by the service client intercepted by the access proxy to the service server when the intelligent gateway obtains the resource access request;
[0148] Among them, the resource access request is used to instruct the service server to authorize the service client to access the service data resource. For example, the access request initiated by the access object (such as the above-mentioned User A) through the service application (such as Browser B) for Document A (i.e., the service data resource).
[0149] Among them, the specific implementation process of step S103 can refer to the description in step S205 above, and will not be elaborated here.
[0150] It can be seen that in the embodiments of the present application, the security application server can receive a ticket acquisition request for business data resources sent by the security application client. When the device application data information of the terminal device where the security application client is located is obtained based on the ticket acquisition request, the security application server can generate a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and can return the first access ticket and the second access ticket to the security application client as resource access tickets, so that when the security application client identifies that the resource access ticket includes a first type of access ticket and a second type of access ticket, the first type of access ticket is sent to the access proxy in the security application client through the first data transmission channel, and the device auxiliary information associated with the terminal device and the second type of access ticket are sent to the access proxy through the second data transmission channel; wherein, the security transmission level of the first data transmission channel here is higher than that of the second data transmission channel; wherein, the security application server issues the first type of access ticket and the second type of access ticket simultaneously, and transmits the second type of access ticket through the second data transmission channel with a lower security transmission level. This means that the second type of access ticket will not be encrypted or will be encrypted at a low level. In this way, when an attacker attempts to tamper with the access ticket, the attacker will be misled into thinking that the second type of access ticket is the first type of access ticket issued by the server, inducing the attacker to tamper with the second type of access ticket, so that during the subsequent verification process of the second type of access ticket, the tampering behavior of the attacker can be judged. Further, the security application server can receive a ticket verification request sent by the access proxy through the intelligent gateway, and perform ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request respectively, to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; further, when the first ticket verification result indicates that the first ticket to be verified is the first access ticket, and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, the security application server can notify the intelligent gateway to forward the resource access request to the business server when the intelligent gateway obtains the resource access request intercepted by the access proxy from the business client. Specifically, when verifying the second type of access ticket, the relevant information for generating the second type of access ticket can be compared with the above-mentioned device auxiliary information. When the comparison result indicates inconsistency, the security application server can effectively discover the tampering behavior of the attacker against the second type of access ticket, thereby disabling the access permission of the access object and interrupting the connection between the access proxy and the intelligent gateway, and then interrupting this access.It can be seen that by issuing the first access ticket and the second access ticket, the security application server can effectively detect the tampering behavior of the attack on the ticket and the illegal access behavior to the service data resource. When the tampering behavior is detected, security defense measures can be taken in a timely manner to interrupt the access session, thereby ensuring the security and reliability of the access object when accessing the service data resource.
[0151] Further, please refer to Figure 7 , Figure 7 which is a schematic flowchart of another method for accessing data resources provided by an embodiment of the present application. As Figure 7 shown, this method can be executed by a terminal device running a security application client, and the terminal device can be Figure 3 the user terminal 30A in the corresponding embodiment, and the security application client can correspond to the security application client 301a shown in the above Figure 3 . The method can specifically include the following steps S301-S304.
[0152] Step S301: Send a ticket acquisition request for the service data resource to the security application server;
[0153] Among them, the specific implementation manner of step S301 can be referred to the description in the corresponding embodiment above Figure 3 , and will not be elaborated here.
[0154] Step S302: Receive the resource access ticket returned by the security application server, perform ticket identification on the first access ticket and the second access ticket carried in the resource access ticket, and obtain a ticket identification result;
[0155] Among them, it should be understood that the first access ticket and the second access ticket are generated by the security application server based on the device application data information of the terminal device where the security application client is located carried in the ticket acquisition request;
[0156] Among them, it should be noted that during the process of the security application server sending the first type of access ticket in the resource access ticket to the security application client, the network communication security between the security application client and the security application server is strictly guaranteed. First, to avoid using protocols with known security vulnerabilities, both the security application client and the security application server use the latest version of the Transport Layer Security (TLS) protocol (such as TLS 1.3) and secure encryption suites to implement mutual authentication of HTTPS, thereby achieving communication security between the terminal device and the security application server. Further, configure SSL / TLS in the Web server (such as Nginx) of the security application server, install the server certificate, enable client certificate verification at the same time, and add the trusted CA certificate to the trust list. In this way, the security application server will require the security application client to provide a valid client certificate during the TLS handshake process. Among them, the CA certificate is issued by the certification authority service provider and is the technical foundation guarantee of digital signature, which can effectively ensure that the information in the communication process will not be tampered with. Further, on the side of the security application client, the certificate or public key of the security application server will be embedded in the application program in the security application client, and the security storage of the certificate or public key will be ensured in the encrypted persistent library of the terminal device. When initiating an HTTPS request, the security application client will carry the client certificate to authenticate with the security application server. During the TLS handshake, the security application client and the security application server will mutually verify each other's certificates, and in the security application client, a custom certificate verification logic is implemented. When establishing a TLS connection with the security application server, the security application client will verify whether the certificate provided by the security application server matches the embedded certificate or public key. Only when the certificates match will the security application client accept the certificate of the security application server and establish a secure connection. Only when both certificates are valid and trustworthy will a secure communication channel be established. Similarly, to enhance the network communication security between the security application client and the security application server, the security application client certificate will be stored in the encrypted persistent library of the terminal device to ensure the secure storage of the certificate and prevent leakage or abuse.
[0157] Specifically, the security application client can receive the resource access ticket returned by the security application server, and obtain the first access ticket and the second access ticket from the resource access ticket; further, the security application client can perform a first ticket identification operation on the first access ticket based on the ticket identification policy to obtain a first ticket identification result; wherein, it should be understood that the ticket identification policy is jointly determined by the security application client and the security application server; it should be understood that if the first ticket identification result indicates that a first marker field is identified in the first access ticket, the security application client can determine that the first access ticket is a first type of access ticket; wherein, it should be understood that the first marker field is obtained by performing a first marking operation on the first basic data field, and the first basic data field is device application data information; in addition, the security application client can perform a second ticket identification operation on the second access ticket based on the ticket identification policy to obtain a second ticket identification result; further, if the second ticket identification result indicates that a second marker field is identified in the second access ticket, the security application client can determine that the second access ticket is a second type of access ticket; wherein, it should be understood that the second marker field is obtained by performing a second marking operation on the second basic data field, and the second basic data field is device application data information.
[0158] Among them, the above implementation can refer to Figure 4 the process in which the security application server in the corresponding embodiment performs ticket identification on the ticket in the request to be verified, which will not be elaborated here.
[0159] Step S303, when the ticket identification result indicates that the first access ticket is a first type of access ticket, send the first type of access ticket to the access proxy in the security application client through the first data transmission channel.
[0160] It should be understood that after the security application client obtains and identifies the first type of access ticket (i.e., the first access ticket), each component in the security application client needs to transfer and share the ticket through inter-process communication and other means. Taking the communication between the security application client and the access proxy as an example, to enhance the security of the inter-process communication (IPC) between the security application client and the access proxy process, in addition to adopting a secure IPC mechanism and encrypting the transmitted data using a relatively strong cryptographic algorithm (e.g., the AES symmetric encryption algorithm) and mode (e.g., the GCM mode), other methods are also combined to enhance communication security, including generating a shared key using a key agreement algorithm (e.g., the Diffie-Hellman key exchange) between security application client components before establishing an IPC channel. When establishing an IPC channel, a session key and a message authentication code (MAC) are generated based on the dynamically negotiated shared key. This session key is used to encrypt and decrypt communication data, while the message authentication code ensures that the data is not tampered with during transmission. Secondly, in a long-term IPC communication, a mechanism for periodically updating the dynamically negotiated key is combined to further reduce the risk of the key being cracked by an attacker. Finally, the programs on both sides of the IPC channel mutually verify the digital signatures, executable file hashes, etc. of the peer programs to prevent third-party programs from forging legitimate communication processes.
[0161] In addition, to increase the difficulty for an attacker to crack the security communication mechanism in the security application client, obfuscation processing is performed on key code segments related to the zero-trust network access system. Using an obfuscation tool can obfuscate the code of the original program, making it more difficult to understand in static analysis and increasing the difficulty for an attacker to analyze the program. Further, an anti-debugging and anti-detection function is included in the shell program to prevent an attacker from using a debugger or detector to analyze the obfuscated program. In other aspects, a terminal encryption (white-box) persistence library is used for storing sensitive data including tickets. Sensitive data is encrypted using a random key in memory, the ciphertext is stored in memory, decrypted when used, and the plaintext is destroyed. It should be understood that the first data transmission channel is the secure transmission channel between the security application client and the access proxy mentioned above.
[0162] Thus, it can be seen the storage security of the first access ticket in the security application client and the transmission security of the first access ticket between the security application client and the access proxy.
[0163] Step S304, when the bill recognition result indicates that the second access bill is a second - type access bill, obtain the device - assisted information associated with the terminal device, and send the second - type access bill and the device - assisted information to the access agent through the second data transmission channel, so that when the access agent obtains the first - type access bill and the second - type access bill, it takes the first - type access bill as the first bill to be recognized and the second - type access bill as the second bill to be recognized, generates a bill verification request based on the first bill to be recognized, the second bill to be recognized, and the device - assisted information, and sends the bill verification request to the security application server through the intelligent gateway.
[0164] Among them, the number of the second - type access bills is N, and N is a positive integer.
[0165] Specifically, the security application client can store the second - type access bills in the file storage system in the security application client and can take the second - type access bills as the original stored bills. Further, the security application client can obtain the device - assisted information associated with the terminal device and can send the second - type access bills, the device - assisted information, and the file path of the file storage system to the access agent through the second data transmission channel, so that when the access agent obtains the second - type access bills, it stores S second - type access bills as the bills to be selected in the memory; where S is a positive integer less than N. In addition, the security application client can send a bill verification request generation instruction to the access agent, so that when the access agent receives the bill verification request generation instruction, it takes the first - type access bill as the first bill to be recognized and selects one bill from the bills to be selected as the second bill to be recognized, generates a bill verification request based on the first bill to be recognized, the second bill to be recognized, and the device - assisted information, and sends it to the security application server through the intelligent gateway.
[0166] Among them, it should be understood that during the process of the security application server sending the second - type access bill (i.e., the second access bill) to the security application client, no security reinforcement measures or low - level reinforcement measures (compared with the above - mentioned first data transmission channel) are taken.
[0167] Among them, the specific process for the security application client to obtain the device - assisted information associated with the terminal device can be: the security application client reads the terminal registry information in the security application client through the information acquisition module configured in the security application client, so as to obtain the device - assisted information. The device - assisted information can include the machine information of the terminal device (such as machine name, device version, etc.), software and hardware information (such as the type of the operating system of the terminal device, the operating system version information, and the CPU model, etc.), and the information of the logged - in user (i.e., the access object) (such as user name, user account, etc.).
[0168] Further, in the process that the security application server sends the second type of access ticket (i.e., the second access ticket) and device assistance information to the access proxy, the inter-process communication channel passed through does not adopt any security reinforcement measures or adopts relatively low-level reinforcement methods. For example, in the process of storing the second type of access ticket in the local file system as described above, no encryption processing is performed, or a fixed short key is used to perform symmetric encryption processing on the file content using a simple block encryption mode (e.g., ECB mode, etc.), the processing logic is not shelled, the second type of access ticket is transmitted in plain text between processes, and the peer program is not verified, etc. Here, the inter-process communication channel between the security application server and the access proxy is the second data transmission channel.
[0169] Therefore, it should be understood that the security transmission level of the first data transmission channel is higher than that of the second data transmission channel.
[0170] Further, please refer to Figure 8 , Figure 8 which is a schematic diagram of a security application client processing a resource access ticket provided by an embodiment of the present application. As Figure 8 shown, in the embodiment of the present application, the security application server 80A can be the server corresponding to the security application client, and the security application server 80A can be the security application server 30B in Figure 3 above. As Figure 8 shown, the security application client 80B can correspond to the security application client 301a as Figure 3 shown. Figure 8 The access proxy 80C shown as Figure 3 shown can correspond to the access proxy 301b as
[0171] Specifically, the ticket center in the security application server 80A sends a resource access ticket 801a to the security application client 80B. Further, the security application client 80B receives the resource access ticket 801a, and then obtains the resource access ticket 801a, and performs a ticket recognition operation on the resource access ticket 801a based on the ticket recognition policy, so as to recognize the access ticket 802a and the access ticket 802b in the resource access ticket 801a. Among them, it should be understood that the access ticket 802a can correspond to the above-mentioned first type of access ticket, the access ticket 802b can correspond to the above-mentioned second type of access ticket, and the specific implementation process of performing the ticket recognition operation on the resource access ticket 801a can refer to the descriptions in the above steps S302 and S303. Further, the security application client 80B obtains the information 802c, and encrypts and stores the access ticket 802a and the access ticket 802b in the file storage system 80a. It should be understood that the information 802c can correspond to the above-mentioned device auxiliary information. At this time, the access ticket 802b here can correspond to the above-mentioned original cache ticket (that is, the second type of access ticket with a quantity of N), and the specific implementation process of obtaining the information 802c can refer to the description in the above step S303.
[0172] Further, the security application client 80B sends the access ticket 802a (i.e., the second type of access ticket) to the access proxy 80C through the transmission channel 81a, and at the same time sends the access ticket 802c, the information 802c, and the file path of the file storage system 80a to the access proxy 80C through the transmission channel 81b. Among them, it should be understood that the transmission channel 81a here can correspond to the above-mentioned first data transmission channel, and the transmission channel 81b can correspond to the above-mentioned second data transmission channel.
[0173] Based on the above Figure 8 , further, please refer to Figure 9 , Figure 9 is a schematic diagram of a resource access ticket processed by an access proxy provided by an embodiment of the present application. As Figure 9 shown, the access proxy 90A in the embodiment of the present application can correspond to the access proxy 80C shown in Figure 8 . In addition, Figure 9 the intelligent gateway 90B shown can be a network interconnection device associated with the security application client (for example, the security application client 80B shown in Figure 8 ), and can correspond to the intelligent gateway 30C shown in Figure 3 . Figure 9 The security application server 90C shown can correspond to the security application server 80A corresponding to the above Figure 8 .
[0174] Specifically, the access agent 90A obtains the access ticket 901a, the access ticket 901b, the information 901c, and the file path of the file storage system 90a, and stores the second access ticket 901b with the quantity of S as the to-be-selected ticket 901d in the memory. It should be understood that the access ticket 901a here can correspond to the access ticket 802a (i.e., the first type of access ticket) sent through the transmission channel 81a in the corresponding embodiment above Figure 8 The access ticket corresponding to the access ticket sent through the transmission channel 81a in the corresponding embodiment (i.e., the first type of access ticket), and the access ticket 901b can correspond to the above Figure 8 The access ticket 802b (i.e., the second type of access ticket) sent through the transmission channel 81b in the corresponding embodiment, and the information 901c can correspond to the above Figure 8 The information 802c (i.e., the above device auxiliary information) sent through the transmission channel 81b in the corresponding embodiment. The file path of the file storage system 90a can correspond to the above Figure 8 The file path of the file storage system 80a sent through the transmission channel 81b in the corresponding embodiment.
[0175] Further, the access agent 90A takes the access ticket 901a as the access ticket 902a, selects one ticket from the to-be-selected tickets 901d as the access ticket 902b, generates a ticket verification request 903a based on the access ticket 902a, the access ticket 902b, and the information 901c, and then sends it to the intelligent gateway 90B. Further, the intelligent gateway 90B sends the ticket verification request 903a to the security application server 90C, and then the security application server 90C performs further verification based on the ticket verification request 903a. It should be understood that the specific process of the security application server 90C for ticket verification can refer to the specific description in the corresponding embodiment above Figure 4 And will not be elaborated here.
[0176] It should be understood that both the access ticket 802a and the access ticket 802b stored in the security application client 80B as shown above Figure 8 Will be associated with the corresponding business application (for example, application B1) and business data resource (for example, resource B2).
[0177] Therefore, when the access object generates a resource access request by accessing the resource B2 through the application B1 for the next time, when the access agent 90A intercepts the resource access request, it can directly obtain the first type of access ticket from the file storage system of the security application client (for example, the file storage system 80a of the above security application client 80B) Figure 8The access ticket 802b) shown, select a ticket (i.e., the second type of access ticket) from the tickets to be selected 901d in its own memory, and generate a new ticket verification request (different from the ticket verification request 903a) in combination with the above information 901c.
[0178] Optionally, after the access proxy 90A selects a ticket from the tickets to be selected 901d each time, it will decrement the tickets to be selected 901d by one. Then, when the number of accesses reaches S times, that is, the tickets to be selected 901d decrement to 0, which means that there are no longer second-type access tickets in the memory of the access proxy 90A. At this time, the access proxy 90A will read the second-type access ticket stored in the secure application client based on the file path of the file storage system 90a (for example, the access ticket 802b in the above Figure 8 ), and then select a ticket from the access ticket 802b, and generate a ticket verification request in combination with the above access ticket 901a and information 901c.
[0179] It should be understood that by storing tickets in the secure application client and the access proxy, it is possible to avoid sending ticket acquisition requests to the secure application server every time the access object initiates a resource access request for the same business data resource (for example, the above resource B2) through the same business application (for example, the above application B1), thereby reducing the complexity of data resource access and improving the efficiency of data resource access.
[0180] As can be seen, in the embodiments of the present application, the security application server can receive a ticket acquisition request for business data resources sent by the security application client. When obtaining the device application data information of the terminal device where the security application client is located based on the ticket acquisition request, the security application server can generate a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and can return the first access ticket and the second access ticket to the security application client as resource access tickets. Further, when the security application client recognizes that the resource access ticket includes a first type of access ticket and a second type of access ticket, the security application client can send the first type of access ticket to the access proxy in the security application client through the first data transmission channel, and send the device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through the second data transmission channel; wherein, the security application server issues the first type of access ticket and the second type of access ticket simultaneously, and transmits the second type of access ticket through the second data transmission channel with a lower security transmission level. Since the security transmission level of the first data transmission channel here is higher than that of the second data transmission channel, this means that when an attacker intends to tamper with the access ticket, the attacker will mistake the second type of access ticket for the first type of access ticket issued by the server, inducing the attacker to tamper with the second type of access ticket, so that during the subsequent verification process of the second type of access ticket, the tampering behavior of the attacker can be effectively judged. Further, the security application server can receive a ticket verification request sent by the access proxy through the intelligent gateway, and respectively perform ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request, to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; further, when the first ticket verification result indicates that the first ticket to be verified is the first access ticket, and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, the security application server can notify the intelligent gateway to forward the resource access request to the business server when obtaining the resource access request sent by the business client intercepted by the access proxy. Specifically, when verifying the second type of access ticket, the relevant information for generating the second type of access ticket can be compared with the above-mentioned device auxiliary information. When the comparison result indicates inconsistency, the security application server can effectively discover the tampering behavior of the attacker against the second type of access ticket, thereby disabling the access permission of the access object and interrupting the connection between the access proxy and the intelligent gateway, and further interrupting this access. As can be seen, by issuing the first access ticket and the second access ticket, the security application server can effectively discover the tampering behavior of the attacker against the ticket and the illegal access behavior against the business data resources. When discovering this tampering behavior, it can timely take security defense measures to interrupt the access session, thereby ensuring the security and reliability of the access object when accessing the business data resources.
[0181] Further, please refer to Figure 10 , Figure 10 which is a sequence diagram of a data resource access method provided by an embodiment of the present application. As Figure 10 shown, this method can be jointly executed by a user terminal running a security management client, an intelligent gateway associated with the security application client, a security application server corresponding to the security application client, and a business server corresponding to a business application. The user terminal can be any one of the user terminal clusters as described above Figure 1 , for example, user terminal 100a. The security application server can be the server 101 as described above Figure 1 . The intelligent gateway can be the intelligent gateway 102 as described above Figure 1 . In addition, the business server can be any one of the business server clusters as described above Figure 1 , for example, business server 103a. This method can at least include the following steps S401 - step S414
[0182] Step S401, the security application client sends a ticket acquisition request for business data resources to the security application server
[0183] Among them, the specific implementation manner of step S401 can refer to the description of step S301 in the corresponding embodiment above Figure 7 , and will not be elaborated here
[0184] Step S402, the security application server receives the ticket acquisition request for business data resources sent by the security application client. When obtaining the device application data information of the terminal device where the security application client is located based on the ticket acquisition request, the security application server generates a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and uses the first access ticket and the second access ticket as resource access tickets
[0185] Step S403, the security application server sends the resource access tickets to the security application client
[0186] Step S404, the security application client receives the resource access tickets returned by the security application server, performs ticket identification on the first access ticket and the second access ticket carried in the resource access tickets, and obtains a ticket identification result
[0187] Step S405, when the ticket identification result indicates that the first access ticket is a first - type access ticket, the security application client sends the first - type access ticket to the access proxy through the first data transmission channel
[0188] Step S406, when the bill recognition result indicates that the second access bill is a second type of access bill, the security application client obtains device auxiliary information associated with the terminal device;
[0189] Step S407, the security application client sends the second type of access bill and the device auxiliary information through the second data transmission channel;
[0190] Step S408, the access proxy obtains the first type of access bill and the second type of access bill, takes the first type of access bill as the first bill to be recognized and the second type of access bill as the second bill to be recognized, and generates a bill verification request based on the first bill to be recognized, the second bill to be recognized and the device auxiliary information;
[0191] Step S409, the access proxy sends the bill verification request to the intelligent gateway;
[0192] Step S410, the intelligent gateway sends the bill verification request to the security application server;
[0193] Among them, for the specific implementation manners of steps S402 - S410, reference can be made to the descriptions of steps S302 - S304 in the corresponding embodiments above, and details will not be elaborated here. Figure 7 For the descriptions of steps S302 - S304 in the corresponding embodiments above, and details will not be elaborated here.
[0194] Step S411, the security application server receives the bill verification request, respectively performs bill verification on the first bill to be verified and the second bill to be verified carried in the bill verification request, and obtains a first bill verification result associated with the first bill to be verified and a second bill verification result associated with the second bill to be verified;
[0195] Step S412, when the first bill verification result indicates that the first bill to be verified is a first type of access bill and the second bill verification result indicates that the second bill to be verified is a second type of access bill, the security application server notifies the intelligent gateway that when obtaining a resource access request sent by the service client intercepted by the access proxy, forward the resource access request to the service server;
[0196] Step S413, the access proxy sends the resource access request to the intelligent gateway;
[0197] Step S414, the intelligent gateway sends the resource access request to the service server.
[0198] Among them, for the specific implementation manners of steps S411 - S414, reference can be made to the descriptions of steps S101 to S103 in the corresponding embodiments above, and details will not be elaborated here. Figure 3 For the descriptions of steps S101 to S103 in the corresponding embodiments above, and details will not be elaborated here.
[0199] It can be seen that in the embodiments of the present application, the security application server can receive a ticket acquisition request for business data resources sent by the security application client. When obtaining the device application data information of the terminal device where the security application client is located based on the ticket acquisition request, the security application server can generate a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and can return the first access ticket and the second access ticket to the security application client as resource access tickets. Furthermore, when the security application client recognizes that the resource access ticket includes a first type of access ticket and a second type of access ticket, the security application client can send the first type of access ticket to the access proxy in the security application client through the first data transmission channel, and send the device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through the second data transmission channel; wherein, the security application server simultaneously issues the first type of access ticket and the second type of access ticket, and transmits the second type of access ticket through the second data transmission channel with a lower security transmission level. Since the security transmission level of the first data transmission channel here is higher than that of the second data transmission channel, this means that when an attacker intends to tamper with the access ticket, the attacker will be misled into thinking that the second type of access ticket is the first type of access ticket issued by the server, inducing the attacker to tamper with the second type of access ticket, so that during the subsequent verification process of the second type of access ticket, the tampering behavior of the attacker can be effectively judged. Further, the security application server can receive a ticket verification request sent by the access proxy through the intelligent gateway, and respectively perform ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; further, when the first ticket verification result indicates that the first ticket to be verified is the first access ticket, and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, the security application server can notify the intelligent gateway to forward the resource access request to the business server when obtaining the resource access request sent by the business client intercepted by the access proxy. Specifically, when verifying the second type of access ticket, the relevant information for generating the second type of access ticket can be compared with the above-mentioned device auxiliary information. When the comparison result indicates inconsistency, the security application server can effectively discover the tampering behavior of the attacker against the second type of access ticket, thereby disabling the access permission of the access object and interrupting the connection between the access proxy and the intelligent gateway, and then interrupting this access. It can be seen that by issuing the first access ticket and the second access ticket, the security application server can effectively discover the tampering behavior of the attacker against the ticket and the illegal access behavior against the business data resources. When discovering the tampering behavior, the security application server can timely take security defense measures to interrupt the access session, thereby ensuring the security and reliability of the access object when accessing the business data resources.
[0200] Please refer to Figure 11 , Figure 11 which is a schematic structural diagram of a data resource access device provided by an embodiment of the present application. As Figure 11 shown, the data resource access device 1 may be a computer program (including program code) running on a computer device. For example, the data resource access device 1 is an application software, and the computer device may be a user terminal. The device may be used to execute corresponding steps in the data resource access method provided by an embodiment of the present application. As Figure 11 shown, the data resource access device 1 may include: a ticket generation module 11, a ticket verification module 12, and a result notification module 13;
[0201] The ticket generation module 11 is configured to receive a ticket acquisition request for business data resources sent by a secure application client. When obtaining device application data information of the terminal device where the secure application client is located based on the ticket acquisition request, generate a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and return the first access ticket and the second access ticket to the secure application client as resource access tickets, so that when the secure application client identifies that the resource access tickets include a first type of access ticket and a second type of access ticket, send the first type of access ticket to an access proxy in the secure application client through a first data transmission channel, and send device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through a second data transmission channel; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel;
[0202] The ticket verification module 12 is configured to receive a ticket verification request sent by the access proxy through an intelligent gateway, and respectively perform ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; the intelligent gateway is deployed between a business client in the terminal device and a business server storing business data resources;
[0203] The result notification module 13 is configured to, when the first ticket verification result indicates that the first ticket to be verified is the first access ticket and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, notify the intelligent gateway to forward a resource access request sent by the business client intercepted by the access proxy to the business server when the intelligent gateway obtains the resource access request; the resource access request is used to instruct the business server to authorize the business client to access the business data resources.
[0204] Among them, for the specific implementation manners of the ticket generation module 11, the ticket verification module 12, and the result notification module 13, reference may be made to the above Figure 3The descriptions of steps S101 - S103 in the corresponding embodiments will not be elaborated here.
[0205] Among them, the bill acquisition request is generated by the security application client based on the device application data information and the access verification data information of the access object; the access verification data information is determined by the security application client when it intercepts the resource access request for business data resources sent by the access object through the service client by the access proxy, and verifies the access data information carried in the resource access request and the information verification is successful; the device application data information is obtained by the security application client from the service client when it obtains the access verification data information;
[0206] The bill generation module 11 includes: an access policy acquisition unit 111, an influencing factor determination unit 112, an access bill generation unit 113, and an access bill return unit 114;
[0207] The access policy acquisition unit 111 is configured to receive the bill acquisition request for business data resources sent by the security application client, and acquire the business access policy configured for the access object in the business access database based on the bill acquisition request;
[0208] The influencing factor determination unit 112 is configured to obtain the device application data information of the terminal device from the bill acquisition request, and determine the bill generation influencing factors associated with the access object based on the business access policy and the device application data information;
[0209] The access bill generation unit 113 is configured to generate a first access bill and a second access bill based on the bill generation influencing factors, the device application data information, and the access verification data information;
[0210] The access bill return unit 114 is configured to return the first access bill and the second access bill to the security application client as resource access bills.
[0211] Among them, for the specific implementation manners of the access policy acquisition unit 111, the influencing factor determination unit 112, the access bill generation unit 113, and the access bill return unit 114, reference can be made to the descriptions of steps S101 - S103 in the above Figure 4 The descriptions of the corresponding embodiments will not be elaborated here.
[0212] Among them, the access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes the resource characteristic information used to characterize the service data resource; the factors affecting ticket generation include the resource sensitivity of the service data resource; the resource sensitivity is determined based on the configured resource sensitivity of the matched resource configuration characteristic information when the resource characteristic information matches the resource configuration characteristic information in the service access policy;
[0213] The access ticket generation unit 113 includes: a first authentication subunit 1131, a sensitivity detection subunit 1132, a second authentication subunit 1133, and a first ticket generation subunit 1134;
[0214] The first authentication subunit 1131 is configured to obtain the object information, device information, and client information in the access verification data information from the ticket acquisition request, and perform a first identity authentication on the access object based on the object information, device information, and client information to obtain a first identity authentication result;
[0215] The sensitivity detection subunit 1132 is configured to perform a sensitivity detection on the resource sensitivity in the factors affecting ticket generation based on the resource sensitivity threshold indicated by the service access policy when the first identity authentication result indicates that the access object has access rights;
[0216] The second authentication subunit 1133 is configured to send authentication indication information for performing a second identity authentication on the service object to the security application client when it is detected that the resource sensitivity in the factors affecting ticket generation reaches the resource sensitivity threshold;
[0217] The first ticket generation subunit 1134 is configured to receive the secondary access data information sent by the service client through the security application client, and when it is determined that the secondary access data information is consistent with the access verification data information, generate a first access ticket based on the first ticket generation policy indicated by the service access policy and the device application data information, and generate a second access ticket based on the second ticket generation policy indicated by the service access policy and the device application data information.
[0218] Among them, for the specific implementation manners of the first authentication subunit 1131, the sensitivity detection subunit 1132, the second authentication subunit 1133, and the first ticket generation subunit 1134, reference can be made to the description of step S101 in the corresponding embodiment above, and details will not be elaborated here. Figure 4 The description corresponding to the embodiment will not be repeated here.
[0219] Among them, the access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes the permission characteristic information used to characterize the access permission of the access object; the factors affecting ticket generation include the permission level of the access permission; the permission level is determined based on the configured permission level of the matched permission configuration characteristic information when the permission characteristic information matches the permission configuration characteristic information in the service access policy;
[0220] The access ticket generation unit 113 includes: a third authentication subunit 1135, a level detection subunit 1136, and a second ticket generation subunit 1137;
[0221] The third authentication subunit 1135 is configured to obtain the object information, device information, and client information in the access verification data information from the ticket acquisition request, and perform first identity authentication on the access object based on the object information, device information, and client information to obtain a first identity authentication result;
[0222] The level detection subunit 1136 is configured to perform level detection on the permission level in the factors affecting ticket generation based on the permission level threshold indicated by the service access policy when the first identity authentication result indicates that the access object has access permission;
[0223] The second ticket generation subunit 1137 is configured to generate a first access ticket based on the third ticket generation policy and the device application data information indicated by the service access policy, and generate a second access ticket based on the fourth ticket generation policy and the device application data information indicated by the service access policy when it is detected that the permission level in the factors affecting ticket generation reaches the permission level threshold.
[0224] Among them, for the specific implementation manners of the third authentication subunit 1135, the level detection subunit 1136, and the second ticket generation subunit 1137, reference can be made to the description of step S101 in the corresponding embodiment above, and details will not be elaborated here. Figure 4 The description of the corresponding embodiment of step S101 will not be repeated here.
[0225] Among them, the access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes the access behavior information used to characterize the access behavior of the access object; the factors affecting ticket generation include the behavior deviation degree between the access behavior information and the normal access behavior baseline; the normal access behavior baseline is formed by the security application server collecting and recording the historical access behavior information of the access object; the behavior deviation degree is determined by comparing the access behavior information with the normal access behavior baseline;
[0226] The access ticket generation unit 113 includes: a fourth authentication subunit 1138, a first comparison subunit 1139, a fifth authentication subunit 1140, and a third ticket generation subunit 1141;
[0227] The fourth authentication subunit 1138 is configured to obtain object information, device information, and client information in the access verification data information from a ticket acquisition request, and perform first identity authentication on the access object based on the object information, device information, and client information to obtain a first identity authentication result;
[0228] The first comparison subunit 1139 is configured to, when the first identity authentication result indicates that the access object has access rights, compare the behavior deviation degree in the ticket generation influencing factors with the behavior deviation degree threshold indicated by the service access policy to obtain a first comparison result;
[0229] The fifth authentication subunit 1140 is configured to, when the first comparison result indicates that the behavior deviation degree in the ticket generation influencing factors reaches the behavior deviation degree threshold, send authentication indication information for performing second identity authentication on the service object to the security application client;
[0230] The third ticket generation subunit 1141 is configured to receive secondary access data information sent by the service client through the security application client, and when it is determined that the secondary access data information is consistent with the access verification data information, generate a first access ticket based on the fifth ticket generation policy and the device application data information indicated by the service access policy, and generate a second access ticket based on the sixth ticket generation policy and the device application data information indicated by the service access policy.
[0231] Among them, for the specific implementation manners of the fourth authentication subunit 1138, the first comparison subunit 1139, the fifth authentication subunit 1140, and the third ticket generation subunit 1141, reference can be made to the description of step S101 in the corresponding embodiments above, and details will not be elaborated here. Figure 4 The description of step S101 in the corresponding embodiments above, and details will not be elaborated here.
[0232] Among them, the access verification data information includes object information of the access object, device information of the terminal device, and client information of the service client; the device application data information includes environment state information for characterizing the environment state of the terminal device; the ticket generation influencing factors include environment state information;
[0233] The access ticket generation unit 113 includes: a sixth authentication subunit 1142, a second comparison subunit 1143, a seventh authentication subunit 1144, and a fourth ticket generation subunit 1145;
[0234] The sixth authentication subunit 1142 is configured to obtain object information, device information, and client information in the access verification data information from the ticket acquisition request, perform first identity authentication on the access object based on the object information, device information, and client information, and obtain a first identity authentication result;
[0235] The second comparison subunit 1143 is configured to, when the first identity authentication result indicates that the access object has access permission, compare the environmental status information in the ticket generation influencing factors with the environmental status threshold indicated by the service access policy to obtain a second comparison result;
[0236] The seventh authentication subunit 1144 is configured to, when the second comparison result indicates that the environmental status information in the ticket generation influencing factors reaches the environmental status threshold, send authentication indication information for performing second identity authentication on the service object to the secure application client;
[0237] The fourth ticket generation subunit 1145 is configured to receive the secondary access data information sent by the service client through the secure application client, and when it is determined that the secondary access data information is consistent with the access verification data information, generate a first access ticket based on the seventh ticket generation policy and the device application data information indicated by the service access policy, and generate a second access ticket based on the eighth ticket generation policy and the device application data information indicated by the service access policy.
[0238] Among them, for the specific implementation manners of the sixth authentication subunit 1142, the second comparison subunit 1143, the seventh authentication subunit 1144, and the fourth ticket generation subunit 1145, reference may be made to the description of step S101 in the corresponding embodiment above, and details will not be elaborated here. Figure 4 For the description of step S101 in the corresponding embodiment above, details will not be elaborated here.
[0239] Among them, the first ticket generation subunit 1134 is further specifically configured to use the device application data information as a first basic data field, perform a first marking operation on the first basic data field to obtain a first marked field, generate a first type of access ticket based on the first ticket generation policy indicated by the service access policy, and use the first type of access ticket as the first access ticket;
[0240] The first ticket generation subunit 1134 is further specifically configured to use the device application data information as a second basic data field, perform a second marking operation on the second basic data field to obtain a second marked field, generate a second type of access ticket based on the second ticket generation policy indicated by the service access policy, and use the second type of access ticket as the second access ticket.
[0241] Optionally, the apparatus 1 further includes: a ticket identification module 14 and a ticket to be verified acquisition module 15;
[0242] The bill recognition module 14 is used to receive the bill verification request sent by the access agent through the intelligent gateway, perform bill recognition on the first bill to be recognized and the second bill to be recognized carried in the bill verification request, and obtain a bill recognition result;
[0243] The to-be-verified ticket acquisition module 15 is used to use the first to-be-verified ticket as the first to-be-verified ticket and the second to-be-verified ticket as the second to-be-verified ticket when the ticket recognition result indicates that the first to-be-verified ticket is a first-type access ticket and the second to-be-verified ticket is a second-type access ticket.
[0244] The specific implementation of the bill recognition module 14 and the to-be-verified bill acquisition module 15 can be found in the above Figure 4 The description of step S102 in the corresponding embodiment will not be repeated here.
[0245] The ticket identification module 14 includes: a ticket acquisition unit 141 for identification, a first ticket identification unit 142, a first type of access ticket determination unit 143, a second ticket identification unit 144 and a second type of access ticket determination unit 145;
[0246] A to-be-identified bill acquisition unit 141 is used to acquire a first to-be-identified bill and a second to-be-identified bill from a bill verification request;
[0247] The first bill identification unit 142 is used to perform a first bill identification operation on the first bill to be identified based on a bill identification strategy to obtain a first bill identification result; the bill identification strategy is jointly determined by the security application client and the security application server;
[0248] A first type access ticket determining unit 143 is configured to determine that the first ticket to be identified is a first type access ticket if the first ticket identification result indicates that a first tag field is identified in the first ticket to be identified; the first tag field is obtained by performing a first tag operation on the first basic data field; the first basic data field is device application data information;
[0249] A second bill recognition unit 144, configured to perform a second bill recognition operation on the second bill to be recognized based on the bill recognition strategy to obtain a second bill recognition result;
[0250] The second type access ticket determination unit 145 is used to determine that the second identified ticket is a second type access ticket if the second ticket identification result indicates that a second tag field is identified in the second ticket to be identified; the second tag field is obtained by performing a second tag operation on the second basic data field; the second basic data field is device application data information.
[0251] Among them, for the specific implementation manners of the to-be-recognized bill acquisition unit 141, the first bill recognition unit 142, the first type of access bill determination unit 143, the second bill recognition unit 144, and the second type of access bill determination unit 145, reference may be made to the description of step S102 in the corresponding embodiment above, and details will not be elaborated herein. Figure 4 The description of step S102 in the corresponding embodiment will not be repeated here.
[0252] The bill verification module 12 includes: a first parsing unit 121, a first verification unit 122, a second parsing unit 123, and a second verification unit 124;
[0253] The first parsing unit 121 is configured to perform a first information parsing operation on a first bill to be verified to obtain first configuration verification information associated with the first type of access bill;
[0254] The first verification unit 122 is configured to perform bill verification on the first bill to be verified based on the first configuration verification information to obtain a first bill verification result;
[0255] The second parsing unit 123 is configured to perform a second information parsing operation on a second bill to be verified to obtain second configuration verification information associated with the second type of access bill;
[0256] The second verification unit 124 is configured to perform bill verification on the second bill to be verified based on the second configuration verification information and device auxiliary information to obtain a second bill verification result; the device auxiliary information is obtained by the security application client.
[0257] Among them, for the specific implementation manners of the first parsing unit 121, the first verification unit 122, the second parsing unit 123, and the second verification unit 124, reference may be made to the description of step S102 in the corresponding embodiment above, and details will not be elaborated herein. Figure 4 The description of step S102 in the corresponding embodiment will not be repeated here.
[0258] Optionally, the bill verification module 12 further includes: a first access bill determination unit 125 and a second access bill determination unit 126;
[0259] The first access bill determination unit 125 is configured to determine the first bill to be verified as the first access bill when the first bill verification result indicates that the first configuration verification information passes the verification;
[0260] The second access bill determination unit 126 is configured to determine the second bill to be verified as the second access bill when the second bill verification result indicates that the second configuration verification information passes the verification and the second configuration verification information is consistent with the device auxiliary information.
[0261] Among them, for the specific implementation manners of the first access bill determination unit 125 and the second access bill determination unit 126, reference may be made to the description of step S102 in the corresponding embodiment above,Figure 4 The description of step S102 in the corresponding embodiment will not be elaborated here.
[0262] Please refer to Figure 12 , Figure 12 FIG. is a schematic structural diagram of another data resource access device provided by an embodiment of the present application. As Figure 12 shown, the data resource access device 2 may be a computer program (including program code) running on a computer device. For example, the data resource access device 2 is an application software, and the computer device may be a user terminal. The device may be used to execute corresponding steps in the data resource access method provided by the embodiment of the present application. As Figure 12 shown, the data resource access device 2 may include: a first sending module 21, a ticket identification module 22, a first transmission module 23, and a second transmission module 24;
[0263] The first sending module 21 is configured to send a ticket acquisition request for service data resources to a security application server;
[0264] The ticket identification module 22 is configured to receive a resource access ticket returned by the security application server, perform ticket identification on a first access ticket and a second access ticket carried in the resource access ticket to obtain a ticket identification result; the first access ticket and the second access ticket are generated by the security application server based on device application data information of the terminal device where the security application client is located carried in the ticket acquisition request;
[0265] The first transmission module 23 is configured to, when the ticket identification result indicates that the first access ticket is a first type of access ticket, send the first type of access ticket to an access proxy in the security application client through a first data transmission channel;
[0266] The second transmission module 24 is configured to, when the ticket identification result indicates that the second access ticket is a second type of access ticket, obtain device auxiliary information associated with the terminal device, and send the second type of access ticket and the device auxiliary information to the access proxy through a second data transmission channel, so that when the access proxy obtains the first type of access ticket and the second type of access ticket, the first type of access ticket is used as a first ticket to be identified, and the second type of access ticket is used as a second ticket to be identified, generate a ticket verification request based on the first ticket to be identified, the second ticket to be identified, and the device auxiliary information, and send the ticket verification request to the security application server through an intelligent gateway; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel; the intelligent gateway is deployed between the service client in the terminal device and the service server storing the service data resources.
[0267] Among them, for the specific implementation manners of the first sending module 21, the bill recognition module 22, the first transmission module 23, and the second transmission module 24, reference can be made to the descriptions of steps S301 - S304 in the corresponding embodiments above, which will not be elaborated here. Figure 7 For the descriptions of steps S301 - S304 in the corresponding embodiments above, which will not be elaborated here.
[0268] The bill recognition module 22 includes: a bill receiving unit 221, a first bill recognition unit 222, a first type of access bill determination unit 223, a second bill recognition unit 224, and a second type of access bill determination subunit 225;
[0269] The bill receiving unit 221 is configured to receive the resource access bill returned by the security application server, and obtain a first access bill and a second access bill from the resource access bill;
[0270] The first bill recognition unit 222 is configured to perform a first bill recognition operation on the first access bill based on a bill recognition policy to obtain a first bill recognition result; the bill recognition policy is jointly determined by the security application client and the security application server;
[0271] The first type of access bill determination unit 223 is configured to, if the first bill recognition result indicates that a first marker field is recognized in the first access bill, determine the first access bill as the first type of access bill; the first marker field is obtained by performing a first marking operation on a first basic data field; the first basic data field is device application data information;
[0272] The second bill recognition unit 224 is configured to perform a second bill recognition operation on the second access bill based on a bill recognition policy to obtain a second bill recognition result;
[0273] The second type of access bill determination subunit 225 is configured to, if the second bill recognition result indicates that a second marker field is recognized in the second access bill, determine the second access bill as the second type of access bill; the second marker field is obtained by performing a second marking operation on a second basic data field; the second basic data field is device application data information.
[0274] Among them, for the specific implementation manners of the bill receiving unit 221, the first bill recognition unit 222, the first type of access bill determination unit 223, the second bill recognition unit 224, and the second type of access bill determination subunit 225, reference can be made to the description of step S302 in the corresponding embodiments above, which will not be elaborated here. Figure 7 For the descriptions of step S302 in the corresponding embodiments above, which will not be elaborated here.
[0275] Among them, the number of the second access bills is N, and N is a positive integer;
[0276] The second transmission module 24 includes: a bill storage unit 241, a data transmission unit 242, and an instruction sending unit 243;
[0277] The bill storage unit 241 is configured to store the second type of access bill in the file storage system in the secure application client, and use the second type of access bill as the original stored bill;
[0278] The data transmission unit 242 is configured to obtain device auxiliary information associated with the terminal device, and send the second type of access bill, the device auxiliary information, and the file path of the file storage system to the access proxy through the second data transmission channel, so that when the access proxy obtains the second type of access bill, it stores S second type of access bills as the bills to be selected in the memory; S is a positive integer less than N;
[0279] The instruction sending unit 243 is configured to send a bill verification request generation instruction to the access proxy, so that when the access proxy receives the bill verification request generation instruction, it uses the first type of access bill as the first bill to be identified, and selects one bill from the bills to be selected as the second bill to be identified, generates a bill verification request based on the first bill to be identified, the second bill to be identified, and the device auxiliary information, and sends it to the secure application server through the intelligent gateway.
[0280] Among them, for the specific implementation manners of the bill storage unit 241, the data transmission unit 242, and the instruction sending unit 243, reference can be made to the description of step S304 in the corresponding embodiment above, and details will not be elaborated here. Figure 7 Here, it will not be elaborated any further.
[0281] Among them, after the access proxy selects one bill from the bills to be selected as the second bill to be identified, it performs a decrement process on the bills to be selected. When the bills to be selected are decremented to 0, it reads the original cached bill from the file storage system through the file path of the file storage system, and selects one bill from the original cached bills as the second bill to be identified.
[0282] Further, please refer to Figure 13 , Figure 13 which is a schematic structural diagram of a computer device provided by an embodiment of the present application. As Figure 13 shown, the computer device 1000 can be a user terminal. For example, the user terminal 100a in the corresponding embodiment above, or it can also be a server. For example, the Figure 1 above Figure 1The server 101 in the corresponding embodiment will not be restricted here. For ease of understanding, this application takes a computer device as the user terminal as an example. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. In addition, the computer device 1000 may further include: a user interface 1003, and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, the user interface 1003 may further include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a non-volatile memory, for example, at least one disk memory. The memory 1005 may optionally further be at least one storage device located far from the aforementioned processor 1001. As Figure 13 shown, the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
[0283] Among them, the network interface 1004 in the computer device 1000 may further provide a network communication function, and the optional user interface 1003 may further include a display screen and a keyboard. In Figure 13 the computer device 1000 shown, the network interface 1004 can provide a network communication function; while the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application program stored in the memory 1005 to execute the previous Figure 4 、 Figure 6 and Figure 7 the description of the service data access method in the corresponding embodiment, and can also execute the previous Figure 11 the description of the data resource access device 1 in the corresponding embodiment, and can also execute Figure 12 the description of the data resource access device 2 in the corresponding embodiment, which will not be elaborated here. In addition, the description of the beneficial effects of adopting the same method will not be elaborated either.
[0284] In addition, it should be pointed out here that: the embodiments of this application also provide a computer-readable storage medium, and the computer-readable storage medium stores the computer programs executed by the aforementioned data resource access device 1 or data resource access device 2, and the computer programs include computer instructions. When the processor executes the computer instructions, it can execute the previous Figure 4 、 Figure 6 and Figure 7The description of the business data access method in the corresponding embodiment will therefore not be repeated here. In addition, the description of the beneficial effects of the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, computer instructions may be deployed on a computing device for execution, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network. Multiple computing devices distributed at multiple locations and interconnected by a communication network can constitute a blockchain system.
[0285] In addition, it should be noted that: the embodiment of the present application also provides a computer program product or a computer program, which may include computer instructions, and the computer instructions may be stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, so that the computer device executes the above Figure 4 , Figure 6 as well as Figure 7 The description of the business data access method in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated. For technical details not disclosed in the computer program product or computer program embodiment involved in this application, please refer to the description of the method embodiment of this application.
[0286] For further information, see Figure 14 , Figure 14 1 is a schematic diagram of a data processing system provided in an embodiment of the present application. The data processing system 3 may include a data processing device 1a and a data processing device 2a. The data processing device 1a may be the above-mentioned Figure 11 In the data resource access device 1 in the corresponding embodiment, it can be understood that the data processing device 1a can be integrated in the above Figure 3 The corresponding embodiment is the user terminal 30A, so it will not be described in detail here. The data processing device 2a can be the above Figure 12 In the data resource access device 2 in the corresponding embodiment, it can be understood that the data processing device 2a can be integrated in the above Figure 3 The security application server 30B in the corresponding embodiment will not be described in detail here. In addition, the description of the beneficial effects of the same method will not be described in detail. For technical details not disclosed in the data processing system embodiment involved in this application, please refer to the description of the method embodiment of this application.
[0287] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, some steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.
[0288] The steps in the method embodiments of this application can be adjusted, combined, and deleted according to actual needs.
[0289] The modules in the device embodiments of this application can be combined, divided, and deleted according to actual needs.
[0290] In the embodiments of this application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of the overall module or unit that includes the function of the module or unit.
[0291] Those of ordinary skill in the art can understand that to implement all or part of the processes in the above method embodiments, it can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above method embodiments. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.
[0292] The foregoing disclosure is only the preferred embodiments of this application. Of course, it cannot be used to limit the scope of rights of this application. Therefore, equivalent changes made according to the claims of this application still fall within the scope covered by this application.
Claims
1. A data resource access method, characterized in that, The method is executed by a security application server and includes: Receiving a ticket acquisition request for business data resources sent by a security application client. When obtaining the device application data information of the terminal device where the security application client is located based on the ticket acquisition request, generating a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and returning the first access ticket and the second access ticket as resource access tickets to the security application client, so that when the security application client identifies that the resource access tickets include a first type of access ticket and a second type of access ticket, sending the first type of access ticket to an access proxy in the security application client through a first data transmission channel, and sending device auxiliary information associated with the terminal device and the second type of access ticket to the access proxy through a second data transmission channel; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel; Receiving a ticket verification request sent by the access proxy through an intelligent gateway, and respectively performing ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified; the intelligent gateway is deployed between a business client in the terminal device and a business server storing the business data resources; When the first ticket verification result indicates that the first ticket to be verified is the first access ticket and the second ticket verification result indicates that the second ticket to be verified is the second access ticket, notifying the intelligent gateway to forward the resource access request sent by the business client intercepted by the access proxy to the business server when the intelligent gateway obtains the resource access request; the resource access request is used to instruct the business server to authorize the business client to access the business data resources.
2. The method according to claim 1, wherein The ticket acquisition request is generated by the security application client based on device application data information and access verification data information of an access object; the access verification data information is determined by the security application client when the access proxy intercepts a resource access request for the business data resources sent by the access object through the business client, verifying the access data information carried in the resource access request, and when the information verification is successful; the device application data information is obtained by the security application client from the business client when obtaining the access verification data information; The step of receiving a ticket acquisition request for business data resources sent by a security application client, when obtaining the device application data information of the terminal device where the security application client is located based on the ticket acquisition request, generating a first access ticket and a second access ticket associated with the business data resources based on the device application data information, and returning the first access ticket and the second access ticket as resource access tickets to the security application client, includes: Receive a ticket acquisition request for the service data resource sent by the security application client, and obtain the service access policy configured for the access object in the service access database based on the ticket acquisition request; Obtain the device application data information of the terminal device from the ticket acquisition request, and determine the ticket generation influencing factors associated with the access object based on the service access policy and the device application data information; Generate the first access ticket and the second access ticket based on the ticket generation influencing factors, the device application data information, and the access verification data information; Return the first access ticket and the second access ticket as resource access tickets to the security application client.
3. The method according to claim 2, characterized in that, The access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes resource characteristic information for characterizing the service data resource; the ticket generation influencing factors include the resource sensitivity of the service data resource; the resource sensitivity is determined based on the configured resource sensitivity of the matched resource configuration characteristic information when the resource characteristic information matches the resource configuration characteristic information in the service access policy; The generating the first access ticket and the second access ticket based on the ticket generation influencing factors, the device application data information, and the access verification data information includes: Obtain the object information, the device information, and the client information in the access verification data information from the ticket acquisition request, and perform a first identity authentication on the access object based on the object information, the device information, and the client information to obtain a first identity authentication result; When the first identity authentication result indicates that the access object has access rights, perform a sensitivity detection on the resource sensitivity in the ticket generation influencing factors based on the resource sensitivity threshold indicated by the service access policy; When it is detected that the resource sensitivity in the ticket generation influencing factors reaches the resource sensitivity threshold, send authentication indication information for performing a second identity authentication on the service object to the security application client; Receive the secondary access data information sent by the service client through the security application client, and when it is determined that the secondary access data information is consistent with the access verification data information, generate the first access ticket based on the first ticket generation policy indicated by the service access policy and the device application data information, and generate the second access ticket based on the second ticket generation policy indicated by the service access policy and the device application data information.
4. The method according to claim 2, wherein The access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes permission characteristic information for characterizing the access permission of the access object; The ticket generation influencing factors include the permission level of the access permission; The permission level is determined based on the configured permission level of the matched permission configuration feature information when the permission feature information matches the permission configuration feature information in the service access policy; Generating the first access ticket and the second access ticket based on the ticket generation influencing factors, the device application data information, and the access verification data information includes: Obtaining the object information, device information, and client information in the access verification data information from the ticket acquisition request, and performing first identity authentication on the access object based on the object information, device information, and client information to obtain a first identity authentication result; When the first identity authentication result indicates that the access object has access permission, performing level detection on the permission level in the ticket generation influencing factors based on the permission level threshold indicated by the service access policy; When it is detected that the permission level in the ticket generation influencing factors reaches the permission level threshold, generating the first access ticket based on the third ticket generation policy indicated by the service access policy and the device application data information, and generating the second access ticket based on the fourth ticket generation policy indicated by the service access policy and the device application data information.
5. The method according to claim 2, wherein The access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes access behavior information for characterizing the access behavior of the access object; the ticket generation influencing factors include the behavior deviation degree between the access behavior information and the normal access behavior baseline; The normal access behavior baseline is formed by the security application server collecting and recording the historical access behavior information of the access object; the behavior deviation degree is determined by comparing the access behavior information with the normal access behavior baseline; Generating the first access ticket and the second access ticket based on the ticket generation influencing factors, the device application data information, and the access verification data information includes: Obtaining the object information, device information, and client information in the access verification data information from the ticket acquisition request, and performing first identity authentication on the access object based on the object information, device information, and client information to obtain a first identity authentication result; When the first identity authentication result indicates that the access object has access permission, comparing the behavior deviation degree in the ticket generation influencing factors with the behavior deviation degree threshold indicated by the service access policy to obtain a first comparison result; When the first comparison result indicates that the behavior deviation degree in the ticket generation influencing factors reaches the behavior deviation degree threshold, sending authentication indication information for performing second identity authentication on the service object to the security application client; Receive the secondary access data information sent by the service client through the security application client. When it is determined that the secondary access data information is consistent with the access verification data information, generate the first access ticket based on the fifth ticket generation policy indicated by the service access policy and the device application data information, and generate the second access ticket based on the sixth ticket generation policy indicated by the service access policy and the device application data information.
6. The method according to claim 2, wherein The access verification data information includes the object information of the access object, the device information of the terminal device, and the client information of the service client; the device application data information includes environmental status information for characterizing the environmental status of the terminal device; the ticket generation influencing factors include the environmental status information; Generating the first access ticket and the second access ticket based on the ticket generation influencing factors, the device application data information, and the access verification data information includes: Obtain the object information, the device information, and the client information in the access verification data information from the ticket acquisition request, and perform a first identity authentication on the access object based on the object information, the device information, and the client information to obtain a first identity authentication result; When the first identity authentication result indicates that the access object has access rights, compare the environmental status information in the ticket generation influencing factors with the environmental status threshold indicated by the service access policy to obtain a second comparison result; When the second comparison result indicates that the environmental status information in the ticket generation influencing factors reaches the environmental status threshold, send authentication instruction information for performing a second identity authentication on the service object to the security application client; Receive the secondary access data information sent by the service client through the security application client. When it is determined that the secondary access data information is consistent with the access verification data information, generate the first access ticket based on the seventh ticket generation policy indicated by the service access policy and the device application data information, and generate the second access ticket based on the eighth ticket generation policy indicated by the service access policy and the device application data information.
7. The method according to claim 3, wherein Generating the first access ticket based on the first ticket generation policy indicated by the service access policy and the device application data information, and generating the second access ticket based on the second ticket generation policy indicated by the service access policy and the device application data information includes: Take the device application data information as the first basic data field, perform a first marking operation on the first basic data field to obtain a first marked field, generate the first type of access ticket based on the first ticket generation policy indicated by the service access policy, and use the first type of access ticket as the first access ticket; Using the device application data information as the second basic data field, perform a second marking operation on the second basic data field to obtain a second marked field, generate a second type of access ticket based on the second ticket generation policy indicated by the service access policy, and use the second type of access ticket as the second access ticket.
8. The method according to claim 1, wherein The performing of ticket verification on the first ticket to be verified and the second ticket to be verified carried in the ticket verification request respectively to obtain a first ticket verification result associated with the first ticket to be verified and a second ticket verification result associated with the second ticket to be verified includes: Performing a first information parsing operation on the first ticket to be verified to obtain first configuration verification information associated with the first type of access ticket; Performing ticket verification on the first ticket to be verified based on the first configuration verification information to obtain a first ticket verification result; Performing a second information parsing operation on the second ticket to be verified to obtain second configuration verification information associated with the second type of access ticket; Performing ticket verification on the second ticket to be verified based on the second configuration verification information and the device auxiliary information to obtain a second ticket verification result; the device auxiliary information is obtained by the security application client.
9. The method according to claim 8, wherein The method further includes: When the first ticket verification result indicates that the first configuration verification information passes the verification, determining the first ticket to be verified as the first access ticket; When the second ticket verification result indicates that the second configuration verification information passes the verification and the second configuration verification information is consistent with the device auxiliary information, determining the second ticket to be verified as the second access ticket.
10. A data resource access method, characterized in that, The method is executed by a terminal device running a security application client, and includes: Sending a ticket acquisition request for business data resources to a security application server; Receiving the resource access ticket returned by the security application server, performing ticket identification on the first access ticket and the second access ticket carried in the resource access ticket to obtain a ticket identification result; the first access ticket and the second access ticket are generated by the security application server based on the device application data information of the terminal device where the security application client is located carried in the ticket acquisition request; When the ticket identification result indicates that the first access ticket is the first type of access ticket, sending the first type of access ticket to the access proxy in the security application client through a first data transmission channel; When the bill recognition result indicates that the second access bill is a second - type access bill, obtain device - assisted information associated with the terminal device, and send the second - type access bill and the device - assisted information to the access proxy through a second data transmission channel, so that when the access proxy obtains the first - type access bill and the second - type access bill, the first - type access bill is used as the first bill to be recognized, and the second - type access bill is used as the second bill to be recognized. Generate a bill verification request based on the first bill to be recognized, the second bill to be recognized, and the device - assisted information, and send the bill verification request to the security application server through the intelligent gateway; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel; the intelligent gateway is deployed between the service client in the terminal device and the service server storing the service data resources.
11. A data resource access device, characterized in that, The device runs on the security application server and includes: A bill generation module, configured to receive a bill acquisition request for service data resources sent by a security application client. When obtaining the device application data information of the terminal device where the security application client is located based on the bill acquisition request, generate a first access bill and a second access bill associated with the service data resources based on the device application data information, and return the first access bill and the second access bill as resource access bills to the security application client, so that when the security application client recognizes that the resource access bill includes a first - type access bill and a second - type access bill, the first - type access bill is sent to the access proxy in the security application client through the first data transmission channel, and the device - assisted information associated with the terminal device and the second - type access bill are sent to the access proxy through the second data transmission channel; the security transmission level of the first data transmission channel is higher than that of the second data transmission channel; A bill verification module, configured to receive the bill verification request sent by the access proxy through the intelligent gateway, and respectively perform bill verification on the first bill to be verified and the second bill to be verified carried in the bill verification request, to obtain a first bill verification result associated with the first bill to be verified and a second bill verification result associated with the second bill to be verified; the intelligent gateway is deployed between the service client in the terminal device and the service server storing the service data resources; A result notification module, configured to, when the first bill verification result indicates that the first bill to be verified is the first access bill, and the second bill verification result indicates that the second bill to be verified is the second access bill, notify the intelligent gateway to forward the resource access request sent by the service client intercepted by the access proxy to the service server when the intelligent gateway obtains it; the resource access request is used to instruct the service server to authorize the service client to access the service data resources.
12. A data resource access device, characterized in that, The described device runs on a terminal device with a security application client installed, and includes: A first sending module, configured to send a ticket acquisition request for business data resources to a security application server; A ticket identification module, configured to receive the resource access ticket returned by the security application server, perform ticket identification on the first access ticket and the second access ticket carried in the resource access ticket, and obtain a ticket identification result; the first access ticket and the second access ticket are generated by the security application server based on the device application data information of the terminal device where the security application client is located carried in the ticket acquisition request; A first transmission module, configured to, when the ticket identification result indicates that the first access ticket is a first type of access ticket, send the first type of access ticket to an access proxy in the security application client through a first data transmission channel; A second transmission module, configured to, when the ticket identification result indicates that the second access ticket is a second type of access ticket, obtain device auxiliary information associated with the terminal device, and send the second type of access ticket and the device auxiliary information to the access proxy through a second data transmission channel, so that when the access proxy obtains the first type of access ticket and the second type of access ticket, the first type of access ticket is used as a first ticket to be identified, and the second type of access ticket is used as a second ticket to be identified, generate a ticket verification request based on the first ticket to be identified, the second ticket to be identified, and the device auxiliary information, and send the ticket verification request to the security application server through an intelligent gateway; the intelligent gateway is deployed between a business client in the terminal device and a business server storing the business data resources.
13. A computer device, characterized in that, It includes a memory and a processor; The memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program to enable the computer device to execute the method according to any one of claims 1-10.
14. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, and the computer program is suitable for being loaded and executed by a processor to enable a computer device with the processor to execute the method according to any one of claims 1-10.
15. A computer program product, characterized in that, It includes a computer program / instructions, and when the computer program / instructions are executed by a processor, the method according to any one of claims 1-10 is implemented.