ANSI INCITS459-2011 Information Technology - Requirements for the Implementation and Interoperability of Role Based Access Control《信息技术.基于角色访问控制的实施和互操作性要求》.pdf

1、American National StandardDeveloped byfor Information Technology Requirements for theImplementation and Interoperabilityof Role Based Access ControlINCITS 459-2011INCITS 459-2011Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or n

2、etworking permitted without license from IHS-,-,-Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 459-2011American National Standardfor Information Technology Requirements

3、 for theImplementation and Interoperabilityof Role Based Access ControlSecretariatInformation Technology Industry CouncilApproved January 14, 2011American National Standards Institute, Inc.AbstractThis RBAC implementation and interoperability standard is intended for use by developers and consumerso

4、f RBAC products. Developers will ensure conformance of products with the standard and consumers willconsult the standard to compare and evaluate products. Conformance with the standard provides uniformsets of RBAC features and provisions to promote interoperability between RBAC systems. These featur

5、esand provisions can serve as criteria for comparing and evaluating RBAC products.Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-Approval of an American National Standard requi

6、res 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 the ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected

7、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 effort be madetowards their resolution.The use of American National Standards is completely voluntary; theirexist

8、ence 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 to the standards.The American National Standards Institute does not develop standards andwill in no circumst

9、ances 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 the AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat

10、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 StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard.

11、Purchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNational Standards Institute.American National StandardPublished byAmerican National Standards Institute, Inc.25 West 43rd Street, New York, NY 10036Copyright 2011 by Informati

12、on 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 permission of ITI, 1101 K Street NW, Suite 610Washington, DC 20005. Printed in the United States of AmericaCAUTION: T

13、he 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 developers nor the publisher have undertaken a patent search in order to identifywhich, if any, patents may app

14、ly 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 claims have been made. No further patent search is conducted by the de-veloper or publisher in respect to any s

15、tandard it processes. No representation is made or impliedthat licenses are not required to avoid infringement in the use of this standard.Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license fro

16、m IHS-,-,-Contents 1 Scope. 1 2 Conformance. 2 3 References. 2 3.1 Normative . 2 3.2 Non-normative 2 4 Terms and Definitions. 3 5 Abbreviated Terms 4 6 Requirements 4 6.1 Implementation . 5 6.2 Interoperability 6 6.2.1 RBAC Interaction Functions for Interoperability. 6 6.2.2 Data Requirements for In

17、teroperability 8 6.2.3 Policy Rules 8 6.3 Audit and reporting/logging 9 Informative Annex A: Conceptual Model . 10 Informative Annex B: Use Cases for Interoperability . 12 Use Case Syntax . 12 Use Case Examples. 12 Case 1 Company Merger and Integration of Existing RBAC Systems . 12 Case 2 Continuous

18、 Synchronization of External Role Model . 14 Informative Annex C 16 C.1 Introduction 16 C.2 Definition of Two Types of Roles: Structural and Functional 16 Purpose 16 Role Semantics 16 Structural Roles vs Organizational Roles . 17 Roles in ASTM Healthcare Policy and Standard Guide. 17 i Copyright Ame

19、rican National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-iiForeword (This foreword is not part of American National Standard INCITS 459-2011.)This standard provides implementation requirements for Ro

20、le Based Access Control(RBAC) systems, which use RBAC components defined in INCITS 359-2004(R2009). It is an implementation and interoperability standard intended for (1) soft-ware engineers and product development managers who design products incorporat-ing access control features; and (2) managers

21、 and procurement officials who seek toacquire computer security products with features that provide access control capabil-ities in accordance with commonly known and understood terminology and functionalspecifications. The implementation requirements in this standard are intended tosupport the inte

22、rchange of RBAC data (e.g., roles, permissions, users) and thus pro-mote functional interoperability among multiple RBAC systems.Since best practices for RBAC solutions are not readily available, this standard pro-vides implementation requirements for systems and components that comply withINCITS 35

23、9-2004 (R2009). Additional requirements beyond those in INCITS 359-2004 (R2009) are also included.Requests for interpretation, suggestions for improvement or addenda, or defect re-ports are welcome. They should be sent to InterNational Committee for InformationTechnology Standards (INCITS), ITI, 110

24、1 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 necessarily imply that all committee mem-bers voted for its approval. At the time it approved this standard, INCITS had thefollowing

25、members:Don Wright, ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeAdobe Systems Inc. . Scott Foshee Steve Zilles (Alt.)Apple Computer, Inc. . Kwok Lau Helene Workman (Alt.)David Singer (Alt.)Distributed Management Task Force John Crandall Jeff Hilland (Alt.)Electronic

26、 Industries Alliance Edward Mikoski, Jr. Henry Cuschieri (Alt.)EMC Corporation . Gary Robinson Farance Inc. . Frank Farance Timothy Schoechle (Alt.)GS1 US . Ray Delnicki Frank Sharkey (Alt.)James Chronowski (Alt.)Mary Wilson (Alt.)Hewlett-Packard Company Karen Higginbottom Paul Jeran (Alt.)IBM Corpo

27、ration Gerald Lane Robert Weir (Alt.)Arnaud Le Hors (Alt.)Debra Boland (Alt.)Steve Holbrook (Alt.)IEEE . Bill Ash Jodie Haasz (Alt.)Bob Labelle (Alt.)Intel Philip Wennblom Grace Wei (Alt.)Stephen Balogh (Alt.)Copyright American National Standards Institute Provided by IHS under license with ANSI Not

28、 for ResaleNo reproduction or networking permitted without license from IHS-,-,-iiiOrganization Represented Name of RepresentativeLexmark InternationalDon Wright Dwight Lewis (Alt.)Paul Menard (Alt.)Jerry Thrasher (Alt.)Microsoft CorporationJim Hughes Dick Brackney (Alt.)John Calhoun (Alt.)National

29、Institute of Standards & Technology .Michael Hogan Sal Francomacaro (Alt.)Dan Benigni (Alt.)Fernando Podio (Alt.)Teresa Schwarzhoff (Alt.)Wo Chang (Alt.)Oracle CorporationDonald R. Deutsch Jim Melton (Alt.)Michael Kavanaugh (Alt.)Toshihiro Suzuki (Alt.)Jeff Mischkinsky (Alt.)Tony DiCenzo (Alt.)Eduar

30、do Gutentag (Alt.)Purdue University .Stephen Elliott Adam Wamsley (Alt.)Storage Networking Industry Association (SNIA)Gary Phillips Arnold Jones (Alt.)Dave Thiel (Alt.)US Department of Defense .Jerry Smith Dennis Devera (Alt.)Dave Brown (Alt.)Leonard Levine (Alt.)US Department of Homeland Security P

31、eter Shebell Gregg Piermarini (Alt.)Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-ivTechnical Committee CS1 on Cyber Security, which reviewed this standard, had thefollowing m

32、embers:Dan Benigni, Chair(NIST)Eric Hibbard, International Representative(Hitachi Data Systems)Laura Kuiper, Secretary (Cisco Systems, Inc.)Organization Represented Name of RepresentativeAlcatel-Lucent Technologies. Igor FaynbergAmper Politziner & Mattia . (Representation Vacant)Atsec Information Se

33、curity Corporation Fiona PattinsonBooz Allen & Hamilton, Inc. Nadya BartolCERT Coordination Center. Art Manion Cisco Systems, Inc. Laura KuiperConcordant, Inc. . Donald HoldenCygnaCom Solutions Sheila Brand Ernst & Young LLP . (Representation Vacant)Forsythe Solutions Group. Pamela FredericksGemalto

34、 Neville PattinsonHewlett-Packard Company. Eva KuiperHID Global Gary Klinefelter Hitachi Data Systems . Eric HibbardIntel Corporation . David GrawrockMicrosoft Corporation . Mike LaiMitre Corporation James W. MooreNational Security Agency Debby WallnerNIST Richard KisselOrange Parachute Arun Sivaram

35、an PREMIER Bankcard, Inc. . Chuck CincoRaytheon Systems Company . Kenneth KungRSA Security, Inc James RandallSailpoint Technologies Darran Rolls Surety Technologies, Inc. . Dimitri AndivahisSymantec Roger CummingsUnited States Council for International Business Heather ShawUnited States Dept of Defe

36、nse . Richard FernandezZygma Partnership . Richard WilsherTask Group CS1.1 on Role-Based Access Control, which developed and reviewedthis standard, had the following members:Ed Coyne, Chair and Editor(VHA CHIO)Tim Weil, Vice-Chair and Co-Editor(Booz | Allen | Hamilton) Richard Kissel, Co-Editor(NIST

37、)Organization Represented Name of RepresentativeBooz Allen & Hamilton, Inc. Tim WeilHitachi Data Systems . Eric HibbardMicrosoft . Mike LaiNIST Rick KuhnSailpoint Technologies . Darran RollsVHA CHIO Ed CoyneCopyright American National Standards Institute Provided by IHS under license with ANSI Not f

38、or ResaleNo reproduction or networking permitted without license from IHS-,-,-AMERICAN NATIONAL STANDARD INCITS 459-2011American National Standard for Information Technology Requirements for the Implementation and Interoperability of Role Based Access Control 1 1 Scope The System and Administrative

39、Functional Specification clause clause 6 in INCITS 359-2004 (R2009) specifies the features that are required of an RBAC system. These features fall into three categories: administrative operations, administrative reviews, and system level functionality. This standard specifies the implementation of

40、RBAC systems. It describes the packaging of features through the selection of functional components and feature options within a component, beginning with a core set of RBAC features that shall be included in all packages. Other components that may be selected in arriving at a relevant package of fe

41、atures pertain to role hierarchies, static constraints (e.g., Static Separation of Duty or SSD), and dynamic constraints (e.g., Dynamic Separation of Duty or DSD). These are defined in Section 4. This standard specifies that compliant RBAC products shall include an audit and reporting function. This

42、 function is not present in INCITS 359-2004 (R2009), but shall be available in compliant RBAC products. This standard also specifies interoperability requirements that facilitate the exchange of RBAC system data between two systems. Interoperability is here defined as the ability of two systems to p

43、articipate in the exchange of RBAC definition data in a non-operational state. To address this, the standard describes options for the interchange of RBAC elements (e.g., roles, permissions, users) and for functional interoperability among RBAC services and applications. The standard recognizes a di

44、stinction between “Business Role” and “IT Role.” Business roles are those commonly found in the business environment, e.g., an individuals role in the organization. This role is not necessarily implemented in any information technology (IT) system. Thus, a business role is a job function of an indiv

45、idual within an organization. IT roles are those roles that are implemented in an IT system. These roles may reflect business roles, but may also be unique to the IT system because of the particular permissions present in the system. IT roles may themselves be classified into structural roles and fu

46、nctional roles. This distinction is described in Annex C. The scope of this standard covers IT roles and not necessarily business roles. This standard is concerned with the implementation and translation of access privileges within Copyright American National Standards Institute Provided by IHS unde

47、r license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 459-2011 IT systems. In recognition of the fact that systems and components may not include all features described in INCITS 359-2004 (R2009), the definitions of components that derive from

48、INCITS 359-2004 (R2009) may be only partially implemented in RBAC products. The use of this standard is intended for implementations of the RBAC infrastructure. Role definition processes (role engineering) may be addressed in a future standard. This standard provides a generalized syntax and data mo

49、del for developing use cases for implementation of interoperable RBAC systems. 2 Conformance To conform to this standard, an RBAC system shall comply with all or a subset of the requirements in 6.1, 6.2, and 6.3. 3 References 3.1 Normative INCITS 359-2004 (R2009), Role Based Access Control 3.2 Non-normative 1. PMAC, Ber