ANSI INCITS 359-2012 Information Technology C Role Based Access Control.pdf

1、American National StandardDeveloped byfor Information Technology Role Based Access ControlINCITS 359-2012INCITS 359-2012INCITS 359-2012Revision ofINCITS 359-2004(R2009)American National Standardfor Information Technology Role Based Access ControlSecretariatInformation Technology Industry CouncilAppr

2、oved May 29, 2012 American National Standards Institute, Inc.Approval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgement of t

3、he ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected interests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Consensus requires that allviews and objections be considered, and that a concerted effor

4、t be madetowards their resolution.The use of American National Standards is completely voluntary; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufacturing, marketing, purchasing, or usingproducts, processes, or procedures not conforming

5、to the standards.The American National Standards Institute does not develop standards andwill in no circumstances give an interpretation of any American NationalStandard. Moreover, no person shall have the right or authority to issue aninterpretation of an American National Standard in the name of t

6、he AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the American National

7、StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard. Purchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNational Standards Institute.American National StandardPublished byA

8、merican National Standards Institute, Inc.25 West 43rd Street, New York, NY 10036Copyright 2012 by Information Technology Industry Council (ITI)All rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permissio

9、n of ITI, 1101 K Street NW, Suite 610, Washington, DC 20005. Printed in the United States of AmericaCAUTION: The developers of this standard have requested that holders of patents that may berequired for the implementation of the standard disclose such patents to the publisher. However,neither the d

10、evelopers nor the publisher have undertaken a patent search in order to identifywhich, if any, patents may apply to this standard. As of the date of publication of this standardand following calls for the identification of patents that may be required for the implementation ofthe standard, no such c

11、laims have been made. No further patent search is conducted by the de-veloper or publisher in respect to any standard it processes. No representation is made or impliedthat licenses are not required to avoid infringement in the use of this standard.i CONTENTS PAGE FOREWORD . II 1 SCOPE . 1 2 CONFORM

12、ANCE 2 3 NORMATIVE REFERENCES. 2 4 TERMS AND DEFINITIONS 2 5 RBAC REFERENCE MODEL 3 5.1 CORE RBAC . 4 5.1.1 Core RBAC specification: . 5 5.2 HIERARCHAL RBAC . 6 5.2.1 General Role Hierarchies: . 7 5.2.2 Limited Role Hierarchies: 8 5.3 CONSTRAINED RBAC . 8 5.4 STATIC SEPARATION OF DUTY RELATIONS . 9

13、5.4.1 Static Separation of Duty: 10 5.4.2 Static Separation of Duty in the Presence of a Hierarchy: . 10 5.5 DYNAMIC SEPARATION OF DUTY RELATIONS . 10 5.5.1 Dynamic Separation of Duty: . 11 6 POLICY ENHANCEMENTS . 12 7 RBAC SYSTEM AND ADMINISTRATIVE FUNCTIONAL SPECIFICATION 12 7.1 CORE RBAC . 13 7.1

14、.1 Administrative Commands for Core RBAC 13 7.1.2 Supporting System Functions for Core RBAC 16 7.1.3 Review Functions for Core RBAC 17 7.1.4 Advanced Review Functions for Core RBAC 18 7.2 HIERARCHICAL RBAC 19 7.2.1 General Role Hierarchies . 19 7.2.1.1 Administrative Commands for General Role Hierar

15、chies 19 7.2.1.2 Supporting System Functions for General Role Hierarchies 21 7.2.1.3 Review Functions for General Role Hierarchies 22 7.2.1.4 Advanced Review Functions for General Role Hierarchies . 22 7.2.2 Limited Role Hierarchies 23 7.2.2.1 Administrative Commands for Limited Role Hierarchies 23

16、7.2.2.2 Supporting System Functions for Limited Role Hierarchies 24 7.2.2.3 Review Functions for Limited Role Hierarchies 24 7.2.2.4 Advanced Review Functions for Limited Role Hierarchies . 24 7.3 STATIC SEPARATION OF DUTY (SSD) RELATIONS . 24 7.3.1 Core RBAC . 24 7.3.1.1 Administrative commands for

17、 SSD Relations 24 7.3.1.2 Supporting System Functions for SSD . 26 7.3.1.3 Review Functions for SSD . 26 7.3.1.4 Advanced Review Functions for SSD 27 7.3.2 SSD with General Role Hierarchies . 27 7.3.2.1 Administrative Commands for SSD with General Role Hierarchies 27 7.3.2.2 Supporting System Functi

18、ons for SSD with General Role Hierarchies 29 7.3.2.3 Review Functions for SSD with General Role Hierarchies 30 7.3.2.4 Advanced Review Functions for SSD with General Role Hierarchies . 30 ii 7.3.3 SSD Relations with Limited Role Hierarchies 30 7.3.3.1 Administrative Commands for SSD with Limited Rol

19、e Hierarchies 30 7.3.3.2 Supporting System Functions for SSD with Limited Role Hierarchies 30 7.3.3.3 Review Functions for SSD with Limited Role Hierarchies 30 7.3.3.4 Advanced Review Functions for SSD with Limited Role Hierarchies . 30 7.4 DYNAMIC SEPARATION OF DUTIES (DSD) RELATIONS . 31 7.4.1 Cor

20、e RBAC . 31 7.4.1.1 Administrative Commands for DSD Relations . 31 7.4.1.2 Supporting System Functions for DSD Relations. 33 7.4.1.3 Review Functions for DSD Relations . 33 7.4.1.4 Advanced Review Functions for DSD Relations 34 7.4.2 DSD Relations with General Role Hierarchies 34 7.4.2.1 Administrat

21、ive commands for DSD Relations with General Role Hierarchies 34 7.4.2.2 Supporting System Functions for DSD Relations with General Role Hierarchies . 34 7.4.2.3 Review Functions for DSD Relations with General Role Hierarchies . 35 7.4.2.4 Advanced Review Functions for DSD Relations with General Role

22、 Hierarchies 35 7.4.3 DSD Relations with Limited Role Hierarchies . 35 7.4.3.1 Administrative Commands for DSD Relations with Limited Role Hierarchies . 35 7.4.3.2 Supporting System Functions for DSD Relations with Limited Role Hierarchies . 36 7.4.3.3 Review Functions for DSD Relations with Limited

23、 Role Hierarchies . 36 7.4.3.4 Advanced Review Functions for DSD Relations with Limited Role Hierarchies 36 A FUNCTIONAL SPECIFICATION OVERVIEW 37 A.1 FUNCTIONAL SPECIFICATION FOR CORE RBAC . 37 A.1.1 Administrative Functions 37 A.1.2 Supporting System Functions . 38 A.1.3 Review Functions 38 A.2 FU

24、NCTIONAL SPECIFICATION FOR HIERARCHICAL RBAC . 39 A.2.1 Hierarchical Administrative Functions 39 A.2.2 Supporting System Functions . 40 A.2.3 Review Functions 40 A.3 FUNCTIONAL SPECIFICATION FOR SSD RELATION 41 A.3.1 Administrative Functions 41 A.3.2 Supporting System Functions . 41 A.3.3 Review Fun

25、ctions 41 A.4 FUNCTIONAL SPECIFICATION FOR DSD RELATION 42 A.4.1 Administrative Functions 42 A.4.2 Supporting System Functions . 42 A.4.3 Review Functions 43 A.5 FUNCTIONAL SPECIFICATION PACKAGES . 43 B RATIONALE INFORMATIVE ANNEX 45 B.1 CORE RBAC . 45 B.2 HIERARCHICAL RBAC 45 B.3 STATIC SEPARATION

26、OF DUTY RELATIONS . 46 B.4 DYNAMIC SEPARATION OF DUTY RELATIONS . 47 C COMMAND LIST . 49 iiForeword (This foreword is not part of American National Standard INCITS 359-2012.)Development this standard was initiated by the National Institute of Standards andTechnology (NIST) in recognition of a need a

27、mong government and industry pur-chasers of information technology products for a consistent and uniform definition ofrole based access control (RBAC) features. Vendors were implementing role basedaccess control features in their database management systems, security manage-ment, and network operati

28、ng system products, without general agreement on the def-inition of RBAC features. This lack of a widely accepted model resulted in uncertaintyand confusion about RBACs utility and meaning. This standard seeks to resolve thissituation by using a reference model to define RBAC features and then descr

29、ibingthe functional specifications for those features.This standard contains three annexes. Annexes A and B are informative and are notconsidered part of the standard. Annex C is normative and is considered part of thestandard.Requests for interpretation, suggestions for improvement or addenda, or d

30、efect re-ports are welcome. They should be sent to InterNational Committee for InformationTechnology Standards (INCITS), ITI, 1101 K Street, NW, Suite 610, Washington, DC20005.This standard was processed and approved for submittal to ANSI by INCITS. Com-mittee approval of this standard does not nece

31、ssarily imply that all committee mem-bers voted for its approval. At the time it approved this standard, INCITS had thefollowing members:Don Wright, ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeAdobe Systems Inc. . Scott Foshee Steve Zilles (Alt.)AIM Global, Inc. Ste

32、ve HallidayApple Helene WorkmanDavid Singer (Alt.)Distributed Management Task Force John Crandall Jeff Hilland (Alt.)EMC Corporation . Gary Robinson Stephen Diamond (Alt.)Farance, Inc. Frank Farance Timothy Schoechle (Alt.)GS1 US . Frank SharkeyCharles Biss (Alt.)Hewlett-Packard Company Karen Higgin

33、bottom Paul Jeran (Alt.)IBM Corporation Alexander TarpinianRobert Weir (Alt.)Arnaud Le Hors (Alt.)Debra Boland (Alt.)Steve Holbrook (Alt.)Gerald Lane (Alt.)IEEE . Jodie HaaszTerry deCourcelle (Alt.)Bob Labelle (Alt.)Intel Philip Wennblom Grace Wei (Alt.)Stephen Balogh (Alt.)Lexmark International. Do

34、n Wright Dwight Lewis (Alt.)Paul Menard (Alt.)Jerry Thrasher (Alt.)iiiOrganization Represented Name of RepresentativeMicrosoft CorporationJim Hughes Dick Brackney (Alt.)John Calhoon (Alt.)National Institute of Standards and (2) manag-ers and procurement officials who seek to acquire computer securit

35、y products withfeatures that provide access control capabilities according to commonly known andunderstood terminology and functional specifications.AMERICAN NATIONAL STANDARD INCITS 359-2012American National Standard for Information Technology Role Based Access Control 1 1 SCOPE This standard consi

36、sts of two main parts the RBAC Reference Model and the RBAC System and Administrative Functional Specification. The RBAC Reference Model defines sets of basic RBAC elements (i.e., users, roles, permissions, operations and objects) and relations as types and functions that are included in this standa

37、rd. The RBAC reference model serves two purposes. First, the reference model defines the scope of RBAC features that are included in the standard. This identifies the minimum set of features included in all RBAC systems, aspects of role hierarchies, aspects of static constraint relations, and aspect

38、s of dynamic constraint relations. Second, the reference model provides a precise and consistent language, in terms of element sets and functions for use in defining the functional specification. The RBAC System and Administrative Functional Specification specifies the features that are required of

39、an RBAC system. These features fall into three categories, administrative operations, administrative reviews, and system level functionality. The administrative operations define functions in terms of an administrative interface and an associated set of semantics that provide the capability to creat

40、e, delete and maintain RBAC elements and relations (e.g., to create and delete user role assignments). The administrative review features define functions in terms of an administrative interface and an associated set of semantics that provide the capability to perform query operations on RBAC elemen

41、ts and relations. System level functionality defines features for the creation of user sessions to include role activation/deactivation, the enforcement of constraints on role activation, and for calculation of an access decision. Annex A provides a functional specification overview. Informative Ann

42、ex B provides a rationale for the major RBAC components defined in this document. A companion to this standard describes the enhancement of RBAC constraints. The present standard recognizes only constraints that are local to an RBAC environment. These constraints deal only with separation of duty an

43、d cardinality. These constraints are evaluated within the local RBAC environment, as opposed to being provided from outside the local RBAC environment. The RBAC Policy-Enhanced (RPE) standard RPE also specifies constraints evaluated within the local environment. In addition, external constraints or

44、the results of evaluating external constraints are imported into the environment. These constraints may change in real-time. This standard and the RPE standard have the evaluation of constraints as part of the access control decision in common. Thus, they are compatible, with the base standard INCIT

45、S 359-2012 2 addressing more limited constraints and the RPE standard addressing a potentially wide variety of constraints. 2 CONFORMANCE Not all RBAC features are appropriate for all applications. As such, this standard provides a method of packaging features through the selection of functional com

46、ponents and feature options within a component, beginning with a core set of RBAC features that must be included in all packages. Other components that may be selected in arriving at a relevant package of features pertain to role hierarchies, static constraints (Static Separation of Duty), and dynam

47、ic constraints (Dynamic Separation of Duty). INCITS 459-2011, RBAC Implementation and Interoperability Standard, defines acceptable combinations of RBAC features. To conform to this standard, an RBAC system shall comply with all of the core set of RBAC functional specifications in 7.1. Conformance o

48、f an RBAC system to any other functional specifications for a particular component and feature option, found in 7.2 through 7.4, is optional and dependent upon the functional requirements of a particular application. 3 NORMATIVE REFERENCES RIIS INCITS 459-2011 Role Based Access Control Implementatio

49、n and Interoperability Standard. RPE INCITS TBD-2-1x Role Based Access Control Policy Enhanced.(under development as of this writing) This document makes use of the Z formal description language as defined in ISO/IEC 13568:2002, Information technology - Z formal specification notation. 4 TERMS AND DEFINITIONS The following terms have specialized meanings within this standard. component: As used in this standard, component refers to one of the major blocks of RBAC features, core RBAC, hierarchical RBAC, SSD relations, and DSD relations. objects: