Yun Zhang, Ram Krishnan, Farhan Patwa, and Ravi Sandhu
University of Texas at San Antonio, San Antonio, TX, USA
Cloud computing is revolutionizing the way businesses obtain IT resources. Cloud computing refers to Internet‐based computing that provides on‐demand access to a shared pool of configurable computing resources (Hassan 2011), such as networks, servers, storages, applications, services, etc. Instead of having an application installed on a local PC, applications are hosted in the Cloud. Cloud computing allows users and organizations to conveniently and rapidly get computing resources with minimal management effort, helping organizations avoid focusing on upfront infrastructure costs. Rapid maturity of both commercial and open source cloud platforms greatly contributes to the wider acceptance and application of cloud computing in industry.
Infrastructure‐as‐a‐Service (IaaS) is a cloud service model (Mell and Grance 2011) in which a cloud service provider (CSP) offers compute, storage, and networking resources as a service to its tenants. Tenant refers to an organization that is a customer of a CSP. Traditionally, IaaS providers maintain strict separation between tenants, for obvious reasons. Thus their virtual resources are strongly isolated. For instance, in OpenStack (http://openstack.org), a tenant user does not have the capability to access resources outside its domain. Domain refers to the administrative boundary of that tenant. Similarly, in AWS (http://aws.amazon.com) and Microsoft Azure (https://azure.microsoft.com), tenant refers to an account—an administrative boundary. Users from one account (tenant) by default have no rights to access resources outside that account.
In this chapter, we will introduce the basic cloud access‐control models for the dominant IaaS cloud platforms, including the open source cloud platform OpenStack, and two commercial cloud platforms: AWS and Microsoft Azure. We provide a formal characterization of the access‐control models of these three cloud platforms. For each of the platforms, we also specify novel ways to construct intertenant secure information and resource sharing. The chapter outline is as follows. In Section 4.2, we present some background knowledge: more details of cloud services and the idea of information and resource sharing. In Sections 4.3, 4.4, and 4.5, we introduce the cloud access‐control models for OpenStack, AWS, and Azure, respectively. For each of those platforms, we first give a formal access‐control model specification, and then we extend the access‐control model to include the capability of handling information and resources sharing across tenants. We also give a formal specification of the respective administrative models of information and resources sharing. Section 4.6 concludes the chapter.
Cloud computing has three service models: Infrastructure‐as‐a‐Service (IaaS), Platform‐as‐a‐Service (PaaS), and Software‐as‐a‐Service (SaaS). PaaS offer a development environment to application developers. SaaS offers application and software to end users. We focus on IaaS for two reasons: (i) IaaS is one of the most‐adopted cloud service models today (as compared to PaaS and SaaS), and (ii) IaaS is the foundation of the Cloud, with characteristics such as elasticity, self‐service, etc. By gaining insights into issues related to sharing at this lower level of abstraction, we can also develop better models for higher levels of abstraction of cloud computing, such as PaaS and SaaS.
Note that in the context of IaaS, the unit of sharing consists of virtual resources such as objects in a storage volume, virtual machines (VMs), etc. For models, we mainly focus on administrative aspects. Administrative models are concerned with managing which users and what resources are to be shared, setting up and tearing down platforms for sharing, etc. Examples include a tenant administrator creating a shared secure isolated domain, adding users and resources to and removing them from that domain, inviting other tenants to join the domain, etc.
While cloud technology provides significant convenience to business systems, it also gives great potential to facilitate cyber‐collaborations among organizations. In a cloud community, organizations can share cybersecurity information with other members through a cybersecurity committee to make informed decisions about the community’s security governance. In most cases, organizations maintain their group of security specialists, who manage security policies, conduct security audits, and investigate security‐related events. A community also maintains a group of external security experts who help organizations with security issues. When a cybersecurity incident occurs, the cybersecurity committee members start an incident‐response group with a cross‐organization security team including organizations’ internal security specialists and external security experts, as illustrated in Figure 4.1. Security information about this incident is shared within the incident response group.
Models for information sharing in IaaS are lacking. The concept we used to build our models for sharing comes from Group‐Centric Secure Information Sharing (g‐SIS) (Krishnan et al. 2009), which presents a method to control access among a group of users and objects that is well suited to the collaborative community scenario. In particular, g‐SIS enables sharing using copies of the original information, versus traditional sharing that gives access to original information and resources (Cohen et al. 2002; Pearlman et al. 2002; Shands et al. 2000). Sharing by copy gives additional security protection, since access to the copies can be provided in a tightly controlled environment.
We present access‐control models in a way that fits our best understanding. We abstract a necessary set of components to describe an access‐control model. Based on the cloud platform access‐control model, we build models for secure information and resource sharing. Then we formalize the administrative model. When we discuss the models, we assume one organization has only one tenant in the cloud community. In the discussion of models for sharing, we simply ignore the group entity from cloud access‐control models, since it is essentially a convenience to group users and can easily be incorporated in a more complete description. Instead, we use the term group to mean a group of organizations.
In this section, we will introduce an access‐control model for the OpenStack cloud IaaS platform and demonstrate its flexibility by extending it to include information and resource sharing. The content of this section has been published in (Zhang et al. 2015a). From the cloud provider's perspective, each tenant is an independent customer of the Cloud. From an organization's perspective, in general a single organization may have a single or multiple tenants in a single cloud. For simplicity, we assume here that each organization from the cloud community has exactly one tenant.
A core OpenStack access control (OSAC) model was presented in (Tang and Sandhu 2014), based on the OpenStack Identity API v3 and Havana release. This model comprises nine entities: users, groups, projects, domains, roles, services, object types, operations, and tokens. Hierarchical multitenancy (HMT) (http://openstack.org) is a new feature added to OpenStack since the Juno release. We enhance the OSAC model with HMT, resulting in the OSAC‐HMT model shown in Figure 4.2. In this and other figures in this chapter, the arrows denote binary relations, with the single arrowhead indicating one side and double arrowheads many sides.
Users represent people who are authenticated to access OpenStack cloud resources, while groups are sets of users. HMT does not change user/group management, which is handled at the domain level:
We formalize the OSAC‐HMT model next. Part of it is the same as the OSAC model (Tang and Sandhu 2014).
In this section, we present a model for sharing in OpenStack; we call it the Hierarchical Multitenancy OpenStack Access Control Model with Secure Isolated Domain extension (OSAC‐HMT‐SID model). In our discussion, we assume that a user belongs to one organization in the community, which is consistent with the user home‐domain concept in OpenStack. The concept of a home domain requires that a user can belong to only one domain in OpenStack. OpenStack allows a user to be assigned to projects across domains and access those projects separately using the appropriate tokens.
The OSAC‐HMT‐SID model extends the OSAC‐HMT model to include secure isolated domain (SID) (Zhang et al. 2014) functionality. We build the OSAC‐HMT‐SID model on top of the OSAC‐HMT model. We will present the OSAC‐HMT‐SID model in a way that covers only the additional components compared to the OSAC‐HMT model. Figure 4.3 shows the OSAC‐HMT‐SID model. We use circles to represents entities that can be created multiple times in OpenStack, whereas rectangles represent entities that can be created only once. The additional entity components included in the model are SID, Expert User (EU), Core Project (CP), Secure Isolated Project (SIP), and Open Project (OP):
Following are the formalized concepts we just introduced, as well as the relationships among them.
The administrative aspects of OSAC‐HMT‐SID are discussed informally next. A formal specification is given in Table 4.1.
Table 4.1 OSAC‐HMT‐SID administrative model.
Operation | Authorization Requirement | Update |
SipCreate(uSet, sip) /* A subset of Core Project/domain admin users together create a sip */ | ∀ u ∈ uSet.(u ∈ U ∧ [u, <CP, admin>] ∈ UA) ∧ sip ∉ SIP | assoc(sip) ∪u∈uSet UO(u) SIP′ = SIP ∪ {sip} UA′ = UA ∪ uSet × {<sip, admin>} |
SipDelete(uSet, sip) /* The same subset of Core Project/domain admin users together delete a sip*/ | ∀ u ∈ uSet.(u ∈ U ∧ (u, <sip, admin>) ∈ UA ∧ (u, <CP, admin>) ∈ UA) ∧ assoc.(sip) = ∪u∈uSet UO(u) ∧ sip ∈ SIP | assoc(sip) = NULL SIP′ = SIP – {sip} UA′ = UA – uSet × {<sip, admin>} |
ExpertUserCreate(coreadmin, eu) /* Core Project admin users can create an expert user */ | coreadmin ∈ U ∧ (coreadmin, <CP, admin>) ∈ UA ∧ eu ∉ EU | EU′ = EU ∪ {eu} |
ExpertUserDelete(coreadmin, eu) /* Core Project admin users can delete an expert user */ | coreadmin ∈ U ∧ (coreadmin, <CP, admin>) ∈ UA ∧ eu ∈ EU | EU′ = EU – {eu} |
ExpertUserList(adminuser) /* Admin users of Core Project and SIPs can list expert users */ | adminuser ∈ U ∧ (∃ proj) {proj ∈ ({CP} ∪ SIP) ∧ (adminuser, <proj, admin>) ∈ UA} | |
ExpertUserAdd(adminuser, r, eu, proj) /* Core Project/sip admin can add an expert user to Core Project/sip*/ | adminuser ∈ U ∧ proj ∈ ({CP} ∪ SIP) ∧ (adminuser, <proj, admin>) ∈ UA ∧ eu ∈ EU ∧ r ∈ R | UA′ = UA ∪ (eu, [proj, r]) |
ExpertUserRemove(adminuser, r, eu, proj) /* Core Project/sip admin can remove an expert user from Core Project/sip */ | adminuser ∈ U ∧ proj ∈ ({CP} ∪ SIP) ∧ (adminuser, <proj, admin>) ∈ UA ∧ eu ∈ EU ∧ r ∈ R ∧ (eu, [proj, r]) ∈ UA | UA′ = UA – (eu, [proj, r]) |
UserAdd(adminuser, r, u, sp, p) /* CP/Sip admin can add a user from their home domain Security Project to CP/sip*/ | adminuser ∈ U ∧ (adminuser, <p, admin>) ∈ UA ∧ p ∈ ({CP} ∪ SIP) ∧ r ∈ R ∧ u ∈ U ∧(u, <sp, r>) ∈ UA ∧ SPO(sp) = UO(adminuser) | UA′ = UA ∪ (u, [p, r]) |
UserRemove(adminuser, r, u, sp, p) /* CP/Sip admin can remove a user from the Core Project/sip */ | adminuser ∈ U ∧ (adminuser, <p, admin>) ∈ UA ∧ p ∈ ({CP} ∪ SIP) ∧ r ∈ R ∧ u ∈ U ∧ (u, <sp., r>) ∈ UA ∧ SPO(sp) = UO(adminuser) ∧ (u, [p, r]) ∈ UA | UA′ = UA – (u, [p, r]) |
OpenUserSubscribe(u, member, OP) /* Users subscribe to Open Project */ | u ∈ U ∧ (u, <OP, member>) ∉ USS | USS′ = USS ∪ (u, <OP, member>) |
OpenUserUnsubscribe(u, member, OP) /* Users unsubscribe from Open Project */ | u ∈ U ∧ (u, <OP, member>) ∈ USS | USS′ = USS – (u, <OP, member>) |
CopyObject(u, so1, sp., so2, p) /* Copy object from Security Project to Core Project/SIP */ | sol ∈ SO ∧ sp. ∈ SP ∧ so2 ∉ SO ∧ SOO(so1) = sp ∧ UO(u) = SPO(sp) ∧ u ∈ U ∧ (∃ r ∈ R) {(u, <sp, r>) ∈ UA ∧ (u, <p, r>) ∈ UA)} ∧ p ∈ ({CP} ∪ SIP) | SO′ = SO ∪ {so2} SOO(so2) = p |
ExportObject(adminuser, so1, p. so2 sp) /* Export object from Core Project/SIP to Security Project */ | adminuser ∈ ∪ ∧ (adminuser, <p, admin>) ∈ UA ∧ p ∈ ({CP} ∪ SIP) ∧ so1 ∈ SO ∧ SOO(so1) = p ∧ so2 ∉ SO ∧ sp ∈ SP ∧ (adminuser, <sp., admin>) ∈ UA | SO′ = SO U {so2} SOO(so2) = sp |
Creation of the SID, CP, OP, and SP: A SID with a CP and OP is part of the community cloud functionality the CSP provides to its customers on behalf of organizations responding collaboratively to cyber incidents. The SID, CP, and OP are created when the community cloud is set up. Each domain has one corresponding SP. The creation of a SP is automatically done with the creation of a domain.
Initial user assignment for the SID, CP, OP, and SP: The SID has no admin users assigned on the domain level. The admin users of the CP come from an organization's domain. When a domain is created, the cloud admin assigns a domain admin user as an admin of the CP. We assume there is only one admin user for each domain. Domain admins assign admin users for their SPs. The OP doesn't have an admin user assigned to it. Each user in the Cloud can self‐subscribe or unsubscribe as a member of the OP.
In this section, we investigate a model for the AWS public cloud and demonstrate its flexibility by extending the access‐control model to include information and resource sharing. The content of this section has been published in (Zhang et al. 2015b). As we did for OpenStack, for simplicity, we assume that each organization from the cloud community has only one tenant that is an AWS account.
As a public CSP, AWS provides web services to its customers through AWS accounts. Customers that own an account have access to cloud resources. They can create users and grant them access to cloud resources in the account. A user belongs to a unique account. Users can also access resources in other accounts with federated permissions. We discuss the AWS access control (AWS‐AC) model from two perspectives: within a single account and across accounts. AWS offers a form of policy‐based access control, wherein permissions are defined over cloud resources in a policy file and policies are attached to entities such as users, groups, roles, and resources. Figure 4.4 depicts this model within a single account. In this and other figures in this chapter, dotted lines denote virtual relations between entities, whereas solid lines denote explicit relations. Cross‐account access will be discussed later in the context of Figure 4.5.
The AWS‐AC model has seven components: accounts (A), users (U), groups (G), roles (R), services (S), object types (OT), and operations (OP). We also introduce other entities such as policies and credentials, which are implicitly included in the model:
With these concepts described above, we can formalize the AWS‐AC model as follows.
In this section, we present an access‐control model for AWS with the SID extension (AWS‐AC‐SID). We build the AWS‐AC‐SID model on top of the AWS‐AC model to include SID functionality (Zhang et al. 2014). We present the AWSAC‐SID model so as to cover only the additional components added to the AWS‐AC model. Figure 4.6 shows the AWS‐AC‐SID model.
The additional components included in AWSAC‐SID model are SID, SIP, EU, CP, and OP. These are described next:
The following formalizes these concepts as well as the relationships among them.
For proprietary products such as AWS, we cannot modify the cloud platform. SID functionality can be provided as a security service to all organizations in the SID community by a third party in AWS. The CP and OP are created with the SID. Each organization can join several SIDs with different communities of organizations. Each of these SIDs is isolated from the others.
The roles can be two types, administrative and member, which denote the permission of being able to manage users and permissions only for resources, respectively. The roles CPadmin and SIPadmin represent limited administrative power in the CP or a SIP, respectively, which gives the CP or SIP admin users permission to add and remove other users from their home account to the CP or a SIP. The roles CPmember, OPmember, and SIPmember represent operative permissions that can be given to normal users to access the CP, the OP, or a SIP. Since roles in AWS are local, SIPadmin and SIPmember are two sets of roles, separately representing the set of admin roles and the set of member roles in all SIPs; while CPadmin, CPmember, and OPmember are single roles in an account.
The administrative aspects of the AWS‐AC‐SID model are discussed informally below. A formal specification is given in Table 4.2.
Table 4.2 AWS‐AC‐SID administrative model.
Operation | Authorization Requirement | Update |
SipCreate(subuSet, sip) /* A subset of organization security admin users together create a sip */ | ∀ u ∈ subuSet.(u ∈ uSet) ∧ sip ∉ SIP | assoc(sip) = ∪u∈subuSet UO(u) SIP′ = SIP ∪ {sip} |
SipDelete(subuSet, sip) /* The same subset of security admin users together delete a sip*/ | ∀ u ∈ subuSet.(u ∈ uSet) ∧ sip ∈ SIP ∧ assoc(sip) = ∪u∈subuSetUO(u) | assoc(sip) = NULL SIP′ = SIP – {sip} |
CpUserAdd(adminu, u) /* CP admin adds a user from their home account to CP */ | adminu ∈ uSet ∧ u ∈ U ∧ UO(u) = UO(adminu) | VUR′ = VUR ∪ {(u, CPmember)} |
CpUserRemove(adminu, u) /* CP admin removes a user from CP */ | adminu ∈ uSet ∧ u ∈ U ∧ UO(u) = UO(adminu) ∧ (u, CPmember) ∈ VUR | VIR′ = VIR –{(u, CPmember)} |
SIPUserAdd(adminu, u, r, sip) /* Sip admin adds a user from their home account to SIP*/ | adminu ∈ uSet ∧ UO(adminu) ∈ assoc.(sip) ∧ u ∈ U ∧ r ∈ SIPmember ∧ RO(r) = sip ∧ sip ∈ SIP ∧ UO(u) = UO(adminu) | VUR′ = VUR ∪ {(u, r)} |
SIPUserRemove(adminu, u, r, sip) /* Sip admin removes a user from SIP */ | adminu ∈ uSet ∧ UO(adminu) ∈ assoc.(sip) ∧ u ∈ U ∧ r ∈ SIPmember ∧ RO(r) = sip ∧ (u, r) ∈ VUR ∧ sip ∈ SIP ∧ UO(u) = UO(adminu) | VUR′ = VUR – {(u, r)} |
OpenUserAdd(u) /* Users add themselves to OP*/ | u ∈ U ∧ UO(u) ∈ UO(uSet) | VUR′ = VUR ∪ {(u, OPmember)} |
OpenUserRemove(u) /* Users remove themselves from OP */ | u ∈ U ∧ UO(u) ∈ UO(uSet) ∧ (u, OPmember) ∈ VUR | VUR′ = VUR – {(u, OPmember)} |
CpEUserAdd(adminu, eu) /* CP admin adds an expert user to CP */ | adminu ∈ uSet ∧ eu ∈ EU | VUR′ = VUR ∪ {(eu, CPmember)} |
CpEUserRemove(adminu, eu) /* CP admin removes an expert user from CP */ | adminu ∈ uSet ∧ eu ∈ EU ∧ (eu, CPmember) ∈ VUR | VUR′ = VUR – {(eu, CPmember)} |
SipEUserAdd(adminu, eu, r, sip) /* SIP admin adds an expert user to SIP */ | adminu ∈ uSet ∧ UO(adminu) ∈ assoc(sip) ∧ eu ∈ EU ∧ r ∈ SIPmember ∧ RO(r) = sip ∧ sip ∈ SIP | VUR′ = VUR ∪ {(eu, r)} |
SipEUserRemove(adminu, eu, r, sip) /* SIP admin removes an expert user from SIP */ | adminu ∈ uSet ∧ UO(adminu) ∈ assoc(sip) ∧ eu ∈ EU ∧ r ∈ SIPmember ∧ RO(r) = sip ∧ (eu, r) ∈ VUR ∧ sip ∈ SIP | VUR′ = VUR – {(eu, r)} |
CpCopyObject(u, o1, o2) /*Users copy objects from organization accounts to CP */ | o1 ∈ O ∧ 02 ∉ O ∧ UO(u) = 00(o1) ∧ u ∈ U ∧ (u, CPmember) ∈ VUR | O′ = O ∪ {o2} OO(o2) = CP |
CpExportObject(adminu, o1, o2) /* Admin users export objects from CP to organizations accounts */ | adminu ∈ uSet ∧ o1 ∈ O ∧ OO(o1) = CP ∧ o2 ∉ O | O′ = O ∪ {o2} OO(o2) = UO(adminu) |
SipCopyObject(u, r, o1, o2, sip) /*Users copy objects from organization accounts to a SIP */ | o1 ∈ O ∧ o2 ∉ O ∧ UO(u) = OO(o1) ∧ u ∈ U ∧ r ∈ SIPmember ∧ RO(r) = sip ∧ (u, r) ∈ VUR ∧ sip ∈ SIP | O′ = O ∪ {o2} OO(o2) = sip |
SipExportObject(adminu, o1, o2, sip) /* Admin users export objects from SIP to organization accounts */ | adminu ∈ uSet ∧ UO(adminu) ∈ assoc(sip) ∧ o1 ∈ O ∧ OO(o1) = sip ∧ o2 ∉ O | O′ = O ∪ {o2} OO(o2) = UO(adminu) |
Initially set up the SID: In the case of one SID serving one community of organizations, we can initially set up the SID with one CP and one OP. The member organizations of the SID are fixed. Let uSet denote a fixed group of security admin users from all organizations of the community, with one admin user for one organization. Each organization in the community has equal limited administrative power in the SID, which is carried through uSet. The SID maintains uSet as a core group of admin users in the SID. Only users from uSet later can dynamically create SIPs in the SID.
With the setting up of the SID, users in uSet automatically get limited administrative permission in the CP, represented by the role CPadmin. With this role, CP admin users can add and remove other users from their home account to the CP. The OP is open for all users from the community of organizations. No admin users are needed for the OP. All users can add themselves to the OP with the role OPmember as a normal member user.
In this section, we introduce a model for the Microsoft Azure cloud and demonstrate its flexibility by extending the access‐control model to include information and resource sharing. As we did for AWS, we assume that each organization from the cloud community has only one tenant that is an Azure account.
In Azure, any user has the ability to create an Azure account. The user who creates an Azure account will be the owner and super‐administrative user of that account. Local users created in an Azure Active Directory (AAD) can create their own Azure accounts that are isolated from the parent account. Azure has two main components to manage users' access to resources in the Cloud: AAD and Subscriptions (Sub). To use resources in Azure, a user has to be assigned to a subscription. AAD helps to manage users, including both local AAD users and other valid Microsoft users. Azure offers a form of RBAC wherein permissions are defined over cloud resources within roles in resource groups. Roles can then be assigned to users. Roles are predefined in Azure.
The Azure Access Control (Azure‐AC) model has 14 entities: Accounts (A), Azure Active Directory (AAD), Subscription (Sub), Azure Active Directory Role (AADR), Azure Active Directory User (AADU), Non‐Azure Active Directory User (NAADU), Group (G), Resource Group (RG), Role (R), Subscription Role (SubR), Resource (RS), Service (S), Object Type (OT), and Operation (OP), as shown in Figure 4.8:
With these concepts described, we can formalize the Azure‐AC model as follows.
In this section, we present an access‐control model for Azure with the SID extension (Azure‐AC‐SID). We extend the Azure‐AC model to include SID functionality (Zhang et al. 2014). We present the Azure‐AC‐SID model so as to cover only the additional components added to the Azure‐AC model. Figure 4.9 shows the Azure‐AC‐SID model.
The following introduces the Azure‐AC‐SID model. The additional components included are Secure Isolated Domain (SID), Secure Isolated Project (SIP), Expert User (EU), User (U), Core Project (CP), and Open Project (OP):
The following formalizes these concepts, as well as the relationships among them.
Similar to the AWS‐AC‐SID model, each SID has a CP and an OP as a security service provided to all organizations in the SID community. The CP and OP are created with the SID. Each organization can join different SIDs with different communities of organizations. Each of these SIDs is isolated from the others. We only discuss the model in which the SIDs are manually set up, serving different communities of organizations in the Azure public cloud.
We design a SID manager as an automated agent that serves cloud communities of organizations and manages SIDs and their constituent components throughout their life cycle. The SID manager processes SID requests from communities of organizations and maintains a separate SID for each community. Within each SID, it facilitates the creation and deletion of SIPs. Each time a cyber‐collaboration request is sent to the SID manager, it creates a new subscription, assigning the subscription to the group of organizations that made the request. After the collaboration is done, the SIP is deleted.
Considering that Azure already has dedicated roles for managing subscriptions and AAD, we will use those existing AAD administrative roles and subscription roles to manage SIPs, the CP, and the OP in a SID. Azure provides five AAD admin roles and two subscription admin roles. For simplicity, we will constrain the administrative roles to include only the AAD global admin role and subscription co‐admin role. Azure also provides a set of operative roles in RGs, which allows users to have permission to access cloud resources.
To make role assignment simple and clear, we constrain roles to be two types, administrative roles and member roles, which denote the permission of being able to manage users and permissions only for accessing cloud resources. We use the admin role SIDAdmin to represent all admin permissions a user can get from AAD and subscriptions. We use the member role SIDmember to represent all normal roles a user can have in a RG. Admin users have the capability to add and remove other users from their home organizations to a CP subscription or a SIP subscription. Member users can be added/removed from/to a project subscription inside a SID. Member users are those who have access to real cloud services and resources, like creating or deleting a VM.
The administrative aspects of the Azure‐AC‐SID model are discussed informally next. A formal specification is given in Table 4.3.
Table 4.3 Azure‐AC‐SID administrative model.
Operation | Authorization Requirement | Update |
SipCreate(uSet, sip, sid) /* A set of organization security admin users together create a sip */ | ∀ u ∈ uSet.(u ∈ uSet) ∧ sip ∉ SIP | assoc(sid) = ∪u∈uSetUO(u) SIPO(sip) = sid SIP′ =SIP ∪ {sip} |
SipDelete(subuSct, sip, sid) /* The same subset of security admin users together delete a sip*/ | ∀ u ∈ subuSet.(u ∈ uSet) ∧ sip ∈ SIP ∧ assoc(sid) = ∪u∈subuSetUO(u) ∧ SIPO(sip) = sid | assoc(sid) = NULL SIPO(sip) = NULL SIP′ = SIP – {sip} |
UserAdd(adminu, u, p, sid) /* Admin users add a user from their home account to a Cp/Sip */ | adminu ∈ uSet ∧ u ∈ U ∧ UO(u) = UO(adminu) ∧ p ∈ (CP ∪ SIP) ∧ (CPO(p) = sid ∪ SIP(p) = sid) | UA′ = ∃ rg ∈ p.(UA ∪ {(u, [rg, SIDmember])}) |
UserRemove(adminu, u, p, sid) /* Admin users remove a user from a Cp/Sip */ | adminu ∈ uSet ∧ u ∈ U ∧ UO(u) = UO(adminu) ∧ p ∈ (CP ∪ SIP) ∧ (CPO(p) = sid ∪ SIP(p) = sid) ∧ ∃ rg ∈ p.(UA ∪ {(u, [rg, SIDmember])}) | UA′ = UA – {(u, [rg, SIDmember])} |
OpenUserAdd(u, op, sid) /* Users add themselves to a Op */ | u ∈ U ∧ UO(u) ∈ UO(uSet) ∧ op ∈ OP ∧ OPO(op) = sid | UA′ = ∃ rg ∈ op.(UA ∪ {(u, [rg, SIDmember])}) |
OpenUserRemove(u, op sid) /* Users remove themselves from a Op */ | u ∈ U ∧ UO(u) ∈ UO(uSet) ∧ op ∈ OP ∧ OPO(op) = sid ∧ ∃ rg ∈ op.(UA ∪ {(u, [rg, SIDmember])}) | UA′ = UA – {(u, [rg, SIDmember])} |
ExpertUserAdd(adminu, eu, p, sid) /* Admin users add an expert user to a Cp/Sip */ | adminu ∈ uSet ∧ eu ∈ EU ∧ p ∈ (CP ∪ SIP) ∧ (CPO(p) = sid ∪ SIPO(p) = sid) | UA′ = ∃ rg ∈ p.(UA ∪ {(eu, [rg, SIDmember])}) |
ExpertUserRemove(adminu, eu, p, sid) /* Admin users remove an expert user from a Cp/Sip */ | adminu ∈ uSet ∧ eu ∈ EU ∧ p ∈ (CP ∪ SIP) ∧ (CPO(p) = sid ∪ SIPO(p) = sid) ∧ ∃ rg ∈ p.(UA ∪ {(eu, [rg, SIDmember])}) | UA′ = UA – {(eu, [rg, SIDmember])} |
CopyObject(u, o1, o2, p) /*Users copy objects from organization accounts to a Cp/Sip */ | o1 ∈ O ∧ o2 ∉ O ∧ UO(u) = OO(o1) ∧ u ∈ U ∧ p ∈ (CP ∪ SIP) ∧ 3 rg.((u, [rg, SIDmember]) ∈ UA) | O′ = O ∪ {o2} OO(o2) = p |
ExportObject(adminu, o1, o2, p) /* Admin users export objects from a Cp/Sip to organization accounts */ | adminu ∈ uSet ∧ o1 ∈ O ∧ o2 ∉ O ∧ OO(o1) = p ∧ p ∈ (CP ∪ SIP) ∧ ∃ rg.((adminu, [rg, SIDadmin]) ∈ UA) | O′ = O ∪ {o2} OO(o2) = UO(adminu) |
Initially set up the SID: For every community of organizations that will have cyber collaboration, we offer one SID associated with the community. The number of organizations associated with the SID is fixed. Let uSet denotes the fixed group of security admin users, each of which represents one and only one organization in the community. Each organization in the community has equal limited administrative power in the SID, which is carried through uSet. The SID maintains uSet as a core group (Sandhu et al. 2011) of SID admin users. Only users from uSet later can dynamically create SIPs in the SID.
Inside the SID, organizations can request multiple SIPs for the convenience of different cyber collaborations. The number of SIPs depends on how much collaboration is initialized by the group of organizations. A SID is initially set up with a CP and an OP, and organizations can then automatically request to create and delete SIPs, as well as add or remove users to/from SIPs. With the initialization of a SID, admin users from uSet automatically get limited administrative permission in a CP in a SID, which is represented by role SIDadmin. Normal users from the community automatically get permissions to be able to add them to the OP with role the SIDmember.
In this chapter, we introduced access‐control models for OpenStack, AWS, and Microsoft Azure cloud IaaS platforms. We identified fundamental elements of access control in cloud IaaS. We also explored models for information and resource sharing in cybersecurity to show the flexibility of those cloud access‐control models. We designed these models mainly based on the concept and architecture of the cloud platforms. We gave formal descriptions of administrative models, which provide a clear specification of how the users and resources are managed and controlled in the model.