WO2022095730A1 - 业务通信方法、系统、装置及电子设备 - Google Patents

业务通信方法、系统、装置及电子设备 Download PDF

Info

Publication number
WO2022095730A1
WO2022095730A1 PCT/CN2021/125653 CN2021125653W WO2022095730A1 WO 2022095730 A1 WO2022095730 A1 WO 2022095730A1 CN 2021125653 W CN2021125653 W CN 2021125653W WO 2022095730 A1 WO2022095730 A1 WO 2022095730A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
access process
service access
verification processing
information
Prior art date
Application number
PCT/CN2021/125653
Other languages
English (en)
French (fr)
Inventor
吴岳廷
刘跃波
蔡东赟
朱祁林
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to KR1020237008870A priority Critical patent/KR20230048431A/ko
Priority to EP21888427.8A priority patent/EP4181460A4/en
Priority to JP2023515835A priority patent/JP2023541599A/ja
Publication of WO2022095730A1 publication Critical patent/WO2022095730A1/zh
Priority to US17/974,067 priority patent/US20230056432A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

Definitions

  • the present application relates to communication technologies, and in particular, to a business communication method, system, apparatus, electronic device, computer-readable storage medium, and computer program product.
  • an interface call often occurs, for example, a process of a terminal device calls the interface of another process of the terminal device, or a process of the terminal device calls the interface of the process of the server.
  • the purpose of an interface call is to implement business communication, such as sending or requesting specific data.
  • the embodiment of the present application provides a service communication method, including:
  • the communication connection with the service access process for carrying the encrypted service communication is controlled.
  • An embodiment of the present application provides a service communication system, including a service access client, a security client, and a security server; wherein, the service access client runs a service access process;
  • the security client for:
  • the communication connection with the service access process for carrying the encrypted service communication is controlled.
  • An embodiment of the present application provides a service communication device, including:
  • a receiving module configured to receive an authentication request sent by the service access process
  • a verification module configured to perform synchronous verification processing on the service access process, and perform asynchronous verification processing on the service access process
  • a determining module configured to determine the service key information allocated to the service access process according to the synchronous verification processing result of the service access process
  • a sending module configured to send the service key information to the service access process, so as to perform encrypted service communication with the service access process based on the service key information
  • the connection control module is configured to control the communication connection with the service access process for carrying the encrypted service communication according to the asynchronous verification processing result of the service access process.
  • the embodiment of the present application provides an electronic device, including:
  • the processor is configured to implement the service communication method provided by the embodiment of the present application when executing the executable instructions stored in the memory.
  • the embodiments of the present application provide a computer-readable storage medium storing executable instructions for implementing the service communication method provided by the embodiments of the present application when a processor is executed.
  • the embodiments of the present application provide a computer program product, including executable instructions, which implement the service communication method provided by the embodiments of the present application when the executable instructions are executed by a processor.
  • FIG. 1 is a schematic structural diagram of a service communication system provided by an embodiment of the present application.
  • FIG. 2 is a schematic structural diagram of a business communication system combined with a blockchain network provided by an embodiment of the present application;
  • FIG. 3 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • 4A is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • 4B is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • 4C is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • 4D is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • 4E is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of a policy management interface of a security management terminal provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of process information provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a zero-trust gateway interface of a security management terminal provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a configuration interface of a zero-trust gateway provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a service system interface of a security management terminal provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a configuration interface of a business system provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram of a configuration interface of a business system provided by an embodiment of the present application.
  • FIG. 12 is a schematic diagram of a configuration interface of a business system provided by an embodiment of the present application.
  • FIG. 13 is a schematic diagram of a policy management interface of a security management terminal provided by an embodiment of the present application.
  • FIG. 14 is a schematic diagram of a security client interface provided by an embodiment of the present application.
  • 15 is a schematic diagram of a security client interface provided by an embodiment of the present application.
  • 16 is a schematic diagram of a security client interface provided by an embodiment of the present application.
  • 17 is a schematic diagram of an access process provided by an embodiment of the present application.
  • FIG. 18 is a schematic diagram of an access process provided by an embodiment of the present application.
  • FIG. 19 is a schematic diagram of cascaded deployment of security servers provided by an embodiment of the present application.
  • FIG. 20 is a schematic diagram of an asynchronous verification process provided by an embodiment of the present application.
  • first ⁇ second ⁇ third is only used to distinguish similar objects, and does not represent a specific ordering of objects. It is understood that “first ⁇ second ⁇ third” Where permitted, the specific order or sequence may be interchanged to enable the embodiments of the application described herein to be practiced in sequences other than those illustrated or described herein. In the following description, reference to the term “plurality” refers to at least two.
  • Service access process refers to the process as the caller.
  • the embodiment of this application does not limit the type of the service access process.
  • the service access process may be an application process (such as a process of a certain conference application), or It is a process specially used to proxy the business request of the application process.
  • Synchronous verification processing It is necessary to wait for the completion of the synchronous verification processing, that is, when the synchronous verification processing result is obtained, before other steps can be performed.
  • the synchronous verification processing of the service access process and the synchronous verification processing of the application process are involved. For example, the determination as The steps of the service key information allocated by the service access process.
  • Asynchronous verification processing During the asynchronous verification processing, other steps may be performed. In the embodiment of this application, the asynchronous verification processing of the service access process and the synchronous verification processing of the application process are involved. For example, during the asynchronous verification processing of the service access process, the Encrypt business communications.
  • Service key information used for encrypted service communication, the service key information at least includes a key, and may also include information such as a key identifier.
  • Signature information generally refers to information related to digital signature (Digital Signature), for example, it may include the digital signature itself and certificate information.
  • Hash Convert an input of any length into a fixed-length output through a hash algorithm (also called hashing), and the output is the Hash value (also called the Hash result), so that the obtained value can be obtained by Hash value to identify the input.
  • Hash algorithms include message digest (Message-Digest, MD) algorithm and secure hash algorithm (Secure Hash Algorithm, SHA) and so on.
  • Symmetric key means that the party sending the data and the party receiving the data use the same key to perform encryption processing and decryption processing.
  • the embodiment of this application does not limit the generation method of the symmetric key.
  • Advanced Encryption Standard, AES Advanced Encryption Standard
  • Asymmetric key pair including public key and private key, the party sending the data encrypts the data through the public key, and the party receiving the data decrypts the encrypted data through the private key, or it can also use the private key.
  • the key is used to encrypt the data
  • the public key is used to decrypt the encrypted data.
  • Service gateway used to forward the received service request to the corresponding service server, so as to realize the proxy of the service request.
  • the service gateway may be implemented in a software form, or may be implemented in a hardware form.
  • Service server a server for providing service resources.
  • the background server of the conference application is the service server, which is used to provide data support for the networking operation of the conference application.
  • Blockchain The storage structure of encrypted, chained transactions formed by blocks.
  • Blockchain Network A collection of nodes that incorporate new blocks into the blockchain through consensus.
  • Embodiments of the present application provide a service communication method, system, apparatus, electronic device, and computer-readable storage medium, which can improve the security of service communication. Exemplary applications of the electronic device provided by the embodiment of the present application are described below.
  • the electronic device provided by the embodiment of the present application may be implemented as a terminal device or as a server.
  • FIG. 1 is a schematic structural diagram of a service communication system 100 provided by an embodiment of the present application.
  • a terminal device 400 is connected to a server 200 through a network 300, and the network 300 may be a wide area network or a local area network, or a combination of the two.
  • the terminal device 400 runs a service access client.
  • the service communication method provided by the embodiments of the present application may be implemented by the terminal device.
  • the service access client in the terminal device 400 can call the interface of the application process of the application client in the terminal device 400 through the running service access process, that is, the application client will receive the authentication sent by the service access process. rights request.
  • the application client can perform synchronous verification processing and asynchronous verification processing on the service access process, determine the allocated service key information according to the synchronous verification processing result, and perform encryption with the service access process based on the service key information.
  • the application client obtains the asynchronous verification processing result, it can also control the communication connection with the business access process according to the asynchronous verification processing result.
  • the service access process can achieve various service purposes, which are not limited.
  • the service access process may be the application process of the instant messaging application client (hereinafter referred to as client A), and the application process of the file management client (hereinafter referred to as client B) is invoked.
  • client A such as a file link shared in the session interface
  • client B the application process of the file management client
  • client A When a file link in A (such as a file link shared in the session interface) is triggered by the user, the application process of client A will call the interface of the application process of client B to establish encryption with the application process of client B business communication.
  • the application process of client A can send a service request including the file link to the application process of client B, and the application process of client B can query the file link corresponding to the file under management. and send the queried file to the application process of client A for display on the interface of client A.
  • the service communication method provided by the embodiments of the present application may be implemented by the server.
  • the service access client in the terminal device 400 can call the interface of the process running in the server 200 through the running service access process, that is, the server 200 will receive the authentication request sent by the service access process.
  • the server 200 may perform synchronous verification processing and asynchronous verification processing on the service access process to establish encrypted service communication with the service access process.
  • the service access client may be the client of an application
  • the server 200 is the background server of the application
  • the service access client may establish encrypted service communication with the process in the server 200 through the service access process, thereby sending the Processes in server 200 request application data (ie, response data).
  • the service communication method provided by the embodiments of the present application may also be implemented by a terminal device and a server in cooperation.
  • the terminal device 400 runs a security client
  • the server 200 is a security server.
  • the security client receives the authentication request sent by the service access process
  • the security client performs synchronous verification processing on the service access process, and notifies the security server to perform asynchronous verification processing on the service access process, so as to be consistent with the service access process.
  • Establish encrypted business communications may be implemented by a terminal device and a server in cooperation.
  • the terminal device 400 runs a security client
  • the server 200 is a security server.
  • the terminal device 400 or the server 200 may implement the service communication method provided by the embodiments of the present application by running a computer program
  • the computer program may be a native program or software module in an operating system; ) application program (APP, Application), that is, a program that needs to be installed in the operating system to run; it can also be a small program, that is, a program that can be run only after being downloaded into the browser environment; it can also be embedded in any APP An applet in , where the applet component can be run or closed under user control.
  • APP Application
  • the above-mentioned computer programs may be any form of application, module or plug-in.
  • the server 200 may be an independent physical server, or a server cluster or a distributed system composed of multiple physical servers, or may provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, Cloud servers for basic cloud computing services such as network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, where the cloud service can be an asynchronous verification service for the terminal device 400 to call .
  • the terminal device 400 may be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart TV, a smart speaker, a smart watch, etc., but is not limited thereto.
  • the terminal device and the server may be directly or indirectly connected through wired or wireless communication, which is not limited in this embodiment of the present application.
  • FIG. 2 is a schematic structural diagram of a business communication system 110 combined with a blockchain network provided by an embodiment of the present application, including a blockchain network 500 (the blockchain network 500 usually includes a plurality of nodes, here exemplarily The node 510 is shown), the authentication center 600 and the electronic device 700.
  • the electronic device 700 may be a server (such as the server 200 shown in FIG. 1 ) or a terminal device (such as the terminal device 400 shown in FIG. 1 ). According to the actual application scenario Depends.
  • the certification center 600 is used to issue a digital certificate to the electronic device 700 .
  • the electronic device 700 can access the blockchain network 500 to become a client node of the blockchain network 500, and then query the data stored in the blockchain, where the blockchain can be used to store various information in the process of business communication .
  • the electronic device 700 may query the blacklist stored in the blockchain to perform at least one of synchronous verification processing and asynchronous verification processing on the service access process according to the blacklist.
  • FIG. 3 is a schematic structural diagram of a terminal device 400 provided by an embodiment of the present application.
  • the terminal device 400 shown in FIG. The various components in terminal 400 are coupled together by bus system 440 .
  • the bus system 440 is used to implement the connection communication between these components.
  • the bus system 440 also includes a power bus, a control bus, and a status signal bus.
  • the various buses are labeled as bus system 440 in FIG. 3 .
  • the processor 410 may be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where a general-purpose processor may be a microprocessor or any conventional processor or the like.
  • DSP Digital Signal Processor
  • User interface 430 includes one or more output devices 431 that enable presentation of media content, including one or more speakers and/or one or more visual display screens.
  • User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, and other input buttons and controls.
  • Memory 450 may be removable, non-removable, or a combination thereof.
  • Exemplary hardware devices include solid state memory, hard drives, optical drives, and the like.
  • Memory 450 optionally includes one or more storage devices that are physically remote from processor 410 .
  • Memory 450 includes volatile memory or non-volatile memory, and may also include both volatile and non-volatile memory.
  • the non-volatile memory may be a read-only memory (ROM, Read Only Memory), and the volatile memory may be a random access memory (RAM, Random Access Memory).
  • ROM read-only memory
  • RAM random access memory
  • the memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.
  • memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.
  • the operating system 451 includes system programs for processing various basic system services and performing hardware-related tasks, such as framework layer, core library layer, driver layer, etc., for implementing various basic services and processing hardware-based tasks;
  • a presentation module 453 for enabling presentation of information (eg, a user interface for operating peripherals and displaying content and information) via one or more output devices 431 (eg, a display screen, speakers, etc.) associated with the user interface 430 );
  • An input processing module 454 for detecting one or more user inputs or interactions from one of the one or more input devices 432 and translating the detected inputs or interactions.
  • the service communication apparatus provided by the embodiments of the present application may be implemented in software.
  • FIG. 3 shows the service communication apparatus 455 stored in the memory 450, which may be software in the form of programs and plug-ins, including the following Software modules: receiving module 4551, verifying module 4552, determining module 4553, sending module 4554 and connection control module 4555, these modules are logical, so any combination or further division can be carried out according to the realized functions. The function of each module will be explained below.
  • FIG. 4A is a schematic flowchart of a service communication method provided by an embodiment of the present application, which will be described in conjunction with the steps shown in FIG. 4A .
  • step 101 an authentication request sent by a service access process is received.
  • the electronic device receives the authentication request sent by the service access process.
  • an authentication interface (such as a specific port) can be pre-agreed in the electronic device.
  • the authentication request When requesting an interface call, the call request is used as an authentication request.
  • the service access process may be an application process of an application client, or a process used to proxy the application client, which will be described later. It should be noted that the embodiment of the present application does not limit the type of the service, for example, it may be an instant messaging service or a video service.
  • step 102 synchronous verification processing is performed on the service access process, and asynchronous verification processing is performed on the service access process.
  • synchronous verification processing and asynchronous verification processing are performed to verify its legitimacy.
  • the embodiments of the present application do not limit the execution order of the synchronous verification processing and the asynchronous verification processing, for example, they may be executed simultaneously, or, for example, the asynchronous verification processing may be executed when the result of the synchronous verification processing is that the verification is successful.
  • the embodiments of the present application also do not limit the processing methods of the synchronous verification processing and the asynchronous verification processing.
  • the verification objects of the synchronous verification processing and the asynchronous verification processing may be the same. The difference is that the synchronous validation process is performed only once, while the asynchronous validation process is performed periodically multiple times.
  • step 103 the service key information allocated to the service access process is determined according to the synchronous verification processing result of the service access process.
  • whether to determine the service key information allocated to the service access process can be determined according to the synchronous verification processing result of the service access process.
  • the service key information includes at least a key, and may also include a key identifier and the like.
  • the service key information may be pre-allocated for the service access process, or may be allocated in real time, which is not limited.
  • the electronic device can also periodically update the service key information allocated to the service access process, and perform invalidation processing (also called invalidation processing) on the service key information before the update. ) to trigger the service access process to resend the authentication request, so as to obtain the updated service key information.
  • invalidation processing also called invalidation processing
  • the electronic device may pre-agreed multiple authentication request addresses, so that the service access process sends the authentication request according to the authentication request addresses.
  • the electronic device determines the service key information allocated for the service access process, it can implement various allocation schemes according to the two factors of the service access process itself and the authentication request address.
  • the first allocation scheme is to allocate different service key information for authentication request addresses sent by different service access processes, and allocate different service key information for different authentication request addresses sent by the same service access process. key information.
  • the security of this distribution scheme is higher, and the quantity of distributed service key information is also larger, and the electronic device needs to consume more storage resources to store the distributed service key information.
  • the second allocation scheme is that different service key information is allocated to the authentication request addresses sent by different service access processes, and the same service key information is allocated to different authentication request addresses sent by the same service access process, that is, only Differentiate the service access process. Compared with the first allocation scheme, the second allocation scheme requires less storage resources.
  • the third allocation scheme is to allocate uniform service key information without distinguishing the service access process and the authentication request address. This scheme requires the least amount of storage resources.
  • any one of the above three allocation schemes can be selected.
  • an enterprise that has the highest security requirements can choose the first allocation scheme above.
  • the flexibility of distributing service key information is improved.
  • the above-mentioned determination of the service key information allocated to the service access process according to the synchronous verification processing result of the service access process can be implemented in this way: when the synchronous verification processing of the service access process is performed When the result is that the verification is successful, the service key information allocated to the service access process is determined.
  • the synchronous verification processing result of the service access process is that the verification is successful
  • the service key information allocated to the service access process is determined; when the synchronous verification processing result of the service access process is verification failure, it is proved that the service access process If the incoming process is illegal, the service key information is refused to be allocated to the service access process, and the communication connection with the service access process can also be disconnected. That is, the synchronous verification processing of the service access process can be regarded as a preliminary verification of whether the service access process is legal in essence.
  • an error message may be sent to the service access process to notify the service access process to resend the authentication request, or to communicate with the service access process Disconnect communication.
  • the asynchronous verification processing of the service access process is being executed when the synchronous verification processing result of the service access process is obtained as verification failure, the asynchronous verification processing of the service access process can be interrupted to save computing resources.
  • step 104 the service key information is sent to the service access process, so as to perform encrypted service communication with the service access process based on the service key information.
  • the electronic device sends the service key information allocated to the service access process to the service access process, so that encrypted service communication with the service access process can be performed based on the service key information.
  • the service key information includes a symmetric key
  • the service access process can encrypt the data according to the symmetric key, and send the encrypted data to the electronic device, so that the electronic device can receive the data according to the symmetric key.
  • the encrypted data is decrypted; similarly, the electronic device can encrypt the data according to the symmetric key, and send the encrypted data to the service access process, so that the service access process can encrypt the encrypted data according to the symmetric key.
  • the resulting data is decrypted.
  • step 105 according to the asynchronous verification processing result of the service access process, the communication connection with the service access process for carrying encrypted service communication is controlled.
  • the communication connection with the service access process for carrying encrypted service communication is controlled according to the asynchronous verification processing result.
  • the embodiment of the present application does not limit the type of the communication connection, for example, it may be a socket (Socket) connection.
  • the above-mentioned communication connection for carrying encrypted service communication between the control and the service access process according to the asynchronous verification processing result of the service access process can be implemented in this way: when the service access process is When the asynchronous verification processing result of the process is that the verification is successful, the communication connection with the service access process for carrying the encrypted service communication is maintained; when the asynchronous verification processing result of the service access process is the verification failure, the connection with the service is disconnected.
  • the asynchronous verification processing of the service access process can be regarded as a re-verification of whether the service access process is legal in essence.
  • the embodiment of the present application can effectively verify the legitimacy of the service access process by combining synchronous verification processing and asynchronous verification processing; at the same time, encryption is performed through the service key information issued by the electronic device
  • Business communication can reduce the probability of business key information being stolen and used by malicious processes, and improve the security of business communication.
  • FIG. 4B is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • Step 102 shown in FIG. 4A can be implemented through steps 201 to 204 , which will be described in conjunction with each step.
  • step 201 the matching result between the process path of the service access process and the set security directory is taken as the first verification processing result.
  • the synchronous verification processing of the service access process may include the verification processing of the process path and the verification processing of the signature information.
  • the security directory can be preset according to the actual application scenario, and the process path of the service access process is matched with the security directory, and the obtained matching result is used as the first verification processing result.
  • the process path of the service access process when the process path of the service access process is located in the security directory, it is determined that the matching result between the process path and the security directory is successful, that is, the first verification processing result is the verification success; when the process path of the service access process is not When located in the security directory, it is proved that the service access process is illegal, and the matching result between the process path and the security directory is determined to be failure, that is, the result of the first verification processing is verification failure.
  • step 202 verification processing is performed on the signature information of the service access process to obtain a second verification processing result.
  • the signature information generally refers to the information related to the digital signature of the service access process, and the specific content of the signature information that needs to be verified can be determined according to the security requirements in the actual application scenario. After performing verification processing on the signature information of the service access process, a second verification processing result is obtained.
  • the above-mentioned verification processing on the signature information of the service access process can be implemented in this way, and a second verification processing result is obtained: according to whether the signature information includes the result of the digital signature, the validity verification of the digital signature At least one of the processing result, the matching result between the signer of the digital signature and the blacklist of the signing parties, and the matching result between the certificate information in the signature information and the certificate information blacklist, determines the second verification processing result.
  • the embodiment of the present application provides four influencing factors for the verification processing of the signature information of the service access process, which will be described separately below.
  • the signature information includes the result of the digital signature. For example, when the signature information includes a digital signature, the result of the second verification processing is determined to be a successful verification; when the signature information does not include a digital signature, the result of the second verification processing is determined to be a verification failure.
  • the validity verification processing result obtained by performing the validity verification processing on the digital signature in the signature information may be directly used as the second verification processing result, and the manner of the validity verification processing will be described later.
  • the matching result between the signer of the digital signature in the signature information and the blacklist of the signer includes multiple malicious signers.
  • the second verification processing result is determined Indicates that the verification fails; when the signer of the digital signature of the service access process is different from all malicious signers in the signer blacklist, that is, when the matching fails, the second verification processing result is determined to be a successful verification.
  • the certificate refers to the digital certificate (Digital Certificate).
  • the certificate information blacklist includes multiple malicious certificate information.
  • the certificate information of the service access process is the same as any malicious certificate information in the certificate information blacklist, that is, when the matching is successful, it is determined that the second verification processing result is verification failure ;
  • the certificate information of the service access process is different from all malicious certificate information in the certificate information blacklist, that is, when the matching fails, it is determined that the result of the second verification processing is that the verification is successful.
  • the certificate information may be certificate chain (Certificate Chain) information, for example, including root certificate information, intermediate certificate information, and signature certificate information, and the format of the certificate information is determined according to the actual certificate issuance situation of the service access process.
  • the verification strength of the above-mentioned influencing factors from 1) to 4) increases, and the verification duration also increases.
  • the security requirements and efficiency requirements in practical application scenarios can be integrated, and at least one of the above-mentioned influencing factors can be selected for verification processing.
  • the signature information includes a digital signature
  • the validity verification processing result of the digital signature is that the verification is successful
  • it is determined that the second verification processing result is The verification is successful; when the signature information does not include a digital signature, or the result of the verification processing on the validity of the digital signature is a verification failure, the second verification processing result is determined to be a verification failure.
  • the flexibility of verification processing for the signature information of the service access process is improved.
  • the method further includes: determining a digital signature in the signature information and a decryption key corresponding to the digital signature; decrypting the digital signature according to the decryption key to obtain the first hash of the process file of the service access process. Hash the process file of the service access process to obtain the second hash result; use the matching result between the first hash result and the second hash result as the result of the validity verification of the digital signature .
  • the digital signature may be obtained by hashing the process file of the service access process, and then encrypting the obtained first hash result, wherein the process file may refer to the portable and executable (Portable and executable) of the service access process. Executable, PE) file. Therefore, when validating the digital signature, the digital signature in the signature information and the decryption key corresponding to the digital signature can be determined first, wherein the decryption key can be obtained by parsing the certificate information of the service access process , as parsed from the signed certificate.
  • the process file may refer to the portable and executable (Portable and executable) of the service access process. Executable, PE) file. Therefore, when validating the digital signature, the digital signature in the signature information and the decryption key corresponding to the digital signature can be determined first, wherein the decryption key can be obtained by parsing the certificate information of the service access process , as parsed from the signed certificate.
  • the digital signature is decrypted according to the decryption key to obtain the first hash result.
  • the process file of the service access process is hashed to obtain the second hash result.
  • the algorithm used for hashing It can also be obtained from the certificate information. In this way, it can be ensured that the algorithm used for calculating the first hash result is consistent with the algorithm used for calculating the second hash result.
  • the matching result between the first hash result and the second hash result is used as the validity verification processing result. For example, when the first hash result is the same as the second hash result, that is, the match is successful, it is determined that the result is valid.
  • the result of the validity verification processing is that the verification is successful; when the first hash result is different from the second hash result, it is proved that the process file has been tampered with, and the result of the validity verification processing is determined to be a verification failure.
  • the above method is only an example of the validity verification process, and does not constitute a limitation on the validity verification process.
  • the validity can also be achieved by calling a specific application programming interface (Application Programming Interface, API), such as WinVerifyTrust Validation processing.
  • API Application Programming Interface
  • step 203 the synchronous verification processing result of the service access process is determined according to the first verification processing result and the second verification processing result.
  • the synchronous verification processing result of the service access process is determined to be verified successfully; when any of the first verification processing result and the second verification processing result is One is that when the verification fails, it is determined that the result of the synchronous verification processing on the service access process is verification failure.
  • the synchronization verification processing of the service access process is performed in combination with the two aspects of the process path and the signature information, which can effectively improve the accuracy of the obtained synchronization verification processing result.
  • step 204 the process information of the service access process is periodically matched with the process information blacklist, and the obtained matching result is used as the asynchronous verification processing result of the service access process.
  • the process information may include at least one of the MD5 value of the process file, the Hash value of the process file, the process path, and certificate information, which may be set according to actual application scenarios.
  • the process information blacklist includes process information of multiple malicious processes, and the process information blacklist can be continuously updated over time, similar to a virus database. In the process of asynchronously verifying the service access process, the process information of the service access process can be periodically matched with the process information blacklist (for example, the current latest process information blacklist).
  • the process information is the same as any process information in the process information blacklist, that is, when the match is successful, it is determined that the asynchronous verification processing result for the service access process is verification failure; All process information is different, that is, when the matching fails, it is determined that the asynchronous verification processing result of the service access process is verification successful.
  • the process information when the process information includes multiple types of content (such as MD5 value, Hash value, etc.), it can be set that a certain content (such as MD5 value) included in the process information A and the content included in the process information B can be set.
  • a certain content such as MD5 value
  • the content included in the process information B can be set.
  • process information of the service access process can be periodically sent to a specific cloud service, so that the cloud service matches the process information of the service access process with the process information blacklist, thereby reducing the local processing pressure.
  • the embodiments of the present application provide some examples of performing synchronous verification processing and asynchronous verification processing on the service access process, which can effectively improve the accuracy of the obtained synchronous verification processing results and asynchronous verification processing results, thereby enhancing subsequent The security of conducting business communications.
  • FIG. 4C is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • Step 104 shown in FIG. 4A can be implemented through steps 301 to 307 , which will be described in conjunction with each step.
  • step 301 the service key information is encrypted according to the public key in the authentication request.
  • an asymmetric key pair may be generated by the service access process, and the asymmetric key pair in the asymmetric key pair may be generated.
  • the public key is added to the authentication request, wherein the asymmetric key pair includes the public key and the private key matched with the public key.
  • the electronic device After determining the service key information allocated to the service access process, the electronic device can encrypt the service key information by using the public key sent by the service access process.
  • step 302 the encrypted service key information is sent to the service access process, so that the service access process decrypts the encrypted service key information according to the private key.
  • the electronic device sends the encrypted service key information to the service access process, so that the service access process decrypts the encrypted service key information according to the stored private key. Since other processes except the service access process do not hold the private key, even if the encrypted service key information is stolen by other processes, other processes cannot obtain the actual service key information. In the above manner, the confidentiality of the service key information can be improved.
  • step 303 a service request sent by the service access process is received; wherein, the service request includes a key identifier and request data encrypted with a symmetric key.
  • the process of encrypting the service communication is described by taking the service key information including the key identifier and the symmetric key as an example.
  • the service access process can generate a call request based on the service key information.
  • the call request includes the key identifier and the request data encrypted with the symmetric key.
  • the type of the request data is not specified here. The limit can be determined according to the actual application scenario.
  • a service interface (such as a specific port) may be pre-agreed in the electronic device, and when the electronic device receives a call request for the service interface from the service access process, the call request is regarded as a service request.
  • different service interfaces can be set for various services, and a unified service interface can also be set.
  • step 304 in the distributed symmetric key, query the symmetric key corresponding to the key identifier in the service request.
  • the electronic device When distributing the service key information, the electronic device stores the service key information, wherein each service key information includes a key identifier and a symmetric key corresponding to the key identifier.
  • each service key information includes a key identifier and a symmetric key corresponding to the key identifier.
  • the electronic device searches for the symmetric key corresponding to the key identifier in the service request among all the distributed symmetric keys. If the symmetric key corresponding to the key identifier is not queried, corresponding error information may be sent to the service access process, so that the service access process resends the service request when the error information is received.
  • the method further includes: when the queried use parameter of the symmetric key meets the expiration parameter condition, sending expiration information to the service access process, so that the service access process receives the expiration information after receiving the expiration information.
  • the authentication request is re-sent when the time of use; wherein, the use parameter includes at least one of the number of times of use and the length of use.
  • an expired parameter condition can be set.
  • the electronic device can update the service key information, wherein the expired parameter condition can be the maximum usage At least one of the number of times and the effective use duration, of course, may also be other conditions, which are not limited.
  • the electronic device After the electronic device performs a query based on the key identifier in the service request, if the queried use parameter of the symmetric key (equivalent to the use parameter of the service key information to which the symmetric key belongs) satisfies the expired parameter condition, the expired information will be stored. It is sent to the service access process, so that the service access process resends the authentication request when it receives the expired information, thereby requesting the updated service key information. In the above manner, the dynamic update of the service key information can be realized, and the security of the service communication can be further improved.
  • step 305 decrypt the encrypted request data in the service request according to the queried symmetric key.
  • step 306 a response process is performed on the request data obtained by the decryption process to obtain response data.
  • the request data obtained by the decryption process may be subjected to response processing according to actual business policies or rules to obtain response data.
  • the request data obtained by the decryption process is a video link
  • the video data corresponding to the video link can be obtained as the response data.
  • the response processing performed may also be to store the request data obtained by the decryption processing, that is, it is not necessary to obtain the response data, and only the case of obtaining the response data is described here as an example.
  • the service request further includes a timestamp and first verification information; wherein, the first verification information is the service access process pair key identifier, symmetric key, timestamp, and encrypted data using the symmetric key. It is obtained by hashing the request data obtained by hashing; the above-mentioned response processing to the request data obtained by the decryption process can also be implemented in this way: the key identifier, the queried symmetric key, the timestamp, and the encrypted request The data is hashed to obtain second verification information; when the matching result between the first verification information and the second verification information is successful, a response processing is performed on the request data obtained by the decryption processing.
  • the service access process may perform hash processing on the key identifier, the symmetric key, the current timestamp, and the request data encrypted with the symmetric key to obtain the first verification information, and the first verification information
  • the service request includes the key identifier, the request data encrypted with the symmetric key, the time stamp, and the first verification information.
  • the electronic device After the electronic device obtains the corresponding symmetric key by querying the key identifier in the service request, it searches the key identifier in the service request, the symmetric key obtained in the query, the timestamp in the service request, and the encrypted data in the service request.
  • the requested data is hashed to obtain the second verification information.
  • the algorithm used in the hash processing can be pre-agreed to ensure the uniformity of the algorithm.
  • the electronic device When the first verification information is the same as the second verification information, that is, the matching is successful, it proves that the data in the service request has not been tampered with. At this time, the electronic device responds to the request data obtained by the decryption process; when the first verification information Different from the second verification information, that is, when the matching fails, it proves that the data in the service request has been tampered with, and the electronic device can send the corresponding error information to the service access process, so that when the service access process receives the error information, Resend the service request.
  • the first verification information and the second verification information may be compared first, and then the encrypted request data in the service request is decrypted according to the symmetric key obtained;
  • the encrypted request data in the service request may also be decrypted according to the symmetric key obtained, and then the first verification information and the second verification information are compared.
  • step 307 the response data is encrypted according to the public key, and the encrypted response data is sent to the service access process, so that the service access process decrypts the encrypted response data according to the private key.
  • the electronic device After obtaining the response data through the response processing, the electronic device encrypts the response data according to the public key sent by the service access process, and sends the encrypted response data to the service access process.
  • the service access process receives the encrypted response data, it can decrypt it according to the stored private key, obtain the response data, and complete an encrypted service communication.
  • the embodiment of the present application performs encrypted service communication by combining the asymmetric key pair generated by the service access process and the service key information issued by the electronic device, which can effectively ensure the security and privacy of service communication.
  • FIG. 4D is a schematic flowchart of a service communication method provided by an embodiment of the present application.
  • the data sent by the service access process may also be received.
  • Credential request wherein, the credential request is sent by the service access process when it intercepts the service request of the application process, and the destination address of the service request is the address of the service server.
  • the service access process may be used to intercept a service request sent by an application process (for example, an application process running on the same terminal device as the service access process), where the destination address of the service request is a service server
  • the address here can include IP address (or domain name) and port.
  • the manner of intercepting the service request is not limited, for example, the interception can be implemented through a specific virtual network card.
  • the service access process When the service access process intercepts the service request, it generates a credential request.
  • the content of the credential request may include the source address (that is, the address of the application process) and the destination address in the service request, and may also include the process identification number (Process ID) of the application process. IDentification, PID).
  • step 402 a synchronization verification process is performed on the application process.
  • the electronic device When receiving the credential request sent by the service access process, the electronic device performs synchronous verification processing on the application process pointed to by the credential request.
  • the credential request is also one of the service requests sent by the service access process, and the response data requested by the credential request is the service credential.
  • the above-mentioned synchronous verification processing for the application process can also be implemented by: determining the user account in the logged-in state in the device where the application process is located, and obtaining the process information of the trusted application process corresponding to the user account, and the address of the accessible service server corresponding to the user account; the matching result between the process information of the application process and the process information of the trusted application process is used as the third verification processing result; the address of the service server requested by the service request The matching result with the address of the accessible service server is taken as the fourth verification processing result; the device information of the device where the application process is located is obtained, and the matching result between the device information and the device security condition is taken as the fifth verification processing result ; According to the third verification processing result, the fourth verification processing result and the fifth verification processing result, determine the synchronization verification processing result for the application process.
  • a trusted application process corresponding to the user account and an accessible service server can be set.
  • the address of the accessed business server is stored locally.
  • the electronic device When the electronic device receives the credential request sent by the service access process, it can determine the corresponding application process according to the PID in the credential request, determine the user account in the logged-in state in the device where the application process is located, and obtain the device information of the device where the application process is located. .
  • the process information of the application process is the same as the process information of any trusted application process corresponding to the user account, that is, when the matching is successful, the third verification processing result is determined to be successful verification;
  • the process information is different from the process information of all trusted application processes corresponding to the user account, it is determined that the third verification processing result is verification failure.
  • the fourth verification processing result is determined to be successful;
  • the destination address in the request is different from the addresses of all accessible service servers corresponding to the user account, it is determined that the fourth verification processing result is verification failure.
  • the device information is also matched with the set device security conditions. If the device information meets the device security conditions, that is, the matching is successful, the fifth verification processing result is determined to be verification success; otherwise, the fifth verification processing result is determined to be verification failure.
  • the device security conditions are not limited, for example, the device information may not include viruses and system vulnerabilities.
  • the synchronous verification processing result for the application process can also be determined according to at least one of the above-mentioned third verification processing result, fourth verification processing result and fifth verification processing result, thereby improving the efficiency of the synchronous verification processing. . In the above manner, the accuracy and validity of the obtained synchronization verification processing result can be improved.
  • the method further includes: periodically matching the process information of the application process with the process information blacklist, and using the obtained matching result as the asynchronous verification processing result of the application process;
  • the asynchronous verification processing result of the control and the service access process is used to carry the communication connection of encrypted service communication.
  • asynchronous verification processing can also be performed on the application process.
  • the process of performing the asynchronous verification processing on the application process is similar to the above-mentioned process of performing the asynchronous verification processing on the service access process.
  • the method further includes: sending a query request to the blockchain network to query the blacklist stored in the blockchain.
  • the embodiments of the present application can also be implemented in combination with blockchain technology.
  • the blockchain can be used to store blacklists, including but not limited to the above-mentioned blacklist of signers, blacklist of certificate information, and blacklist of process information.
  • blacklists including but not limited to the above-mentioned blacklist of signers, blacklist of certificate information, and blacklist of process information.
  • an example application of the blockchain network will be described by taking the electronic device accessing the blockchain network to realize the query blacklist as an example.
  • the electronic device 700 is connected to the blockchain network 500 and becomes a client node of the blockchain network 500 .
  • the electronic device 700 needs to query the blacklist, it sends the query request to the blockchain network 500 in the form of a transaction, and specifies in the transaction the smart contract that needs to be called to realize the query operation and the parameters passed to the smart contract, and the transaction also carries the electronic device.
  • 700 signs the digital signature (eg, obtained by encrypting a digest of the transaction using the digital certificate of the electronic device 700 ), and broadcasts the transaction to the blockchain network 500 .
  • the digital certificate can be obtained by registering with the certification center 600 by the electronic device 700 .
  • the node 510 in the blockchain network 500 When the node 510 in the blockchain network 500 receives the transaction, it verifies the digital signature carried in the transaction. After the verification of the digital signature is successful, it confirms whether the electronic device 700 has the transaction status according to the identity of the electronic device 700 carried in the transaction. Any one of authority, digital signature and authority verification will cause the transaction to fail. After the verification is successful, the digital signature of the node 510 is signed and continues to be broadcast in the blockchain network 500.
  • the node 510 with the sorting function in the blockchain network 500 fills the transaction into a new block and broadcasts it to the nodes in the blockchain network 500 that provide consensus services.
  • the nodes 510 providing consensus services in the blockchain network 500 perform a consensus process on the new block to reach an agreement, and the nodes 510 providing the ledger function append the new block to the end of the blockchain and execute the transactions in the new block:
  • For queries on the blacklist the blacklist is queried from the state database, and the queried blacklist is sent to the electronic device 700 .
  • the state database stores data in the form of key-value pairs, and the data stored in the state database is usually the same as the data stored in the blockchain.
  • the data in the state database can be given priority to respond, thereby Improve response efficiency.
  • the above method ensures the accuracy of the obtained blacklist.
  • the data stored in the blockchain is not limited to the blacklist.
  • it may also include the assigned business key information, the process information of the trusted application process corresponding to the user account, the address of the accessible business server corresponding to the user account, etc. .
  • step 403 according to the synchronous verification processing result of the application process, determine the service credential and gateway address allocated to the application process, and send the service credential and gateway address to the service access process, so that the service access process can send the service credential and gateway address to the service access process. And the service request is sent to the service gateway corresponding to the gateway address.
  • the electronic device determines the service credential and gateway address allocated to the application process, and sends the service credential and gateway address to the service access process; synchronous verification of the application process
  • the processing result is that the verification fails
  • the communication connection with the service access process may be disconnected, or the service access process may be notified to directly connect with the service server.
  • the gateway address here refers to the address of the service gateway that has permission to access the service server (here, the service server requested by the service request of the application process).
  • the service gateway to be accessed can also be uniformly set to the service gateway authorized to access, which is not limited.
  • the electronic device may store the assigned service credential locally for subsequent verification, wherein the type of the service credential is not limited, for example, it may be a random character string.
  • the service access process When the service access process receives the service credential and the gateway address, it may first send the service credential to the service gateway corresponding to the gateway address.
  • the business gateway receives the business credential, it sends the business credential to the electronic device for verification processing. If the business credential is the same as the business credential stored in the electronic device, that is, the verification is successful, the business gateway can send the verification success information to the service access process.
  • the service access process receives the information that the verification is successful, it sends the service request of the application process to the service gateway, so that the service gateway forwards the service request to the service server. Request data for response processing.
  • the response data obtained by the service server through response processing can be sent to the application process in the opposite communication direction.
  • the service gateway fails to verify the received service credential, the service gateway does not support forwarding the service request sent by the service access process, for example, the service gateway can disconnect the communication connection with the service access process.
  • the interaction between the service access process and the electronic device belongs to the category of encrypted service communication.
  • the service access process can act as an agent of the application process to access the service server, which is suitable for zero-trust scenarios, such as zero-trust borderless office scenarios.
  • the service communication method can be implemented through a service communication system, wherein the service communication system includes a service access client, a security client, and a security server.
  • FIG. 4E is a schematic flowchart of a service communication method provided by an embodiment of the present application, which will be described with reference to the steps shown in FIG. 4E.
  • step 501 the security client receives the authentication request sent by the service access process.
  • the security client and the service access client may be deployed in the same terminal device, or may be deployed in different terminal devices.
  • step 502 the security client performs synchronization verification processing on the service access process.
  • the synchronization verification processing performed on the service access process may include verification processing on the process path and signature information.
  • the service access client may be a component of the security client, and when the security client verifies the process path of the service access process, the security directory may be the installation directory of the security client .
  • step 503 the security server performs asynchronous verification processing on the service access process.
  • the security client may notify the security server to perform asynchronous verification processing on the service access process, and the security server may return the asynchronous verification processing result on the service access process to the security client.
  • the security client can send the process information of the service access process to the security server, so as to facilitate asynchronous verification processing.
  • step 504 the security client determines the service key information allocated to the service access process according to the synchronous verification processing result of the service access process.
  • the security client requests the security server for service key information, that is, the actual generator of the service key information may be the security server.
  • the security client can store the acquired service key information locally for subsequent encrypted service communication.
  • step 505 the security client sends the service key information to the service access process, so as to perform encrypted service communication with the service access process based on the service key information.
  • the method further includes: the security client receives a credential request sent by the service access process; wherein, the credential request is sent by the service access process when the service request of the application process is intercepted, and the service request is sent by the service access process.
  • the destination address is the address of the service server; the security client informs the security server to perform synchronous verification processing on the application process; the security server determines the service credential and gateway address allocated to the application process according to the synchronous verification processing result of the application process, and sends the service credential.
  • the service access client sends the service certificate and service request to the service gateway corresponding to the gateway address through the service access process;
  • the business voucher is verified, and when the verification processing result of the business voucher is successful, the received business request is sent to the business server; the business server is used for responding to the request data in the received business request.
  • the security client, the service access process and the application process can run in the same terminal device.
  • the security client can send the obtained credential request, the user account in the logged-in state in the device where the application process is located, the process information of the application process, and the device information of the device where the application process is located to the security server, so that the security server can process the application process.
  • Synchronous verification processing, wherein the user account in the login state may refer to the user account in the login state in the security client.
  • the security server may also perform asynchronous authentication processing on the application process.
  • step 506 the security client controls the communication connection with the service access process for carrying encrypted service communication according to the asynchronous verification processing result of the security server on the service access process.
  • encrypted service communication can be implemented through a service access client, a security client, and a security server, wherein the service access client can be used as a component of the security client, which is convenient for installation on terminal devices (For example, terminal devices held by enterprise employees), it is suitable for scenarios such as zero-trust borderless office.
  • the business communication system may include a security client, a security server, and a security management terminal, wherein the security management terminal is used to configure policies, rules, etc. applied in the security client and/or the security server, and the security management terminal
  • the terminal can provide a human-computer interaction interface (such as a Web interface), so that it is convenient for administrators (such as enterprise administrators) to configure.
  • an administrator can configure a zero-trust policy on the security management end, where the zero-trust policy includes applications (trusted applications) that can be used by a user account and business systems that can be accessed.
  • the zero-trust policy can be configured from three aspects: user accounts (or user account groups), trusted applications, and business systems (corresponding to the above-mentioned business servers) in the organizational structure, which are described separately below.
  • the granularity of the zero trust policy may be a single user account. If a zero-trust policy is configured for a user account group, all user accounts included in the user account group can share the same zero-trust policy.
  • the terminal device can access the application carrier of the internal business system, and the application carrier is trusted by the security management terminal.
  • the process information of the application process may include an application name, a process name, an application MD5 value, signature information, and the like.
  • Business system It can be used to provide internal business resources, data, development environment, test environment, operation and maintenance environment and formal production environment, etc. It is the object that the access subject (person/terminal device/application) needs to access, that is, the business The system is the object of access.
  • the business system may be a business server (or a cluster of business servers).
  • the user account group is a node in the organizational structure of the enterprise.
  • the nodes are the network-wide account, user account group and user account from top to bottom, that is, the network-wide account belongs to all user account groups.
  • the parent node, the user account group is the parent node of all user accounts included in the user account group.
  • the "lemon" user account in Figure 5 belongs to the "testgroup” user account group, and the "testgroup” user account group also belongs to the entire network account.
  • This embodiment of the present application also provides a schematic diagram of process information (also called process features) as shown in FIG. 6 .
  • process information also called process features
  • FIG. 6 the process information of a conference application process is shown, which may include process name, application name, operation System (that is, the operating system of the terminal device used to run the application process), manufacturer, signature information, inspection result (that is, the asynchronous verification processing result), version, MD5 value, and SHA256.
  • the administrator can configure the zero-trust gateway on the zero-trust gateway (corresponding to the above-mentioned business gateway) interface on the security management side.
  • the zero-trust gateway on the security management side as shown in Figure 7 is provided.
  • the schematic diagram of the interface, and the schematic diagram of the configuration interface of the zero-trust gateway shown in FIG. 8, the configuration interface shown in FIG. 8 can be displayed by triggering a certain gateway (such as gateway 4) shown in FIG. This is not limited. Administrators can configure attributes such as the name, IP address, domain name, port, and IP address segment of the zero-trust gateway according to actual needs.
  • a gateway is configured with a preferentially accessed IP address segment
  • the gateway when the IP address of the access subject (such as a terminal device) matches the preferentially accessed IP address segment successfully (that is, it falls into the preferentially accessed IP address segment ), the gateway can be used preferentially to forward the service request of the access subject; when the IP address of the access subject fails to match the IP address segment of the preferential access, the gateway can be selected or not used, depending on the actual application scenario Depends.
  • the embodiment of the present application also provides a schematic diagram of the service system interface of the security management terminal as shown in FIG. 9 .
  • a specific business system can be queried, and it can also support adding, copying, and deleting (eg, batch deleting) business systems.
  • different system combinations can also be created, wherein the system combination includes at least one business system.
  • the system combination 1 taking the system combination 1 as an example, the service systems 1 to 4 in the system combination 1 are shown.
  • the embodiment of the present application also provides schematic diagrams of configuration interfaces of the service system as shown in FIG. 10 , FIG. 11 , and FIG. 12 .
  • the embodiment of the present application provides a schematic diagram of the policy management interface of the security management terminal as shown in FIG. 13 .
  • a trusted application ie, “xx conference” in FIG. 13
  • a business system accessible through trusted applications ie, “System Composition 2” in Figure 13.
  • the embodiment of the present application may provide an inheritance function, that is, the configuration is automatically copied down along with the hierarchical relationship of user accounts from top to bottom, so as to avoid repeated checking operations by the administrator. For example, if the user account "123" belongs to the user account group "test”, the configuration of the user account group "test” can be copied to the user account "123".
  • the inheritance function can also be turned off to perform targeted configuration on the user account "123".
  • the security management terminal can deploy the zero trust policy configured by the administrator to the security server, of course, it can also be deployed to the security client, for example, deploy part of the zero trust policy to the security client.
  • the security client is used to be installed in the terminal device as the access subject, such as the personal computer used by the employees of the enterprise.
  • the embodiment of the present application provides a schematic interface diagram of a security client as shown in FIG. 14 .
  • FIG. 14 two modes of scanning code login and account login are provided. way to log in.
  • the security client can also integrate functions such as virus detection, compliance detection, vulnerability repair, and computer tools.
  • the security client can provide real-time protection policies,
  • the antivirus protection engine and security hardening strategy can add and delete functions to the security client according to actual application scenarios.
  • the embodiment of the present application also provides a schematic interface diagram of the security client as shown in FIG. 16 .
  • the security client can obtain the zero-trust policy configured for the user account in the logged-in state, and obtain the trusted value from the zero-trust policy. applied and displayed.
  • the trusted application "xx conference” corresponding to the user account "lemon” is shown.
  • the terminal device can access the configured business system according to the configured trusted application, which is suitable for the scenarios of borderless office, such as remote office.
  • the business communication system can act as a zero-trust network security service provider, based on an access proxy (corresponding to the above-mentioned business access client) and zero-trust network security service providers.
  • the trust gateway provides a unified portal for the access subject, so that the access subject can access the access object through the unified portal, that is, send a service request through the network.
  • the business communication system can provide authentication operations for the unified portal, and only the business requests that pass the authentication can be forwarded to the zero-trust gateway by the access agent, so that the access to the actual business system can be represented by the zero-trust gateway.
  • the embodiment of the present application also provides a schematic diagram of an access process as shown in FIG. 18 .
  • the core modules in FIG. 18 include a security client, a security server, an access proxy, and a zero-trust gateway (smart gateway). .
  • Security client Agent installed in the access subject (such as the terminal device of an enterprise employee), which can be used to verify whether the user account in the login state is trustworthy, whether the terminal device is trustworthy, and whether the application is trustworthy.
  • the security client can send the process characteristics of the application process (corresponding to the above process information) to the security server, that is, to perform process submission (corresponding to the above asynchronous verification processing for the application process).
  • Access proxy Also known as proxy client, it is used to hijack the traffic of the terminal device, that is, to intercept the service requests sent by the application process in the terminal device. Among them, traffic hijacking can be achieved through the TUN/TAP virtual network card, but the hijacking method is not. limited to this.
  • Zero-trust gateway It can be deployed at the entrance of enterprise applications and data resources, and is responsible for verifying, authorizing and forwarding each business request used to access the enterprise's internal business system. Among them, the zero trust gateway can be built in the form of software.
  • Security server responsible for the security scheduling of service traffic through the policy control engine (policy center), and authorize the service requests of the application process according to the granularity of user account-terminal device-application.
  • the security server can be used to verify whether the user account in the login state in the security client is trustworthy, can also be used to verify device hardware information and device security status, and can also be used to detect whether the application process is trustworthy, such as whether there are loopholes, whether There are virus Trojans and so on.
  • the security server can periodically send files to the cloud server for inspection. If the application process that sends the service request is identified as a malicious process, it will notify the security client to perform an asynchronous blocking operation, such as disconnecting the communication connection with the access agent.
  • the cloud server is used to provide cloud detection services (or cloud query services, cloud identification services, etc.) of malicious processes.
  • the terminal device can send a service request for the access object through the application process.
  • the access agent hijacks the service request, it sends a ticket request (corresponding to the above credential request) to the security client.
  • the ticket request Including the source IP address (or source domain name), source port, destination IP address (or destination domain name) and destination port in the service request, as well as the PID corresponding to the application process, where the ticket corresponds to the above service credential, and the PID uses to uniquely identify the application process.
  • the security client When the security client receives the ticket request sent by the access agent, it collects the MD5 value of the application process, the process path, the last modification time of the process, the copyright information and the signature information according to the PID in it, together with the source IP address (or source domain name), source port, destination IP address (or destination domain name) and destination port, together with the information of the user account in the login state in the security client, apply for a ticket to the security server. After receiving the information, the security server obtains the zero-trust policy corresponding to the user account in the logged-in state in the security client, and determines whether the user account has passed the application process (referring to initiating a service request) according to the obtained zero-trust policy.
  • the application process has the right to access the business system (referring to the business system requested by the business request). If it has the right, the security server can send the generated ticket, the maximum number of times of use of the ticket and the valid use time of the ticket to the security client, so that the The secure client forwards to the access proxy.
  • the security client applies for a ticket to the security server, and the security server performs synchronous verification processing on the process characteristics of the application process, such as verifying whether the application process is a trusted application, and whether the user account has access to the corresponding application process through the application process. business system permissions, etc. If the synchronous verification processing result obtained by the security server is successful, the security server will normally respond to the ticket, the maximum number of times the ticket is used, and the valid usage time of the ticket to the security client, and the security client will send it to the access agent. For example, the security client can pass the local Process communication (ie, Socket communication connection) is sent to the access agent.
  • the local Process communication ie, Socket communication connection
  • the security server may periodically send a file submission request to a specific cloud server according to the process characteristics of the application process. If the security server obtains from the cloud server that the application process is a malicious process, it can notify the security client to perform an asynchronous blocking operation, such as disconnecting the communication connection with the access agent.
  • the access agent After the access agent obtains the ticket, it can send the ticket to the zero-trust gateway for verification by the zero-trust gateway. For example, an access proxy can add a ticket to the Authorization header field of an HTTPS request and send the HTTPS request to the Zero Trust Gateway. When the zero-trust gateway receives the HTTPS request, it parses the ticket in the Authorization header field and verifies the ticket to the security server.
  • the zero-trust gateway successfully verifies the ticket, the zero-trust gateway and the access agent successfully establish a connection, and then the access agent can send the original service request (here, the service request sent by the application process) to the zero-trust gateway, and the zero-trust gateway Forward the business request to the corresponding business system to proxy the network access of the application process to the business system; if the zero-trust gateway fails to verify the ticket, the communication connection between the access agent and the zero-trust gateway is disconnected, and the access agent directly Send the original business request to the corresponding business system.
  • the zero-trust borderless office scenario in order to ensure the security of network access, such access usually fails.
  • the security server can adapt to medium-sized enterprises and institutions and the government through a single deployment mode, and can also adapt to large-scale enterprise groups and multi-level vertical government e-government systems through a distributed cascade deployment mode.
  • the scheme of multi-active zero-trust core services in different places can be adopted.
  • the core basic services are deployed in the master control node, and different services are deployed in different secondary service nodes.
  • the embodiment of the present application provides a schematic diagram of cascading deployment as shown in FIG. 19 .
  • the security server adopts a cascading deployment mode, including a master control node (master control server) and a secondary service node (server node).
  • the master control node is deployed with core basic services, such as heartbeat service, policy synchronization service, and device management and control service.
  • the configuration and data of the master control node can be periodically synchronized to each secondary service node; at the same time, when the secondary service node has data and configuration that needs to be changed, the master control node can be notified to modify it. After the master control node is modified, the synchronization Just give it to the corresponding secondary business node.
  • the service access process of the access agent can call the interface in the security client to realize data transmission.
  • the service access process of the access agent can be subjected to synchronous verification processing and asynchronous verification processing. Each of them will be described below.
  • the security client After the access proxy establishes a socket connection with the security client, the security client obtains the PID of the service access process through the IP address and port number of the access proxy. Then, the security client obtains the process path of the service access process according to the PID of the service access process, and detects whether the process path is located in the installation directory of the security client (corresponding to the security directory above).
  • the access agent may be a component of the business communication system. After normal installation, the access agent is usually located in the installation directory of the security client.
  • the installation directory of the security client can be protected by directory protection, so that services or processes of other non-service communication systems can be prevented from operating the installation directory.
  • the validity of the access process can be preliminarily detected. If the process path of the service access process is located in the installation directory, the signature information of the process file of the service access process can be further acquired, and verification processing is performed.
  • the security control intensity of the enterprise is low, it is possible to relax (authorize) the interface access of the service access process without digital signature to the security client; when the security control intensity of the enterprise is high, it can be Only the signed service access process can access the interface of the secure client.
  • the following verification processes for signature information can be implemented.
  • the security client performs validity verification processing on the digital signature locally, such as calling the API of WinVerifyTrust for validity verification processing. If the validity verification process is that the verification is successful, it is determined that the verification of the signature information is successful.
  • the security client obtains the certificate chain information of the process file of the service access process (corresponding to the certificate information above), for example, the certificate chain information may include digest algorithm, root certificate information, intermediate certificate information, signature certificate information, signature status, Signer's name, timestamp, and signature verification error information.
  • the root certificate information includes the name, serial number, and expiration time of the root certificate, and the intermediate certificate information and signature certificate information and so on.
  • the signature status can be used to indicate one of the digital signature available, the digital signature being tampered with, the certificate not trusted, the certificate expired, the certificate revoked, and other errors.
  • the security client can match the certificate chain information with the certificate chain information blacklist (corresponding to the certificate information blacklist above). If the matching fails, it is determined that the verification of the signature information is successful.
  • the security management and control strength of the above four methods is gradually increased, and accordingly, the time spent on verification processing will also become longer. According to the strength requirements and efficiency requirements of security management and control in actual application scenarios, at least one method can be selected to realize the verification of signature information. verification processing.
  • the security client When the security client successfully verifies the process path and signature information of the service access process, it can first allow the interface call of the service access process to enter the interface authentication link.
  • the security client can asynchronously obtain the process characteristics of the service access process and send it to the security server for asynchronous verification processing.
  • the process characteristics of the service access process include but are not limited to the MD5 value, Hash value, process path and signature information (including certificate chain information) of the service access process.
  • the security server After the security server receives the process characteristics of the service access process, it can periodically send a file inspection request to the cloud server. Whether the service access process is a malicious process. If the cloud server determines that the service access process is a malicious process, the security server will notify the security client, so that the security client disconnects the socket connection with the service access process.
  • the embodiment of the present application provides a schematic diagram of asynchronous verification processing as shown in FIG. 20 .
  • the numbers in FIG. 20 represent steps of the asynchronous verification processing, which will be described in conjunction with the illustrated steps.
  • the access agent tries to call the relevant interface of the security client, that is, sends an authentication request to the security client.
  • the security client performs synchronous verification processing on the service access process (including verification processing on the process path and signature information), and if the synchronous verification processing result is that the verification is successful, the process characteristics of the service access process are collected.
  • the security client sends the process characteristics of the service access process to the security server, that is, asynchronous submission.
  • the security server sends the process characteristics of the service access process to the cloud server, so that the cloud server can judge whether the service access process is a malicious process.
  • the cloud server sends the result of the asynchronous verification processing to the security server, that is, whether the business access process is a malicious process.
  • the security server If the service access process is a malicious process, the security server notifies the security client to perform a connection blocking operation.
  • the service access process generates an asymmetric key pair.
  • an asymmetric key pair is generated by the service access process.
  • the private key in the asymmetric key pair can be encrypted and stored in memory by the service access process, and the public key pubkey in the asymmetric key pair is used to send to the security client.
  • This embodiment of the present application does not limit the manner of generating the asymmetric key pair, for example, it can be generated by using the RSA algorithm.
  • the service access process sends an authentication request to the authentication interface of the security client, and an example of the authentication request is as follows.
  • [port] represents the listening port of the security service provided by the security client
  • [path] represents the service route (corresponding to the authentication request address above)
  • [req_acc] represents the request identifier, which is used to request authentication.
  • ⁇ pubkey ⁇ urlencode(base64encode(pubkey)) in the above example, that is, ⁇ pubkey ⁇ is the result obtained by performing urlencode after base64encoding the public key pubkey generated by the service access process.
  • the purpose of executing base64encode and urlencode is to facilitate network transmission.
  • the security client When the security client receives the authentication request, it detects the legitimacy of the service access process through the above-mentioned combination of synchronous and asynchronous methods. When the result of the synchronous verification processing on the service access process is that the verification is successful, the security client requests the security server to generate a symmetric key aes_key for subsequent encrypted service communication, where the symmetric key can be generated by the AES algorithm or other algorithms. The security client encrypts the symmetric key through ⁇ pubkey ⁇ in the authentication request, and sends the encrypted symmetric key to the service access process to complete the first authorization.
  • encrypt(plain_data, pubkey) represents the result obtained after the security client encrypts the plaintext information plain_data of the data packet body according to the public key pubkey sent by the service access process, that is, encrypt represents encryption processing.
  • the access_key is the result obtained by the security client performing base64encode on the symmetric key aes_key.
  • the security server can store the mapping relationship between the access_id and the access_key, and can also store attributes such as the maximum number of times the access_key is used and the effective use duration.
  • the security client can also store the access_id and the corresponding access_key (or the corresponding aes_key) locally for subsequent query.
  • the service access process receives and parses the data packets responded by the security client.
  • the service access process When the service access process receives the data packet returned by the security client, it parses out the response code code in the data packet. If the value of the response code code is 0, it means the processing is normal, and the service access process further parses the data through base64decode The base64 plaintext of the package data, and then decrypt the base64 plaintext through the private key encrypted and stored in the memory to obtain plain_data.
  • access_id and access_key may be in a one-to-one relationship.
  • the service access process calls the service interface of the security client.
  • the business interface may be an interface for applying for a ticket, or of course other business interfaces.
  • the service access process calls the service interface of the security client, the raw parameter raw_param (corresponding to the above request data) sent to the service interface is processed as follows to form call_param.
  • step 3 Execute urlencode for the result obtained in step 2, that is, urlencode(base64encode(encrypt(raw_param, aes_key))), to get call_param.
  • the service access process calls the service interface of the security client
  • the service access process simultaneously generates custom verification information signature (corresponding to the first verification information above), and the generation steps are as follows.
  • the service access process takes out the access_id from the memory encrypted data as the first part (named A).
  • timestamp represents the timestamp in the process of generating the signture, that is, the above D. It is worth noting that the service request sent by the service access process to the security client includes the above-mentioned call_param and Authorization public header information.
  • the security client parses the service request sent by the service access process to the service interface, and checks whether the service request is legal.
  • the security client When the security client receives the service request, it urldecodes the call_param in the service request, and then performs base64decode to obtain encrypt(raw_param, aes_key). Then, decrypt (raw_param, aes_key) with aes_key to obtain raw_param, that is, the original parameter of the service access process.
  • the security client For the Authorization public header information in the service request, the security client first performs base64decode to obtain the plaintext, that is, access_id, custom verification information signture, and timestamp. Then, the security client performs a local query according to the access_id to obtain the corresponding access_key (or aes_key), and then sends the queried access_key to the security server to detect whether the queried access_key expires. If the queried access_key has expired, the security client triggers the re-authentication by calling the authentication interface, that is, the service access process resends the authentication request.
  • the security client will regenerate the verification information according to the call_param in the service request, the access_id in the Authorization public header, the timestamp in the Authorization public header, and the queried access_key.
  • the security client compares the generated verification information Signature' with the custom verification information Signature sent by the service access process. If the two are the same, the security client determines that the service request is legal; if the two are different, it proves that the service request is valid. If the parameters of the server are tampered with or forged, the security client determines that the service request is invalid, and the service access process fails to call the service interface.
  • the security client responds to the original parameters in the service request to obtain response data, and returns it to the service access process.
  • the security client determines that the service request is valid, that is, the call of the service access process to the service interface is valid, the security client responds to the raw parameter raw_param in the service request, and obtains the response data resultdata.
  • the specific content is not limited, and can be set according to the actual business.
  • An example of a data packet returned by the security client to the service access process is as follows.
  • retcode represents the response code for the service request sent by the service access process. If retcode is 0, it means that the invocation of the service interface is successful; if retcode is 1, it means that the invocation of the service interface fails; if retcode is 2, It means that the access_key (or aes_key) has expired, and the service access process needs to resend the authentication request, that is, re-execute step 2).
  • the symmetric key required for interface authentication may be periodically updated at the security management end, and at each update, the security server may set all access_id and access_key (or aes_key) before the update to invalid, Thus, the service access process is triggered to call the authentication interface of the security client again to obtain the updated access_id and access_key.
  • access_id and access_key can be configured on the security management end in this embodiment of the present application, for example, the service access process itself and the service route sent when the service access process calls the authentication interface can be distinguished .
  • the service routes include path1, path2, and path3, and when the service access process B calls the authentication interface, the service routes include path4 and path5.
  • the granularity division scheme may include the following: Three:
  • the security server simultaneously distinguishes service access processes and service routes, that is, assigns different access_id and access_key combination pairs for different service access processes, and also assigns different access_id and access_key combination pairs for different service routes of the same service access process. .
  • service access processes and service routes that is, assigns different access_id and access_key combination pairs for different service access processes, and also assigns different access_id and access_key combination pairs for different service routes of the same service access process.
  • the security server only distinguishes service access processes, not service routes, that is, assigns different access_id and access_key combination pairs to different service access processes, and assigns the same access_id and access_key combination to different service routes of the same service access process right. For example, for path1, path2 and path3 of service access process A, a set of access_id and access_key combination pairs are uniformly allocated; for path4 and path5 of service access process B, another set of access_id and access_key combination pairs are uniformly allocated.
  • the security server does not distinguish between service access processes and service routes, that is, for all service routes of all service access processes, a set of access_id and access_key combination pairs are uniformly allocated.
  • administrators can use any of the above granularity division schemes according to the level of management and control of the enterprise.
  • the security server can configure at least one of the maximum number of times of use and the effective use time, so as to realize regular update of access_id and access_key and improve security.
  • the security client can effectively verify the legitimacy of the service access process by performing verification processing on the process path and signature information of the service access process; It can accurately verify whether the business access process is a malicious process.
  • the embodiment of the present application not only improves the verification accuracy of the service access process, but also improves the efficiency of the compliant service access process accessing the security client.
  • the embodiments of the present application provide an interface authentication scheme verified by dynamic keys and self-defined verification information, which can encrypt business communication according to the symmetric key issued by the security server, so as to avoid the problem of key storage being cracked; , the service key information can be periodically updated, thereby enhancing the security of interface calls; it also allows administrators to distinguish service key information through different granularity division schemes according to the degree of control of each service, improving the ability to understand different services and different scenarios. applicability.
  • the software module stored in the service communication device 455 of the memory 450 may include: receiving The module 4551 is used to receive the authentication request sent by the service access process; the verification module 4552 is used to perform synchronous verification processing on the service access process, and perform asynchronous verification processing on the service access process; The synchronous verification processing result of the service access process determines the service key information allocated to the service access process; the sending module 4554 is used to send the service key information to the service access process, so as to perform communication with the service based on the service key information. Encrypted service communication between access processes; the connection control module 4555 is configured to control the communication connection with the service access process for carrying encrypted service communication according to the asynchronous verification processing result of the service access process.
  • the verification module 4552 is further configured to: take the matching result between the process path of the service access process and the set security directory as the first verification processing result; The verification process is performed to obtain a second verification process result; according to the first verification process result and the second verification process result, the synchronous verification process result for the service access process is determined.
  • the verification module 4552 is further configured to, according to whether the signature information includes the result of the digital signature, the verification processing result of the validity of the digital signature, the matching result between the signer of the digital signature and the blacklist of signers, and the signature At least one of the matching results between the certificate information in the information and the certificate information blacklist determines the second verification processing result.
  • the verification module 4552 is further configured to: determine the digital signature in the signature information and the decryption key corresponding to the digital signature; perform decryption processing on the digital signature according to the decryption key to obtain the process of the service access process
  • Validity verification processing result is further configured to: determine the digital signature in the signature information and the decryption key corresponding to the digital signature; perform decryption processing on the digital signature according to the decryption key to obtain the process of the service access process
  • the first hash result of the file the process file of the service access process is hashed to obtain the second hash result
  • the matching result between the first hash result and the second hash result is used as the digital signature.
  • the authentication request includes a public key in an asymmetric key pair generated by the service access process; wherein the asymmetric key pair includes a public key and a private key corresponding to the public key; the sending module 4554, further Used for: encrypting the service key information according to the public key; sending the encrypted service key information to the service access process, so that the service access process decrypts the encrypted service key information according to the private key .
  • the service key information includes a key identifier and a symmetric key
  • the service communication device 455 further includes: a service receiving module, configured to receive a service request sent by the service access process; wherein the service request includes the key identifier , and the request data encrypted by the symmetric key; the query module is used to query the symmetric key corresponding to the key identifier in the service request in the allocated symmetric key; the decryption module is used to query the symmetric key according to the The symmetric key is used to decrypt the encrypted request data in the service request; the response module is used to respond to the request data obtained by the decryption processing to obtain the response data; the encrypted sending module is used to analyze the response data according to the public key Perform encryption processing, and send the encrypted response data to the service access process, so that the service access process decrypts the encrypted response data according to the private key.
  • the service request further includes a timestamp and first verification information; wherein, the first verification information is the service access process pair key identifier, symmetric key, timestamp, and encrypted data using the symmetric key.
  • the request data is obtained by hashing; the response module is also used to: perform hashing on the key identifier, the queried symmetric key, the timestamp, and the encrypted request data to obtain the second verification information;
  • a response processing is performed on the request data obtained by the decryption processing.
  • the service communication device 455 further includes: an expiration processing module, configured to send expiration information to the service access process when the queried use parameter of the symmetric key meets the expiration parameter condition, so as to enable the service access The process resends the authentication request when receiving the expired information; wherein the use parameter includes at least one of the number of times of use and the duration of use.
  • the authentication request includes an authentication request address; the determining module 4553 is further configured to perform any one of the following processing: assign different service key information to authentication request addresses sent by different service access processes, Different authentication request addresses sent by the same service access process are assigned different service key information; different authentication request addresses sent by different service access processes are assigned different service key information, and different authentication request addresses sent by the same service access process
  • assign different service key information is allocated to the authorization request address; the same service key information is allocated to the authentication request addresses sent by different service access processes, and the same service key is allocated to different authentication request addresses sent by the same service access process. information.
  • the verification module 4552 is further configured to: periodically match the process information of the service access process with the process information blacklist, and use the obtained matching result as the asynchronous verification processing result of the service access process .
  • the determining module 4553 is further configured to: when the result of the synchronous verification processing on the service access process is that the verification is successful, determine the service key information allocated to the service access process; When the result of the synchronous verification processing is verification failure, perform any one of the following processing: notify the service access process to resend the authentication request; disconnect the communication connection with the service access process for transmitting the authentication request; interrupt the service access process.
  • Asynchronous validation processing for incoming processes is further configured to: when the result of the synchronous verification processing on the service access process is that the verification is successful, determine the service key information allocated to the service access process; When the result of the synchronous verification processing is verification failure, perform any one of the following processing: notify the service access process to resend the authentication request; disconnect the communication connection with the service access process for transmitting the authentication request; interrupt the service access process.
  • Asynchronous validation processing for incoming processes are further configured to: when the result of the synchronous verification processing on the service access process is that the verification is successful, determine the service key information allocated to the service access process;
  • connection control module 4555 is further configured to: when the result of the asynchronous verification processing on the service access process is that the verification is successful, maintain the communication connection with the service access process for carrying encrypted service communication; when When the asynchronous verification processing result of the service access process is that the verification fails, the communication connection with the service access process for carrying the encrypted service communication is disconnected.
  • the service communication device 455 further includes: an encrypted communication module, configured to: in the process of encrypting the service communication, perform the following processing: receive a credential request sent by the service access process; wherein, the credential request is a service access Sent by the process when it intercepts the service request of the application process, and the destination address of the service request is the address of the service server; performs synchronous verification processing on the application process; determines the business credentials allocated to the application process according to the synchronous verification processing result of the application process and gateway address, and send the service credential and gateway address to the service access process, so that the service access process sends the service credential and service request to the service gateway corresponding to the gateway address;
  • the voucher is verified, and when the verification processing result of the business voucher is that the verification is successful, the received business request is sent to the business server; the business server is used for responding to the request data in the received business request.
  • the encrypted communication module is further configured to: determine the user account in the logged-in state in the device where the application process is located, and obtain process information of the trusted application process corresponding to the user account and accessible service servers corresponding to the user account address; use the matching result between the process information of the application process and the process information of the trusted application process as the third verification processing result; compare the address of the service server requested by the service request and the address of the accessible service server The matching result is taken as the fourth verification processing result; the device information of the device where the application process is located is obtained, and the matching result between the device information and the device security condition is taken as the fifth verification processing result; according to the third verification processing result, the fourth verification processing result The verification processing result and the fifth verification processing result are used to determine the synchronization verification processing result for the application process.
  • the encrypted communication module is further configured to: periodically match the process information of the application process with the process information blacklist, and use the obtained matching result as an asynchronous verification processing result for the application process;
  • the asynchronous verification processing result of the control and the service access process is used to carry the communication connection of encrypted service communication.
  • Embodiments of the present application provide a computer program product or computer program, where the computer program product or computer program includes computer instructions (executable instructions), and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the service communication method described above in the embodiment of the present application
  • the embodiments of the present application provide a computer-readable storage medium storing executable instructions, wherein the executable instructions are stored, and when the executable instructions are executed by a processor, the processor will cause the processor to execute the method provided by the embodiments of the present application, for example , the service communication method shown in FIG. 4A , FIG. 4B , FIG. 4C , FIG. 4D and FIG. 4E .
  • the computer-readable storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; it may also include one or any combination of the foregoing memories Various equipment.
  • executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and which Deployment may be in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • executable instructions may, but do not necessarily correspond to files in a file system, may be stored as part of a file that holds other programs or data, for example, a Hyper Text Markup Language (HTML, Hyper Text Markup Language) document
  • HTML Hyper Text Markup Language
  • One or more scripts in stored in a single file dedicated to the program in question, or in multiple cooperating files (eg, files that store one or more modules, subroutines, or code sections).
  • executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one site, or alternatively, distributed across multiple sites and interconnected by a communication network execute on.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种业务通信方法、系统、装置、电子设备、计算机可读存储介质及计算机程序产品；方法包括：接收业务接入进程发送的鉴权请求；对业务接入进程进行同步验证处理，对业务接入进程进行异步验证处理；根据对业务接入进程的同步验证处理结果，确定为业务接入进程分配的业务密钥信息；将业务密钥信息发送至业务接入进程，以基于业务密钥信息进行与业务接入进程之间的加密业务通信；根据对业务接入进程的异步验证处理结果，控制与业务接入进程之间用于承载加密业务通信的通信连接。

Description

业务通信方法、系统、装置及电子设备
相关申请的交叉引用
本申请基于申请号为202011222173.X、申请日为2020年11月05日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及通信技术，尤其涉及一种业务通信方法、系统、装置、电子设备、计算机可读存储介质及计算机程序产品。
背景技术
在业务场景中，常常会出现接口调用的情况，例如终端设备的某个进程去调用该终端设备的另一个进程的接口，又例如终端设备的进程去调用服务器的进程的接口。接口调用的目的是实现业务通信，例如发送或者请求特定的数据等。
在相关技术提供的方案中，对于业务接入进程(即调用方进程)的调用，通常是由业务接入进程来约定一个固定的密钥，并基于该密钥来进行后续的加密业务通信。但是，该密钥容易被恶意进程利用，导致业务通信的安全性不足，无法对业务进行有效保障。
发明内容
本申请实施例提供一种业务通信方法，包括：
接收业务接入进程发送的鉴权请求；
对所述业务接入进程进行同步验证处理，对所述业务接入进程进行异步验证处理；
根据对所述业务接入进程的同步验证处理结果，确定为所述业务接入进程分配的业务密钥信息；
将所述业务密钥信息发送至所述业务接入进程，以基于所述业务密钥信息进行与所述业务接入进程之间的加密业务通信；
根据对所述业务接入进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
本申请实施例提供一种业务通信系统，包括业务接入客户端、安全客户端及安全服务器；其中，所述业务接入客户端运行有业务接入进程；
所述安全客户端，用于：
接收所述业务接入进程发送的鉴权请求；
对所述业务接入进程进行同步验证处理，通知所述安全服务器对所述业务接入进程进行异步验证处理；
根据对所述业务接入进程的同步验证处理结果，确定为所述业务接入进程分配的业务密钥信息；
将所述业务密钥信息发送至所述业务接入进程，以基于所述业务密钥信息进行与所述业务接入进程之间的加密业务通信；
根据所述安全服务器对所述业务接入进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
本申请实施例提供一种业务通信装置，包括：
接收模块，配置为接收业务接入进程发送的鉴权请求；
验证模块，配置为对所述业务接入进程进行同步验证处理，对所述业务接入进程进行异步验证处理；
确定模块，配置为根据对所述业务接入进程的同步验证处理结果，确定为所述业务接入进程分配的业务密钥信息；
发送模块，配置为将所述业务密钥信息发送至所述业务接入进程，以基于所述业务密钥信息进行与所述业务接入进程之间的加密业务通信；
连接控制模块，配置为根据对所述业务接入进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
本申请实施例提供一种电子设备，包括：
存储器，用于存储可执行指令；
处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的业务通信方法。
本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的业务通信方法。
本申请实施例提供一种计算机程序产品，包括可执行指令，所述可执行指令被处理器执行时实现本申请实施例提供的业务通信方法。
附图说明
图1是本申请实施例提供的业务通信系统的一个架构示意图；
图2是本申请实施例提供的结合区块链网络的业务通信系统的一个架构示意图；
图3是本申请实施例提供的终端设备的一个架构示意图；
图4A是本申请实施例提供的业务通信方法的一个流程示意图；
图4B是本申请实施例提供的业务通信方法的一个流程示意图；
图4C是本申请实施例提供的业务通信方法的一个流程示意图；
图4D是本申请实施例提供的业务通信方法的一个流程示意图；
图4E是本申请实施例提供的业务通信方法的一个流程示意图；
图5是本申请实施例提供的安全管理端的策略管理界面的一个示意图；
图6是本申请实施例提供的进程信息的一个示意图；
图7是本申请实施例提供的安全管理端的零信任网关界面的一个示意图；
图8是本申请实施例提供的零信任网关的配置界面的一个示意图；
图9是本申请实施例提供的安全管理端的业务系统界面的一个示意图；
图10是本申请实施例提供的业务系统的配置界面的一个示意图；
图11是本申请实施例提供的业务系统的配置界面的一个示意图；
图12是本申请实施例提供的业务系统的配置界面的一个示意图；
图13是本申请实施例提供的安全管理端的策略管理界面的一个示意图；
图14是本申请实施例提供的安全客户端界面的一个示意图；
图15是本申请实施例提供的安全客户端界面的一个示意图；
图16是本申请实施例提供的安全客户端界面的一个示意图；
图17是本申请实施例提供的访问过程的一个示意图；
图18是本申请实施例提供的访问过程的一个示意图；
图19是本申请实施例提供的安全服务器级联部署的一个示意图；
图20是本申请实施例提供的异步验证处理的一个示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。在以下的描述中，所涉及的术语“多个”是指至少两个。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本 申请实施例中涉及的名词和术语适用于如下的解释。
1)业务接入进程：指作为调用方的进程，本申请实施例对业务接入进程的类型不做限定，例如业务接入进程可以是应用进程(如某个会议应用的进程)，也可以是专门用于对应用进程的业务请求进行代理的进程。
2)同步(Synchronous)验证处理：需要等待同步验证处理完成，即得到同步验证处理结果时，才能执行其他的步骤。在本申请实施例中，涉及对业务接入进程的同步验证处理、以及对应用进程的同步验证处理，举例来说，只有在得到对业务接入进程的同步验证处理结果时，才执行确定为业务接入进程分配的业务密钥信息的步骤。
3)异步(Asynchronous)验证处理：在异步验证处理的期间，可以执行其他的步骤。在本申请实施例中，涉及对业务接入进程的异步验证处理、以及对应用进程的同步验证处理，举例来说，在对业务接入进程进行异步验证处理期间，可以与业务接入进程进行加密业务通信。
4)业务密钥信息：用于进行加密业务通信，业务密钥信息至少包括密钥，还可以包括密钥标识等信息。
5)签名信息：泛指与数字签名(Digital Signature)相关的信息，例如可以包括数字签名本身以及证书信息等。
6)哈希(Hash)：将任意长度的输入通过散列算法(也称哈希处理)变换成固定长度的输出，该输出即为Hash值(也称Hash结果)，从而，可以通过得到的Hash值来对输入进行标识。散列算法包括信息摘要(Message-Digest，MD)算法及安全散列算法(Secure Hash Algorithm，SHA)等。
7)对称密钥：指发送数据的一方和接收数据的一方使用相同的密钥进行加密处理和解密处理，本申请实施例对对称密钥的生成方式不做限定，例如可通过高级加密标准(Advanced Encryption Standard，AES)算法来生成对称密钥。
8)非对称密钥对：包括公钥及私钥，发送数据的一方通过公钥对数据进行加密处理，接收数据的一方通过私钥对加密后的数据进行解密处理，或者，也可以用私钥对数据进行加密处理，用公钥对加密后的数据进行解密处理。本申请实施例对生成非对称密钥对的方式不做限定，例如可通过RSA算法进行生成。
9)业务网关：用于将接收到的业务请求转发给相应的业务服务器，以实现对业务请求的代理。在本申请实施例中，业务网关可以通过软件形式实现，也可以通过硬件形式实现。
10)业务服务器：用于提供业务资源的服务器，例如，对于会议业务来说，会议应用的后台服务器即为业务服务器，用于给会议应用的联网运行提供数据支持。
11)区块链(Blockchain)：由区块(Block)形成的加密的、链式的交易的存储结构。
12)区块链网络(Blockchain Network)：通过共识的方式将新区块纳入区块链的一系列的节点的集合。
本申请实施例提供一种业务通信方法、系统、装置、电子设备及计算机可读存储介质，能够提升业务通信的安全性。下面说明本申请实施例提供的电子设备的示例性应用，本申请实施例提供的电子设备可以实施为终端设备，也可以实施为服务器。
参见图1，图1是本申请实施例提供的业务通信系统100的一个架构示意图，终端设备400通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。其中，终端设备400运行有业务接入客户端。
在一些实施例中，以电子设备是终端设备为例，本申请实施例提供的业务通信方法可以由终端设备实现。例如，终端设备400中的业务接入客户端，可以通过运行的业务接入进程，调用终端设备400中的应用客户端的应用进程的接口，即应用客户端会接收到业务接入进程发送的鉴权请求。此时，应用客户端可以对业务接入进程进行同步验证处理及异步验证处理，根据同步验证处理结果确定分配的业务密钥信息，并基于业务密钥信息进行与业务接入进程之间的加密业务通信，应用客户端在得到异步验证处理结果时，还可以根据异步验证处理结果控制与业务接入进程之间的通信连接。基于建立的加密业务通信，业务接入进程可实现多种业务目的，对此不做限定。
举例来说，业务接入进程可以是即时通信应用客户端(以下简称为客户端A)的应用进程，所调用的是文件管理客户端(以下简称为客户端B)的应用进程，当客户端A中的某条文件链接(如分享在会话界面中的文件链接)被用户触发时，客户端A的应用进程会调用客户端B的应用进程的接口，以与客户端B的应用进程建立加密业务通信。在已建立加密业务通信的基础上，客户端A的应用进程可以向客户端B的应用进程发送包括该文件链接的业务请求，客户端B的应用进程从所管理的文件中查询该文件链接对应的文件(即响应数据)，并将查询到的文件发送至客户端A的应用 进程，以在客户端A的界面中进行显示。
在一些实施例中，以电子设备是服务器为例，本申请实施例提供的业务通信方法可以由服务器实现。例如，终端设备400中的业务接入客户端可以通过运行的业务接入进程调用服务器200中运行的进程的接口，即服务器200会接收到业务接入进程发送的鉴权请求。此时，服务器200可以对业务接入进程进行同步验证处理及异步验证处理，以建立与业务接入进程之间的加密业务通信。举例来说，业务接入客户端可以是某应用的客户端，服务器200是该应用的后台服务器，业务接入客户端可以通过业务接入进程与服务器200中的进程建立加密业务通信，从而向服务器200中的进程请求应用数据(即响应数据)。
在一些实施例中，本申请实施例提供的业务通信方法也可以由终端设备及服务器协同实现。例如，终端设备400中运行有安全客户端，服务器200为安全服务器。当安全客户端接收到业务接入进程发送的鉴权请求时，安全客户端对业务接入进程进行同步验证处理，并通知安全服务器对业务接入进程进行异步验证处理，以与业务接入进程建立加密业务通信。
在一些实施例中，终端设备400或服务器200可以通过运行计算机程序来实现本申请实施例提供的业务通信方法，例如，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(Native)应用程序(APP，Application)，即需要在操作系统中安装才能运行的程序；也可以是小程序，即只需要下载到浏览器环境中就可以运行的程序；还可以是能够嵌入至任意APP中的小程序，其中，该小程序组件可以由用户控制运行或关闭。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。
在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，其中，云服务可以是异步验证服务，供终端设备400进行调用。终端设备400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能电视、智能音箱、智能手表等，但并不局限于此。终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。
参见图2，图2是本申请实施例提供的结合区块链网络的业务通信系统110的一个架构示意图，包括区块链网络500(区块链网络500通常包括多个节点，这里示例性地示出了节点510)、认证中心600及电子设备700，电子设备700可以是服务器(例如图1所示的服务器200)或者终端设备(例如图1所示的终端设备400)，根据实际应用场景而定。其中，认证中心600用于向电子设备700下发数字证书。
电子设备700可接入区块链网络500，成为区块链网络500的客户端节点，进而查询存储于区块链中的数据，其中，区块链可用于存储业务通信过程中的各种信息。例如，电子设备700可以查询存储于区块链中的黑名单，以根据黑名单对业务接入进程进行同步验证处理以及异步验证处理中的至少之一。
以本申请实施例提供的电子设备是终端设备为例说明，可以理解的，对于电子设备是服务器的情况，图3中示出的结构中的部分(例如用户接口、呈现模块和输入处理模块)可以缺省。参见图3，图3是本申请实施例提供的终端设备400的结构示意图，图3所示的终端设备400包括：至少一个处理器410、存储器450、至少一个网络接口420和用户接口430。终端400中的各个组件通过总线系统440耦合在一起。可理解，总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统440。
处理器410可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
用户接口430包括使得能够呈现媒体内容的一个或多个输出装置431，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口430还包括一个或多个输入装置432，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
存储器450可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器450可选地包括在物理位置上远离处理器410的一个或多个存储设备。
存储器450包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非 易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器450旨在包括任意适合类型的存储器。
在一些实施例中，存储器450能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
操作系统451，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
网络通信模块452，用于经由一个或多个(有线或无线)网络接口420到达其他计算设备，示例性的网络接口420包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；
呈现模块453，用于经由一个或多个与用户接口430相关联的输出装置431(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；
输入处理模块454，用于对一个或多个来自一个或多个输入装置432之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
在一些实施例中，本申请实施例提供的业务通信装置可以采用软件方式实现，图3示出了存储在存储器450中的业务通信装置455，其可以是程序和插件等形式的软件，包括以下软件模块：接收模块4551、验证模块4552、确定模块4553、发送模块4554及连接控制模块4555，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
将结合本申请实施例提供的电子设备的示例性应用和实施，说明本申请实施例提供的业务通信方法。
参见图4A，图4A是本申请实施例提供的业务通信方法的一个流程示意图，将结合图4A示出的步骤进行说明。
在步骤101中，接收业务接入进程发送的鉴权请求。
这里，电子设备接收业务接入进程发送的鉴权请求，例如，可以在电子设备中预先约定一个鉴权接口(如某个特定的端口)，当电子设备接收到业务接入进程对该鉴权接口的调用请求时，将该调用请求作为鉴权请求。其中，业务接入进程可以是某个应用客户端的应用进程，也可以用于对应用客户端进行代理的进程，将在后文进行阐述。值得说明的是，本申请实施例对业务的类型不做限定，例如可以是即时通信业务或视频业务等。
在步骤102中，对业务接入进程进行同步验证处理，对业务接入进程进行异步验证处理。
这里，针对业务接入进程，进行同步验证处理及异步验证处理，以验证其合法性。本申请实施例对同步验证处理及异步验证处理的执行顺序不做限定，例如可以同时执行，又例如，也可以在同步验证处理结果为验证成功时，再执行异步验证处理。
本申请实施例对同步验证处理及异步验证处理的处理方式同样不做限定，例如，同步验证处理及异步验证处理的验证对象可以相同，验证对象如业务接入进程的进程信息，两者之间的区别在于同步验证处理只执行一次，而异步验证处理是周期性地执行多次。
在步骤103中，根据对业务接入进程的同步验证处理结果，确定为业务接入进程分配的业务密钥信息。
例如，可以根据对业务接入进程的同步验证处理结果，判断是否确定为业务接入进程分配的业务密钥信息。其中，业务密钥信息至少包括密钥，还可以包括密钥标识等。业务密钥信息可以是针对业务接入进程预先分配好的，也可以是实时分配的，对此不做限定。
值得说明的是，为了进一步提升安全性，电子设备还可以周期性地对分配给业务接入进程的业务密钥信息进行更新，并对更新前的业务密钥信息进行失效处理(也称无效处理)，以触发业务接入进程重新发送鉴权请求，从而获取更新后的业务密钥信息。
在一些实施例中，鉴权请求包括鉴权请求地址；可以通过这样的方式来实现上述的确定为业务接入进程分配的业务密钥信息：针对不同业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，针对同一业务接入进程发送的不同鉴权请求地址分配不同的业务密钥信息；针对不同业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，针对同一业务接入进程发送的不同鉴权请求地址分配相同的业务密钥信息；针对不同业务接入进程发送的鉴权请求地址分配相同的业务密钥信息，针对同一业务接入进程发送的不同鉴权请求地址，分配相同的业务密钥信息。
这里，电子设备可以预先约定多个鉴权请求地址，以便业务接入进程根据鉴权请求地址发送鉴 权请求。电子设备在确定为业务接入进程分配的业务密钥信息时，可以根据业务接入进程本身以及鉴权请求地址这两个因素，实现多种分配方案。
举例来说，第一种分配方案是，针对不同业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，并针对同一业务接入进程发送的不同鉴权请求地址分配不同的业务密钥信息。该种分配方案的安全性相较于其他分配方案来说更高，同时分配的业务密钥信息的数量也较多，电子设备需要耗费更多的存储资源来存储分配的业务密钥信息。
第二种分配方案是，针对不同业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，针对同一业务接入进程发送的不同鉴权请求地址分配相同的业务密钥信息，即仅区分业务接入进程。较之第一种分配方案，第二种分配方案需要耗费的存储资源更少。
第三种分配方案是，不区分业务接入进程及鉴权请求地址，即分配统一的业务密钥信息，该种方案需要耗费的存储资源最少。
根据实际应用场景中的需求，可以选用上述三种分配方案中的任意一个，例如某企业对安全性需求最高，则可以选用上述的第一种分配方案。通过上述方式，提升了分配业务密钥信息的灵活性。
在一些实施例中，可以通过这样的方式来实现上述的根据对业务接入进程的同步验证处理结果，确定为业务接入进程分配的业务密钥信息：当对业务接入进程的同步验证处理结果为验证成功时，确定为业务接入进程分配的业务密钥信息。
这里，当对业务接入进程的同步验证处理结果为验证成功时，确定为业务接入进程分配的业务密钥信息；当对业务接入进程的同步验证处理结果为验证失败时，证明业务接入进程不合法，则拒绝为业务接入进程分配业务密钥信息，还可以断开与业务接入进程之间的通信连接。即，对业务接入进程的同步验证处理，实质上可以看作是对业务接入进程是否合法的初步验证。
在一些实施例中，当对业务接入进程的同步验证处理结果为验证失败时，可以向业务接入进程发送错误信息，以通知业务接入进程重新发送鉴权请求，或者与业务接入进程断开通信连接。另外，若在得到对业务接入进程的同步验证处理结果为验证失败时，正在执行对业务接入进程的异步验证处理，则可以中断对业务接入进程的异步验证处理，以节省计算资源。
在步骤104中，将业务密钥信息发送至业务接入进程，以基于业务密钥信息进行与业务接入进程之间的加密业务通信。
电子设备将为业务接入进程分配的业务密钥信息发送至业务接入进程，如此，便可基于业务密钥信息进行与业务接入进程之间的加密业务通信。例如，业务密钥信息包括一个对称密钥，则业务接入进程可以根据对称密钥对数据进行加密处理，并将加密后的数据发送至电子设备，以使电子设备根据对称密钥对接收到的加密后的数据进行解密处理；同样地，电子设备可以根据对称密钥对数据进行加密处理，并将加密后的数据发送至业务接入进程，以使业务接入进程根据对称密钥对加密后的数据进行解密处理。
在步骤105中，根据对业务接入进程的异步验证处理结果，控制与业务接入进程之间用于承载加密业务通信的通信连接。
这里，在得到对业务接入进程的异步验证处理结果时，根据该异步验证处理结果控制与业务接入进程之间的用于承载加密业务通信的通信连接。本申请实施例对通信连接的类型不做限定，例如可以是套接字(Socket)连接。
在一些实施例中，可以通过这样的方式来实现上述的根据对业务接入进程的异步验证处理结果，控制与业务接入进程之间用于承载加密业务通信的通信连接：当对业务接入进程的异步验证处理结果为验证成功时，维持与业务接入进程之间用于承载加密业务通信的通信连接；当对业务接入进程的异步验证处理结果为验证失败时，断开与业务接入进程之间用于承载加密业务通信的通信连接。
这里，当对业务接入进程的异步验证处理结果为验证成功时，证明业务接入进程合法，则继续维持与业务接入进程之间用于承载加密业务通信的通信连接；当对业务接入进程的异步验证处理结果为验证失败时，证明业务接入进程不合法，则断开与业务接入进程之间用于承载加密业务通信的通信连接，以避免对业务造成损害(例如业务数据被窃取)。即，对业务接入进程的异步验证处理，实质上可以看作是对业务接入进程是否合法的再度验证。
如图4A所示，本申请实施例通过同步验证处理和异步验证处理相结合的方式，能够对业务接入进程的合法性进行有效验证；同时，通过电子设备下发的业务密钥信息进行加密业务通信，能够降低业务密钥信息被恶意进程窃取并利用的概率，提升业务通信的安全性。
在一些实施例中，参见图4B，图4B是本申请实施例提供的业务通信方法的一个流程示意图，图4A示出的步骤102可以通过步骤201至步骤204实现，将结合各步骤进行说明。
在步骤201中，将业务接入进程的进程路径与设定的安全目录之间的匹配结果，作为第一验证处理结果。
在本申请实施例中，对业务接入进程的同步验证处理可以包括对进程路径的验证处理以及对签名信息的验证处理。对于前者，可以根据实际应用场景预先设定安全目录，并将业务接入进程的进程路径与安全目录进行匹配处理，并将得到的匹配结果作为第一验证处理结果。其中，当业务接入进程的进程路径位于安全目录中时，确定进程路径与安全目录之间的匹配结果为成功，即第一验证处理结果为验证成功；当业务接入进程的进程路径并未位于安全目录中时，证明业务接入进程不合法，确定进程路径与安全目录之间的匹配结果为失败，即第一验证处理结果为验证失败。
在步骤202中，对业务接入进程的签名信息进行验证处理，得到第二验证处理结果。
这里，签名信息泛指与业务接入进程的数字签名相关的信息，可以根据实际应用场景中的安全性需求来确定需要进行验证处理的签名信息的具体内容。对业务接入进程的签名信息进行验证处理后，得到第二验证处理结果。
在一些实施例中，可以通过这样的方式来实现上述的对业务接入进程的签名信息进行验证处理，得到第二验证处理结果：根据签名信息是否包括数字签名的结果、数字签名的有效性验证处理结果、数字签名的签名方与签名方黑名单之间的匹配结果、以及签名信息中的证书信息与证书信息黑名单之间的匹配结果中的至少之一，确定第二验证处理结果。
本申请实施例提供了对业务接入进程的签名信息进行验证处理的四种影响因素，以下进行分别说明。
1)签名信息是否包括数字签名的结果。例如，当签名信息包括数字签名时，确定第二验证处理结果为验证成功；当签名信息未包括数字签名时，确定第二验证处理结果为验证失败。
2)对签名信息中的数字签名进行有效性验证处理得到的有效性验证处理结果。例如，可以直接将有效性验证处理结果作为第二验证处理结果，有效性验证处理的方式在后文进行阐述。
3)签名信息中的数字签名的签名方与签名方黑名单之间的匹配结果。例如，签名方黑名单包括有多个恶意签名方，当业务接入进程的数字签名的签名方与签名方黑名单中的任意一个恶意签名方相同，即匹配成功时，确定第二验证处理结果为验证失败；当业务接入进程的数字签名的签名方与签名方黑名单中的所有恶意签名方均不同，即匹配失败时，确定第二验证处理结果为验证成功。
4)签名信息中的证书信息与证书信息黑名单之间的匹配结果。其中，证书指的是数字证书(Digital Certificate)。例如，证书信息黑名单包括有多个恶意证书信息，当业务接入进程的证书信息与证书信息黑名单中的任意一个恶意证书信息相同，即匹配成功时，确定第二验证处理结果为验证失败；当业务接入进程的证书信息与证书信息黑名单中的所有恶意证书信息均不同，即匹配失败时，确定第二验证处理结果为验证成功。这里，证书信息可以是证书链(Certificate Chain)信息，例如包括根证书信息、中级证书信息及签名证书信息，证书信息的格式根据业务接入进程实际的证书签发情况而定。
上述的1)至4)的影响因素的验证力度递增，验证的时长同样递增，可以综合实际应用场景中的安全性需求和效率需求，选用上述的至少一种影响因素进行验证处理。以选用上述的第1)种和第2)种方式为例进行说明，则当签名信息包括数字签名、且对数字签名的有效性验证处理结果为验证成功时，才确定第二验证处理结果为验证成功；当签名信息未包括数字签名、或者对数字签名的有效性验证处理结果为验证失败时，确定第二验证处理结果为验证失败。通过上述方式，提升了对业务接入进程的签名信息进行验证处理的灵活性。
在一些实施例中，还包括：确定签名信息中的数字签名、以及与数字签名对应的解密密钥；根据解密密钥对数字签名进行解密处理，得到业务接入进程的进程文件的第一哈希结果；对业务接入进程的进程文件进行哈希处理，得到第二哈希结果；将第一哈希结果与第二哈希结果之间的匹配结果，作为数字签名的有效性验证处理结果。
这里，提供了对数字签名进行有效性验证处理的一种示例。数字签名可以是对业务接入进程的进程文件进行哈希处理，再对得到的第一哈希结果进行加密处理得到，其中，进程文件可以是指业务接入进程的可移植且可执行(Portable Executable，PE)文件。因此，在对数字签名进行有效性验证处理时，可以首先确定签名信息中的数字签名、以及与数字签名对应的解密密钥，其中，解密密钥可以从业务接入进程的证书信息中解析得到，如从签名证书中解析得到。
然后，根据解密密钥对数字签名进行解密处理，得到第一哈希结果，同时，对业务接入进程的进程文件进行哈希处理，得到第二哈希结果，这里的哈希处理所用的算法同样可以从证书信息中得到，如此，可以保证计算第一哈希结果所用的算法与计算第二哈希结果所用的算法一致。最后，将 第一哈希结果与第二哈希结果之间的匹配结果，作为有效性验证处理结果，例如，当第一哈希结果与第二哈希结果相同，即匹配成功时，确定有效性验证处理结果为验证成功；当第一哈希结果与第二哈希结果不同时，证明进程文件经过了篡改，则确定有效性验证处理结果为验证失败。当然，上述方式仅仅是有效性验证处理的一种示例，并不构成对有效性验证处理的限定，例如还可以通过调用特定的应用程序接口(Application Programming Interface，API)，如WinVerifyTrust来实现有效性验证处理。
在步骤203中，根据第一验证处理结果及第二验证处理结果，确定对业务接入进程的同步验证处理结果。
例如，当第一验证处理结果及第二验证处理结果均为验证成功时，确定对业务接入进程的同步验证处理结果为验证成功；当第一验证处理结果及第二验证处理结果中的任意一个为验证失败时，确定对业务接入进程的同步验证处理结果为验证失败。如此，结合进程路径和签名信息两个方面来进行对业务接入进程的同步验证处理，能够有效提升得到的同步验证处理结果的准确性。
在步骤204中，周期性地将业务接入进程的进程信息与进程信息黑名单进行匹配，并将得到的匹配结果作为对业务接入进程的异步验证处理结果。
这里，进程信息可以包括进程文件的MD5值、进程文件的Hash值、进程路径以及证书信息中的至少之一，可以根据实际应用场景进行设定。进程信息黑名单则包括多个恶意进程的进程信息，进程信息黑名单可以是随着时间推移而不断更新的，类似于病毒库。在对业务接入进程进行异步验证处理的过程中，可以周期性地将业务接入进程的进程信息与进程信息黑名单(例如当前最新的进程信息黑名单)进行匹配，当业务接入进程的进程信息与进程信息黑名单中的任意一个进程信息相同，即匹配成功时，确定对业务接入进程的异步验证处理结果为验证失败；当业务接入进程的进程信息与进程信息黑名单中的所有进程信息均不同，即匹配失败时，确定对业务接入进程的异步验证处理结果为验证成功。
值得说明的是，在进程信息包括多种类型的内容(如MD5值、Hash值等)的情况下，可以设定当进程信息A包括的某个内容(如MD5值)与进程信息B包括的同类型的内容相同时，确定进程信息A与进程信息B相同，从而加强安全管控的效率。
另外，可以周期性地将业务接入进程的进程信息发送至特定的云服务，以使云服务将业务接入进程的进程信息与进程信息黑名单进行匹配，从而减轻本地的处理压力。
如图4B所示，本申请实施例提供了对业务接入进程进行同步验证处理及异步验证处理的一些示例，能够有效提升得到的同步验证处理结果及异步验证处理结果的准确性，从而增强后续进行业务通信的安全性。
在一些实施例中，参见图4C，图4C是本申请实施例提供的业务通信方法的一个流程示意图，图4A示出的步骤104可以通过步骤301至步骤307实现，将结合各步骤进行说明。
在步骤301中，根据鉴权请求中的公钥对业务密钥信息进行加密处理。
为了提升传输业务密钥信息过程中的安全性和保密性，在本申请实施例中，可以在步骤101之前，由业务接入进程生成非对称密钥对，并将非对称密钥对中的公钥添加至鉴权请求中，其中，非对称密钥对包括公钥以及与公钥配套的私钥。
电子设备在确定出为业务接入进程分配的业务密钥信息后，可以利用业务接入进程发送的公钥对业务密钥信息进行加密处理。
在步骤302中，将加密后的业务密钥信息发送至业务接入进程，以使业务接入进程根据私钥对加密后的业务密钥信息进行解密处理。
这里，电子设备将加密后的业务密钥信息发送至业务接入进程，以使业务接入进程根据存储的私钥对加密后的业务密钥信息进行解密处理。由于除业务接入进程外的其他进程未持有私钥，因此，就算加密后的业务密钥信息被其他进程窃取，其他进程也无法得到实际的业务密钥信息。通过上述方式，能够提升业务密钥信息的保密性。
在步骤303中，接收业务接入进程发送的业务请求；其中，业务请求包括密钥标识、以及利用对称密钥加密后的请求数据。
这里，以业务密钥信息包括密钥标识及对称密钥为例，说明加密业务通信的过程。业务接入进程在接收到业务密钥信息后，可以基于业务密钥信息生成调用请求，该调用请求包括密钥标识、以及利用对称密钥加密后的请求数据，这里对请求数据的类型不做限定，可以根据实际应用场景确定。
值得说明的是，可以在电子设备中预先约定一个业务接口(如某个特定的端口)，当电子设备接收到业务接入进程对该业务接口的调用请求时，将该调用请求作为业务请求。其中，可以为多种业 务设定不同的业务接口，也可以设定统一的业务接口。
在步骤304中，在已分配的对称密钥中，查询与业务请求中的密钥标识对应的对称密钥。
电子设备在分配业务密钥信息的同时，将业务密钥信息进行存储，其中每个业务密钥信息包括一个密钥标识以及与密钥标识对应的对称密钥。电子设备在接收到业务接入进程发送的业务请求时，在已分配的所有对称密钥中，查询与业务请求中的密钥标识对应的对称密钥。若未查询到与密钥标识对应的对称密钥，则可以发送相应的错误信息给业务接入进程，以使业务接入进程在接收到错误信息时重新发送业务请求。
在一些实施例中，步骤304之后，还包括：当查询到的对称密钥的使用参数满足过期参数条件时，将过期信息发送至业务接入进程，以使业务接入进程在接收到过期信息时重新发送鉴权请求；其中，使用参数包括使用次数以及使用时长中的至少一种。
对于业务密钥信息，可以设定过期参数条件，当某个业务密钥信息的使用参数满足过期参数条件时，电子设备可以对该业务密钥信息进行更新，其中，过期参数条件可以是最大使用次数以及有效使用时长中的至少一种，当然也可以是其他的条件，对此不做限定。
电子设备在根据业务请求中的密钥标识进行查询后，若查询到的对称密钥的使用参数(等同于对称密钥所属的业务密钥信息的使用参数)满足过期参数条件，则将过期信息发送至业务接入进程，以使业务接入进程在接收到过期信息时重新发送鉴权请求，从而请求更新后的业务密钥信息。通过上述方式，能够实现业务密钥信息的动态更新，进一步提升业务通信的安全性。
在步骤305中，根据查询到的对称密钥，对业务请求中的加密后的请求数据进行解密处理。
在步骤306中，对解密处理得到的请求数据进行响应处理，得到响应数据。
这里，可以根据实际的业务策略或者规则对解密处理得到的请求数据进行响应处理，得到响应数据。例如，解密处理得到的请求数据是一个视频链接，则可以获取与该视频链接对应的视频数据，作为响应数据。值得说明的是，进行的响应处理也可以是将解密处理得到的请求数据进行存储，即并非一定要得到响应数据，这里仅以得到响应数据的情况进行示例说明。
在一些实施例中，业务请求还包括时间戳及第一校验信息；其中，第一校验信息是业务接入进程对密钥标识、对称密钥、时间戳、以及利用对称密钥加密后的请求数据进行哈希处理得到的；还可以通过这样的方式实现上述的对解密处理得到的请求数据进行响应处理：对密钥标识、查询到的对称密钥、时间戳、以及加密后的请求数据进行哈希处理，得到第二校验信息；当第一校验信息与第二校验信息之间的匹配结果为匹配成功时，对解密处理得到的请求数据进行响应处理。
这里，业务接入进程可以对密钥标识、对称密钥、当前的时间戳、以及利用对称密钥加密后的请求数据进行哈希处理，得到第一校验信息，并将第一校验信息添加至业务请求中，即业务请求包括密钥标识、利用对称密钥加密后的请求数据、时间戳以及第一校验信息。电子设备在通过业务请求中的密钥标识查询得到相应的对称密钥后，对业务请求中的密钥标识、查询到的对称密钥、业务请求中的时间戳、以及业务请求中的加密后的请求数据进行哈希处理，得到第二校验信息。其中，哈希处理所采用的算法可以预先约定，保证算法统一。
当第一校验信息与第二校验信息相同，即匹配成功时，证明业务请求中的数据未经篡改，此时电子设备对解密处理得到的请求数据进行响应处理；当第一校验信息与第二校验信息不同，即匹配失败时，证明业务请求中的数据经过了篡改，电子设备可以将相应的错误信息发送给业务接入进程，以使业务接入进程在接收到错误信息时重新发送业务请求。值得说明的是，在本申请实施例中，可以先比对第一校验信息与第二校验信息，再根据查询到的对称密钥对业务请求中的加密后的请求数据进行解密处理；也可以先根据查询到的对称密钥对业务请求中的加密后的请求数据进行解密处理，再比对第一校验信息与第二校验信息。通过上述方式，能够准确判断业务请求中的数据是否经过篡改，从而确定是否进行响应处理。
在步骤307中，根据公钥对响应数据进行加密处理，并将加密后的响应数据发送至业务接入进程，以使业务接入进程根据私钥对加密后的响应数据进行解密处理。
电子设备在通过响应处理得到响应数据后，根据业务接入进程发送的公钥对响应数据进行加密处理，并将加密后的响应数据发送至业务接入进程。如此，业务接入进程在接收到加密后的响应数据时，便可根据存储的私钥对其进行解密处理，得到响应数据，完成一次加密业务通信。
如图4C所示，本申请实施例结合业务接入进程生成的非对称密钥对、以及电子设备下发的业务密钥信息进行加密业务通信，能够有效保障业务通信的安全性和隐私性。
在一些实施例中，参见图4D，图4D是本申请实施例提供的业务通信方法的一个流程示意图，图4A示出的步骤104之后，还可以在步骤401中，接收业务接入进程发送的凭证请求；其中，凭 证请求是业务接入进程在拦截到应用进程的业务请求时发送的，业务请求的目的地址为业务服务器的地址。
在本申请实施例中，业务接入进程可以用于拦截应用进程(例如与业务接入进程运行于同一终端设备上的应用进程)发送的业务请求，其中，该业务请求的目的地址为业务服务器的地址，这里的地址可以包括IP地址(或域名)及端口。这里，对拦截业务请求的方式不做限定，例如可以通过特定的虚拟网卡实现拦截。
业务接入进程在拦截到业务请求时，生成凭证请求，该凭证请求的内容可以包括业务请求中的源地址(即应用进程的地址)及目的地址，还可以包括应用进程的进程识别号(Process IDentification，PID)。
在步骤402中，对应用进程进行同步验证处理。
电子设备在接收到业务接入进程发送的凭证请求时，对凭证请求所指向的应用进程进行同步验证处理。本质上来说，凭证请求也是业务接入进程发送的业务请求中的一种，凭证请求所请求的响应数据即为业务凭证。
在一些实施例中，还可以通过这样的方式实现上述的对应用进程进行同步验证处理：确定应用进程所在设备中处于登录态的用户账号，并获取用户账号对应的可信应用进程的进程信息、以及用户账号对应的可访问的业务服务器的地址；将应用进程的进程信息与可信应用进程的进程信息之间的匹配结果，作为第三验证处理结果；将业务请求所请求的业务服务器的地址与可访问的业务服务器的地址之间的匹配结果，作为第四验证处理结果；获取应用进程所在设备的设备信息，并将设备信息与设备安全条件之间的匹配结果，作为第五验证处理结果；根据第三验证处理结果、第四验证处理结果及第五验证处理结果，确定对应用进程的同步验证处理结果。
这里，提供了对应用进程进行同步验证处理的一种示例。首先，可以根据实际应用场景，针对多个用户账号中的每个用户账号，设定用户账号对应的可信应用进程以及可访问的业务服务器，电子设备可以将可信应用进程的进程信息以及可访问的业务服务器的地址存储在本地。
电子设备在接收到业务接入进程发送的凭证请求时，可以根据凭证请求中的PID确定相应的应用进程，确定应用进程所在设备中处于登录态的用户账号，同时获取应用进程所在设备的设备信息。针对处于登录态的用户账号，当应用进程的进程信息与该用户账号对应的任意一个可信应用进程的进程信息相同，即匹配成功时，确定第三验证处理结果为验证成功；当应用进程的进程信息与该用户账号对应的所有可信应用进程的进程信息均不同时，确定第三验证处理结果为验证失败。同样针对处于登录态的用户账号，当凭证请求中的目的地址与该用户账号对应的任意一个可访问的业务服务器的地址相同，即匹配成功时，确定第四验证处理结果为验证成功；当凭证请求中的目的地址与该用户账号对应的所有可访问的业务服务器的地址均不同时，确定第四验证处理结果为验证失败。
此外，还将设备信息与设定的设备安全条件进行匹配，若设备信息符合设备安全条件，即匹配成功，则确定第五验证处理结果为验证成功；否则，确定第五验证处理结果为验证失败。这里，对设备安全条件不做限定，例如可以是设备信息中不包括病毒和系统漏洞。
最后，当第三验证处理结果、第四验证处理结果及第五验证处理结果均为验证成功时，确定对应用进程的同步验证处理结果为验证成功；当第三验证处理结果、第四验证处理结果及第五验证处理结果中的任意一个为验证失败时，确定对应用进程的同步验证处理结果为验证失败。值得说明的是，也可以根据上述的第三验证处理结果、第四验证处理结果及第五验证处理结果中的至少一个，来确定对应用进程的同步验证处理结果，从而提升同步验证处理的效率。通过上述方式，能够提升得到的同步验证处理结果的准确性和有效性。
在一些实施例中，步骤401之后，还包括：周期性地将应用进程的进程信息与进程信息黑名单进行匹配，并将得到的匹配结果作为对应用进程的异步验证处理结果；根据对应用进程的异步验证处理结果，控制与业务接入进程之间用于承载加密业务通信的通信连接。
除了对应用进程进行同步验证处理之外，还可以对应用进程进行异步验证处理。这里，对应用进程进行异步验证处理的过程，与上述对业务接入进程进行异步验证处理的过程类似。在得到对应用进程的异步验证处理结果后，若该异步验证处理结果为验证成功，则维持与业务接入进程之间的通信连接；若该异步验证处理结果为验证失败，则断开与业务接入进程之间的通信连接。
在一些实施例中，在任意步骤之间，还包括：向区块链网络发送查询请求，以查询区块链中存储的黑名单。
本申请实施例也可结合区块链技术实现。在本申请实施例中，区块链可用于存储黑名单，包括但不限于上述的签名方黑名单、证书信息黑名单及进程信息黑名单。下面，以电子设备接入区块链 网络以实现查询黑名单为例，说明区块链网络的示例性应用。
为了便于理解，以图2示出的架构进行说明，电子设备700接入区块链网络500，成为区块链网络500的客户端节点。电子设备700在需要查询黑名单时，将查询请求以交易形式发送至区块链网络500，在交易中指定实现查询操作需要调用的智能合约以及向智能合约传递的参数，交易还携带了电子设备700签署的数字签名(例如，使用电子设备700的数字证书，对交易的摘要进行加密得到)，并将交易广播到区块链网络500。其中，数字证书可由电子设备700向认证中心600进行登记注册得到。
区块链网络500中的节点510在接收到交易时，对交易携带的数字签名进行验证，数字签名验证成功后，根据交易中携带的电子设备700的身份标识，确认电子设备700是否是具有交易权限，数字签名和权限验证中的任何一个验证判断都将导致交易失败。验证成功后签署节点510自己的数字签名，并继续在区块链网络500中广播。
区块链网络500中具有排序功能的节点510接收到验证成功的交易后，将交易填充到新的区块中，并广播到区块链网络500中提供共识服务的节点。
区块链网络500中的提供共识服务的节点510对新区块进行共识过程以达成一致，提供账本功能的节点510将新区块追加到区块链的尾部，并执行新区块中的交易：对于查询黑名单的交易，从状态数据库中查询黑名单，并将查询到的黑名单发送至电子设备700。值得说明的是，状态数据库以键值对的形式存储数据，且状态数据库存储的数据通常与区块链存储的数据相同，在响应查询交易时，可以优先根据状态数据库中的数据进行响应，从而提升响应效率。当然，在不存在状态数据库的情况下，可以直接根据区块链中的数据进行响应。由于区块链中的数据具有不可篡改的特性，故通过上述方式，保证了获取到的黑名单的准确性。另外，区块链中存储的数据并不限于黑名单，例如还可以包括分配的业务密钥信息、用户账号对应的可信应用进程的进程信息、用户账号对应的可访问的业务服务器的地址等。
在步骤403中，根据对应用进程的同步验证处理结果，确定为应用进程分配的业务凭证及网关地址，并将业务凭证及网关地址发送至业务接入进程，以使业务接入进程将业务凭证及业务请求发送至网关地址对应的业务网关。
例如，当对应用进程的同步验证处理结果为验证成功时，电子设备确定为应用进程分配的业务凭证及网关地址，并将业务凭证及网关地址发送至业务接入进程；对应用进程的同步验证处理结果为验证失败时，可以断开与业务接入进程之间的通信连接，或者通知业务接入进程与业务服务器进行直连。这里的网关地址是指有权限访问业务服务器(这里指应用进程的业务请求所请求的业务服务器)的业务网关的地址，在本申请实施例中，可以针对不同的业务服务器设定不同的有权限访问的业务网关，也可以统一设定有权限访问的业务网关，对此不做限定。电子设备可以将分配的业务凭证存储在本地，以便后续验证，其中，对业务凭证的类型不做限定，例如可以是一个随机的字符串。
业务接入进程在接收到业务凭证及网关地址时，可以首先将业务凭证发送至网关地址对应的业务网关。业务网关在接收到业务凭证时，将业务凭证发送至电子设备以进行验证处理，若业务凭证与电子设备中存储的业务凭证相同，即验证成功，则业务网关可以将验证成功的信息发送至业务接入进程。业务接入进程在接收到验证成功的信息时，将应用进程的业务请求发送至业务网关，以使业务网关将业务请求转发至业务服务器，如此，业务服务器便可对接收到的业务请求中的请求数据进行响应处理。对于业务服务器通过响应处理得到的响应数据，按照相反的通信方向发送给应用进程即可。此外，若业务网关对接收到的业务凭证验证失败，则业务网关不支持对业务接入进程发送过来的业务请求进行转发，例如，业务网关可以与业务接入进程断开通信连接。
值得说明的是，在上述的步骤401至步骤403中，业务接入进程与电子设备之间的交互，均属于加密业务通信的范畴。
如图4D所示，业务接入进程可以作为应用进程的代理，实现对业务服务器的访问，适用于零信任场景，如零信任无边界办公的场景。
在一些实施例中，可以通过业务通信系统来实现业务通信方法，其中，业务通信系统包括业务接入客户端、安全客户端及安全服务器。参见图4E，图4E是本申请实施例提供的业务通信方法的一个流程示意图，将结合图4E示出的步骤进行说明。
在步骤501中，安全客户端接收业务接入进程发送的鉴权请求。
这里，安全客户端及业务接入客户端可以部署于同一个终端设备中，也可以部署在不同的终端设备中。
在步骤502中，安全客户端对业务接入进程进行同步验证处理。
这里，对业务接入进程进行的同步验证处理可以包括对进程路径和签名信息的验证处理。值得说明的是，在一些实施例中，业务接入客户端可以是安全客户端的一个组件，安全客户端在对业务接入进程的进程路径进行验证处理时，安全目录可以是安全客户端的安装目录。
在步骤503中，安全服务器对业务接入进程进行异步验证处理。
这里，安全客户端可以通知安全服务器对业务接入进程进行异步验证处理，安全服务器可以将对业务接入进程的异步验证处理结果返回给安全客户端。其中，安全客户端可以将业务接入进程的进程信息发送至安全服务器，以便于进行异步验证处理。
在步骤504中，安全客户端根据对业务接入进程的同步验证处理结果，确定为业务接入进程分配的业务密钥信息。
例如，当对业务接入进程的同步验证处理结果为验证成功时，安全客户端向安全服务器请求业务密钥信息，即业务密钥信息的实际生成方可以是安全服务器。安全客户端可以将获取到的业务密钥信息存储在本地，以便后续进行加密业务通信。
在步骤505中，安全客户端将业务密钥信息发送至业务接入进程，以基于业务密钥信息进行与业务接入进程之间的加密业务通信。
在一些实施例中，步骤505之后，还包括：安全客户端接收业务接入进程发送的凭证请求；其中，凭证请求是业务接入进程在拦截到应用进程的业务请求时发送的，业务请求的目的地址为业务服务器的地址；安全客户端通知安全服务器对应用进程进行同步验证处理；安全服务器根据对应用进程的同步验证处理结果，确定为应用进程分配的业务凭证及网关地址，并将业务凭证及网关地址通过安全客户端发送至业务接入进程；业务接入客户端通过业务接入进程，将业务凭证及业务请求发送至网关地址对应的业务网关；其中，业务网关用于对接收到的业务凭证进行验证处理，并在对业务凭证的验证处理结果为验证成功时，将接收到的业务请求发送至业务服务器；业务服务器用于对接收到的业务请求中的请求数据进行响应处理。
例如，安全客户端、业务接入进程及应用进程可运行于同一个终端设备中。安全客户端可以将获取到的凭证请求、应用进程所在设备中处于登录态的用户账号、应用进程的进程信息、以及应用进程所在设备的设备信息发送至安全服务器，以使安全服务器对应用进程进行同步验证处理，其中，处于登录态的用户账号可以是指安全客户端中处于登录态的用户账号。
在一些实施例中，安全服务器还可以对应用进程进行异步验证处理。
在步骤506中，安全客户端根据安全服务器对业务接入进程的异步验证处理结果，控制与业务接入进程之间用于承载加密业务通信的通信连接。
如图4E所示，本申请实施例可以通过业务接入客户端、安全客户端及安全服务器来实现加密业务通信，其中，业务接入客户端可以作为安全客户端的一个组件，便于安装至终端设备(例如企业员工持有的终端设备)中，适用于零信任无边界办公等场景。
下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，为了便于理解，以零信任无边界办公的场景进行示例说明，其中，零信任(Zero Trust)是指不信任网络内部和外部的任何用户/设备/应用。在本申请实施例中，业务通信系统可以包括安全客户端、安全服务器以及安全管理端，其中，安全管理端用于配置在安全客户端和/或安全服务器中应用的策略、规则等，安全管理端可以提供人机交互界面(如Web界面)，从而便于管理员(如企业管理员)进行配置。
例如，管理员可以在安全管理端配置零信任策略，其中，零信任策略包括用户账号可使用的应用(可信应用)以及可访问的业务系统。作为示例，参见图5所示的安全管理端的策略管理界面的一个示意图。在图5中，零信任策略可以从组织架构中的用户账号(或用户账号组)、可信应用、业务系统(对应上文的业务服务器)这三方面进行配置，下面进行分别说明。
1)用户账号或用户账号组：在本申请实施例中，零信任策略的粒度可以为单个用户账号。如果为某个用户账号组配置零信任策略，则该用户账号组包括的所有用户账号可以共享同一个零信任策略。
2)可信应用：终端设备可访问内部业务系统的应用载体，该应用载体由安全管理端授信。在本申请实施例中，应用进程的进程信息可以包括应用名称、进程名称、应用MD5值及签名信息等。
3)业务系统：可以用于提供企业内部的业务资源、数据、开发环境、测试环境、运维环境和正式生产环境等，是访问主体(人/终端设备/应用)需要访问的对象，即业务系统是访问客体。在一些情况中，业务系统可以是业务服务器(或者是业务服务器集群)。
值得说明的是，用户账号组是企业组织架构里的一个节点，在图5中，节点从上至下依次为全 网账号、用户账号组及用户账号，即全网账号是所有用户账号组的父节点，用户账号组是该用户账号组包括的所有用户账号的父节点。举例来说，图5中的“lemon”用户账号属于“testgroup”用户账号组，“testgroup”用户账号组又属于全网账号。
本申请实施例还提供了如图6所示的进程信息(也称进程特征)的一个示意图，在图6中，示出了一个会议应用进程的进程信息，可以包括进程名称、应用名称、操作系统(即用于运行应用进程的终端设备的操作系统)、厂家、签名信息、送检结果(即异步验证处理结果)、版本、MD5值及SHA256。
在配置业务系统之前，管理员可以在安全管理端的零信任网关(对应上文的业务网关)界面进行零信任网关的相关配置，作为示例，提供了如图7所示的安全管理端的零信任网关界面的示意图、以及如图8所示的零信任网关的配置界面示意图，图8示出的配置界面可以是对图7示出的某个网关(如网关4)进行触发而显示的，当然对此并不做限定。管理员可以根据实际需求，对零信任网关的名称、IP地址、域名、端口、以及优先访问的IP地址段等属性进行配置。其中，若对某个网关配置了优先访问的IP地址段，则当访问主体(如某个终端设备)的IP地址与该优先访问的IP地址段匹配成功(即落入优先访问的IP地址段)时，可以优先使用该网关转发该访问主体的业务请求；当该访问主体的IP地址与该优先访问的IP地址段匹配失败时，可以选择使用该网关或者不使用该网关，根据实际应用场景而定。
本申请实施例还提供了如图9所示的安全管理端的业务系统界面的示意图。在图9中，可以查询具体的某个业务系统，还可以支持添加、拷贝及删除(如批量删除)业务系统。根据实际应用场景的不同，还可以创建不同的系统组合，其中，系统组合包括至少一个业务系统。在图9中，以系统组合1为例，示出了系统组合1中的业务系统1至4。
作为示例，本申请实施例还提供了如图10、图11及图12所示的业务系统的配置界面的示意图。对于每个业务系统，可以配置其IP地址、所属的IP地址段、域名以及端口，还可以根据实际的业务情况，配置可访问该业务系统的网关(即具有访问权限的网关)，并自定义可访问该业务系统的多个网关的顺序。举例来说，对于可访问某个业务系统的4个网关，按照从前至后的顺序依次为网关1、网关2、网关3及网关4，则访问主体在访问该业务系统时，同样按照该顺序进行依次访问，例如首先访问网关1，若访问失败则访问网关2，以此类推。
对业务系统及可信应用配置完成之后，即可针对用户账号或用户账号组下发相关的配置，即进行零信任策略的下发。作为示例，本申请实施例提供了如图13所示的安全管理端的策略管理界面的一个示意图，在图13中，为用户账号“123”配置了可信应用(即图13中的“xx会议”)、以及通过可信应用可访问的业务系统(即图13中的“系统组合2”)。值得说明的是，本申请实施例可以提供继承功能，即是将配置随着从上到下的用户账号层级关系自动复制下来，避免管理员反复勾选操作。例如，用户账号“123”属于用户账号组“test”，则可以将对用户账号组“test”的配置，复制给用户账号“123”。当然，也可以关闭继承功能，以对用户账号“123”进行针对性配置。
安全管理端可以将管理员配置的零信任策略部署至安全服务器中，当然也可以部署至安全客户端中，例如将部分零信任策略部署至安全客户端中。安全客户端用于安装至作为访问主体的终端设备中，这里的终端设备如企业员工使用的个人电脑等。作为示例，本申请实施例提供了如图14所示的安全客户端的界面示意图，在图14中，提供了扫码登录及账号登录两种方式，其中，账号登录是指通过输入用户名和密码的方式进行登录。值得说明的是，安全客户端还可以集成病毒查杀、合规检测、漏洞修复及电脑工具等功能，又例如，如图15所示，在成功登录之后，安全客户端可以提供实时防护策略、杀毒防护引擎及安全加固策略，可以根据实际应用场景对安全客户端进行功能的添加和删除。
本申请实施例还提供了如图16所示的安全客户端的界面示意图，在登录后，安全客户端可以获取针对处于登录态的用户账号配置的零信任策略，从该零信任策略中获取可信应用并进行显示。例如，在图16中，示出了与用户账号“lemon”对应的可信应用“xx会议”。依据安全管理端下发的零信任策略，终端设备可以根据配置的可信应用来访问配置的业务系统，适用于无边界办公，如远程办公的场景。
接下来，以无边界办公的场景为例，说明实际的访问过程。本申请实施例提供了如图17所示的访问过程示意图，在图17中，业务通信系统可以充当零信任网络安全服务提供方，基于访问代理(对应上文的业务接入客户端)和零信任网关为访问主体提供统一入口，以使访问主体通过统一入口对访问客体进行访问，即通过网络发送业务请求。其中，业务通信系统可以为统一入口提供鉴权操作，只有通过鉴权的业务请求才能由访问代理转发给零信任网关，从而通过零信任网关代理对实际业务 系统的访问。
作为示例，本申请实施例还提供了如图18所示的访问过程示意图，图18中的核心模块包括安全客户端、安全服务器、访问代理及零信任网关(智能网关)，接下来进行分别说明。
1)安全客户端：安装在访问主体(如企业员工的终端设备)中的Agent，可以用于验证处于登录态的用户账号是否可信、终端设备是否可信以及应用是否可信。安全客户端可以将应用进程的进程特征(对应上文的进程信息)发送给安全服务器，即进行进程送检(对应上文的针对应用进程的异步验证处理)。
2)访问代理：也称代理客户端，用于劫持终端设备的流量，即拦截终端设备中的应用进程发送的业务请求，其中，可以通过TUN/TAP虚拟网卡实现流量劫持，但劫持方式并不限于此。
3)零信任网关：可以部署在企业应用程序和数据资源的入口，负责对每一个用于访问企业内部业务系统的业务请求进行验证、授权及转发。其中，零信任网关可以通过软件形式构建。
4)安全服务器：负责通过策略控制引擎(策略中心)对业务流量进行安全调度，按照用户账号-终端设备-应用的颗粒度对应用进程的业务请求进行授权。安全服务器可以用于验证安全客户端中处于登录态的用户账号是否可信，还可以用于验证设备硬件信息和设备安全状态，还可以用于检测应用进程是否可信，如是否有漏洞，是否有病毒木马等。安全服务器可以周期性地向云服务器发起文件送检，若识别出发送业务请求的应用进程为恶意进程，则通知安全客户端执行异步阻断操作，例如断开与访问代理之间的通信连接，其中，云服务器用于提供恶意进程的云检测服务(或称云查询服务、云识别服务等)。
举例来说，终端设备(访问主体)可以通过应用进程发送针对访问客体的业务请求，访问代理在劫持到该业务请求时，向安全客户端发送票据请求(对应上文的凭证请求)，票据请求包括业务请求中的源IP地址(或者源域名)、源端口、目的IP地址(或者目的域名)及目的端口，还包括应用进程对应的PID，其中，票据即对应上文的业务凭证，PID用于唯一地标识应用进程。安全客户端在接收到访问代理发送的票据请求时，根据其中的PID采集应用进程的MD5值、进程路径、进程最近修改时间、版权信息及签名信息等，连同票据请求中的源IP地址(或者源域名)、源端口、目的IP地址(或者目的域名)以及目的端口，还连同安全客户端中处于登录态的用户账号的信息等，向安全服务器申请票据。安全服务器在接收到这些信息后，获取与安全客户端中处于登录态的用户账号对应的零信任策略，并根据获取到的零信任策略，确定该用户账号是否具有通过应用进程(指发起业务请求的应用进程)访问业务系统(指业务请求所请求的业务系统)的权限，若具有权限，则安全服务器可以将生成的票据、票据最大使用次数以及票据有效使用时长发送至安全客户端，以使安全客户端转发至访问代理。
在票据申请的过程中，可以包括同步和异步两个方面。例如，在同步验证处理中，安全客户端向安全服务器申请票据，安全服务器对应用进程的进程特征进行同步验证处理，例如验证应用进程是否为可信应用、用户账号是否拥有通过应用进程访问相应的业务系统的权限等。若安全服务器得到的同步验证处理结果为验证成功，则安全服务器正常响应票据、票据最大使用次数以及票据有效使用时长给安全客户端，由安全客户端发送给访问代理，例如安全客户端可以通过本地进程通信(即Socket通信连接)的方式发送至访问代理。
在异步验证处理中，安全服务器可以根据应用进程的进程特征，周期性地向特定的云服务器发送文件送检请求。若安全服务器从云服务器获取到应用进程为恶意进程，则可以通知安全客户端执行异步阻断操作，例如断开与访问代理之间的通信连接。
访问代理在获取到票据后，可以向零信任网关发送票据，以使零信任网关进行验证。例如，访问代理可以将票据添加在一个HTTPS请求的Authorization首部字段中，并将该HTTPS请求发送至零信任网关。零信任网关在接收到该HTTPS请求时，解析出Authorization首部字段中的票据，并向安全服务器校验票据。若零信任网关对票据验证成功，则零信任网关与访问代理成功建立连接，之后访问代理便可将原始的业务请求(这里指应用进程发送的业务请求)发送给零信任网关，由零信任网关将业务请求转发至到对应的业务系统，以代理应用进程对业务系统的网络访问；若零信任网关对票据验证失败，则断开访问代理与零信任网关之间的通信连接，由访问代理直接将原始的业务请求发送至对应的业务系统，在零信任无边界办公的场景中，为了保证网络访问的安全性，这种访问通常会失败。
在本申请实施例中，安全服务器既能够通过单一部署方式，适应中型企事业单位和政府，也能够通过分布式级联部署方式，适应大型企业集团和多级垂直政府电子政务系统。
例如，为了保障零信任网络访问核心业务的稳定运行，可以采取零信任核心服务异地多活的方 案。核心的基础业务部署在总控节点，各个不同的业务部署在不同的二级业务节点中。作为示例，本申请实施例提供了如图19所示的级联部署的示意图，在图19中，安全服务器采取级联部署模式，包括总控节点(总控服务器)和二级业务节点(服务器节点)。总控节点部署有核心的基础服务，例如心跳服务、策略同步服务及设备管控服务等。总控节点的配置和数据可以周期性地同步给各二级业务节点；同时，当二级业务节点有数据和配置需要更改时，可以通知总控节点去修改，总控节点修改完成之后，同步给相应的二级业务节点即可。
在本申请实施例中，访问代理的业务接入进程可以调用安全客户端中的接口来实现数据传递，为了保证安全性，可以对访问代理的业务接入进程进行同步验证处理及异步验证处理，以下进行分别说明。
1)同步验证处理。
访问代理与安全客户端建立Socket连接后，安全客户端通过访问代理的IP地址和端口号，获取业务接入进程的PID。然后，安全客户端根据业务接入进程的PID获取业务接入进程的进程路径，检测该进程路径是否位于安全客户端的安装目录(对应上文的安全目录)内。在本申请实施例中，访问代理可以是业务通信系统的一个组件，在正常安装后，访问代理通常位于安全客户端的安装目录中。并且，在本申请实施例中，可以对安全客户端的安装目录进行目录保护，阻止其他非业务通信系统的服务或进程对该安装目录进行操作。
通过检测业务接入进程的进程路径是否在安全客户端的安装目录内，可以初步检测接入进程的合法性。若业务接入进程的进程路径位于该安装目录内，则可以进一步获取业务接入进程的进程文件的签名信息，并进行验证处理。在企业的安全管控强度较低的情况下，可以放松(授权)未具有数字签名的业务接入进程对安全客户端的接口访问；在企业的安全管控强度较高的情况下，可限制只有具备数字签名的业务接入进程才能访问安全客户端的接口。根据安全管控强度的不同，可以实行以下几种针对签名信息的验证处理。
①检测业务接入进程的进程文件是否具备数字签名，若具备数字签名，即确定对签名信息验证成功。
②安全客户端本地对数字签名进行有效性验证处理，例如调用WinVerifyTrust的API进行有效性验证处理。若有效性验证处理为验证成功，则确定对签名信息验证成功。
③在安全客户端本地进行有效性验证处理的基础上，获取数字签名的签名人姓名(对应上文的签名方)，并将签名人姓名与签名人黑名单进行匹配。当签名人姓名不位于签名人黑名单中，即匹配失败时，确定对签名信息验证成功。
④安全客户端获取业务接入进程的进程文件的证书链信息(对应上文的证书信息)，例如，证书链信息可以包括摘要算法、根证书信息、中级证书信息、签名证书信息、签名状态、签名人姓名、时间戳及签名验证错误信息。其中，根证书信息包括根证书的名称、序列号及到期时间等，中级证书信息及签名证书信息以此类推。另外，签名状态可以用于表示数字签名可用、数字签名被篡改、证书不可信、证书过期、证书吊销及其他错误中的一种。安全客户端在获取到证书链信息后，可以将证书链信息与证书链信息黑名单(对应上文的证书信息黑名单)进行匹配，若匹配失败，则确定对签名信息验证成功。
以上4种方式的安全管控强度逐渐增强，相应地，验证处理所耗费的时长也会变长，可以根据实际应用场景中的安全管控的强度需求以及效率需求，选用至少一种方式实现对签名信息的验证处理。
安全客户端在对业务接入进程的进程路径和签名信息均验证成功时，可以先允许业务接入进程的接口调用，进入接口鉴权环节。
2)异步验证处理。
为了充分验证业务接入进程是否是恶意进程，安全客户端可以异步获取业务接入进程的进程特征，并发送至安全服务器，以进行异步验证处理。其中，业务接入进程的进程特征包括但不限于业务接入进程的MD5值、Hash值、进程路径及签名信息(包括证书链信息)。安全服务器接收到业务接入进程的进程特征后，可以周期性地向云服务器发送文件送检请求，云服务器根据存储的不断更新的进程特征黑名单(对应上文的进程信息黑名单)，判断业务接入进程是否为恶意进程。若云服务器判断出业务接入进程为恶意进程，则安全服务器会通知安全客户端，以使安全客户端断开与业务接入进程之间的Socket连接。
作为示例，本申请实施例提供了如图20所示的异步验证处理的示意图，图20中的编号表示异步验证处理的步骤，将结合示出的各个步骤进行说明。
①访问代理尝试调用安全客户端的相关接口，即向安全客户端发送鉴权请求。
②安全客户端对业务接入进程进行同步验证处理(包括对进程路径及签名信息的验证处理)，若同步验证处理结果为验证成功，则采集业务接入进程的进程特征。
③安全客户端将业务接入进程的进程特征发送至安全服务器，即进行异步送检。
④安全服务器将业务接入进程的进程特征发送至云服务器，以便云服务器判断业务接入进程是否为恶意进程。
⑤云服务器向安全服务器发送异步验证处理的结果，即业务接入进程是否为恶意进程。
⑥若业务接入进程为恶意进程，则安全服务器通知安全客户端执行连接阻断操作。
⑦安全客户端主动断开与业务接入进程之间的Socket连接。
接下来，对安全客户端与业务接入进程之间的接口鉴权环节进行阐述，为了便于理解，以步骤形式进行说明。
1)业务接入进程生成非对称密钥对。
业务接入进程在调用安全客户端的接口时，需要获取安全客户端针对此次调用的授权。首先，由业务接入进程生成非对称密钥对，非对称密钥对中的私钥privatekey可以由业务接入进程进行内存加密保存，非对称密钥对中的公钥pubkey用于发送给安全客户端。本申请实施例对生成非对称密钥对的方式不做限定，例如可以通过RSA算法进行生成。
2)业务接入进程调用安全客户端的鉴权接口。
这里，业务接入进程向安全客户端的鉴权接口发送鉴权请求，鉴权请求的示例如下。
GET http://localhost:[port]/[path]/[req_acc]/{pubkey}
其中，[port]表示安全客户端所提供的安全服务的监听端口，[path]表示服务路由(对应上文的鉴权请求地址)，[req_acc]表示请求标识，即用于表示请求鉴权。另外，上述示例中的{pubkey}＝urlencode(base64encode(pubkey))，即{pubkey}是对业务接入进程生成的公钥pubkey进行base64encode之后，再进行urlencode得到的结果。在本申请实施例中，执行base64encode和urlencode的目的均是为了便于进行网络传输。
3)安全客户端响应鉴权请求。
安全客户端在接收到鉴权请求时，通过上述的同步和异步相结合的方法检测业务接入进程的合法性。在对业务接入进程的同步验证处理结果为验证成功时，安全客户端请求安全服务器生成对称密钥aes_key，用于后续的加密业务通信，其中，对称密钥可以通过AES算法或其他算法生成。安全客户端通过鉴权请求中的{pubkey}对对称密钥进行加密，并将加密后的对称密钥发送至业务接入进程，完成首次授权。
这里，安全客户端向业务接入进程返回的数据包的示例如下。
Figure PCTCN2021125653-appb-000001
其中，encrypt(plain_data，pubkey)表示安全客户端根据业务接入进程发送的公钥pubkey对数据包主体的明文信息plain_data进行加密后得到的结果，即encrypt表示加密处理。access_key是安全客户端对对称密钥aes_key执行base64encode得到的结果，这里，安全服务器可以将access_id与access_key之间的映射关系进行存储，还可以存储access_key的最大使用次数以及有效使用时长等属性。安全客户端也可以将access_id及对应的access_key(或者对应的aes_key)存储在本地，以便后续查询。
4)业务接入进程接收并解析安全客户端响应的数据包。
业务接入进程接收到安全客户端返回的数据包时，解析出数据包中的响应码code，若响应码code的值为0，则表示处理正常，业务接入进程进一步通过base64decode解析出该数据包的data的base64明文，再通过内存中加密保存的私钥privatekey对base64明文进行解密处理，得到plain_data。
然后，业务接入进程从plain_data中解析出access_id和access_key，并加密存储在内存中。在本申请实施例中，access_id和access_key可以是一对一的关系。
5)业务接入进程调用安全客户端的业务接口。
这里，业务接口可以是用于申请票据的接口，当然也可以是其他的业务接口。当业务接入进程调用安全客户端的业务接口时，对发送给业务接口的原始参数raw_param(对应上文的请求数据)经过如下处理，形成call_param。
①使用对称密钥aes_key对原始参数raw_param进行加密处理，即encrypt(raw_param，aes_key)。其中，对原始参数raw_param的内容不做限定，可以根据实际业务来具体设定。
②针对第①步得到的结果执行base64encode，即base64encode(encrypt(raw_param，aes_key))。
③针对第②步得到的结果执行urlencode，即urlencode(base64encode(encrypt(raw_param，aes_key)))，得到call_param。
当业务接入进程调用安全客户端的业务接口时，业务接入进程同时生成自定义校验信息signature(对应上文的第一校验信息)，生成的步骤如下所示。
①业务接入进程从内存加密数据中取出access_id，以作为第一部分(命名为A)。
②对对称密钥aes_key执行base64encode，得到第二部分(命名为B)，即B＝base64encode(aes_key)。
③对参数call_param执行base64encode，得到第三部分(命名为C)，即C＝base64encode(call_param)。
④将当前的时间戳timestamp作为第四部分(命名为D)。
⑤将上述4步得到的字符串相加，再计算MD5值，得到自定义校验信息signature，即signature＝MD5(A+B+C+D)。
在得到自定义校验信息signature后，对其进行base64encode得到Authorization公共头信息，例如可以表示为：
Authorization:"IPN base64encode({"access_id":""，"signature":""，"timestamp":""})"
其中，timestamp表示在生成signture过程中的时间戳，即上述的D。值得说明的是，业务接入进程向安全客户端发送的业务请求包括上述的call_param及Authorization公共头信息。
6)安全客户端解析业务接入进程向业务接口发送的业务请求，并检测业务请求是否合法。
当安全客户端接收到业务请求时，对业务请求中的call_param进行urldecode，然后进行base64decode，得到encrypt(raw_param，aes_key)。然后，使用aes_key对encrypt(raw_param，aes_key)进行解密处理得到raw_param，即业务接入进程的原始参数。
对于业务请求中的Authorization公共头信息，安全客户端首先进行base64decode得到明文，即access_id、自定义校验信息signture及时间戳timestamp。然后，安全客户端根据access_id在本地进行查询，得到相应的access_key(或者aes_key)，然后将查询到的access_key发送至安全服务器，以检测查询到的access_key是否过期。若查询到的access_key已过期，则安全客户端触发鉴权接口的调用重认证，即是使业务接入进程重新发送鉴权请求。
若查询到的access_key未过期，即未失效，则安全客户端根据业务请求中的call_param、Authorization公共头信息中的access_id、Authorization公共头信息中的timestamp、以及查询到的access_key，重新生成校验信息Signature’(对应上文的第二校验信息)，即Signature’＝MD5(access_id+base64encode(aes_key)+base64encode(call_param)+timestamp)，这里的base64encode(aes_key)即为查询到的access_key。
安全客户端将生成的校验信息Signature’与业务接入进程发送的自定义校验信息Signature进行比较，若两者相同，则安全客户端确定业务请求合法；若两者不同，证明业务请求中的参数经过篡改或伪造，安全客户端确定业务请求不合法，业务接入进程对业务接口的调用失败。
7)安全客户端对业务请求中的原始参数进行响应处理得到响应数据，并返回给业务接入进程。
若安全客户端确定出业务请求合法，即业务接入进程针对业务接口的调用合法，则安全客户端对业务请求中的原始参数raw_param进行响应处理，得到响应数据resultdata，这里，对响应数据resultdata的具体内容不做限定，可以根据实际业务进行设定。安全客户端返回给业务接入进程的数据包的示例如下。
Figure PCTCN2021125653-appb-000002
Figure PCTCN2021125653-appb-000003
其中，retcode表示针对业务接入进程发送的业务请求的响应码，若retcode是0，则表示针对业务接口的调用成功；若retcode是1，则表示针对业务接口的调用失败；若retcode是2，则表示access_key(或者aes_key)已过期，需要业务接入进程重新发送鉴权请求，即重新执行步骤2)。
在本申请实施例，可以在安全管理端周期性地更新接口鉴权所需的对称密钥，在每次更新时，安全服务器可以将更新前的所有access_id及access_key(或者aes_key)设置为失效，从而触发业务接入进程重新调用安全客户端的鉴权接口，以获取更新后的access_id和access_key。
针对access_id和access_key(或者aes_key)，本申请实施例可以在安全管理端配置不同的粒度，例如可从业务接入进程本身、以及业务接入进程调用鉴权接口时发送的服务路由两方面进行区分。举例来说，业务接入进程A调用鉴权接口时的服务路由包括path1、path2和path3，业务接入进程B调用鉴权接口时的服务路由包括path4和path5，则粒度划分的方案可包括如下三种：
1)安全服务器同时区分业务接入进程和服务路由，即针对不同的业务接入进程分配不同的access_id和access_key组合对，针对同一业务接入进程的不同服务路由也分配不同的access_id和access_key组合对。举例来说，针对业务接入进程A的path1、path2及path3，分别分配三组不同的access_id和access_key组合对；针对业务接入进程B的path4及path5，分别分配另外两组不同的access_id和access_key组合对。
2)安全服务器仅区分业务接入进程，不区分服务路由，即针对不同的业务接入进程分配不同的access_id和access_key组合对，针对同一业务接入进程的不同服务路由分配相同的access_id和access_key组合对。举例来说，针对业务接入进程A的path1、path2及path3，统一分配一组access_id和access_key组合对；针对业务接入进程B的path4及path5，统一分配另一组access_id和access_key组合对。
3)安全服务器不区分业务接入进程及服务路由，即针对所有业务接入进程的所有服务路由，统一分配一组access_id和access_key组合对。
在实际应用场景中，管理员可以根据企业的管控程度，采用上述的任意一种粒度划分的方案。
针对access_id和access_key(或者aes_key)的更换机制，安全服务器可以配置最大使用次数以及有效使用时长中的至少一种，从而实现access_id和access_key的定期更新，提升安全性。
在本申请实施例中，安全客户端通过对业务接入进程的进程路径及签名信息进行验证处理，能够实现对业务接入进程的合法性的有效验证；同时，通过安全客户端的进程特征异步送检以及安全服务器的云查服务检测，能够准确验证业务接入进程是否为恶意进程。本申请实施例既提升了对业务接入进程的验证准确率，也提升了合规的业务接入进程接入安全客户端的效率。
此外，本申请实施例提供了通过动态密钥和自定义校验信息验证的接口鉴权方案，能够根据安全服务器下发的对称密钥进行加密业务通信，避免密钥存储被破解的问题；同时，可以周期性地更新业务密钥信息，从而加强接口调用的安全性；还允许管理员根据各业务的管控程度，通过不同的粒度划分方案来区分业务密钥信息，提升对不同业务及不同场景的适用性。
下面继续说明本申请实施例提供的终端设备400实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器450的业务通信装置455中的软件模块可以包括：接收模块4551，用于接收业务接入进程发送的鉴权请求；验证模块4552，用于对业务接入进程进行同步验证处理，对业务接入进程进行异步验证处理；确定模块4553，用于根据对业务接入进程的同步验证处理结果，确定为业务接入进程分配的业务密钥信息；发送模块4554，用于将业务密钥信息发送至业务接入进程，以基于业务密钥信息进行与业务接入进程之间的加密业务通信；连接控制模块4555，用于根据对业务接入进程的异步验证处理结果，控制与业务接入进程之间用于承载加密业务通信的通信连接。
在一些实施例中，验证模块4552，还用于：将业务接入进程的进程路径与设定的安全目录之间的匹配结果，作为第一验证处理结果；对业务接入进程的签名信息进行验证处理，得到第二验证处理结果；根据第一验证处理结果及第二验证处理结果，确定对业务接入进程的同步验证处理结果。
在一些实施例中，验证模块4552，还用于根据签名信息是否包括数字签名的结果、数字签名的有效性验证处理结果、数字签名的签名方与签名方黑名单之间的匹配结果、以及签名信息中的证书信息与证书信息黑名单之间的匹配结果中的至少之一，确定第二验证处理结果。
在一些实施例中，验证模块4552，还用于：确定签名信息中的数字签名、以及与数字签名对应的解密密钥；根据解密密钥对数字签名进行解密处理，得到业务接入进程的进程文件的第一哈希结果；对业务接入进程的进程文件进行哈希处理，得到第二哈希结果；将第一哈希结果与第二哈希结果之间的匹配结果，作为数字签名的有效性验证处理结果。
在一些实施例中，鉴权请求包括业务接入进程生成的非对称密钥对中的公钥；其中，非对称密钥对包括公钥以及与公钥对应的私钥；发送模块4554，还用于：根据公钥对业务密钥信息进行加密处理；将加密后的业务密钥信息发送至业务接入进程，以使业务接入进程根据私钥对加密后的业务密钥信息进行解密处理。
在一些实施例中，业务密钥信息包括密钥标识及对称密钥；业务通信装置455还包括：业务接收模块，用于接收业务接入进程发送的业务请求；其中，业务请求包括密钥标识、以及利用对称密钥加密后的请求数据；查询模块，用于在已分配的对称密钥中，查询与业务请求中的密钥标识对应的对称密钥；解密模块，用于根据查询到的对称密钥，对业务请求中的加密后的请求数据进行解密处理；响应模块，用于对解密处理得到的请求数据进行响应处理，得到响应数据；加密发送模块，用于根据公钥对响应数据进行加密处理，并将加密后的响应数据发送至业务接入进程，以使业务接入进程根据私钥对加密后的响应数据进行解密处理。
在一些实施例中，业务请求还包括时间戳及第一校验信息；其中，第一校验信息是业务接入进程对密钥标识、对称密钥、时间戳、以及利用对称密钥加密后的请求数据进行哈希处理得到的；响应模块，还用于：对密钥标识、查询到的对称密钥、时间戳、以及加密后的请求数据进行哈希处理，得到第二校验信息；当第一校验信息与第二校验信息之间的匹配结果为匹配成功时，对解密处理得到的请求数据进行响应处理。
在一些实施例中，业务通信装置455还包括：过期处理模块，用于当查询到的对称密钥的使用参数满足过期参数条件时，将过期信息发送至业务接入进程，以使业务接入进程在接收到过期信息时重新发送鉴权请求；其中，使用参数包括使用次数以及使用时长中的至少一种。
在一些实施例中，鉴权请求包括鉴权请求地址；确定模块4553，还用于执行以下任意一种处理：针对不同业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，针对同一业务接入进程发送的不同鉴权请求地址分配不同的业务密钥信息；针对不同业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，针对同一业务接入进程发送的不同鉴权请求地址分配相同的业务密钥信息；针对不同业务接入进程发送的鉴权请求地址分配相同的业务密钥信息，针对同一业务接入进程发送的不同鉴权请求地址分配相同的业务密钥信息。
在一些实施例中，验证模块4552，还用于：周期性地将业务接入进程的进程信息与进程信息黑名单进行匹配，并将得到的匹配结果作为对业务接入进程的异步验证处理结果。
在一些实施例中，确定模块4553，还用于：当对业务接入进程的同步验证处理结果为验证成功时，确定为业务接入进程分配的业务密钥信息；当对业务接入进程的同步验证处理结果为验证失败时，执行以下任意一种处理：通知业务接入进程重新发送鉴权请求；断开与业务接入进程之间用于传输鉴权请求的通信连接；中断对业务接入进程的异步验证处理。
在一些实施例中，连接控制模块4555，还用于：当对业务接入进程的异步验证处理结果为验证成功时，维持与业务接入进程之间用于承载加密业务通信的通信连接；当对业务接入进程的异步验证处理结果为验证失败时，断开与业务接入进程之间用于承载加密业务通信的通信连接。
在一些实施例中，业务通信装置455还包括：加密通信模块，用于：在加密业务通信的过程中，执行以下处理：接收业务接入进程发送的凭证请求；其中，凭证请求是业务接入进程在拦截到应用进程的业务请求时发送的，业务请求的目的地址为业务服务器的地址；对应用进程进行同步验证处理；根据对应用进程的同步验证处理结果，确定为应用进程分配的业务凭证及网关地址，并将业务凭证及网关地址发送至业务接入进程，以使业务接入进程将业务凭证及业务请求发送至网关地址对应的业务网关；其中，业务网关用于对接收到的业务凭证进行验证处理，并在对业务凭证的验证处理结果为验证成功时，将接收到的业务请求发送至业务服务器；业务服务器用于对接收到的业务请求中的请求数据进行响应处理。
在一些实施例中，加密通信模块还用于：确定应用进程所在设备中处于登录态的用户账号，并获取用户账号对应的可信应用进程的进程信息、以及用户账号对应的可访问的业务服务器的地址；将应用进程的进程信息与可信应用进程的进程信息之间的匹配结果，作为第三验证处理结果；将业务请求所请求的业务服务器的地址与可访问的业务服务器的地址之间的匹配结果，作为第四验证处理结果；获取应用进程所在设备的设备信息，并将设备信息与设备安全条件之间的匹配结果，作为第五验证处理结果；根据第三验证处理结果、第四验证处理结果及第五验证处理结果，确定对应用进程的同步验证处理结果。
在一些实施例中，加密通信模块还用于：周期性地将应用进程的进程信息与进程信息黑名单进行匹配，并将得到的匹配结果作为对应用进程的异步验证处理结果；根据对应用进程的异步验证处 理结果，控制与业务接入进程之间用于承载加密业务通信的通信连接。
本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令(可执行指令)，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的业务通信方法
本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图4A、图4B、图4C、图4D及图4E示出的业务通信方法。
在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper Text Markup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
以上，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (21)

  1. 一种业务通信方法，由电子设备执行，所述方法包括：
    接收业务接入进程发送的鉴权请求；
    对所述业务接入进程进行同步验证处理，对所述业务接入进程进行异步验证处理；
    根据对所述业务接入进程的同步验证处理结果，确定为所述业务接入进程分配的业务密钥信息；
    将所述业务密钥信息发送至所述业务接入进程，以基于所述业务密钥信息进行与所述业务接入进程之间的加密业务通信；
    根据对所述业务接入进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
  2. 根据权利要求1所述的方法，其中，所述对所述业务接入进程进行同步验证处理，包括：
    将所述业务接入进程的进程路径与设定的安全目录之间的匹配结果，作为第一验证处理结果；
    对所述业务接入进程的签名信息进行验证处理，得到第二验证处理结果；
    根据所述第一验证处理结果及所述第二验证处理结果，确定对所述业务接入进程的同步验证处理结果。
  3. 根据权利要求2所述的方法，其中，所述对所述业务接入进程的签名信息进行验证处理，得到第二验证处理结果，包括：
    根据所述签名信息是否包括数字签名的结果、所述数字签名的有效性验证处理结果、所述数字签名的签名方与签名方黑名单之间的匹配结果、以及所述签名信息中的证书信息与证书信息黑名单之间的匹配结果中的至少之一，确定第二验证处理结果。
  4. 根据权利要求3所述的方法，其中，所述方法还包括：
    确定所述签名信息中的数字签名、以及与所述数字签名对应的解密密钥；
    根据所述解密密钥对所述数字签名进行解密处理，得到所述业务接入进程的进程文件的第一哈希结果；
    对所述业务接入进程的进程文件进行哈希处理，得到第二哈希结果；
    将所述第一哈希结果与所述第二哈希结果之间的匹配结果，作为所述数字签名的有效性验证处理结果。
  5. 根据权利要求1所述的方法，其中，所述鉴权请求包括所述业务接入进程生成的非对称密钥对中的公钥；其中，所述非对称密钥对包括所述公钥以及与所述公钥对应的私钥；
    所述将所述业务密钥信息发送至所述业务接入进程，包括：
    根据所述公钥对所述业务密钥信息进行加密处理；
    将加密后的所述业务密钥信息发送至所述业务接入进程，以使所述业务接入进程根据所述私钥对加密后的所述业务密钥信息进行解密处理。
  6. 根据权利要求5所述的方法，其中，所述业务密钥信息包括密钥标识及对称密钥；
    所述将加密后的所述业务密钥信息发送至所述业务接入进程之后，所述方法还包括：
    接收所述业务接入进程发送的业务请求；其中，所述业务请求包括所述密钥标识、以及利用所述对称密钥加密后的请求数据；
    在已分配的对称密钥中，查询与所述业务请求中的所述密钥标识对应的对称密钥；
    根据查询到的对称密钥，对所述业务请求中的加密后的请求数据进行解密处理；
    对解密处理得到的请求数据进行响应处理，得到响应数据；
    根据所述公钥对所述响应数据进行加密处理，并将加密后的所述响应数据发送至所述业务接入进程，以使所述业务接入进程根据所述私钥对加密后的所述响应数据进行解密处理。
  7. 根据权利要求6所述的方法，其中，所述业务请求还包括时间戳及第一校验信息；其中，所述第一校验信息是所述业务接入进程对所述密钥标识、所述对称密钥、所述时间戳、以及利用所述对称密钥加密后的请求数据进行哈希处理得到的；
    所述对解密处理得到的请求数据进行响应处理，包括：
    对所述密钥标识、所述查询到的对称密钥、所述时间戳、以及所述加密后的请求数据进行哈希处理，得到第二校验信息；
    当所述第一校验信息与所述第二校验信息之间的匹配结果为匹配成功时，对解密处理得到的请求数据进行响应处理。
  8. 根据权利要求6所述的方法，其中，所述在已分配的对称密钥中，查询与所述业务请求中的所述密钥标识对应的对称密钥之后，所述方法还包括：
    当查询到的对称密钥的使用参数满足过期参数条件时，将过期信息发送至所述业务接入进程，以使所述业务接入进程在接收到所述过期信息时重新发送鉴权请求；
    其中，所述使用参数包括使用次数以及使用时长中的至少一种。
  9. 根据权利要求1所述的方法，其中，所述鉴权请求包括鉴权请求地址；
    所述确定为所述业务接入进程分配的业务密钥信息，包括：
    执行以下任意一种处理：
    针对不同所述业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，针对同一所述业务接入进程发送的不同鉴权请求地址分配不同的业务密钥信息；
    针对不同所述业务接入进程发送的鉴权请求地址分配不同的业务密钥信息，针对同一所述业务接入进程发送的不同鉴权请求地址分配相同的业务密钥信息；
    针对不同所述业务接入进程发送的鉴权请求地址分配相同的业务密钥信息，针对同一所述业务接入进程发送的不同鉴权请求地址分配相同的业务密钥信息。
  10. 根据权利要求1所述的方法，其中，所述根据对所述业务接入进程的同步验证处理结果，确定为所述业务接入进程分配的业务密钥信息，包括：
    当对所述业务接入进程的同步验证处理结果为验证成功时，确定为所述业务接入进程分配的业务密钥信息；
    所述方法还包括：
    当对所述业务接入进程的同步验证处理结果为验证失败时，执行以下任意一种处理：
    通知所述业务接入进程重新发送鉴权请求；
    断开与所述业务接入进程之间用于传输所述鉴权请求的通信连接；
    中断对所述业务接入进程的异步验证处理。
  11. 根据权利要求1所述的方法，其中，所述根据对所述业务接入进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接，包括：
    当对所述业务接入进程的异步验证处理结果为验证成功时，维持与所述业务接入进程之间用于承载所述加密业务通信的通信连接；
    当对所述业务接入进程的异步验证处理结果为验证失败时，断开与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
  12. 根据权利要求1至11任一项所述的方法，其中，所述方法还包括：
    在所述加密业务通信的过程中，执行以下处理：
    接收所述业务接入进程发送的凭证请求；其中，所述凭证请求是所述业务接入进程在拦截到应用进程的业务请求时发送的，所述业务请求的目的地址为业务服务器的地址；
    对所述应用进程进行同步验证处理；
    根据对所述应用进程的同步验证处理结果，确定为所述应用进程分配的业务凭证及网关地址，并将所述业务凭证及所述网关地址发送至所述业务接入进程，以使
    所述业务接入进程将所述业务凭证及所述业务请求发送至所述网关地址对应的业务网关；
    其中，所述业务网关用于对接收到的所述业务凭证进行验证处理，并在对所述业务凭证的验证处理结果为验证成功时，将接收到的所述业务请求发送至所述业务服务器；所述业务服务器用于对接收到的所述业务请求中的请求数据进行响应处理。
  13. 根据权利要求12所述的方法，其中，所述对所述应用进程进行同步验证处理，包括：
    确定所述应用进程所在设备中处于登录态的用户账号，并获取所述用户账号对应的可信应用进程的进程信息、以及所述用户账号对应的可访问的业务服务器的地址；
    将所述应用进程的进程信息与所述可信应用进程的进程信息之间的匹配结果，作为第三验证处理结果；
    将所述业务请求所请求的业务服务器的地址与所述可访问的业务服务器的地址之间的匹配结果，作为第四验证处理结果；
    获取所述应用进程所在设备的设备信息，并将所述设备信息与设备安全条件之间的匹配结果，作为第五验证处理结果；
    根据所述第三验证处理结果、所述第四验证处理结果及所述第五验证处理结果，确定对所述应用进程的同步验证处理结果。
  14. 根据权利要求12所述的方法，其中，所述接收所述业务接入进程发送的凭证请求之后，所述方法还包括：
    周期性地将所述应用进程的进程信息与进程信息黑名单进行匹配，并将得到的匹配结果作为对所述应用进程的异步验证处理结果；
    根据对所述应用进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
  15. 根据权利要求1至11任一项所述的方法，其中，所述对所述业务接入进程进行异步验证处理，包括：
    周期性地将所述业务接入进程的进程信息与进程信息黑名单进行匹配，并将得到的匹配结果作为对所述业务接入进程的异步验证处理结果。
  16. 一种业务通信系统，包括业务接入客户端、安全客户端及安全服务器；其中，所述业务接入客户端运行有业务接入进程；
    所述安全客户端，用于：
    接收所述业务接入进程发送的鉴权请求；
    对所述业务接入进程进行同步验证处理，通知所述安全服务器对所述业务接入进程进行异步验证处理；
    根据对所述业务接入进程的同步验证处理结果，确定为所述业务接入进程分配的业务密钥信息；
    将所述业务密钥信息发送至所述业务接入进程，以基于所述业务密钥信息进行与所述业务接入进程之间的加密业务通信；
    根据所述安全服务器对所述业务接入进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
  17. 根据权利要求16所述的系统，其中，
    所述安全客户端，还用于：
    接收所述业务接入进程发送的凭证请求；其中，所述凭证请求是所述业务接入进程在拦截到应用进程的业务请求时发送的，所述业务请求的目的地址为业务服务器的地址；
    通知所述安全服务器对所述应用进程进行同步验证处理；
    所述安全服务器，用于根据对所述应用进程的同步验证处理结果，确定为所述应用进程分配的业务凭证及网关地址，并将所述业务凭证及所述网关地址通过所述安全客户端发送至所述业务接入进程；
    所述业务接入客户端，还用于将所述业务凭证及所述业务请求通过所述业务接入进程发送至所述网关地址对应的业务网关；
    其中，所述业务网关用于对接收到的所述业务凭证进行验证处理，并在对所述业务凭证的验证处理结果为验证成功时，将接收到的所述业务请求发送至所述业务服务器；所述业务服务器用于对接收到的所述业务请求中的请求数据进行响应处理。
  18. 一种业务通信装置，所述装置包括：
    接收模块，配置为接收业务接入进程发送的鉴权请求；
    验证模块，配置为对所述业务接入进程进行同步验证处理，对所述业务接入进程进行异步验证处理；
    确定模块，配置为根据对所述业务接入进程的同步验证处理结果，确定为所述业务接入进程分配的业务密钥信息；
    发送模块，配置为将所述业务密钥信息发送至所述业务接入进程，以基于所述业务密钥信息进行与所述业务接入进程之间的加密业务通信；
    连接控制模块，配置为根据对所述业务接入进程的异步验证处理结果，控制与所述业务接入进程之间用于承载所述加密业务通信的通信连接。
  19. 一种电子设备，所述电子设备包括：
    存储器，用于存储可执行指令；
    处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至15任一项所述的业务通信方法。
  20. 一种计算机可读存储介质，存储有可执行指令，所述可执行指令被处理器执行时实现权利要求1至15任一项所述的业务通信方法。
  21. 一种计算机程序产品，包括可执行指令，所述可执行指令被处理器执行时实现权利要求1至15任一项所述的业务通信方法。
PCT/CN2021/125653 2020-11-05 2021-10-22 业务通信方法、系统、装置及电子设备 WO2022095730A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020237008870A KR20230048431A (ko) 2020-11-05 2021-10-22 서비스 통신 방법, 시스템, 장치 및 전자 디바이스
EP21888427.8A EP4181460A4 (en) 2020-11-05 2021-10-22 SERVICE COMMUNICATION METHOD, SYSTEM AND DEVICE AND ELECTRONIC DEVICE
JP2023515835A JP2023541599A (ja) 2020-11-05 2021-10-22 サービス通信方法、システム、装置及び電子機器
US17/974,067 US20230056432A1 (en) 2020-11-05 2022-10-26 Service communication method, system, apparatus, electronic device, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011222173.X 2020-11-05
CN202011222173.XA CN112422532B (zh) 2020-11-05 2020-11-05 业务通信方法、系统、装置及电子设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/974,067 Continuation US20230056432A1 (en) 2020-11-05 2022-10-26 Service communication method, system, apparatus, electronic device, and storage medium

Publications (1)

Publication Number Publication Date
WO2022095730A1 true WO2022095730A1 (zh) 2022-05-12

Family

ID=74827887

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/125653 WO2022095730A1 (zh) 2020-11-05 2021-10-22 业务通信方法、系统、装置及电子设备

Country Status (6)

Country Link
US (1) US20230056432A1 (zh)
EP (1) EP4181460A4 (zh)
JP (1) JP2023541599A (zh)
KR (1) KR20230048431A (zh)
CN (1) CN112422532B (zh)
WO (1) WO2022095730A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115529352A (zh) * 2022-09-20 2022-12-27 蚂蚁区块链科技(上海)有限公司 计算服务的路由处理方法及装置
CN117240910A (zh) * 2023-11-16 2023-12-15 中邮消费金融有限公司 零信任校验系统以及方法
WO2024083978A1 (fr) * 2022-10-21 2024-04-25 Orange Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112422532B (zh) * 2020-11-05 2024-02-23 腾讯科技（深圳）有限公司 业务通信方法、系统、装置及电子设备
CN113259319B (zh) * 2021-04-12 2023-05-12 杭州顶象科技有限公司 验证处理方法及系统
CN113242230B (zh) * 2021-05-07 2022-09-06 中国科学技术大学 一种基于智能合约的多级认证与访问控制系统及方法
CN114172664B (zh) * 2021-12-07 2024-02-09 天融信雄安网络安全技术有限公司 数据加密、数据解密方法、装置、电子设备及存储介质
CN114650216A (zh) * 2022-03-22 2022-06-21 阿里云计算有限公司 安全防护方法及装置
CN114938278B (zh) * 2022-04-11 2023-10-31 北京邮电大学 一种零信任访问控制方法及装置
CN116204543B (zh) * 2023-05-04 2023-08-08 天津金城银行股份有限公司 一种票据保活的方法、系统、计算机和可读存储介质
CN116614312B (zh) * 2023-07-19 2024-04-09 北京云尚汇信息技术有限责任公司 一种云计算系统的安全验证方法及系统
CN117201192A (zh) * 2023-11-06 2023-12-08 国家计算机网络与信息安全管理中心 一种基于环境度量的零信任单包通信方法及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106790080A (zh) * 2016-12-22 2017-05-31 深圳新众诚科技有限公司 业务系统和电子凭证系统之间的网络安全通信方法与装置
CN110535648A (zh) * 2018-05-24 2019-12-03 腾讯科技（深圳）有限公司 电子凭证生成及验证和密钥控制方法、装置、系统和介质
CN110535807A (zh) * 2018-05-24 2019-12-03 腾讯科技（深圳）有限公司 一种业务鉴权方法、装置和介质
CN111212075A (zh) * 2020-01-02 2020-05-29 腾讯云计算（北京）有限责任公司 业务请求的处理方法、装置、电子设备及计算机存储介质
US20200259827A1 (en) * 2018-12-04 2020-08-13 Journey.ai Providing access control and identity verification for communications when initiating a communication from an entity to be verified
CN112422532A (zh) * 2020-11-05 2021-02-26 腾讯科技（深圳）有限公司 业务通信方法、系统、装置及电子设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107040513B (zh) * 2016-06-30 2020-06-02 郭铮铮 一种可信访问认证处理方法、用户终端和服务端
US11973745B2 (en) * 2018-12-04 2024-04-30 Journey.ai Performing concealed transactions using a zero-knowledge data management network
AU2020217563A1 (en) * 2019-02-05 2021-09-30 Ethopass, Llc Security system and related methods
CN110569649A (zh) * 2019-08-21 2019-12-13 上海易点时空网络有限公司 基于异步处理的数据接入服务接口鉴权方法及装置
CN111211908B (zh) * 2019-12-25 2023-03-03 深圳供电局有限公司 访问控制方法、系统、计算机设备和存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106790080A (zh) * 2016-12-22 2017-05-31 深圳新众诚科技有限公司 业务系统和电子凭证系统之间的网络安全通信方法与装置
CN110535648A (zh) * 2018-05-24 2019-12-03 腾讯科技（深圳）有限公司 电子凭证生成及验证和密钥控制方法、装置、系统和介质
CN110535807A (zh) * 2018-05-24 2019-12-03 腾讯科技（深圳）有限公司 一种业务鉴权方法、装置和介质
US20200259827A1 (en) * 2018-12-04 2020-08-13 Journey.ai Providing access control and identity verification for communications when initiating a communication from an entity to be verified
CN111212075A (zh) * 2020-01-02 2020-05-29 腾讯云计算（北京）有限责任公司 业务请求的处理方法、装置、电子设备及计算机存储介质
CN112422532A (zh) * 2020-11-05 2021-02-26 腾讯科技（深圳）有限公司 业务通信方法、系统、装置及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4181460A4 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115529352A (zh) * 2022-09-20 2022-12-27 蚂蚁区块链科技(上海)有限公司 计算服务的路由处理方法及装置
WO2024083978A1 (fr) * 2022-10-21 2024-04-25 Orange Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants
FR3141301A1 (fr) * 2022-10-21 2024-04-26 Orange Procédé de traitement d’une requête d’exécution d’un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d’ordinateur correspondants
CN117240910A (zh) * 2023-11-16 2023-12-15 中邮消费金融有限公司 零信任校验系统以及方法
CN117240910B (zh) * 2023-11-16 2024-03-01 中邮消费金融有限公司 零信任校验系统以及方法

Also Published As

Publication number Publication date
KR20230048431A (ko) 2023-04-11
EP4181460A1 (en) 2023-05-17
US20230056432A1 (en) 2023-02-23
JP2023541599A (ja) 2023-10-03
CN112422532B (zh) 2024-02-23
EP4181460A4 (en) 2024-01-03
CN112422532A (zh) 2021-02-26

Similar Documents

Publication Publication Date Title
WO2022095730A1 (zh) 业务通信方法、系统、装置及电子设备
US9621355B1 (en) Securely authorizing client applications on devices to hosted services
US20200186358A1 (en) Persistent network device authentication
US8782757B2 (en) Session sharing in secure web service conversations
US8024488B2 (en) Methods and apparatus to validate configuration of computerized devices
US9237021B2 (en) Certificate grant list at network device
JP2019526993A (ja) ネットワーク機能仮想化システム及び検証方法
US20220103361A1 (en) Enforcing a Segmentation Policy Using Cryptographic Proof of Identity
CN112149105A (zh) 数据处理系统、方法、相关设备及存储介质
US9325697B2 (en) Provisioning and managing certificates for accessing secure services in network
WO2022100356A1 (zh) 身份认证系统、方法、装置、设备及计算机可读存储介质
WO2023065969A1 (zh) 访问控制方法、装置及系统
US11722303B2 (en) Secure enclave implementation of proxied cryptographic keys
WO2021159818A1 (zh) 秘钥访问控制方法和装置
EP4096160A1 (en) Shared secret implementation of proxied cryptographic keys
CN115473648A (zh) 一种证书签发系统及相关设备
Walsh et al. Intra-cloud and inter-cloud authentication
US11804957B2 (en) Exporting remote cryptographic keys
US11611541B2 (en) Secure method to replicate on-premise secrets in a cloud environment
CN116846682B (zh) 通信信道建立方法、装置、设备及介质
US20230403138A1 (en) Agentless single sign-on techniques
CN115130116A (zh) 业务资源访问方法、装置、设备、可读存储介质及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21888427

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021888427

Country of ref document: EP

Effective date: 20230207

ENP Entry into the national phase

Ref document number: 2023515835

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20237008870

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE