# Secure Partitioning of Cloud Applications, with Cost Look-Ahead
## 6 Partitioning with a Look Ahead on Migration Costs  
We mentioned before that reducing the number of domains corresponds to reducing the used resources and avoids degrading the performance. In this section, we want to consider another type of cost aside from the number of domains.  
Figure 4: Minimal safe partitioning.  
After the deployment of an application, changing the isolation of the components during the execution could bring unexpected costs, for example, the downtime of components that must be stopped and redeployed or the work time to change the explicit channels from intra-domain to extra-domain. Unfortunately, there are situations in which the labels of data or characteristics must be changed given the determined circumstances. Data labels can change due to new privacy regulations that can classify or declassify categories of data. Regarding the characteristics, an exploitable vulnerability of a library can be discovered that drastically reduces its trust. Then, the deployed partitioning could not be safe anymore with the changed labelling and the data confidentiality protected by the isolation is compromised. In those situations, the software must be migrated to different domains to preserve data confidentiality, at the cost of such a migration.  
For example, consider the motivating example deployed as per the safe partitioning calculated in Section 5.4. Assume that a bug in the TLS Library, a characteristic of the component Authenticator, is discovered. This event can reduce the library security label from top to medium, making this software component _untrusted_ and the partitioning not safe anymore. To avoid leaks of data, the application operator should calculate the new safe partitioning, stop the application (or at least the components that change domain), work on the communication code of the components that change domain and re-deploy the application. In Figure 5 we show the partitioning change from the starting partitioning \(P0\) to the final partitioning \(P1\), indicating the communication links of the Authenticator component. The downtime of the application and the work on the communication code are a cost for the application developer that can be predicted and optimised with the partitioning.  
What if the application was deployed with the partitioning \(P1\)_from the start_? This partitioning is not minimal with the initial labelling, but it is safe. The Authenticator component is isolated in a domain and from the point of view of a safe partitioning its labelling does not matter. What really changes from partitioning \(P0\) to \(P1\) are  
* the number of domains, four to five,
* the link connecting the Authenticator and the App Manager components, which is inter-domain in \(P0\) and extra-domain in \(P1\), and  
Figure 5: Partitioning change due to Authenticator labelling change.  
* the cost of changing the partitioning when the event of TLS library changes its label from top to another one; this cost is 50 in \(P0\) (given by summing the costs of Authenticator and App Manager) and 0 with \(P1\).  
Indeed, the partitioning \(P1\) is safe for both the starting labelling and for a labelling with the component Authenticator untrusted. Thus, with \(P1\) as the starting partitioning, the label change does not require stopping the application for changing the deployment and the cost of working on the communication links of Authenticator and the App Manager is 0.  
This analysis is on the basis of our refined cost model that captures the _future cost_ of migrating software components from one partitioning to another.