Withdrawn Draft

Warning Notice

The attached draft document has been withdrawn, and is provided solely for historical purposes.
It has been superseded by the document identified below.

Withdrawal Date July 31, 2020

Original Release Date April 1, 2020

Superseding Document

Status Final

Series/Number NIST Special Publication (SP) 800-210

Title General Access Control Guidance for Cloud Systems

Publication Date July 2020

DOI https://doi.org/10.6028/NIST.SP.800-210

CSRC URL https://csrc.nist.gov/publications/detail/sp/800-210/final

Additional Information
 1 Draft NIST Special Publication 800-210
2

3 General Access Control Guidance for

4 Cloud Systems
5
6
7 Vincent C. Hu
8 Michaela Iorga
9 Wei Bao
10 Ang Li
11 Qinghua Li
12 Antonios Gouglidis
13
14
15
16
17
18 This publication is available free of charge from:
19 https://doi.org/10.6028/NIST.SP.800-210-draft
20
21
22

C O M P U T E R S E C U R I T Y
23

24
25 Draft NIST Special Publication 800-210
26

27 General Access Control Guidance for

28 Cloud Systems
29

30 Vincent C. Hu
31 Michaela Iorga
32 Computer Security Division
33 Information Technology Laboratory
34
35 Wei Bao
36 Ang Li
37 Qinghua Li
38 Department of Computer Science and Computer Engineering
39 University of Arkansas
40
41 Antonios Gouglidis
42 School of Computing and Communications
43 Lancaster University
44
45 This publication is available free of charge from:
46 https://doi.org/10.6028/NIST.SP.800-210-draft
47
48
49 April 2020
50
51

52
53
54 U.S. Department of Commerce
55 Wilbur L. Ross, Jr., Secretary
56
57 National Institute of Standards and Technology
58 Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology
 59 Authority

60 This publication has been developed by NIST in accordance with its statutory responsibilities under the
61 Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law
62 (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including
63 minimum requirements for federal information systems, but such standards and guidelines shall not apply
64 to national security systems without the express approval of appropriate federal officials exercising policy
65 authority over such systems. This guideline is consistent with the requirements of the Office of Management
66 and Budget (OMB) Circular A-130.

67 Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and
68 binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these
69 guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
70 Director of the OMB, or any other federal official. This publication may be used by nongovernmental
71 organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
72 however, be appreciated by NIST.

73 National Institute of Standards and Technology Special Publication 800-210

74 Natl. Inst. Stand. Technol. Spec. Publ. 800-210, 34 pages (April 2020)
75 CODEN: NSPUE2
76
77 This publication is available free of charge from:
78 https://doi.org/10.6028/NIST.SP.800-210-draft

79 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
80 experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
81 endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
82 available for the purpose.

83 There may be references in this publication to other publications currently under development by NIST in accordance
84 with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies,
85 may be used by federal agencies even before the completion of such companion publications. Thus, until each
86 publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For
87 planning and transition purposes, federal agencies may wish to closely follow the development of these new
88 publications by NIST.
89 Organizations are encouraged to review all draft publications during public comment periods and provide feedback to
90 NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at
91 https://csrc.nist.gov/publications.

92
93 Public comment period: April 1, 2020 to May 15, 2020
94 National Institute of Standards and Technology
95 Attn: Computer Security Division, Information Technology Laboratory
96 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
97 Email: sp800-210-comments@nist.gov
98
99 All comments are subject to release under the Freedom of Information Act (FOIA).
100
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

101
102 Reports on Computer Systems Technology

103 The Information Technology Laboratory (ITL) at the National Institute of Standards and
104 Technology (NIST) promotes the U.S. economy and public welfare by providing technical
105 leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
106 methods, reference data, proof of concept implementations, and technical analyses to advance the
107 development and productive use of information technology. ITL’s responsibilities include the
108 development of management, administrative, technical, and physical standards and guidelines for
109 the cost-effective security and privacy of other than national security-related information in federal
110 information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and
111 outreach efforts in information system security, and its collaborative activities with industry,
112 government, and academic organizations.
113
114 Abstract
115
116 This document presents cloud access control characteristics and a set of general access control
117 guidance for cloud service models: IaaS (Infrastructure as a Service), PaaS (Platform as a Service),
118 and SaaS (Software as a Service). Different service delivery models require managing different
119 types of access on offered service components. Such service models can be considered hierarchical,
120 thus the access control guidance of functional components in a lower-level service model are also
121 applicable to the same functional components in a higher-level service model. In general, access
122 control guidance for IaaS is also applicable to PaaS and SaaS, and access control guidance for IaaS
123 and PaaS is also applicable to SaaS. However, each service model has its own focus with regard
124 to access control requirements for its service.
125
126 Keywords
127
128 access control; access control mechanism; Cloud; cloud systems.
129
130
131 Acknowledgements
132
133 The authors, Vincent C. Hu of the National Institute of Standards and Technology (NIST), Bao
134 Wei, Ang Li, and Qinghua Li of Department of Computer Science and Computer Engineering
135 University of Arkansas, and Antonios Gouglidis of School of Computing and Communications
136 Lancaster University wish to thank Isabel Van Wyk and David Ferraiolo (NIST) who reviewed
137 drafts of this document. The authors also gratefully acknowledge and appreciate the comments
138 and contributions made by government agencies, private organizations, and individuals in
139 providing direction and assistance in the development of this document.
140

ii
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

141 Call for Patent Claims

142 This public review includes a call for information on essential patent claims (claims whose use
143 would be required for compliance with the guidance or requirements in this Information
144 Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may be
145 directly stated in this ITL Publication or by reference to another publication. This call also includes
146 disclosure, where known, of the existence of pending U.S. or foreign patent applications relating
147 to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.

148 ITL may require from the patent holder, or a party authorized to make assurances on its behalf, in
149 written or electronic form, either:

150 a) assurance in the form of a general disclaimer to the effect that such party does not hold and
151 does not currently intend holding any essential patent claim(s); or
152 b) assurance that a license to such essential patent claim(s) will be made available to
153 applicants desiring to utilize the license for the purpose of complying with the guidance or
154 requirements in this ITL draft publication either:
155 i) under reasonable terms and conditions that are demonstrably free of any unfair
156 discrimination; or
157 ii) without compensation and under reasonable terms and conditions that are
158 demonstrably free of any unfair discrimination.

159 Such assurance shall indicate that the patent holder (or third party authorized to make assurances
160 on its behalf) will include in any documents transferring ownership of patents subject to the
161 assurance, provisions sufficient to ensure that the commitments in the assurance are binding on
162 the transferee, and that the transferee will similarly include appropriate provisions in the event of
163 future transfers with the goal of binding each successor-in-interest.

164 The assurance shall also indicate that it is intended to be binding on successors-in-interest
165 regardless of whether such provisions are included in the relevant transfer documents.

166 Such statements should be addressed to sp800-210-comments@nist.gov.

iii
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

167 Executive Summary

168 Cloud systems have been developed over time and conceptualized through the combination of
169 software, hardware components, and virtualization technologies. Characteristics of the cloud, such
170 as resource pooling, rapid elasticity, and pay-as-you-go services, accelerated its wide adoption by
171 industry, government, and academia. Specifically, cloud systems offer application services, data
172 storage, data management, networking, and computing resources management to consumers over
173 a network (the internet in general). Despite the great advancements of cloud systems, concerns
174 have been raised about the offered level of security and privacy. The importance of these concerns
175 becomes more evident when considering the vast number of users who have adopted cloud services.
176
177 This document presents cloud access control (AC) characteristics and a set of general access
178 control guidance for cloud service models—IaaS (Infrastructure as a Service), PaaS (Platform as a
179 Service), and SaaS (Software as a Service)—without considering deployment models (e.g., public
180 cloud, private cloud), which require another layer of access control that depends on the security
181 requirements of the business function or the organization of deployment for which the cloud
182 system is implemented. Different service delivery models need to consider managing different
183 types of access on offered service components. Such considerations can be hierarchical, such as
184 how the access control considerations of functional components in a lower-level service model
185 (e.g., networking and storage layers in the IaaS model) are also applicable in the same functional
186 components in a higher-level service model (e.g., networking and storage in PaaS and SaaS
187 models). In general, access control considerations for IaaS are also applicable to PaaS and SaaS,
188 and access control considerations for IaaS and PaaS are also applicable to SaaS. Therefore, AC
189 guidance for IaaS is applicable to PaaS and SaaS, and AC guidance for IaaS and PaaS is also
190 applicable to SaaS. However, each service model has its own focus with regard to access control
191 requirements for its service.
192

iv
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

193 Table of Contents

194 Executive Summary ................................................................................................................... iv

195 1 Introduction ......................................................................................................................... 1

196 1.1 Purpose ..................................................................................................................................... 1

197 1.2 Scope ........................................................................................................................................ 1
198 1.3 Audience ................................................................................................................................... 1
199 1.4 Document Structure .................................................................................................................. 2

200 2 Cloud Access Control Characteristics.............................................................................. 3

201 3 Access Control Guidance for IaaS .................................................................................... 8

202 3.1 Guidance for Network ............................................................................................................... 8

203 3.2 Guidance for Hypervisor ........................................................................................................... 8
204 3.3 Guidance for Virtual Machines .................................................................................................. 9
205 3.4 Guidance for APIs ..................................................................................................................... 9
206 3.5 Recommendations for IaaS Access Control ............................................................................. 9

207 4 Access Control System for PaaS .................................................................................... 11

208 4.1 Guidance for Memory Data ..................................................................................................... 11

209 4.2 Guidance for APIs ................................................................................................................... 11
210 4.3 Recommendations for PaaS Access Control .......................................................................... 11

211 5 AC System for SaaS ......................................................................................................... 13

212 5.1 Guidance for Data Owner’s Control ........................................................................................ 13

213 5.2 Guidance for Confidentiality .................................................................................................... 13
214 5.3 Guidance for Privilege Management ....................................................................................... 14
215 5.4 Guidance for Multiple Replicas of Data ................................................................................... 14
216 5.5 Guidance for Multi-tenancy ..................................................................................................... 14
217 5.6 Guidance for Attribute and Role Management........................................................................ 14
218 5.7 Guidance for Policies .............................................................................................................. 15
219 5.8 Guidance for APIs ................................................................................................................... 15
220 5.9 Recommendations for SaaS Access Control .......................................................................... 15

221 6 Guidance for Inter and Intra Operation ........................................................................... 18

222 7 Conclusions ...................................................................................................................... 20

223 References................................................................................................................................. 21

224 List of Appendices

225 Guidance and SP 800-53 Revision 4 AC Control Mapping ........................... 25

226

v
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

227 List of Figures

228 Figure 1: The general architecture of a cloud system ................................................................................... 4

229 Figure 2: The service models of a cloud system........................................................................................... 4
230 Figure 3: Accesses managed by the cloud provider and the consumer ....................................................... 5
231 Figure 4: The multi-tenant architecture of the SaaS model ........................................................................ 13
232 Figure 5: The external collaboration (inter-operation) between different Clouds........................................ 18
233 Figure 6: The internal collaboration (intra-operation) within the same Cloud ............................................. 19

234 List of Tables

235 Table 1: Potential policy rules expressed by Subject, Action, Object for IaaS AC policy .. Error! Bookmark
236 not defined.
237 Table 2: Potential policy rules expressed by Subject, Action, Object for PaaS AC policy Error! Bookmark
238 not defined.
239 Table 3: Potential policy rules expressed by Subject, Action, Object for SaaS AC policy Error! Bookmark
240 not defined.
241
242

vi
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

243 1 Introduction

244 1.1 Purpose

245 Access control (AC) dictates how principals (i.e., users and processes) can access resources based
246 on defined AC policies to protect sensitive data and critical computing resources in the cloud.
247 Considering the heterogeneity and remote nature of the cloud service models, AC and its general
248 concepts should be revisited. In recent years, many works have focused on AC in cloud systems
249 [22, 24, 25, 26]. However, these are primarily ad hoc solutions targeted at specific cloud
250 applications and do not provide comprehensive views of cloud AC.
251
252 Cloud deployment models (e.g., public cloud, private cloud, community cloud, hybrid cloud, etc.)
253 are configured by the scope of cloud users, services, and resources based on service requirements.
254 This document presents a set of general AC guidance for cloud service models independent from
255 its deployment models because it requires another layer of access control that depends on the
256 security requirements of the business function for which the cloud system is used. As shown in
257 Figure 3, different service models require the management of different types of access for the
258 components of the offered service. Since such service models can be considered hierarchical, the
259 AC considerations of functional components in a lower-level (according to Figure 2) service model
260 (e.g., networking and storage layers in the IaaS model) are also applicable to the same functional
261 components in a higher-level service model (e.g., networking and storage in PaaS and SaaS
262 models). In general, AC considerations for IaaS are also applicable to PaaS and SaaS, and AC
263 considerations for IaaS and PaaS are also applicable to SaaS. Thus, AC guidance for IaaS is
264 applicable to PaaS and SaaS, and AC guidance for IaaS and PaaS is also applicable to SaaS.
265 However, each service model has its own focus with regard to AC. For instance, an IaaS provider
266 may put more effort into virtualization control, and in addition to the virtualization control, an
267 SaaS provider needs to consider data security and the privacy of services it provides.

268 1.2 Scope

269 This document focuses on providing guidance for access control systems that are applied to an
270 organization’s cloud implementation. It does not prescribe the internal cloud access control
271 standards that an organization may need in their enterprise systems or within a community other
272 than the organization itself.

273 1.3 Audience

274 The intended audience for this document is an organizational entity that implements access control
275 solutions for sharing information in cloud systems. This document assumes that readers are
276 familiar with the cloud and access (authorization) control systems and have basic knowledge of
277 operating systems, databases, networking, and security. Given the constantly changing nature of
278 the information technology (IT) industry, readers are strongly encouraged to take advantage of
279 other documents—including those listed in this document—for more current and detailed
280 information.

1
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

281 1.4 Document Structure

282 The sections and appendices presented in this document are as follows:

283 • Section 1 states the purpose and scope of access control and cloud systems.

284 • Section 2 gives overviews of cloud access control characteristics.

285 • Section 3 discusses guidance for access control systems for IaaS (Infrastructure as a
286 Service).

287 • Section 4 discusses guidance for access control systems for PaaS (Platform as a Service).

288 • Section 5 discusses guidance for access control systems for SaaS (Software as a Service).

289 • Section 6 discusses guidance for inter- and intra-cloud operations.

290 • Section 7 concludes the document with future directions.

291

2
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

292 2 Cloud Access Control Characteristics

293 With the support of different service models, cloud systems can provide a wide range of services
294 to its end-users, developers, and system administrators. Cloud systems have been developed over
295 time and conceptualized through the combination of software, hardware components, and
296 virtualization technologies. Characteristics of the cloud, such as resource pooling, rapid elasticity,
297 and pay-as-you-go services, have accelerated its wide adoption by industry, government, and
298 academia. Specifically, cloud systems offer application services, data storage, data management,
299 networking, and computing resources management to consumers 1 over a network (and the internet
300 in general). Examples of popular cloud applications include web-based email services (e.g.,
301 Google’s Gmail, Microsoft’s Office 365 Outlook), data storage (e.g., Google Drive, Microsoft’s
302 OneDrive, Dropbox) for end-users, and customer relationship management and business
303 intelligence systems (e.g., CRM Cloud, Workday) for business management. Despite the great
304 advancements of cloud systems, concerns have been raised about offered levels of security and
305 privacy. The importance of these concerns becomes more evident when considering the vast
306 number of users that have adopted cloud services [1].
307
308 According to NIST, cloud computing is defined as “a model for enabling ubiquitous, convenient,
309 on-demand network access to a shared pool of configurable computing resources (e.g., networks,
310 servers, storage, applications, and services) that can be rapidly provisioned and released with
311 minimal management effort or service provider interaction” [2]. Cloud computing systems may be
312 deployed privately, hosted on the premises of a cloud customer or a provider’s dedicated
313 infrastructure, or hosted publicly by one or more cloud service providers. The system may be
314 configured and used by one consumer or a group of trusted partners or support multi-tenancy and
315 be used publicly by different end-users that acquire the service. Depending on the type of cloud
316 deployment model, the cloud may have limited private computing resources or access to large
317 quantities of remotely accessed resources. The different deployment models present a number of
318 trade-offs in how customers can control their resources as well as the scale, cost, and availability
319 of those resources [3]. As depicted in Figure 1, the architecture of a cloud system is composed, in
320 general, by layers of functions:
321 • VM (Virtual Machine), including:
322 - Applications
323 - Application Programming Interface (API)
324 - Operating System (OS)
325 • Hypervisor
326 • Storage
327 • Networking
328 • Hardware

329 A cloud service can provide access to software applications such as email or office productivity
330 tools (i.e., the Software as a Service, or SaaS, service model), an environment for customers to
331 build and operate their own software (i.e., the Platform as a Service, or PaaS, service model), or
332 network access to virtualized computing resources such as processing power and storage (i.e., the

1 In this document, consumers refer to system planners, program managers, technologists, and others adopting cloud computing
as clients of cloud service for their end users. Users are generally applicable to both consumers and end users.

3
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

333 Infrastructure as a Service, or IaaS, service model). The different service models have different
334 strengths and are suitable for different customers and business objectives [3], as illustrated in
335 Figure 2.
336
337 A cloud system that deploys the SaaS model can be accessible over a network by an end user
338 utilizing various client devices (e.g., a thin client interface, such as a web browser, for accessing a
339 web-based email application) or via a program with the correct set of interfaces whose execution
340 would enable communication with a cloud application. In the SaaS model, an application user is
341 limited to user-specific application configuration settings and does not manage or control the
342 underlying cloud infrastructure, which typically includes the network, servers, operating systems,
343 storage, or individual applications.
344

345
346

347 Figure 1: The general architecture of a cloud system

348

349
350 Figure 2: The service models of a cloud system

4
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

351 The PaaS model in a cloud system allows developers to create and deploy applications onto the
352 cloud infrastructure using programming languages, libraries, services, and tools. A software
353 developer does not manage or control the underlying cloud infrastructure but has control over the
354 deployed applications (software) and, possibly, configuration settings for the application-hosting
355 environment.
356
357 An IaaS cloud service provides computation, virtualized storage, and network resources to
358 consumers for deploying and running arbitrary software, including operating systems and
359 applications. Consumers may have control over virtual storage, virtualized network components,
360 and the ability to deploy their own VMs and applications.
361

362
363
364 Figure 3: Accesses managed by the cloud provider and the consumer

365 The five essential characteristics that affect AC system design are summarized as follows [2]:
366
367 1. Broad network access: Cloud services are available over the network and accessible
368 through standard mechanisms that promote use by heterogeneous thick and thin client
369 platforms (e.g., mobile phones, tablets, laptops, workstations). This raises security
370 concerns with regard to network access. For example, denial of service (DoS) attacks can

5
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

371 be launched against a cloud system, rendering its resources unavailable to legitimate users.
372 Thus, AC for network access should be managed.
373
374 2. Resource pooling: The computing resources of a cloud system (e.g., storage, memory,
375 processing, network bandwidth) are pooled to serve multiple consumers using a multi-
376 tenant model through different physical and virtual resources, each dynamically assigned
377 and reassigned according to consumer demands. Information may be leaked if the resource
378 allocated to a consumer can be accessed by another co-located consumer or if the allocated
379 resource, such as memory, is not wiped before being reallocated to another consumer.
380 There is also a sense of location independence in that the consumer generally has no control
381 over or knowledge of the exact location of the provided resources. Location may be
382 specified at a higher level of abstraction (e.g., country, state, data center) that brings
383 security concerns. Therefore, methods for implementing resource pooling while ensuring
384 the isolation of shared resources should be considered in the AC design.
385
386 3. Rapid elasticity: Cloud services can be elastically provisioned and released—automatically,
387 in some cases—to rapidly scale outward and inward commensurate with demands. To the
388 consumer, services available for provisioning often appear to be unlimited and
389 appropriated in any quantity at any time and are supported by adding new virtual machines
390 (VMs) with specified computing resources. A challenge for AC design involves the
391 capability to rapidly verify the security of new VMs and determine whether the newly
392 added VMs are qualified to execute a specific task.
393
394 4. Measured service: Cloud systems automatically control and optimize resource use by
395 leveraging a metering capability at some level of abstraction appropriate to the type of
396 service (e.g., storage, processing, bandwidth, active end user accounts). Resource usage is
397 monitored, controlled, and reported to provide transparency to both the provider and
398 consumer of the utilized service. To maintain resource usage, cloud consumers should be
399 authorized to review but not modify their own metering data since this could lead to the
400 falsification of payments required for cloud services. Thus, it is reasonable for AC to
401 consider the protection of metering data.
402
403 5. Data sharing: Sharing information among different organizations is not a trivial task since
404 a cloud system needs to meet the same security requirements of organizations to achieve
405 that. To facilitate data sharing, concepts such as trust of federated identities and AC
406 attributes need be considered, and building that trust is paramount. In this document, it is
407 assumed that trust and federated identities/attributes are already established, and further
408 discussion on that topic will be considered in another document. Regardless of the service
409 model, consumers are entitled to be responsible for the security of their cloud-based data
410 and, implicitly, of who has access to it [4]. For this reason, data is never controlled by cloud
411 providers but rather always stays with the cloud customers. (The exception to this is log
412 data, but consideration should still be given to how privacy and security is affected by such
413 data.) Although a cloud provider might become the custodian of consumers’ data, it should
414 not have access to that data. If consumers’ data is not encrypted, then cloud administrators
415 might be able to read it. In this case, accessing data is a red flag, and customers should be
416 aware when it is happening.

6
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

417
418 Guidance for each cloud service model, as described in Sections 3, 4, and 6 of this document, can
419 be further extended to system requirements by referring to AC control elements listed in NIST SP
420 800-53, Revision 4, Security and Privacy Control for Federal Information Systems and
421 Organizations [5] based on the operation requirements of the cloud service. The Appendix section
422 maps the guidance to the AC control elements listed in the NIST SP 800-53, Revision 4.

7
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

423 3 Access Control Guidance for IaaS

424 IaaS is the cornerstone of all cloud services that offer computing and storage through a network
425 such as the internet. Through virtualization technology, IaaS enables end users to dynamically
426 allocate computing resources by instantiating new virtual machines (VMs) or releasing them based
427 on their requirements. A VM is a software container that behaves like a physical machine with its
428 own operating system (OS) and virtual resources (e.g., CPU, memory, hard disk, etc.). Leasing
429 VMs is more cost-effective than purchasing new physical machines. The virtualization technology
430 is composed of VMs and a hypervisor, as shown in Figure 1. VMs are managed by the hypervisor,
431 which controls the flow of data and instructions between the VMs and the physical hardware. At
432 the consumer side, system administrators are usually the major users of IaaS services since IaaS
433 services are flexible to configure resources (e.g., network, data storage).

434 Cloud virtualization adds additional security management burdens by introducing security controls
435 that arise from combining multiple VMs onto a single physical computer, which can have potential
436 negative impacts if a security compromise occurs. Some cloud systems make it easy to share
437 information among VMs by, for instance, allowing users to create multiple VMs on top of the
438 same hypervisor if multiple VMs are available. However, this convenience can also become an
439 attack vector since data leakage could occur among VMs. Additionally, virtualized environments
440 are transient since they are created and vanish frequently, thereby making the creation and
441 maintenance of necessary security boundaries more complex.
442
443 As shown in Figure 3, data in the middleware, data, applications, and OS layers is owned and
444 controlled by the customer. The IaaS system and the customer need to ensure that access to the
445 data is not granted to IaaS system administrators or any other IaaS customers in these layers unless
446 any of them are permitted. IaaS administrators are responsible for access control on the virtual
447 machine, hypervisor, storage, and networking layers and should consider Sections 3.1 – 3.5 below.
448
449 3.1 Guidance for Network

450 The network is shared among IaaS clients, and it is important to secure the network traffic and the
451 cloud’s environment from being exploited by unauthorized clients. Thus, access control for
452 network boundaries and whitelists for network communications are required and may be applied
453 through, for example, dedicated virtual local area networks (VLANs) leveraging automated access
454 control lists (ACLs). Using the Institute of Electrical and Electronics Engineers (IEEE) 802.1Q
455 VLAN tagging for network traffic with a cloud data center will result in routing only traffic tagged
456 with the server’s unique VLAN identifier to or from that server [6].
457
458 3.2 Guidance for Hypervisor

459 A hypervisor plays an important role in the security of the entire virtualized architecture since it
460 manages customer loads and guest operating systems (OSs), 2 creates new guest OS images, and
461 controls hardware resources. The security implications of actions like managing guest OS and
462 hardware resources means that access to the hypervisor should be restricted to authorized cloud
463 administrators only. Otherwise, a cloud end user could potentially obtain a VM from the cloud

2 An OS that is secondary to the originally installed OS.

8
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

464 service provider and install a malicious guest OS that compromises the hypervisor by gaining
465 unauthorized access to and altering the memory of other VMs [7]. Moreover, an attacker in a VM
466 with lower access rights may be able to escalate their access privilege to a higher level by
467 compromising the hardware resources allocation within the hypervisor [8]. Protecting the
468 hypervisor from unauthorized access is therefore critical to the security of IaaS services.
469
470 3.3 Guidance for Virtual Machines

471 VMs that are created by different end users allow resources to be shared among multiple end users.
472 In such a case, it must be ensured that no application from one VM can directly access other VMs
473 since covert channels [9, 10] may leak information between VMs by accessing shared physical
474 resources (e.g., memory). Similarly, although the ability to copy and paste information between
475 VMs via the clipboard is a convenient feature, such a capability could be made available on other
476 VMs running on the same hypervisor and thus introduce an attack vector (i.e., information can be
477 leaked to other VMs through the clipboard). Organizations should have policies regarding the use
478 of shared clipboards. Isolation between VMs is necessary to keep VMs running independently of
479 each other, and quotas on VM resource usage should be regulated so that a malicious VM can be
480 prohibited from exhausting computation resources. If a malicious application consumes the
481 majority of computation resources, legitimate applications may not be able to obtain sufficient
482 resources to perform their operations. Moreover, end users might terminate the execution of their
483 tasks before they are finished. The state and data of the current VM would then be saved as a guest
484 OS image, and when the task is resumed, the VM might be migrated from a different hypervisor.
485 In such scenarios, guest OS images must be protected from unauthorized access, tampering, or
486 storage. Furthermore, VMs that are not active may also store sensitive data. Monitoring access to
487 the sensitive data in inactive VMs should be considered.
488
489 3.4 Guidance for APIs

490 There are several popular open-source platforms for deploying an IaaS cloud [11, 12, 13]. These
491 solution platforms enable APIs to manage access control of VMs, hypervisors, and networks (note
492 that a consumer cannot control hypervisors and networks in a multi-tenant environment unless it
493 is a private cloud). For example, [13] consists of control components, including API,
494 communication, lifecycle, storage, volume, scheduler, network, API server for managing AC
495 policies for hypervisors, and network Controller for constructing network bridges and firewall AC
496 rules. The lack of monitoring AC within these APIs might result in unenforced or wrongly enforced
497 AC policies by the hypervisors, VMs, and networks. Thus, a service for monitoring the AC APIs
498 in cloud platforms should also be taken into consideration.
499
500 3.5 Recommendations for IaaS Access Control

501 As shown in previous sections, the security of an IaaS cloud system is heavily dependent on the
502 virtualization (hypervisor). One of the most widely adopted solutions for protecting them is a
503 virtualization management system [14], which lies between the underlying hardware and the
504 hypervisor. The virtualization management system enforces AC on both hypervisors and VMs in
505 different ways. Virtualization management systems enforce different levels of access on different
506 users. Some users are given read-only access to the administrative interface of a guest OS; some
507 are allowed to control particular guest OSs; and some are given complete administrative control.

9
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

508 There are existing solutions for providing AC for hypervisors and VMs. For example, the approach
509 in [15] secures the hypervisor against control hijacking attacks by protecting its code from
510 unauthorized access and offering isolation of VMs with flexible security of mandatory access
511 control (MAC). To enforce AC on interoperations, a well-designed service-level agreement can
512 be applied to secure external interoperations. Other isolation mechanisms [16, 17] are helpful in
513 ensuring the security of internal interoperations.
514
515 Guideline rules for IaaS AC policy that consider the main elements in AC (i.e., subject, object, and
516 action) are listed in Table 1. While each row indicates a possible AC rule, the AC designer should
517 ultimately decide whether the access in each rule is permitted or denied based on system
518 requirements. For example, if a legitimate IaaS end user requires the use of cloud services, a login
519 action in the hypervisor for the end user should be granted; otherwise, it should be denied.
520 Table 1: Potential policy rules expressed by Subject, Action, Object for IaaS AC policy

Subjects Actions Objects

IaaS end user Login, Read, Write, Create Hypervisor

IaaS end user Read, Write, Create VMs

VM Write Hypervisor

VM Read, Write Other VMs within the same host

VM Read, Write, Create Guest OS images

VM Read, Write Other VMs from different hosts but within the
same IaaS provider

VM Read, Write Other VMs from different IaaS providers

Hypervisor Read, Write, Create Guest OS images

Hypervisor Read, Write Hardware resources

Hypervisor Read, Write, Create VMs

521

10
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

522 4 Access Control System for PaaS

523 PaaS is a platform that provides a framework for developers to create and deploy customized
524 applications. As shown in Figure 3, any security assurance considerations below the data level and
525 starting from the runtime level should be offered by the PaaS provider. The primary focus of AC
526 in the PaaS model is to protect data during runtime, which is managed by middleware and OS.
527 Applications have to rely on the security and privacy offered by the PaaS provider to protect their
528 data from leaks through a covert channel introduced by unsecure shared memory. Therefore,
529 enforcing AC over data during runtime in the PaaS is critical for the security of PaaS services.
530
531 The PaaS system administrator is responsible for the access control of runtime, middleware, OS,
532 virtual machine, hypervisor, storage, and networking layers, as described by the guidance in
533 Sections 4.1-4.6 below.
534
535 4.1 Guidance for Memory Data

536 The PaaS model permits users to deploy tasks in a provider-controlled middleware and host OS,
537 which may be shared with other PaaS applications. As such, PaaS typically leverages OS-based
538 techniques (e.g., Linux Containers and Docker for isolating applications) [18]. However,
539 numerous existing memory-related attacks can compromise sensitive application-related data by
540 hacking through the shared OS memory in PaaS [19]. Thus, AC for OS memory, such as AC of
541 different processes on top of processor caches [20], should be considered.
542
543 4.2 Guidance for APIs

544 As the PaaS model allows developers to build applications on top of the platform, APIs should
545 control the scope of each user’s application such that user data remains inaccessible between
546 different applications. In addition, packaged API can be serviced as microservices in a PaaS Cloud.
547 A centralized architecture for provisioning and enforcement of access policies governing access
548 to all microservices is required due to the sheer number of services needed for service composition
549 to support real-world business transactions (e.g., customer order processing and shipping). Since
550 each of the microservices may be implemented in a different language, policy provisioning and
551 computation of access decisions may require the use of an authorization server [21].
552
553 4.3 Recommendations for PaaS Access Control

554 An efficient method should be established for protecting memory data by flushing processor
555 caches during context switches. However, in order to avoid significant performance degradation,
556 only highly sensitive memory data should be flushed.
557
558 Guideline rules for PaaS AC policy are listed in Table 2 with respect to the three basic elements
559 of AC (i.e., subject, object, and action). Each row indicates a possible AC rule, but the AC designer
560 should decide whether access should be granted or denied based on the system requirements. For
561 example, if a user of an application needs to access memory data related to their application,
562 permission to read memory data will be granted. However, access to that memory data will be
563 denied to other users.
564

11
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

565 Table 2: Potential policy rules expressed by Subject, Action, Object for PaaS AC policy

Subjects Actions Objects

Application user Read Memory data

VM of a hosted application Read, Write Other applications’ data within the same host

Application developer Create, Read, Write Middleware data, memory data

Cloud provider Replicate Application-related data

566

12
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

567 5 AC System for SaaS

568 In SaaS, a cloud provider delivers an application as a service to end users through a network such
569 as the internet. Thus, there is no need for users to install and execute applications locally on their
570 own computers. As shown in Figure 4, multiple applications and users can be supported
571 simultaneously by the cloud to share common resources, including applications and underlying
572 databases.
573

574
575 Figure 4: The multi-tenant architecture of the SaaS model

576 If a developer deploys a third-party application, data in that application and other unrelated
577 applications might be stored. End users have to rely on the security and privacy offered by the
578 cloud provider to protect their data from unauthorized access introduced by those unrelated
579 applications. Note that data managed by the application layer is owned and controlled by the
580 customer. The SaaS system and customer need to ensure that access to application data in these
581 layers is not granted to the SaaS system administrator, customers, or other users unless they are
582 trusted. SaaS administrators are responsible for the access control of all operation layers in Figure
583 3 and should consider the guidance in Sections 3, 4, and 5.1- 5.4.
584
585 5.1 Guidance for Data Owner’s Control

586 A data provider is the creator or source of application data owned by consumer organizations.
587 Application data is typically stored in the SaaS service provider’s database. How a data provider
588 manages access to its data is a challenge. Example questions to be addressed are related to data
589 retention by the provider (e.g., where data is kept and for how long) and whether the provider has
590 any permission to determine access rights to the data it hosts. If a data provider has the capability
591 to determine access rights on data it holds, consideration should be given to ensure that an up-to-
592 date AC policy is always enforced within the SaaS model.
593
594 5.2 Guidance for Confidentiality

595 In the application deployment model, the integrity of sensitive data residing within the data
596 owner’s domain must be protected. Protection mechanisms for application data include data
597 encryption schemes by which data can be encrypted through certain cryptographic primitives, and

13
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

598 decryption keys will only be disclosed to authorized users [22]. For such enforcement, attribute-
599 based access control (ABAC) [23] and attribute-based encryption (ABE) schemes can be used to
600 control access to SaaS data [22, 24, 25, 26, 27] since these schemes can use the identity of users
601 through attributes to manage, encrypt, and decrypt application data. However, considering the high
602 volume of data in the SaaS model, the involved encryption and decryption significantly reduce
603 performance. Hence, when encryption is used, consideration should be given to ensure the
604 confidentiality of data while offering good performance.
605
606 5.3 Guidance for Privilege Management

607 In addition to AC enforcement, privilege management involves adding, removing, and changing
608 the privileges of a subject. It is crucial to design a flexible mechanism for assigning and revoking
609 privileges to maintain the usability of the SaaS service [28].
610
611 5.4 Guidance for Multiple Replicas of Data

612 To maintain high availability, the cloud provider may replicate data at multiple locations, even
613 across countries. Thus, it is important to make sure that all data replicas are protected under the
614 same AC policy. In other words, the same AC policy for the replicated data object should be
615 populated to all hosts that process the same data. The technology for policy synchronization upon
616 changes must also be considered for inclusion.
617
618 5.5 Guidance for Multi-tenancy

619 The SaaS model introduces additional considerations with regard to the management of access to
620 applications. An immediate necessity is to focus on users’ access to applications. The access rights
621 are granted to end users through AC policies based on predefined attributes or roles. This
622 requirement can be specified by attribute-based access control (ABAC) policy models [29, 30],
623 role-based access control [31] (RBAC), and context-based access control [32] (CBAC).
624
625 A tenant hosts a service application. The SaaS model is a typical, multi-tenancy platform that
626 supports multiple end users accessing an application simultaneously and with data of different
627 users’ applications residing at the same location. Exploiting vulnerabilities in the application or
628 injecting client code into the SaaS system might expose data to other users [33]. Therefore,
629 consideration should to be given to implementing multi-tenancy while segregating data from
630 different users’ applications during the design of an AC system.
631
632 5.6 Guidance for Attribute and Role Management

633 In the SaaS service model, attribute and role-based AC management employs policies and
634 predefined roles to manage access rights to applications and underlying databases. The primary
635 challenge of deploying attribute or role-based AC management is reaching an agreement on what
636 types of attributes or roles should be used and what should be taken into account when designing
637 the AC systems [34]. If the set of considered attributes or roles is too small, flexibility will be
638 reduced. However, if the number of attributes or roles is too large, the complexity of policies will
639 increase.
640

14
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

641 5.7 Guidance for Policies

642 SaaS applications provide application-specific access control configurations for different user
643 applications, and in this case, user policies for each application are enforced by the SaaS provider.
644 This configuration does not support collaboration between the SaaS provider and the consumer’s
645 access control infrastructure. For example, while large organizations often employ on-premises
646 access control systems for managing their users centrally and efficiently, SaaS applications
647 typically provide organizations with an AC configuration interface for managing AC policies,
648 which forces the AC policies to be stored and evaluated on the SaaS provider’s side. This approach
649 might result in disclosing sensitive data required for evaluating the AC policies to the SaaS
650 provider. Therefore, methods for enforcing authorization in the SaaS provider while not disclosing
651 sensitive access control data to the SaaS provider should be considered. Federated authorization
652 [35] is an efficient technique that utilizes a middleware layer to transfer the management of access
653 control policies from the SaaS provider to the consumer side and enforce policies on the SaaS
654 applications without disclosing sensitive data required for evaluating the policies.
655
656 5.8 Guidance for APIs

657 An API in the SaaS model serves as an interface between the cloud server and its users. The API
658 should be designed to protect against both accidental and malicious attempts to circumvent any
659 AC policy. Applications for organizations and third parties often build upon the APIs, which
660 introduce the AC complexity of the new layered API. For example, if the APIs do not require
661 memory access for their tasks, then the AC policy for the APIs should enforce the non-memory
662 access. Additionally, AC policies should be specified to manage the authorization process for web
663 APIs. For example, when APIs connect through SOAP and REST protocols, the AC should control
664 whether to allow end users to interface between Microsoft or non-Microsoft tools and technologies.
665 For authorized API connections through SOAP and REST protocols, the AC should grant all
666 related access requested by the protocols. For unauthorized API connections through these
667 protocols, no access or partial access should be granted by the AC.
668
669 5.9 Recommendations for SaaS Access Control

670 With regard to multi-tenancy, authorization may be enforced using a centralized, decentralized, or
671 hybrid authorization system. In a centralized authorization system, the SaaS provider manages a
672 central authorization database for every end user and their accounts [36]. In a decentralized or
673 hybrid authorization system, individual tenants are responsible for all or part of the authorization
674 process. Note that different tenants may require different systems. Considering the attributes or
675 roles of tenants is crucial when selecting the most suitable system. There are many ways to specify
676 attributes or roles, such as in ABAC and RBAC models [30,31]. Attributes or roles must be well-
677 designed and take into account hierarchy relationships when implementing AC policies for
678 different tenants.
679
680 Authorization federation [35] is an efficient way to enforce AC policies in the SaaS provider. A
681 generic middleware architecture that incorporates access control requirements from consumers and
682 handles local and remote attributes or roles can be used to extend and shift AC policy management
683 from the SaaS provider to the consumer side. This approach centralizes consumer AC policy
684 management and lowers the required trust in the SaaS provider. In addition, the AC for VM-

15
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

685 supporting federation operations should also be specified (e.g., an end user may create a VM to
686 run different applications). Within the VM of the same host, one application may need to access
687 the application code of other applications to fulfill its task. Unlike the PaaS architecture, where
688 consumers can fully manage the design, testing, and development of the software, SaaS consumers
689 have limited control of the applications hosted in the cloud server.
690
691 To achieve the application data owner’s control, a security class agreement (SCA) [27] may be of
692 use. SCA is mutually agreed upon by both the data provider of PaaS subscribers and the PaaS
693 service provider and is used for defining the security class of data providers. Multiple replicas of
694 the same data share the same security level as its data provider. This means that given data from a
695 particular data provider, the security class for multiple replicas of the data should be identical. As
696 a result, the host within the PaaS service that is qualified for executing the access request can be
697 determined by referring to the SCA. The data provider can manage access to its data by specifying
698 security classes for the SCA to keep the data provider and the cloud host synchronized in
699 determining the access right of data. For example, in a Bell-LaPadula model [37], assuming a
700 patient’s report is written by a doctor with confidential clearance, the report can only be read by a
701 host with the same or higher security clearance. Additionally, when multiple data sources that are
702 not intended to be accessed in the same cloud system are accessed, the privacy of data should not
703 be leaked due to different security classes of these data sources and their data in the SCA. However,
704 due to the high computation complexity of encryption and decryption, cryptographic schemes
705 should be carefully designed to maintain the performance of cloud systems while protecting data
706 confidentiality.
707
708 A privilege management infrastructure (PMI) [38] can be employed to dynamically manage
709 assigning and revoking privileges through the use of attributes or role specification certificates in
710 the PaaS model. PMI specifies the privileges for different users and links the privileges with
711 different attribute or role specification certificates, which contain different attribute or role
712 assignments to enforce privilege management.
713
714 To handle access control of multiple replicas of data, a method to manage the central AC policy
715 system should be introduced. Thus, once the data within a PaaS provider is duplicated across PaaS
716 providers, any change in the policy should result in an appropriate update to the central AC policy
717 system. Moreover, the AC policy related to the replicated data in other PaaS providers should be
718 synchronized accordingly based on an AC policy in the central system.
719
720 Guideline rules for SaaS AC policy are listed in Table 3. The AC designer should decide whether
721 access in each rule is permitted or denied based on the system requirements. For example, during
722 federation operation, VM read/write to other application code within the same host is permitted;
723 otherwise, it is denied.
724

16
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

725 Table 3: Potential policy rules expressed by Subject, Action, Object for SaaS AC policy

Subjects Actions Objects

Application user Read, Write Application-related data

Application user Read Memory

Application user Execute Application

Application user Read, Write Application data

Application user Execute Application code

VM of a hosted application Execute Other application code within the same host
726

727

17
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

728 6 Guidance for Inter and Intra Operation

729 In general, collaboration (i.e., two or more systems that work together as a combined system) in
730 the context of the cloud may lead to a seamless exchange of data and services among various cloud
731 infrastructures. There are two types of collaborations: inter-operation and intra-operation. Inter-
732 operation refers to the capability of using multiple cloud infrastructures. For example, as shown in
733 Figure 4, a customer may purchase IaaS services from two different cloud providers, Cloud A and
734 Cloud B, and the collaboration between them should be allowed due to data processing
735 requirements.
736

737
738 Figure 5: The external collaboration (inter-operation) between different Clouds

739 With regard to intra-operation, two scenarios must be considered, as shown in Figure 5. First, a
740 customer may own multiple VMs in a single cloud host (VM A and VM B), and collaboration
741 among those VMs may be required. Second, a customer may rent multiple hosts within the same
742 IaaS service, and collaboration among VMs from these different hosts may be required (e.g., an
743 interoperation between VM B and VM C).
744
745 There are some access control policy integration issues for inter-operation. For instance, different
746 cloud providers using different sets of subject attributes for AC may cause potential conflicts or
747 leak access permissions [39]. Attributes with the same name may result in different privileges
748 when switching providers. Enforcing AC among different cloud providers without incurring
749 conflicts or blocks of privilege for individual users/VMs is a challenge. This would require
750 examining how to achieve secure inter-operation among the cloud providers [1]. Some cloud AC
751 systems adopt centralized mechanisms to create global AC policies that manage policy integration
752 among different cloud providers [40]. However, the cloud inter-operation is transient and thus
753 inefficient to manage global AC policies as frequent updates for individual cloud AC policies.
754
755 With regard to intra-operation, the AC policy should enable the operations of VMs for the same
756 customer to access each other as needed during the collaboration period and disable the access
757 when the collaboration period ends. There are two primary cases in intra-operation: inter-host case
758 (i.e., VMs from different cloud hosts are operating collaboratively) and intra-host case (i.e., VMs
759 are from the same cloud host and must exchange data and services). Additionally, for some
760 applications, VMs might be distributed in multiple host computers, so the AC policy should cover
761 both intra-host and inter-host cases.
762

18
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

763
764 Figure 6: The internal collaboration (intra-operation) within the same Cloud
765

19
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

766 7 Conclusions

767 This document presents an initial step toward understanding security challenges in cloud systems
768 by analyzing the access control (AC) considerations in all three cloud service delivery models—
769 IaaS, PaaS, and SaaS. Essential characteristics that would affect the Cloud’s AC design are also
770 summarized, such as broad network access, resource pooling, rapid elasticity, measured service,
771 and data sharing. Various guidance for AC design of IaaS, PaaS, and SaaS are proposed according
772 to their different characteristics. Recommendations for AC design in different cloud systems are
773 also included to facilitate future implementations. Additionally, potential policy rules are
774 summarized for each cloud system. However, many issues remain open, such as AC management
775 across different devices and platforms as well as new challenges that have yet to emerge with the
776 wide adoption of the cloud.
777
778

20
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

779 References

780 [1] Gouglidis A, Mavridis I, Hu VC (2014) Security policy verification for multi-domains in
781 Cloud systems. International Journal of Information Security 13(2):97-111.
782 https://doi.org/10.1007/s10207-013-0205-x

783 [2] Mell PM, Grance T (2011) The NIST Definition of Cloud Computing. (National Institute
784 of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-145.
785 https://doi.org/10.6028/NIST.SP.800-145

786 [3] Badger ML, Grance T, Patt-Corner R, Voas JM (2012) Cloud Computing Synopsis and
787 Recommendations. (National Institute of Standards and Technology, Gaithersburg, MD),
788 NIST Special Publication (SP) 800-146. https://doi.org/10.6028/NIST.SP.800-146.

789 [4] Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128 Stat. 3073.
790 https://www.govinfo.gov/app/details/PLAW-113publ283

791 [5] Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for
792 Federal Information Systems and Organizations. (National Institute of Standards and
793 Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 4, Includes
794 updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4

795 [6] Bartock MJ, Souppaya MP, Scarfone KA, Carroll D, Masten R, Scinta G, Massis P,
796 Prafullchandra H, Malnar J, Singh H, Yeluri R, Shea T, Dalton M, Dukes A, Phoenix C
797 Swarts B (2018) Trust Cloud: Security Practice Guide for VMware Hybrid Cloud
798 Infrastructure as a Service (IaaS) Environments. (National Institute of Standards and
799 Technology, Gaithersburg, MD), Preliminary Draft NIST Special Publication (SP) 1800-
800 19B. Available at https://www.nccoe.nist.gov/projects/building-blocks/trusted-cloud

801 [7] Szefer J, Lee RB (2011) A case for hardware protection of guest VMs from compromised
802 hypervisors in cloud computing. 2011 31st International Conference on Distributed
803 Computing Systems Workshops (ICDCSW) (IEEE, Minneapolis, MN), pp 248–252.
804 https://doi.org/10.1109/ICDCSW.2011.51

805 [8] Krutz RL, Vines RD (2010) Cloud security: A comprehensive guide to secure cloud
806 computing (Wiley Publishing, Indianapolis, IN).

807 [9] Wu J, Ding L, Wu Y, Min-Allah N, Khan SU, Wang Y (2014) C2detector: a covert channel
808 detection framework in cloud computing. Security and Communication Networks
809 7(3):544–557. https://doi.org/10.1002/sec.754

810 [10] Rushby J (1992) Noninterference, transitivity, and channel-control security policies. (SRI
811 International, Menlo Park, CA), Technical Report CSL-92-02. Available at
812 http://www.csl.sri.com/papers/csl-92-2/

813 [11] Change ATC, Foster JL, Hall DK (1987) Nimbus-7 SMMR derived global snow cover
814 parameters. Annals of Glaciology 9:39-44. https://doi.org/10.3189/S0260305500200736

21
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

815 [12] Nurmi D, Wolski R, Grzegorczyk C, Obertelli G, Soman S, Youseff L, Zagorodnov D

816 (2009) The Eucalyptus open-source cloud-computing system. 9th IEEE/ACM
817 International Symposium on Cluster Computing and the Grid (CCGRID'09) (IEEE,
818 Shanghai, China), pp 124-131. https://doi.org/10.1109/CCGRID.2009.93

819 [13] Sefraoui O, Aissaoui M, Eleuldj M (2012) OpenStack: toward an open-source solution for
820 cloud computing. International Journal of Computer Applications 55(3):38-42.
821 https://doi.org/10.5120/8738-2991

822 [14] Scarfone KA, Souppaya MP, Hoffman P (2011) Guide to Security for Full Virtualization
823 Technologies. (National Institute of Standards and Technology, Gaithersburg, MD), NIST
824 Special Publication (SP) 800-125. https://doi.org/10.6028/NIST.SP.800-125

825 [15] Wang Z, Jiang X (2010) Hypersafe: A lightweight approach to provide lifetime hypervisor
826 control-flow integrity. 2010 IEEE Symposium on Security and Privacy (SP) (IEEE,
827 Berkeley/Oakland, CA), pp 380–395. https://doi.org/10.1109/SP.2010.30

828 [16] Berger S, Cáceres R, Pendarakis D, Sailer R, Valdez E, Perez R, Schildhauer W, Srinivasan
829 D (2008) TVDc: managing security in the trusted virtual datacenter. ACM SIGOPS
830 Operating Systems Review 42(1):40–47. https://doi.org/10.1145/1341312.1341321

831 [17] Sailer R, Valdez E, Jaeger T, Perez R, Doorn LV, Griffin JL, Berger S (2005) sHype:
832 Secure hypervisor approach to trusted virtualized systems. (IBM Research Division,
833 Yorktown Heights, NY) IBM Research Report RC23511. Available at
834 https://domino.research.ibm.com/library/cyberdig.nsf/papers/265C8E3A6F95CA8D8525
835 6FA1005CBF0F/$File/rc23511.pdf

836 [18] Zhang Y, Juels A, Reiter MK, Ristenpart T (2014) Cross-tenant Side-channel Attacks in
837 PaaS Clouds. Proceedings of the 2014 ACM SIGSAC Conference on Computer and
838 Communications Security (ACM, Scottsdale, AZ), pp 990–1003.
839 https://doi.org/10.1145/2660267.2660356

840 [19] Osvik DA, Shamir A, Tromer E (2006) Cache attacks and countermeasures: the case of
841 AES. Pointcheval D. (eds) Topics in Cryptology – CT-RSA 2006. CT-RSA 2006. Lecture
842 Notes in Computer Science 3860 (Springer, Berlin), pp 1–20.
843 https://doi.org/10.1007/11605805_1

844 [20] Tromer E, Osvik DA, Shamir A (2010) Efficient cache attacks on AES, and
845 countermeasures. Journal of Cryptology 23(1):37–71. https://doi.org/10.1007/s00145-009-
846 9049-y

847 [21] Chandramouli R (2019) Security Strategies for Microservices-based Application Systems.
848 (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special
849 Publication (SP) 800-204. https://doi.org/10.6028/NIST.SP.800-204

850 [22] Yu S, Wang C, Ren K, Lou W (2010) Achieving secure, scalable, and fine-grained data
851 access control in cloud computing. INFOCOM, 2010 Proceedings (IEEE, San Diego, CA),
852 pp 1-9. https://doi.org/10.1109/INFCOM.2010.5462174

22
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

853 [23] Hu VC, Ferraiolo DF, Kuhn DR, Schnitzer A, Sandlin K, Miller R, Scarfone KA (2014)
854 Guide to Attribute Based Access Control (ABAC) Definition and Considerations.
855 (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special
856 Publication (SP) 800-162, Includes updates as of August 02, 2019.
857 https://doi.org/10.6028/NIST.SP.800-162

858 [24] Sahai A, Waters B (2005) Fuzzy identity-based encryption. Advances in Cryptology –
859 EUROCRYPT 2005. Lecture Notes in Computer Science 3494 (Springer, Berlin), pp 457–
860 473. https://doi.org/10.1007/11426639_27

861 [25] Nali D, Adams CM, Miri A (2005) Using threshold attribute-based encryption for practical
862 biometric-based access control. International Journal of Network Security 1(3):173–182.
863 Available at http://ijns.jalaxy.com.tw/download_paper.jsp?PaperID=IJNS-2005-06-30-
864 2&PaperName=ijns-v1-n3/ijns-2005-v1-n3-p173-182.pdf

865 [26] Zhu Y, Hu H, Ahn G-J, Huang D, Wang S (2012) Towards temporal access control in
866 cloud computing. INFOCOM, 2012 Proceedings (IEEE, Orlando, FL), pp 2576–2580.
867 https://doi.org/10.1109/INFCOM.2012.6195656

868 [27] Hu VC, Grance T, Ferraiolo DF, Kuhn DR (2014) An access control scheme for big data
869 processing. 2014 International Conference on Collaborative Computing: Networking,
870 Applications and Worksharing (CollaborateCom) (IEEE, Miami, FL), pp 1–7.
871 https://doi.org/10.4108/icst.collaboratecom.2014.257649

872 [28] Hu VC, Scarfone KA (2012) Guidelines for Access Control System Evaluation Metrics.
873 (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or
874 Internal Report (IR) 7874. https://doi.org/10.6028/NIST.IR.7874

875 [29] Vipul G, Pandey O, Sahai A, Waters B (2006) Attribute-based encryption for fine-grained
876 access control of encrypted data. Proceedings of the 13th ACM Conference on Computer
877 and Communications Security (CCS ’06) (ACM, Alexandria, VA), pp 89-98.
878 https://doi.org/10.1145/1180405.1180418

879 [30] Hu VC, Kuhn DR, Ferraiolo DF, Voas J (2015) Attribute-based access control. Computer
880 48(2):85-88. http://doi.org/10.1109/MC.2015.33

881 [31] Sandhu RS, Coyne EJ, Feinstein HL, Youman CE (1996) Role-based access control
882 models. Computer 29(2):38-47. https://doi.org/10.1109/2.485845

883 [32] Rubart J (2005) Context-based access control. Proceedings of the 2005 Symposia on
884 Metainformatics (MIS ’05). (ACM, New York, NY), pp 13-18.
885 https://doi.org/10.1145/1234324.1234337

886 [33] Subashini S, Kavitha V (2011) A survey on security issues in service delivery models of
887 cloud computing. Journal of Network and Computer Applications 34(1), pp 1–11.
888 https://doi.org/10.1016/j.jnca.2010.07.006

23
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

889 [34] Jin X, Krishnan R, Sandhu R (2012) A unified attribute-based access control model
890 covering DAC, MAC, and RBAC. Data and Applications Security and Privacy XXVI,
891 DBSec 2012. Lecture Notes in Computer Science 7371 (Springer, Berlin), pp 41-55.
892 https://doi.org/10.1007/978-3-642-31540-4_4

893 [35] Decat M, Lagaisse B, Van Landuyt D, Crispo B, Joosen W (2013) Federated authorization
894 for software-as-a-service applications. On the Move to Meaningful Internet Systems: OTM
895 2013 Conferences. Lecture Notes in Computer Science 8185 (Springer, Berlin), pp 342–
896 359. https://doi.org/10.1007/978-3-642-41030-7_25

897 [36] Dimitrios Z, Lekkas D (2012) Addressing cloud computing security issues. Future
898 Generation Computer Systems 28(3):583-592.
899 https://doi.org/10.1016/j.future.2010.12.006

900 [37] McLean J (1985) A comment on the ‘basic security theorem’ of Bell and LaPadula.
901 Information Processing Letters 20(2):67-70.
902 https://doi.org/10.1016/0020-0190(85)90065-1

903 [38] Blobel B, Nordberg R, Davis JM, Pharow P (2006) Modelling privilege management and
904 access control. International Journal of Medical Informatics 75(8), pp 597–623.
905 https://doi.org/10.1016/j.ijmedinf.2005.08.010

906 [39] Bertino E, Federica P, Rodolfo F, Shang N (2009) Privacy-preserving digital identity
907 management for cloud computing. IEEE Data Engineering Bulletin 32(1):21-27. Available
908 at http://sites.computer.org/debull/A09mar/bertino.pdf

909 [40] Catteddu D (2010) Cloud Computing: benefits, risks and recommendations for information
910 security. Web Application Security. Communications in Computer and Information
911 Science 72 (Springer, Berlin), pp 17-17. https://doi.org/10.1007/978-3-642-16120-9_9

24
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

912 Guidance and SP 800-53 Revision 4 Access Control (AC) Family Mapping

913 The following table maps the cloud access control guidance to the AC controls listed in NIST SP
914 800-53, Revision 4, Security and Privacy Controls for Federal Information Systems and
915 Organizations [5].

Guidance AC Control in 800-53

3.1 Guidance for Network AC-1, AC-3, AC-4, AC-5, AC-10,

AC-17, AC-21, AC-22

3.2 Guidance for Hypervisor AC-1, AC-3, AC-5, AC-17, AC-21

3.3 Guidance for Virtual Machine AC-1, AC-3, AC-4, AC-5, AC-11

3.4 Guidance for API AC-1, AC-3, AC-4, AC-5, AC-11,

AC-17, AC-21, AC-22

4.1 Guidance for Memory Data AC-1, AC-3, AC-4, AC-5, AC-10,
AC-11, AC-21

4.2 Guidance for APIs AC-1, AC-3, AC-4, AC-5, AC-10,

AC-11, AC-21

5.1 Guidance for Data Owner’s Control AC-1, AC-3, AC-5

5.2 Guidance for Confidentiality AC-3, AC-6, AC-21

5.3 Guidance for Privilege Management AC-2, AC-11, AC-14, AC-22

5.4 Guidance for Multiple Replicas of Data AC-1, AC-3, AC-4, AC-5, AC-17,
AC-21

5.5 Guidance for Multi-tenancy AC-1, AC-2, AC-3, AC-4, AC-5,

AC-10, AC-11, AC-21

5.6 Guidance for Attribute and Role Management AC-6, AC-1, AC-3

5.7 Guidance for Policies AC-1, AC-3

5.8 Guidance for APIs AC-1, AC-2, AC-3, AC-4, AC-5,

AC-6, AC-11, AC-14, AC-17, AC-
21

916
917 AC-1: Access Control Policy and Procedures
918 AC-2: Account Management
919 AC-3: Access Enforcement
920 AC-4: Information Flow Enforcement

25
 NIST SP 800-210 (DRAFT) GENERAL ACCESS CONTROL GUIDANCE
FOR CLOUD SYSTEMS

921 AC-5: Separation of Duties

922 AC-6: Lease Privilege
923 AC-10: Concurrent Session Control
924 AC-11: Session Lock
925 AC-14: Permitted Actions without Identification or Authentication
926 AC-17: Remote Access
927 AC-21: Collaboration and Information Sharing
928 AC-22: Publicly Accessible Content

26