# Secure Partitioning of Cloud Applications, with Cost Look-Ahead
## 3 Preliminaries
### Motivating Example  
Consider a Cloud-centralised IoT system that collects data sampled by sensors and sends them to a Cloud application, where the data are stored and used to decide which commands to issue to IoT actuators. The users of this application can make requests on the status of the devices and can remotely configure the application. Nowadays, these kinds of applications are well-established in the home-automation field [49], service-device compositions [50] and platforms offered by Cloud providers [51; 52]. The architecture of the example application is depicted in Figure 1. Consider six software components and two hardware components--depicted in grey--that are used by the application, connected by edges representing explicit communication links between components. Users and IoT devices perform REST invocations toward the considered application. All inbound communication passes through the Network Interface and is received by the API Gateway. The intra-application communication is performed by message passing between components, exploiting explicit channels supplied by the underlying hardware. The Authenticator decrypts and authenticates the inbound data and forwards them to the intended recipient. Application users can send General requests and Configuration requests. The former are requests for explicit actuation or data previously sampled and are delivered to the App Manager, which is the main component of the application that implements the business logic. The latter are requests for reading or updating the current application configuration and are delivered to the User Configuration component, which manages the configuration of the application. The IoT devices send either sampled data or events, which are dispatched to the App Manager component. The outbound communication consists of responses to the users based on their requests or IoT commands from the App Manager toward the IoT devices. To store relevant application data--IoT Measurement and User Preferences--the application relies on the component DB, a database that is the only one connected to the Disk. Finally, AI Learning is a machine-learning module that uses IoT Measurement and User Preferences to perform predictions and support the decision-making of the App Manager. Each component has explicit links to other components, its own data--depicted in the lower boxes of the components--and its relevant characteristics--depicted in the upper boxes of the components. For instance, the component AI Learning has data IoT Measurement and User Preference, its relevant characteristic is AI Framework and it is linked to App Manager and User Configuration. The characteristics are properties, third-party libraries, etc., that impact the _trust_ of the components. For instance, the Disk is owned by the Cloud provider, which in our setting makes the component unreliable. The measure of the trust level of the  
Figure 1: Application architecture (labels: T = top, M = medium, L = low). components is mandatory to determine if they can manage their data in order to avoid leaks. For instance, the API Gateway must be able to manage its data to avoid the leak of such data toward the Network interface. The dotted arrow between User Config and Disk represents a link consisting of an alteration of the application architecture. Figure 1 represents two different application architectures with only that link as a difference. The base application--identified as iotApp1--does not have the dotted link. The modified application--identified as iotApp2--has the dotted link. We will use those two slightly different architectures in Section 5.4 when discussing the partitioning of the two applications. This application results in a large codebase that includes the operating system, communication stacks, AI frameworks, etc, and also requires frequent updates. These factors make it hard to verify or certify the security of the released software.