Secure and Reliable Data Access

Abstract

A computer-implemented method for configuring access to secure data, the method comprising: identifying an application programming interface (API) associated with a data access application; determining a first application access mode of the data access application based on the identified API; verifying the first application access mode based on a comparison of the first application access mode with a pre-approved application access mode for accessing secure data; and generating an application container comprising the secure data and the verified first application access mode, the application container being configured to grant access to the secure data through the second API when a second application access mode associated with the second API matches the verified first application access mode.

Description

Technical Field

[0001] The present disclosure relates to techniques for providing access to data, including methods, apparatus, and computer-readable media for providing secure and reliable data access. Background Art

[0002] Big data and machine learning require vast amounts of data to generate meaningful insights and guide business behavior. The increased demand for data access presents unique opportunities and challenges for data owners and the data rental market.

[0003] Traditional data access and data leasing models provide full access and control of data to the tenant (also known as the data renter) or the buyer of the data. More specifically, after transferring the data to the tenant (or buyer), the data owner loses ownership of the data. As a result, the data owner cannot prevent the data renter / buyer from manipulating and copying the acquired information for purposes other than those originally provided to and consented to by the data owner (for example, the tenant / buyer could resell the data for profit, manipulate the data to generate derivative data, or perform other functions not consented to by the data owner before leasing / selling the data).

[0004] One approach to addressing these shortcomings is to require the data renter / buyer to submit data queries (or data access applications) to the data owner to be used in conjunction with the data, and the data owner can respond and return only the portion of the data that is relevant to the query (or data access application) and has been pre-approved for use by the data renter / buyer. A disadvantage of this setup is that the data renter / buyer may experience a lack of flexibility when multiple remote queries must be executed. Other disadvantages are associated with information leakage and data security on the data renter / buyer side when performing continuous data queries and processing multiple data responses to respond to the queries. In addition, running the data renter / buyer's data access application or query in the data owner's network environment may disclose the data renter / buyer's own trade secrets or other proprietary information. Summary of the Invention

[0005] Various examples are now described to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] According to a first aspect of the present disclosure, a computer-implemented method is provided for configuring access to secure data. The method comprises: identifying a first application programming interface (API) associated with a data access application; determining a first application access mode of the data access application based on the identified first API; verifying the first application access mode based on a comparison of the first application access mode with a pre-approved application access mode for accessing the secure data; and generating an application container including the secure data and the verified first application access mode, the application container being configured to grant access to the secure data through a second API when a second application access mode associated with the second API matches the verified first application access mode.

[0007] In a first implementation form of the method according to such first aspect, a data processing process of the data access application is retrieved, and the determination of the first application access pattern of the data access application is further based on the data processing process.

[0008] In a second implementation form of the method according to such first aspect or any preceding implementation form of the first aspect, the data processing process of the data access application and the first API are retrieved based on a request to access the secure data, the request being received from a data renter.

[0009] In a third implementation form of the method according to such first aspect or any preceding implementation form of the first aspect, a verified application signature of the data access application is retrieved from an application verification service. The verified application signature is generated during pre-approval of the data access application for accessing the secure data.

[0010] In a fourth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, an application signature is generated using the data processing process of the data access application. The data access application is authenticated based on a comparison of the authenticated application signature and the generated application signature. Upon successful authentication of the data access application, the application container is generated to include the authenticated application signature.

[0011] In a fifth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, a verified API access pattern signature for the first API is retrieved from an application verification service. The verified API access pattern signature is generated during pre-approval of the first API for accessing the secure data.

[0012] In a sixth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, a signature is generated for the application access pattern. The application access pattern is verified based on a comparison of the generated signature with the verified API access pattern signature. Upon successful verification of the application access pattern, the application container is generated to include the verified API access pattern signature.

[0013] In a seventh implementation form of the method according to such first aspect or any preceding implementation form of the first aspect, the determination of the first application access pattern of the data access application is further based on a static analysis or a dynamic analysis of the identified first API.

[0014] In an eighth implementation form of the method according to such first aspect or any preceding implementation form of the first aspect, said static analysis of said identified first API comprises tracking information flow using said identified first API and based on a predetermined sensitivity of said security data.

[0015] In a ninth implementation form of the method according to such a first aspect or any preceding implementation form of the first aspect, the dynamic analysis of the identified first API includes receiving input specifying a data access technology, retrieving a machine learning model trained with the data access technology, and determining the first application access pattern by applying the machine learning model to the identified first API.

[0016] According to a second aspect of the present disclosure, there is provided a system for configuring access to secure data, comprising a memory storing instructions, and one or more processors in communication with the memory. The one or more processors execute the instructions to: identify an application programming interface (API) associated with a data access application; determine a first application access mode of the data access application based on the identified first API; verify the first application access mode based on a comparison of the first application access mode with a pre-approved application access mode for accessing the secure data; and generate an application container including the secure data and the verified first application access mode, the application container being configured to grant access to the secure data through a second API when a second application access mode associated with the second API matches the verified first application access mode.

[0017] In a first implementation form of the system according to the second aspect, the one or more processors execute the instructions to retrieve a data processing process of the data access application. The determination of the first application access mode of the data access application is further based on the data processing process.

[0018] In a second implementation form of the system according to such a second aspect or any preceding implementation form of the second aspect, the one or more processors execute the instructions to retrieve the data processing process of the data access application and the first API based on a request to access the secure data, the request being received from a data renter.

[0019] In a third implementation form of the system according to such second aspect or any preceding implementation form of the second aspect, the one or more processors execute the instructions to retrieve a verified application signature of the data access application from an application verification service, the verified application signature being generated during pre-approval of the data access application for accessing the secure data.

[0020] In a fourth implementation form of the system according to such a second aspect or any preceding implementation form of the second aspect, the one or more processors execute the instructions to: generate an application signature using the data processing process of the data access application; verify the data access application based on a comparison of the verified application signature and the generated application signature; and based on successful verification of the data access application, generate the application container to include the verified application signature.

[0021] In a fifth implementation form of the system according to such a second aspect or any preceding implementation form of the second aspect, the one or more processors execute the instructions to retrieve a verified API access mode signature of the first API from an application verification service, wherein the verified API access mode signature is generated during pre-approval of the first API for accessing the secure data.

[0022] In a sixth implementation form of the system according to such a second aspect or any preceding implementation form of the second aspect, the one or more processors execute the instructions to: generate a signature for the application access mode; verify the first application access mode based on a comparison of the generated signature with the verified API access mode signature; and based on successful verification of the application access mode, generate the application container to include the verified API access mode signature.

[0023] According to a third aspect of the present disclosure, a non-transitory computer-readable medium is provided, storing instructions for configuring access to secure data, wherein the instructions, when executed by one or more processors, cause the one or more processors to perform operations. The operations include identifying an application programming interface (API) associated with a data access application, determining a first application access mode of the data access application based on the identified first API, and verifying the first application access mode based on a comparison of the first application access mode with a pre-approved application access mode for accessing the secure data. The operations also include generating an application container including the secure data and the verified first application access mode, the application container being configured to grant access to the secure data through a second API when a second application access mode associated with a second API matches the verified first application access mode.

[0024] In a first implementation form of a non-transitory computer-readable medium according to such a third aspect, the instructions, when executed, further cause the one or more processors to perform operations including the following steps: retrieving a verified API access mode signature for the first API from an application verification service, the verified API access mode signature being generated during pre-approval of the first API for accessing the secure data.

[0025] In a second implementation form of the non-transitory computer-readable medium according to such a third aspect, the instructions, when executed, further cause the one or more processors to perform operations including the following steps: generating a signature for the application access mode, verifying the first application access mode based on a comparison of the generated signature with the verified API access mode signature, and generating the application container to include the verified API access mode signature based on successful verification of the application access mode.

[0026] Any of the foregoing examples can be combined with any one or more of the other foregoing examples to create new embodiments within the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views.The drawings illustrate generally, by way of example and not limitation, the various embodiments discussed in this document.

[0028] Figure 1 is a block diagram of a secure data access apparatus (SDAA) in communication with a data access application according to some example embodiments.

[0029] Figure 2is a block diagram of a network-based service infrastructure that data owners may use to configure SDAA for secure and reliable data access, according to some example embodiments.

[0030] Figure 3 is a swimlane diagram illustrating an example communication exchange between a data owner and a data renter for configuring secure and reliable data access, according to some example embodiments.

[0031] Figure 4 is a block diagram of a data control gateway within an SDAA, according to some example embodiments.

[0032] Figure 5A is a flowchart of a method for authorizing SDAA for secure and reliable data access, according to some example embodiments.

[0033] Figure 5B According to some example embodiments, Figure 5A A flowchart of a method in which SDAA is used for static analysis to determine data access patterns.

[0034] Figure 5C According to some example embodiments, Figure 5A A flowchart of a method in which the purpose of SDAA is to perform dynamic analysis to determine data access patterns.

[0035] Figure 6 is a flow chart of a method for secure and reliable data access based on analysis of near data processing (NDP) application signatures and access patterns, according to some example embodiments.

[0036] Figure 7 is a flowchart of a method for secure and reliable data access based on data usage statistics, according to some example embodiments.

[0037] Figure 8 is a flowchart of a method for generating an application container of SDAA to provide secure and reliable data access, according to some example embodiments.

[0038] Figure 9 is a block diagram illustrating a representative software architecture that may be used in conjunction with the various device hardware described herein, according to some example embodiments.

[0039] Figure 10 is a block diagram illustrating circuits of apparatuses for implementing algorithms and performing methods, according to some example embodiments. DETAILED DESCRIPTION

[0040] It should be understood at the outset that although illustrative implementations of one or more embodiments are provided below, reference is made to Figures 1 to 10 The disclosed systems, methods, and / or devices described herein may be implemented using any number of techniques, whether currently known or not yet available. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with all their equivalents.

[0041] In the following description, reference is made to the accompanying drawings which form a part hereof and in which are shown by way of illustration specific embodiments that may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the subject matter of the present invention, and it is understood that other embodiments may be used and that structural, logical, and electrical changes may be made without departing from the scope of the present disclosure. Therefore, the following description of the example embodiments should not be construed in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0042] As used herein, the term "network-based service infrastructure" includes multiple network devices (also referred to as hosts, nodes, or servers) that provide data access capabilities, on-demand computing capabilities (e.g., through one or more virtual machines or other virtual resources running on the network devices), and / or storage capabilities as a service to a community of end-recipients (e.g., customers of the service infrastructure), wherein, according to some example embodiments, the end-recipients can be communicatively coupled to one or more network devices within the service infrastructure via a network to request services provided by the service infrastructure (e.g., sell or rent data to customers of the service infrastructure). Customers of the service infrastructure can use one or more computing devices (or customer devices) to request, access, configure, or manage services (e.g., data access-related services) provided by the service infrastructure over the network. Customer devices, networks, and network-based service infrastructure can be collectively referred to as the "network infrastructure." Customers of the service infrastructure can also be referred to as "users" or "tenants." Users who request to lease data owned by the service infrastructure can be referred to as "data renters." Users who request to purchase data owned by the service infrastructure can be referred to as "data buyers."

[0043] As used herein, the terms "application process" and "data processing process" are interchangeable and refer to application code associated with performing a specific function (or multiple functions). For example, an "application process" may refer to application code (e.g., binary files and / or libraries) of an application associated with processing data, such as a near data processing (NDP) application. In this regard, the "application process" of an NDP application (or APP) indicates, for example, an application program interface (API) for accessing data, data access patterns, data usage statistics (e.g., information access rate, access duration, access frequency, amount of data accessed, type of accessed data), etc.

[0044] As used herein, the term "application access pattern" is interchangeable with the term "data access pattern" and indicates information associated with the data accessed by an application, including at least one of the following: (a) a model trained with multidimensional features, such as "time of day of access," "total bytes returned per hour," "whether data is stored sequentially," etc.; (b) pre-measured patterns of use cases, such as "search for the top n best matching customers"; (c) only aggregated or allowed rows (with rate limits).

[0045] The techniques disclosed herein can be used to configure secure and reliable access to data (e.g., data requested by a data renter). More specifically, a data owner can provide a data renter with a secure data access appliance (SDAA) that includes the requested data and a data control gateway (DCG) that restricts access to the data based on pre-approved data access verification information. The requested data is stored on the SDAA as encrypted data, which can only be decrypted (and released to the data renter) after the DCG verifies the data access request based on the pre-approved data access verification information. The DCG is configured to execute from a secure container or other type of secure environment in the SDAA. In addition, the DCG includes pre-approved data access verification information, such as pre-approved access modes, API signatures, and data access application signatures. Access to the secure data in the SDAA is granted based on a match between the data access configuration (e.g., application access mode, application signature, API signature, etc.) of the current data access request and the pre-approved data access verification information. The use of the SDAA, access modes, and pre-approved information related to the pre-approved data access verification information are recorded in a public ledger that can be accessed by the data owner or other third parties for auditing and billing.

[0046] To initiate configuration of the SDAA, the data lessee may provide an API (e.g., a first API) or a data access application process to the data owner for analysis. The application access pattern may be determined by the data owner using the API and / or the data access application process. The determined access pattern may be verified by the data owner based on data access standards, pre-approved access patterns, pre-approved data access application signatures, etc. The verified access pattern is stored in the DCG as data access verification information. After access to the SDAA is provided to the data lessee (e.g., the SDAA is delivered to the lessee and the lessee has physical control over the SDAA), the data lessee may attempt to access data in the SDAA using a new API for accessing data in the SDAA (e.g., a second API from the data lessee's data access application). The DCG determines the access pattern of the new API and compares the determined access pattern with the verified access pattern in the data access verification information. Access to the data in the SDAA is authorized based on the comparison and whether the access pattern of the new API matches the verified access pattern.

[0047] In this regard, the techniques disclosed herein provide a secure way (eg, for a data renter) to configure access to data by bundling the data with a data control gateway within the SDAA that can be provided to intended users. The techniques discussed herein for providing secure and reliable data access using SDAA have the following technical advantages and benefits over existing data access techniques: (a) SDAA can be physically shipped or virtually deployed (e.g., data can be encrypted and stored in a remote network and accessed wirelessly by a data lessee, authenticated by a DCG, rather than securely storing the data in the SDAA); (b) SDAA enables data anti-dump functionality by providing access to specific data based on usage data access patterns; (c) SDAA stores the DCG and data in a secure environment (e.g., the DCG is executed from a secure application container and the data is stored in an encrypted format); (d) application and API analysis and verification can use artificial intelligence (AI) and machine learning (ML) techniques to identify access patterns and enforce access patterns that are consistent with prior agreements reflected by verified information stored in the SDAA; and (e) verified information stored in the DCG can be based on call stack and API dependencies, application signature mapping, API signatures, application signatures, etc.

[0048] Figure 1 is a block diagram of an SDAA 102 in communication with a data access application 108 according to some example embodiments. Figure 1, SDAA 102 is configured by a data owner to provide secure and reliable data access to a data access application 108 associated with a data renter. SDAA 102 includes encrypted data 104 and DCG 106 and is configured to use the techniques discussed herein (e.g., in conjunction with Figure 2-Figure 8 The technology discussed above provides secure and reliable data access to the data access application 108 via the network 112. More specifically, Figure 3-5C Details are provided regarding initial approval of an SDAA to be generated for use by a data renter, as well as details regarding configuring the SDAA for use by the data renter in conjunction with a data access application. Figure 6-Figure 8 Details are provided for an example method of using configured SDAA for secure and reliable data access.

[0049] In some embodiments, the reliability of data access provided by the SDAA 102 is achieved through the use of a public ledger 110. More specifically, the public ledger 110 is used by data owners to store information associated with the initial configuration of the SDAA 102 and subsequent use of the SDAA 102 by data access applications 108, including approved or denied data access attempts based on approved or denied data access patterns, data usage statistics, etc.

[0050] In some embodiments, the encrypted data 104 may be stored remotely outside of the SDAA 102 as encrypted data 114 within the network 112. In this case, the SDAA 102 may include the DCG 106, and the DCG 106 may be configured to access the data when data access by the data access application 108 is authorized (e.g., as in conjunction with Figure 6 and Figure 7 As discussed, encrypted data 114 is then retrieved from network 112 based on an analysis of data access patterns of application 108 .

[0051] Figure 2 is a block diagram of a network-based service infrastructure 204 that a data owner may use to configure an SDAA 226 for secure and reliable data access by a data renter 202, according to some example embodiments. Figure 2 , the network architecture 200 includes devices 244 (eg, user devices), a network-based service infrastructure 204 , and an application authentication service 206 , all of which are communicatively coupled to one another via a network 208 .

[0052] Device 244 is associated with data renter 202 and is configured to interact with network-based service infrastructure 204 using a network access client, which can be implemented as a web client or an application (app) client. In some embodiments, the network access client of device 244 can include a data access application 210. Data access application 210 can be an NDP application configured to communicate with multiple network entities within network architecture 200, including application verification service 206, computing device 212, and SDAA 226 in connection with being authorized and obtaining access to encrypted data 230.

[0053] Data renters 202 may generally be referred to as “users 202,” which may include human users (e.g., humans), machine users (e.g., computers configured by software programs to interact with devices 244 and network-based service infrastructure 204), or any suitable combination thereof (e.g., humans assisted by machines or machines supervised by humans). User 202 is not part of network architecture 200, but is associated with (and is a user of) device 244. Device 244 may be a desktop computer, an in-vehicle computer, a tablet computer, a navigation device, a portable media device, or a smartphone belonging to user 202. User 202 may use device 244 to access services and data provided by network-based service infrastructure 204. In this regard, user 202 may also be referred to as a “customer 202” or “tenant 202” of network-based service infrastructure 204.

[0054] The network-based service infrastructure 204 may include multiple computing devices, such as a computing device 212. The computing device 212 includes an application analysis and validation module (AAVM) 214, a gateway configuration module (GCM) 216, and an encryption module (EM) 218. Additional configuration associated with the computing device 212 may be combined with Figure 9 and Figure 10 Discuss in more detail.

[0055] The AAVM 214 comprises suitable circuitry, logic, interfaces and / or code and is configured to perform functions associated with initial approval of an SDAA to be generated for use by a data renter, including performing static or dynamic analysis to determine application access patterns associated with a data access application (e.g., 210), detecting data usage statistics associated with the data access application, storing the determined access patterns, retrieving and storing application signatures and API access pattern signatures, and as such in conjunction with Figure 3 and Figures 5A-5C Other tasks discussed.

[0056] The GCM 216 comprises suitable circuitry, logic, interfaces and / or code and is operable to configure the DCG 228 within the SDAA 226, such as in conjunction with Figure 3 and Figure 4 discussed.

[0057] The encryption module 218 comprises suitable circuitry, logic, interfaces, and / or code and is configured to generate encrypted data 230 within the SDAA 226. More specifically, the AAVM 214 may provide the encryption module 218 with an indication of the data that the user 202 wishes to lease and access via the data access application 210. The encryption module 218 may access the data from the database 222 and encrypt the data using the security key 220 to generate the encrypted data 230 for inclusion in the SDAA 226. The key 220 may also be provided to the DCG 228 so that the DCG 228 can decrypt the data 230 when access by the application 210 is authorized. In an example embodiment, the encryption module 212 may encrypt all data stored in the database 222 prior to receiving the indication from the AAVM 214 that the user 202 wishes to lease the data.

[0058] Although the SDAA 226 is shown as being within the network-based service infrastructure 204, the present disclosure is not limited in this respect. In one embodiment, after the SDAA is approved for use with the data access application 210, the SDAA 226 is configured as a separate physical device that includes the DCG 228 and the encrypted data 230. The SDAA 226 is then provided to the user 202, and the user 202 can access the SDAA 226 through the user device 244 without being connected to the network-based service infrastructure 204. In another embodiment, after the SDAA is approved for use with the data access application 210, the SDAA 226 can be configured as a separate device within the network-based service infrastructure 204, and the user 202 can be provided with access to the SDAA 226 (e.g., through the communication path 236 of the network 208 and the interface 229 of the DCG 228). In yet another embodiment, the encrypted data 230 can be stored at a remote location (e.g., within the network-based service infrastructure 204 or another location accessible via the network 208). DCG 228 may access the remote location to retrieve the data and provide the retrieved data to data access application 210 (eg, based on verification of a data access pattern associated with the API requesting access to encrypted data 230 ).

[0059] The network-based service infrastructure 204 also includes a public ledger 224 that is used during configuration of the SDAA 226 and after the SDAA has been configured. More specifically, the public ledger 224 is used to store information associated with the initial configuration of the SDAA 226 and subsequent use of the SDAA 226 by the data access application 210, including approved or denied data access attempts based on approved or denied data access patterns, data usage statistics, etc. In an example embodiment, the public ledger 224 can be located external to the NBSI 204 (e.g., with a third-party service provider accessible via the network 208).

[0060] The application verification service 206 may be a service provided by the network-based service infrastructure 204 or may be a third-party service used to analyze the data access application 210. In some embodiments, the data access application 210 or a data processing process associated with the data access application 210 is transmitted to the application verification service 206 via the communication path 240 of the network 208. The application verification service 206 analyzes the received application (or data processing process) to determine the API used by the application and the data access pattern of the API. The application verification service 206 also generates an application signature 232 (of the received application 210 or the received data processing process) and an API access pattern signature 234 (of the data access pattern of the determined API). In some embodiments, the network-based service infrastructure 204 may share a security key 220 or other security keys, which may be used by the application verification service 206 to generate the signatures 232 and 234. The generated signatures 232 and 234 are transmitted to the computing device 212 via the communication path 242 of the network 208 for use by the GCM 216 to configure data access verification information used by the DCG 228 (e.g., as Figure 4 shown).

[0061] Figure 2 Any of the devices shown in can be implemented in a general-purpose computer modified (e.g., configured or programmed) by software to become a special-purpose computer to perform the functions described herein for that machine, database, or device. As used herein, a "database" is a data storage resource that stores data that is structured as a text file, table, spreadsheet, relational database (e.g., object-relational database, NoSQL database, network or graph database), triple store, hierarchical data store, or any suitable combination thereof. In addition, data accessed (or stored) through an application program interface (API) or remote procedure call (RPC) can be considered to be accessed from (or stored to) a database. In addition, Figure 2Two or more devices or databases shown in can be combined into a single machine, database or device, and the functionality described herein for any single machine, database or device can be subdivided between multiple machines, databases or devices. In an example embodiment, a file system or other technology can be used to store encrypted data instead of using database 222.

[0062] The network 208 can be any network that enables communication between machines, databases, and devices (e.g., device 244, application verification service 206, SDAA 226 via interface 229, and device 212 within network-based service infrastructure 204). Thus, the network 208 can be a wired network, a wireless network (e.g., a mobile or cellular network), or any suitable combination thereof. The network 208 can include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof.

[0063] Figure 3 is a swim lane diagram 300 illustrating an example communication exchange between a data owner (e.g., network-based service infrastructure 204) and a data renter (e.g., user 202) for configuring secure and reliable data access, according to some example embodiments. Figure 2 and Figure 3 At operation 302, user 202 transmits a request (e.g., via communication path 238 of network 208) to a data owner (e.g., network-based service infrastructure 204) via device 244. The request from user 202 may include a request to rent or purchase data, such as data stored in database 222. At operation 304, network-based service infrastructure 204 transmits a request for data usage information (i.e., what application or API will be used to access the requested data) to device 244. In response, at operation 306, device 244 may submit the data to application 210, one or more APIs associated with application 210, or a data processing process of application 210.

[0064] At operation 308, the AAVM 214 may perform application analysis and validation tasks to determine data access patterns associated with the provided application 210 and to determine whether the configuration of the SDAA for accessing the requested data can be approved for the user 202 associated with the data access application 210. Example application analysis and validation tasks include performing static or dynamic analysis of the application to determine data access patterns (e.g., as combined with Figures 5A-5C), storing the determined access patterns and detecting potential violations of the pre-approved access patterns, retrieving application signatures and API access pattern signatures (e.g., from application verification service 206), determining data usage statistics associated with the provided application 210 (e.g., the type of data accessed, frequency of data access, duration of access, amount of data accessed), etc. Registering the determined data access patterns and data usage statistics that conform to the pre-approved access patterns and user statistics as access patterns and usage statistics that the GCM 216 can use to configure data access verification information within the DCG 228 (e.g., Figure 4 Information 406 and 408 in).

[0065] At operation 310, when the configuration of the SDAA for accessing the requested data is approved, the GCM 216 may configure the DCG 228 (eg, the DCG 228 may be configured with the interface 229 and the data access authentication information (eg, Figure 4 410 in a secure application container). In addition, GCM 216 can use cryptographic module 218 and security key 220 to generate encrypted data 230 using data from database 222 and store encrypted data 230 as part of SDAA 226. At operation 312, SDAA 226 can be shipped to user 202, or otherwise (when SDAA 226 is maintained within network-based service infrastructure 204) user 202 can be provided access to SDAA 226 (e.g., secure access credentials or other types of access information that data access application 210 can use to communicate with SDAA 226 via communication path 236 and interface 229 to access encrypted data 230).

[0066] Figure 4 is a block diagram of a data control gateway 228 within the SDAA 226 according to some example embodiments. Figure 4 , the GCM 216 within the computing device 212 receives the application signature 402 from the application verification service 206 (in Figure 2 232) and API access mode signature 404 (in Figure 2 In addition, the GCM 216 obtains registered access patterns 406 and registered data usage statistics 408 associated with the data access application 210 and obtained during the analysis and verification process (e.g., as combined with Figure 3 The GCM 216 further configures the DCG 228 as a secure application container having a communication interface 229 and data access authentication information 410.

[0067] The data access verification information 410 includes the application signature 402, the API access mode signature 404, the registered access mode 406, and the registered data usage statistics 408. The DCG 228 uses the data access verification information 410 to determine whether to grant access to the encrypted data 230 when the data access application 210 uses the new data access API. Using the data access verification information 410 to determine whether to provide access to the encrypted data 230 in the SDAA 226 will be combined with Figure 6 and Figure 7 Discuss in more detail.

[0068] In some embodiments, GCM 216 may retrieve the requested data from database 222 using encryption module 218, encrypt the retrieved data using security key 220, and store the encrypted data as script data 230 in SDAA 226. Alternatively, GCM 216 may instruct encryption module 218, and encryption module 218 may generate encrypted data 230 and store it in SDAA 226.

[0069] Figure 5A is a flow chart of a method 500 for authorizing SDAA for secure and reliable data access according to some example embodiments. The method 500 includes operations 502-522. By way of example and not limitation, the method 500 is described as being performed by a computing device 212 using modules 214, 216, and 218 (corresponding to Figure 9 Modules 960, 962, and 964, or Figure 10 Modules 1060, 1065 and 1070) are executed.

[0070] At operation 502, computing device 212 (e.g., via communication path 238 of network 208) identifies an application process or API associated with data access application 210. Alternatively, the application process or API is transmitted to computing device 212 by data access application 210. At operation 504, AAVM 214 performs static analysis and / or dynamic analysis to output a determined data access pattern at operation 506. At operation 508, AAVM 214 determines whether the data access pattern is acceptable. For example, AAVM 214 may compare the data access pattern determined using static and / or dynamic analysis of the application process or API associated with data access application 210 to one or more pre-approved data access patterns. If the determined data access pattern matches at least one pre-approved data access pattern, processing continues at operation 516. If the determined data access pattern does not match any pre-approved data access pattern, SDAA generates a rejection notification and transmits it to user 202 at operation 518.

[0071] At operation 510, computing device 212 receives a data usage profile from user 202 as input. For example, AAVM 214 may receive configuration information from data access application 210 indicating the expected data usage of the requested data. At operation 512, AAVM 214 may process the configuration information to generate data usage statistics at operation 514. The data usage statistics may include, for example, data access frequency, access duration, amount of data accessed, or other statistics associated with the data access application 210's proposed data usage for the requested data. At operation 516, AAVM 214 determines whether the data usage statistics are acceptable. For example, AAVM 214 may compare the data usage statistics determined at operation 514 with pre-approved data usage statistics (e.g., data usage statistics set as acceptable by the network operator of network-based service infrastructure 204). If the determined data usage statistics do not match the pre-approved data usage statistics, SDAA generation is denied at operation 518 and a notification is transmitted to user 202. When the determined usage statistics match the pre-approved data usage statistics, at operation 520, the determined data access pattern in the data usage statistics is registered (e.g., as registered access pattern 406 and registered data usage statistics 408) for subsequent use by the GCM 2164 configuring the DCG 228. At operation 522, generation of the SDAA is approved and a notification is transmitted to the user 202.

[0072] Figure 5B According to some example embodiments, Figure 5A Flowchart of method 530 for static analysis to determine data access patterns for the purpose of SDAA. Figure 5B At operation 532, the AAVM 214 receives an application process or API from the data access application 210. At operation 534, the AAVM 214 tracks the flow of information in the application process or API to detect one or more data access patterns. In an example embodiment, at operation 538, the AAVM 214 may also use a predetermined data sensitivity associated with the data access requested by the data access application 210. For example, the network-based service infrastructure 204 may provide different levels of data sensitivity based on the data type. The predetermined data sensitivity associated with the requested data may also be used at operation 534 to fine-tune the detection of the data access pattern. At operation 536, the data access pattern is output.

[0073] Figure 5C According to some example embodiments, Figure 5A Flowchart of method 540 for dynamic analysis to determine data access patterns. Initially, user 202 may provide (at operation 542) input 1A or (at operation 550) input 1B.

[0074] At operation 542, the user may indicate as input 1A a known technique for accessing data via the data access application 210. At operation 544, the AAVM 214 may receive a predetermined data sensitivity associated with the requested data (e.g., Figure 5B At operation 546, the AAVM 214 may determine, based on the input 1A and the predetermined data sensitivity, whether the machine learning model is available in the network-based service infrastructure 204. If the machine learning model is available, at operation 548, the AAVM 214 outputs the data access pattern from the machine learning model.

[0075] If the machine learning model is not available, then at operation 552, a binary program for a known technique is retrieved (e.g., manually or automatically), and when the retrieved program is executed in a "programming sandbox," processing continues to operation 554 and the results are added to the machine learning model. At operation 556, the AAVM 214 may determine whether an accurate machine learning model is available. If the machine learning model is inaccurate, then at operation 558, the machine learning model input parameters are changed and processing resumes again at operation 554. If the machine learning model is accurate, processing resumes at operation 548 when the AAVM 214 outputs the data access pattern from the machine learning model.

[0076] Alternatively, input 1B is provided at operation 550, which includes an application process or API associated with the data access application 210. At operation 554, the application process or API is executed in a "programming sandbox," and the results are added to the machine learning model. At operation 556, the AAVM 214 can determine whether an accurate machine learning model is available. If the machine learning model is inaccurate, at operation 558, the machine learning model input parameters are changed and processing resumes at operation 554. If the machine learning model is accurate, processing resumes at operation 548 when the AAVM 214 outputs the data access pattern from the machine learning model.

[0077] Figure 6 is a flow chart of a method 600 for secure and reliable data access based on analysis of near data processing (NDP) application signatures and access patterns according to some example embodiments. The method 600 includes operations 602-610. By way of example and not limitation, the method 600 is described as being performed by the SDAA 226 or computing device 212 using modules 214, 216, and 218 (corresponding to Figure 9 Modules 960, 962, and 964, or Figure 10Modules 1060, 1065, and 1070 of the data access application 210 are executed. At operation 602, the application process or API of the data access application 210 is identified by (or otherwise received at) the computing device 212. For example, after the SDAA 226 has been configured and provided to the user 202, a new data access request is transmitted to the SDAA via the communication path 236 and the interface 229. The data access request may include the application process or API associated with the new data access request.

[0078] At operation 604, a signature of the application process or API is generated, and a determination is made as to whether the determined application or API signature matches the data access verification information 410 (e.g., signatures 402 and 404 provided by the application verification service 206). If the signature does not match the data access verification information 410, then at operation 606, the data access attempt by the data access application 210 is logged in the public ledger 224 and future access by the SDAA is disabled.

[0079] If the signature matches the data access verification information 410, at operation 608, a data access pattern associated with the application process or API is generated, and a determination is made as to whether the data access pattern matches the data access verification information 410 (e.g., by determining whether the data access pattern matches the registered access pattern 406). If the access pattern does not match the data access verification information 410, then at operation 606, the data access attempt by the data access application 210 is recorded in the public ledger 224 and future access by the SDAA 226 is disabled. If the access pattern matches the data access verification information 410, then at operation 610, in response to the data access request, the requested data is retrieved (from the encrypted data 230), decrypted, and prepared for transmission back to the data access application 210.

[0080] Figure 7 7 is a flow chart of a method 700 for secure and reliable data access based on data usage statistics according to some example embodiments. In an example embodiment, method 700, as a continuation of method 600, includes operations 702-712. More specifically, operation 702 is the same as operation 610. At operation 704, data usage statistics for the requested data access are determined (e.g., based on a provided application process or API associated with the data access application 210). As previously described, the data usage statistics may include data access frequency, access duration, amount of data accessed, etc. At operation 706, it is determined whether the determined data usage statistics match the registered data usage statistics (e.g., 408) in the data access verification information 410. If the data usage statistics do not match the data access verification information 410, then at operation 708, the data access attempt made by the data access application 210 is recorded in the public ledger 224 and future access by the SDAA 226 is disabled.

[0081] If the data usage statistics match the data access verification information 410, then at operation 710, the data access attempt by the data access application 210 is recorded in the public ledger 224. At operation 712, the decrypted data previously retrieved (at operation 702) is transferred back to the data access application 210 in response to the data access request.

[0082] Figure 8 800 is a flow chart of a method 800 for generating an SDAA application container to provide secure and reliable data access according to some example embodiments. The method 800 includes operations 702, 704, 706, 708, and 710. By way of example and not limitation, the method 800 is described as being performed by a computing device 212 using modules 214, 216, and 218 (corresponding to Figure 9 Modules 960, 962, and 964, or Figure 10 Modules 1060, 1065 and 1070) are executed.

[0083] At operation 802, a first application programming interface (API) associated with a data access application is identified. For example, upon receiving a data access request from the data access application 210, the AAVM 214 may identify the first API associated with the data access request. At operation 804, a first application access mode of the data access application is determined based on the identified first API. For example, static and / or dynamic processing (e.g., combining Figure 5B and Figure 5C discussed) to determine the first application access mode.

[0084] At operation 806, the first application access pattern is verified based on a comparison of the first application access pattern with a pre-approved application access pattern for accessing data. For example, the analysis and verification tasks may be performed by the AAVM 214 in conjunction with Figure 3 and Figure 4 A discussion was held.

[0085] At operation 808, an application container is generated that includes the secure data and the verified first data access mode, wherein the container is configured to grant access to the data when a second API is identified and the second application access mode associated with the second API matches the verified first application access mode. For example, the SDAA 226 can be configured to include the DCG 228 and the encrypted data 230, and subsequent data access requests (e.g., via the new API from the data access application 210) can be processed by the DCG 228 using the data access verification information 410 to determine whether the application access mode associated with the new API matches the verified access mode (e.g., 406 in the data access verification information 410).

[0086] Figure 9 is a block diagram illustrating a representative software architecture 900 that may be used in conjunction with the various device hardware described herein, according to some example embodiments. Figure 9 is only a non-limiting example of a software architecture 902, and it should be understood that many other architectures can be implemented to facilitate the functionality described herein. The software architecture 902 can be implemented in applications such as Figure 10 1000, which includes, but is not limited to, a processor 1005, a memory 1010, storage devices 1015 and 1020, and I / O components (or interfaces) 1025 and 1030. Representative hardware layers 904 are illustrated and may represent, for example, Figure 10 The computing device 1000 of FIG. The representative hardware layer 904 includes one or more processing units 906 with associated executable instructions 908. The executable instructions 908 represent executable instructions of the software architecture 902, including Figures 1-8 The hardware layer 904 also includes a memory and / or storage module 910, which also has executable instructions 908. The hardware layer 904 may also include other hardware 912, which represents any other hardware of the hardware layer 904, such as other hardware described as part of the computing device 1000.

[0087] exist Figure 9 In the example architecture of FIG, software architecture 902 can be conceptualized as a stack of layers, where each layer provides specific functionality. For example, software architecture 902 may include layers such as operating system 914, library 916, framework / middleware 918, application 920, and presentation layer 944. In operation, application 920 and / or other components within the layer can call application program interface (API) calls 924 through the software stack and, in response to API calls 924, receive responses, return values, etc., as shown by message 926. Figure 9 The layers shown are representative in nature, and not all software architectures 902 have all layers. For example, some mobile or specialized operating systems may not provide framework / middleware 918, while other systems may provide such layers. Other software architectures may include additional or different layers.

[0088] The operating system 914 can manage hardware resources and provide public services. The operating system 914 may include, for example, a kernel 928, services 930, and drivers 932. The kernel 928 may act as an abstraction layer between the hardware and other software layers. For example, the kernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. The services 930 may provide other public services to other software layers. The drivers 932 may be responsible for controlling or interfacing with the underlying hardware. For example, the drivers 932 may include display drivers, camera drivers, drivers, flash drives, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), drivers, audio drivers, power management drivers, etc., depending on the hardware configuration.

[0089] Libraries 916 can provide common infrastructure that can be used by applications 920 and / or other components and / or layers. The functionality provided by libraries 916 generally allows other software modules to perform tasks more easily than directly interfacing with underlying operating system 914 functionality (e.g., kernel 928, services 930, and / or drivers 932). Libraries 916 may include system libraries 934 (e.g., the C standard library), which may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, etc. In addition, libraries 916 may include API libraries 936, such as media libraries (e.g., libraries that support the rendering and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.), graphics libraries (e.g., the OpenGL framework that can be used to render 2D and 3D graphics content on a display), database libraries (e.g., SQLite that can provide various relational database functions), web libraries (e.g., WebKit that can provide web browsing functionality), etc. Libraries 916 may also include various other libraries 938 to provide many other APIs to applications 920 and other software components / modules.

[0090] Framework / middleware 918 (sometimes also referred to as middleware) can provide a higher-level common infrastructure that can be used by applications 920 and / or other software components / modules. For example, framework / middleware 918 can provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. Framework / middleware 918 can provide a wide range of other APIs that can be used by applications 920 and / or other software components / modules, some of which can be specific to a particular operating system 914 or platform.

[0091] Applications 920 include built-in applications 940, third-party applications 942, an application analysis and verification module (AAVM) 960, a gateway configuration module (GCM) 962, and an encryption module (EM) 964. In some embodiments, AAVM 960, GCM 962, and EM 964 may be the same as (and perform the same functions as) AAVM 214, GCM 216, and EM 218, respectively.

[0092] Examples of representative built-in applications 940 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and / or a game application. Third-party applications 942 may include any of the built-in applications 940 as well as a wide variety of other applications. In a specific example, third-party applications 942 (e.g., applications developed by entities other than the vendor of a particular platform using Android TM or iOS TM Applications developed with a software development kit (SDK) can be developed on mobile operating systems such as iOS. TM 、Android TM 、 Mobile software running on a mobile phone or other mobile operating system. In this example, third-party applications 942 can call API calls 924 provided by a mobile operating system such as operating system 914 to facilitate the functions described herein.

[0093] Applications 920 can utilize built-in operating system functionality (e.g., kernel 928, services 930, and / or drivers 932), libraries (e.g., system libraries 934, API libraries 936, and other libraries 938), and framework / middleware 918 to create a user interface to interact with system users. Alternatively or additionally, in some systems, interaction with the user can occur through a presentation layer, such as presentation layer 944. In these systems, the application / module "logic" can be separated from the application / module's interactive aspects with the user.

[0094] Some software architectures utilize virtual machines. Figure 9 In the example of , this is illustrated by virtual machine 948. A virtual machine creates a software environment where applications / modules can be run as if they were on a hardware machine (e.g. Figure 9 The virtual machine 948 is executed by the host operating system ( Figure 9 The virtual machine 948 is hosted by an operating system 914 in the host computer and typically, but not always, has a virtual machine monitor 946 that manages the operation of the virtual machine 948 and the interface with the host operating system (i.e., the operating system 914). Software architecture can execute within the virtual machine 948, such as an operating system 950, libraries 952, framework / middleware 954, applications 956, and / or a presentation layer 958. These layers of the software architecture executed within the virtual machine 948 can be the same as the corresponding layers as described above or can be different.

[0095] Figure 10is a block diagram illustrating circuitry for implementing algorithms and executing methods according to some example embodiments. Not all components need be used in various embodiments. For example, a client, server, and cloud-based network device may each use a different set of components, or, in the case of a server, a larger storage device may be used, for example.

[0096] An example computing device in the form of a computer 1000 (also referred to as computing device 1000, network node 1000, computer system 1000, or computer 1000) may include a processor 1005, memory 1010, removable storage 1015, non-removable storage 1020, input interface 1025, output interface 1030, and communication interface 1035, all connected via a bus 1040. Although the example computing device is illustrated and described as a computer 1000, computing devices may take different forms in different embodiments.

[0097] Memory 1010 may include volatile memory 1045 and nonvolatile memory 1050 and may store programs 1055. Computer 1000 may include various computer-readable media, such as volatile memory 1045, nonvolatile memory 1050, removable storage 1015, and non-removable storage 1020, or may have access to a computing environment that includes various computer-readable media. Computer storage includes random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD ROM), digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.

[0098] Computer-readable instructions stored on a computer-readable medium (e.g., program 1055 stored in memory 1010) can be executed by the processor 1005 of the computer 1000. Hard drives, CD-ROMs, and RAM are some examples of items that include non-transitory computer-readable media such as storage devices. The terms "computer-readable medium" and "storage device" do not include carrier waves, as carrier waves are considered to be transient. "Computer-readable non-transitory medium" includes all types of computer-readable media, including magnetic storage media, optical storage media, flash memory media, and solid-state storage media. It should be understood that the software can be installed in a computer and sold with the computer. Alternatively, the software can be obtained and loaded into the computer, including obtaining the software through physical media or distribution systems, including, for example, obtaining the software from a server owned by the software creator or from a server that the software creator does not own but uses. For example, the software can be stored on a server for distribution over the Internet. As used herein, the terms "computer-readable medium" and "machine-readable medium" are interchangeable.

[0099] Program 1055 may utilize modules discussed herein, such as AAVM 1060, GCM 965, and EM 1070. In some embodiments, AAVM 1060, GCM 1065, and EM 1070 may be the same as (and perform the same functions as) AAVM 214, GCM 216, and EM 218, respectively.

[0100] Any one or more modules described herein may be implemented using hardware (e.g., a processor of a machine, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any suitable combination thereof). In addition, any two or more of these modules may be combined into a single module, and the functionality described herein for a single module may be subdivided across multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

[0101] In some aspects, one or more of modules 1060-1070 can be integrated into a single module that performs the respective functions of each integrated module. As discussed herein, a module can include one or both of hardware or software that has been designed to perform one or more functions (e.g., one or more functions related to providing secure and reliable data access as discussed herein).

[0102] Although several embodiments have been described in detail above, other modifications are possible. For example, the logic flows depicted in the figures do not require the particular order or sequence shown to achieve the desired results. Other steps may be provided or eliminated from the described flows, and other components may be added to or removed from the described systems. Other embodiments may be within the scope of the following claims.

[0103] It should also be understood that software comprising one or more computer-executable instructions that facilitate the processes and operations described above with reference to any or all of the steps of the present disclosure can be installed in and sold with one or more computing devices consistent with the present disclosure. Alternatively, the software can be acquired and loaded into one or more computing devices, including acquiring the software via physical media or a distribution system, including, for example, from a server owned by the creator of the software or from a server not owned by the creator of the software but used by the creator of the software. For example, the software can be stored on a server for distribution over the Internet.

[0104] In addition, it will be understood by those skilled in the art that the application of the present disclosure is not limited to the details of the construction and component arrangements set forth in the specification or shown in the drawings. The embodiments herein are capable of other embodiments and can be practiced or implemented in various ways. In addition, it should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered restrictive. "Including," "comprising," or "having" and their variations used herein are intended to cover the items listed thereafter and their equivalents as well as additional items. Unless otherwise limited, the terms "connect," "couple," and "install" and their variations herein are used broadly and cover direct and indirect connections, couplings, and installations. In addition, the terms "connect" and "couple," and their variations are not limited to physical or mechanical connections or couplings. In addition, terms such as up, down, bottom, and top are relative and are used to help illustrate, but are not restrictive.

[0105] The components of the illustrative devices, systems, and methods used in accordance with the illustrated embodiments may be implemented at least in part in digital electronic circuitry, analog electronic circuitry, or computer hardware, firmware, software, or a combination thereof. For example, these components may be implemented as a computer program product, such as a computer program, program code, or computer instructions tangibly embodied in an information carrier or machine-readable storage device, for execution by, or to control the operation of, a data processing apparatus, such as a programmable processor, a computer, or multiple computers.

[0106] Computer programs can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to execute on one computer or multiple computers at one site or distributed across multiple sites and interconnected by a communication network. In addition, functional programs, codes, and code segments for implementing the techniques described herein can be readily interpreted by programmers in the art to which the techniques described herein belong as being within the scope of the claims. The method steps associated with the illustrative embodiments can be performed by one or more programmable processors that execute computer programs, codes, or instructions to perform functions (e.g., by operating on input data and / or generating output). The method steps can also be performed by dedicated logic circuitry, and the apparatus for performing these methods can be implemented as dedicated logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0107] The various illustrative logical blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0108] Processors suitable for executing computer programs include, for example, general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Typically, a processor will receive instructions and data from read-only memory or random access memory, or both. The required elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic, magneto-optical, or optical disks, or be operatively coupled to receive data from or transfer data to, or both, such mass storage devices. Suitable information carriers for embodying computer program instructions and data include all forms of non-volatile memory, including, for example, semiconductor memory devices, such as electrically programmable read-only memory or ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks). The processor and memory may be supplemented by, or incorporated into, special-purpose logic circuitry.

[0109] Those skilled in the art will appreciate that any of a variety of different technologies and techniques may be used to represent information and signals. For example, references to data, instructions, commands, information, signals, bits, symbols, and chips throughout the foregoing specification may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0110] As used herein, a “machine-readable medium” (or “computer-readable medium”) refers to a device capable of temporarily or permanently storing instructions and data, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), cache memory, flash memory, optical media, magnetic media, cache memory, other types of storage devices (e.g., erasable programmable read-only memory (EEPROM)), and / or any suitable combination thereof. The term “machine-readable medium” should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that can store processor instructions. The term “machine-readable medium” should also be understood to include any medium (or combination of multiple media) that can store instructions for execution by one or more processors 1005, such that the instructions, when executed by one or more processors 1005, cause the one or more processors 1005 to perform any one or more of the methods described herein. Thus, a “machine-readable medium” refers to a single storage device or device, as well as a “cloud-based” storage system or storage network comprising multiple storage devices or devices. As used herein, the term “machine-readable medium” does not include the signal itself.

[0111] In addition, without departing from the scope of the present disclosure, the techniques, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, which may be electrical, mechanical, or other means. Other examples of changes, substitutions, and modifications are ascertainable by those skilled in the art and may be made without departing from the scope of the present disclosure.

[0112] Although the present disclosure has been described with reference to specific features and embodiments thereof, it will be apparent that various modifications and combinations thereof may be made without departing from the scope of the present disclosure. For example, other components may be added to or removed from the system. Accordingly, the specification and drawings are to be considered simply as illustrations of the present disclosure as defined by the appended claims, and are intended to cover any and all modifications, variations, combinations, or equivalents falling within the scope of the present disclosure. Other aspects may be within the scope of the following claims.

Claims

1. A computer-implemented method for configuring access to secure data, the method comprising: identifying a first application programming interface (API) associated with a data access application; determining a first application access mode of the data access application based on the identified first API; verifying the first application access pattern based on a comparison of the first application access pattern with a pre-approved application access pattern for accessing the secure data; as well as Generate an application container including the security data and the verified first application access mode, wherein the application container is configured to grant access to the security data through the second API when the second application access mode associated with the second API matches the verified first application access mode.

2. The computer-implemented method of claim 1 , further comprising: Retrieving a data processing process of the data access application; And among them Determination of the first application access pattern of the data access application is further based on the data processing process.

3. The computer-implemented method of claim 2 , further comprising: The data processing process of the data access application and the first API are retrieved based on a request to access the secure data, the request being received from a data renter.

4. The computer-implemented method of claim 2 , further comprising: A verified application signature of the data access application is retrieved from an application verification service, the verified application signature generated during pre-approval of the data access application for accessing the secure data.

5. The computer-implemented method of claim 4 , further comprising: generating an application signature using the data processing process of the data access application; authenticating the data access application based on a comparison of the verified application signature and the generated application signature; as well as Based on successful authentication of the data access application, the application container is generated to include the authenticated application signature.

6. The computer-implemented method of claim 1 , further comprising: A verified API access mode signature for the first API is retrieved from an application verification service, the verified API access mode signature being generated during pre-approval of the first API for accessing the secure data.

7. The computer-implemented method of claim 6 , further comprising: generating a signature for the application access mode; verifying the application access mode based on a comparison of the generated signature with the verified API access mode signature; as well as Based on successful verification of the application access mode, the application container is generated to include the verified API access mode signature.

8. The computer-implemented method of claim 1 , wherein: Determination of the first application access pattern of the data access application is further based on static analysis or dynamic analysis of the identified first API.

9. The computer-implemented method of claim 8, wherein: The static analysis of the identified first API includes tracking information flow using the identified first API and based on a predetermined sensitivity of the security data.

10. The computer-implemented method of claim 8, wherein: The dynamic analysis of the identified first API includes: receiving input specifying a data access technology; Retrieving a machine learning model trained using the data access technology; and The first application access pattern is determined by applying the machine learning model to the identified first API.

11. A system for configuring access to secure data, the system comprising: a memory for storing instructions; as well as one or more processors in communication with the memory, wherein the one or more processors execute the instructions to: identifying a first application programming interface (API) associated with a data access application; determining a first application access mode of the data access application based on the identified first API; verifying the first application access pattern based on a comparison of the first application access pattern with a pre-approved application access pattern for accessing the secure data; as well as Generate an application container including the security data and the verified first application access mode, wherein the application container is configured to grant access to the security data through the second API when the second application access mode associated with the second API matches the verified first application access mode.

12. The system of claim 11, wherein the one or more processors execute the instructions to: Retrieving a data processing process of the data access application; and wherein Determination of the first application access pattern of the data access application is further based on the data processing process.

13. The system according to claim 12, wherein: The one or more processors execute the instructions to: The data processing process of the data access application and the first API are retrieved based on a request to access the secure data, the request being received from a data renter.

14. The system of claim 12, wherein the one or more processors execute the instructions to: A verified application signature of the data access application is retrieved from an application verification service, the verified application signature generated during pre-approval of the data access application for accessing the secure data.

15. The system according to claim 14, wherein: The one or more processors execute the instructions to: generating an application signature using the data processing process of the data access application; authenticating the data access application based on a comparison of the verified application signature and the generated application signature; as well as Based on successful authentication of the data access application, the application container is generated to include the authenticated application signature.

16. The system according to claim 11, wherein The one or more processors execute the instructions to: A verified API access mode signature for the first API is retrieved from an application verification service, the verified API access mode signature being generated during pre-approval of the first API for accessing the secure data.

17. The system according to claim 16, wherein: The one or more processors execute the instructions to: generating a signature for the application access mode; verifying the first application access mode based on a comparison of the generated signature with the verified API access mode signature; as well as Based on successful verification of the application access mode, the application container is generated to include the verified API access mode signature.

18. A computer-readable medium storing computer instructions for configuring access to secure data, wherein the instructions, when executed by one or more processors, cause the one or more processors to perform the following steps, comprising: identifying a first application programming interface (API) associated with a data access application; determining a first application access mode of the data access application based on the identified first API; verifying the first application access pattern based on a comparison of the first application access pattern with a pre-approved application access pattern for accessing the secure data; as well as Generate an application container including the security data and the verified first application access mode, wherein the application container is configured to grant access to the security data through the second API when the second application access mode associated with the second API matches the verified first application access mode.

19. The computer-readable medium of claim 18, wherein: The instructions further cause the one or more processors to perform the following steps, including: A verified API access mode signature for the first API is retrieved from an application verification service, the verified API access mode signature being generated during pre-approval of the first API for accessing the secure data.

20. The computer-readable medium of claim 19, wherein: The instructions further cause the one or more processors to perform the following steps, including: generating a signature for the application access mode; verifying the first application access pattern based on a comparison of the generated signature with the verified API access pattern signature; and Based on successful verification of the application access mode, the application container is generated to include the verified API access mode signature.

Images