Techniques for securely executing verified code in a collaborative environment

Abstract

This document describes methods, systems, and devices for data processing. The process orchestration layer of the data processing system can obtain an identifier of code approved by two or more parties in a secure shared session. The process orchestration layer can generate a stored procedure including an initialization function, an output function, and a run function with the approved code. The process orchestration layer can output a request to a first subsystem associated with a first party in the secure shared session, causing the first subsystem to execute the stored procedure. The process orchestration layer can receive an identifier of an encrypted session token from the first subsystem according to the initialization function of the stored procedure. The process orchestration layer can validate the encrypted session token and provide the validated session token to other parties in the secure shared session.

Description

Technical Field

[0001] This patent application claims priority to U.S. Patent Application No. 18 / 602,359, filed Mar. 12, 2024, by Puliyeril et al., entitled "TECHNIQUES FOR SECURELY EXECUTING ATTESTED CODE IN A COLLABORATIVE ENVIRONMENT," and U.S. Provisional Patent Application No. 63 / 490,987, filed Mar. 17, 2023, by Puliyeril et al., entitled "TECHNIQUES FOR SECURELY EXECUTING ATTESTED CODE IN A COLLABORATIVE ENVIRONMENT," each of which was assigned to the assignee of this patent application and each of which is hereby incorporated by reference in its entirety.

[0002] The present disclosure generally relates to database systems and data processing, and more particularly, to techniques for securely executing attested code in a collaborative environment.

Background Art

[0003] In some cloud computing systems, companies may want to securely share data so that other companies can run authorized queries on customer datasets without viewing or otherwise accessing actual customer data. For example, one company might want to extract customer insights from another company's sales metrics (such as revenue growth, churn, and conversion rates) without accessing the other company's underlying data records. To this end, some cloud service providers allow users to run Structured Query Language (SQL) queries in a way that ensures data privacy (for example, by setting up a data clean room where users can exchange or otherwise share aggregated and anonymized data). However, such methods may restrict users from executing code that dynamically generates SQL queries. [Brief explanation of the drawing]

[0004] [Figure 1] This figure shows an example of a data processing system that supports techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 2] This figure shows an example of a data processing system that supports techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 3] This figure shows an example of a data processing system that supports techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 4] This figure shows an example of a flowchart supporting a technique for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 5] This figure shows an example of a process flow that supports techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 6] This is a block diagram of a device that supports techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 7] This is a block diagram of a process orchestration layer that supports techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 8] This is a diagram of a system including a device that supports techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Figure 9] This flowchart shows a method for supporting techniques for securely executing verified code in a collaborative environment, as described in this disclosure. [Modes for carrying out the invention]

[0005] In some cloud computing systems, companies may want to securely share data so that other companies can run authorized queries on customer datasets without viewing or otherwise accessing actual customer data. For example, one company might want to extract customer insights from another company's sales metrics (such as revenue growth, churn, and conversion rates) without accessing that other company's underlying data records. To this end, some cloud service providers allow users to run Structured Query Language (SQL) queries in a way that ensures data privacy (for example, by setting up a data clean room where users can exchange or otherwise share aggregated and anonymized data). However, when SQL queries can be dynamically generated, such techniques may restrict users from executing the code that generates the SQL queries.

[0006] The techniques described herein enable a cloud client (also referred to herein as a collaborator, party, or data owner) to execute multiple queries in parallel and / or perform other processing tasks while ensuring that raw client data is not exposed to other parties in the process. According to aspects of this disclosure, the process orchestration layer of a data processing system can receive an identifier of code mutually approved (i.e., verified) by two or more parties in a data clean room. The process orchestration layer can generate a stored procedure that includes an initialization function, an output function, and a run function containing the mutually approved code. Thus, the process orchestration layer can issue a request to a first subsystem of the data processing system associated with a first party (also referred to as an owner account) in a data clean room.

[0007] The request causes the first subsystem to execute the initialization function of a stored procedure and return an encrypted session token to the process orchestration layer. After receiving the encrypted session token from the first subsystem, the process orchestration layer can validate the encrypted session token using a private key. The process orchestration layer can then provide the validated token to other subsystems of the data processing system associated with other parties (synonymously referred to as partner accounts) in the data clean room. The other subsystems can store the validated token in a list of acceptable session identifiers (IDs) associated with the data clean room. After the token (also referred herein as the signed session ID) has been distributed to the partner account, the first subsystem can execute the remainder of the stored procedure (i.e., the run function and output function) to, for example, access one or more rows in a shared database instance and write the results to a table.

[0008] Aspects of this disclosure can be implemented to achieve one or more of the following benefits. The techniques described herein can support improvements in user experience, data privacy, and query complexity by enabling collaborators to perform complex queries on partner datasets and / or perform additional processing without exposing actual data from partner datasets. For example, the techniques described can enable collaborators in a data clean room to execute Python code approved by all other collaborators in the data clean room, thereby providing data owners with a way to control who can access and use their data. The techniques described herein can also leverage a combination of cryptographic techniques, secure functions, and low-access policies to prevent collaborators from tampering with or otherwise manipulating approved code.

[0009] The aspects of this disclosure are first described in the context of data processing systems, flowcharts, and process flows. The aspects of this disclosure are further illustrated and described by device diagrams, system diagrams, and flowcharts relating to techniques for securely executing verified code in a collaborative environment.

[0010] Figure 1 shows an example of a data processing system 100 that supports techniques for securely executing verified code in a collaborative environment, according to various aspects of this disclosure. The data processing system 100 includes a cloud client 105, a communication network 110, a cloud platform 115, a data center 120, an account 125, and customer data 130. The cloud platform 115 may be an example of a public or private cloud network. The cloud client 105 can access the cloud platform 115 via the communication network 110. The communication network 110 may implement a transfer control protocol and internet protocol (TCP / IP), such as the Internet, or other network protocols. The cloud client 105 may be an example of a user device such as a server, smartphone, or laptop. In other examples, the cloud client 105 may be a desktop computer, tablet, sensor, or another computing device or system capable of generating, analyzing, transmitting, or receiving communications. In some real-world examples, Cloud Client 105 can be operated by users who are part of a business, enterprise, non-profit organization, newly established company, or any other type of organization.

[0011] The cloud client 105 can access the cloud platform 115 (e.g., Snowflake, Amazon Web Services, Microsoft Azure, or Google Cloud Platform) to store, manage, and process customer data 130 within account 125. In some cases, the cloud client 105 may have associated security or permission levels. Based on the associated security or permission levels, the cloud client 105 may have access to certain applications, data, and database information within the cloud platform 115, and may not have access to others. The cloud client 105 may have one or more remote software components that act on input data and generate resulting data by processing, parsing, or otherwise transforming the input data. The remote software components may also support database tracking procedures such as streams to shared tables and shared views.

[0012] The cloud platform 115 can provide on-demand database services to the cloud client 105. In some cases, the cloud platform 115 can be an example of a multi-tenant database system. In such cases, the cloud platform 115 can serve multiple cloud clients 105 using a single instance of software. However, it can implement other types of systems, including, but not limited to, client-server systems, mobile device systems, and mobile network systems. In some cases, the cloud platform 115 can support customer relationship management (CRM) solutions. This may include support for sales, service, marketing, community, analytics, applications, and the Internet of Things (IoT). The cloud platform 115 can receive customer data 130 from the cloud client 105 via the communication network 110, store that data, and analyze it. In some cases, the cloud platform 115 can receive data directly from the cloud client 105. In some cases, the cloud client 105 can develop applications to run on the cloud platform 115. The cloud platform 115 can be implemented using remote servers. In some cases, the remote servers can be located in one or more data centers 120.

[0013] The data center 120 may include multiple servers. These servers can be used for data storage, management, and processing. The data center 120 can receive data from the cloud platform 115 via connection 140 or directly from the cloud client 105. The data center 120 may utilize multiple redundancies for security purposes. In some cases, data stored in the data center 120 can be backed up by copies of the data in a different data center (not shown). The data processing system 100 includes the cloud client 105, the cloud platform 115, and the data center 120. In some cases, data processing can be performed in any of the components of the data processing system 100, or in a combination of these components. In some cases, a server can perform data processing. The server may be the cloud client 105 or it may be located in the data center 120.

[0014] In some implementations, the data center 120 may include or utilize hard disk drives (HDDs), solid state drives (SSDs), storage clusters, Amazon S3 storage systems, or any other data storage technology. The cloud platform 115 may include distributed file systems (such as Hadoop Distributed File System (HDFS)), object storage systems, etc. The computing resources of the cloud platform 115 may be virtually and / or logically partitioned into virtual warehouses, each of which may contain one or more cache elements, processors, virtual machines, operating system-level container execution environments, etc. In some implementations, the communication links between elements of the data processing system 100 may be implemented by one or more data communication networks, such as the communication network 110. These data communication networks may utilize any communication protocol and any type of communication medium. In some examples, the data communication network is a combination of two or more data communication networks (or subnets) coupled together. In alternative examples, a communication link can be implemented using any type of communication medium and any communication protocol.

[0015] In some examples, the data processing system 100 may include or be an example of a multi-tenant database system. A multi-tenant database system can store data for different tenants (i.e., parties, collaborators, or accounts) in a single database or a set of databases. For example, a multi-tenant database system can store data for multiple tenants in a single table in the database (e.g., in different rows). To support multi-tenant security, a multi-tenant database system can prevent (e.g., restrict) a first tenant from accessing, viewing, or interacting in any way with data or rows associated with different tenants. Thus, tenant data for a first tenant can be separated (e.g., logically separated) from tenant data for a second tenant, and tenant data for a first tenant can be invisible (or otherwise transparent) to the second tenant. In addition, a multi-tenant database system can use encryption techniques to further protect tenant-specific data from unauthorized access (e.g., by another tenant).

[0016] The cloud platform 115 may include an access management system and / or a web proxy. The access management system may allow users to create and manage users, roles, and groups, and to use permissions to grant or deny access to cloud services and resources. The web proxy may handle tasks including traffic management, authorization and access control, monitoring, and API versioning, which are involved in accepting and processing concurrent calls to application programming interfaces (APIs). The web proxy may provide a Hypertext Transfer Protocol (HTTP) proxy service for creating, publishing, maintaining, securing, and monitoring APIs such as representational state transfer (REST) ​​APIs.

[0017] In the example in Figure 1, account 125 can be associated with different parties (i.e., collaborators) in a data sharing session. For example, a first party (e.g., collaborator A) may have account 125-a containing customer data 130-a (i.e., data relating to collaborator A's customers). Customer data 130-a can be stored in a tabular or other format for storing customer information and other relevant information. Other relevant information may include identifying information such as email, and other customer characteristics such as gender, geographical location, and purchasing habits. For example, if the first party is a consumer goods company, it can store purchasing characteristics such as whether the customer is single, married, or a member of a family in a suburban or urban area. If the first party is a streaming service company, it can store information about the customer's viewing habits, such as whether the customer likes action, mystery, reality, etc.

[0018] Similarly, a second party (e.g., collaborator B) may have account 125-b containing customer data 130-b (i.e., data relating to collaborator B's customers). Customer data 130-b may be stored in a tabular or other format for storing customer information and other relevant information. Other relevant information may include identifying information such as email, and other known characteristics of the customer, such as gender, geographical location, and purchasing habits. For security and privacy reasons, customer data 130-b may be inaccessible to the first party (and vice versa). However, these two parties may want to share at least some of their data with each other without disclosing sensitive information such as personally identifiable information of customers. For example, collaborators A and B may want to explore cross-marketing or cross-advertising opportunities, determine how much of their customers overlap, or filter overlapping customers based on specific characteristics to identify relevance and patterns.

[0019] According to the techniques described herein, the process orchestration layer of the cloud platform 115 can obtain an identifier of mutually approved code from two or more parties in a secure shared session (synonymously referred herein as a secure share or data sharing session) (i.e., from the cloud client 105 via the communication network 110). The process orchestration layer of the cloud platform 115 can generate and install a stored procedure that includes an initialization function, an output function, and a run function with the mutually approved code. The process orchestration layer can issue a request to a first subsystem (e.g., account 125-a) associated with a first party (e.g., collaborator A) in the secure shared session. The request causes the first subsystem to execute at least a portion of the initialization function of the stored procedure.

[0020] The initialization function can include a call to a secure function that generates an encrypted session token and returns it to the process orchestration layer of the cloud platform 115. The process orchestration layer can verify the validity of the encrypted session token by decrypting the encrypted session token using a private key. If the encrypted session token is valid, the process orchestration layer can provide the verified token to a second subsystem (e.g., account 125-b) associated with a second party (e.g., collaborator B) of the secure shared session. After the token becomes available to the second subsystem (and all other parties of the secure shared session), the first subsystem can run the rest of the stored procedure (i.e., a portion of the initialization function, the run function, and the output function). The run function can access one or more rows of customer data 130-b according to mutually approved code in some implementations. The output function can store the result of the run function in a table accessible from the first subsystem.

[0021] Those skilled in the art should understand that implementing one or more aspects of the present disclosure within the data processing system 100 can solve additional problems or problems alternative to those described above. Further, aspects of the present disclosure can provide a technical improvement over "conventional" systems or processes as described herein. However, this description and the accompanying drawings only include exemplary technical improvements resulting from implementing aspects of the present disclosure, and thus do not necessarily represent all of the technical improvements provided within the scope recited in the claims.

[0022] Figure 2 shows an example of a data processing system 200 that supports techniques for securely executing verified code in a collaborative environment, according to aspects of this disclosure. The data processing system 200 may also implement aspects of the data processing system 100, or may be implemented by such aspects. For example, the data processing system 200 includes a process orchestration layer 210, which can be implemented using one or more logical and / or physical components of the cloud platform 115 described with reference to Figure 1. The data processing system 200 also includes subsystems 205-a and 205-b, which can be associated with different parties (i.e., collaborators, accounts) in a data clean room. For example, subsystem 205-a may correspond to a first party (i.e., owner, collaborator A), and subsystem 205-b may correspond to a second party (i.e., partner, collaborator B). The process orchestration layer 210 can facilitate secure shared sessions 225 between parties within the data clean room.

[0023] As described herein with reference to Figure 1, the process orchestration layer 210 can obtain an identifier of code mutually approved by all parties in the secure sharing session 225 (synonymously referred herein as a secure share or data sharing session) (i.e., from the cloud client 105 as described with reference to Figure 1). The process orchestration layer 210 can generate and install a stored procedure (such as stored procedure 345 as described with reference to Figure 3) which includes an initialization function, an output function, and a run function with the mutually approved code. The process orchestration layer 210 can issue a request to a subsystem 205-a associated with a first party (e.g., collaborator A) in the secure sharing session 225. The request causes subsystem 205-a to execute at least a portion of the initialization function of the stored procedure.

[0024] The initialization function can include a call to a secure function that generates an encrypted session token 230 (SIGNED_SESSION_ID) and returns it to the process orchestration layer 210. Thus, the session validator 235 (SESSION_VALIDATOR) of the process orchestration layer 210 can validate the encrypted session token 230 by decrypting the encrypted session token 230 using the private key. If the encrypted session token 230 is valid, the process orchestration layer 210 can provide the validated token to a subsystem 205-b associated with the second party (e.g., Collaborator B) of the secure sharing session 225. Then, the subsystem 205-b can insert the valid token into an allowed session table 240 (ALLOWED_SESSIONS). If the encrypted session token 230 is invalid, the process orchestration layer 210 can refrain from taking further action.

[0025] After the token becomes available to the subsystem 205-b (and all other parties within the data clean room), the subsystem 205-a can run the remainder of the stored procedure (i.e., a portion of the initialization function, the run function, and the output function). The run function can access one or more rows of a dataset 220 (e.g., TXN_DATA) associated with the subsystem 205-b and / or a dataset 215 (e.g., CRM_DATA) associated with the subsystem 205-a in some implementations. The run function can access one or both of the datasets 215 and 220 according to mutually approved code. The output function of the stored procedure can save or otherwise write the result of the run function into a table (such as a cross-reference table) accessible from the subsystem 205-a.

[0026] Embodiments of the data processing system 200 can be implemented to achieve one or more of the following advantages. Techniques described with reference to Figure 2 can support improvements in user experience, data privacy, and query complexity by enabling collaborators (such as subsystem 205) to perform complex queries on partner datasets (such as dataset 215 and dataset 220) and / or perform additional processing without exposing actual data from those partner datasets. For example, the techniques described can enable collaborators in a data clean room to execute Python code approved by all other collaborators in the data clean room, thereby providing the data owner with a way to control who can access and use the data owner's data. The techniques described herein can also leverage a combination of cryptographic techniques, secure functions, and low-access policies to prevent collaborators from tampering with or otherwise manipulating approved code.

[0027] Figure 3 shows an example of a data processing system 300 that supports techniques for securely executing verified code in a collaborative environment, according to aspects of this disclosure. The data processing system 300 may also implement, or be implemented by, aspects of the data processing system 100 or data processing system 200. For example, the data processing system 300 includes a process orchestration layer 310, which can be implemented using one or more logical and / or physical components of the cloud platform 115 described with reference to Figure 1. The data processing system 300 also includes subsystems 305-a and 305-b, which can be associated with different parties (i.e., collaborators, accounts) in a data clean room. For example, subsystem 305-a may correspond to a first party (i.e., owner, collaborator A), and subsystem 305-b may correspond to a second party (i.e., partner, collaborator B). The process orchestration layer 310 can facilitate secure shared sessions between parties within the data cleanroom.

[0028] The data processing system 300 can be an example of a cloud-based data warehousing platform (such as Snowflake) that supports standard SQL and other data processing technologies. The data processing system 300 can provide a shared database feature that allows collaborators to share a single database instance across multiple accounts in the computing environment (such as account 125 as described in Figure 1), thereby enabling collaborators to share data while maintaining separate security and access controls. Using a shared database, the data owner can control who can access and use their data.

[0029] The data processing system 300 can support row access policies, which are security features that allow collaborators to control access to specific rows of data in a table based on specified conditions. Using row access policies 355, a user (such as the cloud client 105 described with reference to Figure 1) can define a set of conditions that must be met for a query to access a particular row of a table (such as a row in the dataset 320). If a user or role does not meet the conditions specified in row access policy 355, the user or role will not be able to access the corresponding row of data. For example, row access policy 355 may specify that requests to a particular view are only allowed if the query occurs within a particular session. The data processing system 300 can also support secure functions, which expose code with custom logic (e.g., code that stores an encryption key when executed) and provide a way to perform actions on data without collaborators knowing the actual transformations being performed.

[0030] As described herein with reference to Figures 1 and 2, collaborators (i.e., parties) may want to share data in a privacy-safe environment where only approved queries can be run on the dataset and none of the parties can see the data of other parties. The process orchestration layer 310 can run SQL queries in a privacy-safe manner by leveraging various cloud computing capabilities (such as the pattern processor 350). However, these techniques may limit collaborators to executing only one SQL query at a time. In some cases, collaborators may want to execute approved code that runs multiple queries on the data and / or performs other processing tasks without exposing the raw data of other parties.

[0031] According to aspects of this disclosure, the pattern processor 350 can use patterns to help securely run code approved by all parties. The patterns are for using an approved session ID that can only execute fingerprinted (i.e., signed, encrypted) code approved by all parties in a data clean room. To support this functionality, the process orchestration layer 310 can create a stored procedure 345 with initialization, run, and output functions / methods. The initialization function generates a fingerprint of the current run environment, shares that fingerprint with the process orchestration layer 310, and can wait for its session ID to be approved on a partner account (such as subsystem 305-b), for the request to be canceled, or for a timeout to occur. If the session is approved, the stored procedure 345 can call the run and output functions and then clean up the approved session.

[0032] Run functions can include code written by the client (e.g., client-provided code). Run methods take an input variable called “session,” which corresponds to a data sharing session between two or more parties / collaborators (e.g., a snowpark session). Any instance in which a table name macro is used can be replaced with the corresponding clean-room low-access policy compliant view name. Output methods can write results to a result table shared with process orchestration layer 310. Output methods can include a session and a data frame to write as output. The names and data types of the columns in the output data frame correspond to dimensions and measures.

[0033] As described herein, the initialization function may include a call to an authentication token generation secure function that encrypts the current session ID, current virtual warehouse name, current task name, current timestamp, the secure hashing algorithm (SHA) value of the stored procedure 345 that wraps the python function, the SHA value of the task code, and the SHA value of the stored procedure 345 that runs the procedure, using a private key. The process orchestration layer 310 can validate the SHA value, task name, warehouse name, and timestamp, so that if a client (or malicious actor) attempts to insert its worksheet session ID into the table, the ID will contain an incorrect warehouse name and / or task name. If a client attempts to modify the stored procedure 345, the SHA value of the stored procedure 345 will not match the SHA value generated by the process orchestration layer 310, thereby preventing any hacking or unauthorized modification. A dataset (such as dataset 320) may have a low-access policy 355 that allows read access for queries only if the session ID has been validated.

[0034] In the example shown in Figure 3, the process orchestration layer 310 may include or otherwise access authentication information 325 (e.g., authentication_info), clean room requests 330 (e.g., clean_room_requests), an authenticator function 335 (e.g., authenticator()), and a session-allowing function 340 (e.g., allowSession()). Subsystem 305-a may include or otherwise access a dataset 315 (e.g., crm_data), authentication information 325, a stored procedure 345 (e.g., generated_stored_proc_(random1)), clean room requests 330, and an authenticator function 335. Similarly, subsystem 305-b may include or otherwise access a dataset 320 (e.g., txn_data), a session-allowing function 340, clean room requests 330, and an allowed session ID table 360. As described herein, stored procedure 345 may include an initialization function (e.g., init()), a run function (e.g., run(session)), and an output function (e.g., output(output_df)).

[0035] Embodiments of the data processing system 300 can be implemented to achieve one or more of the following advantages. The techniques described with reference to Figure 3 can support improvements in user experience, data privacy, and query complexity by enabling collaborators (such as subsystem 305) to perform complex queries on partner datasets (such as dataset 320) and / or perform additional processing without exposing actual data from the partner datasets. For example, the techniques described can enable collaborators in a data clean room to execute Python code approved by all other collaborators in the data clean room, thereby providing the data owner with a way to control who can access and use the data owner's data. The techniques described herein can also leverage a combination of cryptographic techniques, secure functions, and low-access policies (such as low-access policy 355) to prevent collaborators from tampering with or otherwise manipulating approved code.

[0036] Figure 4 shows an example of a flowchart 400 supporting a technique for securely executing verified code in a collaborative environment, according to aspects of this disclosure. Flowchart 400 can also implement, and may be implemented by, any aspect of the data processing system described with reference to Figures 1 to 3. For example, flowchart 400 includes a process orchestration layer 410, subsystem 405-a, and subsystem 405-b, which can be examples of the corresponding elements described herein, including with reference to Figures 1 to 3. The process orchestration layer 410 can facilitate a secure shared session between subsystem 405-a and subsystem 405-b. Subsystem 405-a may correspond to a first party (i.e., owner, collaborator A) in the data clean room, and subsystem 405-b may correspond to a second party (i.e., partner, collaborator B) in the data clean room.

[0037] At 415, the process orchestration layer 410 can create a view request that is sent to subsystem 405-b. At 420, subsystem 405-b can create the requested view. At 425, subsystem 405-b (more specifically, the cloud client associated with subsystem 405-b) can add a low access policy to its view (such as low access policy 355 as described with reference to Figure 3).

[0038] In 430, the process orchestration layer 410 may share a secure function (e.g., token_generation) with one or both of the subsystems 405. In 435, the process orchestration layer 410 may generate / install a stored procedure (such as stored procedure 345 as described with reference to Figure 3) and send a procedure call request to subsystem 405-a. In 440, subsystem 405-a may create the procedure in response to the procedure call request. In 445, subsystem 405-a may call that procedure.

[0039] At 450, subsystem 405-a can share tokens (such as the encrypted session token 230 described with reference to Figure 2) with the process orchestration layer 410. At 455, subsystem 405-a can wait for the token (i.e., session_id) to become available within a partner account (e.g., subsystem 405-b).

[0040] In step 460, the process orchestration layer 410 can validate the token from subsystem 405-a using a secret encryption key hidden from both subsystems 405. If the token is valid, in step 465, the process orchestration layer 410 can send a token insertion request to the partner account (e.g., subsystem 405-b). Checking the token can help ensure that the client dataset is accessed only by authorized (i.e., verified) code running within a secure shared session.

[0041] Therefore, in 470, the subsystem 405-b can share the view with the owner account (e.g., subsystem 405-a). In 475, the subsystem 405-b can insert the token into an allowed session ID table (such as the allowed session ID table 360 ​​as described with reference to Figure 3). In 480, the subsystem 405-a can complete the rest of the procedure.

[0042] Figure 5 shows an example of a process flow 500 that supports a technique for securely executing verified code in a collaborative environment, according to aspects of this disclosure. Process flow 500 may also implement, or be implemented by, any aspect of the data processing system or flow diagram described with reference to Figures 1 to 4. For example, process flow 500 includes a process orchestration layer 510, a subsystem 505-a (i.e., owner account), and a subsystem 505-b (i.e., partner account). As described herein, subsystem 505 may correspond to parties (e.g., collaborators) in a data clean room. In the following description of process flow 500, the operations between the process orchestration layer 510 and subsystem 505 may be added, omitted, or performed in a different order (from the exemplary order shown).

[0043] As described herein, the process orchestration layer 510 can be installed on all of the subsystems 505 using any other process, such as a native application, a Python command-line interface (CLI), or sharing orchestration code. In subsystem 515, the process orchestration layer 510 can obtain code that is mutually approved by all parties in the data clean room (i.e., both subsystems 505). In some examples, the code can be written using a high-level programming language such as Python.

[0044] At 520, the process orchestration layer 510 can generate a stored procedure (such as stored procedure 345, as described with reference to Figure 3) which includes an initialization function, a run function, and an output function. At 525, the process orchestration layer issues a procedure call request to subsystem 505-a, thereby causing subsystem 505-a to execute the stored procedure.

[0045] In 530, subsystem 505-a can execute an initialization function for a stored procedure. As described herein, the initialization function may include a call to a secure function that generates an encrypted session token (i.e., a signed session ID) based on the stored procedure, subsystem 505-a, and other parameters and attributes. For example, the secure function may use SHA to generate hash values ​​associated with the stored procedure wrapping the Python code, the task code, or the stored procedure running the procedure. The secure function may encrypt these hash values ​​along with the current session ID, the current warehouse name, the current task name, and the current timestamp.

[0046] In step 535, the secure token generation function can share the encrypted session token with the process orchestration layer 510. In step 540, the process orchestration layer can validate the token provided by subsystem 505-a by, for example, decrypting the encrypted session token using a private key. If the token is valid (i.e., all elements of the decrypted token match the corresponding elements generated by the process orchestration layer 510), in step 545, the process orchestration layer 510 can provide the token to subsystem 505-b. The process orchestration layer 510 can also provide the token to all other parties in the data clean room. Thus, in step 550, subsystem 505-b can insert the token into the list of acceptable session IDs (for example, the acceptable session ID table 360 ​​described with reference to Figure 3).

[0047] After the token (i.e., session ID) becomes available to subsystem 505-b, subsystem 505-a can complete the rest of the stored procedure, for example, by executing the rest of the initialization function (including calls to the run function and output function). In 555, subsystem 505-a can execute the run function of the stored procedure, which may include mutually approved client-provided code. The run function may access one or more rows of a dataset from subsystem 505-b and / or subsystem 505-a, in accordance with one or more row access policies configured for that dataset. In 560, subsystem 505-a can execute the output function of the stored procedure, which stores / writes the results of the run function to a client table shared with the process orchestration layer 510.

[0048] Figure 6 shows a block diagram 600 of a device 605 that supports a technique for securely executing verified code in a collaborative environment, according to an aspect of the present disclosure. Device 605 may include an input module 610, an output module 615, and a process orchestration layer 620. Device 605 may also include a processor. Each of these components may be in communication with one another (for example, via one or more buses).

[0049] The input module 610 can manage input signals from device 605. For example, the input module 610 can identify input signals based on interaction with a modem, keyboard, mouse, touchscreen, or similar device. These input signals may be related to user input or processing in other components or devices. In some cases, the input module 610 can handle input signals using an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or another known operating system. The input module 610 can send these input signals to other components of device 605 for processing. For example, the input module 610 can send input signals to a process orchestration layer 620 for the purpose of supporting techniques for securely executing verified code in a collaborative environment. In some cases, the input module 610 can be a component of the I / O controller 810, as described with reference to Figure 8.

[0050] The output module 615 can manage the output signals of device 605. For example, the output module 615 can receive signals from other components of device 605, such as the process orchestration layer 620, and transmit these signals to other components or devices. In some examples, the output module 615 can transmit output signals for display in a user interface, for storage in a database or data store, for further processing in a server or server cluster, or for any other processing in any number of devices or systems. In some cases, the output module 615 can be a component of the I / O controller 810, as described with reference to Figure 8.

[0051] For example, the process orchestration layer 620 may include a verified code component 625, a stored procedure component 630, a call request component 635, a cryptographic token component 640, a private key component 645, a row access component 650, an output table component 655, or any combination thereof. In some examples, the process orchestration layer 620, or its various components, may be configured to perform various operations (e.g., receiving, monitoring, transmitting) using or in cooperation with the input module 610, the output module 615, or both. For example, the process orchestration layer 620 may receive information from the input module 610, send information to the output module 615, or integrate with the input module 610, the output module 615, or both to receive information, transmit information, or perform various other operations described herein.

[0052] The process orchestration layer 620 can support data processing in the examples disclosed herein. The verified code component 625 can be configured in the process orchestration layer of the data processing system to support obtaining an identifier for code approved by two or more parties in a secure shared session. The stored procedure component 630 can be configured in the process orchestration layer to support generating a stored procedure that includes an initialization function, an output function, and a run function containing the approved code. The call request component 635 can be configured in the process orchestration layer to support outputting a request to a first subsystem of the data processing system associated with a first party among two or more parties in a secure shared session, causing the first subsystem to execute the stored procedure.

[0053] The cryptographic token component 640 can be configured to support receiving an identifier for a cryptographic session token from a first subsystem in the process orchestration layer according to the initialization function of a stored procedure. The private key component 645 can be configured to support validating the cryptographic session token provided by the first subsystem based on decrypting the cryptographic session token using a private key. The cryptographic token component 640 can be configured to support providing the validated session token to a second subsystem of a data processing system associated with at least the second of two or more parties to a secure shared session.

[0054] The row access component 650 can be configured to support accessing one or more rows of a dataset associated with a second party, based on comparing a validated session token with a list of authorized session identifiers associated with that dataset, according to the run function of the stored procedure. The output table component 655 can be configured to support writing the results of the run function to a table, according to the output function of the stored procedure.

[0055] Figure 7 shows a block diagram 700 of a process orchestration layer 720 that supports a technique for securely executing verified code in a collaborative environment, according to an aspect of this disclosure. The process orchestration layer 720 may be an example of an aspect of the process orchestration layer or process orchestration layer 620, or both, as described herein. The process orchestration layer 720, or its various components, may be an example of means for implementing various aspects of the technique for securely executing verified code in a collaborative environment, as described herein. For example, the process orchestration layer 720 may include a verified code component 725, a stored procedure component 730, a call request component 735, a cryptographic token component 740, a private key component 745, a row access component 750, an output table component 755, or any combination thereof. Each of these components may communicate with one another directly or indirectly (e.g., via one or more buses).

[0056] The process orchestration layer 720 can support data processing in the examples disclosed herein. The verified code component 725 can be configured in the process orchestration layer of the data processing system to support obtaining an identifier for code approved by two or more parties in a secure shared session. The stored procedure component 730 can be configured in the process orchestration layer to support the generation of a stored procedure including an initialization function, an output function, and a run function containing the approved code.

[0057] The call request component 735 can be configured to support outputting a request from the process orchestration layer to a first subsystem of a data processing system associated with a first party among two or more parties to a secure shared session, causing the first subsystem to execute a stored procedure. The cryptographic token component 740 can be configured to support receiving an identifier for an encrypted session token from the first subsystem in the process orchestration layer according to the stored procedure initialization function. The private key component 745 can be configured to support validating the encrypted session token provided by the first subsystem based on decrypting the encrypted session token using a private key.

[0058] In some examples, the cryptographic token component 740 may be configured to support providing a validated session token to a second subsystem of a data processing system associated with at least a second of two or more parties to a secure shared session. The row access component 750 may be configured to support accessing one or more rows of a dataset associated with the second party, based on comparing a validated session token with a list of authorized session identifiers associated with that dataset, according to a run function of a stored procedure. The output table component 755 may be configured to support writing the results of a run function to a table, according to an output function of a stored procedure.

[0059] In some examples, the encrypted session token provided by the first subsystem includes a session identifier, a data warehouse name, a task name, a timestamp, a hash value associated with the stored procedure's wrapping function, a hash value of the task code, and a hash value associated with the stored procedure's run function.

[0060] In some examples, the cryptographic token component 740 can be configured to support the generation of cryptographic session tokens in a first subsystem of the data processing system using a secure hashing algorithm, according to the initialization function of a stored procedure.

[0061] In some practical applications, to support access to one or more rows in a dataset, the row access component 750 may be configured to support access to one or more rows in a dataset associated with a second party, in accordance with a row access policy defined by the second party.

[0062] In some examples, the initialization function of a stored procedure includes a call to a secure function that returns an encrypted session token. In some examples, a table is accessible to two or more parties in a secure shared session. In some examples, data from a dataset associated with a second party is not exposed to other parties in the secure shared session.

[0063] In some examples, the process orchestration layer provides an encrypted session token to each of two or more parties in a secure shared session. In some examples, the verified code component 725 can be configured to support verifying that a dataset is being accessed by code running within a secure shared session.

[0064] Figure 8 shows a diagram of a system 800 including a device 805 that supports a technique for securely executing verified code in a collaborative environment, according to an aspect of this disclosure. Device 805 may be an example of a component of device 605 described herein, or may include such components. Device 805 may include components for bidirectional data communication, including components for transmitting and receiving communications, such as a process orchestration layer 820, an input / output (I / O) controller 810, a database controller 815, memory 825, a processor 830, and a database 835. These components may be in electronic communication state via one or more buses (e.g., bus 840), or may be coupled in other ways (e.g., operably, communicatively, functionally, electronically, electrically).

[0065] The I / O controller 810 can manage the input signal 845 and output signal 850 of device 805. The I / O controller 810 can also manage peripheral devices not integrated into device 805. In some cases, the I / O controller 810 may represent a physical connection or port to an external peripheral device. In some cases, the I / O controller 810 may utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or another known operating system. In other cases, the I / O controller 810 may represent and interact with a modem, keyboard, mouse, touchscreen, or similar device. In some cases, the I / O controller 810 may be implemented as part of the processor 830. In some examples, a user can interact with device 805 via the I / O controller 810 or via hardware components controlled by the I / O controller 810.

[0066] The database controller 815 can manage the storage and processing of data in the database 835. In some cases, the user can interact with the database controller 815. In other cases, the database controller 815 can operate automatically without user interaction. The database 835 can be an example of a single database, a distributed database, multiple distributed databases, a data store, a data lake, or an emergency backup database.

[0067] Memory 825 may include random-access memory (RAM) and read-only memory (ROM). Memory 825 may store computer-readable, computer-executable software, which, when executed, causes the processor 830 to perform various functions described herein. In some cases, memory 825 may house a basic I / O system (BIOS) that can control basic hardware or software operations, such as, among other things, interaction with peripheral components or peripheral devices.

[0068] The processor 830 may include intelligent hardware devices (e.g., general-purpose processors, digital signal processors (DSPs), central processing units (CPUs), microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, the processor 830 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into the processor 830. The processor 830 may be configured to execute computer-readable instructions stored in memory 825 to perform various functions (e.g., functions or tasks that support techniques for securely executing verified code in a cooperative environment).

[0069] The process orchestration layer 820 can support data processing in the examples disclosed herein. For example, the process orchestration layer 820 can be configured to support obtaining an identifier for code approved by two or more parties in a secure shared session within the process orchestration layer of a data processing system. The process orchestration layer 820 can be configured to support the generation of a stored procedure by the process orchestration layer, which includes an initialization function, an output function, and a run function containing the approved code.

[0070] The process orchestration layer 820 can be configured to support outputting a request from the processing orchestration layer to a first subsystem of a data processing system associated with a first party among two or more parties to a secure shared session, causing the first subsystem to execute a stored procedure. The process orchestration layer 820 can be configured to support receiving an identifier for an encrypted session token from the first subsystem in accordance with the stored procedure initialization function. The process orchestration layer 820 can be configured to support validating the encrypted session token provided by the first subsystem based on decrypting the encrypted session token using a private key.

[0071] The process orchestration layer 820 can be configured to support providing validated session tokens to a second subsystem of a data processing system associated with at least a second party among two or more parties to a secure shared session. The process orchestration layer 820 can be configured to support accessing one or more rows of a dataset associated with the second party, based on comparing the validated session tokens with a list of authorized session identifiers associated with that dataset, according to a run function of a stored procedure. The process orchestration layer 820 can be configured to support writing the results of a run function to a table, according to an output function of a stored procedure.

[0072] By including or configuring a process orchestration layer 820 in accordance with the examples described herein, System 800 can support techniques for improving user experience, data privacy, and query complexity by enabling collaborators to perform complex queries on partner datasets and / or perform additional processing without exposing actual data from partner datasets. For example, the techniques described can enable collaborators in a data clean room to execute Python code approved by all other collaborators in the data clean room, thereby providing a data owner with a way to control who can access and use their data. The techniques described herein can also leverage a combination of cryptographic techniques, secure functions, and low-access policies to prevent collaborators from tampering with or otherwise manipulating approved code.

[0073] Figure 9 shows a flowchart illustrating Method 900, which supports a technique for securely executing verified code in a collaborative environment, according to aspects of this disclosure. The operation of Method 900 can be implemented by a data processing system or its components. For example, the operation of Method 900 can be implemented by an aspect of the data processing system 300 described with reference to Figure 3. In some examples, the data processing system can execute a set of instructions to control functional elements of the data processing system to perform the functions described. In addition to or instead of this, the data processing system can also implement aspects of the functions described using dedicated hardware.

[0074] In 905, the method may include obtaining an identifier for a code approved by two or more parties in a secure shared session at the process orchestration layer of a data processing system. The operation of 905 can be carried out according to the examples disclosed herein. In some examples, aspects of the operation of 905 can be carried out by the verified code component 725 described with reference to Figure 7.

[0075] In 910, the method may include the process orchestration layer generating a stored procedure that includes an initialization function, an output function, and a run function containing approved code. The operation of 910 can be carried out according to the examples disclosed herein. In some examples, the operation of 910 can be carried out by a stored procedure component 730 described with reference to Figure 7.

[0076] In 915, the method may include outputting a request from the process orchestration layer to a first subsystem of a data processing system associated with a first party among two or more parties of a secure shared session, causing the first subsystem to execute a stored procedure. The operation of 915 can be carried out according to the examples disclosed herein. In some examples, the operation of 915 can be carried out by a call request component 735 described with reference to Figure 7.

[0077] In 920, the method may include receiving an identifier for a cryptographic session token from a first subsystem in the process orchestration layer according to the initialization function of a stored procedure. The operation of 920 can be carried out according to the examples disclosed herein. In some examples, the operation of 920 can be carried out by a cryptographic token component 740 described with reference to Figure 7.

[0078] In 925, the method may include validating an encrypted session token provided by a first subsystem based on decrypting the encrypted session token using a private key. The operation of 925 can be carried out according to the examples disclosed herein. In some examples, aspects of the operation of 925 can be carried out by a private key component 745 described with reference to Figure 7.

[0079] In 930, the method may include providing a validated session token to a second subsystem of a data processing system associated with at least a second of two or more parties to a secure shared session. The operation of 930 can be carried out according to the examples disclosed herein. In some examples, aspects of the operation of 930 can be carried out by the cryptographic token component 740 described with reference to Figure 7.

[0080] In 935, the method may include accessing one or more rows of a dataset associated with a second party, based on comparing a validated session token with a list of authorized session identifiers associated with that dataset, according to a run function of a stored procedure. The operation of 935 can be carried out according to the examples disclosed herein. In some examples, aspects of the operation of 935 can be carried out by a row access component 750 described with reference to Figure 7.

[0081] In 940, the method may include writing the result of a run function to a table according to the output function of a stored procedure. The operation of 940 can be carried out according to the examples disclosed herein. In some examples, aspects of the operation of 940 can be carried out by the output table component 755 described with reference to Figure 7.

[0082] This document describes a method for data processing. The method involves the process orchestration layer of the data processing system obtaining an identifier for code approved by two or more parties of a secure shared session; the process orchestration layer generating a stored procedure including an initialization function, an output function, and a run function containing the approved code; the process orchestration layer outputting a request to a first subsystem of the data processing system associated with the first of the two or more parties of the secure shared session to cause the first subsystem to execute the stored procedure; and the process orchestration layer receiving an identifier for an encrypted session token from the first subsystem according to the initialization function of the stored procedure. This may include validating an encrypted session token provided by a first subsystem by decrypting the encrypted session token using a private key, providing the validated session token to a second subsystem of a data processing system associated with at least second of two or more parties to a secure shared session, accessing one or more rows of a dataset associated with the second party by comparing the validated session token with a list of authorized session identifiers associated with that dataset, according to a run function of a stored procedure, and writing the results of the run function to a table, according to an output function of a stored procedure.

[0083] This document describes a device for data processing. The device may include a processor, memory coupled to the processor, and instructions stored in memory. The instructions include: obtaining an identifier for code approved by two or more parties of a secure shared session in the process orchestration layer of the data processing system; generating a stored procedure in which the process orchestration layer includes an initialization function, an output function, and a run function containing the approved code; outputting a request from the process orchestration layer to a first subsystem of the data processing system associated with the first of the two or more parties of the secure shared session, causing the first subsystem to execute the stored procedure; and receiving an identifier for an encrypted session token from the first subsystem in the process orchestration layer according to the initialization function of the stored procedure. The processor can be configured to cause the device to perform the following actions: validate an encrypted session token provided by the system by decrypting the encrypted session token using a private key; provide the validated session token to a second subsystem of a data processing system associated with at least a second party among two or more parties to a secure shared session; access one or more rows of a dataset associated with the second party by comparing the validated session token with a list of authorized session identifiers associated with that dataset, according to a run function of a stored procedure; and write the results of the run function to a table, according to an output function of a stored procedure.

[0084] Another device for data processing is described. The device includes means for obtaining an identifier of code approved by two or more parties of a secure shared session in the process orchestration layer of the data processing system; means for the process orchestration layer to generate a stored procedure including an initialization function, an output function, and a run function containing the approved code; means for the process orchestration layer to output a request to a first subsystem of the data processing system associated with a first party among the two or more parties of the secure shared session to cause the first subsystem to execute the stored procedure; and, in accordance with the initialization function of the stored procedure, receiving an identifier of an encrypted session token from the first subsystem in the process orchestration layer. The system may include means for validating an encrypted session token provided by a first subsystem based on decrypting the encrypted session token using a private key; means for providing the validated session token to a second subsystem of a data processing system associated with at least a second of two or more parties to a secure shared session; means for accessing one or more rows of a dataset associated with the second party based on comparing the validated session token with a list of authorized session identifiers associated with that dataset, according to a run function of a stored procedure; and means for writing the results of the run function to a table, according to an output function of a stored procedure.

[0085] This document describes a non-temporary computer-readable medium for storing code for data processing. The code involves obtaining an identifier for code approved by two or more parties of a secure shared session at the process orchestration layer of the data processing system; the process orchestration layer generating a stored procedure including an initialization function, an output function, and a run function containing the approved code; the process orchestration layer outputting a request to a first subsystem of the data processing system associated with the first of the two or more parties of the secure shared session to cause the first subsystem to execute the stored procedure; and, according to the initialization function of the stored procedure, the process orchestration layer receiving an identifier for an encrypted session token from the first subsystem, and the first subsystem The instructions may include instructions executable by the processor to validate an encrypted session token provided by the system by decrypting the encrypted session token using a private key; provide the validated session token to a second subsystem of a data processing system associated with at least a second party among two or more parties to a secure shared session; access one or more rows of a dataset associated with the second party by comparing the validated session token with a list of authorized session identifiers associated with that dataset, according to a run function of the stored procedure; and write the results of the run function to a table, according to an output function of the stored procedure.

[0086] In some examples of the methods, apparatus, and non-temporary computer-readable media described herein, the cryptographic session token provided by the first subsystem includes a session identifier, a data warehouse name, a task name, a timestamp, a hash value associated with the wrapping function of the stored procedure, a hash value of the task code, and a hash value associated with the run function of the stored procedure.

[0087] Some examples of methods, apparatus, and non-temporary computer-readable media described herein may further include operations, features, means, or instructions for generating cryptographic session tokens using a secure hashing algorithm in a first subsystem of a data processing system, according to an initialization function of a stored procedure.

[0088] In some examples of the methods, apparatus, and non-temporary computer-readable media described herein, accessing one or more rows of a dataset may include actions, features, means, or instructions for accessing one or more rows of a dataset associated with a second party, in accordance with a row access policy defined by the second party.

[0089] In some examples of the methods, apparatus, and non-temporary computer-readable media described herein, the initialization function of a stored procedure includes a call to a secure function that returns an encrypted session token.

[0090] In some examples of the methods, apparatus, and non-temporary computer-readable media described herein, tables can be made accessible to two or more parties in a secure shared session.

[0091] In some examples of the methods, apparatus, and non-temporary computer-readable media described herein, data from a dataset associated with a second party may not be exposed to other parties in a secure shared session.

[0092] In some examples of the methods, apparatus, and non-temporary computer-readable media described herein, a process orchestration layer provides an encrypted session token to each of two or more parties in a secure shared session.

[0093] Some examples of methods, apparatus, and non-temporary computer-readable media described herein may further include actions, features, means, or instructions for verifying whether a dataset may be accessed by code running within a secure shared session.

[0094] The following is an overview of the aspects of this disclosure.

[0095] Embodiment 1: A method for data processing, comprising: obtaining an identifier for code approved by two or more parties of a secure shared session in the process orchestration layer of a data processing system; generating a stored procedure comprising an initialization function, an output function, and a run function containing the approved code in the process orchestration layer; outputting a request from the process orchestration layer to a first subsystem of the data processing system associated with a first party among the two or more parties of the secure shared session, causing the first subsystem to execute the stored procedure; and receiving an identifier for an encrypted session token from the first subsystem in the process orchestration layer according to the initialization function of the stored procedure. A method for data processing, comprising validating an encrypted session token provided by a first subsystem, at least in part on decrypting the encrypted session token using a private key; providing the validated session token to a second subsystem of a data processing system associated with at least a second party among two or more parties to a secure shared session; accessing one or more rows of a dataset associated with the second party, at least in part on comparing the validated session token with a list of authorized session identifiers associated with that dataset, according to a run function of a stored procedure; and writing the results of the run function to a table, according to an output function of a stored procedure.

[0096] Embodiment 2: The method of Embodiment 1, wherein the encrypted session token provided by the first subsystem includes a session identifier, a data warehouse name, a task name, a timestamp, a hash value associated with the wrapping function of the stored procedure, a hash value of the task code, and a hash value associated with the run function of the stored procedure.

[0097] Embodiment 3: A method according to any embodiment of Embodiments 1 to 2, further comprising generating an encrypted session token in a first subsystem of a data processing system using a secure hashing algorithm, according to an initialization function of a stored procedure.

[0098] Embodiment 4: A method according to any one embodiment of Embodiments 1 to 3, wherein accessing one or more rows of a dataset includes accessing one or more rows of a dataset associated with a second party in accordance with a row access policy defined by the second party.

[0099] Embodiment 5: A method according to any embodiment of Embodiments 1 to 4, wherein the initialization function of a stored procedure includes a call to a secure function that returns an encrypted session token.

[0100] Embodiment 6: A method according to any embodiment of Embodiments 1 to 5, wherein the table is accessible from two or more parties in a secure shared session.

[0101] Embodiment 7: A method according to any embodiment of Embodiments 1 to 6, wherein data from a dataset associated with a second party is not exposed to other parties in the secure shared session.

[0102] Embodiment 8: A method according to any embodiment 1 to 7, wherein the process orchestration layer provides an encrypted session token to each of two or more parties in a secure shared session.

[0103] Embodiment 9: A method according to any embodiment of Embodiments 1 to 8, further comprising verifying that the dataset is being accessed by code running within a secure shared session.

[0104] Embodiment 10: A data processing apparatus comprising a processor, a memory coupled to the processor, and instructions stored in the memory, wherein the instructions are executable by the processor to cause the apparatus to perform a method according to any of Embodiments 1 to 9.

[0105] Embodiment 11: A data processing apparatus comprising at least one means for carrying out a method according to any one embodiment of Embodiments 1 to 9.

[0106] Embodiment 12: A non-temporary computer-readable medium for storing code for data processing, wherein the code comprises instructions executable by a processor to carry out the method of any embodiment of Embodiments 1 to 9.

[0107] Please note that the methods described above describe possible implementations, that the operations and steps can be rearranged or otherwise modified, and that other implementations are possible. Furthermore, it is possible to combine two or more aspects of the methods.

[0108] The descriptions provided herein in relation to the accompanying drawings are illustrative and do not necessarily represent all implementable examples or examples that fall within the scope of the claims. The term “exemplary” as used herein means “acting as an example, case, or illustration,” and not “preferred” or “advantageous over other examples.” The modes for carrying out the invention include specific details for the purpose of providing an understanding of the techniques described. However, these techniques can be practiced without these specific details. In some cases, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the examples described.

[0109] In the attached diagrams, similar components or features may share the same reference numeral. Furthermore, different components of the same type can be distinguished by the following steps: a dash followed by a second reference numeral to differentiate them from similar components. Where only the first reference numeral is used in this specification, the description is applicable to any one of the similar components sharing the same first reference numeral, regardless of the second reference numeral.

[0110] The information and signals described herein can be represented using a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description can be represented by voltage, electric current, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any combination thereof.

[0111] The various exemplary blocks and modules described herein in relation to this disclosure may be implemented or carried out using general-purpose processors, DSPs, ASICs, FPGAs or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors and a DSP core, or any other such configuration).

[0112] The functions described herein may be implemented as hardware, as software executed by a processor, as firmware, or as any combination thereof. When implemented as software executed by a processor, the functions may be stored on or transmitted via a computer-readable medium as one or more instructions or codes. Other examples and implementations are included within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwiring, or any combination thereof. Features implementing the functions may also be physically located in various locations, including being distributed so that parts of the functions are implemented in different physical locations. Also, within this specification, including the claims, when "or" is used in a list of items (e.g., a list of items beginning with a phrase such as "at least one of..." or "one or more of...") it indicates an inclusive list, such as a list of at least one of A, B, or C meaning A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, in this specification, the phrase "based on" should not be interpreted as referring to a closed set of conditions. For example, an exemplary step described as "based on condition A" can be based on both condition A and condition B without departing from the scope of this disclosure. In other words, in this specification, the phrase "based on" shall be interpreted similarly to the phrase "based at least partially on."

[0113] Computer-readable media include both non-temporary computer storage media and communication media, which include any media that facilitate the transfer of computer programs from one location to another. Non-temporary storage media can be any available media accessible by a general-purpose computer or a dedicated computer. Examples, but not limited to, non-temporary computer-readable media may include RAM, ROM, electrically erasable programmable ROM (EEPROM), compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-temporary media that can be used to carry or store desired program code means in the form of instructions or data structures, and can be accessed by a general-purpose computer or a dedicated computer, or a general-purpose processor or a dedicated processor. Any connection is also appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair cable, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair cable, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. Disk and disc, as used herein, include CDs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, provided that a disk typically reproduces data magnetically, while a disc reproduces data optically using a laser. Any combination of the above is also included within the scope of computer-readable media.

[0114] The descriptions herein are provided to enable those skilled in the art to create or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the scope of the disclosure. Accordingly, the disclosure should not be limited to the examples and designs described herein, but should be given the broadest scope that is consistent with the principles and novel features disclosed herein.

Claims

1. A method for data processing, In the process orchestration layer of a data processing system, obtaining identification of code approved by two or more parties in a secure shared session, The process orchestration layer generates a stored procedure comprising an initialization function, an output function, and a run function containing the approved code. The process orchestration layer outputs a request to the first subsystem of the data processing system associated with the first of the two or more parties of the secure shared session to cause the first subsystem to execute the stored procedure. In accordance with the initialization function of the stored procedure, the process orchestration layer receives an identifier for the cryptographic session token from the first subsystem. Validating the encrypted session token provided by the first subsystem, at least in part, based on decrypting the encrypted session token using a private key, Providing the validated session token to a second subsystem of the data processing system associated with at least a second party among the two or more parties of the secure shared session, Accessing one or more rows of the dataset associated with the second party, at least in part, based on comparing the validated session token with a list of authorized session identifiers associated with the dataset, according to the run function of the stored procedure, The result of the run function is written to the table according to the output function of the stored procedure. A method for data processing, including...

2. The method according to claim 1, wherein the encrypted session token provided by the first subsystem includes a session identifier, a data warehouse name, a task name, a timestamp, a hash value associated with the wrapping function of the stored procedure, a hash value of the task code, and a hash value associated with the run function of the stored procedure.

3. In accordance with the initialization function of the stored procedure, the first subsystem of the data processing system generates the encrypted session token using a secure hashing algorithm. The method according to claim 1, further comprising:

4. Accessing one or more rows of the aforementioned dataset is Accessing one or more rows of the dataset associated with the second party in accordance with the row access policy defined by the second party. The method according to claim 1, including the method described in claim 1.

5. The method according to claim 1, wherein the initialization function of the stored procedure includes a call to a secure function that returns the encrypted session token.

6. The method according to claim 1, wherein the table is accessible from the two or more parties of the secure shared session.

7. The method according to claim 1, wherein the data from the dataset associated with the second party is not exposed to other parties in the secure shared session.

8. The method according to claim 1, wherein the process orchestration layer provides the encrypted session token to each of the two or more parties of the secure shared session.

9. Verify that the dataset is being accessed by the code running within the secure shared session. The method according to claim 1, further comprising:

10. A device for data processing, Processor and The memory coupled to the aforementioned processor, Stored in the aforementioned memory, In the process orchestration layer of a data processing system, obtaining identification of code approved by two or more parties in a secure shared session, The process orchestration layer generates a stored procedure comprising an initialization function, an output function, and a run function containing the approved code. The process orchestration layer outputs a request to the first subsystem of the data processing system associated with the first of the two or more parties of the secure shared session to cause the first subsystem to execute the stored procedure. In accordance with the initialization function of the stored procedure, the process orchestration layer receives an identifier for the cryptographic session token from the first subsystem. Validating the encrypted session token provided by the first subsystem, at least in part, based on decrypting the encrypted session token using a private key, Providing the validated session token to a second subsystem of the data processing system associated with at least a second party among the two or more parties of the secure shared session, Accessing one or more rows of the dataset associated with the second party, at least in part, based on comparing the validated session token with a list of authorized session identifiers associated with the dataset, according to the run function of the stored procedure, The result of the run function is written to the table according to the output function of the stored procedure. Instructions that can be executed by the processor and A device for data processing that includes the following features.

11. The apparatus according to claim 10, wherein the encrypted session token provided by the first subsystem includes a session identifier, a data warehouse name, a task name, a timestamp, a hash value associated with the wrapping function of the stored procedure, a hash value of the task code, and a hash value associated with the run function of the stored procedure.

12. The aforementioned instruction, In accordance with the initialization function of the stored procedure, the first subsystem of the data processing system generates the encrypted session token using a secure hashing algorithm. The apparatus according to claim 10, further executable by the processor to cause the apparatus to perform the above.

13. To access one or more rows of the dataset, the instruction, Accessing one or more rows of the dataset associated with the second party in accordance with the row access policy defined by the second party. The apparatus according to claim 10, wherein the processor is capable of causing the apparatus to perform the above action.

14. The apparatus according to claim 10, wherein the initialization function of the stored procedure includes a call to a secure function that returns the encrypted session token.

15. The apparatus according to claim 10, wherein the table is accessible from the two or more parties of the secure shared session.

16. The apparatus according to claim 10, wherein data from the dataset associated with the second party is not exposed to other parties in the secure shared session.

17. The apparatus according to claim 10, wherein the process orchestration layer provides the encrypted session token to each of the two or more parties of the secure shared session.

18. The aforementioned instruction, Verify that the dataset is being accessed by the code running within the secure shared session. The apparatus according to claim 10, further executable by the processor to cause the apparatus to perform the above.

19. A non-temporary computer-readable medium for storing code for data processing, wherein the code is In the process orchestration layer of a data processing system, obtaining identification of code approved by two or more parties in a secure shared session, The process orchestration layer generates a stored procedure comprising an initialization function, an output function, and a run function containing the approved code. The process orchestration layer outputs a request to the first subsystem of the data processing system associated with the first of the two or more parties of the secure shared session to cause the first subsystem to execute the stored procedure. In accordance with the initialization function of the stored procedure, the process orchestration layer receives an identifier for the cryptographic session token from the first subsystem. Validating the encrypted session token provided by the first subsystem, at least in part, based on decrypting the encrypted session token using a private key, Providing the validated session token to a second subsystem of the data processing system associated with at least a second party among the two or more parties of the secure shared session, Accessing one or more rows of the dataset associated with the second party, at least in part, based on comparing the validated session token with a list of authorized session identifiers associated with the dataset, according to the run function of the stored procedure, The result of the run function is written to the table according to the output function of the stored procedure. A non-temporary computer-readable medium having instructions that can be executed by a processor to perform the following actions.

20. The non-temporary computer-readable medium according to claim 19, wherein the encrypted session token provided by the first subsystem includes a session identifier, a data warehouse name, a task name, a timestamp, a hash value associated with the wrapping function of the stored procedure, a hash value of the task code, and a hash value associated with the run function of the stored procedure.

Images