Cloud Computing Adoption Framework for Business Clouds: A Multi-Layered Security Approach
Write an overview of 4 options for upgrading business and computer systems, with a focus on option 3: Move to a cloud-based hosted suite solution.
33 Pages17004 Words252 Views
Added on 2023-06-09
About This Document
This paper presents a Cloud Computing Adoption Framework (CCAF) security suitable for business clouds. CCAF multi-layered security is based on the development and integration of three major security technologies: firewall, identity management and encryption based on the development of Enterprise File Sync and Share technologies. The paper explains the motivation, related work, and views on security framework. It also presents the core technologies in detail and experiments designed to demonstrate the robustness of the CCAF multi-layered security. The paper illustrates how CCAF multi-layered security can blend with policy, real services, and business activities. The subject is Cloud Computing Adoption Framework (CCAF) and the course code is not mentioned. The course name and college/university are also not mentioned.
Cloud Computing Adoption Framework for Business Clouds: A Multi-Layered Security Approach
Write an overview of 4 options for upgrading business and computer systems, with a focus on option 3: Move to a cloud-based hosted suite solution.
Added on 2023-06-09
ShareRelated Documents
Cloud Computing Adoption Framework – a security framework for business clouds
Victor Chang1, Yen-Hung Kuo2, Muthu Ramachandran1
1. School of Computing, Creative Technologies and Engineering,
Leeds Beckett University, Leeds, UK.
2. Data Analytics Technology & Applications, Institute for Information Industry, Taiwan, R.O.C.
Corresponding authors: V.I.Chang@leedsbeckett.ac.uk ; keh@iii.org.tw
Abstract
This paper presents a Cloud Computing Adoption Framework (CCAF) security suitable for business clouds.
CCAF multi-layered security is based on the development and integration of three major security
technologies: firewall, identity management and encryption based on the development of Enterprise File
Sync and Share technologies. This paper presents our motivation, related work and our views on security
framework. Core technologies have been explained in details and experiments were designed to
demonstrate the robustness of the CCAF multi-layered security. In penetration testing, CCAF multi-layered
security could detect and block 99.95% viruses and trojans and could maintain 85% and above of blocking
for 100 hours of continuous attacks. Detection and blocking took less than 0.012 second per trojan and
viruses. A full CCAF multi-layered security protection could block all SQL injection providing real
protection to data. CCAF multi-layered security had 100% rate of not reporting false alarm. All F-measures
for CCAF test results were 99.75% and above. How CCAF multi-layered security can blend with policy,
real services and blend with business activities have been illustrated. Research contributions have been
justified and CCAF multi-layered security can offer added value for volume, velocity and veracity for Big
Data services operated in the Cloud.
Keywords: Cloud Computing Adoption Framework (CCAF); OpenStack; CCAF multi-layered security;
security for business clouds
1. Introduction
Security, trust and privacy always remain challenges for organizations that adopt Cloud Computing and
Big Data. While there are demands for businesses to move their data in the Cloud and centralize
management for data centers, services and applications are designed to achieve cost savings and operational
efficiencies. At the same time, system design and deployment based on current security practices should
be enforced to ensure all data and services are security compliant with up-to-date patches and policies. A
risk-based approach to the development of a security program that recognizes (and funds) appropriate
controls will ensure that all users can be protected, and that data can be confidential, have integrity and be
available.
Some researchers have adopted a framework approach to allow organizations to follow guidelines, policies
and standards. For example, Zhang et al. [1] propose their Usage-Based Security Framework (UBSF) which
can consolidate guidelines and policies with their framework, architecture and digital certificates. Takabi
et al. [2] describe their comprehensive security framework by presenting a model to explain how to work
with different service integrators and service providers. Zia and Zomaya [3] present their wireless sensor
networks model with their algorithms and a software engineering approach. All these frameworks have
Victor Chang1, Yen-Hung Kuo2, Muthu Ramachandran1
1. School of Computing, Creative Technologies and Engineering,
Leeds Beckett University, Leeds, UK.
2. Data Analytics Technology & Applications, Institute for Information Industry, Taiwan, R.O.C.
Corresponding authors: V.I.Chang@leedsbeckett.ac.uk ; keh@iii.org.tw
Abstract
This paper presents a Cloud Computing Adoption Framework (CCAF) security suitable for business clouds.
CCAF multi-layered security is based on the development and integration of three major security
technologies: firewall, identity management and encryption based on the development of Enterprise File
Sync and Share technologies. This paper presents our motivation, related work and our views on security
framework. Core technologies have been explained in details and experiments were designed to
demonstrate the robustness of the CCAF multi-layered security. In penetration testing, CCAF multi-layered
security could detect and block 99.95% viruses and trojans and could maintain 85% and above of blocking
for 100 hours of continuous attacks. Detection and blocking took less than 0.012 second per trojan and
viruses. A full CCAF multi-layered security protection could block all SQL injection providing real
protection to data. CCAF multi-layered security had 100% rate of not reporting false alarm. All F-measures
for CCAF test results were 99.75% and above. How CCAF multi-layered security can blend with policy,
real services and blend with business activities have been illustrated. Research contributions have been
justified and CCAF multi-layered security can offer added value for volume, velocity and veracity for Big
Data services operated in the Cloud.
Keywords: Cloud Computing Adoption Framework (CCAF); OpenStack; CCAF multi-layered security;
security for business clouds
1. Introduction
Security, trust and privacy always remain challenges for organizations that adopt Cloud Computing and
Big Data. While there are demands for businesses to move their data in the Cloud and centralize
management for data centers, services and applications are designed to achieve cost savings and operational
efficiencies. At the same time, system design and deployment based on current security practices should
be enforced to ensure all data and services are security compliant with up-to-date patches and policies. A
risk-based approach to the development of a security program that recognizes (and funds) appropriate
controls will ensure that all users can be protected, and that data can be confidential, have integrity and be
available.
Some researchers have adopted a framework approach to allow organizations to follow guidelines, policies
and standards. For example, Zhang et al. [1] propose their Usage-Based Security Framework (UBSF) which
can consolidate guidelines and policies with their framework, architecture and digital certificates. Takabi
et al. [2] describe their comprehensive security framework by presenting a model to explain how to work
with different service integrators and service providers. Zia and Zomaya [3] present their wireless sensor
networks model with their algorithms and a software engineering approach. All these frameworks have
provided recommendations on how they should be used. However, there are no details on how to actually
use these proposals, and there are no clear evidence that these proposals can be adopted for Business
Clouds, whereby the requirements include the ease of use, adaptability, best practice compliant and
supported by large scale experiments such as penetration testing to validate robustness of such proposals
[4-5]. Indeed, without such a clear “line on sight” between conception and implementation, such
frameworks are unlikely to achieve operational status.
In order to meet requirements for Business Clouds, the Cloud Computing Adoption Framework (CCAF)
has been developed to ensure that all implementations and service deliveries can meet all the technical
challenges. There are real-life case studies to show how different Cloud Computing design, development
and service delivery can meet both technical and organizational challenges. In the first example, CCAF
was the framework used to develop Cloud storage and bioinformatics solutions for biomedical scientists
based at Guy’s Hospital and King’s College London, UK [6]. The use of the framework ensured that the
deliveries of storage services to back up thousands of medical data with terabytes of size. Bioinformatics
services can simulate DNAs, proteins, genes, tumor and organs related to human bodies. The use of their
security is limited to authentication, encryption and users with authorized access. In the second example,
CCAF is used to provide guidelines for financial modeling, so that the best put and call prices can be
computed in regard to the change of risks. Advanced computational techniques have been used to calculate
risks and market volatility [7]. Security is limited to password authentication and users with authorized
access and biometrics checks to the financial simulations. In the third example, investigations of hacking
methods have been studied and made as part of prototype requirements. As a result of a user requirement
and literature review, factors for successful implementations have been identified. All the collected and
synthesized information have been instrumental in the development of CCAF Version 1.1, which
emphasizes on the security policies, recommendations, techniques and technologies to be updated in our
framework [8]. In these three examples, a more comprehensive Cloud security solution is required to ensure
that services are robust and can be resistant to attack, hacking and unauthorized attempts to gain access.
More experiments and simulations are required to validate the robustness and effectiveness of our security
framework. This motivates us to consolidate our CCAF framework by providing a holistic approach
involved with service integration, OpenStack security and multi-layered security to enhance security for
business clouds. We propose an integrated security framework for business clouds to have the multi-layered
security in place and have the large scale penetration testing and experiments to validate the robustness and
effectiveness of our approach. All these proofs-of-concepts and lessons learned are important to Big Data
in the Cloud as follows. First, it ensures that all the cloud services are safe and secure, including data coming
in and out of the organizational data centers hosted on hundreds and thousands of virtual machines (VMs).
Second, it ensures that large amount of data and large datasets can be processed and analyzed safely in the
Cloud, which also explains why large scale penetration testing is necessary to validate the framework.
The breakdown of this paper is as follows. Section 2 presents the literature for security. Section 3 describes
our core security technology for Enterprise File Sync and Share, including the architecture and layered
components. Section 4 explains our multi-layered approach with core technologies and results from large
scale experiments for penetration testing, SQL injection and data scanning. Section 5 illustrates topics of
discussion and Section 6 sums up Conclusion and Future Work.
2. Literature
Different types of security frameworks are introduced as follows. First, Zhang et al. [1] propose their Usage-
Based Security Framework (UBSF) for Collaborative Computing Systems. They explain their motivation,
techniques behind, architecture and conditions for experiments. Usage decision of the USFB is based on
subjects, objects, authorization, obligations and conditions. They explain how their model can work in
collaborative ways supported by their literature and hypotheses. The usage-based authorization architecture
uses sensors, directory service, policy decision point (PDP) and usage monitor (UM) to functions. Steps
have been described to justify how the USFB can function effectively. To assist USFB, Zhang et al. [1]
use these proposals, and there are no clear evidence that these proposals can be adopted for Business
Clouds, whereby the requirements include the ease of use, adaptability, best practice compliant and
supported by large scale experiments such as penetration testing to validate robustness of such proposals
[4-5]. Indeed, without such a clear “line on sight” between conception and implementation, such
frameworks are unlikely to achieve operational status.
In order to meet requirements for Business Clouds, the Cloud Computing Adoption Framework (CCAF)
has been developed to ensure that all implementations and service deliveries can meet all the technical
challenges. There are real-life case studies to show how different Cloud Computing design, development
and service delivery can meet both technical and organizational challenges. In the first example, CCAF
was the framework used to develop Cloud storage and bioinformatics solutions for biomedical scientists
based at Guy’s Hospital and King’s College London, UK [6]. The use of the framework ensured that the
deliveries of storage services to back up thousands of medical data with terabytes of size. Bioinformatics
services can simulate DNAs, proteins, genes, tumor and organs related to human bodies. The use of their
security is limited to authentication, encryption and users with authorized access. In the second example,
CCAF is used to provide guidelines for financial modeling, so that the best put and call prices can be
computed in regard to the change of risks. Advanced computational techniques have been used to calculate
risks and market volatility [7]. Security is limited to password authentication and users with authorized
access and biometrics checks to the financial simulations. In the third example, investigations of hacking
methods have been studied and made as part of prototype requirements. As a result of a user requirement
and literature review, factors for successful implementations have been identified. All the collected and
synthesized information have been instrumental in the development of CCAF Version 1.1, which
emphasizes on the security policies, recommendations, techniques and technologies to be updated in our
framework [8]. In these three examples, a more comprehensive Cloud security solution is required to ensure
that services are robust and can be resistant to attack, hacking and unauthorized attempts to gain access.
More experiments and simulations are required to validate the robustness and effectiveness of our security
framework. This motivates us to consolidate our CCAF framework by providing a holistic approach
involved with service integration, OpenStack security and multi-layered security to enhance security for
business clouds. We propose an integrated security framework for business clouds to have the multi-layered
security in place and have the large scale penetration testing and experiments to validate the robustness and
effectiveness of our approach. All these proofs-of-concepts and lessons learned are important to Big Data
in the Cloud as follows. First, it ensures that all the cloud services are safe and secure, including data coming
in and out of the organizational data centers hosted on hundreds and thousands of virtual machines (VMs).
Second, it ensures that large amount of data and large datasets can be processed and analyzed safely in the
Cloud, which also explains why large scale penetration testing is necessary to validate the framework.
The breakdown of this paper is as follows. Section 2 presents the literature for security. Section 3 describes
our core security technology for Enterprise File Sync and Share, including the architecture and layered
components. Section 4 explains our multi-layered approach with core technologies and results from large
scale experiments for penetration testing, SQL injection and data scanning. Section 5 illustrates topics of
discussion and Section 6 sums up Conclusion and Future Work.
2. Literature
Different types of security frameworks are introduced as follows. First, Zhang et al. [1] propose their Usage-
Based Security Framework (UBSF) for Collaborative Computing Systems. They explain their motivation,
techniques behind, architecture and conditions for experiments. Usage decision of the USFB is based on
subjects, objects, authorization, obligations and conditions. They explain how their model can work in
collaborative ways supported by their literature and hypotheses. The usage-based authorization architecture
uses sensors, directory service, policy decision point (PDP) and usage monitor (UM) to functions. Steps
have been described to justify how the USFB can function effectively. To assist USFB, Zhang et al. [1]
have a prototype system architecture. They use OpenLDAP and OpenSSL to enforce security. They have
three types of digital certificates: User, Attribute Repository (AR) and Resource Provider (RP) certificate.
They explain how these certificates work in their workflow-type of security processes. They also adopt
extensible access control markup language (XACML) to enforce policy specification which aligns with the
UBSF approach for security. Ko et al [9] investigate trust for Cloud computing and propose a TrustCloud
Framework focused on accountability. They have three layers: (1) System layer, which covers all the
underlying hardware and platform; (2) Data layer, which contains the data for the work and (3) Workflow
layer, which uses workflow to execute all the services and requests. There are two non-functional layers
attached throughout the three layers. The first layer is Laws and Regulations, which can ensure all services
follow the legal requirements in the country that the service is delivered. The second layer is Policies, which
are the consolidated service level agreements and the best practice approach. This framework is considered
a conceptual framework focused on the recommendations and best practice, since they do not have
quantitative analyses, computational demonstrations and case studies. Pal et al. [10] present their proposed
Cloud security that has emphasized on the architecture and steps of interactions between different services.
They explain the role in each major user, their agents and all the fifteen steps involved. They use UML
diagram to justify their approach and use architecture to explain relationship between the user, provider,
proxy server, user agent and provider agent. They present their two algorithms and their experimental
results. Using “Trust Value Updation”, they validate their approach. However, their assumption is based
on the probability of having a trusted user is 0.8 and a non-trusted user is 0.2. There are no any evidences
to support this and they do not use any references or large number of surveys to justify their research. This
also depends on their sample size, demographics and the country that the research is conducted. The NIST
[11] framework provides a common language for establishing cybersecurity. The core NIST framework
provides a set of activities on Identify, Protect, Detect, Respond, and Recover without more specific
examples and case studies implementing a full security solution. However, our work on CCAF extends
detailed activities and implementation on security for Cloud Computing and Big Data.
All these examples have security framework. However, those proposals do not demonstrate their
contributions for business clouds. In other words, when businesses adopt Cloud Computing solution, they
should be able to provide architecture, approaches for their framework, steps and experiments to support
the robustness and validity of the framework. Our proposal on Cloud Computing Adoption Framework
(CCAF) will provide details in core technologies in Section 3, and then the theoretical framework mapping
to core technologies with experimental results to validate our framework will be shown in Section 4.
Following that, key topics including security policy, business and security alignment, framework and core
technology integration, relation of the big data in cloud, overall contributions with limitation are discussed
in Section 5. Finally, research conclusion and future work will be in Section 6.
3. Core technologies
Prior to introduce the Cloud Computing Adoption Framework (CCAF), this section uses a concrete instance
of the CCAF to be an example to explain CCAF core technologies and implementations. To hit the needs
of moving big data in a semi-public business cloud, an enterprise cloud storage application - the semi-
public Enterprise File Sync and Share (EFSS) service is chosen to be the CCAF instance to explain how
CCAF protect enormous enterprise files (a kind of unstructured big data) in a business cloud environment.
To provide enterprises with the convenient cloud file sync and share service while taking enterprise
concerns such as security, compliance, and regulation concerns into consideration, the cloud file sync and
share service was been deployed by either on-premise or hybrid cloud model to target high value Enterprise
File Sync and Share market [12-14]. Existing EFSS systems focus on system security and manageability,
which encrypt data on transfer and at rest and also support system audit trail. As part of the core
technologies of the CCAF framework, important EFSS security issues should be well addressed,
particularly for businesses with critical data services. Following items describe the opened EFSS security
issues.
three types of digital certificates: User, Attribute Repository (AR) and Resource Provider (RP) certificate.
They explain how these certificates work in their workflow-type of security processes. They also adopt
extensible access control markup language (XACML) to enforce policy specification which aligns with the
UBSF approach for security. Ko et al [9] investigate trust for Cloud computing and propose a TrustCloud
Framework focused on accountability. They have three layers: (1) System layer, which covers all the
underlying hardware and platform; (2) Data layer, which contains the data for the work and (3) Workflow
layer, which uses workflow to execute all the services and requests. There are two non-functional layers
attached throughout the three layers. The first layer is Laws and Regulations, which can ensure all services
follow the legal requirements in the country that the service is delivered. The second layer is Policies, which
are the consolidated service level agreements and the best practice approach. This framework is considered
a conceptual framework focused on the recommendations and best practice, since they do not have
quantitative analyses, computational demonstrations and case studies. Pal et al. [10] present their proposed
Cloud security that has emphasized on the architecture and steps of interactions between different services.
They explain the role in each major user, their agents and all the fifteen steps involved. They use UML
diagram to justify their approach and use architecture to explain relationship between the user, provider,
proxy server, user agent and provider agent. They present their two algorithms and their experimental
results. Using “Trust Value Updation”, they validate their approach. However, their assumption is based
on the probability of having a trusted user is 0.8 and a non-trusted user is 0.2. There are no any evidences
to support this and they do not use any references or large number of surveys to justify their research. This
also depends on their sample size, demographics and the country that the research is conducted. The NIST
[11] framework provides a common language for establishing cybersecurity. The core NIST framework
provides a set of activities on Identify, Protect, Detect, Respond, and Recover without more specific
examples and case studies implementing a full security solution. However, our work on CCAF extends
detailed activities and implementation on security for Cloud Computing and Big Data.
All these examples have security framework. However, those proposals do not demonstrate their
contributions for business clouds. In other words, when businesses adopt Cloud Computing solution, they
should be able to provide architecture, approaches for their framework, steps and experiments to support
the robustness and validity of the framework. Our proposal on Cloud Computing Adoption Framework
(CCAF) will provide details in core technologies in Section 3, and then the theoretical framework mapping
to core technologies with experimental results to validate our framework will be shown in Section 4.
Following that, key topics including security policy, business and security alignment, framework and core
technology integration, relation of the big data in cloud, overall contributions with limitation are discussed
in Section 5. Finally, research conclusion and future work will be in Section 6.
3. Core technologies
Prior to introduce the Cloud Computing Adoption Framework (CCAF), this section uses a concrete instance
of the CCAF to be an example to explain CCAF core technologies and implementations. To hit the needs
of moving big data in a semi-public business cloud, an enterprise cloud storage application - the semi-
public Enterprise File Sync and Share (EFSS) service is chosen to be the CCAF instance to explain how
CCAF protect enormous enterprise files (a kind of unstructured big data) in a business cloud environment.
To provide enterprises with the convenient cloud file sync and share service while taking enterprise
concerns such as security, compliance, and regulation concerns into consideration, the cloud file sync and
share service was been deployed by either on-premise or hybrid cloud model to target high value Enterprise
File Sync and Share market [12-14]. Existing EFSS systems focus on system security and manageability,
which encrypt data on transfer and at rest and also support system audit trail. As part of the core
technologies of the CCAF framework, important EFSS security issues should be well addressed,
particularly for businesses with critical data services. Following items describe the opened EFSS security
issues.
(1) Employee Privacy: To prevent data leak, enterprise data are usually encrypted in existing EFSS
systems. However, most existing EFSS systems only uses single master key to encrypt entire data space,
which can prevent enterprise data leaks from outside but not from inside. For example, an EFSS system
administrator (IT or MIS in enterprise) can spy enterprise sensitive data by self-granted authority.
(2) Share Link: The share link is widely adopted to share data to business partners who do not have an
EFSS system account. From enterprise's perspective, the share link is convenient but not secure since
it introduced new security loophole and might be used to leak data to unauthorized domain without
leaving enough audit trail [15].
(3) Cloud File Synchronization: The natural of the cloud file synchronization is a security loophole to
enterprises. It synchronizes shared and collaborative enterprise data from a managed EFSS service to
employees' endpoint devices, and enterprises then have less/no control to the synchronized enterprise
data. The synchronized enterprise data can then be distributed from the endpoint devices to other
unauthorized domains by email, USB disk, and other communication interfaces available on the
endpoint devices.
(4) Enterprise Directory Integration: To enable SSO (Single Sign On) in enterprise, most existing EFSS
systems via direct network connection to integrate its authentication with existing enterprise directory,
e.g., AD (Active Directory) and LDAP (Lightweight Directory Authentication Protocol). It also
introduces two new security issues. Firstly, the EFSS system is able to access employees' profiles
available in enterprise directories. Secondly, the EFSS system can log employees' credential
information when authentication since every employee's username and password are pass through EFSS
system to enterprise directory to conduct the actual authentication. Both cases provide EFSS system
with chances to get authorized information.
An integrated security approach is introduced in follow sections, which implements several key
components to form a scalable Secure EFSS system to address the enterprises' concerns by leveraging the
on-premise OpenStack infrastructure [16]. EFSS has been integrated with our CCAF framework as an
overarching model for cloud security for businesses.
Architecture and Design of the Integrated Security Approach
The key components of the Secure EFSS system are virtual appliances which can be provisioned and ran
on the OpenStack compute service – Nova, and the data (e.g., metadata in database and uploaded enterprise
files in user storage space) generated by the key components are stored in the OpenStack storage services
– Cinder for block storage and Swift for object storage in which the OpenStack storage services are
managed storage system controlled by the enterprise. The separation of the compute and storage makes the
Secure EFSS system is scalable and more secure than existing EFSS systems.
All key components/virtual appliances including Load Balancer, Firewall, VFS (Virtual File System)
Service, Directory Service, Log Service, MQ (Message Queue) Service, and the Database Service are
provisioned from an all-in-one image stored in the OpenStack VM image management service – Glance to
form the Secure EFSS system as shown in Figure 1. The VFS service of the proposed Secure EFSS system
provides clients with a REST API set to manipulate a directory structure and files of a virtual file system.
The backend of the virtual file system is the Database Service, which stores metadata to represent the
directory structure and the nodes' attributes of the directory structure. Enterprise files uploaded by clients
are leaf nodes of the directory structure, and they have a node attribute to point to encrypted objects in the
Swift. Since there is no knowledge kept in the VFS service, the VFS service can dynamically provision
more VFS VM to satisfy growing EFSS system usage in a scalable and distributed manner.
In Figure 1, rest key components’ interactions and how they benefit to security and scalability are shown
below. The Load Balancer is deployed in the DMZ (Demilitarized Zone), which dynamically distributes
systems. However, most existing EFSS systems only uses single master key to encrypt entire data space,
which can prevent enterprise data leaks from outside but not from inside. For example, an EFSS system
administrator (IT or MIS in enterprise) can spy enterprise sensitive data by self-granted authority.
(2) Share Link: The share link is widely adopted to share data to business partners who do not have an
EFSS system account. From enterprise's perspective, the share link is convenient but not secure since
it introduced new security loophole and might be used to leak data to unauthorized domain without
leaving enough audit trail [15].
(3) Cloud File Synchronization: The natural of the cloud file synchronization is a security loophole to
enterprises. It synchronizes shared and collaborative enterprise data from a managed EFSS service to
employees' endpoint devices, and enterprises then have less/no control to the synchronized enterprise
data. The synchronized enterprise data can then be distributed from the endpoint devices to other
unauthorized domains by email, USB disk, and other communication interfaces available on the
endpoint devices.
(4) Enterprise Directory Integration: To enable SSO (Single Sign On) in enterprise, most existing EFSS
systems via direct network connection to integrate its authentication with existing enterprise directory,
e.g., AD (Active Directory) and LDAP (Lightweight Directory Authentication Protocol). It also
introduces two new security issues. Firstly, the EFSS system is able to access employees' profiles
available in enterprise directories. Secondly, the EFSS system can log employees' credential
information when authentication since every employee's username and password are pass through EFSS
system to enterprise directory to conduct the actual authentication. Both cases provide EFSS system
with chances to get authorized information.
An integrated security approach is introduced in follow sections, which implements several key
components to form a scalable Secure EFSS system to address the enterprises' concerns by leveraging the
on-premise OpenStack infrastructure [16]. EFSS has been integrated with our CCAF framework as an
overarching model for cloud security for businesses.
Architecture and Design of the Integrated Security Approach
The key components of the Secure EFSS system are virtual appliances which can be provisioned and ran
on the OpenStack compute service – Nova, and the data (e.g., metadata in database and uploaded enterprise
files in user storage space) generated by the key components are stored in the OpenStack storage services
– Cinder for block storage and Swift for object storage in which the OpenStack storage services are
managed storage system controlled by the enterprise. The separation of the compute and storage makes the
Secure EFSS system is scalable and more secure than existing EFSS systems.
All key components/virtual appliances including Load Balancer, Firewall, VFS (Virtual File System)
Service, Directory Service, Log Service, MQ (Message Queue) Service, and the Database Service are
provisioned from an all-in-one image stored in the OpenStack VM image management service – Glance to
form the Secure EFSS system as shown in Figure 1. The VFS service of the proposed Secure EFSS system
provides clients with a REST API set to manipulate a directory structure and files of a virtual file system.
The backend of the virtual file system is the Database Service, which stores metadata to represent the
directory structure and the nodes' attributes of the directory structure. Enterprise files uploaded by clients
are leaf nodes of the directory structure, and they have a node attribute to point to encrypted objects in the
Swift. Since there is no knowledge kept in the VFS service, the VFS service can dynamically provision
more VFS VM to satisfy growing EFSS system usage in a scalable and distributed manner.
In Figure 1, rest key components’ interactions and how they benefit to security and scalability are shown
below. The Load Balancer is deployed in the DMZ (Demilitarized Zone), which dynamically distributes
every request made by the Sandbox-based Cloud File Sync App to one of VFS VM for handling the requests
by according to loads of the VFS VM for maximizing overall VFS Service performance. Moreover, a
Firewall is deployed in between the Load Balancer and the VFS Service to form a secure deployment
scheme which defends external direct network attacks for internal services. Once the VFS Service receives
a request, it firstly sends the authentication information that came with the request to the Directory Service
to check the request identity and authority. Subsequently, the VFS Service handles the request and logs
related audit trails to the Log Service. When VFS Service is serving, it also reports overall service status
including concurrent serving requests, CPU and memory usages, etc. to MQ service which actively calls
OpenStack compute service API to provision and de-provision VFS VM to handle Secure EFSS system
peak and idle situations.
Figure 1. The Secure EFSS system architecture in the OpenStack.
Designs of key components of the proposed integrated security approach are introduced in following
subsections which include User Storage Space Modeling, Distinct Share Link, Zero-knowledge Cloud
Scale File Sharing System, Sandbox-based Cloud File Synchronization, Out-of-band Authentication, and
a NoSQL adoption consideration.
A. User Storage Space Modeling
To make sure the system is scalable, metadata generated by key components especially by the VFS Service
are stored into a MongoDB cluster. The MongoDB is a document based NoSQL database which sacrifices
the relationship between documents to increase its scalability [17-18]. Further, we use user accounts as
database sharding key to shard entire user storage space into smaller parts to mitigate the MongoDB
scalability limitation which impacts database performance when there are too many documents inserted
into a data collection. Following that, every user has own directory structure formed by metadata stored in
own data collection, which physically isolates users’ metadata, and every user’s metadata then can be
protected by owner’s encryption key without worrying sensitive metadata being leaked when Database
Service been hacked.
by according to loads of the VFS VM for maximizing overall VFS Service performance. Moreover, a
Firewall is deployed in between the Load Balancer and the VFS Service to form a secure deployment
scheme which defends external direct network attacks for internal services. Once the VFS Service receives
a request, it firstly sends the authentication information that came with the request to the Directory Service
to check the request identity and authority. Subsequently, the VFS Service handles the request and logs
related audit trails to the Log Service. When VFS Service is serving, it also reports overall service status
including concurrent serving requests, CPU and memory usages, etc. to MQ service which actively calls
OpenStack compute service API to provision and de-provision VFS VM to handle Secure EFSS system
peak and idle situations.
Figure 1. The Secure EFSS system architecture in the OpenStack.
Designs of key components of the proposed integrated security approach are introduced in following
subsections which include User Storage Space Modeling, Distinct Share Link, Zero-knowledge Cloud
Scale File Sharing System, Sandbox-based Cloud File Synchronization, Out-of-band Authentication, and
a NoSQL adoption consideration.
A. User Storage Space Modeling
To make sure the system is scalable, metadata generated by key components especially by the VFS Service
are stored into a MongoDB cluster. The MongoDB is a document based NoSQL database which sacrifices
the relationship between documents to increase its scalability [17-18]. Further, we use user accounts as
database sharding key to shard entire user storage space into smaller parts to mitigate the MongoDB
scalability limitation which impacts database performance when there are too many documents inserted
into a data collection. Following that, every user has own directory structure formed by metadata stored in
own data collection, which physically isolates users’ metadata, and every user’s metadata then can be
protected by owner’s encryption key without worrying sensitive metadata being leaked when Database
Service been hacked.
B. Distinct Share Link
A share link provides conveniences for sharing cloud files in enterprise and external business partners, but
it is insecure since web crawlers can find it by scanning emails and social network and then download it
simply [19]. To address this issue, it introduces a utility named Distinct Share Link to secure sharing cloud
files and to build a secure sharing relationship between two user storage spaces which are isolated data
collections sharded from entire user storage space [20].
A Distinct Share Link is an additional layer attached with permissions, identities, and access conditions
which encapsulates a share link, decreases diffusibility of the share link, adds traceability as well as
controllability to the share link, and then be sent to recipients according to the attached identities. Whenever
a recipient tries to access a Distinct Share Link, the recipient has to present his/her identities for access
condition check. Once the recipient passes all checks, the Distinct Share Link layer then prepares an
ephemeral representation to link to the share link for accessing. Since every Distinct Share Link access
requires own identity (traceability) and controlled by permissions and access conditions (controllability),
the diffusibility and convenience of the Distinct Share Link is decreased accordingly.
Compare to share link, always need to provide different identities when accessing a Distinct Share Link is
inconvenient. To address the problem, it provides a recipient-defined identity function which allows a
recipient to define own identity (e.g., password, secret, etc.) to each received Distinct Share Link. Hence,
the recipient can define easy to remember identities to received Distinct Share Links. It also solves the
share link identity management issue, that is, share links with different identities (e.g., passwords) are too
much information to be remembered by a single recipient.
In addition to aforementioned benefits, the Distinct Share Link further support sandbox feature for creating
a collaborative workspace with external business partners. In the collaborative workspace, every participant
has own permission, and any inappropriate operation (e.g., delete all files) is only performed in a specific
shared folder but not in entire personal user storage space. Note that with cloud storage capabilities, the
performed inappropriate operations are able to be reverted to original, e.g., reverting previous cloud file
version from file change history or reverting deleted shared files from the recycle bin.
The Distinct Share Link is also used to implement the internal cloud file sharing in the proposed Secure
EFSS by building a secure sharing relationship between two isolated user storage spaces (data collections).
Figure 2 depicts an example to explain how Distinct Share Link help build the internal cloud file sharing.
In the top-left of the Figure 2, it represents two internal cloud file sharing relationships: (1) users A and C
receive an object shared from user B and (2) user B receives an object shared from the user C. The callout
box shown at the top-right of the Figure 2 further explains sharing relationships associated with the object
(ID: WXYZ) in the former sharing relationship. It shows that three Distinct Share Links are used to share
the object (ID: WXYZ) to recipients: user A, user B, and an email address. Moreover, all of the three
Distinct Share Links are able to be parsed into three parts: (1) the service endpoint (e.g., https://distinct.url/),
(2) the UID part for identifying user storage space as known as the location of the data collection, and (3)
the SID part for identifying the metadata (as shown in the table of the Figure 2) which contains information
about the sharing relationship in the located data collection. After retrieving the metadata, the “ObjectID”
can be used to refer to either a shared object or a share link point to a shared object.
A share link provides conveniences for sharing cloud files in enterprise and external business partners, but
it is insecure since web crawlers can find it by scanning emails and social network and then download it
simply [19]. To address this issue, it introduces a utility named Distinct Share Link to secure sharing cloud
files and to build a secure sharing relationship between two user storage spaces which are isolated data
collections sharded from entire user storage space [20].
A Distinct Share Link is an additional layer attached with permissions, identities, and access conditions
which encapsulates a share link, decreases diffusibility of the share link, adds traceability as well as
controllability to the share link, and then be sent to recipients according to the attached identities. Whenever
a recipient tries to access a Distinct Share Link, the recipient has to present his/her identities for access
condition check. Once the recipient passes all checks, the Distinct Share Link layer then prepares an
ephemeral representation to link to the share link for accessing. Since every Distinct Share Link access
requires own identity (traceability) and controlled by permissions and access conditions (controllability),
the diffusibility and convenience of the Distinct Share Link is decreased accordingly.
Compare to share link, always need to provide different identities when accessing a Distinct Share Link is
inconvenient. To address the problem, it provides a recipient-defined identity function which allows a
recipient to define own identity (e.g., password, secret, etc.) to each received Distinct Share Link. Hence,
the recipient can define easy to remember identities to received Distinct Share Links. It also solves the
share link identity management issue, that is, share links with different identities (e.g., passwords) are too
much information to be remembered by a single recipient.
In addition to aforementioned benefits, the Distinct Share Link further support sandbox feature for creating
a collaborative workspace with external business partners. In the collaborative workspace, every participant
has own permission, and any inappropriate operation (e.g., delete all files) is only performed in a specific
shared folder but not in entire personal user storage space. Note that with cloud storage capabilities, the
performed inappropriate operations are able to be reverted to original, e.g., reverting previous cloud file
version from file change history or reverting deleted shared files from the recycle bin.
The Distinct Share Link is also used to implement the internal cloud file sharing in the proposed Secure
EFSS by building a secure sharing relationship between two isolated user storage spaces (data collections).
Figure 2 depicts an example to explain how Distinct Share Link help build the internal cloud file sharing.
In the top-left of the Figure 2, it represents two internal cloud file sharing relationships: (1) users A and C
receive an object shared from user B and (2) user B receives an object shared from the user C. The callout
box shown at the top-right of the Figure 2 further explains sharing relationships associated with the object
(ID: WXYZ) in the former sharing relationship. It shows that three Distinct Share Links are used to share
the object (ID: WXYZ) to recipients: user A, user B, and an email address. Moreover, all of the three
Distinct Share Links are able to be parsed into three parts: (1) the service endpoint (e.g., https://distinct.url/),
(2) the UID part for identifying user storage space as known as the location of the data collection, and (3)
the SID part for identifying the metadata (as shown in the table of the Figure 2) which contains information
about the sharing relationship in the located data collection. After retrieving the metadata, the “ObjectID”
can be used to refer to either a shared object or a share link point to a shared object.
Figure 2: Example for explaining distinct share link.
A forementioned external and internal sharing cases have similar Distinct Share Link creation and access
processes. The key difference between the two cases is the identity delivery process. In the external sharing
case, the identity is firstly defined by the Distinct Share Link creator, subsequently it is delivered by oral
or identity itself (e.g., email), and finally it might be re-defined by the recipient. The internal sharing case
automatically performs similar process by system with following steps: (1) generate random keys as
identities in the sharing source, (2) encrypt generated identities by a recipient’s public key, and (3) deliver
the encrypted identities from the sharing source to the sharing destination for further usage.
C. Zero-knowledge Cloud Scale File Sharing System
All Cloud files are stream-encrypted by different random symmetric keys and stored in the Swift object
storage when uploading to the proposed Secure EFSS system. This subsection will introduce a Zero-
knowledge Cloud Scale File Sharing System which leverages introduced stacks including User Storage
Space Modeling technique and Distinct Share Link. The Zero-knowledge Cloud Scale File Sharing System
also introduces a new key cascading model [21-22] which uses in this work to manage the random
symmetric keys crossing loose coupled domains and further to protect cloud files from internal/external
unauthorized access attempts.
To develop a Zero-knowledge Cloud Scale File Sharing System, authors take following key enterprise
security concerns and modern cloud system’s scalability and manageability issues into consideration:
(1) Zero-knowledge System: Zero-knowledge means that a system knows nothing about things provided
by users. The user provided things can be contents of cloud files, metadata of user storage spaces, and
encryption keys including users’ passwords used to protect cloud files and user storage spaces, and
the last and the most important part is that it must apply to entire lifecycle of things starting from its
first time appearing in the system to its end, that is, being permanently wiped from the system. To this
end, the Zero-knowledge Cloud Scale File Sharing System is formed by stacking multiple distinct
A forementioned external and internal sharing cases have similar Distinct Share Link creation and access
processes. The key difference between the two cases is the identity delivery process. In the external sharing
case, the identity is firstly defined by the Distinct Share Link creator, subsequently it is delivered by oral
or identity itself (e.g., email), and finally it might be re-defined by the recipient. The internal sharing case
automatically performs similar process by system with following steps: (1) generate random keys as
identities in the sharing source, (2) encrypt generated identities by a recipient’s public key, and (3) deliver
the encrypted identities from the sharing source to the sharing destination for further usage.
C. Zero-knowledge Cloud Scale File Sharing System
All Cloud files are stream-encrypted by different random symmetric keys and stored in the Swift object
storage when uploading to the proposed Secure EFSS system. This subsection will introduce a Zero-
knowledge Cloud Scale File Sharing System which leverages introduced stacks including User Storage
Space Modeling technique and Distinct Share Link. The Zero-knowledge Cloud Scale File Sharing System
also introduces a new key cascading model [21-22] which uses in this work to manage the random
symmetric keys crossing loose coupled domains and further to protect cloud files from internal/external
unauthorized access attempts.
To develop a Zero-knowledge Cloud Scale File Sharing System, authors take following key enterprise
security concerns and modern cloud system’s scalability and manageability issues into consideration:
(1) Zero-knowledge System: Zero-knowledge means that a system knows nothing about things provided
by users. The user provided things can be contents of cloud files, metadata of user storage spaces, and
encryption keys including users’ passwords used to protect cloud files and user storage spaces, and
the last and the most important part is that it must apply to entire lifecycle of things starting from its
first time appearing in the system to its end, that is, being permanently wiped from the system. To this
end, the Zero-knowledge Cloud Scale File Sharing System is formed by stacking multiple distinct
domains with own services, and each of the distinct domain is serving as an additional complementary
security layer to its one-level lower domain. As shown in Figure 3 and Figure 4, they represent
stacking relationships of personal cloud file and shard cloud file situations respectively. In Figure 3,
the lowest OpenStack Domain only provides cloud file storage capability, subsequently the one-level
upper VFS Service Domain servers cloud file metadata management functions and adds additional
stream cloud file and metadata encryption capabilities, and finally the top-level Directory Service
Domain incorporates with User Domain to protect the encryption keys used in cloud file and metadata
protections. In aforementioned stacking relationship, the worth to mention part is that the User Domain
is not in cyberspace instead it is in users’ brain, only users themselves know their own passwords, and
it makes the zero-knowledge system work. Similarly, the Figure 4 further provides a sibling stacking
relationship to the Figure 3 to isolate share participants’ personal VFS Service Domains (see User1
and User2’s distinct Personal Databases in Figure 4). It further makes the zero-knowledge system
work in a multitenant cloud environment. Users do not need to worry about their cloud files when
another user’s storage space was conquered since that the sibling stacking relationship is a one-way
relationship, and there is no way for a lower layer using existing knowledge to derive upper layer
information. This zero-knowledge design also guarantees users have zero-knowledge with each other.
(2) Security Compliance: In addition to data encryption, enterprise security compliance also requires to
support password history management capability. For example, an employee has to change its
password every quarter, and the password cannot be equal to any password used in the last year. The
Zero-knowledge Cloud Scale File Sharing System abstracts a Directory Service Domain to deal with
the password history management requirement (as shown in the Figure 3 and Figure 4). Every time a
user’s password changed, the Directory Service Domain will automatically adjust its internal
relationship to keep the stacking relationship be consist without bothering every lower domains. In
other words, the Zero-knowledge Cloud Scale File Sharing System is also a security compliance
friendly system.
(3) Atomic Objects and Systems: Considering the complex cloud environment, to make everything be
atomic is a good idea. In the Zero-knowledge Cloud Scale File Sharing System, every service in the
domains and every encrypted cloud file is an atomic unit which can be managed (e.g., create, update,
and delete) without worried about dependencies with other atomic units. To achieve this, authors
separate data from computation logic. As mentioned, metadata of a user are aggregated to form a
personal database, and because of choosing MongoDB, the personal database is physically a set of
manageable files stored in the block storage. In terms of cloud files, a cloud file itself is atomic and
can be stored in object storage directly. However, once the cloud file be encrypted, to manage the
encrypted cloud file as an atomic unit is difficult since the encryption key of the cloud file has to be
managed as well. To keep it be atomic, it encrypts the encryption key of the cloud file, then combines
the encrypted encryption key and the encrypted cloud file to form a manageable encrypted object to
replace the original plain-text cloud file, and let the encryption key of the cloud file’s encryption key
be managed by the VFS Service Domain. As shown in the dot line block in the Figure 3 and Figure 4,
the encrypted cloud file (File) and its encryption key (File_Key) is combined as an encrypted object
stored in the OpenStack Swift object storage. The encrypted object is then an atomic unit which can
then be migrated, backup, and managed by a cloud manner. Following that, rest parts are computation
logics which can be categorized by domains (e.g., Directory Service and VFS Service Domains have
their own computation logics), and different types of computation logics can be implemented in virtual
machine or container images which can be managed by the OpenStack Glance image service as atomic
units and be hosted on the OpenStack Nova cloud computing environment.
(4) API Integration: All domains in the Zero-knowledge Cloud Scale File Sharing System are integrated
by REST API, which provides services in domains with flexibility by developing and growing
themselves. With such a integration, every domain only need to focus on satisfying contracts and/or
security layer to its one-level lower domain. As shown in Figure 3 and Figure 4, they represent
stacking relationships of personal cloud file and shard cloud file situations respectively. In Figure 3,
the lowest OpenStack Domain only provides cloud file storage capability, subsequently the one-level
upper VFS Service Domain servers cloud file metadata management functions and adds additional
stream cloud file and metadata encryption capabilities, and finally the top-level Directory Service
Domain incorporates with User Domain to protect the encryption keys used in cloud file and metadata
protections. In aforementioned stacking relationship, the worth to mention part is that the User Domain
is not in cyberspace instead it is in users’ brain, only users themselves know their own passwords, and
it makes the zero-knowledge system work. Similarly, the Figure 4 further provides a sibling stacking
relationship to the Figure 3 to isolate share participants’ personal VFS Service Domains (see User1
and User2’s distinct Personal Databases in Figure 4). It further makes the zero-knowledge system
work in a multitenant cloud environment. Users do not need to worry about their cloud files when
another user’s storage space was conquered since that the sibling stacking relationship is a one-way
relationship, and there is no way for a lower layer using existing knowledge to derive upper layer
information. This zero-knowledge design also guarantees users have zero-knowledge with each other.
(2) Security Compliance: In addition to data encryption, enterprise security compliance also requires to
support password history management capability. For example, an employee has to change its
password every quarter, and the password cannot be equal to any password used in the last year. The
Zero-knowledge Cloud Scale File Sharing System abstracts a Directory Service Domain to deal with
the password history management requirement (as shown in the Figure 3 and Figure 4). Every time a
user’s password changed, the Directory Service Domain will automatically adjust its internal
relationship to keep the stacking relationship be consist without bothering every lower domains. In
other words, the Zero-knowledge Cloud Scale File Sharing System is also a security compliance
friendly system.
(3) Atomic Objects and Systems: Considering the complex cloud environment, to make everything be
atomic is a good idea. In the Zero-knowledge Cloud Scale File Sharing System, every service in the
domains and every encrypted cloud file is an atomic unit which can be managed (e.g., create, update,
and delete) without worried about dependencies with other atomic units. To achieve this, authors
separate data from computation logic. As mentioned, metadata of a user are aggregated to form a
personal database, and because of choosing MongoDB, the personal database is physically a set of
manageable files stored in the block storage. In terms of cloud files, a cloud file itself is atomic and
can be stored in object storage directly. However, once the cloud file be encrypted, to manage the
encrypted cloud file as an atomic unit is difficult since the encryption key of the cloud file has to be
managed as well. To keep it be atomic, it encrypts the encryption key of the cloud file, then combines
the encrypted encryption key and the encrypted cloud file to form a manageable encrypted object to
replace the original plain-text cloud file, and let the encryption key of the cloud file’s encryption key
be managed by the VFS Service Domain. As shown in the dot line block in the Figure 3 and Figure 4,
the encrypted cloud file (File) and its encryption key (File_Key) is combined as an encrypted object
stored in the OpenStack Swift object storage. The encrypted object is then an atomic unit which can
then be migrated, backup, and managed by a cloud manner. Following that, rest parts are computation
logics which can be categorized by domains (e.g., Directory Service and VFS Service Domains have
their own computation logics), and different types of computation logics can be implemented in virtual
machine or container images which can be managed by the OpenStack Glance image service as atomic
units and be hosted on the OpenStack Nova cloud computing environment.
(4) API Integration: All domains in the Zero-knowledge Cloud Scale File Sharing System are integrated
by REST API, which provides services in domains with flexibility by developing and growing
themselves. With such a integration, every domain only need to focus on satisfying contracts and/or
End of preview
Want to access all the pages? Upload your documents or become a member.
Related Documents
Cloud Computing Adoption Framework for Business Clouds: A Multi-Layered Security Approachlg...
|33
|17004
|408
Cloud computing adoption framework: A security framework for business cloudslg...
|18
|17028
|244
Cloud Computing Adoption Framework: A Security Framework for Business Cloudslg...
|8
|1744
|83
Adoption of Cloud Computinglg...
|12
|2951
|100
BCT APPLIED IN CLOUD COMPUTINGlg...
|13
|2314
|21
Project Proposal and Plan, Cloud Security - ITC 568lg...
|12
|2096
|1387