CN112765639B - Security micro-service architecture based on zero trust access strategy and implementation method - Google Patents
Security micro-service architecture based on zero trust access strategy and implementation method Download PDFInfo
- Publication number
- CN112765639B CN112765639B CN202110122187.2A CN202110122187A CN112765639B CN 112765639 B CN112765639 B CN 112765639B CN 202110122187 A CN202110122187 A CN 202110122187A CN 112765639 B CN112765639 B CN 112765639B
- Authority
- CN
- China
- Prior art keywords
- access
- user
- module
- service
- micro
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Storage Device Security (AREA)
Abstract
The invention provides a security micro-service architecture based on a zero trust access strategy and an implementation method thereof, wherein the architecture comprises the following steps: identity authentication center, little service area, inside security territory, public API agent and private API agent, the identity authentication center includes: the system comprises an Access policy module, a encryption and decryption module, a safe production authentication module and a trust engine module, wherein the trust engine module executes identity verification and generates a short-term Access Token and a Refresh Token; the realization process is as follows: requesting resources, single sign-on and authenticating identities, assigning permissions, returning Token, filtering and checking Token validity to perform access; when the caller needs to reach the internal security domain, the private API proxy is accessed through the Facade service and passes the matching additional authorization level. The invention generates the short-term Token through the authentication and authorization mechanism so as to protect the distributed micro-service isolated from the front-end system, adjusts the security priority level of the micro-service in real time through the private API agent, reduces the possible attack surface of the micro-service system and realizes the defense-in-depth strategy.
Description
Technical Field
The invention belongs to the technical field of micro services, and particularly relates to a security micro service architecture based on a zero trust access strategy and an implementation method thereof.
Background
Security is a long standing problem in network systems, and as microservices appear, security becomes more challenging. By breaking down the system into smaller, independent and distributed units, a large amount of ingress point and communication traffic occurs. Microservices are becoming a new specification for software development in enterprise design models, allowing software systems to be built by composing lightweight services. Especially in the aspect of developing complex and distributed application programs, the method is an architectural design mode and aims to solve the problems of expandability, scalability and easy maintenance of online services.
Furthermore, trust cannot simply be established between individual microservices in a network, which are usually from different unknown providers. The problems of the current micro service are as follows: (1) The attack surface will increase significantly as the logical and middle layers of the application are split into many smaller and independent parts. (2) The loose coupling of the front-end and back-end allows multiple front-end systems to communicate with back-end services, increasing the likelihood of attacks.
Zero trust emphasizes "no trust anyone, identity verification everyone", each deployed microservice must be protected on demand using fine-grained security policies that will scrutinize the incoming and outgoing traffic of the microservice. Through a zero trust mechanism, safe access among the micro services and a trusted safe environment in the container can be constructed, and all service access in the network is required to be subjected to identity verification and encryption authorization.
Based on the above analysis, a secure microservice scheme based on a zero trust access policy is needed in the prior art.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a security microservice architecture based on a zero trust access strategy and an implementation method thereof.
In order to solve the technical problems, the invention adopts the following technical scheme:
a secure microservice architecture based on a zero trust access policy, comprising: an identity authentication center, a micro-service domain, an internal security domain, a public API agent, and a private API agent,
wherein, the identity authentication center includes: the system comprises an access policy module, an encryption and decryption module, a safe production authentication module and a trust engine module, wherein the access policy module formulates an access control policy based on roles according to a minimum privilege principle; the encryption and decryption module is used for transparently encrypting data; the secure production authentication module is used for securely identifying micro-services in dynamic and heterogeneous environments; the trust engine module is responsible for identity verification and generates short-term Access Token and Refresh Token, the user accesses the micro-service through Token,
the micro-service domain is used to store public services,
the internal security domain is used to store specific high-level services or management services,
the public API agent is used for providing single sign-on and has a filtering mechanism, and is used for receiving the access request of the user and calling the trust engine module of the identity authentication center,
the private API proxy has an additional authorization scheme, and when a caller needs to reach the internal security domain, the private API proxy is accessed through the Facade service and delivers a matching additional authorization level.
Further, the secure microservice architecture further comprises:
a security risk center, the security risk center comprising: the system comprises a central log aggregation module, a vulnerability detection module and a task arrangement module, wherein the central log aggregation module is used for continuously monitoring service and user recording activities; the vulnerability detection module is used for scanning the system and helping developers to identify vulnerabilities as soon as possible; the task arranging module is used for combining the safety scanning tasks according to a logical relation to form an automatic monitoring and feedback mechanism.
A secure micro-service access implementation method based on a zero trust access policy, which implements a micro-service authorization process based on the secure micro-service architecture based on the zero trust access policy claimed in the claims, the method comprising the following steps:
a user requesting a protected resource hosted on a microservice;
the user performs single sign-on, and the public API agent performs multi-factor identity authentication;
generating and submitting Credential after the verification is passed, and calling the trust engine module through a public API agent;
the trust engine module requests the access strategy module to dynamically distribute the authority to the user;
the trust engine module returns short-term Access Token and Refresh Token to the front end;
the front end stores the Refresh Token and calls the micro-service again through the Access Token;
the public API proxy executes a filtering mechanism that issues an authorization check to the trust engine module to perform an access authorization operation.
Further, the access authorization operation includes:
when the trust engine module verifies that the Access Token is valid, sending the request to the micro service to transmit the request required by the user, so that the user can Access the micro service; and/or
When the trust engine module verifies that the Access Token is invalid, the user is denied Access to the microservice; and/or
When the trust engine module verifies that the Access Token is expired, a new Access Token is requested from the trust engine module through the Refresh Token and the verification operation is executed again.
Further, the step of requesting, by the trust engine module, the access policy module to dynamically assign the right to the user includes:
a user requests the authority from the trust engine;
the trust engine module requests the access strategy module to evaluate the trust degree of the user;
the access strategy module detects the account and the associated attribute;
the query log aggregation module automatically analyzes based on past user behavior to obtain an acceptable risk level for user access to perform an assign permissions operation.
Further, the operation of assigning the right includes:
when the acceptable risk level of user access is acceptable, detecting the request asset state, calling a dynamic identifier of a microprogram to a safety production authentication module, and performing authority distribution on the user; and/or
When the acceptable risk level of the user access is not acceptable, the user is not assigned the right.
Further, when the user invokes the micro-service in the internal security domain, the method further comprises the following steps:
a user calls a Facade service and sends a request to a private API agent through the Facade;
the private API agent executes a filtering mechanism to verify the additional authorization Credential provided by the user;
and executing the internal security domain access authorization operation based on the verification result of the additional authorization Credential.
Further, the internal security domain access authorization operation includes:
when the trust engine module verifies that the additional authorization Credential is successful, the private API agent requests the access policy module to dynamically allocate additional authority to the user and allows the user to access the microservice in the internal security domain; and/or
And when the trust engine module fails to verify the additional authorization Credential, rejecting the access request of the user.
Compared with the prior art, the invention has the following beneficial effects: the invention generates the short-term Token through the authentication and authorization mechanism, thereby protecting the distributed micro-service isolated from the front-end system, adjusting the security priority level of the micro-service in real time by introducing the private API agent, reducing the possible attack surface of the micro-service system and providing a depth defense strategy. The concrete aspects are as follows:
1) The trust engine manages and controls the authentication and authorization of the user based on a zero trust mechanism, and reduces possible attack surfaces.
2) And (3) using technologies such as transparent encryption and the like, and encrypting the static data by using the safety key changed at regular time to ensure the data security in various heterogeneous databases.
3) Important micro-services are stored in an internal security domain, multi-layer security control of the system is achieved through a private API agent, and deep defense is built.
4) The access policy is dynamically authorized based on the least privilege principle, only the access right is granted to the user who is not only authenticated but also has the right to access the API, and the API access right is granted and expanded only according to the requirement.
5) And the safe missed scanning tasks are automatically arranged, so that the safety risk investigation efficiency is improved.
Drawings
Fig. 1 is a schematic diagram of a framework of a security microservice architecture based on a zero-trust access policy in an embodiment of the present invention.
FIG. 2 is a flow chart illustrating a process for a user to invoke microservice in an embodiment of the present invention.
FIG. 3 is a flowchart illustrating rights assignment in an embodiment of the invention.
FIG. 4 is a flowchart illustrating a process for a user to invoke microservice in an internal security domain in an embodiment of the present invention.
Detailed Description
The invention will be further described with reference to examples of embodiments shown in the drawings.
As shown in fig. 1, the present embodiment discloses a security microservice architecture based on a zero-trust access policy, which specifically includes: an identity authentication center, a security risk center, a micro-service domain, an internal security domain, a public API proxy, and a private API proxy.
Specifically, the identity authentication center includes: the system comprises an access strategy module, an encryption and decryption module, a safe production authentication module and a trust engine module, wherein the access strategy module formulates an access control strategy based on roles according to a minimum privilege principle; the encryption and decryption module is used for transparently encrypting the data; the safety production authentication module is used for safely identifying the micro-service in the dynamic and heterogeneous environments; the trust engine module is responsible for identity verification and generates short-term Access Token and Refresh Token, and the user accesses the micro-service through Token.
The security risk center comprises: the system comprises a central log aggregation module, a vulnerability detection module and a task arrangement module, wherein the central log aggregation module is used for continuously monitoring service and user recording activities; the vulnerability detection module is used for scanning the system and helping developers to identify vulnerabilities as soon as possible; and the task arranging module is used for combining the safety scanning tasks according to a logical relation to form an automatic monitoring and feedback mechanism.
The micro-service domain is used to store most of the public services. The internal security domain is then used to store specific high-level services or management services.
The public API agent is used for providing single sign-on and has a filtering mechanism, and is used for receiving an access request of a user and calling a trust engine module of the identity authentication center.
The private API proxy has an additional authorization scheme to access the private API proxy through the Facade service and pass on the matching additional authorization level when the caller needs to reach the internal security domain.
The concepts of zero trust mechanism, single sign-on, least privilege principle, transparent encryption, log aggregation, and security services orchestration involved in this embodiment are explained as follows:
the zero trust mechanism: the core idea of the zero trust mechanism is that an organization should not automatically trust any user or service within or outside its boundaries, and must validate and grant access to all access requests.
Single sign-on: the single sign-on can intensively verify the identity of the user, and when the user sends an access request, the multi-factor verification is carried out on the user.
Least privileged principle: the least privileged principle requires the most stringent set of permissions granted to users and their programs to perform the required tasks to limit the damage caused by security events.
Transparent encryption: static data encryption is provided for structured databases and unstructured files through centralized key management, transparent to users, microservices and infrastructure.
And log aggregation: the system logs and the behavior logs of multiple sources are centralized and processed, so that the problem range of the system can be narrowed more quickly in security events, and the system can be monitored continuously.
Arranging security services: the workflow is formed by mutually calling a series of independent safety services, and the independent safety services form a complete workflow by mutually calling, so that the workload is reduced, and repeatable processes and operations are simplified.
According to the foregoing security microservice architecture, the present embodiment further provides a method for implementing security microservice access based on a zero trust access policy, as shown in fig. 2, the method includes the following steps:
(1) A user requests a protected resource hosted on a microservice.
(2) The user performs single sign-on, and the public API agent performs multi-factor authentication. Here, multi-factor verification includes, but is not limited to: 1) An account password; 2) Scanning the two-dimensional code; 3) A CA certificate; 4) And (5) short message pushing.
(3) And generating and submitting the Credential after the verification is passed, and calling the trust engine module through the public API agent.
(4) The trust engine module requests the access policy module to dynamically assign permissions to the user, requiring the lowest permission granted to the user and its programs to perform the required tasks.
As shown in fig. 3, the specific right assignment process in step (4) includes:
(41) The user requests the rights from the trust engine.
(42) The trust engine module requests the access policy module to evaluate the user's trust level.
(43) The access policy module detects accounts and associated attributes. Here, the association attribute includes: 1) A user software version; 2) A user group member; 3) IP and MAC address; 4) The time at which the request was made; 5) Already owned Credential.
(44) The query log aggregation module automatically analyzes based on past user behavior to obtain an acceptable risk level for user access to perform an assign permissions operation. Here, past user behaviors include: 1) A resource that has been accessed; 2) Owned digital assets; 3) Permission levels have been assigned in the past.
In step (44), assigning the rights operation comprises:
when the acceptable risk level of user access is acceptable, detecting the state of the request asset, calling a dynamic identifier of the microprogram to a safety production authentication module so as to determine whether the target microprogram is visible or not and the state of the target microprogram, and performing authority distribution on the user after the detection is passed; and/or
And when the acceptable risk level of the user access is not acceptable, the user is not assigned the right.
(5) The trust engine module returns a short-term Access Token and a Refresh Token to the front end, wherein the Access Token is short-term effective, and the Refresh Token needs to request a new Access Token again when the time is out.
(6) The front end of the user stores the Refresh Token and calls the micro-service again through the Access Token.
(7) The public API proxy executes a filtering mechanism that issues an authorization check to the trust engine module to perform an Access authorization operation, here checking the validity of the Access Token.
In step (7), the access authorization operation specifically includes:
when the trust engine module verifies that the Access Token is valid, sending the request to the micro service to transmit the request required by the user, so that the user can Access the micro service; and/or
When the trust engine module verifies that the Access Token is invalid, the user is denied Access to the microservice; and/or
When the trust engine module verifies that the Access Token is expired, a new Access Token is requested from the trust engine module through the Refresh Token, and the verification operation is executed again.
In addition, based on the security microservice architecture, when a user invokes a microservice in the internal security domain, as shown in fig. 4, the method further includes the following steps:
(8) A user calls a Facade service and sends a request to a private API agent through the Facade;
(9) The private API agent executes a filtering mechanism to verify the additional authorization Credential provided by the user;
(10) And executing an internal security domain access authorization operation based on the verification result of the additional authorization Credential.
In step (10), the internal security domain access authorization operation includes:
when the trust engine module verifies that the additional authorization Credential is successful, the private API agent requests the access policy module to dynamically allocate additional authority to the user and allows the user to access the microservice in the internal security domain; and/or
And when the trust engine module fails to verify the additional authorization Credential, rejecting the access request of the user.
Based on the security micro-service architecture and the security micro-service access implementation method of the embodiment, the distributed micro-service isolated from the front-end system is protected through an identity authentication and authorization mechanism, the minimum privilege principle is ensured by adjusting the security priority level in real time, and the efficiency of troubleshooting on security risks is improved by arranging and scanning tasks through tasks. Therefore, potential safety hazards in the micro-service system are effectively reduced through depth defense.
The protective scope of the present invention is not limited to the above-described embodiments, and it is apparent that various modifications and variations can be made to the present invention by those skilled in the art without departing from the scope and spirit of the present invention. It is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.
Claims (7)
1. A secure microservice architecture based on a zero-trust access policy, comprising: an identity authentication center, a micro-service domain, an internal security domain, a public API agent, a private API agent, and a security risk center,
wherein, the identity authentication center includes: the system comprises an access strategy module, an encryption and decryption module, a safety production authentication module and a trust engine module, wherein the access strategy module formulates an access control strategy based on roles according to a minimum privilege principle; the encryption and decryption module is used for transparently encrypting data; the secure production authentication module is used for securely identifying micro-services in dynamic and heterogeneous environments; the trust engine module is responsible for identity verification and generates short-term Access Token and Refresh Token, the user accesses the micro-service through Token,
the micro-service domain is used to store public services,
the internal security domain is used to store certain high-level services or management services,
the public API agent is used for providing single sign-on and has a filtering mechanism, and is used for receiving the access request of the user and calling the trust engine module of the identity authentication center,
the private API agent has an additional authorization scheme to access the private API agent and pass a matching additional authorization level through a Facade service when a caller needs to reach the internal security domain,
the security risk center includes: the system comprises a central log aggregation module, a vulnerability detection module and a task arrangement module, wherein the central log aggregation module is used for continuously monitoring service and user record activities; the vulnerability detection module is used for scanning the system and helping a developer to identify vulnerabilities as soon as possible; the task arranging module is used for combining the safety scanning tasks according to a logical relation to form an automatic monitoring and feedback mechanism.
2. A secure micro-service access implementation method based on a zero-trust access policy, which implements a micro-service authorization process based on the secure micro-service architecture based on the zero-trust access policy of claim 1, the method comprising the following steps:
a user requesting a protected resource hosted on a microservice;
the user performs single sign-on, and the public API agent performs multi-factor identity authentication;
generating and submitting Credential after passing the verification, and calling the trust engine module through the public API agent;
the trust engine module requests the access strategy module to dynamically distribute the authority to the user;
the trust engine module returns short-term Access Token and Refresh Token to the front end;
the front end stores Refresh Token and calls the micro-service again through the Access Token;
the public API proxy executes a filtering mechanism that issues an authorization check to the trust engine module to perform an access authorization operation.
3. The method for implementing secure microservice access based on zero trust access policy of claim 2, wherein:
the access authorization operation comprises:
when the trust engine module verifies that the Access Token is valid, sending the request to the micro service to transmit the request required by the user, so that the user can Access the micro service; and/or
When the trust engine module verifies that the Access Token is invalid, the user is denied Access to the microservice; and/or
When the trust engine module verifies that the Access Token is expired, a new Access Token is requested from the trust engine module through the Refresh Token, and the verification operation is executed again.
4. The method for implementing secure microservice access based on zero-trust access policy of claim 2, wherein:
the step that the trust engine module requests the access policy module to dynamically allocate the authority to the user comprises the following steps:
a user requests the authority from the trust engine;
the trust engine module requests the access strategy module to evaluate the trust degree of the user;
the access strategy module detects the account and the associated attribute;
the query log aggregation module automatically analyzes based on past user behavior to obtain an acceptable risk level for user access to perform an assign permissions operation.
5. The method for implementing secure microservice access based on zero-trust access policy of claim 4, wherein:
the operation of distributing the authority comprises the following steps:
when the acceptable risk level of user access is acceptable, detecting the asset request state, calling a dynamic identifier of the microprogram to a safety production authentication module, and performing authority distribution on the user; and/or
And when the acceptable risk level of the user access is not acceptable, the user is not assigned the right.
6. The method for implementing secure microservice access based on zero-trust access policy of claim 2, wherein:
when the user calls the micro service in the internal security domain, the method further comprises the following steps:
a user calls a Facade service and sends a request to a private API agent through the Facade;
the private API agent executes a filtering mechanism to verify the additional authorization Credential provided by the user;
and executing the internal security domain access authorization operation based on the verification result of the additional authorization Credential.
7. The method for implementing secure microservice access based on zero-trust access policy of claim 6, wherein:
the internal security domain access authorization operation comprises:
when the trust engine module successfully verifies the additional authorization Credential, the private API agent requests the access strategy module to dynamically distribute additional authority to the user and allows the user to access the micro-service in the internal security domain; and/or
And when the trust engine module fails to verify the additional authorization Credential, rejecting the access request of the user.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110122187.2A CN112765639B (en) | 2021-01-27 | 2021-01-27 | Security micro-service architecture based on zero trust access strategy and implementation method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110122187.2A CN112765639B (en) | 2021-01-27 | 2021-01-27 | Security micro-service architecture based on zero trust access strategy and implementation method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112765639A CN112765639A (en) | 2021-05-07 |
| CN112765639B true CN112765639B (en) | 2022-11-04 |
Family
ID=75706544
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110122187.2A Active CN112765639B (en) | 2021-01-27 | 2021-01-27 | Security micro-service architecture based on zero trust access strategy and implementation method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112765639B (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113542238B (en) * | 2021-06-29 | 2023-06-16 | 上海派拉软件股份有限公司 | Zero trust-based risk judging method and system |
| CN113596009B (en) * | 2021-07-23 | 2023-03-24 | 中国联合网络通信集团有限公司 | Zero trust access method, system, zero trust security proxy, terminal and medium |
| CN113472820A (en) * | 2021-09-06 | 2021-10-01 | 中铁信弘远(北京)软件科技有限责任公司 | Cloud resource security isolation control method and system based on zero trust model |
| CN113905048A (en) * | 2021-09-30 | 2022-01-07 | 北京蓝海医信科技有限公司 | Method and device for scheduling engine instance by cluster manager and computer equipment |
| CN113676336B (en) * | 2021-10-22 | 2022-02-08 | 深圳市明源云采购科技有限公司 | Microservice access proxy method, apparatus and storage medium |
| CN114338076B (en) * | 2021-11-11 | 2023-04-07 | 清华大学 | Distributed cross-device access control method and device suitable for smart home environment |
| CN114553540B (en) * | 2022-02-22 | 2024-03-08 | 平安科技（深圳）有限公司 | Zero trust-based Internet of things system, data access method, device and medium |
| CN114465814A (en) * | 2022-03-11 | 2022-05-10 | 江苏天创科技有限公司 | Zero trust safety protection system and protection method |
| CN115001870B (en) * | 2022-08-02 | 2022-11-01 | 国汽智控(北京)科技有限公司 | Information security protection system, method and storage medium |
| CN116389167B (en) * | 2023-05-29 | 2023-08-15 | 南京信息工程大学 | Information access security system based on growing type iterative trust strategy |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020015838A1 (en) * | 2018-07-20 | 2020-01-23 | Nokia Solutions And Networks Oy | Zero trust perimeterization for microservices |
| WO2020106973A1 (en) * | 2018-11-21 | 2020-05-28 | Araali Networks, Inc. | Systems and methods for securing a workload |
| CN110086822B (en) * | 2019-05-07 | 2021-07-27 | 北京智芯微电子科技有限公司 | Method and system for implementing micro-service architecture-oriented unified identity authentication strategy |
| US11233826B2 (en) * | 2019-07-18 | 2022-01-25 | Hitachi, Ltd. | System and method of microservice-based application deployment with automating authorization configuration |
| CN112118242A (en) * | 2020-09-09 | 2020-12-22 | 厦门安胜网络科技有限公司 | Zero trust authentication system |
| CN112118102A (en) * | 2020-10-21 | 2020-12-22 | 国网天津市电力公司 | Dedicated zero trust network system of electric power |
-
2021
- 2021-01-27 CN CN202110122187.2A patent/CN112765639B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN112765639A (en) | 2021-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112765639B (en) | Security micro-service architecture based on zero trust access strategy and implementation method | |
| Indu et al. | Identity and access management in cloud environment: Mechanisms and challenges | |
| US10567438B2 (en) | Providing privileged access to non-privileged accounts | |
| Modi et al. | A survey on security issues and solutions at different layers of Cloud computing | |
| Ertaul et al. | Security Challenges in Cloud Computing. | |
| US9635029B2 (en) | Role-based access control permissions | |
| US9639678B2 (en) | Identity risk score generation and implementation | |
| US20190356661A1 (en) | Proxy manager using replica authentication information | |
| US10333930B2 (en) | System and method for transparent multi-factor authentication and security posture checking | |
| KR20130085472A (en) | Security system for cloud computing service | |
| Kumar | World of cloud computing & security | |
| US20220224535A1 (en) | Dynamic authorization and access management | |
| JP2002063140A (en) | Method for managing access on network, and system for the same | |
| CN111010396A (en) | Internet identity authentication management method | |
| CN113472820A (en) | Cloud resource security isolation control method and system based on zero trust model | |
| Omar et al. | A comparative study of network access control and software-defined perimeter | |
| Otta et al. | Cloud identity and access management solution with blockchain | |
| KR20210026710A (en) | Trust-Aware Role-based System in Public Internet-of-Things | |
| Tutubala et al. | A hybrid framework to improve data security in cloud computing | |
| Priyadharshini et al. | A survey on security issues and countermeasures in cloud computing storage and a tour towards multi-clouds | |
| Waqas et al. | Fault tolerant cloud auditing | |
| KR102347153B1 (en) | Defense command and control(c4i) system with security architecture suitable for cloud computing environment and its authentication and authorization control method | |
| Borazjani | Security issues in cloud computing | |
| Sagar et al. | Information security: safeguarding resources and building trust | |
| Singh et al. | Security in amazon web services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |