# Secure Partitioning of Cloud Applications, with Cost Look-Ahead
## 1 Introduction
We do not consider other sophisticated mechanisms offered, such as the timed scheduling of domains. Given that our discussion is not dependent on the hardware that isolates the domains, in the rest of our article we refer to SKs as the supporting technology that comprehends TEEs and other similar mechanisms. To effectively adopt these technologies, developers must face several design choices. Deciding which components must be grouped together is particularly important and challenging. Developers must solve the problem of _how to partition their applications_, i.e., how to separate the software components of the application to be placed in different SKs' domains. Our ultimate objective is to avoid potential data leaks after the deployment phase by exploiting applications' information flow. Indeed, there is a research gap in addressing this problem. There exist information-flow security methods to address complementary problems, such as checking the correct labelling of software or monitoring the inputs and storage accesses by the applications. Other proposals rely on specialised hardware to tackle unreliable Cloud providers. As far as we know, however, there is no work that employs both aspects (viz., information-flow security and SK protection mechanisms in the Cloud) aiming at supporting the deployment of Cloud applications on specialised hardware such as SKs. In our previous work [16], we presented a methodology to determine a (minimal) eligible partitioning of an application onto an SK. Namely, [16] presents:  
* a declarative model to represent multi-component applications, exploiting information-flow security to check whether components can manage their data without leaks, and
* a (formal) definition of safely partitionable applications and eligible partitioning, also considering the performance cost of exploiting SKs and the cost of migratingsoftware, prototyped in \(\mathsf{SKnife}\) (Open-sourced at: [[https://github.com/di-unipi-socc/sk](https://github.com/di-unipi-socc/sk)]([https://github.com/di-unipi-socc/sk](https://github.com/di-unipi-socc/sk)), accessed on 20 June 2023). In this article, we extend (\(a\)) and (\(b\)), with the following original contributions:  
* the sketch of the proof that the partitioning determined by \(\mathsf{SKnife}\) is minimal and unique,
* a cost model based on the probability of deployment migration, which depends on user-defined parameters, viz., the upper limit of SK domains and the number of admitted changes in data secrecy and components' trust,
* a novel (Prolog and Python) prototype, \(\mathsf{ProbSKnife}\) (open-sourced at: [[https://github.com/di-unipi-socc/ProbSKnife](https://github.com/di-unipi-socc/ProbSKnife)]([https://github.com/di-unipi-socc/ProbSKnife](https://github.com/di-unipi-socc/ProbSKnife)), accessed on 20 June 2023), that exploits \(\mathsf{SKnife}\) to determine the eligible partitionings and implements the above probabilistic cost model to support the decision-making related to the initial deployment of the application, and
* the experimental assessment of \(\mathsf{ProbSKnife}\) considering the execution times, future costs and probability of not finding a safely partitionable application at varying input parameters. The goal of our methodology is to support the decision-making of application operators for the deployment of their applications in Cloud settings where the infrastructure provider is considered not trusted, by exploiting the SK technology. Our prototype tool is able to determine the deployment using the minimum number of domains, e.g., with the lowest SK performance impact, or to recommend different solutions considering the trade-off between the number of domains and costs of future re-deployments. The rest of this article is organised as follows. Section 2 deeply analyses the related literature. Section 3 introduces essential notions to prepare the ground for our methodology and a realistic motivating example. Section 4 describes our declarative modelling of multi-component applications and information-flow methods.