Decentralized and Secure Access Control Model for Multi-Cloud Data Storage

It is important to understand a set of concepts related to the proposed system before exploring the other aspects.

2.1 Cloud computing

Cloud computing is a paradigm that allows individuals and companies to obtain a wide range of computing resources, such as storage, processing, and software, via the Internet without depending on the local infrastructure. This approach provides substantial advantages, including flexibility, scalability, and cost efficiency, because users can utilize resources on demand without the burden of maintaining physical hardware or servers [12, 13].

Cloud computing covers three main deployment scenarios: the public cloud offers services provided by third-party vendors and is accessible to anyone on the internet. A private cloud is intended for a single organization, ensuring greater control and enhanced security. Finally, the hybrid cloud combines public and private clouds, enabling organizations to achieve better flexibility and cost optimization [14].

1.png

Figure 1. Cloud computing

As illustrated in Figure 1, cloud services are grouped into three major paradigms: Infrastructure as a Service (IaaS), which provides shared virtualized computing resources such as storage; Platform as a Service (PaaS), which is designed to offer a framework for developing and deploying applications without the need to maintain the associated infrastructure; and Software as a Service (SaaS), which provides ready-to-use applications that can be accessed via the Internet [15].

2.1.1 Cloud storage

Cloud data storage enables users to save and access their data over the Internet, removing their reliance on the local physical infrastructure. This approach provides significant advantages such as the ability to scale storage capacity as required and the convenience of accessing data from anywhere. It also helps reduce costs by eliminating the need for users to manage and upgrade their hardware systems [16, 17].

Table 1. Cloud data storage categories

Cloud storage has become an essential part of the modern corporate infrastructure and is widely used, as mentioned in Table 1. By leveraging cloud storage, we can ensure that their data are securely stored and readily accessible [18, 19]. In cloud storage, maintaining multiple copies of data across multiple regions and availability zones is a crucial security strategy known as data redundancy.

As illustrated in Figure 1, cloud services are grouped into three major paradigms: Infrastructure as a Service (IaaS), which provides shared virtualized computing resources such as storage; Platform as a Service (PaaS), which is designed to offer a framework for developing and deploying applications without the need to maintain the associated infrastructure; and Software as a Service (SaaS), which provides ready-to-use applications that can be accessed via the Internet.

2.png

Figure 2. Concept of cloud region

As shown in Figure 2, a region in the cloud architecture refers to a specific geographic area with multiple datacenters. Within each region, the availability zones are separate and isolated locations designed to reduce the effects of failures in other zones.

Let $R(C)$ be the set of regions for a CSP $C$:

$R(C)=\left\{R_i, R_2, R_3, \ldots, R_n\right\}$ with $i \in N, \quad i \geq 1$     (1)

Each region $R_i$ contains a set of availability zones, denoted as $A Z\left(R_i\right)$, where each AZ has a minimum of 2 data centers.

$A Z\left(R_i\right)=\left\{A Z_{i j} \mid j=1, \ldots, m_i\right\}, \quad m_i \in N, m_i \geq 2$     (2)

Each availability zone $A Z_{i j}$ contains a set of datacenters, $D C\left(A Z_{i j}\right)$ with at least one datacenter per AZ.

$\begin{gathered}D C\left(A Z_{i j}\right)=\left\{D C_{i j k} \mid k=1,2, \ldots, k_{i j}\right\} \text { with } k_{i j} \\ \in N\end{gathered}$     (3)

For a given region $R_i$, the set of services $S\left(R_i\right)$ available is a subset of all services offered by the CSP. Thus, if a CSP $C$ offers a variety of services, the specific set of services available in each region $R_i$ may differ. Let $S(C)$ denote the set of all services provided by CSP $C$, for each region $R_i$, the set of available services $S\left(R_i\right)$ is a subset of $S(C)$.

2.1.2 Access control

Access control in cloud computing focuses on determining who can access cloud resources, the conditions under which access is granted, and the actions that they are allowed to perform. It helps to ensure the security of data and upholding the overall cloud security.

As illustrated in Table 2, access control models are often used in the cloud, they can be mathematically expressed, in RBAC, resource access is defined as:

$\begin{gathered}\operatorname{Access}(U, R)=U_{i=1}^n \operatorname{Permissions}\left(R_i\right) \\ \text { where } R_i \in \operatorname{Roles}(U)\end{gathered}$     (4)

where, $U$ is the user, $R$ is the resource, $Permissions \left(R_i\right)$ refers to the permissions associated with each role $R_i$, and $Roles (U)$ denotes the set of roles assigned to the user. The Discretionary Access Control (DAC) can be represented as:

$\operatorname{Access}(U, R)=$ Owner $(R) \cup \operatorname{Deleg} \operatorname{Access}(U, R)$     (5)

where, the resource owner or delegated users determine the access. The Mandatory Access Control (MAC) is as follows:

$\operatorname{Access}(U, R)=\operatorname{Sec}_{\text {Level }}(U) \geq \operatorname{Sec}_{\text {Level }(R)}$     (6)

Table 2. Access control models

Ensuring that access relies on security classification. Attribute-Based Access Control (ABAC) is modeled as:

$\operatorname{Access}(U, R)=f\left(A_U, A_R, A_E\right)$     (7)

where, $A_U$, $A_R$ and $A_E$ are attributes of the user, resource, and environment, respectively, and $f$ is a policy function determining access.

2.2 Blockchain

This technology employs a decentralized digital ledger to facilitate secure, open, and unalterable record-keeping. Information is stored in interconnected blocks, forming a sequential chain that makes data manipulation virtually impossible without network consensus [20].

In addition to the structure and workflow shown in Figure 3, blockchain employs cryptographic techniques to enhance security and protect data from unauthorized access. Due to these characteristics, blockchain has taken off as a highly attractive technology for a wide range of applications, particularly in cloud data storage, where maintaining data integrity and trust is essential [21].

3.png

Figure 3. General workflow of blockchain transaction

4.png

Figure 4. Architecture of the proposed system

4.2 Components

4.2.1 User Layer

The User Layer acts as the primary interface between users (Data Owners and Data Requesters) and the system. The Data Owner (DO) uploads data along with predefined access policies, specifying the conditions under which data can be accessed. These access policies are stored securely in the blockchain infrastructure. However, the Data Requester (DR) submits an access request that includes key attributes to rule the request.

Let $R$ represent the access request, where:

$R=(U I D, R I D, A c t, c t x)$     (8)

$U I D$ is the user identifier, $R I D$ is the Resource identifier, $A c t$ is the action to be performed over the resource and $c t x$ is the context of the request, especially the location of the requester and timestamp of the request. The User Layer forwards these requests to the Data Gateway for validation and processing.

4.2.2 Data Gateway

The Data Gateway Layer manages the flow of requests between the User Layer and the cloud storage system. It begins by intercepting all REST calls from users and validating the requests through signature and authenticity checks. Valid requests are forwarded to the CSP Selector, which identifies the optimal region for each cloud service provider (CSP) based on the proximity to the user and cost efficiency. The selected regions are then associated with the data owner for efficient storage and retrieval. Finally, the Data Handler processes data access requests, reconstructing data from the primary storage and its replicas across the selected CSP regions to ensure reliability and scalability.

Rest Calls Interceptor: The Request Interceptor is the first component of the Data Gateway Layer, which is responsible for capturing all REST API calls from the User Layer. Each access request is validated by checking the digital signature for authenticity and ensuring that the request is fresh and not replayed. If the request passes these validations, it is forwarded to the CSP Selector for further processing; otherwise, it is rejected.

CSP selector: The CSP Selector determines the optimal storage or retrieval regions across multiple cloud service providers (CSPs). For data storage, regions were selected based on proximity to reduce latency and cost efficiency to minimize expenses. For data retrieval, the appropriate CSPs and regions in which the data are stored are identified.

The CSP Selector identifies the most suitable region from each cloud service provider (CSP) based on two key criteria:

• The nearest regions over all CSPs are selected based on the Data’s location to reduce latency.
• Choosing the region with the cheapest storage service to ensure cost efficiency.

Using these filters, it selects one region per CSP to ensure a low latency for data access and minimal storage costs. The selected regions are then linked to the data owner for efficient future storage and retrieval operations.

For each CSP $C S P_i \in \operatorname{CSPs}$, the selected region $R n_s\left(C S P_i\right)$ must satisfy:

$\begin{aligned} R n_s\left(C S P_i\right)= & \arg _{r \in R n\left(C S P_i\right)} \min (\alpha . D c(L, r) +\beta \cdot C t(r))\end{aligned}$     (9)

where, $R n\left(C S P_i\right)$ is the set of regions composing $C S P_i$, $L$ is the location of the Data Owner, $D c(L, r)$ is the distance between $L$ and region $r$, $\operatorname{Cost}(r)$ storage cost is region $r$, $\alpha$ and $\beta$ are weights for prioritizing proximity and cost efficiency. The weights α and β in Eq. (9) help balance speed and cost when selecting a cloud storage region. A higher α prioritizes lower latency for faster data access, while a higher β focuses on reducing storage costs. These values can be adjusted based on user needs or Service Level Agreements (SLAs). Experimental evaluations demonstrated that higher α values reduce retrieval time but may increase costs, whereas higher β values lower expenses but can introduce latency. This balance allows the model to adapt to different multi-cloud storage requirements.

The combined CSP selection $C S P_{\text {filtered }}$ includes the selected regions for all CSPs:

$C S P_f=\left\{R n_s\left(C S P_1\right), R n_s\left(C S P_2\right) \ldots, R n_s\left(C S P_n\right)\right\}$     (10)

4.2.3 Data Handler

The Data Handler Module securely manages data storage and retrieval. For uploads, data are encrypted using a symmetric key derived from the Data Owner ID and Resource, distributing the encrypted data and policies across the selected CSP regions. The symmetric key is also encrypted with an asymmetric public key and stored in regional Key Vaults for redundancy. During retrieval, the module verifies the access permissions and, if granted, retrieves and decrypts the key to reconstruct the data, ensuring secure and compliant access.

As depicted in Figure 5, during the encryption phase, a symmetric key $K_s$ is dynamically generated using the secure key derivation function HKDF. This key is derived from immutable attributes, Data Owner ID and Resource ID, ensuring a unique key for each resource. The data is then encrypted with $K_s$ using AES, which is efficient and suitable for handling large datasets. To further secure the encryption key, $K_s$ is encrypted with an asymmetric public key $K_{p u b}$, and the resulting $K_{s_{-} \text {encrypted }}$ is stored in redundant Key Vaults across the selected regions. The encrypted data $D_{\text {encrypted }}$ is distributed to the selected regions.

The decryption phase begins only after the access request is authorized by the Access Validation Layer. The Data Handler retrieves the encrypted key $K_{\text {s_encrypted }}$ from the Key Vault in the region hosting the data. This key is then decrypted using the corresponding private key $K_{\text {priv }}$, restoring the symmetric key $K_s$. Finally, $K_s$ is used to decrypt the data, and reconstruct the original dataset for the authorized requester.

5.png

Figure 5. Workflow of data handler module

By distributing $D_{\text {encrypted }}$ and $K_{s_{-} \text {encrypted }}$ across multiple regions, the system ensures redundancy. Encryption and decryption operations provide robust confidentiality, leveraging symmetric encryption for performance and asymmetric encryption for secure key management.

4.2.4 Access Validation Layer

The Policy Validation Layer is the core of the framework and ensures secure and accurate access control for all the requests. It acts as the decision-making hub, validating access requests against predefined policies through a two-step process involving the Access Module and Blockchain Module. This layer guarantees that only legitimate and authorized requests are granted access, leveraging the blockchain for transparency and immutability.

Access Module: The Access Module performs the initial validation of requests by verifying the identity and attributes of the user. It ensures the request's legitimacy by checking its format, authenticity, and compliance with basic access requirements. Validated requests are then forwarded to the Blockchain Module for further policy evaluation.

Blockchain Module: The Blockchain Module evaluates the access requests against smart contract-defined policies stored in the blockchain. It executes these contracts to determine whether the request complies with the policies, logs the decision immutably on the blockchain, and returns the access decision to the Access Module for further action. This ensures transparency and secure policy enforcement.

As illustrated in Figure 6, the proposed topology functions as a private blockchain network with Ganache serving as the centralized coordination hub. Data owners are represented as nodes that connect to the central ledger by using the Web3.py Python library to send transactions and receive updates. Ganache manages the blockchain ledger to ensure synchronization across all nodes. This setup simulates decentralization while maintaining simplicity and efficiency for experimental purposes.

6.png

Figure 6. Interactions of the proposed private blockchain

7.png

Figure 7. Structure of the proposed transaction block

Table 4. Block attributes

In the proposed framework, data metadata and access policies are stored in the blockchain as structured blocks, as depicted in Figure 7. Each block contains key details, including the Resource ID (RID), metadata regarding data storage and replication across CSPs, and programmatically defined access policies. The metadata include information such as the primary CSP, replication locations, encryption keys, and timestamps, while the policies specify rules such as user roles, conditions, and allowed actions.

Additionally, as depicted in Table 4, the User ID (UID) is stored in the block to link the data and policies to the Data Owner, ensuring accountability and traceability. The blocks are formatted in a JSON structure for flexibility and seamless execution using smart contracts.

The proposed smart contract algorithm automates access control decisions in multi-cloud storage by evaluating requests against policies stored on the blockchain. It first retrieves relevant policies and detects any conflicts. If conflicts exist, a resolution mechanism prioritizes the appropriate policy. The algorithm then verifies user permissions, requested actions, and contextual conditions before granting or denying access. The final decision is immutably logged on the blockchain, ensuring transparency and accountability.

4.2.5 Multi-Cloud Data Storage Layer

This layer manages data securely across multiple cloud service providers. For storage, the data are encrypted, replicated, and distributed to regions selected by the CSP Selector. Policies are defined in each CSP’s Identity and Access Management engine, and are linked to the data. During retrieval, the Data Handler reconstructs the data using metadata from the blockchain.

This paper outlined a private blockchain-based model that improves the security and transparency of data access in the multi-cloud storage context. The integration of decentralized access control and an immutable audit trail ensures that data is accessed only by authorized users while maintaining accountability through secure and tamper-proof logging. The experimental findings validate the model’s capability to deliver robust encryption, reliable access control, and efficient data management within the multi-cloud data storage context.

Although the proposed model demonstrates strong potential, it faces challenges related to scalability and latency under high-demand conditions. As transaction volume increases, the execution time of smart contracts and blockchain validation overhead introduce processing bottlenecks, affecting system response times. Furthermore, high network traffic and inefficient resource allocation can contribute to delays in access request processing, particularly in scenarios with high concurrency.

Future work will focus on optimizing smart contract algorithms to improve access validation efficiency in dynamic scenarios. Additionally, exploring homomorphic encryption could provide enhanced security for data in its "in-use" state, allowing secure operations without exposing sensitive information. These advancements aim to address the existing limitations and improve the scalability and adaptability of the framework in diverse cloud applications.