為使本說明書的目的、技術方案和優點更加清楚，下面將結合本說明書具體實施例及相應的圖式對本說明書技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本說明書一部分實施例，而不是全部的實施例。基於本說明書中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬於本說明書保護的範圍。
對於先前技術部分陳述的現有的資料存取控制方式可能會因商家的帳密資訊洩露而導致大量的會員隱私資料洩露的問題，本說明書實施例提供一種基於零信任的資料存取控制方案，達到加強對商家存取的控制的目，以避免由於存取商家的惡意或不當的操作，造成會員的隱私資料的洩露。
以下結合圖式，詳細說明本說明書各實施例提供的技術方案。
參見圖1所示，本說明書實施例提供一種存取控制方法，該方法具體可包括以下內容：
步驟101：若接收到商家設備的存取請求，則獲取商家設備的設備身份資訊，存取請求中攜帶商家設備對應的使用者帳戶鑒權資訊。
可選的，上述商家的存取請求可以具體包括但不限於檔存取請求、資料庫存取請求、應用程式介面(Application Programming Interface，API)存取請求。針對不同類型的存取請求可以對應請求存取對應的隱私資料。
可選的，上述商家設備的設備身份資訊可以具體包括但不限於商家設備的網路媒體存取控制(Media Access Control，MAC)位址、網路通訊協定(Internet Protocol，IP)地址、網域名稱、宿主/主機(Host)等。
步驟103：基於商家設備對應的目標公鑰證書和設備身份資訊，對商家設備進行設備身份核驗。
其中，上述目標公鑰證書可以基於一定的加密演算法對商家設備的設備身份資訊進行運算生成，用於唯一標識商家設備身份，具體地，可以在系統側對商家設備的上述設備身份資訊進行更新維護，比如根據商家設備的註冊資訊、即時的上、下線資訊等動態更新各商家設備的設備身份資訊，並基於最新的設備身份資訊更新相應的公鑰證書。
可選的，該目標公鑰證書可以具有一定的有效期限，具體可以每間隔一段時間更新一次，也可以在商家設備的設備身份資訊發生變化時進行更新，以確保能夠基於該目標公鑰證書唯一、準確地標識該商家設備。
可選的，該步驟103具體可以執行為如下內容：
基於設備身份資訊生成商家設備的待核驗證書；若待核驗證書與目標公鑰證書相同，則確定設備身份核驗通過。
可以理解，在接收到商家設備的存取請求時，可以主動採集獲取該商家設備的屬性資訊即設備身份資訊，並進一步採用生成目標公鑰證書的相同加密演算法得到對應的待核驗證書。如此，則可以在確認當前生成的待核驗證書與存取請求中攜帶的商家設備的目標公鑰證書相同時，認為對商家設備的首次身份核驗通過。而如果在確認當前生成的待核驗證書與存取請求中攜帶的商家設備的目標公鑰證書不同時，則認為對商家設備的首次身份核驗失敗。
步驟105：當設備身份核驗通過後，基於使用者帳戶鑒權資訊對商家設備對應的使用者進行使用者身份核驗。
可選的，該步驟105具體可以執行為如下內容：
確定使用者帳戶鑒權資訊中是否包含目標符記值；
若使用者帳戶鑒權資訊中包含目標符記值且目標符記值有效，則確定使用者身份核驗通過；
若使用者帳戶鑒權資訊中包含目標符記值且目標符記值無效、或者若使用者帳戶鑒權資訊中未包含目標符記值，則基於使用者帳戶鑒權資訊中包含的帳戶和金鑰對商家設備對應的使用者進行使用者身份核驗。
可以理解，在對商家設備對應的使用者即商家進行使用者身份核驗時，為了確保商家在存取系統時的使用者體驗，可以在對使用者進行使用者身份核驗時無需多次重複輸入帳戶和金鑰，達到一鍵快捷登錄的效果。具體的，可以在一次登錄時輸入相應的帳戶和金鑰進行核驗，並在驗證通過生成相應的目標符記token值，進一步地，若在以後的存取請求中攜帶有該目標符記值，則可以直接確認使用者身份核驗通過，而如果沒有攜帶，則需要輸入使用者的帳戶和金鑰進行使用者身份核驗。其中，該目標符記值與商家設備對應的使用者的帳戶和金鑰一一對應，具有唯一性。進一步地，該目標符記值還可以具有一定的有效時限，通過定期更新該符記值，以避免由於使用者的帳密資訊洩露，導致系統中的隱私資料的洩露。
可選的，上述商家設備對應的使用者的數量可以為一個也可以為多個，商家設備及其對應的使用者之間具有綁定或者關聯關係。
步驟107：當使用者身份核驗通過後，驗證商家設備是否為可信執行環境。
步驟109：確定商家設備的存取控制策略，並基於存取控制策略存取存取請求對應的目標會員的隱私資料。
本說明書實施例，提供了一種基於零信任的對隱私資料系統中儲存的各會員的隱私資料的存取控制方案，具體在接收到商家設備的存取請求時，需要對商家設備對應的設備身份以及商家設備對應的商家即使用者的使用者身份進行層層核驗，以提高對隱私資料存取的安全性。具體的，首先需要基於商家設備的設備身份資訊及其對應且唯一的目標公鑰證書對商家設備的設備身份進行首次核驗，以確定該商家設備是否為與隱私資料系統預先關聯的商家設備；在首次設備身份核驗通過後，基於商家設備對應的使用者帳戶鑒權資訊對相應的商家進行使用者身份核驗，進一步在使用者身份核驗通過後，還需要對商家設備的設備身份進行二次核驗，以確定該商家設備對於該系統的目標會員的隱私資料而言是否為可信執行環境。而在對商家設備進行相應的層層身份核驗後，還需進一步依據當前存取的具體情況確定該商家設備對存取請求對應的目標會員的隱私資料的存取控制策略。如此，不僅需要對進行資料存取的商家設備進行基於零信任的層層身份核驗，還需要進一步為其匹配具體的存取控制策略，以加強對商家設備存取隱私資料的控制，避免由於一些惡意或不當的操作，造成會員的隱私資料的洩漏，降低隱私資料洩漏的風險，提高資料存取的安全性。
進一步需要說明的是，在本說明書實施例的存取控制方法中，若基於商家設備對應的目標公鑰證書和設備身份資訊，對商家設備進行設備身份核驗即首次設備身份核驗的結果為未通過，則可以直接拒絕商家設備的存取請求。
進一步地，在基於商家設備對應的目標公鑰證書和設備身份資訊，對商家設備進行設備身份核驗通過後，若在基於目標公鑰證書的首次設備身份核驗通過後，基於使用者帳戶鑒權資訊對商家設備對應的使用者進行使用者身份核驗的結果為未通過，則可以直接拒絕商家設備的存取請求。
可選的，在本說明書實施例的存取控制方法中，還可以對存取過系統的歷史設備以歷史存取設備清單的形式進行管理。進而在執行上述步驟107時，在使用者身份核驗通過後，可以首先獲取該歷史存取設備清單，以核驗該當前進行存取的商家設備是否與該歷史存取設備清單相匹配，進而基於匹配結果確定對商家設備身份進行二次核驗的具體方式。
進一步地，在本說明書實施例的存取控制方法中，上述存取請求中還可以攜帶商家設備的設備數位憑證以及與設備數位憑證關聯的目標設備數位簽章。
如此，在上述歷史存取設備清單中未包含該商家設備的情況下，可以基於上述設備數位憑證以及與設備數位憑證關聯的目標設備數位簽章，對商家設備身份進行二次核驗，即驗證該商家設備是否為可信執行環境。具體地，上述步驟107可以具體執行為如下內容：
獲取歷史存取設備清單；
若商家設備未位於歷史存取設備清單中，則基於設備數位憑證和目標設備數位簽章驗證商家設備是否為可信執行環境。
進一步地，上述基於設備數位憑證和目標設備數位簽章驗證商家設備是否為可信執行環境的步驟，具體可以執行為如下內容：
獲取預先儲存的設備數位憑證對應的歷史設備數位簽章；
若歷史設備數位簽章與目標設備數位簽章相同，則確定商家設備為可信執行環境；
若歷史設備數位憑證與目標設備數位簽章不同，則確定商家設備為非可信執行環境。
可以理解，在隱私資料系統中儲存並維護商家設備的數位憑證對應的數位簽章。若商家設備在存取時上報的數位憑證與其在系統中預儲存的數位憑證不相符，則說明商家設備為非可信執行環境，而若相符則為可信執行環境。
進一步可選的，本說明書實施例的存取控制方法，還可以包括以下內容：
將商家設備加入歷史存取設備清單。
可以理解，在基於商家設備的設備數位憑證及其對應的設備數位簽章完成對其設備身份的核驗後，對歷史存取設備清單進行更新，以將該商家設備的存取情況記錄在清單中。
進一步地，在上述歷史存取設備清單中，還可以為商家設備設置是否為可信執行環境的標籤，比如，若為可信執行環境則記錄在有效設備清單中，若為非可信執行環境則記錄在黑設備清單中，其中，黑設備具體可以為由於商家的帳密資訊洩露導致的設備身份驗證未通過的設備；進一步地，還可設置對歷史存取設備清單中維護的商家設備的清除策略，比如：定期清除一批載入時間靠前的設備或者清除全部，或者根據商家設備存取的頻次等決定是否將其從清單中及時移除，以在提高歷史存取設備清單的使用價值的同時，為商家設備作為有效設備或者黑設備儲存在歷史設備存取清單中的情況設置一定的有效期限，避免由於對設備的狀態更新不及時導致身份核驗時誤判，造成隱私資料洩露或者影響存取隱私資料的使用者體驗。
那麼，在上述歷史存取設備清單中包含該商家設備的情況下，則可以基於其所具有的是否為可信執行環境的標籤，高效且準確地確定其是否為可信執行環境。具體地，上述步驟107可以具體執行為如下內容：
獲取歷史存取設備清單；
若商家設備位於歷史存取設備清單中，則獲取商家設備對應的歷史行為標識，並基於歷史行為標識驗證商家設備是否為可信執行環境。
進一步地，上述基於歷史行為標識驗證商家設備是否為可信執行環境的步驟，具體可以執行為如下內容：
若歷史行為標識指示商家設備為歷史可信設備，則確定商家設備為可信執行環境；
若歷史行為標識指示商家設備為歷史黑設備，則確定商家設備為非可信執行環境。
可以理解，若商家設備在歷史設備存取清單所具有的是否為可信執行環境的標籤即歷史行為標識指示其為歷史可信設備，即說明該商家設備屬於有效設備行列時，直接確定其為可信執行環境；以及若商家設備在歷史設備存取清單所具有的是否為可信執行環境的標籤即歷史行為標識指示其為歷史黑設備，即說明該商家設備屬於黑設備行列時，直接確定其為非可信執行環境。
可選的，在本說明書實施例的存取控制方法中，上述步驟109，具體可以包括以下內容：
基於存取請求，獲取目標會員的屬性資訊以及商家設備對應的使用者的存取權限資訊；
根據身份核驗結果、屬性資訊和存取權限資訊中的至少一個，確定存取控制策略。
可以理解，在對商家設備的進行層層身份核驗後，可以進一步基於對應的身份核驗結果、商家設備當前所要存取的目標會員的基本情況及與其具有綁定或關聯關係的使用者的最新的存取權限情況，確定相匹配的存取控制策略，以控制其對會員的隱私資料的存取。
其中，上述身份核驗結果具體可以包括驗證商家設備是否可信執行環境的設備身份核驗結果。換言之，上述步驟109，具體還可以表示為：
根據對商家設備是否為可信執行環境的身份核驗結果或設備身份核驗結果，確定商家設備的存取控制策略，並基於存取控制策略存取存取請求對應的目標會員的隱私資料。
進一步地，上述根據對商家設備是否為可信執行環境的身份核驗結果或設備身份核驗結果，確定商家設備的存取控制策略的步驟，具體還可以執行為：
基於存取請求，獲取目標會員的屬性資訊以及商家設備對應的使用者的存取權限資訊；
根據對商家設備是否為可信執行環境的身份核驗結果或設備身份核驗結果、屬性資訊和存取權限資訊中的至少一個，確定存取控制策略。
進一步地，根據身份核驗結果、屬性資訊和存取權限資訊中的至少一個，確定存取控制策略，可以具體包括：僅根據身份核驗結果，確定商家設備的存取控制策略。
進一步具體的，可以執行為：根據驗證商家設備是否可信執行環境的設備身份核驗結果，確定商家設備的存取控制策略。
進一步具體的，若在首次設備身份核驗和使用者身份核驗均通過後，驗證商家設備為非可信執行環境，即對商家設備的二次設備身份核驗的結果為未通過，則可以直接拒絕商家設備的存取請求。而在首次設備身份核驗和使用者身份核驗均通過後，驗證商家設備為可信執行環境，即對商家設備的二次設備身份核驗的結果為通過，則可以調用與商家設備的存取請求對應的目標會員的隱私資料，以提供至商家設備供使用者查看等。
進一步地，在驗證商家設備為可信執行環境後，除了可以直接調用與商家設備的存取請求對應的目標會員的隱私資料並回饋至商家設備的存取控制方式外，還需要進一步結合上述目標會員的屬性資訊和商家設備對應的使用者的存取權限資訊中的至少一個，確定存取控制策略。
進一步具體的，若在對商家設備的層層身份核驗均通過後，獲取到的目標會員的屬性資訊為高級會員且敏高等級較高時，則可以限制商家設備對該目標會員的隱私資料的存取。若在對商家設備的層層身份核驗均通過後，獲取到的商家設備對應的存取權限資訊為暫時限制存取會員隱私資料時，則可以直接拒絕商家設備的存取請求。
需要說明的是，上述存取控制策略僅為部分具體示例，其他能夠基於對商家設備的身份核驗結果、目標會員的屬性資訊和商家設備對應的使用者的存取權限資訊中至少一個可以確定的對會員隱私資料的存取控制策略，均在本說明書實施例的保護範圍內。
可選的，上述屬性資訊包括會員註冊資訊、會員時限資訊、會員等級和會員敏感等級；上述存取權限資訊包括是否有許可權存取隱私資料，比如當前是否暫時被限制存取會員隱私資料。
下面結合圖2對本說明書實施例的用於控制對隱私資料存取的系統的具體組成進行詳細說明。具體包括：
(1)商家請求接收模組201
該商家請求接收模組201主要負責接收商家存取請求，如API存取請求、資料庫存取請求、檔存取請求等。其中，商家存取請求中需要傳入商家設備數位憑證、商家設備數位簽章。
(2)統一身份管理識別模組203，包括統一身份管理模組和唯一身份識別模組兩個子模組
其中，統一身份管理模組負責使用唯一公鑰證書標識商家設備身份，並根據商家設備註冊、上下線等資訊，動態更新商家存取設備庫，以確保該公鑰證書能夠唯一且準確地標識該商家設備。其所負責收集的商家設備資訊包括但不限於：商家設備的網路MAC位址、IP位址、網域名稱、host等。
唯一身份識別模組負責根據統一身份管理模組收集的商家設備資訊，採用與唯一公鑰證書對應的相同計算方式，對商家傳入設備身份資訊進行核驗，即採用相同的計算方式對統一身份管理模組收集的發起存取請求的商家設備資訊進行計算得到對應的證書，並將計算得到的證書與統一身份管理模組管理的商家設備的公鑰證書進行匹配，以完成設備身份核驗工作。
(3)認證授權模組205，包括單點登錄、存取代理、存取控制引擎三個子模組，該認證授權模組205主要負責對商家存取進行認證和授權，對符合認證的存取請求進行授權。
其中，單點登錄子模組，用於確保商家在多次存取過程中無需多次重複登錄，只需要在首次登錄時，採用帳戶、金鑰登錄。在之後的存取請求中，均需帶上首次登錄時獲取的token值。進一步地，該token值具有唯一性和一定的生命週期。
存取代理子模組，負責根據商家設備數位憑證、商家設備數位簽章對商家設備身份進行二次驗證，以確定商家設備是否為可信執行環境。
存取控制引擎子模組，用於根據存取代理子模組的驗證結果，基於認證授權輔助模組207中的資訊，對商家設備的存取請求進行存取控制。其中，具體的控制策略來源於認證授權輔助模組207中的商家存取策略。
(4)認證授權輔助模組207，主要為認證授權模組205提供必要的輔助資訊，其包含了商家存取設備清單服務、會員屬性、商家/商家組資料庫以及商家存取策略四個子模組。
其中，商家存取設備清單服務子模組，主要記錄商家歷史存取設備清單，進一步可以分為有效設備清單以及商家黑設備清單等資訊。當在存取代理子模組中進行商家設備身份驗證時，需要對商家設備首先匹配商家歷史存取設備清單，以確定商家設備是否為系統的歷史存取設備，若是，則進一步可以確定該商家設備所歸屬的具體清單，即有效設備清單或商家黑設備清單。對歷史存取過設備，進行歷史行為標識，如歷史可信設備、歷史黑設備、歷史存取情況等；對無歷史存取設備，則標識為新存取設備。
商家/商家組資料庫子模組，用於記錄商家同商家設備或商家組同商家設備之間的綁定或關聯關係，並根據商家申請/更新狀況持續更新商家/商家組與商家設備間的最新關係。在接收到商家設備存取請求時，需將其對應的商家/商家組回填到請求中。
會員屬性子模組，用於記錄會員的屬性資訊，如會員等級、會員敏感等級、會員有效屬性、會員註冊時間等資訊。在接收商家設備存取請求時，將調用會員屬性子模組，獲取商家設備本次的存取請求對應的會員屬性資訊。
商家存取策略子模組，用於根據商家設備身份認證結果、商家存取設備清單、商家/商家組的存取權限、會員屬性資訊指定相應的存取控制策略。比如：
當存取代理子模組驗證商家設備身份不通過時，即商家設備為非可信執行環境時，拒絕本次存取請求。
當檢測到商家設備為歷史無存取設備時，要求對商家設備身份進行二次校驗，即基於商家設備數位憑證和商家設備數位簽章進行設備身份核驗。
當檢測到商家設備對應的商家/商家組為暫時限制存取時，則拒絕本次存取請求。
當檢測到商家本次存取會員為高級且敏感會員時，則限制存取會員的隱私資料資訊。
(5)會員商家服務模組209
該會員商家服務模組209僅對存取控制引擎子模組通過的存取請求，按照商家存取控制策略，輸出請求的會員隱私資料資訊。
綜上可知，在本說明書實施例中，依據對身份和設備狀態的綜合認證情況，制定多層次和多組合的存取控制策略，即在有系統接入請求時，通過對使用者和設備身份以及設備運行狀態資訊進行認證，實現多層級的身份認證。實現了以身份為中心進行零信任的動態存取控制，實現對商家設備及其對應的使用者等的全面身份化，並基於該全面身份化，為零信任網路的人、設備、應用、系統等物理實體建立統一的數位身份標識和治理流程，構築動態存取控制體系，將安全邊界延伸至身份實體，實現安全架構的關口前移，提高了資料存取的安全性。
本說明書實施例還提供一種存取控制裝置，參見圖3所示，該裝置可具體包括：
獲取模組301，用於若接收到商家設備的存取請求，則獲取商家設備的設備身份資訊，存取請求中攜帶商家設備對應的使用者帳戶鑒權資訊；
第一驗證模組303，用於基於商家設備對應的目標公鑰證書和設備身份資訊，對商家設備進行設備身份核驗；
第二驗證模組305，用於當設備身份核驗通過後，基於使用者帳戶鑒權資訊對商家設備對應的使用者進行使用者身份核驗；
第三驗證模組307，用於當使用者身份核驗通過後，驗證商家設備是否為可信執行環境；
控制模組309，用於確定商家設備的存取控制策略，並基於存取控制策略存取存取請求對應的目標會員的隱私資料。
可選的，在本說明書實施例的存取控制裝置中，上述存取請求中還攜帶商家設備的設備數位憑證以及與設備數位憑證關聯的目標設備數位簽章；
其中，上述第三驗證模組307，具體可以用於：
獲取歷史存取設備清單；
若商家設備未位於歷史存取設備清單中，則基於設備數位憑證和目標設備數位簽章驗證商家設備是否為可信執行環境。
可選的，在本說明書實施例的存取控制裝置中，上述第三驗證模組307，具體還可以用於：
獲取預先儲存的設備數位憑證對應的歷史設備數位簽章；
若歷史設備數位簽章與目標設備數位簽章相同，則確定商家設備為可信執行環境；
若歷史設備數位憑證與目標設備數位簽章不同，則確定商家設備為非可信執行環境。
可選的，本說明書實施例的存取控制裝置，還可以包括：
更新模組，用於將商家設備加入歷史存取設備清單。
可選的，在本說明書實施例的存取控制裝置中，上述第三驗證模組307，具體可以用於：
獲取歷史存取設備清單；
若商家設備位於歷史存取設備清單中，則獲取商家設備對應的歷史行為標識，並基於歷史行為標識驗證商家設備是否為可信執行環境。
可選的，在本說明書實施例的存取控制裝置中，上述第三驗證模組307，具體還可以用於：
若歷史行為標識指示商家設備為歷史可信設備，則確定商家設備為可信執行環境；
若歷史行為標識指示商家設備為歷史黑設備，則確定商家設備為非可信執行環境。
可選的，在本說明書實施例的存取控制裝置中，上述控制模組309，具體可以用於：
基於存取請求，獲取目標會員的屬性資訊以及商家設備對應的使用者的存取權限資訊；
根據身份核驗結果、屬性資訊和存取權限資訊中的至少一個，確定存取控制策略。
可選的，在本說明書實施例的存取控制裝置中，上述屬性資訊包括會員註冊資訊、會員時限資訊、會員等級和會員敏感等級；
上述存取權限資訊包括是否有許可權存取隱私資料。
可選的，在本說明書實施例的存取控制裝置中，上述第一驗證模組303，具體可以用於：
基於設備身份資訊生成商家設備的待核驗證書；
若待核驗證書與目標公鑰證書相同，則確定設備身份核驗通過。
可選的，在本說明書實施例的存取控制裝置中，上述第二驗證模組305，具體可以用於：
確定使用者帳戶鑒權資訊中是否包含目標符記值；
若使用者帳戶鑒權資訊中包含目標符記值且目標符記值有效，則確定使用者身份核驗通過；
若使用者帳戶鑒權資訊中包含目標符記值且目標符記值無效、或者若使用者帳戶鑒權資訊中未包含目標符記值，則基於使用者帳戶鑒權資訊中包含的帳戶和金鑰對商家設備對應的使用者進行使用者身份核驗。
能夠理解，本說明書實施例提供的存取控制裝置，能夠實現前述實施例中提供的存取控制方法，關於存取控制方法的相關闡釋均適用於存取控制裝置，此處不再贅述。
本說明書實施例，提供了一種基於零信任的對隱私資料系統中儲存的各會員的隱私資料的存取控制方案，具體在接收到商家設備的存取請求時，需要對商家設備對應的設備身份以及商家設備對應的商家即使用者的使用者身份進行層層核驗，以提高對隱私資料存取的安全性。具體的，首先需要基於商家設備的設備身份資訊及其對應且唯一的目標公鑰證書對商家設備的設備身份進行首次核驗，以確定該商家設備是否為與隱私資料系統預先關聯的商家設備；在首次設備身份核驗通過後，基於商家設備對應的使用者帳戶鑒權資訊對相應的商家進行使用者身份核驗，進一步在使用者身份核驗通過後，還需要對商家設備的設備身份進行二次核驗，以確定該商家設備對於該系統的目標會員的隱私資料而言是否為可信執行環境。而在對商家設備進行相應的層層身份核驗後，還需進一步依據當前存取的具體情況確定該商家設備對存取請求對應的目標會員的隱私資料的存取控制策略。如此，不僅需要對進行資料存取的商家設備進行基於零信任的層層身份核驗，還需要進一步為其匹配具體的存取控制策略，以加強對商家設備存取隱私資料的控制，避免由於一些惡意或不當的操作，造成會員的隱私資料的洩漏，降低隱私資料洩漏的風險，提高資料存取的安全性。
圖4是本說明書的一個實施例電子設備的結構示意圖。請參考圖4，在硬體層面，該電子設備包括處理器，可選地還包括內部匯流排、網路介面、記憶體。其中，記憶體可能包含內部記憶體，例如高速隨機存取記憶體(Random-Access Memory，RAM)，也可能還包括非揮發性記憶體(non-volatile memory)，例如至少1個磁碟記憶體等。當然，該電子設備還可能包括其他業務所需要的硬體。
處理器、網路介面和記憶體可以通過內部匯流排相互連接，該內部匯流排可以是工業標準架構(Industry Standard Architecture，ISA)匯流排、週邊組件互連標準(Peripheral Component Interconnect，PCI)匯流排或延伸工業標準架構(Extended Industry Standard Architecture，EISA)匯流排等。匯流排可以分為位址匯流排、資料匯流排、控制匯流排等。為便於表示，圖4中僅用一個雙向箭頭表示，但並不表示僅有一根匯流排或一種類型的匯流排。
記憶體，用於存放程式。具體地，程式可以包括程式碼，程式碼包括電腦操作指令。記憶體可以包括內部記憶體和非揮發性記憶體，並向處理器提供指令和資料。
處理器從非揮發性記憶體中讀取對應的電腦程式到內部記憶體中然後運行，在邏輯層面上形成存取控制裝置。處理器，執行記憶體所存放的程式，並具體用於執行以下操作：
若接收到商家設備的存取請求，則獲取商家設備的設備身份資訊，存取請求中攜帶商家設備對應的使用者帳戶鑒權資訊；
基於商家設備對應的目標公鑰證書和設備身份資訊，對商家設備進行設備身份核驗；
當設備身份核驗通過後，基於使用者帳戶鑒權資訊對商家設備對應的使用者進行使用者身份核驗；
當使用者身份核驗通過後，驗證商家設備是否為可信執行環境；
確定商家設備的存取控制策略，並基於存取控制策略存取存取請求對應的目標會員的隱私資料。
本說明書實施例，提供了一種基於零信任的對隱私資料系統中儲存的各會員的隱私資料的存取控制方案，具體在接收到商家設備的存取請求時，需要對商家設備對應的設備身份以及商家設備對應的商家即使用者的使用者身份進行層層核驗，以提高對隱私資料存取的安全性。具體的，首先需要基於商家設備的設備身份資訊及其對應且唯一的目標公鑰證書對商家設備的設備身份進行首次核驗，以確定該商家設備是否為與隱私資料系統預先關聯的商家設備；在首次設備身份核驗通過後，基於商家設備對應的使用者帳戶鑒權資訊對相應的商家進行使用者身份核驗，進一步在使用者身份核驗通過後，還需要對商家設備的設備身份進行二次核驗，以確定該商家設備對於該系統的目標會員的隱私資料而言是否為可信執行環境。而在對商家設備進行相應的層層身份核驗後，還需進一步依據當前存取的具體情況確定該商家設備對存取請求對應的目標會員的隱私資料的存取控制策略。如此，不僅需要對進行資料存取的商家設備進行基於零信任的層層身份核驗，還需要進一步為其匹配具體的存取控制策略，以加強對商家設備存取隱私資料的控制，避免由於一些惡意或不當的操作，造成會員的隱私資料的洩漏，降低隱私資料洩漏的風險，提高資料存取的安全性。
上述如本說明書圖1所示實施例揭示的存取控制裝置執行的方法可以應用於處理器中，或者由處理器實現。處理器可能是一種積體電路晶片，具有信號的處理能力。在實現過程中，上述方法的各步驟可以通過處理器中的硬體的整合邏輯電路或者軟體形式的指令完成。上述的處理器可以是通用處理器，包括中央處理器(Central Processing Unit，CPU)、網路處理器(Network Processor，NP)等；還可以是數位訊號處理器(Digital Signal Processor，DSP)、專用積體電路(Application Specific Integrated Circuit，ASIC)、現場可程式設計閘陣列(Field-Programmable Gate Array，FPGA)或者其他可程式設計邏輯器件、分立閘或者電晶體邏輯器件、分立硬體元件。可以實現或者執行本說明書實施例中的揭露的各方法、步驟及邏輯方塊圖。通用處理器可以是微處理器或者該處理器也可以是任何常規的處理器等。結合本說明書實施例所揭露的方法的步驟可以直接體現為硬體解碼處理器執行完成，或者用解碼處理器中的硬體及軟體模組組合執行完成。軟體模組可以位於隨機記憶體，快閃記憶體、唯讀記憶體，可程式設計唯讀記憶體或者電可讀寫可程式設計記憶體、暫存器等本領域成熟的儲存媒體中。該儲存媒體位於記憶體，處理器讀取記憶體中的資訊，結合其硬體完成上述方法的步驟。
該電子設備還可執行圖1中存取控制裝置執行的方法，並實現存取控制裝置在圖1所示實施例的功能，本說明書實施例在此不再贅述。
本說明書實施例還提出了一種電腦可讀儲存媒體，該電腦可讀儲存媒體儲存一個或多個程式，該一個或多個程式包括指令，該指令當被包括多個應用程式的電子設備執行時，能夠使該電子設備執行圖1所示實施例中存取控制裝置執行的方法，並具體用於執行：
若接收到商家設備的存取請求，則獲取商家設備的設備身份資訊，存取請求中攜帶商家設備對應的使用者帳戶鑒權資訊；
基於商家設備對應的目標公鑰證書和設備身份資訊，對商家設備進行設備身份核驗；
當設備身份核驗通過後，基於使用者帳戶鑒權資訊對商家設備對應的使用者進行使用者身份核驗；
當使用者身份核驗通過後，驗證商家設備是否為可信執行環境；
確定商家設備的存取控制策略，並基於存取控制策略存取存取請求對應的目標會員的隱私資料。
本說明書實施例，提供了一種基於零信任的對隱私資料系統中儲存的各會員的隱私資料的存取控制方案，具體在接收到商家設備的存取請求時，需要對商家設備對應的設備身份以及商家設備對應的商家即使用者的使用者身份進行層層核驗，以提高對隱私資料存取的安全性。具體的，首先需要基於商家設備的設備身份資訊及其對應且唯一的目標公鑰證書對商家設備的設備身份進行首次核驗，以確定該商家設備是否為與隱私資料系統預先關聯的商家設備；在首次設備身份核驗通過後，基於商家設備對應的使用者帳戶鑒權資訊對相應的商家進行使用者身份核驗，進一步在使用者身份核驗通過後，還需要對商家設備的設備身份進行二次核驗，以確定該商家設備對於該系統的目標會員的隱私資料而言是否為可信執行環境。而在對商家設備進行相應的層層身份核驗後，還需進一步依據當前存取的具體情況確定該商家設備對存取請求對應的目標會員的隱私資料的存取控制策略。如此，不僅需要對進行資料存取的商家設備進行基於零信任的層層身份核驗，還需要進一步為其匹配具體的存取控制策略，以加強對商家設備存取隱私資料的控制，避免由於一些惡意或不當的操作，造成會員的隱私資料的洩漏，降低隱私資料洩漏的風險，提高資料存取的安全性。
本領域內的技術人員應明白，本說明書實施例可提供為方法、系統、或電腦程式產品。因此，本說明書的實施例可採用完全硬體實施例、完全軟體實施例、或結合軟體和硬體態樣的實施例的形式。而且，本說明書實施例可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。
本說明書實施例的技術方案是參照本說明書實施例對應的方法、設備(系統)、和電腦程式產品的流程圖及/或方塊圖來描述的。應理解可由電腦程式指令實現流程圖及/或方塊圖中的每一流程及/或方塊、以及流程圖及/或方塊圖中的流程及/或方塊的結合。可提供這些電腦程式指令到通用電腦、專用電腦、嵌入式處理機或其他可程式設計資料處理設備的處理器以產生一個機器，使得通過電腦或其他可程式設計資料處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程及/或方塊圖一個方塊或多個方塊中指定的功能的裝置。
這些電腦程式指令也可儲存在能引導電腦或其他可程式設計資料處理設備以特定方式工作的電腦可讀記憶體中，使得儲存在該電腦可讀記憶體中的指令產生包括指令裝置的製品，該指令裝置實現在流程圖一個流程或多個流程及/或方塊圖一個方塊或多個方塊中指定的功能。
這些電腦程式指令也可裝載到電腦或其他可程式設計資料處理設備上，使得在電腦或其他可程式設計設備上執行一系列操作步驟以產生電腦實現的處理，從而在電腦或其他可程式設計設備上執行的指令提供用於實現在流程圖一個流程或多個流程及/或方塊圖一個方塊或多個方塊中指定的功能的步驟。
在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和內部記憶體。
內部記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非揮發性內部記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。內部記憶體是電腦可讀媒體的示例。
電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變內部記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可抹除可程式設計唯讀記憶體(EEPROM)、快閃記憶體或其他內部記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存器、磁盒式磁帶，磁帶式磁碟儲存器或其他磁性儲存裝置或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫態媒體(transitory media)，如調變的資料訊號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
本領域技術人員應明白，本說明書的實施例可提供為方法、系統或電腦程式產品。因此，本說明書可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體態樣的實施例的形式。而且，本說明書實施例可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。
以上所述僅為本說明書的實施例而已，並不用於限制本說明書實施例。對於本領域技術人員來說，本說明書實施例可以有各種更改和變化。凡在本說明書實施例的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本說明書實施例的申請專利範圍之內。In order to make the purpose, technical solutions and advantages of this specification clearer, the technical solutions of this specification will be described clearly and completely below in conjunction with specific embodiments of this specification and 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 prior art may cause a large number of members’ privacy data to be leaked 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, so as to avoid the leakage of members' private information due to malicious or improper operations of the merchants.
The following describes in detail the technical solutions provided by the embodiments of this specification in conjunction with the drawings.
As shown in FIG. 1, an embodiment of this specification provides an access control method, and the method may specifically include the following content:
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 equipment may specifically include, but is not limited to, the network media access control (MAC) address, Internet Protocol (IP) address, and network domain of the merchant equipment. Name, host/host, etc.
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 device, and used to uniquely identify the identity of the merchant device. Specifically, the above-mentioned device identity information of the merchant device can be updated on the system side. Maintenance, such as dynamically updating the device identity information of each merchant device based on the merchant's device registration information, real-time online and offline information, and updating the corresponding public key certificate 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. , Identify the merchant’s equipment accurately.
Optionally, this step 103 can be specifically executed as follows:
Based on the device identity information, a verification certificate of the merchant device is generated; 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 upon receiving the access request of the merchant device, the attribute information of the merchant device, that is, the 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, it is determined that the user 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 include the target token value, it will be based on the account and money contained in the user account authentication information. The key performs user identity verification on the user corresponding to the merchant device.
It is understandable that when verifying the user identity of the user corresponding to the merchant's device, that is, the merchant, in order to ensure the user experience when the merchant accesses the system, there is no need to repeatedly enter the account when verifying the user's user identity. And the key to achieve the effect of one-click quick 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, It can be directly confirmed that the user's identity verification is 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 can 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 leads to the leakage of the private data in the system.
Optionally, the number of users corresponding to the above-mentioned merchant device may be one or more, and there is a binding or association relationship between the merchant device and its corresponding users.
Step 107: After the user identity verification is passed, verify whether the merchant device 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 embodiment of this specification provides a zero-trust-based access control scheme for the private data of each member stored in the private data system. Specifically, when an access request from a merchant device is received, the device identity corresponding to the merchant device is required And the user identity of the merchant, that is, the user corresponding to the merchant device, 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 is verified for user identity based on the user account authentication information corresponding to the merchant’s device. After the user’s identity verification is passed, the device identity of the merchant’s device needs to be verified again. To determine whether the business device is a trusted execution environment for the private information 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 on the private data of the target member corresponding to the access request based on the specific situation of the current access. In this way, it is not only necessary to perform zero-trust-based identity verification on merchant devices that access data, but also need to further match specific access control policies to strengthen the control of merchant devices’ access to private data and avoid some Malicious or improper operations cause the leakage of members’ private data, reduce the risk of private data leakage, and improve 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, the result of the first device identity verification is not passed. , You can directly reject the merchant’s device access request.
Further, based on the target public key certificate and device identity information corresponding to the merchant device, after the device identity verification of the merchant device is passed, if the first device identity verification based on the target public key certificate is passed, based on the user account authentication information If the user identity verification on the user corresponding to the merchant device fails, 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 accessed 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 identity verification is passed, the historical access device list can be obtained first to verify whether the currently accessed merchant device matches the historical access device list, and then based on the matching The result determines the specific method for the second verification of the merchant's device 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 device is not included in the aforementioned historical access device list, the merchant device’s identity can be verified a second time based on the aforementioned device digital certificate and the digital signature of the target device associated with the device digital certificate. Whether the merchant device is a trusted execution environment. Specifically, the foregoing step 107 may be specifically executed as the following content:
Obtain a list of historical access equipment;
If the merchant device is not in the historical access device list, verify whether the merchant device is a trusted execution environment based on the device digital certificate and the digital signature of the target device.
Further, the above-mentioned step of verifying whether the merchant device is a trusted execution environment based on the device digital certificate and the target device digital signature may be specifically executed as follows:
Obtain the historical device digital signature corresponding to the pre-stored device digital certificate;
If the digital signature of the historical device is the same as the digital signature of the target device, the merchant device is determined to be a trusted execution environment;
If the digital certificate of the historical device 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 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 in the embodiment of this specification may further include the following content:
Add merchant equipment to the list of historical access equipment.
It can be understood that after 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 access status of the merchant device in the list .
Further, in the above-mentioned historical access device list, it is also possible to set a label for whether the merchant 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 It is recorded in the list of black equipment, among which, the black equipment can specifically be the 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 check for the merchant’s equipment maintained in the historical access equipment list. Removal strategies, such as: regularly clear a batch of devices with a high loading time or clear all, or decide whether to remove them from the list in time according to the frequency of access to the merchant’s equipment, so as to improve the use of the historical access equipment list At the same time of value, set a certain validity period for the merchant equipment as valid equipment or black equipment stored in the historical equipment access list to avoid misjudgment during identity verification due to untimely update of the status of the equipment, resulting in the leakage or impact of private information The user experience of accessing private data.
Then, if 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 trusted execution environment label. Specifically, the foregoing step 107 may 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 devices, the historical behavior identifier corresponding to the merchant device is obtained, and based on the historical behavior identifier, it is verified whether the merchant device is a trusted execution environment.
Further, the above step of verifying whether the merchant device is a trusted execution environment based on the historical behavior identification can be specifically executed as follows:
If the historical behavior identifier indicates that the merchant device is a historically trusted device, then the merchant device is determined to be a trusted execution environment;
If the historical behavior indicator indicates that the merchant device is a historical black device, it is determined that the merchant device is an untrusted execution environment.
It can be understood that if the merchant device has a trusted execution environment label in the historical device access list, that is, the historical behavior identifier indicates that it is a historically trusted device, it means that when the merchant device belongs to the ranks of valid devices, it is directly determined as Trusted execution environment; and if the merchant device has a trusted execution environment label in the historical device access list, that is, the historical behavior identifier indicates that it is a historical black device, it means that the merchant device belongs to the ranks of black devices, directly determine It is an untrusted execution environment.
Optionally, in the access control method of the embodiment of this specification, the foregoing step 109 may specifically include the following content:
Based on the access request, obtain the attribute information of the target member and the access authority information of the user corresponding to the merchant device;
Determine an access control strategy based on at least one of the identity verification result, attribute information, and access authority information.
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 information of the user with which the merchant device is bound or associated. For access rights, determine the matching access control strategy to control its access to members’ private information.
Wherein, the aforementioned identity verification result may specifically include a device identity verification result for verifying whether the merchant device is a trusted execution environment. In other words, the above step 109 can also be specifically expressed as:
Determine the access control strategy of the merchant equipment according to the identity verification result of whether the merchant device is a trusted execution environment or the device identity verification result, and access the private data of the target member corresponding to the access request based on the access control strategy.
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 also be specifically executed as follows:
Based on the access request, obtain the attribute information of the target member and the access authority information of the user corresponding to the merchant device;
Determine an access control strategy 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 authority information.
Further, determining the access control strategy based on at least one of the identity verification result, the attribute information and the access authority information may specifically include: determining the access control strategy of the merchant equipment only based on the identity verification result.
More specifically, it can be executed as follows: determining the access control policy of the merchant device according to the device identity verification result of verifying whether the merchant device is a trusted execution environment.
To be more specific, 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 can be directly rejected Access request for the device. 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 corresponding access request of the merchant device can be called The private information of the target member of the company can be provided to the merchant’s device for the user to view, etc.
Further, after verifying that the merchant device is a trusted execution environment, in addition to directly calling the target member’s private data corresponding to the merchant device’s access request and feeding it back to the merchant device’s access control method, it is also necessary to further combine the above goals At least one of the attribute information of the member and the access authority information of the user corresponding to the merchant device determines the access control strategy.
To be more specific, if the obtained target member’s attribute information is a senior member and the sensitive level is higher 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, after all levels of identity verification of the merchant equipment are passed, and the obtained access authority information corresponding to the merchant equipment temporarily restricts access to the member’s private data, the merchant equipment’s access request can be directly rejected.
It should be noted that the above access control strategy is only some specific examples, and others can be determined based on at least one of the identity verification result of the merchant device, the attribute information of the target member, and the access authority information of the user corresponding to the merchant device The access control strategies for members' private information 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 currently temporarily restricted.
The specific composition of the system for controlling access to private data according to the embodiment of the present specification will be described in detail below in conjunction with FIG. 2. Specifically:
(1) Merchant request receiving module 201
The merchant request receiving module 201 is mainly responsible for receiving merchant access requests, such as API access requests, data inventory access requests, file access requests, and so on. Among them, the merchant device digital certificate and the merchant device digital signature need to be passed in in the merchant access request.
(2) Unified identity management identification module 203, including two sub-modules: a unified identity management module and a unique identification module
Among them, the unified identity management module is responsible for using the unique public key certificate to identify the identity of the merchant's equipment, and dynamically update the merchant's access device library according to the information of the merchant's equipment registration, online and offline, to ensure that the public key certificate can uniquely and accurately identify the Merchant equipment. 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 device passed by the merchant by using the same calculation method corresponding to the unique public key certificate based on the merchant equipment information collected by the unified identity management module, that is, using the same calculation method for unified identity management The information of the merchant device that initiated the access request collected by the module 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.
(3) 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 for accessing that meets the certification Request authorization.
Among them, the single sign-on sub-module is used to ensure that the merchant does not need to log in repeatedly during multiple access processes, and only needs to log in with an account and a key during the first login. 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 the secondary verification of the identity of the merchant equipment based on the merchant equipment digital certificate and the merchant equipment digital signature to determine whether the merchant equipment 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.
(4) Authentication and authorization auxiliary module 207, which mainly provides necessary auxiliary information for authentication and authorization module 205, which includes four sub-modules: merchant access equipment list service, member attributes, merchant/merchant group database, and merchant access strategy group.
Among them, the merchant access equipment list service sub-module mainly records the historical access equipment list of the merchant, which can be further divided into information such as the effective equipment list and the merchant's black equipment list. When the merchant equipment identity verification is performed in the access agent sub-module, the merchant equipment needs to be matched with the merchant historical access equipment list to determine whether the merchant equipment is the historical access equipment of the system, and if so, the merchant can be further determined The specific list to which the equipment belongs, that is, the valid equipment list or the merchant's black equipment list. For historically accessed devices, perform historical behavior identification, such as historically trusted devices, historical black devices, historical access conditions, etc.; for 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 relationship between the merchant/merchant group and the merchant device according to the merchant application/update status Latest relationship. When receiving a request for accessing a merchant device, the corresponding merchant/merchant group needs to be backfilled into the request.
The member attribute sub-module is used to record the member's attribute information, such as membership level, member sensitivity level, member effective attributes, member registration time and other information. 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 equipment identity authentication result, the merchant access equipment list, the access authority of the merchant/merchant group, and the member attribute information. such as:
When the access agent submodule fails to verify the identity of the merchant device, that is, when the merchant device is in an untrusted execution environment, the access request is rejected.
When it is detected that the merchant device is a historically non-accessible 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 merchant's current access member is a senior and sensitive member, the access to the member's private data information is restricted.
(5) Member Merchant Service Module 209
The member merchant service module 209 only outputs the requested member's private data information according to the merchant's 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-combined access control strategies 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 equipment 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, provide zero-trust network for people, equipment, applications, The system and other physical entities establish a unified digital identity and governance process, build a dynamic access control system, extend the security boundary to the identity entity, and realize the security architecture's gateway forward, which improves the security of data access.
The embodiment of the present specification also provides an access control device. As shown in FIG. 3, the device may specifically include:
The obtaining module 301 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 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 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 307 is used to verify whether the merchant equipment is a trusted execution environment after the user identity verification is passed;
The control 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 the present specification, the above-mentioned 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;
Among them, the above-mentioned third verification module 307 can be specifically used for:
Obtain a list of historical access equipment;
If the merchant device is not in the historical access device list, verify whether the merchant 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 device of the embodiment of this specification, the above-mentioned third verification module 307 may also be specifically used for:
Obtain the historical device digital signature corresponding to the pre-stored device digital certificate;
If the digital signature of the historical device is the same as the digital signature of the target device, the merchant device is determined to be a trusted execution environment;
If the digital certificate of the historical device is different from the digital signature of the target device, it is determined that the merchant device is an untrusted execution environment.
Optionally, the access control device in the embodiment of this specification may further include:
The update module is used to add merchant equipment to the historical access equipment list.
Optionally, in the access control device of the embodiment of this specification, the above-mentioned third verification module 307 may be specifically used for:
Obtain a list of historical access equipment;
If the merchant device is in the list of historical access devices, the historical behavior identifier corresponding to the merchant device is obtained, and based on the historical behavior identifier, it is verified whether the merchant device is a trusted execution environment.
Optionally, in the access control device of the embodiment of this specification, the above-mentioned third verification module 307 may also be specifically used for:
If the historical behavior identifier indicates that the merchant device is a historically trusted device, then the merchant device is determined to be a trusted execution environment;
If the historical behavior indicator indicates that the merchant device is a historical black device, it is determined that the merchant device is an untrusted execution environment.
Optionally, in the access control device of the embodiment of this specification, the above-mentioned control module 309 may be specifically used for:
Based on the access request, obtain the attribute information of the target member and the access authority information of the user corresponding to the merchant device;
Determine an access control strategy based on at least one of the identity verification result, attribute information, and access authority information.
Optionally, in the access control device of the embodiment of this specification, the aforementioned attribute information includes member registration information, member time limit information, member level, and member sensitivity level;
The above-mentioned access authority information includes whether there is permission to access private data.
Optionally, in the access control device of the embodiment of this specification, the above-mentioned first verification module 303 may be specifically used for:
Generate a verification certificate for merchant equipment based on equipment 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.
Optionally, in the access control device of the embodiment of this specification, the above-mentioned second verification module 305 may be specifically used for:
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, it is determined that the user 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 include the target token value, it will be based on the account and money contained in the user account authentication information. The key performs user identity verification on the user corresponding to the merchant device.
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.
The embodiment of this specification provides a zero-trust-based access control scheme for the private data of each member stored in the private data system. Specifically, when an access request from a merchant device is received, the device identity corresponding to the merchant device is required And the user identity of the merchant, that is, the user corresponding to the merchant device, 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 is verified for user identity based on the user account authentication information corresponding to the merchant’s device. After the user’s identity verification is passed, the device identity of the merchant’s device needs to be verified again. To determine whether the business device is a trusted execution environment for the private information 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 on the private data of the target member corresponding to the access request based on the specific situation of the current access. In this way, it is not only necessary to perform zero-trust-based identity verification on merchant devices that access data, but also need to further match specific access control policies to strengthen the control of merchant devices’ access to private data and avoid some Malicious or improper operations cause the leakage of members’ private data, reduce the risk of private data leakage, and improve the security of data access.
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 internal memory, such as high-speed random-access memory (Random-Access Memory, RAM), and may also include non-volatile memory (non-volatile memory), such as at least one magnetic disk memory. Wait. Of course, the electronic equipment may also include hardware required by other businesses.
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 or a Peripheral Component Interconnect (PCI) bus Or extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, etc. Bus can be divided into address bus, data bus, control bus, etc. For ease of presentation, only one double-headed arrow is used to indicate in FIG. 4, but it does not mean that there is only one busbar or one type of busbar.
Memory, used to store programs. Specifically, the program may include program code, and the program code includes computer operating instructions. The memory may include internal 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 internal memory and then runs, forming an access control device on the logical level. The processor executes the programs stored in the memory, and is specifically used 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;
Based on the target public key certificate and device identity information corresponding to the merchant device, perform device identity verification on the merchant device;
After 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;
After the user’s identity verification is passed, verify whether the merchant’s 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 embodiment of this specification provides a zero-trust-based access control scheme for the private data of each member stored in the private data system. Specifically, when an access request from a merchant device is received, the device identity corresponding to the merchant device is required And the user identity of the merchant, that is, the user corresponding to the merchant device, 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 is verified for user identity based on the user account authentication information corresponding to the merchant’s device. After the user’s identity verification is passed, the device identity of the merchant’s device needs to be verified again. To determine whether the business device is a trusted execution environment for the private information 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 on the private data of the target member corresponding to the access request based on the specific situation of the current access. In this way, it is not only necessary to perform zero-trust-based identity verification on merchant devices that access data, but also need to further match specific access control policies to strengthen the control of merchant devices’ access to private data and avoid some Malicious or improper operations cause the leakage of members’ private data, reduce the risk of private data leakage, and improve the security of data access.
The foregoing method executed by the access control apparatus disclosed in the embodiment shown in FIG. 1 of this specification may be applied to a processor or implemented by the processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, the steps of the above method can be completed by hardware integrated logic circuits 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 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 logic 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 by a hardware decoding processor, or executed 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 memory, flash memory, read-only memory, programmable read-only memory, or electrically readable, writable and programmable memory, register. 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 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 , Enabling the electronic device to execute the method executed by the access control device in the embodiment shown in FIG. 1, and specifically for executing:
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;
Based on the target public key certificate and device identity information corresponding to the merchant device, perform device identity verification on the merchant device;
After 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;
After the user’s identity verification is passed, verify whether the merchant’s 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 embodiment of this specification provides a zero-trust-based access control scheme for the private data of each member stored in the private data system. Specifically, when an access request from a merchant device is received, the device identity corresponding to the merchant device is required And the user identity of the merchant, that is, the user corresponding to the merchant device, 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 is verified for user identity based on the user account authentication information corresponding to the merchant’s device. After the user’s identity verification is passed, the device identity of the merchant’s device needs to be verified again. To determine whether the business device is a trusted execution environment for the private information 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 on the private data of the target member corresponding to the access request based on the specific situation of the current access. In this way, it is not only necessary to perform zero-trust-based identity verification on merchant devices that access data, but also need to further match specific access control policies to strengthen the control of merchant devices’ access to private data and avoid some Malicious or improper operations cause the leakage of members’ private data, reduce the risk of private data leakage, and improve the security of data access.
Those skilled in the art should understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may adopt the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present specification may adopt computer program products implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program codes. form.
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 processors of general-purpose computers, dedicated computers, embedded processors, or other programmable data processing equipment to generate a machine that can be executed by the processors of the computer or other programmable data processing equipment A device for realizing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram is generated.
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 generate a product including the instruction device, The instruction 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 generate computer-implemented processing, so that the computer or other programmable equipment The instructions executed above provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.
In a typical configuration, the computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and internal memory.
Internal memory may include non-permanent memory in computer-readable media, random access memory (RAM) and/or non-volatile internal memory, such as read-only memory (ROM) or flash memory (flash RAM). Internal 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. 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 internal memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM). ), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other internal memory technology, CD-ROM, digital Versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape 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 includes not only those elements, but also 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.
Those skilled in the art should understand that the embodiments of this specification can be provided as methods, systems or computer program products. Therefore, this specification may adopt the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of this specification can adopt computer program products implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program codes. form.
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 embodiments of this specification shall be included in the scope of patent application of the embodiments of this specification.
