Modeling Data Sovereignty in Public Cloud—A Comparison of Existing Solutions

Abstract

Data sovereignty has emerged as a critical concern for enterprises, cloud service providers (hyperscalers), end-users, and policymakers at both national and international levels. In response, cloud-based distributed computing models have been proposed as frameworks to enforce data sovereignty requirements. This study aims to evaluate and enhance data sovereignty practices within public cloud environments. Through a comprehensive literature review, we analyze existing reference architectures and solutions that address data sovereignty, identifying the technological and economic constraints they impose, such as increased computational costs associated with specific frameworks and cryptographic measures. To address these challenges, we propose an abstract data sovereignty model designed to aid system designers and architects in developing compliant cloud-based systems. Additionally, we conduct computational experiments assessing the performance of the IDS connector, a key data sovereignty tool, deployed on the Google Cloud Platform and Microsoft Azure. Results reveal that while the geographic location of the software significantly impacts performance, the choice of cloud platform minimally influences the IDS connector’s efficiency. These findings offer insights into optimizing data sovereignty strategies for cloud solutions, with implications for future system design and policy development.

1. Introduction

Data sovereignty within public cloud infrastructure is a complex, multi-layered issue that requires thorough analysis and an understanding of its diverse components. This study builds on a systematic literature review to establish a foundational understanding for developing a data sovereignty model specific to public cloud environments. By examining reference architectures proposed by non-profit organizations, we aim to highlight the state of current frameworks and identify gaps in existing approaches. Additionally, we report on computational experiments designed to test a specific data sovereignty solution in practice.

Digital sovereignty, encompassing both data sovereignty and technological sovereignty, refers to the ability of organizations to control their digital assets independently. Data sovereignty, as a component of digital sovereignty, specifically addresses the control an organization maintains over its data, particularly in the context of cross-jurisdictional cloud services. Key drivers include industry-specific regulations, such as the Digital Operational Resilience Act (DORA) for the EU’s financial sector, as well as broader international data protection frameworks like the General Data Protection Regulation (GDPR). Beyond regulatory compliance, organizations increasingly recognize the necessity of safeguarding their digital assets to maintain autonomy and security in an interconnected digital landscape.

Achieving data sovereignty in public cloud environments requires the implementation of specific sovereignty controls, ranging from contractual obligations to enhanced monitoring of data operations. Although monitoring alone cannot secure data, it can provide accountability by tracking data usage and penalizing misuse. Effective data sovereignty measures are grounded in robust identity and access management (IAM) systems, which enforce sovereignty through secure authentication processes [1]. Cryptographic solutions, such as bring your own encryption (BYOE), also play a crucial role in enabling secure and compliant data handling in public cloud contexts.

Several approaches have been proposed to address data sovereignty within public cloud environments. Sovereign cloud offerings from providers such as Atos exemplify solutions that provide varied levels of sovereignty based on customer needs, spanning from privacy-shielding technologies for lower-security requirements to fully isolated cloud instances for sensitive data [2]. Other solutions, such as data spaces [3], enable standardized data ecosystems that facilitate secure data sharing across multiple parties, promoting data sovereignty through controlled access and exchange. Emerging Web 3.0 technologies also show promise, offering decentralized identity management and secure data exchange, which align with data sovereignty objectives [1].

Public cloud providers have developed managed services that extend their cloud platforms to on-premises environments, thereby broadening data sovereignty options. Notable examples include Google Distributed Cloud Edge, Amazon AWS Outposts, and Microsoft Azure Stack, each enabling organizations to integrate public cloud capabilities with their local infrastructure for enhanced control and sovereignty.

The systematic literature review conducted for this study reveals a notable gap in the current body of knowledge: existing models are often too closely tied to specific technologies, lacking a generalizable framework that describes the functional layers of data sovereignty applicable across various cloud platforms. To address this gap, we propose an abstract data sovereignty model that organizes the essential layers and functional components independently of technology, making it adaptable for a range of sovereign solutions within public cloud environments or extended to edge computing.

Beyond theoretical modeling, we designed and executed computational experiments to validate the practical application of this framework. Specifically, we tested the performance of the International Data Spaces Association (IDSA) data sovereignty solution across different cloud platforms, providing empirical evidence to support our model’s applicability and evaluating its effectiveness in real-world scenarios.

2. Literature Review

As a foundation for this study, a systematic literature review was conducted using a query in Web of Science with the keywords “Data Sovereignty” AND “Public Cloud,” which returned 11 literature items. Additionally, we included a 2023 State-of-the-Art (SoK) paper from the IEEE Symposium on Security and Privacy conference on Data Sovereignty [2] and information from the International Data Spaces Association [3]. References were also expanded based on the reviewer’s recommendations: [4,5,6,7,8].

The literature review reveals three primary perspectives on data sovereignty within the public cloud context: (1) legal aspects, particularly international regulations; (2) strategies for managing public and government data; and (3) technical solutions, ranging from experimental to mature production-ready tools.

(1)

Legal frameworks and their limitations:

The legal dimension of data sovereignty in the public cloud spans various jurisdictions, each with distinct regulatory approaches. Recent studies highlight several challenges:

−

International regulations and data transfers:

Studies focusing on China [9] illustrate regional complexities by comparing overseas data transfer laws in China, the EU, and the USA. However, these frameworks are limited by jurisdictional constraints, creating challenges for multinational organizations that require seamless data access across borders. The lack of global standardization can result in compliance risks and enforcement difficulties.

−

Regional data localization laws:

For instance, the EU’s ongoing efforts to govern data through projects aimed at cloud federation and standardization [10] underscore regional attempts to manage sovereignty. Yet, these efforts reveal gaps, as they may inadvertently restrict cross-border data flow, complicating data accessibility in globally distributed environments. Similarly, data localization laws in Russia [11] enforce strict national boundaries but face criticism for impeding economic exchange.

−

Historical context of privacy and sovereignty laws:

The Data Privacy Matrix (DPM) developed by New Zealand researchers [12] categorizes data privacy laws across major cloud-hosting nations. This resource reflects the inconsistency in data privacy and sovereignty laws globally, which can lead to conflicting legal obligations for cloud service providers and their clients. High-profile events like Edward Snowden’s 2013 revelations about the PRISM program have led to increased scrutiny of US-based cloud providers, raising sovereignty concerns for data stored within the USA.

The limitations in these legal frameworks demonstrate the need for cohesive, enforceable international standards that address the complexities of data sovereignty. Existing models are insufficient for managing the nuances of data jurisdiction in cloud environments, particularly as they often lack clear provisions for cross-border data governance.

(2)

Governance frameworks and public data management:

Research on governance frameworks reveals various national approaches to managing public and government data in the cloud:

−

Government cloud strategies and sovereignty:

In South Africa, studies explore government cloud migration readiness [13]. Challenges arise when attempting to balance sovereignty with efficiency, as on-premises systems are often outdated but shifting to the cloud risks foreign data control. Other studies [14] analyze the government data strategies of the USA, UK, and Australia, where regulations like the USA PATRIOT Act permit extensive access to data by authorities. This raises significant concerns over data control and sovereignty when using foreign cloud providers.

−

Cloud sovereignty projects in the EU:

European countries, through initiatives like GAIA-X [15], have launched sovereign cloud projects aimed at creating an ecosystem where data can be securely shared. However, these projects face obstacles in balancing openness and control, and the infrastructure is still in early stages, lacking a comprehensive governance model that supports consistent data sovereignty practices across borders.

These studies reveal that governance strategies are often reactive, addressing data sovereignty concerns only after challenges emerge. This reactive approach limits the development of proactive, flexible governance models that can adapt to changing cloud environments and multinational data-sharing needs.

(3)

Technical Frameworks and Practical Tools for Data Sovereignty:

The technical dimension of data sovereignty involves practical solutions to safeguard data in public cloud environments:

−

Data encryption and access control solutions:

Recent studies introduce proxy re-encryption technologies, such as ID-based proxy re-encryption (IBPRE) [16], designed to streamline data sharing without exposing decrypted information. This technology provides a layer of sovereignty but is constrained by computational requirements and the need for additional key management infrastructure.

−

Data partitioning and redundancy:

Systems like ARGUS [17], which partition encrypted data across multiple storage providers, add redundancy and security layers to cloud storage. However, while ARGUS enhances security, it does not fully address concerns over the control of data by third-party providers, nor does it provide robust geolocation assurances, which are critical in certain data sovereignty contexts.

−

Blockchain-based governance for cloud resources:

Platforms like CloudAgora [18] leverage the blockchain to create a distributed marketplace for cloud resources, supporting user control and transparency. However, the reliance on the blockchain brings scalability challenges and may not be practical for environments with high data volumes and rapid access needs.

−

Systematization of Knowledge (SoK) in data Sovereignty:

The comprehensive SoK article [1] categorizes data sovereignty mechanisms into layers like decentralized identity, access control, and policy-compliant computation, offering a conceptual foundation for Web 3.0 applications. Although promising, the interoperability limitations in Web 3.0 solutions, such as Decentralized Identifier (DID) systems, highlight gaps that limit their immediate application in large-scale public cloud settings.

These studies indicate that while technological advancements offer promising solutions, the tools are often experimental, resource intensive, and not yet suited for widespread deployment in public cloud environments. Further research is needed to enhance scalability and efficiency, providing stronger guarantees for data sovereignty in a global context.

The reviewed literature underscores significant gaps in existing frameworks for data sovereignty in the cloud. Legal frameworks lack consistent international standards, governance strategies are fragmented and reactive, and technical solutions remain limited in scalability and practicality. Current models are insufficient to address the unique challenges presented by data sovereignty in public cloud environments, where data jurisdiction issues intersect with complex legal, governance, and technical demands.

This study focuses on addressing gaps within technical frameworks by proposing an abstract, layered model for data sovereignty in public cloud environments.

3. Materials and Methods

In this study, a comparison of reference architectures was conducted using expert judgment and analytical modeling methods.

This paper selects and describes three mature, comprehensive solutions that are “production-ready” and already in use across multiple use cases.

As a result, an abstract data sovereignty model was developed. Subsequently, relevant experiments were designed to assess the performance of the Dataspace Connector software when hosted on two public cloud providers: Google Cloud Platform and Microsoft Azure. The present research represents the initial phase of this experimental study, with subsequent phases planned to incorporate the Amazon Web Services platform and Edge hosting.

The performance tests of the Dataspace Connector software (version 8.0.2) were executed using the Python script provided in Appendix A. For a detailed description of the testing environment, refer to Section 4.3, and consult Appendix A for specifics of the testing script. The resulting data were collected as CSV text files (output from the testing script) and stored in a GitHub repository for future reference. The results of experiments from this paper can be used to select the most efficient hosting option for the IDS connector. The research also serves as proof of concept that the Dataspace Connector can be hosted on Google Cloud Platform and Microsoft Azure cloud platforms.

4. Models and Computational Experiments

In this section, we present a comparison of three reference architectures, followed by the introduction of an abstract data sovereignty model. Finally, we describe the experiments we conducted.

4.1. Reference Architecture Comparison and Description

There are three non-profit organizations we have selected during research that develop reference architecture models for services supporting data sovereignty. These organizations are as follows:

−

International Data Spaces Association

−

Gaia-X

−

FIWARE

Each of these organizations has a slightly different goal:

−

IDSA creates international standards for data spaces;

−

Gaia-X is focused on data infrastructure for Europe;

−

FIWARE creates framework smart solutions.

The above organizations have been selected for comparison because they contribute significantly to research and development in the fields of data spaces and data sovereignty.

4.1.1. International Data Spaces (IDSA)

The Reference Architecture Model (RAM) [19] developed by IDSA, currently in version 4.2, released one year ago, describes the general concept and functionality needed to create secure network of trusted data. It uses a technology-agnostic approach and describes components from three perspectives: security, certification, and governance, and within five layers: business, functional, informational, process, and system.

The below diagram Figure 1 shows the interaction of functional components. The main component of the architecture allowing access to data spaces is IDS connector, which is used to provide or consume data endpoints. Data and metadata assets are exchanged between connectors. Applications from the App Store can be downloaded and executed on connectors. After successful contract negotiation, using the Clearing House service, the data can be provided by data provider connector and processed by an application executed on data consumer connector.

4.1.2. Gaia-X

On the other hand, the Gaia-X organization [20] is building federated secure data infrastructure for Europe, as Trust Framework described in an architecture document [21].

The Gaia-X organization describes its reference architecture Figure 2 using three planes: trust, management, and user. The ecosystem consists of federated services that allow data exchange between providers and consumers. Trust is ensured by using verifiable credentials, which are part of self-descriptions published by participants. Self-descriptions attached to service offerings can also contain usage policies which are described in machine readable form such as ODRL. Usage policies consist of rules which implement restrictions of data usage after granting access to data assets. This is a common concept with IDSA reference architecture.

4.1.3. FIWARE

The third reference architecture, Figure 3, has been designed by FIWARE—an organization focusing on building smart solutions that gather data from many different sources, such as IoT devices or third-party systems like weather service. FIWARE organization is developing a curated framework of open source platform components to accelerate the development of smart solutions [22,23].

There are hundreds of use cases implemented already using FIWARE framework in the domains of industry, agrifood, or cities. The central component here is the context broker using the NGSI API. This is a standard API that allows users to read or modify data, for example, from IoT devices like sensors using standard HTTP methods. The concept here is that smart solutions can communicate via standard API using a shared data space.

Additionally, there is cooperation between IDSA and FIWARE foundation on the implementation of IDS reference architecture using FIWARE technologies, where the FIWARE Context Broker component is placed inside the IDS connector.

4.2. Data Sovereignty Model

In this section, we present a data sovereignty model Figure 4 that is generalized from various reference architectures and implementations, e.g., three architectures presented above but also the model presented in paper [1]. Our contribution is the analysis and generalization of various models that group common concepts and divide functionality into corresponding layers. The data sovereignty model is divided into four logical layers: hardware, platform, data protocols, and distributed applications. These distinct layers group technologies and functions that enable data sovereignty.

The lowest layer comprises heterogeneous hardware components, including servers and devices of various sizes and physical locations. This foundational layer provides essential computational, storage, and network resources that support all upper layers. The second layer, known as the trusted infrastructure, is designed to implement trusted platform components that enforce policies, manage certificates, and handle other security measures. It establishes a secure foundation for the data exchange and application layers by integrating robust security features. The subsequent layer encompasses data exchange protocols, such as ODRL [24], NGSI-LD [25], and IDS usage control language, which enable standardized data exchange. This layer integrates international standards and common data models that are interoperable across diverse solutions and systems. Finally, the top layer consists of application frameworks, such as Hadoop, Spark, and Flink, which support distributed processing with data sovereignty enforcement. This layer represents the highest level of the stack, where the complete business logic of applications is implemented. Connectors span the top three layers, as they implement functionalities that belong to the platform, data protocols, and application layers.

Connectors represent a critical component of the data sovereignty model, as they integrate the three primary layers and enable the hosting of essential security and privacy features. An example of an implementation of the abstract connector component is the IDS connector. In the following chapter, we will discuss computational experiments conducted to evaluate the performance of the connector.

4.3. Experiments

The purpose of the experiment was to understand the impact of running Dataspace Connector software (version 8.0.2) on various public cloud platforms hosted in different geographic locations.

As discovered during the systematic literature review, designing and implementing data sovereignty in public cloud environments requires additional software layers, which increase computational complexity and cause additional performance impacts. This paper presents research results related to the performance of accessing data spaces designed for data sharing and exchange. We decided to perform an experiment comparing the performance of the Dataspace Connector.

The Dataspace Connector is an open-source implementation of the IDS connector [26]. A comprehensive list of IDS connector implementations is published monthly by the IDSA organization and is available on their website [27]. Currently, this list includes 38 implementations. The Dataspace Connector was selected for experimentation due to its high maturity level and open-source licensing. In the subsequent phase of experiments, we plan to include additional implementations of IDS connector components.

In this phase, we hosted the Dataspace Connector in two different public cloud environments: the Google Cloud Platform and Microsoft Azure. We selected two Dataspace Connector API endpoints (out of a total of 187) that create or retrieve catalog entities:

• GET/api/catalogs Get a list of base resources with pagination.
• POST/api/catalogs Create a base resource.

All available Dataspace Connector API endpoints are listed in Appendix B.

The Dataspace Connector has been executed on Docker runtime and HTTPS requests were sent to different endpoints hosted on virtual servers and response time was measured.

We used three virtual machines with similar configuration, hosted in Europe and US regions.

Detailed configuration was as follows:

• VM 1

  ○

  Platform: GCP Compute Engine

  ○

  VM size: 2 vCPU, 1 core, 8 GB memory

  ○

  Operating System: Debian GNU/Linux 12 (bookworm)

  ○

  Region: Europe Central 2—Warsaw, Poland

• VM 2

  ○

  Platform: GCP Compute Engine

  ○

  VM size: 2 vCPU, 1 core, 8 GB memory

  ○

  Operating System: Debian GNU/Linux 12 (bookworm)

  ○

  Region: US Central 1—Council Bluffs, Iowa

• VM 3

  ○

  Platform: Azure Virtual Machine

  ○

  VM size: 2 vCPU, 1 core, 8 GB memory

  ○

  Operating System: Debian 11 “Bullseye”—x64 Gen2

  ○

  Region: Europe—Poland Central—Warsaw

Test results are stored in a GitHub repository [28].

Table 1. Dataspace Connector response time, (*) average time for 100 requests.

Environment	GET *	POST *
Azure EU	211 [ms]	187 [ms]
Azure EU-local test (public IP)	105 [ms]	104 [ms]
Azure EU-local test (local IP)	99 [ms]	98 [ms]
GCP EU	190 [ms]	207 [ms]
GCP EU-local test (public IP)	154 [ms]	134 [ms]
GCP EU-local test (local IP)	133 [ms]	115 [ms]
GCP US	757 [ms]	635 [ms]
GCP US-local test (public IP)	125 [ms]	116 [ms]
GCP US-local test (local IP)	113 [ms]	103 [ms]

presents the average response times for GET and POST HTTPS requests sent to endpoints remotely and locally (from the same virtual machine). Tests have been repeated using local and public IPs.

To create catalog items, we used POST https://endpoint/api/catalogs requests, and to read catalog items, we used GET https://endpoint/api/catalogs requests with an initial catalog population of 100 catalog entries.

Figure 5 presents a visualization of response times for individual HTTP GET requests across three different cloud platforms.

Figure 6 presents a visualization of response times for individual HTTP POST requests across three different cloud platforms and Figure 7 visualizes statistical analysis of response times.

5. Discussion

Modeling data sovereignty architecture in public clouds is a complex task that involves analyzing existing models, taking into account available technologies, and identifying gaps in the abstract models and existing technologies. In this research, the technologies have been categorized into functional layers, which facilitates comparison and supports architects when designing new systems that enforce data sovereignty requirements. During the research, it was discovered that quite mature models already exist, many of which have been implemented as open-source software as well as commercial solutions. Data sovereignty solutions are often based on cryptographic methods to provide confidentiality, data exchange protocols to define data usage policies, and secure platforms to host the required infrastructure. The three reference architectures described in this research, designed by three organizations, have slightly different goals. However, they reuse common components, implemented as open-source software, and these organizations cooperate to ensure interoperability between different data spaces.

The model developed in this research builds upon the framework presented in [1]. It is more generic, as it does not rely on any specific technology, and offers greater granularity. Unlike the previous model, which compares complete solutions, this research focuses on the individual software components. The experiments conducted in this research aimed to prove that accessing the IDS data space is cloud agnostic, i.e., running gateway software (Dataspace Connector v. 8.0.2) is independent of cloud hosting infrastructure (e.g., Google Cloud Platform or Microsoft Azure), and the performance of the solution is acceptable across all tested deployments. Observations indicate that POST HTTP requests, in general, were faster than GET requests, likely due to the internal implementation specifics of the Dataspace Connector. Similar response times were measured for all virtual machines (VMs) when tests were run locally, averaging around 100 ms. When using a public IP address for local tests, the response times were slightly higher, by approximately 10 ms. Among the cloud platforms tested, Azure had the lowest response times for GET requests, while the Google Cloud Platform (GCP) had the lowest response times for POST requests. The longest response time was observed for a GCP VM hosted in the United States, at approximately 700 ms.

It is noteworthy that the experimental results are consistent with expectations, however, further work is needed to extend the experiments to include a third major public cloud provider: the Amazon Web Services platform.

6. Conclusions and Future Research Directions

The abstract data sovereignty model introduced in this paper aids in designing components that support data spaces by following a layered approach, which separates the purposes of different independent software building blocks. The experiments confirmed that the most significant factor affecting the performance of the Dataspace Connector is the geographical location of the virtual server (see Figure 3), rather than the cloud platform hosting it. Additionally, only minimal differences in the performance of GET and POST HTTPS requests were measured.

The experiments conducted in this research are limited to one implementation of the IDS connector, two HTTP endpoints, and two cloud service platforms. Future research steps could involve running the Dataspace Connector on edge devices, utilizing public cloud serverless managed services (e.g., GCP Cloud Run or Azure Container apps), and extending the test environment to include Amazon Web Services (AWS). Additional API endpoints can also be included in the test to perform actual data access, allowing the measurement of the time required for policy enforcement. We observed that the main impact on connector performance was related to geographical location, so future research could extend the list of locations. Since various cloud providers and edge devices may have different network connections, it is important to compare different connector hosting options.

The comprehensive set of experiments conducted on three major hyperscale cloud service providers, along with edge hosting options and testing several implementations of the connector service, will provide a more thorough understanding of the performance of data sovereignty solutions in the public cloud. It should be noted that conducting experiments in public cloud environments introduces additional complexity, which may impact results—particularly when measuring response times—due to factors such as network variability. To mitigate this risk and ensure reliable results, it is recommended to repeat tests at different times and locations. This approach also highlights a challenge for future experiments, as cloud providers host data centers in diverse geographical locations. However, future experiments can be designed to remotely initiate test scripts across various combinations of target virtual servers and test-triggering locations, enabling more robust and representative data collection.

The practical implications of this study for organizations influencing decision-making processes related to implementing data sovereignty solutions in public cloud environments are twofold. First, production-ready, off-the-shelf solutions are available, such as those developed by IDSA, FIWARE, and GAIA-X. Second, the abstract data sovereignty model introduced in this paper provides a framework for constructing customized solutions, allowing organizations to build systems from distinct components assembled within defined functional layers. As discussed in the literature review, different data sovereignty requirements necessitate distinct sovereignty solutions, which may range from privacy-shielding services on public cloud platforms to fully isolated private cloud solutions. Generally, practitioners and policymakers involved in data governance decisions should begin with an in-depth analysis of specific requirements. Based on this analysis, they can then assess whether any of the existing solutions presented in this paper meet all criteria, or if a completely new system must be designed using the abstract data sovereignty model outlined in Section 4.