Towards a GDPR-compliant cloud architecture with data privacy controlled through sticky policies

Literature review

In this section, we delve into the existing literature. We categorize our discussion into three main areas: works focused on modeling and validation of the GDPR and data privacy, works dedicated to the GDPR and cloud computing, and works centered around data tracking and the GDPR. Each subsection provides insights into relevant studies, methodologies, and advancements in these specific domains, laying the foundations for our novel contributions.

The General Data Protection Regulation (GDPR)

The General Data Protection Regulation (GDPR) (General Data Protection Regulation (EU GDPR), 2016) came into force on May 25, 2018, as a way to harmonize data protection rules within EU member states. The GDPR was adopted in 2016 to replace the Data Protection Directive, which was born in 1995 out of a need to align data protection standards within its EU member states to facilitate internal and cross-border EU data transfer.

The GDPR is a regulation, which means that it applies directly to its recipients, and no further transpositions are required, as in the case of the Data Protection Directive. In addition to equalizing the data protection rules, the GDPR was introduced to generate greater legal certainty and eliminate potential obstacles to the free flow of personal data, raising the bar for the privacy of the affected persons.

The GDPR applies to any processing of personal data (or personal data sets), whether the processing is carried out, in whole or in part, by automated means (General Data Protection Regulation (EU GDPR), 2016). Anyone who processes or controls the processing of personal data is subject to the GDPR. There are different actors in the GDPR: data subjects, who are the people whose data is processed (for example, customers or site visitors); controllers, which can be a natural or legal person, public authority, agency, or other body that determines the purposes and means of the processing of personal data; and processors, who are a natural or legal person, public authority, agency, or other body that processes personal data on behalf of the controller. The data can be processed within its organization (that is, the controller and the processor are the same) or delegated to an external organization.

Any individual benefits from the GDPR, which also provides specific protection to minors. In contrast, legal entities do not benefit from protection under the GDPR, regardless of their legal form. The GDPR applies when the processing of personal data takes place within the EU or it involves data obtained form European citizens outside of the EU.

There are various implications of the GDPR for organizations and entities (European Comission, 2016). One of the most relevant implications is fair data processing, which means that organizations and entities must process personal data in a legal, fair, and transparent manner. In addition, they must demonstrate that they are GDPR-compliant (accountability) and put in place the necessary technical and organizational measures to guarantee the protection of personal data. The GDPR also establishes the purpose limitation, which means that personal data is collected for specified, explicit, and legitimate purposes and that no further processing is performed in a manner incompatible with those purposes.

The GDPR incorporates a systems engineering approach called privacy by design. This approach is based on seven fundamental principles that aim to proactively integrate data protection into the design of new products and systems. These principles are as follows (Langheinrich, 2001; Cavoukian, 2009): (i) proactive not reactive; preventive, not remedial; (ii) privacy as the default setting; (iii) privacy embedded into the design; (iv) full functionality—positive-sum, not zero-sum; (v) end-to-end security—full life-cycle protection; (vi) visibility and transparency—keep it open; (vii) respect for user privacy—keep it user-centric.

In the event of a data breach, organizations and entities under the GDPR must inform the data protection authorities within the next 72 h after they become aware of the personal data breach, and inform their users promptly. Infractions of different types (less serious or serious) are applied to organizations and entities if the notification is not made on time or the data breach was caused by the negligence of the controller or the processor of personal data.

Another important aspect of the GDPR is the empowerment of data subjects with certain rights to help data subjects in being assured of the protection and privacy of their personal data (General Data Protection Regulation (EU GDPR), 2016). These data subject rights are as follows: right to information, right of access, right to rectification, right to erasure, right to restriction of processing, right to data portability, right to object, and the right to avoid automated decision-making.

Sticky policies

A sticky policy defines a set of conditions and restrictions attached to data that describe how the data should be treated or, where applicable, transmitted between parties (Pearson & Casassa-Mont, 2011). The use of sticky policies facilitates compliance with, and the application of, data policy requirements, since it allows strict control of the data life-cycle in order to guarantee its privacy and the application of specific regulations on the use, access, and disclosure of personal data.

Sticky policies enhance data owners’ control over their data. In particular, machine-readable policies are directly attached to the data, and they are called sticky since they travel along with the data as it travels across multiple administrative domains. These policies make it possible to regulate how data can be accessed and used throughout its life cycle, helping to ensure that access control decisions and policy applications can be carried out in a distributed manner.

This paradigm was initially proposed by Karjoth, Schunter & Waidner (2002) to formalize applicable regulations and associate them with collected data, thereby supporting the identification of applicable regulations and privacy expectations for all personal data in a company. Pearson and Mont were early adopters of sticky policies in the context of the EnCoRe project (Pearson & Casassa-Mont, 2011), which provided mechanisms for users to define and change consent policies, as well as to enforce these policies throughout the entire data life-cycle.

Among other things, a sticky policy can define who owns the data, the content of the data (it may be encrypted), the use to be made of the data (e.g., for statistical analysis, transaction processing, targeted marketing), who can access the data, the maximum duration of the data, as well as other specific obligations and restrictions for the parties involved.

Unified Modeling Language (UML) sequence diagrams and combined fragments, UML profiles, and the object constraint language (OCL)

The Unified Modeling Language (UML) (Object Management Group (OMG), 2017) is a modeling graphical language commonly used in the industry for specification, design, visualization, and documentation of software systems. UML includes several diagram notations for modeling different aspects of software systems, addressing its structural, behavioral, and deployment aspects.

A UML sequence diagram (UML-SD) is a behavioral diagram of the software system that illustrates the sequence of messages passed between system participants (users or system elements) in an interaction. Therefore, a sequence diagram consists of a group of entities or roles that interact in a system, represented by vertical lifelines, and horizontal arrows that represent the messages that they exchange during the interaction over time. In a UML sequence diagram, a lifeline represents an individual participant, object, or entity involved in an interaction or collaboration. It is depicted as a vertical dotted line, headed by a rectangle or cube with the name of the object it represents, and it is used to show the chronological order of interactions between objects in the system.

In a UML-SD, a combined fragment reflects one or more aspects of interaction (called interaction operands) controlled by an interaction operator. The combined fragments are represented by a rectangle and contain the conditional structures that affect the flow of messages (the interaction operands). A combined fragment separates the contained interaction operands with a dashed horizontal line between each operator.

The combined fragment type is determined by the interaction operator. For instance, the operator loop allows the software designers to express interaction loops, while the operator alt allows them to express alternative flows of messages. The operator opt allows the modeling of an if-then structure. Finally, a combined fragment can also contain nested combined fragments or interaction uses (operator ref), whose main goal is to reference other interactions in a UML sequence diagram, and they make it possible to simplify large and complex sequence diagrams.

UML can be adapted for analysis purposes through profiles, by using a UML tool called UML profiling. A UML profile is an extension of the UML standard language with specific elements that correspond to the same domain. For instance, the MARTE (Object Management Group (OMG), 2011) profile has enabled UML to specify and analyze embedded and real-time systems. Likewise, the performance and schedulability sub-profiles of MARTE have proved useful for the modeling and analysis of a wide range of application domains, apart from real-time systems.

The Object Constraint Language (OCL) is part of the UML set of modeling notations (Warmer & Kleppe, 2003). OCL provides a precise textual language for model validation by expressing constraints that cannot be shown diagrammatically in UML. For instance, OCL constraints can be used to specify that a certain attribute must be unique within a class, or that a method must only be called if a particular precondition is met.

By using OCL, software developers can describe constraints and expressions on UML models that must hold on to the UML model elements. In practice, OCL constraints are often used to complement the UML modeling process, as they can help identify potential bugs early in the development cycle. When validating a UML model using OCL, it is possible to catch errors or inconsistencies in the model and correct them before the implementation phase begins, thus improving the quality of the resulting software system. Hence, OCL is a powerful tool for validating UML models and ensuring their correctness and completeness (Oestereich, 2002; Völter et al., 2006).

Stateless machines

Stateless machines (Sbarski & Kroonenburg, 2017; Villamizar et al., 2016) are software components or systems that operate without maintaining session state information for individual users or clients. They rely on external sources to obtain necessary state information and comply with rigorous security measures to ensure data reliability and integrity. In short, when a state machine is launched, it loads data from a data store, and computes some results which are then stored or sent back to the data processing pipeline. Lambdas AWS (https://aws.amazon.com/lambda/) is an example of such a computational model.

Stateless machines play a crucial role in contemporary software design, providing several advantages in scalability, fault tolerance, performance, and streamlining system deployment and maintenance. In the context of GDPR compliance, they help improve security by mitigating the risks associated with data leakage and unauthorized access that can arise from storing user session data. Its importance is particularly pronounced in distributed and cloud-based systems, where reliability and efficiency are paramount attributes. Maintaining meticulous design principles and implementing robust security practices is imperative to ensuring the trustworthiness of external state information. Stateless machines present compelling benefits particularly in industries where secure data management is of utmost importance, such as banking.

Initial sticky policies

We consider five main fields in the sticky policies: permission, owner, purpose, controller, and accessHistory. The permission field defines the access to the data. Permissions are defined as DC labels (Stefan et al., 2012), which are tuples $⟨$S, I $⟩$ where S and I are conjunctive normal forms on entities without negative literals. S specifies the entities whose consent is required to access the data, while I specifies the entities that have created the data and may modify it. A more detailed explanation is given in “Combination and Data Aggregation”.

The owner field defines the owner of the data, while the purpose field defines a list of possible access purposes (in this running example, statistical or tax purposes, as explained above). The controller defines the data controller according to the GDPR, in this case it will be the cloud provider. Finally, the accessHistory field allows us to track this data, that is, save all the entities that have accessed the data and the purpose of the access.

The sticky policies for the different data used in this example are as follows. For the data of the interested party, data subject (DS) or user:

DS_SP = {

  {permission: $⟨$DS,DS $⟩$},

  {owner: DS},

  {purpose: taxes, statistical},

  {controller: ControllerCP},

  {accessHistory:

   [(SB, statistical, read),

   (ING, statistical, read)]}

}

Therefore, DS is the only one that can grant access to the data and can also write the data. The owner of this data is the DS. The list of purposes has two types: statistical and tax. Finally, the accessHistory field allows us to track this data. We assume two new entities (SB and ING), representing banks. These entities are allowed to read the data for statistical purposes.

As can be seen, GestF does not have permission to access the DS data in the initial sticky policy, so it needs to request consent from the controller, who in turn will ask the data subject (DS) for consent. As shown in Fig. 1, consent is given to GestF to read the data from DS, who first reads the data. Therefore, the access history in the DS data must be updated to reflect this access:

DS_SP = {

  {permission: $⟨$DS,DS $⟩$},

  {owner: DS},

  {purpose: taxes, statistical},

  {controller: ControllerCP},

  {accessHistory:

   [(SB, statistical, read),

   (ING, statistical, read),

   (GestF, taxes, read),

   (GestF, statistical, read)]}

}

Likewise, GestF data has the following sticky policy:

GestFDataSP = {

  {permission: $⟨$GestF,GestF $⟩$},

  {owner: GestF},

  {purpose: taxes, statistical},

  {controller: ControllerCP},

  {accessHistory: []}

}

This sticky policy means that GestF must grant access to the data and can write its data, the owner is GestF, and the list of purposes has both types: statistical and tax purposes. Unlike before, the accessHistory field is empty, which means that no one has accessed GestF’s data yet. Eventually, GestF calculates the DS’ taxes and stores them for 30 days (writeData(DataSubjectTaxes, 30 days) message). This creates new data whose sticky policy is a combination of data from GestF and data from DS.

Final sticky policies

The final sticky policies obtained for the new data generated because of the behavior shown in Fig. 1 depend on purpose of the access (note that the controller remains the same):

• • Statistical purpose. In this scenario, GestF executes a statistical application in the cloud to compute the average salary for its employees (in this example, DS and DS1). As GestF already possesses statistical access to DS’s data, the controller is not required to seek the user’s permission for access. The application runs on a trusted machine, as detailed earlier. Following the computation, the anonymized aggregated data is generated and written to the storage machine (writeData(averageSalary, 30 days) message) with the ensuing sticky policy:

• averageSalarySP={

•   {permission: $⟨$GestF,GestF $⟩$},

•   {owner: GestF},

•   {purpose: statistical},

•   {controller: ControllerCP},

•   {accessHistory: []}

• As can be seen, the sticky policy of the new data is different since we consider that in the statistical case the owner of the new combined data is the one who generates this new data (in this case, GestF), and then decides on its permissions. Here, the purpose is statistical only, and the accessHistory only considers the access of GestF, since this data will be used solely in the interest of GestF.

• • Tax purpose. In this case, the GestF is running a tax application on a regular cloud machine and combining its data with the data from DS ( $SPGestF\bigsqcup DS\mathrm{\_}SP$) to calculate the DS’s taxes (DSTaxesSP), where the operator $\bigsqcup$ is $\wedge$ for the entities required to give consent for read operations, and $\bigsqcup$ is $\vee$ for write operations. So, the new sticky policy for the new data (tax data) is as follows:

• DSTaxesSP=

•   {permission: $⟨$DS $\wedge$GestF,DS $\vee$GestF $⟩$},

•   {owner: DS $\wedge$ GestF},

•    {purpose:taxes, statistical},

•    {controller: ControllerCP},

•   {accessHistory: []}

• Note that, for tax purposes, each field is generated according to the following rules:

  • – The permission field is obtained from the most restrictive combination of the permissions of GestF and DS. That is, the DS_SP permissions are $⟨$DS, DS $⟩$, while the Gest SP permissions are $⟨$GestF, GestF $⟩$. Therefore, the resulting permission is: $⟨$DS, DS $⟩$ $\bigsqcup$ $⟨$ GestF, GestF $⟩$ = $⟨$DS $\wedge$ GestF, DS $\vee$ GestF $⟩$.

  • – The owner field contains all the owners of the combined data; in this case, DS and GestF.

  • – The accessHistory is empty because it is new data, and no one has requested access to it yet.

Interaction model

This section describes the UML sequence diagrams that model the interaction between the different roles in our proposed stateless cloud architecture. Regarding the roles, we have defined the following: the user (also called data subject), the ControllerCP² (controller), the stateless computer applications (StatelessAppTP³ ), which want access to the data, and finally, the SSMProcessor⁴ (processor), which is the machine on which the data is stored.

User data is considered sensitive information to be stored and processed in the system. Therefore, ControllerCP is responsible for implementing appropriate technical and organizational measures to guarantee and be able to demonstrate secure access to data (Art. 24 and 25 GDPR (General Data Protection Regulation (EU GDPR), 2016)). It is then responsible for monitoring the application of GDPR to protect the fundamental rights and freedoms of natural users with respect to data processing, and for facilitating the free flow of sensitive data within the EU. The SSMProcessor is responsible for data processing (Article 28 GDPR; General Data Protection Regulation (EU GDPR), 2016). In this cloud environment, the stateless storage machine acts as the data processor, as it stores the data and is responsible for data processing. In accordance with Article 29 GDPR (General Data Protection Regulation (EU GDPR), 2016), the processor and any person acting under the authority of the controller or the processor, who has access to personal data, shall not process this data except on the instructions of the controller, unless required by the law of the Union or Member State.

Figures 3–6 show the interaction between the different roles using UML sequence diagrams.

Figure 3 shows the main sequence diagram, in which we capture the interactions of the different roles when a user interacts with the cloud system and sends personal data to it. As personal data, we also consider data of special categories (Article 9 GDPR (General Data Protection Regulation (EU GDPR), 2016)) or children’s data⁵ . However, in the proposed architecture we do not consider personal data relating to criminal convictions and offenses (Article 10 GDPR (General Data Protection Regulation (EU GDPR), 2016)). Initially, the user signs a contract (represented by the Sticky Policy (SP) message) with the controller to establish it as the controller of data processing and guarantee the principles relating to the processing of personal data (Article 5 GDPR (General Data Protection Regulation (EU GDPR), 2016)). This contract defines the fields of the sticky policy for the data, that is, the permissions, the owner, the purpose, the controller, and the accessHistory, with this last field being empty at the beginning.

The controller and the processor then also sign a Service Level Agreement (SLA message), which allows the specific storage machine to be set as the data processor and thus process personal data on behalf of the controller. This contract defines the maximum time during which data is stored on a machine and the third parties that can access data using the processingDuration, and recipients, respectively (see the class diagram in Appendix A). Hence, data will be stored and processed on that machine. These contracts are defined according to Article 13.2 GDPR (General Data Protection Regulation (EU GDPR), 2016). The GDPR specifies that the processing of data by a processor shall be governed by a contract (Article 28.3, Recital 44 and 109 GDPR (General Data Protection Regulation (EU GDPR), 2016)), where the processing period (maxTime parameter) is established, which is based on the defined processingDuration. After that, the user can transfer its data to the controller (sendData message).

Note that the associated sticky policy is a property of the data (see the class diagram in Appendix A), and from that moment on, the controller oversees and is responsible for controlling the processing of the data. The saving controller in SP action allows the controller to save its identity in the sticky policy by using the controller property. Then, considering Article 13.1 GDPR (General Data Protection Regulation (EU GDPR), 2016) (“the controller shall provide the data subject with some information”), the controller informs the user (info message) about the period for which data will be stored (maxTime), the third parties recipients, the identity, and the contact details of the controller (ControllerCP). Article 14 GDPR (General Data Protection Regulation (EU GDPR), 2016) defines what the controller must do when personal data has not been obtained from the data subject (for instance, from a different company). In this scenario, the data controller must inform the user and provide the same guarantees as before. Therefore, once the user is informed, the controller can store the user data on the storage machine (sendData message).

Subsequently, the controller enters a loop to handle the messages received in the system until the time to store the data expires (time ≤ maxTime condition) or the user orders the deletion of its data. For this purpose, a loop combined fragment is used to model the repetition of the interactions within it. Note that this combined fragment is inside a sequence diagram fragment called sd main. This is an interaction use in UML and allows us to reference it from other diagrams by simply using the label ref together with the name of the fragment (e.g., ref main in this case). Therefore, note that the sd main combined fragment can also end when the deletion of the data is ordered by the user, after which the data controller orders the processor to erase the data subject data and any of its copies (message eraseData), in accordance with Article 28.3.g GDPR (General Data Protection Regulation (EU GDPR), 2016). If this happens, the processor acts by removing Data & copies (at the bottom of this main SD-diagram) and the controller acts by removing SP in Log and removing the corresponding data from the log (self-message removeDatainLog).

The alt combined fragment inside the loop allows us to model the occurrence of different events that can occur in the system. The first event (first part of the alt combined fragment) occurs when the user wants to add new restrictions to its data policy (the user wants to add new restrictions condition). This event allows the user (data subject), for instance, to withdraw consent to third parties at any moment, that is, to change their access permissions in accordance with Article 7.3 GDPR (General Data Protection Regulation (EU GDPR), 2016). The message newRestrictions containing its data (Data) and the new restrictions (newSP) is set. The newSP parameter is of type StickyPolicy, and describes a list of third parties with their associated permissions (permission field) as an array of elements of type PermissionPerTP, which are (S, I) pairs, where both S and I are a list of lists of TPs (Third Parties, defined by StatelessAppCTP), and S defines who is authorized to grant permissions for data access, and I the third parties with writing permission over the data (see “Combination and Data Aggregation” and Appendix A). The controller then saves these new constraints to the log (saving new SP in log action). Therefore, these new data restrictions must be updated on all the machines that store the data. To do this, the update message is sent to the SSMProcessor roles with the Data, machines, and newSP parameters, to specify the data, the machines where these are stored, and the new sticky policy, respectively.

The second event (second part of the alt combined fragment) corresponds to the user’s right to rectify inaccurate personal data via the data controller without undue delay, Article 16 GDPR (General Data Protection Regulation (EU GDPR), 2016) (the User wants to rectify Data condition). The user sends the message rectifyData to the ControllerCP, with two parameters, namely Data and newData, corresponding to the old and new data, respectively. The data must be updated on all the machines where it is stored. To do this, a new message is sent to all the storage machines (SSMProcessor) that contain the data to inform them about the data rectification (message newData), with these three parameters: Data, machines, and newData.

Article 17 GDPR (General Data Protection Regulation (EU GDPR), 2016) regulates the user’s right to delete its data (the User wants to remove Data condition of the alt). Therefore, the third event (third part of the alt combined fragment) occurs when the user orders the removal of its data, sending the message removeData, which contains the data (Data) to be removed. After that, the controller searches for all the possible machines in the log that store the data to erase them (Seaching Data Ubications action) and updates the log by deleting all entries with the deleted information (represented by the recursive self-message removeSPinLog). After that, an eraseData message is sent to the corresponding processors, with the Data and machines parameters, to indicate the data to be deleted and the SSMProcessors that store it, respectively. Note that these interactions are within a break combined fragment, which allows us to model that once the data has been eliminated, the execution leaves the loop⁷ . Let us remark that the user is the only entity authorized to eliminate its data, so we do not consider a special type of permission for this purpose.

Another possible event occurs when a StatelessAppCTP, that is, a third-party (TP), wants to access the user’s data (the TP wants to access Data condition; fourth part of the alt combined fragment). As Fig. 3 shows, the interaction use called accessing_Data is executed. This interaction use shows the implementation of the interactions between the roles from the system to access the user’s data (see Fig. 4). As can be seen in this figure, the TP that wanted to access the data must request the user’s consent by sending a consent message to the controller, as per Article 6 GDPR (General Data Protection Regulation (EU GDPR), 2016). The parameters of the consent message are the data to be accessed (Data), the purpose for which the TP wants to access the user’s data (purpose), and the action to be performed on them (action, of ActionType type, see Fig. 4). In response to this message, the controller requests the TP to identify itself with the askAuthentification message. Then, the TP sends its identity in the tp message. Once the controller receives the identification of the TP, it verifies its permissions in the SP associated with this data. If the TP has no permission to access the data, the controller sends a consent message to the user. Now, the user has the right to object (Article 21 GDPR (General Data Protection Regulation (EU GDPR), 2016)). This behavior is represented in the second part of the alt [User consents] and equates to doing nothing. This situation also covers Article 22 GDPR (General Data Protection Regulation (EU GDPR), 2016) (that is, the user has the right not to be subject to decisions coming only from automatization—including profiling). Otherwise, the condition [User consents] is fulfilled, and the ok message is sent with three parameters: tp, purpose and ActionType, corresponding to the identification of the TP, the purpose for which the data is accessed, and the type of permission to access, respectively. Then, the controller updates its log, adding the information about this new access (adding access information in AccessLog action), including a new record on it, and sends the permission to the TP (permission message), in accordance with Article 7 GDPR (General Data Protection Regulation (EU GDPR), 2016). Therefore, the loop combined fragment is executed if the condition [tp has permission or User consents] is fulfilled, that is, the TP had permission or the user has accepted. This structure is used to model the repetition of TP operations (read, write, and combine) on the specified data.

TP operations are of ActionType type (see the figures in Appendix A), i.e., the TP can read data (readData message) or write data (writeData message) (see Fig. 4). However, the TP can also combine several sets of read data. Then, the corresponding part of the alt combined fragment will be executed, depending on the action that the TP wishes to perform:

• If the TP wants to read, the first part of alt ([TP wants to read and has permission for reading] condition) is executed. If the TP wants to read, and since it has obtained consent, then the readData message is sent to the SSMProcessor to read the data.

• If the TP wants to write, the second part of alt is executed ([TP wants to write and has permission for writing] condition). In this case, the writeData message, which has the new data content as parameter (content parameter), is sent from the TP to the SSMProcessor to write the data and it allows the TP to overwrite the data with that content. The maxTime is 0 since the storage time is unchanged.

• Finally, if TP wants to combine several data, the third part of alt is executed ([TP wants to combine and has permission for reading and writing] condition). In this case, the alt[purpose==statistical] allows us to model the two different behaviors depending on the purpose of access.

  1. If the purpose contributes to statistics on customers or the population (statistical purpose), the first part of alt (condition [purpose==statistical]) is executed. In this case, a readData message is used to read the data. Then, the TP acts by calculating aggregated newData and newSP in trustedM. This action allows the TP to perform a statistical operation on the data⁸ , which are being held on a trusted machine dedicated to this purpose in our cloud architecture. Later, a writeData message allows the TP to write the new data in the storage (newData parameter for maxTime period, which is aggregated data). In this case, the new data is owned by the TP, which makes decisions on it.

  2. If the purpose is not statistical (for instance, tax returns), once the TP has read the data (readData message), it acts by combining Data and calculating newData and newSP. This action is run on a non-reliable cloud machine. Later, a writeData message allows the TP to write the new data (newData parameter for maxTime period of time). Finally, the interaction use main is executed to manage the newly generated data.

“Combination and Data Aggregation” explains in detail how the new SP is generated (calculating newSP) when data aggregation or combination of the data is performed.

Then, the accessHistory field of the new SP is adapted to include the data access information (updating accessHistory of SP action). The controller acts by updating SP in log to modify the corresponding SP in the log, in the accessHistory field. Finally, in accordance with Article 12 GDPR, the user is informed of the data accessed through the message accessinformation.

The following event in Fig. 3 occurs when the controller (ControlerCP) wants to know about changes to the user’s data, modeled by the fifth part of the alt structure (the ControllerCP wants to subscribe to notification of breaches condition; Article 34 GDPR). Thus, the controller subscribes to receive notifications when data breaches occur. For this purpose, the interaction use (subscription ref frame) is executed.

Figure 5 shows this interaction use. The controller can subscribe to notification of any changes detected by the processor through the use of the subscribe message, which allows control of data changes at any time. This message has four parameters: Data, the machines the controller wants to control (machines parameter), the violations detected (breaches parameter), and the maximum subscription time (MaxSubscriptionTime parameter). This maximum time is set by the GDPR at 72 h, in accordance with Article 33, in which the data controller must notify the violation of personal data to the competent supervisory authority in accordance with Article 55, unless it is unlikely that the violation of personal data poses a risk to rights and freedoms of data subjects. The breaches parameter is an array of (Data, TP, actionType, newData, newlocation). In the event of a breach (alt [breaches]), the controller receives a notification message (notify message). This message has three parameters: Data, machines and breaches. Subsequently, the controller checks whether changes to the data have been logged in the log (check changes action), and has 72 h to inform the user, represented by the informBreaches message. If during the maximum subscription time (MaxSubscriptionTime) any changes or breaches are not detected, the timeoutSuscription message is sent to the controller from the processor. This process allows the controller to audit any changes that occur by verifying the information included in its log.

The last event occurs when the user requests information about the handling of its data, in accordance with Article 15 GDPR. This corresponds to the last part of the alt in Fig. 3 (the User wants information about the data management condition). In this case, the interaction use called infoDataUser is executed (see Fig. 6). According to the GDPR, the first time the user requests information about the processing of its data, it will be provided free of charge. However, if further copies are requested, a reasonable fee reflecting administrative costs should be required. We model this behavior as follows. First, a counter named counterUser is defined and initialized to zero. Then, a loop structure is included to model the possible repetitive behavior of the user when requesting this information. The message askDataInformation from the user to the controller models this request. The controller then performs the counterUser++ & checkUserId action to increase the value of counterUser and search for this user’s information. Subsequently, the alt combined fragment with the User verified and counterUser > 1 condition allows the execution of the first part to inform the user that they have to pay a fee, represented by the informationNotForFree message with the parameter price. Therefore, the user can decide whether to pay and receive the information (wantToAccess message). In this case, the opt[User wantToAccess] is executed and the controller generates the report in less than 30 days (generateReport, <30 days action), and sends the reportDataManagement message to the user. However, if this is the first time the user has requested the information (counterUser == 1 condition), the controller generates the report within those 30 days and sends the information for free, with the reportDataManagementforFree message to the user.

Combination and data aggregation

At this point, we provide details about the rules applied in the data combination operation, which are inspired by the ideas presented in Stefan et al. (2012). Permissions are DC labels: tuples of the form $⟨$S, I $⟩$, where S and I are conjunctive normal forms on entities without negative literals. S represents entities whose permission is required to grant access to the data, while I represents the entities that have full access to the data. DC labels have a can-flow-to relation $⊑$ defined as:

$$\frac{S_1\to S_2,I_1\to I_2}{⟨S_1,I_1⟩⊑⟨S_2,I_2⟩}$$

There are two operations defined on DC labels:

• $⟨S_1,I_1⟩\bigsqcup ⟨S_2,I_2⟩=⟨S_1\wedge S_2,I_1\vee I_2⟩$

• $⟨S_1,I_1⟩\sqcap ⟨S_2,I_2⟩=⟨S_1\vee S_2,I_1\wedge I_2⟩$

If we consider $\mathcal{D}$ to be the set of DC labels, then the pair ( $\mathcal{D}\mathcal{,}⊑$) forms a lattice:

when combining two DC labels, for instance $D{C}_1$ and $D{C}_2$, we must keep the less restrictive DC label stronger than both: $S{P}_1\bigsqcup S{P}_2$. For the sake of simplicity, we consider the combination of only two different data. However, it can easily be extended to combine more data. Then, we can define the combination operator of two DC labels $\mathrm{c}:\mathcal{D}\times \mathcal{D}\mapsto \mathcal{D}$, defined as $\mathrm{c}(D{C}_1,D{C}_2)=S{P}_1\bigsqcup S{P}_2$. We obtain $D{C}_1⊑\mathrm{c}(D{C}_1,D{C}_2)$ and $D{C}_2⊑\mathrm{c}(D{C}_1,D{C}_2)$. Let us illustrate this with an example.

However, when aggregating data, the aggregating entity must request permission from all the entities required by the DC label of each aggregated set of data. The entity then creates new data owned by the entity, aggregating the data. The historical field of the aggregated data should reflect this access. For instance:

Architectural model

For simplicity, in this section, we only present a summary of the model that defines the proposed cloud infrastructure. The complete detailed description is available in Appendix A. In previous works (Bernal et al., 2019; Cambronero et al., 2021), we have presented some aspects of the cloud infrastructure, but without considering data storage and management. In contrast, in this work, we focus on this aspect of the cloud, defining a GDPR-compliant architecture to manage the data of users who access the cloud. Hence, our architecture provides data privacy management, GDPR compliance, and data tracking. In particular, data privacy management and data tracking are provided through the use of sticky policies (see “Sticky Policies”). Similarly, GDPR compliance is validated using OCL rules (see “Validation of the Model4 DataCTrack Models”).

Figure 7 shows the stereotypes defined to model the main components of the cloud infrastructure. First, by extending the Component metaclass, the Infrastructure stereotype represents the cloud infrastructure together with the complementary services offered by the cloud provider. The stereotypes DataCenter, Rack, Machine, Hardware, and StatelessAppCTP also extend the Component metaclass. In this way, the cloud infrastructure consists of a set of data centers, which in turn are composed of a collection of racks (Rack). A rack belongs to two subtypes (StorageRack or ComputingRack), depending on the type of machine (Machine stereotype) it contains. In particular, the machine can be a stateless storage machine (SSMProcessor stereotype) or a stateless computing machine (StatelessComputationMachine stereotype), respectively. Therefore, a storage rack will be made up of several (storage) machines, and a computing rack by one or more computing machines. Note that a computing machine has two subtypes: it can either be a TrustedSCM or an UntrustedSCM. Trusted machines are served by controllers in our cloud architecture with the special purpose of statistical use (defined in “Running Example”) and store read-only data, whereas untrusted machines are accessible to anyone and can be used for other purposes, such as taxes or insurance calculation. The Hardware stereotype represents the components that any machine will have, and has three sub-stereotypes: CPU, Memory, and Storage. Finally, the StatelessAppCTP stereotype represents third-party applications seeking to access the data.

As mentioned, the cloud infrastructure is made up of several data centers, many of which have similar or identical configurations, as they are typically purchased in bulk. For this reason, the relationships between components are defined as associations between stereotypes. In Appendix A, these associations are illustrated graphically; they are also discussed in detail.

The definition of the stereotypes used for the interaction (Interaction Model) appears in Fig. 8. The User, ControllerCP, StatelessAppCTP, and SSMProcessor stereotypes extend the Lifeline metaclass. Also, there are the roles that interact in the cloud architecture (see Figs. 3–6). The stereotype User represents the data subject or user. The cloud service provider (ControllerCP) represents the user’s data controller, as explained earlier. The different third-party applications that access the data make up the StatelessAppCTP stereotype. And finally, the machines (SSMProcessor stereotype) represent the entities which will storage and process of the data, thereby becoming the data processors. Next, the StickyPolicy, Data, SLA, and AccessLog stereotypes extend the metaclass Component. These stereotypes represent the system components used for data representation and control. Finally, all the messages exchanged in the interaction extend the Message metaclass.

Appendix A shows the attributes and relationships between interaction stereotypes as associations of stereotypes. In this appendix, these attributes and relationships are fully described.

We should point out that the controller uses the log (AccessLog stereotype) to store information about all the data accesses and changes to the SP associated with the data, which is made up of several fields of different types, as described in Appendix A. Table 3 summarizes this controller log structure. As can be seen, for each data access the following information is stored in a log record: TP, the third party accessing the data, of type StatelessAppCTP, tp for short; L1, the initial data Location (storage machine) of type Storage; SP1, the initial data Sticky Policy, of type Sticky Policy; O, the list of entities (third parties or users) granting permission to access the data, of type PList; Action, the action performed on the data, of type ActionType; NL, the New Location of the data, of type Storage; and finally, NSP, of Sticky Policy type, which stores the New Sticky Policy, in case of changes to the initial sticky policy.

Validation of the Model4_DataCTrack models

To facilitate the validation process, we have established a set of OCL rules (Object Management Group (OMG), 2014), which can be found in Appendix B, encompassing the complete collection of OCL rules.

These rules have been categorized into two distinct groups. The first group, known as the structural rules, primarily focuses on the conventional relationships between stereotypes and their corresponding properties. Appendix A provides a comprehensive description of these constraints. Table 4 presents the most noteworthy examples.

Rule STR-1 validates that the set of data included in an instance of the upDate message (self.data) is present in all machines to which the message is destined. This is accomplished by verifying that the list of data sets stored in each machine (m.storage.data) includes the data from the message, for all machines in the destination machines list of this message (self.machines).

Rule STR-2 checks whether the new processor mentioned in any AccessLog of the controller, where the data has been copied to, is also under the Service Level Agreement (SLA) with the controller of this data. To achieve this, the controller’s log list (self.accesslog) is examined to validate the existence of an SLA in the controller’s SLA list (self.sla) that is included in the SLA list of the newLocation machine in the log (log.newLocation.sla).

Rule STR-3 ensures that the data introduced in any instance of a rectify message does not violate the data accuracy principle of the General Data Protection Regulation (GDPR) by containing empty fields. For this purpose, it is verified that all fields in the newData attribute of the message (self.newData) have a size (number of characters in the string) greater than 0.

The second group comprises rules that pertain to the specific restrictions imposed by the GDPR. Given the significance of these rules in the context of this article, we will now give a more detailed explanation of the rules that we consider most relevant. Refer to Table 5 for a summary of these rules.

Rule GDPR-1 verifies that every machine in the list of machines to which an update message is intended has been assessed as compliant with GDPR standards by an authoritative GDPR entity. In other words, it ensures that the GDPRCompliance attribute for all these machines is set to true.

Rule GDPR-2 validates that within the accessHistory list of a given StickyPolicy, none of the recorded accesses have an associated purpose that is not included in the allowed set of purposes specified by the purpose attribute of that policy.

Rule GDPR-3 ensures that all third parties listed in the accessHistory field of a StickyPolicy possess the appropriate permissions defined for them within the permission list of that policy. Specifically, it examines the I field of the sticky policy’s permission field.

Rule GDPR-4 raises an error if a specific data access recorded in the controller’s log (AccessLog) does not have the corresponding access included in the accessHistory of the associated StickyPolicy. This rule examines the accessHistory list of the StickyPolicy to verify whether the access has been included.

Rule GDPR-5 checks that a third party cannot obtain permission to access the data without obtaining prior consent from the corresponding data subjects. This implies that the preceding consentInfo and ok messages have been sent with the same purpose and permission.

Threat model

In this section, we describe the threat model of a system to which our profile applies to provide a basis for understanding the potential risks and the corresponding safeguards to ensure the security of the described system.

Adversaries may attempt to gain illicit access to user data stored in the cloud. In this sense, strong authentication mechanisms must be employed, along with the need to obtain explicit consent from data subjects each time access is requested. Another critical threat involves data manipulation, where adversaries seek to manipulate user data within cloud infrastructure. Implementing strict controls and obtaining consent from data subjects whenever data is subject to modification can help overcome this threat.

Unauthorized disclosure of sensitive user information to third parties caused by privacy breaches is another possible threat. Mitigation strategies include strict compliance with GDPR guidelines, implementing sticky policies for fine-grained access control, and encrypting sensitive data to safeguard privacy. In this regard, policy abuse is another privacy threat, requiring regular policy reviews, enforcement of access control, and continuous monitoring of policy violations. Likewise, inadequate logging and monitoring practices make it difficult to detect and respond to security incidents. Comprehensive logging mechanisms, real-time monitoring tools, and the establishment of incident response procedures are needed to adequately address security incidents.

Unauthorized access through compromised third parties is another concern. This can be overcome by regularly auditing third-party entities and their permissions, along with enforcing strict access controls. Finally, inadequate management of user consent can lead to unauthorized data processing. Implementing robust consent mechanisms, regular updates to consent preferences, and ensuring compliance with GDPR guidelines can help overcome this issue.

Considerations

Below is a list of some important considerations concerning our framework that we would like to highlight:

• 1) Support. The support of two experts in the GDPR has allowed us to design and develop our modeling framework.

• 2) Types of machines according to the purpose of data access. In our cloud architecture, we consider that the cloud provider offers two types of machines to process the data, depending on the purpose for which the data is accessed. The two types of purposes we consider are statistical and non-statistical. When the access is for statistical purposes, the processing is carried out on trusted machines, and the processor in charge of the treatment will be the owner of the new data. In this case, only third parties to whom the owner authorizes access to the data may access the data. These trusted machines are read-only, and when several of these data are combined for that statistical purpose, the new data will be aggregated data. However, when the purpose of access is not statistical, the processing is carried out on unreliable machines, and if several data sources are combined, the owners of the combined data will be the owners of the original data while the access permissions will be the most restrictive (see “Combination and Data Aggregation”).

• 3) EU or non-EU members. We propose a controlled cloud architecture in which the cloud provider works with machines that may or may not be in members of the EU, but all of them ensure an adequate level of protection according to the GDPR, Article 45. For this purpose, we have included the GDPRCompliance field in the SSMProcessor stereotype (see Appendix A). The value of this field is checked by OCL to ensure that machines acting as processors are GDPR compliant.

• 4) Consent. In our architecture, when a third party wants to access the data and does not have permission to do so, the user’s consent must be requested to authorize such access, as can be seen in Fig. 4. In this case, if the user consents to access, this third party will be included in the list of permissions on that data (indicating the type of permission granted) and will thus have access to the data.

• 5) Supervisory authorities. In this article, we do not explicitly model the supervisory authority as a role in the system as we consider it to be an element outside our cloud architecture. However, interactions with this supervisory authority are easy to include.

Validity threats

• Internal validity. A potential threat to internal validity is that we have interpreted the text of the GDPR provisions to create a cloud architecture. However, this is recommended for any company that operates in the cloud, whether inside or outside the EU, when these are companies that offer goods or services to people in the EU. In our case, this phase was carried out in collaboration with people with a good knowledge of the field (the authors of this work, who are experts in the GDPR) to minimize the threat posed by such a subjective interpretation. Of course, we cannot rule out subjectivity, but we do provide our interpretation accurately and explicitly. Furthermore, our model is publicly available.

• External validity. Our framework focuses on defining and validating a GDPR-compliant cloud architecture, which has been designed with input from legal experts in data protection. Therefore, this allows us a certain degree of confidence in the generalization of our results. However, future studies exemplifying our model in different cloud domains with their corresponding legal aspects will be critical in deciding the completeness and applicability of our framework in real-world scenarios.

The validation process allows us to verify inappropriate access or breaches of customer data confidentiality. Thus, we can conclude that certain recommendations be given to the entity responsible for data security (the controller) to define its architecture in the cloud. In this case, the data controller is the cloud provider, who is responsible for the data of the cloud’s customers and for third party access.