CN114697065A

CN114697065A - Security authentication method and security authentication device

Info

Publication number: CN114697065A
Application number: CN202011636591.3A
Authority: CN
Inventors: 胡帅; 唐菁; 陈海波; 魏春城
Original assignee: China United Network Communications Group Co Ltd; China Unicom System Integration Ltd Corp
Current assignee: China United Network Communications Group Co Ltd; China Unicom System Integration Ltd Corp
Priority date: 2020-12-31
Filing date: 2020-12-31
Publication date: 2022-07-01
Anticipated expiration: 2040-12-31
Also published as: CN114697065B

Abstract

The application provides a security authentication method and a security authentication device, which are beneficial to solving the security authentication problem of micro-service application between cloud units. The method is applied to a system comprising a plurality of cloud units, wherein each cloud unit comprises a cloud access platform, a security micro-engine and a micro-service application, and the method comprises the following steps: the cloud access platform receives the first request message, determines whether the access is legal or not based on the first request message and the first access control list, encrypts the first request message by adopting a corresponding key in the second access control list if the access is legal, and sends the encrypted first request message to a first security micro-engine corresponding to the first micro-service application; and the first security microengine determines whether the access is legal or not based on the encrypted first request message and the second access control list, and if so, decrypts the encrypted first request message by adopting a corresponding key in the second access control list and sends the decrypted first request message to the first microservice application.

Description

Security authentication method and security authentication device

Technical Field

The present application relates to the field of cloud technologies, and in particular, to a security authentication method and a security authentication apparatus.

Background

With the development of public cloud, private cloud and hybrid cloud, more and more enterprises deploy business systems under a multi-cloud micro-service architecture, which is composed of different cloud providers, cloud applications in different geographic locations and micro-service architectures. In a multi-cloud micro-service architecture, two security threats exist in a service system. One is a network intrusion threat outside the multi-cloud micro-service architecture, e.g., a hacker intrusion; another is a security penetration threat in the environment in which the multi-cloud microservice architecture operates.

In the prior art, a security authentication scheme of the microservice mostly adopts an authentication method based on Token, for example, the Oauth2 protocol. The method is beneficial to solving the safety authentication problem from the client to the micro-service application, but the method is not beneficial to solving the safety authentication problem of the micro-service application between different cloud units under a multi-cloud micro-service architecture.

Disclosure of Invention

The application provides a security authentication method and a security authentication device, which are beneficial to solving the security authentication problem of micro-service application among different cloud units.

In a first aspect, a security authentication method is provided, which is applied to a system including a plurality of cloud units, where a cloud unit includes a cloud access platform, a security micro-engine, and a micro-service application, and the method includes: the cloud access platform receives a first request message, wherein the first request message is used for requesting access to a first micro-service application in a cloud unit; the cloud access platform determines whether the access is legal or not based on the first request message and a first access control list, wherein the first access control list comprises access permissions among different cloud units; if the access is legal, the cloud access platform encrypts the first request message by adopting a corresponding key in a second access control list, wherein the second access control list comprises access permissions among different micro-service applications; and the cloud access platform sends the encrypted first request message to a first security micro-engine corresponding to the first micro-service application.

According to the security authentication method provided by the embodiment of the application, the information in the first request message is compared with the first control list and the second control list for verification, the validity of the first request message is verified, the security of the first request message is improved in an encryption mode, and the security authentication problem of micro-service applications among different cloud units and the security authentication problem of the micro-service applications inside the cloud units are favorably solved.

With reference to the first aspect, in certain implementations of the first aspect, the cloud access platform receives a first access control list from the multi-cloud micro-service security management platform.

With reference to the first aspect, in some implementation manners of the first aspect, the cloud access platform sends a second request message to the multi-cloud micro-service security management platform, where the second request message is used to request registration of the cloud access platform, and the second request message carries user configuration information; the cloud access platform receives a response message from the multi-cloud micro-service security management platform, wherein the response message carries an encryption mode and/or a first access control list of the cloud access platform; the cloud access platform stores the encryption mode and/or the first access control list of the cloud access platform.

In a second aspect, another security authentication method is provided, which is applied to a system including a plurality of cloud units, where each cloud unit includes a cloud access platform, a security micro-engine, and a micro-service application, and the method includes: the first security micro-engine receives an encrypted first request message, wherein the first request message is used for requesting to access a first micro-service application in the cloud unit; the first security microengine determines whether the access is legal or not based on the encrypted first request message and a second access control list, wherein the second access control list comprises access permissions among different microservice applications; if the access is legal, the first security micro-engine decrypts the encrypted first request message by adopting a corresponding key in the second access control list; the first security microengine sends the decrypted first request message to the first microservice application.

With reference to the second aspect, in certain implementations of the second aspect, the first security microengine receives a second access control list from the multi-cloud micro-service security management platform.

With reference to the second aspect, in some implementations of the second aspect, the first security microengine sends a third request message to the multi-cloud micro-service security management platform, where the third request message is used to request registration of the first security microengine, and the third request message carries user configuration information; the first security micro-engine receives a response message from the multi-cloud micro-service security management platform, wherein the response message carries an encryption mode and/or a second access control list of the first security micro-engine; the first security microengine maintains an encryption mode and/or a second access control list of the first security microengine.

In a third aspect, a further security authentication method is provided, which is applied to a system including a multi-cloud micro-service security management platform and a plurality of cloud units, where a cloud unit includes a cloud access platform, a security micro-engine, and a micro-service application, and the method includes: the multi-cloud micro-service security management platform receives a second request message from the cloud access platform, wherein the second request message is used for requesting registration of the cloud access platform and carries user configuration information; the multi-cloud micro-service security management platform saves user configuration information of the cloud access platform and updates a first access control list, wherein the first access control list comprises access authorities among different cloud units; the multi-cloud micro-service security management platform sends a response message to the cloud access platform, and the response message carries the encryption mode and/or the first access control list of the cloud access platform.

According to the security authentication method provided by the embodiment of the application, the first access control list is updated by managing the registration information of the cloud access platform, so that the security authentication problem of micro-service application among different cloud units is solved.

With reference to the third aspect, in some implementations of the third aspect, the multi-cloud micro-service security management platform receives a third request message from the security micro-engine, where the third request message is used to request registration of the security micro-engine, and the third request message carries user configuration information; the multi-cloud micro-service security management platform saves user configuration information of the security micro-engine and updates a second access control list, wherein the second access control list comprises access rights among different micro-service applications; and the multi-cloud micro-service security management platform sends a response message to the security micro-engine, wherein the response message carries the encryption mode of the first security micro-engine and/or the second access control list.

According to the security authentication method provided by the embodiment of the application, the second access control list is updated by managing the registration information of the security micro-engine, so that the security authentication problem among different micro-service applications can be solved.

In a fourth aspect, a security authentication apparatus is provided for performing the method in any one of the possible implementations of the first aspect. In particular, the apparatus comprises means for performing the method of any one of the possible implementations of the first aspect described above.

In a fifth aspect, another security authentication apparatus is provided for performing the method in any one of the possible implementations of the second aspect. In particular, the apparatus comprises means for performing the method of any one of the possible implementations of the second aspect described above.

In a sixth aspect, there is provided yet another security authentication apparatus for performing the method in any one of the possible implementations of the third aspect. In particular, the apparatus comprises means for performing the method of any one of the possible implementations of the third aspect described above.

In a seventh aspect, a processor is provided, including: input circuit, output circuit and processing circuit. The processing circuit is configured to receive a signal via the input circuit and transmit a signal via the output circuit, so that the processor performs the method in any one of the possible implementations of the first to third aspects.

In a specific implementation process, the processor may be a chip, the input circuit may be an input pin, the output circuit may be an output pin, and the processing circuit may be a transistor, a gate circuit, a flip-flop, various logic circuits, and the like. The input signal received by the input circuit may be received and input by, for example and without limitation, a receiver, the signal output by the output circuit may be output to and transmitted by a transmitter, for example and without limitation, and the input circuit and the output circuit may be the same circuit that functions as the input circuit and the output circuit, respectively, at different times. The embodiment of the present application does not limit the specific implementation manner of the processor and various circuits.

In an eighth aspect, a processing apparatus is provided that includes a processor and a memory. The processor is configured to read instructions stored in the memory, and may receive a signal through the receiver and transmit a signal through the transmitter to perform the method in any one of the possible implementations of the first aspect to the third aspect.

Optionally, there are one or more processors and one or more memories.

Alternatively, the memory may be integrated with the processor, or provided separately from the processor.

In a specific implementation process, the memory may be a non-transient memory, such as a Read Only Memory (ROM), which may be integrated on the same chip as the processor, or may be separately disposed on different chips.

It will be appreciated that the associated data interaction process, for example, sending the indication information, may be a process of outputting the indication information from the processor, and receiving the capability information may be a process of receiving the input capability information from the processor. In particular, the data output by the processor may be output to a transmitter and the input data received by the processor may be from a receiver. The transmitter and receiver may be collectively referred to as a transceiver, among others.

The processing device in the above eighth aspect may be a chip, the processor may be implemented by hardware or may be implemented by software, and when implemented by hardware, the processor may be a logic circuit, an integrated circuit, or the like; when implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory, which may be integrated with the processor, located external to the processor, or stand-alone.

In a ninth aspect, a computer-readable medium is provided, which stores a computer program (which may also be referred to as code or instructions) that, when executed on a computer, causes the computer to perform the method of any one of the possible implementations of the first to third aspects.

In a tenth aspect, there is provided a computer program product comprising: a computer program (which may also be referred to as code, or instructions), which when executed, causes a computer to perform the method of any of the possible implementations of the first to third aspects described above.

Drawings

FIG. 1 is a schematic diagram of a security threat presented by a multi-cloud microservice architecture;

fig. 2 is a schematic diagram of a multi-cloud micro-service architecture according to an embodiment of the present application;

fig. 3 is a functional structure schematic diagram of a multi-cloud micro-service security management platform according to an embodiment of the present application;

fig. 4 is a functional structure schematic diagram of a cloud access platform according to an embodiment of the present application;

FIG. 5 is a functional block diagram of a security microengine according to an embodiment of the present application;

fig. 6 is a schematic flow chart of a security authentication method proposed in an embodiment of the present application;

fig. 7 is a schematic flow chart of another security authentication method proposed in the embodiment of the present application;

fig. 8 is a schematic flow chart of another security authentication method proposed in the embodiment of the present application;

fig. 9 is a schematic block diagram of a security authentication apparatus according to an embodiment of the present application;

fig. 10 is a schematic block diagram of another security authentication apparatus proposed in an embodiment of the present application;

fig. 11 is a schematic block diagram of another security authentication apparatus proposed in an embodiment of the present application;

fig. 12 is a schematic block diagram of another security authentication apparatus proposed in an embodiment of the present application.

Detailed Description

The technical solution in the present application will be described below with reference to the accompanying drawings.

Cloud technology is now being accepted by more and more enterprises, and each large enterprise gradually puts its own business system in the cloud. The public cloud markets at home and abroad have gradually formed the scale of the dividend, and each of the public cloud markets has various market development points, provides different capability characteristics and pricing strategies. Therefore, the cloud process on the enterprise has to face the problems of multi-cloud application (multi cloud) and hybrid cloud application (hybrid cloud).

Under such a multi-cloud architecture, a service system is often composed of application systems distributed in different cloud providers or different geographic locations. In addition, the cloud application is often a dynamic variation body, and the size of the whole application system can dynamically scale along with the change of the customer requirements. The micro-service architecture which is gradually popular in recent years has the characteristics of small application, large system construction, dynamic scaling and the like. Therefore, most enterprises today adopt a multi-cloud micro-service architecture to accommodate this complex IT ecosystem.

Under a multi-cloud micro-service architecture, two security threats may exist in a business system deployed by an enterprise. One is a network intrusion threat outside the multi-cloud micro-service architecture, e.g., a hacker intrusion; another is a security penetration threat in the environment in which the multi-cloud microservice architecture operates.

Fig. 1 shows a schematic diagram of security threats existing in a multi-cloud micro-service architecture 100. In fig. 1, the multi-cloud micro-service architecture includes arri cloud, private cloud, amazon cloud service (AWS), and micro-service application, where circles represent micro-service application, arri cloud may be used to support data warehouse (hive), AWS may be used to support database (mysql), and private cloud may be used to support storage system (Redis). Under the multi-cloud micro-service architecture, two security threats may exist in a business system deployed by an enterprise. One is the presence of network intrusion threats outside the framework, such as extranet intrusion and intranet intrusion; the other is the security penetration threat that the internet presents when using the multi-cloud micro-service architecture normally.

In the prior art, a security authentication scheme of a micro service mostly adopts a Token-based authentication method, which is beneficial to solving the security authentication problem from a client to a micro service application, but is not beneficial to solving the security authentication problem between different cloud units and different micro service applications in the cloud units under a multi-cloud micro service architecture.

In view of this, embodiments of the present application provide a security authentication method and a security authentication apparatus, which are beneficial to solve the security authentication problem of micro-service applications between different cloud units by deploying a cloud access platform, a security micro-engine and a multi-cloud micro-service security management platform.

Fig. 2 shows a schematic diagram of a multi-cloud microservice architecture 200 as proposed herein. The multi-cloud micro-service architecture 200 comprises three cloud units, namely, an ali cloud (Aliyun.com), a private cloud (privatecloud.com) and an AWS (amazon.com), wherein the private cloud comprises a multi-cloud micro-service security management platform 201, a cloud access platform 202(apig) and a security micro-engine 203; the public cloud and AWS include a cloud access platform 202 and a security microengine 203. Among them, the multi-cloud micro-service security management platform 201 is deployed on a private cloud, which is merely an example, and may be specified by a user to be deployed on any cloud unit in the multi-cloud micro-service architecture.

It should be understood that the multi-cloud micro-service security management platform, the cloud access platform and the security micro-engine are just examples of names, and other platforms or devices having the same function may be included in the scope of the embodiments of the present application.

In the multi-cloud micro-service architecture 200, the multi-cloud micro-service security management platform 201 is a core management side. Fig. 3 shows a functional structure diagram of a multi-cloud micro-service security management platform 201, where the multi-cloud micro-service security management platform 201 may include: the system comprises a micro service access control list (MSACCL) authority rule management module, a multi-cloud access control list (MCACCL) authority rule management module, a system monitoring module and a cloud and application management module.

It should be understood that the msalcl permission rule management module, the mcalcl permission rule management module, the system monitoring module, and the cloud and application management module are just examples of names, and other platforms or devices having the same function may be included in the protection scope of the embodiments of the present application.

The cloud and application management module may generate a multi-cloud component registry (mcms register) according to the registration information of all cloud access platforms 202 and all security microengines 203 under the multi-cloud micro-service architecture, as shown in table one. In table one, registration information of the cloud access platform 202 and the security micro-engine 203 may be recorded, for example, information such as an ID, a cloud unit ID, an IP, a domain name, registration time, a type, a status, a key, and the like, where the ID is a unique identifier of a cloud component in the cloud micro-service system, the cloud unit ID is a domain name that identifies a cloud unit, the domain name is an access domain name of the cloud access platform and the micro-service application, the registration time is a time when the component is registered to the cloud micro-service security management platform, the type indicates whether a current component is a "cloud access platform" or a "security micro-engine", and the status indicates a current component status, including: the key is used for recording key information for accessing the cloud component, and symmetric key encryption (AES, SM1) or asymmetric key encryption (SM2, RSA1024) can be set according to the requirements of a cloud unit user. It should be understood that only encrypted key information is recorded in the mcms register, and the cloud component itself records the decryption key to protect encryption security. In addition, for the purpose of high availability, the micro-service application may deploy multiple instances, which have the same domain name and different IP addresses. The access rules for multiple instances may be determined by the security microengine at the request originator. It should be understood that the contents of the table one record are merely one example.

Watch 1

The mcalcl entitlement rule management module may manage content in the mcalcl that records access reachability of different cloud units and access reachability of cloud units outside the domain. Mcalcl includes information such as ID, requestor, recipient, key, type, reachability, update time, etc., as shown in table two. The ID is a recording serial number, the 'requester' records a domain name of an information initiating cloud access platform, the 'receiver' records a domain name of an information destination cloud access platform, and the secret key is an information encryption secret key for requesting the information initiating cloud access platform to access a destination cloud unit, and the encryption secret key can be in a symmetric encryption mode or an asymmetric encryption mode and can be specifically determined according to user requirements; in addition, the legal access credential of the out-of-domain requester is AppId + Token (as in the 1 st and 2 nd records in table two), the "requester" in the record records the AppId issued by the security management platform, and the Token itself is recorded by the key for the out-of-domain request through Token authentication. "type" means out-of-domain access or inter-cloud access. If the access is available, the identifier is available, 1 is available, and 0 is not available. The update time is the update time of the information. It should be appreciated that access reachability for different cloud units, as well as access reachability to cloud units outside the domain, is not constant and may change, and that the information in the mcalcl table may be updated as it changes. It should be understood that the contents of the table two records are merely one example.

Watch two

The msalcl entitlement rule management module may manage the content in the msalcl used to record the accessibility of accesses to different microservice applications within the cloud unit. As shown in Table III, MSACL includes ID, requester, receiver, key, reachability, update time, etc. information. Wherein, ID is a record serial number, the "requester" records the domain name of the information initiating security micro-engine, and the "receiver" records the domain name of the information destination security micro-engine. The key is an information encryption key for requesting the initiator microservice to access the target microservice, and the encryption key can be in a symmetric encryption mode or an asymmetric encryption mode and can be specifically determined according to user requirements. If yes, the identifier is accessible, 1 is accessible, and 0 is not accessible. The update time is the update time of the information. It should be understood that access reachability for different microservice applications within a cloud unit is not constant and changes may occur, and the information in the msalcl table may be updated as changes occur. It should be understood that the contents of the table three record are merely one example.

Watch III

The system monitoring module can detect whether a cloud access platform exists or not, the security micro-engine cannot work normally (namely heartbeat loss or offline), information in the MCMSregister is updated in time through the cloud and application module, and the security access condition and the compliance condition (whether access conditions of MSACC and MCACC rules violate or not) under the multi-cloud micro-service architecture can be monitored and recorded.

The cloud access platform 202 is a representative cloud unit, and may be implemented by using an API Gateway such as a SpringCloud Gateway. It should be understood that, in consideration of the problem of geographical and network isolation, a set of cloud access platform needs to be deployed on each cloud unit, and the deployment granularity may be the same cloud provider or data centers (regions) in different regions within the same cloud provider. Fig. 4 shows a functional structure diagram of the cloud access platform 202, and the cloud access platform 202 may include: the system comprises a request access module, an access security management module, a heartbeat keeping and registering module and a request distributing module.

It should be understood that the request access module, the access security management module, the heartbeat holding and registration module, and the request distribution module are merely examples of names, and other platforms or devices having the same functions may be included in the protection scope of the embodiments of the present application.

The request access module may receive the out-of-domain access request and access requests of other cloud units and send the requests to the access security management module. If the request access module receives the access request outside the domain, the request access module can provide the https encrypted link to the outside.

The access security management module may store access control information related to a cloud unit deploying the cloud access platform 202 in the mcalcl, that is, a record of a "sender" or a "receiver" in the mcalcl table registering a domain name for a current cloud access platform, and may also store access control information related to micro services inside the cloud unit in the msalcl, that is, a record of a "sender" in the msalcl table registering a domain name for a current cloud access platform, and the access security management module may determine validity of an inter-cloud access request and validity of a token of an out-of-domain request according to information in the msalcl.

The heartbeat keeping and registering module may send registration information to the cloud micro-service security management platform 201, for example, if a request for accessing the cloud access platform is specified by a user as an asymmetric key, the heartbeat keeping and registering module may automatically generate a publicKey and a privateKey, and send the publicKey to the cloud micro-service security management platform 201 along with the attribute information of the cloud access platform for registration. The heartbeat keeping and registering module may also send the state of the cloud access platform to the multi-cloud micro-service security management platform 201 at regular time, so as to prove the availability of the cloud access platform and the cloud unit where the cloud access platform is located.

The request distribution module is used for distributing the legal access request to the corresponding micro service application for subsequent processing, and in addition, if the micro service application has a plurality of instances, the module can also perform load balancing and other operations.

The security microengine 203 may operate in the form of a SideCar, which may be adapted to different deployment modalities. For example, when deployed in kubernets, the security microengines may be deployed in different containers in the same pod, along with the microservices. If the bottom layer is a virtual machine, the sidecar can run in a separate process.

The security micro-engine and the micro-service application communicate through a built-in encryption rpc protocol, and meanwhile, the receiving or sending of messages between the security micro-engine and the micro-service application needs to be carried out through a SideCar so as to intercept or filter the traffic of the micro-service application.

Fig. 5 shows a functional structure diagram of the security microengine 203. The security microengine 203 may include: the system comprises a request access module, a link security management module, a heartbeat keeping and registering module and a request distributing module.

It should be understood that the request access module, the link security management module, the heartbeat maintaining and registering module, and the request distributing module are merely examples of names, and other platforms or devices having the same function may be included in the protection scope of the embodiments of the present application.

The request access module may receive the access request and send the request to the link security management module.

The access security management module may save and store access control information related to the corresponding microservice application in the MSACL, that is, a record of the "sender" or "receiver" in the MSACL table registering a domain name for the current security microengine. In addition, the link security management module stores mcalcl information of a cloud unit where the security micro engine is located, and when the micro service application needs to access other cloud units, the micro service application can acquire rights and related encryption keys from the mcalcl and send a message request to the target cloud access platform.

The heartbeat holding and registering module may send registration information to the cloud micro-service security management platform 201, for example, if a request for accessing the security micro-engine is specified by a user as an asymmetric key, the heartbeat holding and registering module may automatically generate a publicKey and a privateKey, and send the publicKey to the cloud micro-service security management platform 201 along with the attribute information of the security micro-engine for registration. The heartbeat hold and registration module may also periodically send the status of the security microengines to the cloudy microservice security management platform 201 to prove the availability of the security microengines and corresponding microservice applications.

The request distribution module is used for distributing the legal access request to the corresponding micro-service application for subsequent processing, and in addition, if the micro-service application has a plurality of instances, the module can also perform load balancing and other operations.

The multi-cloud micro-service architecture 200 proposed in the embodiment of the present application is described in detail above with reference to fig. 2 to 5, and the security authentication method proposed in the embodiment of the present application based on the multi-cloud micro-service architecture 200 is described in detail below with reference to fig. 6 and 8.

Fig. 6 shows a schematic flowchart of a security authentication method 600 provided in an embodiment of the present application. The method 600 may be applied to the multi-cloud micro-service architecture 200 shown in fig. 2, and may also be applied to other similar architectures, which are not limited in this embodiment of the present application. The method 600 may include the following steps:

s601, the cloud access platform receives a first request message, and the first request message is used for requesting access to a first micro-service application in the cloud unit.

The first request message may be an out-of-domain request from a user, or may be an inter-cloud request from another cloud unit, and the first request message is used to request a first micro-service application of a cloud unit where the cloud access platform is located.

Optionally, S601 may be implemented by the request access module of the cloud access platform.

S602, the cloud access platform determines whether the access is legal or not based on the first request message and a first access control list, wherein the first access control list comprises access permissions among different cloud units.

The cloud access platform can compare and verify the information in the first request message with the content of the first access control list, and if the verification is successful, the access is determined to be legal; if the verification is not successful, an non-compliance request can be sent to the multi-cloud micro-service security management platform, and accordingly the multi-cloud micro-service security management platform receives the non-compliance request and records the request. Illustratively, the multi-cloud micro-service security management platform may record the non-compliance request through a system monitoring module.

The first access control list includes access rights of different cloud units and access rights of the cloud units outside the domain. Illustratively, the first access control list may be a multi-cloud access control list (mcalcl).

Optionally, the first access control list may be sent by the multi-cloud micro-service security management platform to the cloud access platform. It should be understood that the multi-cloud micro-service security management platform may actively send the first access control list to the cloud access platform, or the multi-cloud micro-service security management platform may send the first access control list to the cloud access platform according to a request of the cloud access platform.

Optionally, S601 may be implemented by an access security management module of the cloud access platform.

S603, if the access is legal, the cloud access platform encrypts the first request message by using a corresponding key in a second access control list, wherein the second access control list comprises access permissions among different micro-service applications.

The second access control list includes access rights between different microservice applications within the cloud unit. Illustratively, the second access control list may be a micro service access control list (msalcl).

If the access is legal, the cloud access platform can determine an encryption mode of the first security microengine corresponding to the first micro-service application according to the second access control list, and encrypt the first request message by using a corresponding key in the second access control list.

Optionally, the second access control list may be sent by the multi-cloud micro-service security management platform to the cloud access platform. It should be understood that the multi-cloud micro-service security management platform may actively send the second access control list to the cloud access platform, or the multi-cloud micro-service security management platform may send the second access control list to the cloud access platform according to a request of the cloud access platform.

Optionally, S603 may be implemented by an access security management module of the cloud access platform.

S604, the cloud access platform sends the encrypted first request message to the first security microengine corresponding to the first microservice application, and correspondingly, the first security microengine receives the encrypted first request message.

And the cloud access platform sends the encrypted first request message to the first security micro-engine according to the address of the first security micro-engine in the second access control list, and correspondingly, the first security micro-engine can receive the encrypted first request message.

Optionally, S604 may be implemented by the request distribution module of the cloud access platform and the request access module of the first security micro-engine.

Optionally, the cloud access platform may further send status information to the multi-cloud micro-service security management platform through the heartbeat maintaining and registering module, which indicates the availability of the current cloud access platform.

S605, the first security micro-engine determines whether the access is legal or not based on the encrypted first request message and the second access control list.

The first security microengine can compare and verify the information in the first request message with the content of the second access control list, and if the verification is successful, the access is determined to be legal; if the verification is not successful, an non-compliance request can be sent to the multi-cloud micro-service security management platform, and accordingly the multi-cloud micro-service security management platform receives the non-compliance request and records the request. Illustratively, the multi-cloud micro-service security management platform may record the non-compliance request through a system monitoring module.

Optionally, the second access control list may be sent by the multi-cloud micro-service security management platform to the first security micro-engine. It should be understood that the multi-cloud micro-service security management platform may actively send the second access control list to the first security micro-engine, or the multi-cloud micro-service security management platform may send the second access control list to the first security micro-engine according to a request of the first security micro-engine.

Alternatively, S605 may be implemented by the link security management module of the first security microengine.

And S606, if the access is legal, the first security microengine decrypts the encrypted first request message by adopting the corresponding key in the second access control list.

If the encrypted first request message is a legal request, the first security microengine can decrypt the encrypted first request message by using the corresponding key in the second access control list, and if the decryption is successful, the encrypted first request message is proved to be secure; if the decryption is unsuccessful, the encrypted first request message is proved to be an illegal request, an unqualified request is sent to the multi-cloud micro-service security management platform, and accordingly the multi-cloud micro-service security management platform receives the unqualified request and records the unqualified request. Illustratively, the multi-cloud micro-service security management platform may record the non-compliance request through a system monitoring module.

Optionally, S606 may be implemented by the link security management module of the first security microengine.

S607, the first security microengine sends the decrypted first request message to the first micro service application, and correspondingly, the first micro service application receives the decrypted first request message.

The first security microengine sends the decrypted first request message to the first microservice application via the encrypted rpc protocol, and correspondingly, the first microservice application may receive the decrypted first request message.

Alternatively, S607 may be implemented by the request distribution module of the first security microengine and the first microservice application described above.

Optionally, the first security micro-engine may further send status information to the multi-cloud micro-service security management platform through the heartbeat maintenance and registration module, which indicates the availability of the current first security micro-engine.

S608, the first micro service application determines whether the access is legal or not based on the decrypted first request message and the second access control list.

The first micro service application can compare and verify the information in the decrypted first request message with the content of the second access control list, and if the verification is successful, the access is determined to be legal; if the verification is not successful, an non-compliance request can be sent to the multi-cloud micro-service security management platform, and accordingly the multi-cloud micro-service security management platform receives the non-compliance request and records the request. For example, the multi-cloud micro-service security management platform may record the non-compliance request through a system monitoring module.

And S609, if the access is legal, the first micro-service application encrypts the decrypted first request message by adopting a corresponding key in the second access control list.

If the access is legal, the first micro-service application can determine an encryption mode of a second security micro-engine corresponding to the first micro-service application according to the second access control list, and encrypt the first request message by adopting a corresponding key in the second access control list.

S610, the first micro service application sends the encrypted first request message to a second security micro engine corresponding to the second micro service application, and correspondingly, the second security micro engine receives the encrypted first request message.

The first micro service application sends the encrypted first request message to the second security micro engine according to the address of the second security micro engine in the second access control list, and correspondingly, the second security micro engine may receive the encrypted first request message and then authenticate the encrypted first request message in the authentication manner of the first security micro engine in the above S605 to S607.

S608 to S610 are optional steps, and if the decrypted first request message received by the first micro service application is used to request the second micro service application, S608 to S610 are executed.

Optionally, if the second micro service application is located in another cloud unit, the first micro service application may send the encrypted first request message to a cloud access platform in the cloud unit where the second micro service application is located, where the cloud access platform authenticates the encrypted first request message in the authentication manner of the cloud access platform in S601 to S604.

According to the security authentication method provided by the embodiment of the application, the information in the first request message is compared with the first control list and the second control list for verification, the legality of the first request message is verified, the security of the first request message is improved in an encryption and decryption mode, and the security authentication problem of micro-service applications among different cloud units and the security authentication problem of micro-service applications inside the cloud units are solved.

As an optional embodiment, the method 600 further includes:

and S701, the cloud access platform sends a second request message to the multi-cloud micro-service security management platform, the second request message is used for requesting registration of the cloud access platform, the second request message carries user configuration information, and correspondingly, the multi-cloud micro-service security management platform receives the second request message.

The cloud access platform sends the second request message to the multi-cloud micro-service security management platform, and there are two possible situations. One possible scenario is that the cloud access platform is newly deployed in the cloud unit and is not registered; another possible situation is that the cloud access platform is disconnected from the cloud access platform due to power failure or other unexpected conditions, that is, the cloud access platform goes offline.

S702, the multi-cloud micro-service security management platform stores user configuration information of the cloud access platform and updates a first access control list, wherein the first access control list comprises access rights among different cloud units.

The user configuration information may include information such as encryption mode, platform name, and heartbeat interval time. The multi-cloud micro-service security management platform stores the user configuration information into a registry and updates the first access control list.

Alternatively, the registry may be a multi-cloud component registry (MCMSRegister) that stores user configuration information into the registry, such as record 1 in Table one.

Optionally, if the cloud access platform is registered, the multi-cloud micro-service security management platform may send, to the cloud access platform, information related to the cloud access platform in the first access control list. It should be understood that if the second control list has information related to the cloud access platform, the multi-cloud micro-service security management platform may also send the information related to the cloud access platform in the second access control list to the cloud access platform.

Optionally, S701 may be implemented by a cloud and application management module and an MCACL authority management module of the multi-cloud micro-service security management platform.

S703, the multi-cloud micro-service security management platform sends a response message to the cloud access platform, the response message carries the encryption mode and/or the first access control list of the cloud access platform, and correspondingly, the cloud access platform receives the response message.

S704, the cloud access platform saves the encryption mode and/or the first access control list of the cloud access platform.

And the cloud access platform receives the response message, generates encryption information according to the encryption mode in the response message, and stores the information related to the cloud access platform in the first access control list.

Optionally, the cloud access platform may further send the state information to the multi-cloud micro-service security management platform according to the heartbeat interval time in the user configuration information. Illustratively, the cloud access platform may send the state information to the multi-cloud micro-service security management platform through the heartbeat holding and registering module, and accordingly, the multi-cloud micro-service security management platform updates the first access control list according to the state information. Illustratively, the multi-cloud micro-service security management platform may receive information for monitoring the cloud access platform through the system monitoring module.

S705, the first security micro-engine sends a third request message to the multi-cloud micro-service security management platform, where the third request message is used to request registration of the first security micro-engine, and the third request message carries user configuration information, and the multi-cloud micro-service security management platform receives the third request message.

It should be understood that the first security micro-engine needs to be successfully registered after the cloud access platform is registered in the multi-cloud micro-service security management platform, otherwise, the cloud unit information identifying the identity of the first security micro-engine cannot be found.

The first security microengine sends the third request message to the multi-cloud micro-service security management platform, which has two possible situations. One possible scenario is that the first security microengine is newly deployed in the cloud unit and is not registered; another possible scenario is that the first security microengine is lost to heartbeat, i.e., goes offline, due to a power outage or other unexpected condition.

S706, the multi-cloud micro-service security management platform saves the user configuration information of the first security micro-engine and updates a second access control list, wherein the second access control list comprises access rights among different micro-service applications.

The user configuration information may include information such as encryption mode, platform name, and heartbeat interval time. The multi-cloud micro-service security management platform stores the user configuration information into a registry and updates the second access control list.

Alternatively, the registry may be a multi-cloud component registry (MCMSRegister) that stores user configuration information into the registry, such as record 2 in Table one.

Optionally, if the first security micro-engine is registered, the multi-cloud micro-service security management platform may send, to the first security micro-engine, information related to the cloud access platform in the second access control list.

Optionally, S701 may be implemented by a cloud and application management module and an msalcl permission management module of the multi-cloud micro-service security management platform.

And S707, the multi-cloud micro-service security management platform sends a response message to the security micro-engine, wherein the response message carries the encryption mode and/or the second access control list of the first security micro-engine, and the first security micro-engine receives the response message.

S708, the first security micro-engine stores the encryption mode and/or the second access control list of the first security micro-engine.

And the first security microengine receives the response message, generates encryption information according to the encryption mode in the response message, and stores the information related to the first security microengine in the second access control list.

It should be understood that the execution sequence between S701 to S708 and S601 to S610 described above is not limited. S701 to S708 may be executed before S601, that is, the cloud access platform and the security microengine are registered in the multi-cloud micro security management platform, and the multi-cloud micro security management platform generates the mcms register, the msalcl, and the mcalcl, which facilitates security authentication of the access request; the updating of the MCMSRegister, msalcl, and mcalcl may be performed at any step between S601 to S610, and may be performed after S610.

Optionally, the first security microengine may further send the state information to the multi-cloud micro-service security management platform according to the heartbeat interval time in the user configuration information. Illustratively, the first security microengine may send state information to the multi-cloud micro-service security management platform through the heartbeat holding and registering module, and accordingly, the multi-cloud micro-service security management platform updates the second access control list according to the state information. For example, the multi-cloud micro-service security management platform may receive information for monitoring the first security micro-engine through the system monitoring module.

According to the security authentication method provided by the embodiment of the application, the registration information of the cloud access platform and the security micro-engine, the access authority among different cloud units and the access authority among different micro-service applications are managed, so that the security authentication problem of the micro-service applications among different cloud units and the security authentication problem among the micro-service applications inside the cloud units are favorably solved.

Optionally, if the multi-cloud micro-service security management platform receives a non-compliance condition or too many unsafe accesses of the cloud access platform and the security micro-engine, the access key may be changed in time through the msalcl permission rule management module and the mcalcl permission rule management module, so that the secure access is ensured, and the system monitoring module may collect various cloud access platforms or a condition that the security micro-engine violates mcalcl and msalcl, so as to provide a security log record for the user.

Optionally, when the access key changes and needs to be updated, the multi-cloud micro-service security management platform may notify, through the cloud and application management module, each security micro-engine and each cloud access platform to perform relevant key generation, and send the public key to each security micro-engine and each cloud access platform "heartbeat holding and registering module". In addition, during the key updating, if the messages of the requester and the receiver are not synchronous, the message receiver will return the request and inform the requester to send the message again when receiving the new key, and the request will be sent again when waiting for the mcalcl or msalcl updating.

Optionally, when the micro service applications are increased or decreased, the decreased micro service applications may actively notify the multi-cloud micro service security management platform of a message of offline, or, in an unexpected case, if the multi-cloud micro service security management platform does not receive the cloud access platform or the heartbeat message of the security micro engine within a period set by a user, identify the cloud access platform or the security micro engine as an offline state and update MCAC and msalcl to change the relevant link into a "0 unreachable" state.

Taking a first request message as an out-of-domain access request, a first access control list as mcalcl, a second access control list as msalcl, a multi-cloud micro-service security management platform comprising an msalcl authority rule management module, an mcalcl authority rule management module, a system monitoring module, a cloud and application management module, a cloud access platform comprising a request access module, an access security management module, a heartbeat maintaining and registering module and a request distributing module, and a security micro-engine comprising a request access module, a link security management module, a heartbeat maintaining and registering module and a request distributing module as examples, a security authentication method of the embodiment of the present application is explained in detail.

The user selects Aries in the multi-cloud micro-service security management platform as cloud units capable of receiving the data outside the domain, the user can allocate AppId and access token to each application accessed outside the domain, and the user can set access links between the cloud access platform and each micro-service application, so that MCACL and MSACL are generated.

Fig. 8 shows a schematic flowchart of a security authentication method 800 provided in an embodiment of the present application. The method 800 may be applied to the multi-cloud micro-service architecture 200 shown in fig. 2, and may also be applied to other similar architectures, which are not limited in this embodiment of the present application. The method 800 may include the following steps:

s801, an access request module deployed in a cloud access platform of the Alice cloud receives an access request outside a domain, information such as AppId and token is checked, whether the access request outside the domain is in compliance is determined, and the access request outside the domain is used for requesting access to a first micro-service application in the cloud access platform.

Specifically, the request access module may receive the out-of-domain access request through the https protocol, and check whether the request header has information such as the AppId and Token. If the access request outside the domain does not contain information such as the AppId, the Token and the like, the request access module can discard the access request outside the domain and can send an out-of-compliance request to the multi-cloud micro-service security management platform.

S802, if the access request outside the domain is in compliance, the access security management module in the cloud access platform determines whether the access is legal or not based on the access request outside the domain and the MCACL.

Specifically, if the access request outside the domain is in compliance, the access security management module can acquire information such as the AppId and Token and the like, and compare and verify the information with records in the MCACL, if the verification is unsuccessful, the access request outside the domain is an illegal request, and a non-compliance request is sent to the multi-cloud micro-service security management platform; if the verification is successful, the message is decrypted through the private key of the access security management module according to the rule in the MCACL, and if the decryption is successful, the security of the access request outside the domain is proved; if the decryption is unsuccessful, the access request outside the domain is proved to be an illegal request, and an out-of-compliance request is sent to the multi-cloud micro-service security management platform.

And S803, if the access is legal, the access security management module in the cloud access platform encrypts the access request outside the domain by using a corresponding key in the MSAC.

Specifically, if the access request outside the domain is a legal request, the access security management module may determine, according to the record of MCACL, whether the access request outside the domain can access the first micro service application, and if so, the cloud access platform may encrypt the first request message by using a key corresponding to the first micro service application in the MSACL; and if the access is not possible, sending an out-of-compliance request to the multi-cloud micro-service security management platform.

S804, the request distribution module in the cloud access platform sends the encrypted out-of-domain access request to the first security microengine corresponding to the first micro-service application, and correspondingly, the request access module in the first security microengine receives the encrypted out-of-domain access request.

Specifically, the request distribution module may add information such as sourceHost, sourceIP, and the like to the encrypted out-of-domain access request, and then send the encrypted out-of-domain access request to the first security microengine corresponding to the first micro-service application according to the "receiver" address in the msalcl, and correspondingly, the request access module in the first security microengine receives the encrypted out-of-domain access request.

Optionally, if the first micro-service application may deploy multiple instances, where domain names of the multiple instances are the same, and IP addresses of the multiple instances are different, the request distribution module may add a sourceIP corresponding to the instance to the encrypted out-of-domain access request.

S805, the link security management module in the first security microengine determines whether the access is legal or not based on the encrypted out-of-domain access request and the MSACL.

Specifically, the request access module receives the encrypted out-of-domain access request through the https protocol, and checks whether the request header has information such as sourceHost, sourceIP and the like. If the encrypted out-of-domain access request does not contain the sourceHost, sourceIP and other information, the request access module may discard the encrypted first request message, and may send an out-of-compliance request to the multi-cloud micro-service security management platform.

If the encrypted out-of-domain access request includes sourceHost, sourceIP and other information, the request access module adds the domain name and IP address of the sender, for example, service1.aliyun. com, 10.1.1.1, to the encrypted out-of-domain access request, and sends the result to the link security management module for processing. The link security management module searches a record with the same sender domain name and sourceHost information in MSACL according to sourceHost, sourceIP and other information, if the record is not found, the encrypted out-of-domain access request is an illegal request, and an illegal request is sent to a management platform; if so, the encrypted out-of-domain access request is legal.

S806, if the access is legal, the link security management module in the first security microengine decrypts the encrypted first request message by using the corresponding key in the msalcl.

Specifically, if the encrypted out-of-domain access request is legal, the link security management module decrypts the message through a private key according to a rule in the mcalcl, and if the decryption is successful, the encrypted out-of-domain access request is proved to be secure; if the decryption is unsuccessful, the encrypted out-of-domain access request is proved to be an illegal request, and an out-of-compliance request is sent to the multi-cloud micro-service security management platform.

S807, the request distribution module in the first security microengine sends the decrypted out-of-domain access request to the first micro-service application, and correspondingly, the first micro-service application receives the decrypted out-of-domain access request, where the decrypted out-of-domain access request is used to request the second micro-service application.

The request distribution module sends the decrypted out-of-domain access request to the first micro-service application through the encrypted rpc protocol, and correspondingly, the first micro-service application can receive the decrypted out-of-domain access request.

S808, the first microservice application determines whether the access is legal or not based on the decrypted out-of-domain access request and the MSACC.

The first micro-service application can compare and verify the information in the decrypted out-of-domain access request with the content of the MSACL, and if the verification is successful, the access is determined to be legal; if the verification is not successful, an non-compliance request can be sent to the multi-cloud micro-service security management platform, and accordingly the multi-cloud micro-service security management platform receives the non-compliance request and records the non-compliance request through the system monitoring module.

And S809, if the access is legal, the first micro service application encrypts the decrypted out-of-domain access request by using the corresponding key in the MSACC.

If the access is legal, the first micro-service application can determine an encryption mode of a second security micro-engine corresponding to the second micro-service application according to the MSACC, and encrypt the access request outside the domain by adopting a corresponding key in the MSACC.

S810, the first micro service application sends an encrypted out-of-domain access request to a second security micro engine corresponding to the second micro service application, and correspondingly, the second security micro engine receives the encrypted out-of-domain access request, where the encrypted out-of-domain access request is used to request to access the second micro service application.

The first micro-service application adds sourceHost, sourceIP and other information in the encrypted out-of-domain access request, and sends the encrypted out-of-domain access request to a second security micro-engine according to the address of the second security micro-engine in the MSACL, and correspondingly, the second security micro-engine can receive the encrypted out-of-domain access request.

S811, the link security management module in the second security microengine determines whether the access is legal based on the encrypted out-of-domain access request and MSACL.

If the encrypted out-of-domain access request includes sourceHost, sourceIP and other information, the request access module adds the domain name and IP address of the sender, for example, service1. alias un. com, 10.1.1.1, to the encrypted out-of-domain access request, and sends the result to the link security management module for processing. The link security management module searches a record with the same sender domain name and sourceHost information in MSACL according to sourceHost, sourceIP and other information, if the record is not found, the encrypted out-of-domain access request is an illegal request, and an illegal request is sent to a management platform; if so, the encrypted out-of-domain access request is legal.

S812, if the access is legal, the link security management module in the second security microengine decrypts the encrypted out-of-domain access request by using the corresponding key in the msalcl.

Specifically, if the encrypted out-of-domain access request is legal, the link security management module decrypts the message through a private key according to a rule in the msalcl, and if the decryption is successful, the encrypted out-of-domain access request is proved to be secure; if the decryption is unsuccessful, the encrypted out-of-domain access request is proved to be an illegal request, and an out-of-compliance request is sent to the multi-cloud micro-service security management platform.

S813, the request distribution module in the second security microengine sends the decrypted out-of-domain access request to the second micro-service application, and correspondingly, the second micro-service application receives the decrypted out-of-domain access request, where the decrypted out-of-domain access request is used to request a third micro-service application in the private cloud.

The request distribution module sends the decrypted out-of-domain access request to the second micro-service application through the encrypted rpc protocol, and correspondingly, the second micro-service application can receive the decrypted out-of-domain access request.

And S814, the second micro service application determines whether the access is legal or not based on the decrypted out-of-domain access request and the MCACL.

The second micro service application can compare and verify the information in the decrypted out-of-domain access request with the content of the MCACL, and if the verification is successful, the access is determined to be legal; if the verification is not successful, an non-compliance request can be sent to the multi-cloud micro-service security management platform, and accordingly the multi-cloud micro-service security management platform receives the non-compliance request and records the non-compliance request through the system monitoring module.

S815, if the access is legal, the second micro service application encrypts the decrypted out-of-domain access request with the corresponding key in the mcalcl.

If the access is legal, the second micro service application may determine, according to the mcalcl, an encryption manner of a third secure micro engine corresponding to the third micro service application, and encrypt the access request outside the domain by using a corresponding key in the mcalcl.

S816, the second micro service application sends the encrypted out-of-domain access request to a third security micro engine corresponding to the third micro service application, and correspondingly, the third security micro engine receives the encrypted out-of-domain access request.

Optionally, if the multi-cloud micro-service security management platform receives an unconventional condition or too many unsafe accesses of the cloud access platform and the security micro-engine, the access key may be changed in time through the msalcl permission rule management module and the mcalcl permission rule management module, so that the secure access is ensured.

It should be understood that, the sequence numbers of the above processes do not imply any order of execution, and the order of execution of the processes should be determined by their functions and inherent logic, and should not limit the implementation process of the embodiments of the present application in any way.

The security authentication method according to the embodiment of the present application is described in detail above with reference to fig. 1 and 8, and the security authentication device according to the embodiment of the present application is described in detail below with reference to fig. 9 and 12.

Fig. 9 illustrates a security authentication apparatus 900 according to an embodiment of the present application. The apparatus 900 includes: a transceiver module 910 and a processing module 920.

The transceiver module 910 is configured to: a first request message is received, the first request message requesting access to a first microservice application.

The processing module 920 is configured to: determining whether the access is legal or not based on the first request message and a first access control list, wherein the first access control list comprises access permissions among different cloud units; and if the access is legal, encrypting the first request message by adopting a corresponding key in a second access control list, wherein the second access control list comprises access permissions among different micro-service applications.

The transceiver module 910 is further configured to: and sending the encrypted first request message to a first security micro-engine corresponding to the first micro-service application.

Optionally, the transceiver module 910 is specifically configured to: a first access control list from a multi-cloud micro-service security management platform is received.

Optionally, the transceiver module 910 is further configured to: sending a second request message to the multi-cloud micro-service security management platform, wherein the second request message is used for requesting registration of the device and carries user configuration information; and receiving a response message from the multi-cloud micro-service security management platform, wherein the response message carries the encryption mode and/or the first access control list of the device.

The processing module 920 is further configured to: the encryption mode and/or the first access control list of the device is saved.

In an alternative example, as will be understood by those skilled in the art, the apparatus 900 may be embodied as a cloud access platform in the above embodiments, or the functions of the cloud access platform in the above embodiments may be integrated in the apparatus 900. The above functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above. For example, the transceiver module 910 may be a communication interface, such as a transceiver interface. The apparatus 900 may be configured to perform various processes and/or steps corresponding to the cloud access platform in the foregoing method embodiment.

Fig. 10 shows a schematic block diagram of another security authentication apparatus 1000 provided in an embodiment of the present application, where the apparatus 1000 includes: a transceiver module 1010 and a processing module 1020.

The transceiver module 1010 is configured to: and receiving an encrypted first request message, wherein the first request message is used for requesting to access the first micro-service application.

The processing module 1020 is configured to: determining whether the access is legal or not based on the encrypted first request message and a second access control list, wherein the second access control list comprises access permissions among different micro-service applications; and if the access is legal, decrypting the encrypted first request message by adopting a corresponding key in the second access control list.

The transceiver module 1010 is further configured to: and sending the decrypted first request message to the first micro-service application.

Optionally, the transceiver module 1010 is specifically configured to: and receiving a second access control list from the multi-cloud micro-service security management platform.

Optionally, the transceiver module 1010 is further configured to: sending a third request message to the multi-cloud micro-service security management platform, wherein the third request message is used for requesting registration of the device and carries user configuration information; and receiving a response message from the multi-cloud micro-service security management platform, wherein the response message carries the encryption mode and/or the second access control list of the device.

The processing module 1020 is further configured to: the encryption mode and/or the second access control list of the device is saved.

In an alternative example, those skilled in the art will appreciate that the apparatus 1000 may be embodied as the first security microengine in the above-described embodiment, or the functions of the first security microengine in the above-described embodiment may be integrated into the apparatus 1000. The above functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above. For example, the transceiver module 1010 may be a communication interface, such as a transceiver interface. The apparatus 1000 may be configured to perform various processes and/or steps corresponding to the first security microengine in the method embodiments described above.

Fig. 11 shows a schematic block diagram of another security authentication apparatus 1100 provided in an embodiment of the present application, where the apparatus 1100 includes: a transceiver module 1110 and a processing module 1120.

The transceiver module 1110 is configured to: and receiving a second request message from the cloud access platform, wherein the second request message is used for requesting registration of the cloud access platform and carries user configuration information.

The processing module 1120 is configured to: the method comprises the steps of storing user configuration information of the cloud access platform and updating a first access control list, wherein the first access control list comprises access rights among different cloud units.

The transceiver module 1110 is further configured to: and sending a response message to the cloud access platform, wherein the response message carries the encryption mode and/or the first access control list of the cloud access platform.

Optionally, the transceiver module 1110 is specifically configured to: and receiving a third request message from the security micro-engine, wherein the third request message is used for requesting to register the security micro-engine and carries user configuration information.

The processing module 1120 is specifically configured to: user configuration information for the secure microengines is saved and a second access control list is updated, the second access control list including access rights between different microservice applications.

The transceiver module 1110 is further configured to: and sending a response message to the security microengine, wherein the response message carries the encryption mode and/or the second access control list of the first security microengine.

In an alternative example, as will be understood by those skilled in the art, the apparatus 1100 may be embodied as the multi-cloud micro-service security management platform in the above embodiment, or the functions of the multi-cloud micro-service security management platform in the above embodiment may be integrated in the apparatus 1100. The above functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above. For example, the transceiver module 1110 may be a communication interface, such as a transceiver interface. The apparatus 1100 may be configured to perform various processes and/or steps corresponding to the multi-cloud micro-service security management platform in the foregoing method embodiments.

It should be appreciated that the apparatus 900, the apparatus 1000 and the apparatus 1100 herein are embodied in the form of functional modules. The term module, as used herein, may refer to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (e.g., a shared, dedicated, or group processor), and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that support the described functionality.

In an embodiment of the present application, the apparatus 900, the apparatus 1000, and the apparatus 1100 in fig. 9 to 11 may also be a chip or a chip system, for example: system on chip (SoC). Correspondingly, the transceiver module may be a transceiver circuit of the chip, and is not limited herein.

Fig. 12 illustrates another security authentication apparatus 1200 provided in an embodiment of the present application. The apparatus 1200 includes: a processor 1210, a transceiver 1220, and a memory 1230. Wherein the processor, the transceiver and the memory are in communication with each other through the internal connection path, the memory is used for storing instructions, and the processor is used for executing the instructions stored by the memory to control the transceiver to transmit and/or receive signals.

It should be understood that the apparatus 1200 may be embodied as the cloud access platform, the first security micro engine, or the multi-cloud micro-service security management platform in the foregoing embodiment, or each step and/or flow corresponding to the cloud access platform, the first security micro engine, or the multi-cloud micro-service security management platform in the foregoing embodiment. Optionally, the memory 1230 may include both read-only memory and random-access memory, and provides instructions and data to the processor. The portion of memory may also include non-volatile random access memory. For example, the memory may also store device type information. The processor 1210 may be configured to execute instructions stored in the memory, and when the processor 1210 executes the instructions stored in the memory, the processor 1210 is configured to perform the various steps and/or processes corresponding to the cloud access platform, the first security micro-engine, or the multi-cloud micro-service security management platform. The transceiver 1220 may include a transmitter and a receiver, the transmitter may be configured to implement the steps and/or processes for performing the sending action corresponding to the transceiver, and the receiver may be configured to implement the steps and/or processes for performing the receiving action corresponding to the transceiver.

It should be understood that in the embodiment of the present application, the processor of the above apparatus may be a Central Processing Unit (CPU), and the processor may also be other general processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software elements in a processor. The software elements may be located in ram, flash, rom, prom, or eprom, registers, etc. as is well known in the art. The storage medium is located in a memory, and a processor executes instructions in the memory, in combination with hardware thereof, to perform the steps of the above-described method. To avoid repetition, it is not described in detail here.

The present application provides a readable computer storage medium for storing a computer program for implementing the secure authentication method shown in the various possible implementations in the above embodiments.

The present application provides a chip system, which is used to support the above security authentication method shown in various possible implementation manners in the embodiments.

The present application provides a computer program product comprising a computer program (which may also be referred to as code, or instructions) which, when run on a computer, can perform the various possible security authentication methods of the embodiments described above.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a portable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, an optical disk, or other various media capable of storing program codes.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1.A security authentication method is applied to a system comprising a plurality of cloud units, wherein each cloud unit comprises a cloud access platform, a security micro-engine and a micro-service application, and the method comprises the following steps:

the cloud access platform receives a first request message, wherein the first request message is used for requesting to access a first micro-service application in the cloud unit;

the cloud access platform determines whether the access is legal or not based on the first request message and a first access control list, wherein the first access control list comprises access permissions among different cloud units;

if the access is legal, the cloud access platform encrypts the first request message by adopting a corresponding key in a second access control list, wherein the second access control list comprises access permissions among different micro-service applications;

and the cloud access platform sends the encrypted first request message to a first security micro-engine corresponding to the first micro-service application.

2. The method of claim 1, further comprising:

the cloud access platform receives the first access control list from a multi-cloud micro-service security management platform.

3. The method according to claim 1 or 2, characterized in that the method further comprises:

the cloud access platform sends a second request message to a multi-cloud micro-service security management platform, wherein the second request message is used for requesting registration of the cloud access platform and carries user configuration information;

the cloud access platform receives a response message from the multi-cloud micro-service security management platform, wherein the response message carries an encryption mode of the cloud access platform and/or the first access control list;

and the cloud access platform saves the encryption mode of the cloud access platform and/or the first access control list.

4. A security authentication method is applied to a system comprising a plurality of cloud units, wherein each cloud unit comprises a cloud access platform, a security micro-engine and a micro-service application, and the method comprises the following steps:

a first security micro-engine receives an encrypted first request message, wherein the first request message is used for requesting to access a first micro-service application in the cloud unit;

the first security microengine determines whether the access is legal or not based on the encrypted first request message and a second access control list, wherein the second access control list comprises access permissions among different microservice applications;

if the access is legal, the first security microengine decrypts the encrypted first request message by adopting a corresponding key in the second access control list;

and the first security microengine sends the decrypted first request message to the first micro-service application.

5. The method of claim 4, further comprising:

the first security micro-engine receives the second access control list from a multi-cloud micro-service security management platform.

6. The method according to claim 4 or 5, characterized in that the method further comprises:

the first security micro engine sends a third request message to a multi-cloud micro-service security management platform, wherein the third request message is used for requesting to register the first security micro engine and carries user configuration information;

the first security micro-engine receives a response message from the multi-cloud micro-service security management platform, wherein the response message carries an encryption mode of the first security micro-engine and/or the second access control list;

the first security microengine saves the encryption mode of the first security microengine and/or the second access control list.

7. A security authentication method is applied to a system comprising a multi-cloud micro-service security management platform and a plurality of cloud units, wherein the cloud units comprise a cloud access platform, a security micro-engine and a micro-service application, and the method comprises the following steps:

the method comprises the steps that a multi-cloud micro-service security management platform receives a second request message from a cloud access platform, wherein the second request message is used for requesting registration of the cloud access platform and carries user configuration information;

the multi-cloud micro-service security management platform saves user configuration information of the cloud access platform and updates a first access control list, wherein the first access control list comprises access permissions among different cloud units;

the multi-cloud micro-service security management platform sends a response message to the cloud access platform, wherein the response message carries the encryption mode of the cloud access platform and/or the first access control list.

8. The method of claim 7, further comprising:

the multi-cloud micro-service security management platform receives a third request message from a security micro-engine, wherein the third request message is used for requesting registration of the security micro-engine and carries user configuration information;

the multi-cloud micro-service security management platform saves user configuration information of the security micro-engine and updates a second access control list, wherein the second access control list comprises access rights among different micro-service applications;

and the multi-cloud micro-service security management platform sends a response message to the security micro-engine, wherein the response message carries the encryption mode of the first security micro-engine and/or the second access control list.

9. A security authentication apparatus, comprising:

the receiving and sending module is used for receiving a first request message, and the first request message is used for requesting to access a first micro-service application in the cloud unit;

the processing module is used for determining whether the access is legal or not based on the first request message and a first access control list, and the first access control list comprises access permissions among different cloud units; if the access is legal, the first request message is encrypted by adopting a corresponding key in a second access control list, wherein the second access control list comprises access permissions among different micro-service applications;

the transceiver module is further configured to: and sending the encrypted first request message to a first security microengine corresponding to the first microservice application.

10. A security authentication apparatus, comprising:

the receiving and sending module is used for receiving an encrypted first request message, and the first request message is used for requesting to access a first micro-service application in the cloud unit;

the processing module is used for determining whether the access is legal or not based on the encrypted first request message and a second access control list, and the second access control list comprises access permissions among different micro-service applications; if the access is legal, decrypting the encrypted first request message by adopting a corresponding key in the second access control list;

the transceiver module is further configured to: and sending the decrypted first request message to the first micro-service application.

11. A security authentication apparatus, comprising:

the receiving and sending module is used for receiving a second request message from a cloud access platform, the second request message is used for requesting registration of the cloud access platform, and the second request message carries user configuration information;

the processing module is used for storing user configuration information of the cloud access platform and updating a first access control list, wherein the first access control list comprises access permissions among different cloud units;

the transceiver module is further configured to: and sending a response message to the cloud access platform, wherein the response message carries the encryption mode of the cloud access platform and/or the first access control list.

12. A security authentication apparatus, comprising: a processor coupled with a memory for storing a computer program that, when invoked by the processor, causes the apparatus to perform the method of any of claims 1 to 8.

13. A chip system, comprising: a processor for calling and running a computer program from a memory so that a device on which the system-on-chip is installed performs the method of any one of claims 1 to 8.

14. A computer-readable storage medium, having stored thereon a computer program which, when run on a computer, causes the computer to perform the method of any one of claims 1 to 8.