Patent Description:
The disclosure herein generally relates to serverless clouds, and, more particularly, to a method and system for privacy-preserving workflow validations in serverless clouds.

Serverless cloud computing has gained popularity of late, as it allows users to run applications without having to worry about server maintenance and other hardware specific concerns. Serverless computing allows users to deploy their entire code as multiple individual functions, without taking care of the underlying infrastructure, and other resources. Due to certain critical vulnerabilities or misconfigurations in the cloud architecture, the inter-communication of data at function level results in some serious security and privacy concerns, particularly related to the information flow in the serverless workflows.

Some systems exist to address such security concerns in the serverless platforms. Some of the existing systems use a policy based approach for workflow validation. However, they store policy related information such as a user's roles and privileges, in an insecure manner, leading to privacy and security related issues. For example, attackers may gain unauthorized access to the policy data, and may even tamper with the policy data, which may compromise data security. The existing systems perform workflow validations on an end to end flow at once i.e. before function execution begins. However, this cannot prevent attacks targeted at intermediate function calls in the workflow.

US Patent Application number <CIT> describes a system for detecting a first request associated with invoking a serverless function in a sequence of serverless functions. In response, the system deploys a primary container and a secondary container in a cloud computing environment. The primary container can execute the serverless function and transmit a second request for invoking a second serverless function in the sequence. The secondary container can intercept the second request and generate a modified second request. The secondary container can then transmit the modified second request to a destination other than an endpoint of the second serverless function, where the destination can cause the second serverless function to be executed in response to receiving the modified second request (Abstract).

European Patent Application number <CIT> describes access control to embedded devices of an industrial control system wherein the embedded devices are grouped in security domains. When an access request is received, a security domain permission attribute associated with the access request and a security domain assignment attribute associated with the embedded device are retrieved. Access to the embedded device is denied, when the security domain permission attribute does not match with the security domain assignment attribute (Abstract).

Chinese Patent Application <CIT> describes a method, a device, equipment and a medium for authority control based on roles and cloud functions. Particularly, a function sent by a user is received, the function through a cloud function is analyzed, and a function authority required to be triggered is determined. Further, a role set containing the function authority is inquired and it is verified whether the user's organization owns a role in the set of roles, and if the user is verified to have the roles in the role set in the organization, the function is executed (Abstract).

Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems.

Systems that exist to address workflow related security concerns in serverless platforms have one or more of the following disadvantages. Some of the existing systems use a policy based approach for workflow validation. However, they store policy related information in an insecure manner, leading to privacy and security related issues. For example, attackers may gain unauthorized access to the policy data, and may even tamper with the policy data, which may compromise data security. The existing systems perform workflow validations on an end to end flow at once i.e. before function execution begins. However, this cannot prevent attacks targeted at intermediate function calls in the workflow.

Some of the existing approaches and their disadvantages are described below.

Trapeze proposed by Alpernas et al. is a function's programming language dependent approach for dynamic information flow control in the serverless cloud architecture. Each function is sand-boxed in a security shim that monitors all the input output operations of the function invocations. A lattice of security labels is constructed where the labels represent the security classes of information flowing through the system. The approach has huge run-time overheads due to the expensive SQL operations involved. Further, it requires additional external services modifications to enable the working of serverless functions within the Trapeze which contribute to the overhead.

In SecLambda, each serverless function is executed in a modified runtime environment that captures the current state of the function to a security guard. The guard is responsible to run a set of security functions based on the security policies represented in the form of flow graph managed with the help of a centralized controller. The approach requires huge code instrumentation and agent embedding, thus has high compilation and runtime overheads.

Valve is another workflow protection approach where an agent sits in every container and monitors all the API calls and disk information flow in the serverless application. The workflow developers specify the policies in the form of a look up table. A Valve controller is present that audits and enforces the policies, thus denying any illegitimate behaviour or wrong information flow by a function. However, Valve requires cooperation from third parties to propagate the information about the function level operations and has improper resource utilization.

Another work titled "Workflow Integration Alleviates Identity and Access Management in Serverless Computing", by Sankaran et. Al, hereinafter referred to as WILL. IAM, encodes all the information regarding function level information flows in the form of graphs. Based on the access control policies and graph flows, it proactively checks for any unauthorized information flows in the serverless application, and accepts or deny an incoming request at the point of ingress only. Thus, it optimizes the usage of resources well, avoids the attacks such as Denial-of-service. However, it was observed that some particular attacks such as denial-of-wallet attack is still possible in the WILL. IAM since the approach does not consider checking the intermediate function-level communication or permissions at every function level execution. Rather, it checks for end-to-end permissions.

In order to address these technical challenges existing with the state of the art approaches, method and system disclosed herein handles workflow validations in serverless systems. The system is configured to perform the workflow validation in two levels/stages. The system performs a first level validation at a point of ingress of a sequence of functions forming a workflow to verify whether a user access is to be allowed to a function at the ingress point, and if the first level validation fails, user access to the workflow is denied. Post execution of the function at the ingress point, if access is requested to additional functions, then at critical intermediate function calls, the system performs a second level of validation. Access to the functions at the critical intermediate function calls is permitted only if the second level validation is successful, else the access is denied. The first level validation as well as the second level validation are done based on pre-defined access policies, which are stored in encrypted format to preserve privacy and to add data security.

<FIG> illustrates an exemplary system for workflow validation in serverless platforms, according to some embodiments of the present disclosure. The system <NUM> includes or is otherwise in communication with hardware processors <NUM>, at least one memory such as a memory <NUM>, an I/O interface <NUM>. The hardware processors <NUM>, memory <NUM>, and the Input /Output (I/O) interface <NUM> may be coupled by a system bus such as a system bus <NUM> or a similar mechanism. In an embodiment, the hardware processors <NUM> can be one or more hardware processors.

The I/O interface <NUM> may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface <NUM> may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a printer and the like. Further, the I/O interface <NUM> may enable the system <NUM> to communicate with other devices, such as web servers, and external databases.

The I/O interface <NUM> can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interface <NUM> may include one or more ports for connecting several computing systems with one another or to another server computer. The I/O interface <NUM> may include one or more ports for connecting several devices to one another or to another server.

The one or more hardware processors <NUM> may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, node machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors <NUM> is configured to fetch and execute computer-readable instructions stored in the memory <NUM>.

The memory <NUM> may include any computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the memory <NUM> includes a plurality of modules <NUM>.

The plurality of modules <NUM> include programs or coded instructions that supplement applications or functions performed by the system <NUM> for executing different steps involved in the process of workflow validation, being performed by the system <NUM>. The plurality of modules <NUM>, amongst other things, can include routines, programs, objects, components, and data structures, which performs particular tasks or implement particular abstract data types. The plurality of modules <NUM> may also be used as, signal processor(s), node machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules <NUM> can be used by hardware, by computer-readable instructions executed by the one or more hardware processors <NUM>, or by a combination thereof. The plurality of modules <NUM> can include various sub-modules (not shown). The plurality of modules <NUM> may include computer-readable instructions that supplement applications or functions performed by the system <NUM> for the workflow validation.

The data repository (or repository) <NUM> may include a plurality of abstracted piece of code for refinement and data that is processed, received, or generated as a result of the execution of the plurality of modules in the module(s) <NUM>.

Although the data repository <NUM> is shown internal to the system <NUM>, it will be noted that, in alternate embodiments, the data repository <NUM> can also be implemented external to the system <NUM>, where the data repository <NUM> may be stored within a database (repository <NUM>) communicatively coupled to the system <NUM>. The data contained within such external database may be periodically updated. For example, new data may be added into the database (not shown in <FIG>) and/or existing data may be modified and/or non-useful data may be deleted from the database. In one example, the data may be stored in an external system, such as a Lightweight Directory Access Protocol (LDAP) directory and a Relational Database Management System (RDBMS). Functions of the components of the system <NUM> are now explained with reference to the example implementation depicted in <FIG>, and steps in flow diagrams in <FIG>.

<FIG> is a flow diagram depicting steps involved in the process of workflow validation in serverless platforms, by the system of <FIG>, according to some embodiments of the present disclosure.

Steps in a method <NUM> in <FIG> are explained with reference to the components of the system <NUM> and the components depicted in the example implementation in <FIG>. In an embodiment, the system <NUM> comprises one or more data storage devices or the memory <NUM> operatively coupled to the processor(s) <NUM> and is configured to store instructions for execution of steps of the method <NUM> by the processor(s) or one or more hardware processors <NUM>. The steps of the method <NUM> of the present disclosure will now be explained with reference to the components or blocks of the system <NUM> as depicted in <FIG> and the steps of flow diagram as depicted in <FIG>. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods, and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps to be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.

At step <NUM> of the method <NUM>, the system <NUM> obtains via the external handler implemented by the one or more hardware processors <NUM>, a user request pertaining to a workflow execution in a serverless computing system. The workflow is a sequence of a plurality of functions in a specific order. In an embodiment, different users may have different roles assigned. Workflow permissions (alternately referred to as 'function execution sequence') maybe role specific, or may be assigned at individual level. For example, all users who serve same role, may have same workflow permissions. In another example, two users who have same role may have different workflow permissions. In various embodiments, the workflow permissions maybe preconfigured and may be dynamically changed/updated/edited. In yet another embodiment, a user may have multiple roles, and in turn may have different workflow permissions.

Further, at step <NUM> of the method <NUM>, a request encoder implemented by the one or more hardware processors <NUM> encodes a user role and a function execution sequence extracted from the user request to generate an encoded request. The encoded request maybe in "Role ∥ sequence" format, where 'Role' indicates role of the user who generated the user request, and 'sequence' is the corresponding function execution sequence, extracted from the user request. The encoded request maybe a binary formatted string. Let the serverless application consists of N functions. The incoming request is encoded as E(req) = R ∥ sequence. The request encoder assigns p-bits to define a particular authorization role denoted as R. Based on the total number of roles a user could have, the system <NUM> selects the number of p bits. For a requested workflow, the function execution sequence is generated by the request encoder. Considering each serverless function to be represented by a unique label ranging from <NUM> to (N - <NUM>), the sequence is given as the ordering of labels (each separated by a delimiter '-') present in the requested workflow. The request encoder has knowledge of only the function execution sequence associated with a particular workflow and does not know about the role based permissions required to access the workflow which determines the valid/invalid workflow.

For a user request with role denoted as 'role', and function execution sequence {i, j, k, l} in the range (<NUM>, N) denoted as Fi → Fj → Fk → Fl, the encoded request is given as: <MAT>.

If the user request is from a user who has multiple roles, p - bits for each role is concatenated with the labels of the corresponding functions for which the role is assigned, each function separated by the delimiter. For an example, if multiple roles R<NUM>,R<NUM> are assigned, say R<NUM> for function Fi and R<NUM> for the remaining function execution sequence, Fj → Fk → Fl, the encoded request is given as: <MAT>.

At step <NUM> of the method <NUM>, the system <NUM> invokes via the one or more hardware processors <NUM>, execution of a function at a point of ingress, if a first level validation of the encoded request is successful. In an embodiment, the system <NUM> is configured to validate a user request to a particular function execution sequence in two stages i.e. the first level of validation and a second level of validation. The first level of validation and the second level of validation are performed by a privacy preserving policy evaluation engine implemented by the one or more hardware processors <NUM>. The 'point of ingress' in the context of embodiments herein refers to a first node in a sequence of nodes in the serverless system at which a first function in the function execution sequence requested by the user request is located at. A node in which last function in the function execution sequence requested by the user request is located at, maybe termed as 'last node' or 'point of termination', and nodes between the point of ingress and the point of termination are termed as 'intermediate function calls', for any function execution sequence. The first level validation is performed to validate/verify whether the user has valid permission to access the function at the point of ingress. Steps involved in the first level of validation are depicted in method <NUM> in <FIG>, and are explained hereafter.

At step <NUM> of the method <NUM>, a cryptographic function of the encoded request is computed to generate a transformed encoded request. The cryptographic function used maybe hash function, encryption, or any other similar type. Further, at step <NUM> of the method <NUM>, the transformed encoded request is compared with a plurality of protected access policies stored in an authenticated data structure such as but not limited to a Bloom filter, wherein, the first level validation is determined as successful if the transformed encoded request is permitted by one or more of the plurality of protected access policies, and the first level validation is determined as failure if the transformed encoded request is not permitted by one or more of the plurality of protected access policies. In an embodiment, the plurality of protected access policies (alternately referred to as 'access policies') define function execution sequence that is permitted for a user, and are stored in an authenticated data structure (such as Bloom filter as in <FIG>, however, any suitable data structure maybe used), in a privacy preserving and secured manner. If the first level of authentication is determined as successful, then the particular function access sequence encoded in the transformed encoded request is accepted for the role assigned and the function at the ingress point is executed at respective container i.e. container <NUM> in <FIG>. Otherwise, the workflow is terminated at the point of ingress, and no further function execution is performed.

If the cryptographic function used is the hash function and authenticated data structure used is the Bloom filter, then the first level authentication is as follows. Value at a hash output generated by executing the hash function represents index position of the authenticated data structure for a plurality of access policies stored in it, and has a bit <NUM> or <NUM>, wherein, the first level of validation is determined as successful if the index position has the bit <NUM> (which indicates that the encoded request is permitted by one or more of the plurality of access policies), and the first level of validation is determined as failure if the index position has bit <NUM> (which indicates that the encoded request is not permitted by one or more of the plurality of access policies).

Referring back to the method <NUM>, at step <NUM> of the method <NUM>, the system <NUM> performs via the one or more hardware processors <NUM>, a second level validation of the encoded request, at each of a plurality of critical intermediate function calls of the serverless computing system to which access is requested post execution of the function at the point of ingress. In various embodiments, the critical intermediate function calls may include one or more (i.e. all or a subset) of the plurality of intermediate function calls. All the intermediate function calls maybe configured to be considered as the critical intermediate function calls, if the second level of validation is to be performed at each of the intermediate function calls. While this may improve security, having to perform the second level validation at all the intermediate function calls may increase system overhead. In order to reduce the system overhead and improve overall system performance, a subset of the intermediate function calls maybe considered as the critical intermediate function calls, and the second level of validation performs only in the subset of the intermediate function calls that have been considered as the critical intermediate function calls. Either of these two approaches maybe used as per requirements, with a tradeoff between accuracy and system overhead. Various steps involved in the second level of validation are depicted in method <NUM> in <FIG>, and are explained hereafter.

At step <NUM> of the method <NUM>, a generator in the privacy preserving policy evaluation engine generates an n-gram based on a) a previously invoked function, and b) a current function invocation request from the encoded request. The 'current function invocation request' at any instance refers to a user request to a particular function execution sequence, that is being processed at that instance. The 'previously invoked function' in this context refers to the function that was executed immediately prior to the current function invocation request. The n-gram thus captures relation between the successive functions being executed. Further, at step <NUM> of the method <NUM>, the privacy preserving policy evaluation engine computes a cryptographic function of the n-gram and a corresponding user role to generate a transformed n-gram. Further, at step <NUM> of the method <NUM>, the system <NUM> compares the transformed n-gram with a plurality of protected access policies stored in the authenticated data structure. The second level validation is determined as successful if the current function invocation request is permitted by one or more of the plurality of protected access policies, and the second level validation is determined as failure if the current function invocation request is not permitted by one or more of the plurality of protected access policies.

If the cryptographic function used is the hash function and authenticated data structure used is the Bloom filter, then the second level authentication is as follows. Value at a hash output generated by executing the hash function represents index position of the authenticated data structure for a plurality of access policies stored in it, and has a bit <NUM> or <NUM>, wherein, the second level of validation is determined as successful if the index position has the bit <NUM> (which indicates that the encoded request is permitted by one or more of the plurality of access policies), and the second level of validation is determined as failure if the index position has bit <NUM> (which indicates that the encoded request is not permitted by one or more of the plurality of access policies). In an embodiment, though <FIG> depicts that the access policies for the first level validation and the second level validation are stored in two separate authenticated data structures, they may be stored in the same authenticated data structure.

For all the critical intermediate function calls from among the plurality of critical intermediate function calls, for which the second level validation is successful, at step <NUM> of the method <NUM>, the system <NUM> invokes, via the one or more hardware processors <NUM>, corresponding function execution. At this stage, control gets transferred to respective container, where the function gets executed. In an embodiment, a process of second level validation ends a) when the second level validation is completed for all of the plurality of critical intermediate function calls, or b) the second level validation fails for any of the plurality of critical intermediate function calls.

In the second level of validation, based on number of roles assigned to the user who has requested access to the function execution sequence, there maybe two different cases.

Given the encoded request, denoted as E(req) = R ∥ i - j - k - l, the n - gram is generated for each intermediate function call i.e. directed towards functions in intermediate function calls. For a function Fj where j is a label present in the function execution sequence, the n-gram is defined a contiguous sequence of n labels with j as the nth label and the labels in function execution sequence preceding j constitute the n - <NUM> labels. The labels in the n-gram are separated by a delimiter '-'. Value of n = <NUM>. Hence, the valid n-gram for function Fj is denoted as R∥i - j.

Given the encoded request (assume to be assigned with multiple roles, say R<NUM>,R<NUM>), denoted as E(req) = R<NUM> ∥ i - R<NUM> ∥ j - k - l, the valid n-gram for function Fj is denoted as R<NUM> ∥ i - j since the role R<NUM> is assigned to function Fj.

In case of users having multiple roles, along with ordering of intermediate function calls, it is a necessity to check the roles at every intermediate function calls. Therefore, the system <NUM> combines the role with generated n-grams and is further processed as in steps <NUM> through <NUM> of the second level of validation.

<FIG> depict comparison between the method <NUM> and a state of the art approach, in terms of a plurality of parameters, according to some embodiments of the present disclosure. The experiments were conducted by benchmarking performance of the system <NUM> with an opensource serverless application Hello Retail. There were fourteen functions in the application. Values of parameters such as build size, build time (time taken to build the function), deploy time (time taken to deploy the function on the kubernetes cluster) and teardown time (time taken to delete the function instance) of these functions were calculated and average time after thirty invocations was measured. Obtained values were compared with corresponding values obtained for state of the art WILL. IAM scheme. Four workflows were run and query response time with an average of thousand invocations was measured. It was observed that even though the approach executed by the system <NUM> is privacy preserving when compared to WILL. IAM, the build size, build time and teardown time of the method <NUM> is in similar lines of the state of art approach. However the deploy time of method <NUM> is taking half to <NUM> sec longer to WILL. In terms of the query response time it was observed that complex workflows like product-purchase took more time than WILL. IAM due to level two Bloom filter checking. Based on the results it was inferred that even though the method <NUM> is privacy preserving it is not creating performance overhead when compared to state of the art WILL. These are depicted in the graphs in <FIG>. In the graphs, 'PrivFlow' refers to the method <NUM>, and WILL. IAM refers to the state of the art approach. An example workflow sequence and corresponding first level and second level validations are explained below.

Consider a serverless workflow of Product-Purchase wherein for a given customer name, credit card number and product id, corresponding value of charged amount is fetched from the database. This workflow includes the following function sequence calls:
Product-Purchase (F9) -> product-purchase-get-price (F10) -> product-purchase-authorize-cc (F11) -> product-purchase-publish (F12).

Two Bloom filters BF1 (for level <NUM> validation) and BF2 (for level <NUM> validation) are used, which are prepopulated with values computed by SHA256 based Hash(role+function number) for the functions in the workflow.

Data in BF1 is used for the first level validation, that includes the SHA256 hash of string represented role+function number of ingress function of the workflow. During the experiment conducted, Hash(customer+<NUM>)= 8766f9a0d7e758a06fbe632473e6171748ac84d7 was considered, which is present in BF1, and as a result the first level validation is successful.

Further the system <NUM> proceeds to intermediate calls of the workflow which includes checking for intermediate function call F10--->F11--->F12 and hash values are calculated accordingly Hash(role+previous_function+current_function) and are checked in the second level validation.

Accordingly when sequence is executed F10->F11->F12, the corresponding <MAT> <MAT> and <MAT> were calculated and compared with the values in BF2 at each step. If the hash values calculated at each step are present in BF2 then the workflow is executed successfully.

The embodiments of present disclosure herein address unresolved problem of security in serverless computing systems. The embodiment, thus provides a method and system of multiple levels of validation to secure workflow access at end to end function execution sequence level and at intermediate levels. Moreover, the embodiments herein further provides a mechanism of allowing/denying function execution sequence access at a point of ingress and at intermediate levels, based on success or failure of validation.

Claim 1:
A processor implemented method (<NUM>), further comprising:
obtaining (<NUM>), via one or more hardware processors (<NUM>), a user request pertaining to a workflow execution in a serverless computing system, wherein a workflow is a sequence of a plurality of functions in a specific order;
encoding (<NUM>), via the one or more hardware processors (<NUM>), a user role and a function execution sequence extracted from the user request to generate an encoded request;
invoking (<NUM>), via the one or more hardware processors (<NUM>), execution of a function at a point of ingress, if a first level validation of the encoded request is successful;
performing (<NUM>), via the one or more hardware processors (<NUM>), a second level validation of the encoded request, at each of a plurality of critical intermediate function calls of the serverless computing system to which access is requested post execution of the function at the point of ingress; and
invoking (<NUM>), via the one or more hardware processors (<NUM>), a function execution at each of the plurality of critical intermediate function calls, if the second level validation is successful,
wherein the second level validation at each of the plurality of critical intermediate function calls comprises:
generating (<NUM>) an n-gram based on a) a previously invoked function, and b) a current function invocation request from the encoded request;
computing (<NUM>) a cryptographic function of the n-gram and a corresponding user role to generate a transformed n-gram; and
comparing (<NUM>) the transformed n-gram with a plurality of protected access policies stored in an authenticated data structure, wherein, the second level validation is determined as successful if the current function invocation request is permitted by one or more of the plurality of protected access policies, and the second level validation is determined as failure if the current function invocation request is not permitted by one or more of the plurality of protected access policies.