WO2021071539A1 - Accès à des données sécurisé et responsable - Google Patents

Accès à des données sécurisé et responsable Download PDF

Info

Publication number
WO2021071539A1
WO2021071539A1 PCT/US2020/013710 US2020013710W WO2021071539A1 WO 2021071539 A1 WO2021071539 A1 WO 2021071539A1 US 2020013710 W US2020013710 W US 2020013710W WO 2021071539 A1 WO2021071539 A1 WO 2021071539A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
data
access
api
access pattern
Prior art date
Application number
PCT/US2020/013710
Other languages
English (en)
Inventor
Hongliang Tang
Ning Wu
Hui Lei
Yong Wang
Zhihao Tang
Theodoros GKOUNTOUVAS
Original Assignee
Futurewei Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Futurewei Technologies, Inc. filed Critical Futurewei Technologies, Inc.
Priority to PCT/US2020/013710 priority Critical patent/WO2021071539A1/fr
Priority to CN202080092950.5A priority patent/CN114981812A/zh
Publication of WO2021071539A1 publication Critical patent/WO2021071539A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself

Definitions

  • the present disclosure is related to techniques for providing access to data, including methods, apparatuses, and computer-readable media for providing secure and accountable data access.
  • Big data and machine learning have required a large amount of data in order to have meaningful results to guide business behavior.
  • the increased data access requirements present unique opportunities and challenges for data owners and the data rental market.
  • One approach to address these drawbacks is to ask the data renter/buyer to submit the data query (or data access application) that will be used in connection with the data to the data owner, and the data owner can respond and return only portions of the data which are related to the query (or the data access application) and which have been pre-approved for use by the data renter/buyer.
  • the drawback of this arrangement is that the data renter/buyer may feel a lack of flexibility when multiple remote queries have to be performed. Additional drawbacks are associated with information leaks and data security at the data renter/buyer side when constant data queries are performed and multiple data responses are processed in response to the queries.
  • running the data renter/buyer data access applications or queries in the data owner network environment may reveal the data renter/buyer’ s own trade secrets or other proprietary information.
  • a computer-implemented method for configuring access to secure data includes identifying a first application programming interface (API) associated with a data access application.
  • a first application access pattern for the data access application is determined based on the identified first API.
  • the first application access pattern is validated based on a comparison of the first application access pattern with pre-approved application access patterns for accessing the secure data.
  • An application container including the validated first application access pattern and the secure data is generated.
  • the application container is configured to grant access to the secure data via a second API, while a second application access pattern associated with the second API matches the validated first application access pattern.
  • a data processing progress of the data access application is retrieved.
  • the determining of the first application access pattern for the data access application is further based on the data processing progress.
  • the data processing progress of the data access application and the API are retrieved based on a request for accessing the secure data, the request received from a data renter.
  • a validated application signature of the data access application is retrieved from an application validation service.
  • the validated application signature is generated during pre-approval of the data access application for accessing the secure data.
  • an application signature is generated using the data processing progress of the data access application.
  • the data access application is validated based on a comparison of the validated application signature and the generated application signature.
  • the application container is generated to include the validated application signature, based on successful validation of the data access application.
  • a validated API access pattern signature for the API is retrieved from an application validation service.
  • the validated API access pattern signature is generated during pre-approval of the API for accessing the secure data.
  • a signature is generated for the application access pattern.
  • the application access pattern is validated based on a comparison of the generated signature with the validated API access pattern signature.
  • the application container is generated to include the validated API access pattern signature, based on successful validation of the application access pattern.
  • the determining of the first application access pattern for the data access application is further based on static analysis or dynamic analysis of the identified first API.
  • the static analysis of the identified API includes tracking information flow using the identified API and based on pre-determined sensitivity of the secure data.
  • the dynamic analysis of the identified first API includes receiving input specifying a data access technique, retrieving a machine learning model trained on the data access technique, and determining the first application access pattern by applying the machine learning model to the identified API.
  • a system for configuring access to secure data including a memory that stores 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.
  • API application programming interface
  • a first application access pattern is determined for the data access application based on the identified first API.
  • the first application access pattern is validated based on a comparison of the first application access pattern with pre-approved application access patterns for accessing the secure data.
  • An application container including the validated first application access pattern and the secure data is generated.
  • the application container is configured to grant access to the secure data via a second API, while a second application access pattern associated with the second API matches the validated first application access pattern.
  • the one or more processors execute the instructions to retrieve a data processing progress of the data access application.
  • the determining of the first application access pattern for the data access application is further based on the data processing progress.
  • the one or more processors execute the instructions to retrieve the data processing progress of the data access application and the API based on a request for accessing the secure data, the request received from a data renter.
  • the one or more processors execute the instructions to retrieve a validated application signature of the data access application from an application validation service, the validated application signature generated during pre approval of the data access application for accessing the secure data.
  • the one or more processors execute the instructions to generate an application signature using the data processing progress of the data access application.
  • the data access application is validated based on a comparison of the validated application signature and the generated application signature.
  • the application container is generated to include the validated application signature, based on successful validation of the data access application.
  • the one or more processors execute the instructions to retrieve a validated API access pattern signature for the API from an application validation service, the validated API access pattern signature generated during pre-approval of the API for accessing the secure data.
  • the one or more processors execute the instructions to generate a signature for the application access pattern.
  • the first application access pattern is validated based on a comparison of the generated signature with the validated API access pattern signature.
  • the application container is generated to include the validated API access pattern signature, based on successful validation of the application access pattern.
  • a non-transitory computer-readable medium storing instruction for configuring access to secure data, that 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 pattern for the data access application based on the identified first API, and validating the first application access pattern based on a comparison of the first application access pattern with pre-approved application access patterns for accessing the secure data.
  • the operations further include generating an application container including the validated first application access pattern and the secure data, the application container configured to grant access to the secure data via a second API, while a second application access pattern associated with the second API matches the validated first application access pattern.
  • the instructions upon execution, the instructions further cause the one or more processors to perform operations including retrieving a validated API access pattern signature for the API from an application validation service, the validated API access pattern signature generated during pre-approval of the API for accessing the secure data.
  • the instructions upon execution, the instructions further cause the one or more processors to perform operations including generating a signature for the application access pattern, validating the first application access pattern based on a comparison of the generated signature with the validated API access pattern signature, and generating the application container to include the validated API access pattern signature, based on successful validation of the application access pattern.
  • FIG. 1 is a block diagram of a secure data access apparatus
  • FIG. 2 is a block diagram of a network-based service infrastructure, which can be used by a data owner to configure an SDAA for secure and accountable data access, according to some example embodiments.
  • FIG. 3 is a swimlane diagram illustrating an example communication exchange between a data owner and a data renter for configuring secure and accountable data access, according to some example embodiments.
  • FIG. 4 is a block diagram of a data control gateway within an
  • SDAA Secure Digital
  • FIG. 5A is a flowchart of a method for authorizing an SDAA for secure and accountable data access, according to some example embodiments.
  • FIG. 5B is a flowchart of a method for static analysis to determine data access patterns for purposes of authorizing the SDAA in FIG.
  • FIG. 5C is a flowchart of a method for dynamic analysis to determine data access patterns for purposes of authorizing the SDAA in FIG.
  • FIG. 6 is a flowchart of a method for secure and accountable data access based on analysis of a near data processing (NDP) application signature and access pattern, according to some example embodiments.
  • NDP near data processing
  • FIG. 7 is a flowchart of a method for secure and accountable data access based on data usage statistics, according to some example embodiments.
  • FIG. 8 is a flowchart of a method for generating an application container of an SDAA for providing secure and accountable data access, according to some example embodiments.
  • FIG. 9 is a block diagram illustrating a representative software architecture, which may be used in conjunction with various device hardware described herein, according to some example embodiments.
  • FIG. 10 is a block diagram illustrating circuitry for a device that implements algorithms and performs methods, according to some example embodiments.
  • network-based service infrastructure includes a plurality of network devices (also referred to as hosts, nodes, or servers) providing data access capacity, on-demand computing capacity (e.g., via one or more virtual machines or other virtual resources running on the network devices), and/or storage capacity as a service to a community of end-recipients (e.g., customers of the service infrastructure), where the end recipients may be communicatively coupled to one or more of the network devices within the service infrastructure via a network according to some example embodiments order to request services provided by the service infrastructure (e.g., selling or renting data to customers of the service infrastructure).
  • network devices also referred to as hosts, nodes, or servers
  • the 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 via the network.
  • the customer devices, the network, and the network-based service infrastructure can be collectively referred to as a “network architecture.”
  • the customers of the service infrastructure can also be referred to as “users” or “tenants.”
  • a user who is requesting to rent data owned by the service infrastructure may be referred to as a “data renter.”
  • a user who is requesting to purchase data owned by the service infrastructure may be referred to as a “data buyer.”
  • application progress and “data processing progress” are interchangeable and refer to application code that is associated with performing a specific function (or functions).
  • application progress may refer to application code (e.g., binaries and/or libraries) of an application associated with processing data, such as near-data processing (NDP) application.
  • NDP near-data processing
  • the “application progress” of the NDP application (or app) is indicative of, for example, application programming interfaces (APIs) used for accessing the data, data access patterns, data usage statistics (e.g., information access rate, access duration, access frequency, volume of accessed data, type of accessed data), etc.
  • APIs application programming interfaces
  • data usage statistics e.g., information access rate, access duration, access frequency, volume of accessed data, type of accessed data
  • the term “application access pattern” is interchangeable with the term “data access pattern” and indicates information associated with data access by an application, including at least one of the following: (a) a model trained from multi-dimensional features such as “time of the day of accessing”, “total bytes returned per hour”, “whether the data is sequentially stored”; (b) pre-measured patterns for use cases, such as “Search top n best matching customers”; and (c) aggregation only or individual rows allowed (with a rate limit).
  • Techniques disclosed herein can be used to configure secure and accountable access to data (e.g., data requested by a data renter). More specifically, a data owner can provide the data renter a secure data access apparatus (SDAA) which includes the requested data as well as a data control gateway (DCG) that limits access to the data according to pre-approved data access validation information.
  • SDAA secure data access apparatus
  • DCG data control gateway
  • the requested data is stored on the SDAA as encrypted data, which can be decrypted (and released to the data renter) only by the DCG upon validation of a data access request based on the pre-approved data access validation information.
  • the DCG is configured to execute from a secure container or another type of secure environment within the SDAA.
  • the DCG includes the pre-approved data access validation information, such as pre-approved access patterns, API signatures, and data access application signatures. Access to the secure data in the SDAA is granted based on a match between data access configurations for a current data access request (e.g., application access patterns, application signature, API signature, etc.) with the pre-approved data access validation information. Usage of the SDAA, access patterns, as well as pre-approval information associated with the pre-approved data access validation information is recorded in a public ledger that is accessible by the data owner or other third parties for auditing and billing purposes.
  • pre-approved data access validation information such as pre-approved access patterns, API signatures, and data access application signatures.
  • a data renter may provide an API (e.g., a first API) or a data access application progress to the data owner for analysis.
  • API e.g., a first API
  • Application access patterns can be determined by the data owner using the API and/or the data access application progress.
  • the determined access patterns can be validated by the data owner, based on data access criteria, pre-approved access patterns, pre-approved data access application signatures, and so forth.
  • the validated access pattern is stored in the DCG as data access validation information.
  • the data renter may attempt to access the data in the SDAA using a new API (e.g., a second API from a data access application of the data renter, with ) for accessing data in the SDAA.
  • the DCG determines the access pattern of the new API and compares the determined access pattern against the validated access pattern within the data access validation information ⁇ Access to the data within the SDAA is authorized based on the comparison and whether the access pattern of the new API matches the validated access pattern.
  • techniques disclosed herein provide a secure way to configure access (e.g., for a data renter) to data, by bundling the data with a data control gateway within an SDAA that can be provided to the intended user.
  • the techniques discusses herein for providing secure and accountable data access using the SDAA have the following technical advantages and benefits over existing data access techniques: (a) the SDAA can be physically shipped or virtually deployed (e.g., instead of storing the data securely on the SDAA, the data can be stored encrypted in a remote network and accessed by the data renter wirelessly, upon authentication by the DCG); (b) the SDAA enables data anti dump features based on providing access to specific data using data access patterns; (c) the SDAA stores the DCG and the 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 validation may use artificial intelligence (AI) and machine learning (ML) techniques to identify access patterns and enforce access patterns to conform to
  • FIG. 1 is a block diagram of an SDAA 102 in communication with a data access application 108, according to some example embodiments.
  • the SDAA 102 is configured by a data owner for providing secure and accountable data access to a data access application 108 associated with a data renter.
  • the SDAA 102 includes encrypted data 104 and a DCG 106 and is configured to provide secure and accountable data access to the data access application 108 via network 112 using the techniques discussed herein (e.g., the techniques discussed in connection with FIG. 2 - FIG. 8). More specifically, FIG. 3 - FIG.
  • FIG. 5C provide details regarding initial approval of an SDAA to be generated for use by a data renter, as well as details regarding configuring an SDAA for use by the data renter in connection with a data access application.
  • FIG. 6 - FIG. 8 provide details of example methods for secure and accountable data access using the configured SDAA.
  • accountability of the data access provided by the SDAA 102 is achieved by using the public ledger 110. More specifically, the public ledger 110 is used by the data owner to store information associated with initial configuration of the SDAA 102 as well as subsequent usage of the SDAA 102 by the data access application 108, including approved or denied data access attempts based on approved or denied data access patterns, data usage statistics, and so forth.
  • the encrypted data 104 can be stored remotely, outside of the SDAA 102, as encrypted data 114 within the network 112.
  • the SDAA 102 can include the DCG 106, and the DCG 106 is configured to retrieve the encrypted data 114 from the network 112 after data access by the data access application 108 is authorized (e.g., based on analysis of a data access pattern of the application 108, as discussed in connection with FIG. 6 and FIG. 7).
  • FIG. 2 is a block diagram of a network-based service infrastructure 204, which can be used by a data owner to configure an SDAA 226 for secure and accountable data access by a data renter 202, according to some example embodiments.
  • the network architecture 200 includes a device 244 (e.g., a user device), a network-based service infrastructure 204, and an application validation service 206, all communicatively coupled with each other via the network 208.
  • the device 244 is associated with a data renter 202 and is configured to interact with the network-based service infrastructure 204 using a network access client, which can be implemented as a web client or an application (app) client.
  • the network access client of device 244 can include a data access application 210.
  • the data access application 210 can be an NDP application configured to communicate with multiple network entities within the network architecture 200, including the application validation service 206, the computing device 212, and the SDAA 226 in connection with being authorized for and obtaining access to encrypted data 230.
  • the data renter 202 may be referred to generically as “a user
  • the user 202 may include a human user (e.g., a human being), a machine user (e.g., a computer configured by a software program to interact with the devices 244 and the network-based service infrastructure 204), or any suitable combination thereof (e.g., a human assisted by a machine or a machine supervised by a human).
  • the user 202 is not part of the network architecture 200 but is associated with (and is a user of) device 244.
  • the device 244 may be a desktop computer, a vehicle computer, a tablet computer, a navigational device, a portable media device, or a smartphone belonging to the user 202.
  • User 202 can use device 244 to access services and data provided by the network-based service infrastructure 204.
  • user 202 can also be referred to as “customer 202” or “tenant 202” of the network-based service infrastructure 204.
  • the network-based service infrastructure 204 can include a plurality of computing devices such as computing device 212.
  • the computing device 212 includes application analysis and validation module (AAVM) 214, a gateway configuration module (GCM) 216, and encryption module (EM) 218. Additional configurations associated with the computing device 212 are discussed in greater detail in connection with FIG. 9 and FIG. 10.
  • the AAVM 214 comprises suitable circuitry, logic, interfaces, and/or code and is configured to perform functionalities 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 APA access pattern signatures, and other tasks as discussed in connection with FIG. 3 and FIG. 5A - FIG. 5C.
  • 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 APA access pattern signatures e.g., APA access pattern signatures
  • the GCM 216 comprises suitable circuitry, logic, interfaces, and/or code and is used for configuring the DCG 228 within the SDAA 226, as discussed in connection with FIG. 3 and FIG. 4.
  • the encryption module 218 comprises suitable circuitry, logic, interfaces, and/or code and is configured to generate the encrypted data 230 within the SDAA 226. More specifically, the AAVM 214 can provide the encryption module 218 with an indication of data that user 202 would like to rent and access via the data access application 210. The encryption module 218 can access such data from database 222 and encrypt the data using secure keys 220 to generate the encrypted data 230 for inclusion within the SDAA 226. The secure keys 220 are also 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 of the data that the user 202 would like to rent.
  • the SDAA 226 is illustrated as being within the network-based service infrastructure 204, the disclosure is not limited in this regard.
  • 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 be provided to user 202, and user 202 can access SDAA 226 via the user device 244, without requiring a connection to the network-based service infrastructure 204.
  • the SDAA 226 can be configured as a separate device within the network-based service infrastructure 204 and user 202 may be provided access to the SDAA 226 (e.g., via the communication path 236 of network 208 and interface 229 of the DCG 228).
  • 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). The remote location may be accessed by the DCG 228 in order to retrieve data and provide the retrieved data to the data access application 210 (e.g., based on validation of a data access pattern associated with an API that requests access to the encrypted data 230).
  • the network-based service infrastructure 204 also includes a public ledger 224, which is used during the configuration of the SDAA 226 as well as after the SDAA has been configured. More specifically, the public ledger 224 is used to store information associated with an initial configuration of the SDAA 226 as well as subsequent usage 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, and so forth. In an example embodiment, the public ledger 224 may be located outside of the NBSI 204 (e.g., with a third-party service provider that is accessible via the network 208).
  • the application validation service 206 can be a service provided by the network-based service infrastructure 204 or can be a third-party service for analyzing the data access application 210.
  • the data access application 210, or data processing progress associated with the data access application 210 is communicated to the application validation service 206 via a communication path 240 of network 208.
  • the application validation service 206 analyzes the received application (or data processing progress) to determine APIs used by the application as well as data access patterns of the APIs.
  • the application validation service 206 also generates application signatures 232 (of the received application 210 or the received data processing progress) and API access pattern signatures 234 (of the determined data access patterns of the APIs).
  • the network-based service infrastructure 204 can share secure keys 220, or other secure keys, which can be used by the application validation service 206 to generate the signatures 232 and 234.
  • the generated signatures 232 and 234 are communicated to the computing device 212 via communication path 242 of the network 208, to be used by the GCM 216 to configure data access validation information used by the DCG 228 (e.g., as illustrated in FIG. 4).
  • any of the devices shown in FIG. 2 may be implemented in a general-purpose computer modified (e.g., configured or programmed) by software to be a special-purpose computer to perform the functions described herein for that machine, database, or device.
  • a “database” is a data storage resource that stores data structured as a text file, a table, a spreadsheet, a relational database (e.g., an object-relational database, a NoSQL database, a network or graph database), a triple store, a hierarchical data store, or any suitable combination thereof.
  • data accessed (or stored) via an application programming interface (API) or remote procedure call (RPC) may be considered to be accessed from (or stored to) a database.
  • API application programming interface
  • RPC remote procedure call
  • any two or more of the devices or databases illustrated in FIG. 2 may be combined into a single machine, database, or device, and the functions described herein for any single machine, database, or device may be subdivided among multiple machines, databases, or devices.
  • encrypted data may be stored using a file system or other techniques in lieu of using the database 222.
  • the network 208 may be any network that enables communication between or among machines, databases, and devices (e.g., device 244, the application validation service 206, the SDAA 226 via the interface 229, and device 212 within the network-based service infrastructure 204). Accordingly, the network 208 may be a wired network, a wireless network (e.g., a mobile or a cellular network), or any suitable combination thereof. The network 208 may include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof.
  • FIG. 3 is a swimlane 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 accountable data access, according to some example embodiments.
  • a data owner e.g., network-based service infrastructure 20
  • a data renter e.g., user 202
  • user 202 communicates a request (e.g., via communication path 238 of network 208) to the data owner (e.g., the network- based service infrastructure 204) via device 244.
  • the request from user 202 can include a request to rent data or purchase data, such as data stored within the database 222.
  • the network-based service infrastructure 204 communicates a request for data usage information to device 244 (namely, what application or API will be used for accessing the requested data).
  • device 244 can submit data access application 210, one or more APIs associated with application 210, or data processing progress for the application 210.
  • the AAVM 214 can perform application analysis and validation tasks to determine data access patterns associated with the provided application 210 as well as to determine whether or not the configuration of an SDAA for accessing the requested data can be approved for user 202 in connection with 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 illustrated in connection with FIG. 5A - FIG.
  • the GCM 216 can configure the DCG 228 (e.g., DCG 228 can be configured in a secure application container with an interface 229 and data access validation information (e.g., 410 in FIG. 4). Additionally, the GCM 216 can use the encryption module 218 and secure keys 220 to generate encrypted data 230 using data from the database 222 and store the encrypted data 230 as part of the SDAA 226.
  • DCG 228 can be configured in a secure application container with an interface 229 and data access validation information (e.g., 410 in FIG. 4).
  • the GCM 216 can use the encryption module 218 and secure keys 220 to generate encrypted data 230 using data from the database 222 and store the encrypted data 230 as part of the SDAA 226.
  • the SDAA 226 can be shipped to the user 202, or otherwise (when the SDAA 226 remains within the network-based service infrastructure 204) access to the SDAA 226 can be provided to user 202 (e.g., secure access credentials or other type of access information which can be used by the data access application 210 to communicate with the SDAA 226 via communication path 236 and interface 229 to access the encrypted data 230).
  • access to the SDAA 226 can be provided to user 202 (e.g., secure access credentials or other type of access information which can be used by the data access application 210 to communicate with the SDAA 226 via communication path 236 and interface 229 to access the encrypted data 230).
  • FIG. 4 is a block diagram of a data control gateway 228 within the SDAA 226, according to some example embodiments.
  • the GCM 216 within the computing device 212 receives the application signatures 402 (referenced as 232 in FIG. 2) and API access pattern signatures 404 (referenced as 234 in FIG. 2) from the application validation service 206. Additionally, the GCM 216 obtains the registered access patterns 406 and the registered data usage statistics 408 associated with the data access application 210 and obtained during the analysis and validation process (e.g., as discussed in connection with FIG. 3).
  • the GCM 216 further configures the DCG 228 is a secure application container with a communication interface 229 and data access validation information 410.
  • the data access validation information 410 includes the application signatures 402, the API access pattern signatures 404, the registered access patterns 406, and the registered data usage statistics 408.
  • the data access validation information 410 is used by the DCG 228 to determine whether or not to grant access to the encrypted data 230 when a new data access API is used by the data access application 210. Using the data access validation information 410 to determine whether or not to provide access to the encrypted data 230 in the SDAA 226 is discussed in greater detail in connection with FIG. 6 and FIG.
  • the GCM 216 can use the encryption module 218 to retrieve the requested data from database 222, encrypted the retrieved data using secure keys 220, and store the encrypted data as scripted data 230 in the SDAA 226.
  • the GCM 216 can indicate a command to the encryption module 218, and encryption module 218 can generate and store the encrypted data 230 in the SDAA 226.
  • FIG. 5A is a flowchart of a method 500 for authorizing an SDAA for secure and accountable data access, according to some example embodiments.
  • the method 500 includes operations 502 - 522.
  • the method 500 is described as being performed by the computing device 212 using modules 214, 216, and 218 (corresponding to modules 960, 962, and 964 of FIG. 9, or modules 1060, 1065, and 1070 of FIG. 10).
  • application progress or an API associated with the data access application 210 is identified (e.g., via communication path 238 of network 208) by the computing device 212. Alternatively, the application progress or APIs are communicated by the data access application 210 to the computing device 212.
  • the AAVM 214 perform static analysis and/or dynamic analysis to output, at operation 506, a determined data access pattern.
  • the AAVM 214 determines whether the data access pattern is acceptable. For example, the AAVM 214 can compare the data access pattern determined using static and/or dynamic analysis of the application progress or API associated with the data access application 210 with one or more preapproved data access patterns.
  • computing device 212 receives data usage summary as input from user 202.
  • AAVM 214 can receive configuration information from the data access application 210 indicative of intended data usage for the requested data.
  • the AAVM 214 can process the configuration information to generate, at operation 514, data usage statistics.
  • the data usage statistics can include, for example, data access frequency, access duration, access data volume, or other statistics associated with proposed data usage of the requested data by the data access application 210.
  • the AAVM 214 determines whether the data usage statistics are acceptable. For example, the AAVM 214 can compare the data usage statistics determined at operation 514 with preapproved data usage statistics (e.g., data usage statistics set as acceptable by a network operator of the network-based service infrastructure 204). If the determined data usage statistics do not match the preapproved data usage statistics, the SDAA generation is denied at operation 518 and a notification is communicated to user 202. In the determined usage statistics match the preapproved data usage statistics, at operation 520, the determined data access patterns in the data usage statistics are registered (e.g., as registered access patterns 406 and registered data usage statistics 408) for subsequent use by the GCM 2164 configuring the DCG 228.
  • preapproved data usage statistics e.g., data usage statistics set as acceptable by a network operator of the network-based service infrastructure 204.
  • generating an SDAA is approved and a notification is communicated to user 202.
  • FIG. 5B is a flowchart of a method 530 for static analysis to determine data for purposes of authorizing the SDAA in FIG. 5A, according to some example embodiments.
  • AAVM 214 receives the application progress or API from the data access application 210.
  • AAVM 214 tracks the information flow in the application progress or the API to detect one or more data access patterns.
  • AAVM 214 can also use predetermined data sensitivity in connection with the requested data access by data access application 210.
  • the network-based service infrastructure 204 can provide different levels of data sensitivity based on the data type.
  • FIG. 5C is a flowchart of a method 540 for dynamic analysis to determine data access patterns for purposes of authorizing the SDAA in FIG.
  • user 202 can provide input 1A (at operation 542) or input IB (at operation 550).
  • the user can indicate a known technique for accessing data via the data access application 210 as input 1A.
  • the AAVM 214 can receive predetermined data sensitivity associated with the requested data (e.g., used at operation 538 in FIG. 5B).
  • the AAVM 214 can determine whether a machine learning model is available in the network-based service infrastructure 204, based on input 1A and the predetermined data sensitivity. If a machine learning model is available, at operation 548, the AAVM 214 outputs the data access pattern from the machine learning model.
  • a binary program for the known technique is retrieved (e.g., manually or automatically), and processing continues to operation 554, when the retrieved program is executed in a “programming sandbox” and the results are added to the machine learning model.
  • the AAVM 214 can determine whether an accurate machine learning model is available. If the machine learning model is not accurate, 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.
  • input IB is provided at operation 550, which includes the application progress or APIs associated with the data access application 210.
  • the application progress or the APIs are executed in a “programming sandbox” and the results are added to the machine learning model.
  • the AAVM 214 can determine whether an accurate machine learning model is available. If the machine learning model is not accurate, 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.
  • FIG. 6 is a flowchart of a method 600 for secure and accountable data access based on analysis of a near data processing (NDP) application signature and access pattern, according to some example embodiments.
  • the method 600 includes operations 602 - 610.
  • the method 600 is described as being performed by the SDAA 226 or the computing device 212 using modules 214, 216, and 218 (corresponding to modules 960, 962, and 964 of FIG. 9, or modules 1060, 1065, and 1070 of FIG. 10).
  • application progress or API of data access application 210 is identified by (or otherwise received at) the computing device 212.
  • a new data access request is communicated to the SDAA via communication path 236 and interface 229.
  • the data access request can include the application progress or the API associated with the new data access request.
  • API is generated, and a determination is made on whether the determined application or API signature matches the data access validation information 410 (e.g., signatures 402 and 404 provided by the application validation service 206). If the signatures do not match the data access validation information 410, at operation 606, the data access attempt by the data access application 210 is logged in the public ledger 224 and the SDAA 226 is disabled for future access.
  • data access validation information 410 e.g., signatures 402 and 404 provided by the application validation service 206.
  • data access patterns associated with the application progress or the API are generated, and a determination is made on whether the data access patterns match the data access validation information 410 (e.g., a determination whether the data access patterns match the registered access patterns 406). If the access patterns do not match the data access validation information 410, at operation 606, the data access attempt by the data access application 210 is logged in the public ledger 224 and the SDAA 226 is disabled for future access. If the access patterns match the data access validation information 410, at operation 610, the requested data is fetched (from the encrypted data 230), decrypted, and prepared for communication back to the data access application 210 in response to the data access request.
  • FIG. 7 is a flowchart of a method 700 for secure and accountable data access based on data usage statistics, according to some example embodiments.
  • method 700 includes operations 702 - 712 as a continuation of method 600. More specifically, operation 702 is the same as operation 610.
  • data usage statistics the requested data access are determined (e.g., based on the provided application progress or APIs associated with the data access application 210). As previously discussed, data usage statistics can include data access frequency, access duration, access data volume, and so forth.
  • a determination is made on whether the determined data usage statistics match registered data usage statistics (e.g. 408) in the data access validation information 410. If the data usage statistics do not match the data access validation information 410, at operation 708, the data access attempt by the data access application 210 is logged in the public ledger 224 and the SDAA 226 is disabled for future access.
  • the data access attempt by the data access application 210 is logged in the public ledger 224.
  • the decrypted data that was previously fetched is communicated back to the data access application 210 in response to the data access request.
  • FIG. 8 is a flowchart of a method 800 for generating an application container of an SDAA for providing secure and accountable data access, according to some example embodiments.
  • the method 800 includes operations 702, 704, 706, 708, and 710.
  • the method 800 is described as being performed by the computing device 212 using modules 214, 216, and 218 (corresponding to modules 960, 962, and 964 of FIG. 9, or modules 1060, 1065, and 1070 of FIG. 10).
  • a first application programming interface (API) associated with a data access application is identified.
  • the AAVM 214 can identify a first API associated with a data access request, when the data access request is received from the data access application 210.
  • a first application access pattern is determined for the data access application based on the identified first API. For example, static and/or dynamic processing may be performed (as discussed in connection with FIG. 5B and FIG. 5C) to determine the application access pattern.
  • the first application access pattern is validated based on a comparison of the application access pattern with preapproved application access patterns for accessing the data. For example, analysis and validation tasks can be performed by the AAVM 214 and are discussed in connection with FIG. 3 and FIG. 4.
  • an application container is generated including the validated first data access pattern and the data, where the container is configured to grant access to the data when a second API is identified and a second application access pattern associated with the second API matches the validated first application access pattern.
  • the SDAA 226 can be configured to include the DCG 228 and the encrypted data 230, and subsequent data access requests (e.g., via a new API from the data access application 210) can be processed by the DCG 228 using the data access validation information 410 to determine whether an application access pattern associated with the new API matches the validated access pattern (e.g., 406 in the data access validation information 410).
  • FIG. 9 is a block diagram illustrating a representative software architecture 900, which may be used in conjunction with various device hardware described herein, according to some example embodiments.
  • FIG. 9 is merely a non-limiting example of a software architecture 902 and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein.
  • the software architecture 902 may be executing on hardware such as computing device 1000 of FIG. 10 that includes, among other things, processor 1005, memory 1010, storage 1015 and 1020, and I/O components (or interfaces) 1025 and 1030.
  • a representative hardware layer 904 is illustrated and can represent, for example, the computing device 1000 of FIG. 10.
  • the representative hardware layer 904 comprises one or more processing units 906 having associated executable instructions 908.
  • Executable instructions 908 represent the executable instructions of the software architecture 902, including implementation of the methods, modules and so forth of FIGS. 1-8.
  • Hardware layer 904 also includes memory and/or storage modules 910, which also have executable instructions 908.
  • Hardware layer 904 may also comprise other hardware 912, which represents any other hardware of the hardware layer 904, such as the other hardware illustrated as part of computing device 1000.
  • the software architecture 902 may be conceptualized as a stack of layers where each layer provides particular functionality.
  • the software architecture 902 may include layers such as an operating system 914, libraries 916, frameworks/middleware 918, applications 920, and presentation layer 944.
  • the applications 920 and/or other components within the layers may invoke application programming interface (API) calls 924 through the software stack and receive a response, returned values, and so forth illustrated as messages 926 in response to the API calls 924.
  • API application programming interface
  • Some mobile or special purpose operating systems may not provide frameworks/middleware 918, while others may provide such a layer.
  • Other software architectures may include additional or different layers.
  • the operating system 914 may manage hardware resources and provide common 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 the other software layers. For example, kernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on.
  • the services 930 may provide other common services for the other software layers.
  • the drivers 932 may be responsible for controlling or interfacing with the underlying hardware.
  • the drivers 932 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth, depending on the hardware configuration.
  • serial communication drivers e.g., Universal Serial Bus (USB) drivers
  • USB Universal Serial Bus
  • Wi-Fi® drivers audio drivers
  • power management drivers and so forth, depending on the hardware configuration.
  • the libraries 916 may provide a common infrastructure that may be utilized by the applications 920 and/or other components and/or layers.
  • the libraries 916 typically provide functionality that allows other software modules to perform tasks in an easier fashion than to interface directly with the underlying operating system 914 functionality (e.g., kernel 928, services 930, and/or drivers 932).
  • the libraries 916 may include system libraries 934 (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like.
  • libraries 916 may include API libraries 936 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGL framework that may be used to render 2D and 3D in a graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like.
  • the libraries 916 may also include a wide variety of other libraries 938 to provide many other APIs to the applications 920 and other software components/modules.
  • the frameworks/middleware 918 may provide a higher-level common infrastructure that may be utilized by the applications 920 and/or other software components/modules.
  • the frameworks/middleware 918 may provide various graphical user interface (GUI) functions, high-level resource management, high-level location services, and so forth.
  • GUI graphical user interface
  • the frameworks/middleware 918 may provide a broad spectrum of other APIs that may be utilized by the applications 920 and/or other software components/modules, some of which may be specific to a particular operating system 914 or platform.
  • the applications 920 include built-in applications 940, third-party applications 942, application analysis and validation module (AAVM) 960, a gateway configuration module (GCM) 962, and an encryption module (EM) 964.
  • AAVM application analysis and validation module
  • GCM gateway configuration module
  • EM encryption module
  • the AAVM 960, the GCM 962, and the EM 964 can be the same as (and perform the same functionalities as) the AAVM 214, the GCM 216, and the EM 218, respectively.
  • 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 broad assortment of other applications.
  • the third-party application 942 e.g., an application developed using the AndroidTM or iOSTM software development kit (SDK) by an entity other than the vendor of the particular platform
  • the third-party application 942 may be mobile software running on a mobile operating system such as iOSTM, AndroidTM, Windows® Phone, or other mobile operating systems.
  • the third-party application 942 may invoke the API calls 924 provided by the mobile operating system such as operating system 914 to facilitate functionality described herein.
  • the applications 920 may utilize built-in operating system functions (e.g., kernel 928, services 930, and/or drivers 932), libraries (e.g., system libraries 934, API libraries 936, and other libraries 938), and frameworks/middleware 918 to create user interfaces to interact with users of the system.
  • built-in operating system functions e.g., kernel 928, services 930, and/or drivers 932
  • libraries e.g., system libraries 934, API libraries 936, and other libraries 938
  • frameworks/middleware 918 e.g., frameworks/middleware 918 to create user interfaces to interact with users of the system.
  • interactions with a user may occur through a presentation layer, such as presentation layer 944.
  • the application/module “logic” can be separated from the aspects of the application/module that interact with a user.
  • Some software architectures utilize virtual machines.
  • virtual machine 948 A virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware machine (such as the computing device 900 of FIG. 9, for example).
  • a virtual machine 948 is hosted by a host operating system (operating system 914 in FIG. 9) and typically, although not always, has a virtual machine monitor 946, which manages the operation of the virtual machine 948 as well as the interface with the host operating system (i.e., operating system 914).
  • a software architecture may execute within the virtual machine 948 such as an operating system 950, libraries 952, frameworks/middleware 954, applications 956, and/or presentation layer 958. These layers of software architecture executing within the virtual machine 948 can be the same as corresponding layers previously described or may be different.
  • FIG. 10 is a block diagram illustrating circuitry for a device that implements algorithms and performs methods, according to some example embodiments. All components need not be used in various embodiments. For example, clients, servers, and cloud-based network devices may each use a different set of components, or in the case of servers, for example, larger storage devices.
  • computing device 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 by a bus 1040.
  • processor 1005 may include a processor 1005
  • memory 1010 may include a processor 1005
  • removable storage 1015 may include a processor 1005
  • non-removable storage 1020 may include a processor 1005
  • communication interface 1035 may be in different forms in different embodiments.
  • the memory 1010 may include volatile memory 1045 and non volatile memory 1050 and may store a program 1055.
  • the computer 1000 may include - or have access to a computing environment that includes - a variety of computer-readable media, such as the volatile memory 1045, the non-volatile memory 1050, the removable storage 1015, and the non-removable storage 1020.
  • 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 technologies, compact disc read-only memory (CD ROM), digital versatile disks (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.
  • RAM random-access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technologies
  • compact disc read-only memory (CD ROM), digital versatile disks (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.
  • Computer-readable instructions stored on a computer-readable medium are executable by the processor 1005 of the computer 1000.
  • a hard drive, CD-ROM, and RAM are some examples of articles including a non-transitory computer-readable medium such as a storage device.
  • the terms “computer-readable medium” and “storage device” do not include carrier waves to the extent that carrier waves are deemed too transitory.
  • “Computer-readable non-transitory media” includes all types of computer-readable media, including magnetic storage media, optical storage media, flash media, and solid-state storage media. It should be understood that software can be installed in and sold with a computer.
  • the software can be obtained and loaded into the computer, including obtaining the software through a physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator.
  • the software can be stored on a server for distribution over the Internet, for example.
  • the terms “computer-readable medium” and “machine-readable medium” are interchangeable.
  • the program 1055 may utilize modules discussed herein, such as an AAVM 1060, a GCM 965, and an EM 1070.
  • the AAVM 1060, the GCM 1065, and the EM 1070 can be the same as (and perform the same functionalities as) the AAVM 214, the GCM 216, and the EM 218, respectively.
  • Any one or more of the modules described herein may be implemented using hardware (e.g., a processor of a machine, an application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or any suitable combination thereof). Moreover, any two or more of these modules may be combined into a single module, and the functions described herein for a single module may be subdivided among 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.
  • hardware e.g., a processor of a machine, an application- specific integrated circuit (ASIC), field-programmable gate array (FPGA), or any suitable combination thereof.
  • ASIC application- specific integrated circuit
  • FPGA field-programmable gate array
  • one or more of the modules 1060-1070 can be integrated as a single module, performing the corresponding functions of each of the integrated modules.
  • a module can comprise one or both of hardware or software that has been designed to perform a function or functions (e.g., one or more of the functions discussed herein in connection with providing secure and accountable data access).
  • software including one or more computer-executable instructions that facilitate processing and operations as described above with reference to any one or all of the steps of the disclosure can be installed in and sold with one or more computing devices consistent with the disclosure.
  • the software can be obtained and loaded into one or more computing devices, including obtaining the software through physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator.
  • the software can be stored on a server for distribution over the Internet, for example.
  • the components of the illustrative devices, systems, and methods employed in accordance with the illustrated embodiments can be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. These components can be implemented, for example, as a computer program product such as a computer program, program code or computer instructions tangibly embodied in an information carrier, or in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers.
  • a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or another unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • functional programs, codes, and code segments for accomplishing the techniques described herein can be easily construed as within the scope of the claims by programmers skilled in the art to which the techniques described herein pertain.
  • Method steps associated with the illustrative embodiments can be performed by one or more programmable processors executing a computer program, code or instructions to perform functions (e.g., by operating on input data and/or generating an output). Method steps can also be performed by, and apparatus for performing the methods can be implemented as, special purpose logic circuitry, e.g., an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit), for example.
  • FPGA field-programmable gate array
  • ASIC application-specific integrated circuit
  • DSP digital signal processor
  • 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, e.g., 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.
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read-only memory or a 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.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
  • Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example, semiconductor memory devices, e.g., 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).
  • EPROM electrically programmable read-only memory
  • EEPROM electrically erasable programmable ROM
  • flash memory devices e.g., electrically erasable programmable ROM (EEPROM), flash memory devices
  • data storage disks e.g., magnetic disks, internal hard disks
  • machine-readable medium means a device able to store instructions and data temporarily or permanently and may include, but is not limited to, random- access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)), and/or any suitable combination thereof.
  • RAM random- access memory
  • ROM read-only memory
  • buffer memory flash memory
  • optical media magnetic media
  • cache memory other types of storage
  • EEPROM Erasable Programmable Read-Only Memory
  • machine-readable medium should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store processor instructions.
  • machine-readable medium shall also be taken to include any medium (or a combination of multiple media) that is capable of storing 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 methodologies described herein. Accordingly, a “machine -readable medium” refers to a single storage apparatus or device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. The term “machine- readable medium” as used herein excludes signals per se.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

Un procédé mis en œuvre par ordinateur pour configurer l'accès à des données sécurisées consiste à identifier une interface de programmation d'application (API) associée à une application d'accès à des données. Un premier motif d'accès d'application pour l'application d'accès à des données est déterminé sur la base de l'API identifiée. Le premier motif d'accès d'application est validé sur la base d'une comparaison du premier motif d'accès d'application avec des motifs d'accès d'application pré-approuvés pour accéder aux données sécurisées. Un conteneur d'application est généré comprenant le premier motif d'accès d'application validé et les données sécurisées, le conteneur d'application étant configuré pour accorder l'accès aux données sécurisées par l'intermédiaire d'une seconde API lorsqu'un second motif d'accès d'application associé à la seconde API correspond au premier motif d'accès d'application validé.
PCT/US2020/013710 2020-01-15 2020-01-15 Accès à des données sécurisé et responsable WO2021071539A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2020/013710 WO2021071539A1 (fr) 2020-01-15 2020-01-15 Accès à des données sécurisé et responsable
CN202080092950.5A CN114981812A (zh) 2020-01-15 2020-01-15 安全和可靠的数据访问

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2020/013710 WO2021071539A1 (fr) 2020-01-15 2020-01-15 Accès à des données sécurisé et responsable

Publications (1)

Publication Number Publication Date
WO2021071539A1 true WO2021071539A1 (fr) 2021-04-15

Family

ID=69529060

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/013710 WO2021071539A1 (fr) 2020-01-15 2020-01-15 Accès à des données sécurisé et responsable

Country Status (2)

Country Link
CN (1) CN114981812A (fr)
WO (1) WO2021071539A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002014989A2 (fr) * 2000-08-18 2002-02-21 Camelot Information Technologies Ltd. Generation de niveaux de permission en fonction de l'apprentissage adaptatif
US20060059117A1 (en) * 2004-09-14 2006-03-16 Michael Tolson Policy managed objects
US20110289116A1 (en) * 2010-05-18 2011-11-24 Horadan Peter H Method and Apparatus for Protecting Online Content by Detecting Noncompliant Access Patterns

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002014989A2 (fr) * 2000-08-18 2002-02-21 Camelot Information Technologies Ltd. Generation de niveaux de permission en fonction de l'apprentissage adaptatif
US20060059117A1 (en) * 2004-09-14 2006-03-16 Michael Tolson Policy managed objects
US20110289116A1 (en) * 2010-05-18 2011-11-24 Horadan Peter H Method and Apparatus for Protecting Online Content by Detecting Noncompliant Access Patterns

Also Published As

Publication number Publication date
CN114981812A (zh) 2022-08-30

Similar Documents

Publication Publication Date Title
US20190156387A1 (en) Datacenter-based hardware accelerator integration
JP6761470B2 (ja) ユーザのプライバシを守るデジタル著作権管理対応コンピュータ・ベースの方法、システム、コンピュータ・プログラム
US11645369B2 (en) Blockchain digital rights management streaming library
US9940119B2 (en) Providing limited versions of applications
JP5778865B2 (ja) アプリケーションに機能性を追加するためのサービス
US9710621B1 (en) Platform for cloud application software
US9135610B2 (en) Software application license roaming
US11151226B2 (en) Managing application specific feature rights
US11354421B2 (en) Secure execution guest owner controls for secure interface control
US20240012883A1 (en) Monitoring license constraints in a container orchestration system
US9886685B2 (en) Distributed digital rights-managed file transfer and access control
KR20230165100A (ko) 메타버스 공간에 적용되는 nft 기반의 음원의 등급을 결정 및 관리하는 서비스 제공 방법 및 장치
EP2780817A1 (fr) Distribution efficace d'extensions fonctionnelles à un logiciel de modélisation en 3d
US20190018953A1 (en) Methods and systems for tenant aware behavior injection in content metadata service
US8966651B2 (en) Digital rights management (DRM) locker
CN110352411A (zh) 用于控制对安全计算资源的访问的方法和装置
WO2021071539A1 (fr) Accès à des données sécurisé et responsable
US20230195858A1 (en) Programmable model-driven license management and enforcement in a multi-tenant system
Reagan et al. Web applications on Azure
US20200073990A1 (en) Systems and methods for integrated dynamic runtime etl tool and scalable analytics server platform
JP6012865B2 (ja) デジタルアイテムインジェスチョンプロセス
US10796014B2 (en) Data license manager
US20230394163A1 (en) Data cluster management
Reagan Web applications on Azure: developing for global scale
Krajci et al. Android Development—Business Overview and Considerations

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20704740

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20704740

Country of ref document: EP

Kind code of ref document: A1