WO2021114925A1

WO2021114925A1 - Access control method and access control apparatus

Info

Publication number: WO2021114925A1
Application number: PCT/CN2020/124392
Authority: WO
Inventors: 邓圆
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2019-12-13
Filing date: 2020-10-28
Publication date: 2021-06-17
Also published as: CN111143793A; CN111143793B; TW202123036A; TWI762926B

Abstract

An access control method and an access control apparatus. The access control method comprises: if an access request of a merchant device is received, acquiring device identity information of the merchant device, wherein the access request carries user account authentication information corresponding to the merchant device; on the basis of a target public key certificate and device identity information corresponding to the merchant device, performing device identity verification on the merchant device; when the device identity verification is passed, on the basis of the user account authentication information, performing user identity verification on a user corresponding to the merchant device; when the user identity verification is passed, verifying whether the merchant device is a trusted execution environment; and determining an access control policy of the merchant device, and on the basis of the access control policy, accessing private data of a target member corresponding to the access request.

Description

Access control method and access control device

Technical field

This specification relates to the field of computer technology, in particular to an access control method and an access control device.

Background technique

At present, for the existing private data access system, the merchant's data access calling behavior is mainly controlled based on the merchant's account and key.

However, due to the failure of the security access mechanism of the merchant system or the leakage of merchant data, this may lead to the risk of the merchant’s account and key being leaked. Once the merchant’s account and secret information is leaked, the malicious person can follow After the account and key pass the user identity verification, a large amount of member private data is illegally stolen.

Therefore, it is necessary to improve the traditional access control method of member private data to reduce the risk of private data leakage.

Summary of the invention

The embodiments of the present specification provide an access control method and an access control device, aiming to solve the problem of high leakage risk of existing access methods to member private data.

The embodiments of this specification adopt the following technical solutions.

In the first aspect, an embodiment of this specification provides an access control method, the method includes: if an access request from a merchant device is received, acquiring device identity information of the merchant device, and the access request carries the merchant device Corresponding user account authentication information; based on the target public key certificate corresponding to the merchant device and the device identity information, perform device identity verification on the merchant device; when the device identity verification is passed, authenticate based on the user account The information performs user identity verification on the user corresponding to the merchant device; after the user identity verification is passed, verify whether the merchant device is a trusted execution environment; determine the access control strategy of the merchant device, and based on the access control strategy Access the private data of the target member corresponding to the access request.

In a second aspect, an embodiment of this specification provides an access control device, the device includes: an acquisition module, configured to obtain the device identity information of the merchant device if an access request of the merchant device is received, in the access request Carrying user account authentication information corresponding to the merchant device; a first verification module, configured to perform device identity verification on the merchant device based on the target public key certificate corresponding to the merchant device and the device identity information; second The verification module is used to verify the user identity of the user corresponding to the merchant device based on the user account authentication information after the device identity verification is passed; the third verification module is used to verify the user identity after the user identity verification is passed Whether the merchant equipment is a trusted execution environment; the control module is used to determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.

In a third aspect, an embodiment of this specification provides an electronic device, including: a processor; and a memory arranged to store computer-executable instructions, which when executed, cause the processor to perform the following operations: Upon receiving the access request of the merchant device, the device identity information of the merchant device is obtained, and the access request carries the user account authentication information corresponding to the merchant device; based on the target public key certificate corresponding to the merchant device and all The device identity information is to perform device identity verification on the merchant device; when the device identity verification is passed, the user identity verification is performed on the user corresponding to the merchant device based on the user account authentication information; when the user identity verification is passed, Verify whether the merchant device is a trusted execution environment; determine an access control policy of the merchant device, and access the private data of the target member corresponding to the access request based on the access control policy.

In a fourth aspect, embodiments of this specification provide a computer-readable storage medium that stores one or more programs, and when the one or more programs are executed by an electronic device that includes multiple application programs , The electronic device is caused to perform the following operations: if an access request of the merchant device is received, the device identity information of the merchant device is obtained, and the access request carries the user account authentication information corresponding to the merchant device; The target public key certificate corresponding to the merchant device and the device identity information are used to perform device identity verification on the merchant device; when the device identity verification is passed, the user corresponding to the merchant device is performed based on the user account authentication information User identity verification; after the user identity verification is passed, verify whether the merchant device is a trusted execution environment;

Determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.

The above-mentioned at least one technical solution adopted in the embodiment of this specification achieves the following technical effects: The embodiment of this specification provides a zero-trust-based access control solution to the private data of each member stored in the privacy data system, specifically in the receiving When requesting an access to a merchant device, the device identity corresponding to the merchant device and the user identity of the merchant or user corresponding to the merchant device need to be verified layer by layer to improve the security of access to private data. Specifically, it is necessary to first verify the device identity of the merchant device based on the device identity information of the merchant device and its corresponding and unique target public key certificate to determine whether the merchant device is a merchant device pre-associated with the privacy data system; After the first device identity verification is passed, the corresponding merchant's user identity verification is performed based on the user account authentication information corresponding to the merchant device. After the user identity verification is passed, the device identity of the merchant device needs to be verified a second time to determine the Whether the merchant equipment is a trusted execution environment for the private data of the target member of the system. After performing the corresponding layer-by-layer identity verification on the merchant device, it is necessary to further determine the access control policy of the merchant device to the private data of the target member corresponding to the access request based on the specific situation of the current visit. In this way, it is not only necessary to perform zero-trust-based identity verification on merchant devices for data access, but also to further match specific access control policies to strengthen the control of merchant devices’ access to private data and avoid malicious or improper data access. The operation caused the leakage of private data of members, reduces the risk of leakage of private data, and improves the security of data access.

Description of the drawings

The drawings described here are used to provide a further understanding of the embodiments of this specification, and constitute a part of the embodiments of this specification. The exemplary embodiments and descriptions of this specification are used to explain this specification, and do not constitute an improper limitation of this specification. In the attached picture:

FIG. 1 is a schematic flowchart of an access control method provided by an embodiment of this specification;

Figure 2 is a schematic diagram of the composition of an access control system provided by an embodiment of this specification;

FIG. 3 is a schematic structural diagram of an access control device provided by an embodiment of this specification;

FIG. 4 is a schematic structural diagram of an electronic device provided by an embodiment of this specification.

Detailed ways

In order to make the purpose, technical solutions and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments in this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by a person of ordinary skill in the art without creative work shall fall within the protection scope of this specification.

Regarding the problem that the existing data access control methods stated in the background art may cause a large number of members’ privacy data leakage due to the leakage of merchant’s account and secret information, the embodiments of this specification provide a zero-trust-based data access control solution to achieve Strengthen the purpose of controlling access to merchants to avoid the leakage of members' private data due to malicious or improper operations of visiting merchants.

The technical solutions provided by the embodiments of this specification will be described in detail below with reference to the accompanying drawings.

As shown in FIG. 1, an embodiment of this specification provides an access control method, and the method may specifically include step 101 to step 109.

Step 101: If an access request from a merchant device is received, the device identity information of the merchant device is obtained, and the access request carries user account authentication information corresponding to the merchant device.

Optionally, the aforementioned merchant's access request may specifically include, but is not limited to, a file access request, a database access request, and an Application Programming Interface (API) access request. For different types of access requests, the corresponding private data can be accessed correspondingly.

Optionally, the device identity information of the above-mentioned merchant device may specifically include, but is not limited to, the network media access control (MAC) address, Internet Protocol (IP) address, domain name, and host/host (Host) of the merchant device. )Wait.

Step 103: Perform device identity verification on the merchant device based on the target public key certificate and device identity information corresponding to the merchant device.

Among them, the above-mentioned target public key certificate can be calculated and generated based on a certain encryption algorithm on the device identity information of the merchant's device, and used to uniquely identify the identity of the merchant's device. Specifically, the above-mentioned device identity information of the merchant's device can be updated and maintained on the system side. For example, the device identity information of each merchant device is dynamically updated based on the merchant device's registration information, real-time online and offline information, etc., and the corresponding public key certificate is updated based on the latest device identity information.

Optionally, the target public key certificate may have a certain validity period. Specifically, it may be updated every period of time, or it may be updated when the device identity information of the merchant device changes, so as to ensure that the target public key certificate can be unique based on the target public key certificate. , Accurately identify the merchant’s equipment.

Optionally, this step 103 may be specifically executed as the following content: generate a verification certificate of the merchant device based on the device identity information; if the verification certificate is the same as the target public key certificate, it is determined that the device identity verification is passed.

It can be understood that when receiving an access request from a merchant device, the merchant device's attribute information, that is, device identity information, can be actively collected, and the same encryption algorithm used to generate the target public key certificate is further used to obtain the corresponding verification certificate to be verified. In this way, when it is confirmed that the currently generated verification certificate to be verified is the same as the target public key certificate of the merchant device carried in the access request, it can be considered that the first identity verification of the merchant device has passed. If it is confirmed that the currently generated verification certificate to be verified is different from the target public key certificate of the merchant device carried in the access request, it is considered that the first identity verification of the merchant device has failed.

Step 105: After the device identity verification is passed, perform user identity verification on the user corresponding to the merchant device based on the user account authentication information.

Optionally, this step 105 can be specifically executed as follows: determine whether the user account authentication information contains the target token value; if the user account authentication information contains the target token value and the target token value is valid, then determine the user The identity verification is passed; if the user account authentication information contains the target token value and the target token value is invalid, or if the user account authentication information does not contain the target token value, it will be based on the account and the account contained in the user account authentication information. The key performs user identity verification on the user corresponding to the merchant's device.

It is understandable that when performing user identity verification on the user corresponding to the merchant’s device, that is, the merchant, in order to ensure the merchant’s user experience when accessing the system, there is no need to repeatedly enter the account and key when verifying the user’s user identity. The effect of key shortcut login. Specifically, the corresponding account and key can be entered for verification during one login, and the corresponding target token token value can be generated after verification. Further, if the target token value is carried in subsequent access requests, then It can be directly confirmed that the user's identity verification has passed, and if it is not carried, the user's account and key need to be entered for user identity verification. Wherein, the target token value has a one-to-one correspondence with the user's account and key corresponding to the merchant device, and is unique. Further, the target token value may also have a certain effective time limit, and the token value is updated regularly to avoid the leakage of the user's account and secret information, which may lead to the leakage of private data in the system.

Optionally, the number of users corresponding to the above-mentioned merchant equipment may be one or more, and there is a binding or association relationship between the merchant equipment and the corresponding users.

Step 107: After the user identity verification is passed, verify whether the merchant's equipment is a trusted execution environment.

Step 109: Determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.

The embodiments of this specification provide a zero-trust-based access control solution to the private data of each member stored in the privacy data system. Specifically, when an access request from a merchant device is received, the device identity corresponding to the merchant device and The user identity of the merchant corresponding to the merchant device, that is, the user, is verified layer by layer to improve the security of access to private data. Specifically, it is necessary to first verify the device identity of the merchant device based on the device identity information of the merchant device and its corresponding and unique target public key certificate to determine whether the merchant device is a merchant device pre-associated with the privacy data system; After the first device identity verification is passed, the corresponding merchant's user identity verification is performed based on the user account authentication information corresponding to the merchant device. After the user identity verification is passed, the device identity of the merchant device needs to be verified a second time to determine the Whether the merchant equipment is a trusted execution environment for the private data of the target member of the system. After performing the corresponding layer-by-layer identity verification on the merchant device, it is necessary to further determine the access control policy of the merchant device to the private data of the target member corresponding to the access request based on the specific situation of the current visit. In this way, it is not only necessary to perform zero-trust-based identity verification on merchant devices for data access, but also to further match specific access control policies to strengthen the control of merchant devices’ access to private data and avoid malicious or improper data access. The operation caused the leakage of private data of members, reduces the risk of leakage of private data, and improves the security of data access.

It should be further noted that, in the access control method of the embodiment of this specification, if the device identity verification is performed on the merchant device based on the target public key certificate and device identity information corresponding to the merchant device, that is, the result of the first device identity verification is not passed, You can directly reject the merchant's device access request.

Further, after the device identity verification of the merchant device is passed based on the target public key certificate and device identity information corresponding to the merchant device, if the device identity verification based on the target public key certificate is passed for the first time, the verification information is based on the user account authentication information. If the user corresponding to the merchant device fails the user identity verification, the merchant device's access request can be directly rejected.

Optionally, in the access control method of the embodiment of this specification, the historical devices that have visited the system can also be managed in the form of a historical access device list. Furthermore, when the above step 107 is performed, after the user's identity verification is passed, the historical access device list can be obtained first to verify whether the currently visited merchant device matches the historical access device list, and then the merchant device is determined based on the matching result. The specific method for the second verification of the equipment identity.

Further, in the access control method of the embodiment of the present specification, the above-mentioned access request may also carry the device digital certificate of the merchant device and the digital signature of the target device associated with the device digital certificate.

In this way, if the merchant equipment is not included in the aforementioned historical access equipment list, the merchant’s equipment identity can be verified a second time based on the aforementioned equipment digital certificate and the digital signature of the target equipment associated with the equipment digital certificate, that is, the merchant equipment is verified. Whether it is a trusted execution environment. Specifically, the foregoing step 107 may be specifically executed as the following content: obtaining a list of historically accessed devices; if the merchant's device is not in the list of historically accessed devices, verifying whether the merchant's device is a trusted execution environment based on the device digital certificate and the digital signature of the target device.

Further, the step of verifying whether the merchant’s equipment is a trusted execution environment based on the equipment digital certificate and the digital signature of the target equipment can be specifically executed as follows: Obtain the historical equipment digital signature corresponding to the pre-stored equipment digital certificate; If the signature is the same as the digital signature of the target device, it is determined that the merchant device is a trusted execution environment; if the historical device digital certificate is different from the digital signature of the target device, it is determined that the merchant device is an untrusted execution environment.

It can be understood that the digital signature corresponding to the digital certificate of the merchant's device is stored and maintained in the privacy data system. If the digital certificate reported by the merchant device during access does not match the digital certificate pre-stored in the system, it means that the merchant device is an untrusted execution environment, and if it matches, it is a trusted execution environment.

Further optionally, the access control method of the embodiment of the present specification may further include the following content: adding the merchant's equipment to the historical access equipment list.

It can be understood that after the verification of the device identity based on the device digital certificate of the merchant device and its corresponding device digital signature is completed, the historical access device list is updated to record the merchant device's access status in the list.

Further, in the aforementioned historical access device list, it is also possible to set a label for whether the merchant's device is a trusted execution environment, for example, if it is a trusted execution environment, it is recorded in the effective device list, if it is an untrusted execution environment, then it is recorded in the effective device list. Recorded in the list of black equipment, where the black equipment can specifically be equipment that fails the equipment authentication due to the leakage of the merchant’s account and secret information; further, it is also possible to set a clearing strategy for the merchant equipment maintained in the historical access equipment list , Such as: regularly clear a batch of devices with the earlier loading time or clear all, or decide whether to remove them from the list in time according to the frequency of visits to the merchant’s devices, so as to improve the use value of the historical access device list. Set a certain validity period for merchants’ devices as valid devices or black devices stored in the historical device access list to avoid misjudgment during identity verification due to the failure to update the status of the device in time, causing privacy data leakage or affecting access to privacy data user experience.

Then, in the case where the merchant device is included in the aforementioned historical access device list, it can be efficiently and accurately determined whether it is a trusted execution environment based on whether it has a label of a trusted execution environment. Specifically, the above step 107 can be specifically executed as the following content: obtain a list of historical access equipment; if the merchant device is in the list of historical access equipment, obtain the historical behavior identifier corresponding to the merchant device, and verify whether the merchant device is available based on the historical behavior identifier. Trust the execution environment.

Further, the above step of verifying whether the merchant's equipment is a trusted execution environment based on the historical behavior identification can be specifically executed as follows: if the historical behavior identification indicates that the merchant's equipment is a historically trusted device, it is determined that the merchant's equipment is a trusted execution environment; If the historical behavior identifier indicates that the merchant device is a historical black device, it is determined that the merchant device is an untrusted execution environment.

It is understandable that if the merchant equipment in the historical equipment access list has the label of whether it is a trusted execution environment, that is, the historical behavior identifier indicates that it is a historically trusted equipment, it means that when the merchant equipment belongs to the ranks of valid equipment, it is directly determined to be available. Trusted execution environment; and if the merchant’s device in the historical device access list has a label of whether it is a trusted execution environment, that is, the historical behavior identifier indicates that it is a historical black device, it means that when the merchant’s device is classified as a black device, it is directly determined to be Untrusted execution environment.

Optionally, in the access control method of the embodiment of this specification, the above step 109 may specifically include the following content: based on the access request, obtaining the attribute information of the target member and the access authority information of the user corresponding to the merchant device; and according to the identity verification result At least one of attribute information and access authority information determines the access control strategy.

It can be understood that, after performing layer-by-layer identity verification on the merchant device, it can be further based on the corresponding identity verification result, the basic information of the target member currently to be accessed by the merchant device, and the latest access authority of the user with which the merchant device is bound or associated. Circumstances, determine the matching access control policy to control its access to members’ private data.

Wherein, the aforementioned identity verification result may specifically include a device identity verification result for verifying whether the merchant's device is a trusted execution environment. In other words, the above step 109 can also be specifically expressed as: determining the access control policy of the merchant equipment based on the identity verification result or the device identity verification result of whether the merchant equipment is a trusted execution environment, and accessing the corresponding access request based on the access control policy The private data of the target member.

Further, the above step of determining the access control strategy of the merchant device based on the identity verification result or the device identity verification result of whether the merchant device is a trusted execution environment can be specifically executed as follows: obtaining the attribute information of the target member based on the access request And the access authority information of the user corresponding to the merchant device; determine the access control policy based on at least one of the identity verification result of whether the merchant device is a trusted execution environment or the device identity verification result, attribute information, and access permission information.

Further, determining the access control policy according to at least one of the identity verification result, the attribute information, and the access authority information may specifically include: determining the access control policy of the merchant device only based on the identity verification result.

More specifically, it may be executed as follows: determining the access control policy of the merchant's equipment according to the device identity verification result of verifying whether the merchant's equipment is a trusted execution environment.

More specifically, if the merchant device is verified as an untrusted execution environment after both the first device identity verification and the user identity verification are passed, that is, the result of the secondary device identity verification on the merchant device is not passed, the merchant device can be directly rejected Access request. After both the first device identity verification and user identity verification are passed, the merchant device is verified as a trusted execution environment, that is, the result of the secondary device identity verification on the merchant device is passed, and the target corresponding to the access request of the merchant device can be called The member’s private data is provided to the merchant’s device for the user to view, etc.

Further, after verifying that the merchant’s device is a trusted execution environment, in addition to directly calling the target member’s private data corresponding to the merchant’s device’s access request and feeding it back to the merchant’s device’s access control method, it is also necessary to further combine the above-mentioned target member’s private data At least one of the attribute information and the access authority information of the user corresponding to the merchant device determines the access control policy.

To be more specific, if the target member’s attribute information obtained is a senior member and has a high sensitivity level after all the levels of identity verification on the merchant’s equipment are passed, the merchant’s equipment can be restricted from accessing the target member’s private data. access. If the obtained access authority information corresponding to the merchant device is temporarily restricted from accessing the member's private data after all the layers of identity verification of the merchant device are passed, the merchant device's access request can be directly rejected.

It should be noted that the above access control policies are only some specific examples. Others can be determined based on at least one of the identity verification results of the merchant device, the attribute information of the target member, and the access authority information of the user corresponding to the merchant device. Data access control strategies are all within the protection scope of the embodiments of this specification.

Optionally, the above attribute information includes member registration information, member time limit information, membership level, and member sensitivity level; the above access authority information includes whether there is permission to access private data, such as whether access to member private data is temporarily restricted.

The specific composition of the system for controlling access to private data according to an embodiment of the present specification will be described in detail below in conjunction with FIG. 2. Specifically, it includes: a merchant request receiving module 201, a unified identity management module 203, an authentication and authorization module 205, an authentication and authorization auxiliary module 207, and a member merchant service module 209.

The merchant request receiving module 201 is mainly responsible for receiving merchant access requests, such as API access requests, database access requests, file access requests, and so on. Among them, the merchant equipment digital certificate and the merchant equipment digital signature need to be passed in in the merchant access request.

The unified identity management module 203 includes two sub-modules, a unified identity management module and a unique identity recognition module.

Among them, the unified identity management module is responsible for using the unique public key certificate to identify the merchant's device identity, and dynamically update the merchant's access device library based on the merchant's device registration, online and offline information, to ensure that the public key certificate can uniquely and accurately identify the merchant's device . The merchant equipment information it is responsible for collecting includes, but is not limited to: the network MAC address, IP address, domain name, host, etc. of the merchant equipment.

The unique identification module is responsible for verifying the identity information of the merchants’ incoming devices based on the merchant’s device information collected by the unified identity management module, using the same calculation method corresponding to the unique public key certificate, that is, using the same calculation method to collect the unified identity management module The information of the merchant device that initiated the access request is calculated to obtain the corresponding certificate, and the calculated certificate is matched with the public key certificate of the merchant device managed by the unified identity management module to complete the device identity verification work.

The authentication and authorization module 205 includes three sub-modules of single sign-on, access proxy, and access control engine. The authentication and authorization module 205 is mainly responsible for authenticating and authorizing merchant access, and authorizing access requests that comply with the authentication.

Among them, the single sign-on sub-module is used to ensure that the merchant does not need to log in repeatedly during multiple visits, but only needs to log in with an account and a key when logging in for the first time. In subsequent access requests, the token value obtained when logging in for the first time is required. Further, the token value has uniqueness and a certain life cycle.

The access agent sub-module is responsible for performing secondary verification on the identity of the merchant's device according to the merchant's device digital certificate and the merchant's device digital signature to determine whether the merchant's device is a trusted execution environment.

The access control engine sub-module is used to perform access control on the access request of the merchant equipment based on the information in the authentication and authorization auxiliary module 207 according to the verification result of the access agent sub-module. Among them, the specific control strategy comes from the merchant access strategy in the authentication and authorization auxiliary module 207.

The authentication and authorization auxiliary module 207 mainly provides necessary auxiliary information for the authentication and authorization module 205, and includes four sub-modules: merchant access equipment list service, member attributes, merchant/merchant group database, and merchant access strategy.

Among them, the merchant access equipment list service sub-module mainly records the historical access equipment list of the merchant, and can be further divided into information such as the effective equipment list and the merchant's black equipment list. When the merchant device identity verification is performed in the visit agent submodule, the merchant device needs to be matched with the merchant's historical access device list to determine whether the merchant device is the historical access device of the system, and if so, it can be further determined to which the merchant device belongs The specific list, that is, the list of valid equipment or the list of black merchant equipment. For historically visited devices, perform historical behavior identification, such as historically trusted devices, historically black devices, historical access conditions, etc.; for devices that have no historically accessed devices, they are identified as new access devices.

Merchant/merchant group database sub-module, used to record the binding or association relationship between the merchant and the merchant device or the merchant group and the merchant device, and continuously update the latest relationship between the merchant/merchant group and the merchant device according to the merchant application/update status . When receiving a merchant device access request, the corresponding merchant/merchant group needs to be backfilled into the request.

The member attribute sub-module is used to record the attribute information of the member, such as the member level, the sensitivity level of the member, the effective attribute of the member, and the time of member registration. When receiving the merchant device access request, the member attribute sub-module will be called to obtain the member attribute information corresponding to the merchant device's current access request.

The merchant access strategy sub-module is used to specify the corresponding access control strategy based on the merchant device identity authentication result, the merchant access device list, the merchant/business group access authority, and the member attribute information. For example, when the access agent sub-module fails to verify the identity of the merchant's equipment, that is, when the merchant's equipment is in an untrusted execution environment, the access request is rejected.

When it is detected that the merchant device is a historically non-accessed device, a secondary verification of the merchant device identity is required, that is, the device identity verification is performed based on the merchant device digital certificate and the merchant device digital signature.

When it is detected that the merchant/merchant group corresponding to the merchant device is temporarily restricted from accessing, the access request is rejected.

When it is detected that the current visiting member of the merchant is a senior and sensitive member, the access to the private data information of the member is restricted.

The member merchant service module 209 only outputs the requested member privacy data information in accordance with the merchant access control policy for the access request passed through the access control engine sub-module.

In summary, in the embodiments of this specification, multi-level and multi-combination access control policies are formulated based on the comprehensive authentication of the identity and device status, that is, when there is a system access request, the user and device identity and device The operation status information is authenticated to realize multi-level identity authentication. Realize identity-centered zero-trust dynamic access control, realize the comprehensive identity of merchant equipment and corresponding users, etc., and based on this comprehensive identity, it is the physical identity of the people, equipment, applications, systems, etc. of the zero-trust network. The entity establishes a unified digital identity and governance process, builds a dynamic access control system, extends the security boundary to the identity entity, realizes the advancement of the security architecture, and improves the security of data access.

The embodiment of this specification also provides an access control device. As shown in FIG. 3, the device may specifically include: an obtaining module 301, configured to obtain the device identity information of the merchant device if the access request of the merchant device is received, and the access request It carries the user account authentication information corresponding to the merchant device; the first verification module 303 is used to verify the device identity of the merchant device based on the target public key certificate and device identity information corresponding to the merchant device; the second verification module 305 is used to After the device identity verification is passed, user identity verification is performed on the user corresponding to the merchant device based on the user account authentication information; the third verification module 307 is used to verify whether the merchant device is a trusted execution environment after the user identity verification is passed; The module 309 is used to determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.

Optionally, in the access control apparatus of the embodiment of this specification, the access request also carries the device digital certificate of the merchant device and the digital signature of the target device associated with the device digital certificate; wherein, the third verification module 307 may specifically Used to: obtain a list of historically visited devices; if the merchant's device is not in the list of historically visited devices, verify whether the merchant's device is a trusted execution environment based on the device digital certificate and the digital signature of the target device.

Optionally, in the access control apparatus of the embodiment of the present specification, the third verification module 307 may be specifically used to: obtain the digital signature of the historical device corresponding to the pre-stored digital certificate of the device; if the digital signature of the historical device corresponds to the target device If the digital signatures are the same, the merchant's equipment is determined to be a trusted execution environment; if the historical device digital certificate is different from the target device's digital signature, the merchant's equipment is determined to be an untrusted execution environment.

Optionally, the access control device of the embodiment of the present specification may further include: an update module for adding merchant equipment to the historical access equipment list.

Optionally, in the access control apparatus of the embodiment of the present specification, the third verification module 307 may be specifically used to: obtain a list of historically accessed equipment; if the merchant's equipment is in the historically accessed equipment list, obtain the history corresponding to the merchant's equipment Behavior identification, and verify whether the merchant’s device is a trusted execution environment based on the historical behavior identification.

Optionally, in the access control apparatus of the embodiment of the present specification, the third verification module 307 may be specifically used to: if the historical behavior identifier indicates that the merchant device is a historically trusted device, determine that the merchant device is a trusted execution environment ; If the historical behavior identifier indicates that the merchant's device is a historically black device, the merchant's device is determined to be an untrusted execution environment.

Optionally, in the access control device of the embodiment of the present specification, the above-mentioned control module 309 can be specifically used to: obtain the attribute information of the target member and the access authority information of the user corresponding to the merchant device based on the access request; and according to the identity verification result At least one of attribute information and access authority information determines the access control strategy.

Optionally, in the access control device of the embodiment of this specification, the above attribute information includes member registration information, member time limit information, membership level, and member sensitivity level; the above access authority information includes whether there is authority to access private data.

Optionally, in the access control apparatus of the embodiment of this specification, the above-mentioned first verification module 303 may be specifically used to: generate a verification certificate of the merchant device based on the device identity information; if the verification certificate is the same as the target public key certificate, It is determined that the device identity verification is passed.

Optionally, in the access control apparatus of the embodiment of the present specification, the second verification module 305 may be specifically used to determine whether the user account authentication information includes the target token value; if the user account authentication information includes the target token value; If the token value and the target token value are valid, the user identity verification is determined to be passed; if the user account authentication information contains the target token value and the target token value is invalid, or if the user account authentication information does not contain the target token value , The user identity verification is performed on the user corresponding to the merchant device based on the account and key contained in the user account authentication information.

It can be understood that the access control device provided in the embodiment of this specification can implement the access control method provided in the foregoing embodiment, and the relevant explanations about the access control method are applicable to the access control device, and will not be repeated here.

Fig. 4 is a schematic diagram of the structure of an electronic device according to an embodiment of the specification. Please refer to FIG. 4, at the hardware level, the electronic device includes a processor, and optionally an internal bus, a network interface, and a memory. Among them, the memory may include memory, such as high-speed random access memory (Random-Access Memory, RAM), or may also include non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required by other services.

The processor, network interface, and memory can be connected to each other through an internal bus, which can be an industry standard architecture (ISA) bus, a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus, or an extended industry standard Structure (Extended Industry Standard Architecture, EISA) bus, etc. The bus can be divided into address bus, data bus, control bus and so on. For ease of presentation, only one bidirectional arrow is used to indicate in FIG. 4, but it does not mean that there is only one bus or one type of bus.

Memory, used to store programs. Specifically, the program may include program code, and the program code includes computer operation instructions. The memory may include memory and non-volatile memory, and provide instructions and data to the processor.

The processor reads the corresponding computer program from the non-volatile memory to the memory and then runs, forming an access control device on the logical level. The processor executes the program stored in the memory, and is specifically configured to perform the following operations: if an access request of the merchant device is received, the device identity information of the merchant device is obtained, and the access request carries user account authentication information corresponding to the merchant device; Based on the target public key certificate and device identity information corresponding to the merchant device, the device identity verification is performed on the merchant device; when the device identity verification is passed, the user corresponding to the merchant device is verified based on the user account authentication information; when the user identity verification After passing, verify whether the merchant device is a trusted execution environment; determine the access control policy of the merchant device, and access the private data of the target member corresponding to the access request based on the access control policy.

The foregoing method executed by the access control apparatus disclosed in the embodiment shown in FIG. 1 of this specification may be applied to or implemented by the processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software. The above-mentioned processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (Network Processor, NP), etc.; it may also be a digital signal processor (DSP), a dedicated integrated Circuit (Application Specific Integrated Circuit, ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps, and logical block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like. The steps of the method disclosed in the embodiments of this specification can be directly embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

The electronic device can also execute the method executed by the access control device in FIG. 1 and realize the functions of the embodiment of the access control device shown in FIG. 1, which will not be repeated here in the embodiment of this specification.

The embodiment of this specification also proposes a computer-readable storage medium, the computer-readable storage medium stores one or more programs, the one or more programs include instructions, when the instructions are executed by an electronic device that includes multiple application programs When the electronic device is able to execute the method executed by the access control device in the embodiment shown in FIG. 1, and is specifically used to execute: if an access request from a merchant device is received, the device identity information of the merchant device is obtained, and the access request carries The user account authentication information corresponding to the merchant device; based on the target public key certificate and device identity information corresponding to the merchant device, the device identity verification is performed on the merchant device; when the device identity verification is passed, the merchant device corresponding to the merchant device based on the user account authentication information The user conducts user identity verification; after the user identity verification is passed, verify whether the merchant device is a trusted execution environment; determine the access control policy of the merchant device, and access the private data of the target member corresponding to the access request based on the access control policy.

The embodiments of this specification provide a zero-trust-based access control solution to the private data of each member stored in the privacy data system. Specifically, when an access request from a merchant device is received, the device identity corresponding to the merchant device and The user identity of the merchant corresponding to the merchant device, that is, the user, is verified layer by layer to improve the security of access to private data. Specifically, it is necessary to first verify the device identity of the merchant device based on the device identity information of the merchant device and its corresponding and unique target public key certificate to determine whether the merchant device is a merchant device pre-associated with the privacy data system; After the first device identity verification is passed, the corresponding merchant's user identity verification is performed based on the user account authentication information corresponding to the merchant device. After the user identity verification is passed, the device identity of the merchant device needs to be verified a second time to determine the Whether the merchant equipment is a trusted execution environment for the private data of the target member of the system. After performing the corresponding layer-by-layer identity verification on the merchant device, it is necessary to further determine the access control policy of the merchant device to the private data of the target member corresponding to the access request based on the specific situation of the current visit. In this way, it is not only necessary to perform zero-trust-based identity verification on merchant devices for data access, but also to further match specific access control policies to strengthen the control of merchant devices’ access to private data and avoid malicious or improper The operation caused the leakage of members’ private data, reduced the risk of private data leakage, and improved the security of data access.

Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, the embodiments of this specification may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of this specification may adopt the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

The technical solutions of the embodiments of this specification are described with reference to the flowcharts and/or block diagrams of the methods, equipment (systems), and computer program products corresponding to the embodiments of this specification. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

In a typical configuration, the computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent memory in computer readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.

Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element.

The above descriptions are only the embodiments of this specification, and are not used to limit the embodiments of this specification. For those skilled in the art, various modifications and changes can be made to the embodiments of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiment of the specification should be included in the scope of the claims of the embodiment of the specification.

Claims

An access control method, the method includes:

If an access request of the merchant device is received, obtain the device identity information of the merchant device, and the access request carries the user account authentication information corresponding to the merchant device;

Performing device identity verification on the merchant device based on the target public key certificate corresponding to the merchant device and the device identity information;

After the device identity verification is passed, perform user identity verification on the user corresponding to the merchant device based on the user account authentication information;

After the user identity verification is passed, verify whether the merchant device is a trusted execution environment;

Determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.
The method according to claim 1, wherein the access request also carries the device digital certificate of the merchant device and the digital signature of the target device associated with the device digital certificate;

Wherein, the verifying whether the merchant equipment is a trusted execution environment includes:

Obtain a list of historical access devices;

If the merchant's device is not in the list of historically accessed devices, verify whether the merchant's device is a trusted execution environment based on the device digital certificate and the digital signature of the target device.
The method according to claim 2, wherein the verifying whether the merchant device is a trusted execution environment based on the device digital certificate and the target device digital signature includes:

Obtaining a digital signature of a historical device corresponding to the device digital certificate stored in advance;

If the digital signature of the historical device is the same as the digital signature of the target device, determining that the merchant device is a trusted execution environment;

If the historical device digital certificate is different from the target device digital signature, it is determined that the merchant device is an untrusted execution environment.
The method according to claim 2, further comprising:

Adding the merchant equipment to the historical access equipment list.
The method according to claim 1, wherein the verifying whether the merchant's equipment is a trusted execution environment comprises:

Obtain a list of historical access devices;

If the merchant device is in the list of historically accessed devices, obtain the historical behavior identifier corresponding to the merchant device, and verify whether the merchant device is a trusted execution environment based on the historical behavior identifier.
The method according to claim 5, wherein said verifying whether said merchant's equipment is a trusted execution environment based on said historical behavior identification comprises:

If the historical behavior identifier indicates that the merchant device is a historically trusted device, determining that the merchant device is a trusted execution environment;

If the historical behavior identifier indicates that the merchant device is a historically black device, it is determined that the merchant device is an untrusted execution environment.
The method according to any one of claims 1 to 6, wherein the determining an access control policy of the merchant device includes:

Obtaining the attribute information of the target member and the access authority information of the user corresponding to the merchant device based on the access request;

The access control policy is determined according to at least one of the identity verification result, the attribute information, and the access authority information.
The method according to claim 7, wherein the attribute information includes member registration information, member time limit information, member level, and member sensitivity level;

The access authority information includes whether there is authority to access the private data.
The method according to claim 1, wherein the performing device identity verification on the merchant device based on the target public key certificate corresponding to the merchant device and the device identity information includes:

Generating a verification certificate to be verified of the merchant device based on the device identity information;

If the verification certificate to be verified is the same as the target public key certificate, it is determined that the device identity verification is passed.
The method according to claim 1, wherein after the device identity verification is passed, performing user identity verification on the user corresponding to the merchant device based on the user account authentication information includes:

Determining whether the user account authentication information contains the target token value;

If the user account authentication information includes the target token value and the target token value is valid, it is determined that the user identity verification is passed;

If the user account authentication information includes the target token value and the target token value is invalid, or if the user account authentication information does not include the target token value, then based on the user account The account and key included in the authentication information perform user identity verification on the user corresponding to the merchant device.
An access control device, the device includes:

The obtaining module is configured to obtain the device identity information of the merchant device if an access request of the merchant device is received, and the access request carries the user account authentication information corresponding to the merchant device;

The first verification module is configured to perform device identity verification on the merchant device based on the target public key certificate corresponding to the merchant device and the device identity information;

The second verification module is configured to perform user identity verification on the user corresponding to the merchant device based on the user account authentication information after the device identity verification is passed;

The third verification module is used to verify whether the merchant device is a trusted execution environment after the user identity verification is passed;

The control module is used to determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.
An electronic device including:

Processor; and

A memory arranged to store computer-executable instructions that, when executed, cause the processor to perform the following operations:

If an access request of the merchant device is received, obtain the device identity information of the merchant device, and the access request carries the user account authentication information corresponding to the merchant device;

Performing device identity verification on the merchant device based on the target public key certificate corresponding to the merchant device and the device identity information;

After the device identity verification is passed, perform user identity verification on the user corresponding to the merchant device based on the user account authentication information;

After the user identity verification is passed, verify whether the merchant device is a trusted execution environment;

Determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.
A computer-readable storage medium that stores one or more programs that, when executed by an electronic device including multiple application programs, cause the electronic device to perform the following operations :

If an access request of the merchant device is received, obtain the device identity information of the merchant device, and the access request carries the user account authentication information corresponding to the merchant device;

Performing device identity verification on the merchant device based on the target public key certificate corresponding to the merchant device and the device identity information;

After the device identity verification is passed, perform user identity verification on the user corresponding to the merchant device based on the user account authentication information;

After the user identity verification is passed, verify whether the merchant device is a trusted execution environment;

Determine the access control policy of the merchant equipment, and access the private data of the target member corresponding to the access request based on the access control policy.