ANSI INCITS494-2012 Information technology - Role Based Access Control - Policy Enhanced《信息技术.基于角色的访问控制.增强政策》.pdf

《ANSI INCITS494-2012 Information technology - Role Based Access Control - Policy Enhanced《信息技术.基于角色的访问控制.增强政策》.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS494-2012 Information technology - Role Based Access Control - Policy Enhanced《信息技术.基于角色的访问控制.增强政策》.pdf（27页珍藏版）》请在麦多课文档分享上搜索。

1、American National StandardDeveloped byfor Information Technology Role Based Access Control Policy-EnhancedINCITS 494-2012INCITS 494-2012Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from I

2、HS-,-,-Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 494-2012American National Standardfor Information Technology Role Based Access Control Policy-EnhancedSecretariatIn

3、formation Technology Industry CouncilApproved July 26, 2012American National Standards Institute, Inc.AbstractThis RBAC Policy-Enhanced standard is intended for use by developers and consumers of RBAC prod-ucts. Developers will ensure conformance of products with the standard and consumers will cons

4、ult thestandard to compare and evaluate products. Conformance with the standard provides uniform sets ofRBAC features and provisions to promote interoperability between RBAC systems. These features andprovisions can serve as criteria for comparing and evaluating RBAC products.Copyright American Nati

5、onal 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 requires review by ANSI that therequirements for due process, consensus, and other criteria for approval haveb

6、een 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 interests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Co

7、nsensus 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; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufactu

8、ring, marketing, purchasing, or usingproducts, processes, or procedures not conforming 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 o

9、r 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 or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National St

10、andard 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. Purchasers of American National Standards mayreceive current information on all standards by calling or w

11、riting the AmericanNational Standards Institute.American National StandardPublished byAmerican 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

12、anyform, in an electronic retrieval system or otherwise,without prior written permission 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 imple

13、mentation 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 apply to this standard. As of the date of publication of this standardand following calls for the identifi

14、cation 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 standard it processes. No representation is made or impliedthat licenses are not required to avoid infri

15、ngement 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 from IHS-,-,-i CONTENTS Foreword iv 1 SCOPE 1 2 CONFORMANCE 2 3 NORMATIVE REFERENCES 2 4 TERMS AND DEFINIT

16、IONS 2 5 THE RBAC POLICY-ENHANCED REFERENCE MODEL 4 5.1 INCITS 359 RBAC COMPONENTS 5 5.1.1 CORE RBAC 5 5.1.2 CONSTRAINED RBAC 5 5.1.3 HIERARCHICAL RBAC 5 5.2 RBAC ENGINE 6 5.3 EXTERNAL INTERFACES 7 5.3.1 EXTERNAL POLICY RULES INTERFACE 7 5.3.2 AUDIT INTERFACE 8 5.3.3 RIIS MANAGEMENT FUNCTIONS INTERF

17、ACE 8 5.4 RBAC POLICY ENHANCED CONSTRAINTS 8 5.4.1 DYNAMIC CONSTRAINTS 9 5.4.1.1 Role-Role (Dynamic) 9 5.4.1.2 User-Role (Dynamic) 9 5.4.1.3 Attribute-sensitive (Dynamic) 9 5.4.2 STATIC CONSTRAINTS 10 5.4.2.1 Role-Role (Static) 10 5.4.2.2 Permission-permission (Static) 10 5.4.2.3 Permission-role (St

18、atic) 10 5.4.2.4 User-role (Static) 11 5.4.3 CONSTRAINT LANGUAGE 11 6 RBAC SYSTEM AND ADMINISTRATIVE FUNCTIONAL SPECIFICATION 13 6.1 POLICY-ENHANCED ADMINISTRATIVE COMMANDS 13 6.1.1 RPE ADMINISTRATIVE COMMANDS 13 Copyright American National Standards Institute Provided by IHS under license with ANSI

19、 Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-ii 6.2 SUPPORTING SYSTEM COMMANDS 14 6.2.1 NEW SYSTEM FUNCTION COMMANDS 14 6.2.2 EXTERNAL INTERFACE SUPPORTING SYSTEM COMMANDS 14 6.3 REVIEW COMMANDS 14 6.3.1 RPE REVIEW COMMANDS 14 ANNEX A BIBLIOGRAPHY 15 ANNEX B RB

20、AC IMPLEMENTATION AND INTEROPERABILITY MANAGEMENT FUNCTIONS 16 Figures Figure 1 RBAC Policy-Enhanced Reference Model . 4 Figure 2 RBAC Engine Algorithm . 7 Tables Table 1. RPE Dynamic Constraints 9 Table 2. RPE Static Constraints 10 Table 3. Syntax for Static Constraints 11 Table 4. Syntax for Dyami

21、c Constraints . 12 Table A.1. RIIS Management Functions for RBAC Reference Model Interface 16 Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-iiiForeword (This foreword is not p

22、art of American National Standard INCITS 494-2012.)As defined in the original INCITS 359-2004 standard, Role Based Access Control(RBAC), permissions are assigned to roles rather than to individual users. Users arethen assigned to roles rather than directly to permissions. This level of indirection f

23、a-cilitates user-permission management and provides additional security benefits (seethe NIST RBAC website http:/csrc.nist.gov/rbac). Without the benefits and conve-niences provided by RBAC, there is an enhanced danger that a user may be grantedmore access to resources than is needed due to limited

24、control over the type of ac-cess that can be associated with users and resources. For example, users may needto list directories and modify existing files without creating new files, or they mayneed to append records to a file without modifying existing records. Increasing theflexibility of controll

25、ing access to resources strengthens the application of the princi-ple of least privilege.This standard describes RBAC features that have been identified since the publica-tion of INCITS 359-2004. In particular, the term RBAC Policy-Enhanced refers theuse of external security policy mechanisms to alt

26、er RBAC constraints as defined inthe body of this document. It also contains two annexes: Annex A - Informative Refer-ences, and Annex B - RBAC Implementation and Interoperability.Development of this standard reflects a need in the authorization community to en-hance and generalize the concepts and

27、constructs originally defined in INCITS 359.This standard builds on the features of the INCITS 359 standard, and is intended tobe a companion for that standard.Requests for interpretation, suggestions for improvement or addenda, or defect re-ports are welcome. They should be sent to InterNational Co

28、mmittee for InformationTechnology Standards (INCITS), Information Technology Industry Council, 1101 KStreet NW, Suite 610, Washington, DC 20005. This standard was processed and approved for submittal to ANSI by INCITS. Com-mittee approval of this standard does not necessarily imply that all committe

29、e 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, IncScott Foshee Steve Zilles (Alt.)AIM Global, Inc.Steve HallidayAppleHelene WorkmanDavid

30、 Singer (Alt.)Distributed Management Task Force John Crandall Jeff Hilland (Alt.)EMC Corporation .Gary Robinson Stephen Diamond (Alt.)Farance, IncFrank Farance Timothy Schoechle (Alt.)Futurewei Technologies, Inc.Yi ZhaoTimothy Jeffreies (Alt.)Wilbert Adams (Alt.)GS1 US .Frank SharkeyCharles Biss (Al

31、t.)Hewlett-Packard Company Karen Higginbottom Paul Jeran (Alt.)Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-ivOrganization Represented Name of RepresentativeIBM Corporation A

32、lexander 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.Don Wright Dwight Lewis (Alt.)Paul Menard (Alt

33、.)Jerry Thrasher (Alt.)Microsoft Corporation.Jim Hughes Dick Brackney (Alt.)John Calhoon (Alt.)National Institute of Standards the power set of the set X is indicated by the notation 2X. 4 Terms and Definitions The following terms have specialized meanings within thisstandard. attribute: RBAC sessio

34、n attributes as used in this document are a characteristic of a subject, resource, action, or environment that may be referenced in a predicate or target. audit data: audit records written to an external audit service. component: As used in this standard, component refers to one of the major blocks

35、of RBAC features, core RBAC, hierarchical RBAC, and constraint relations. constraint: A constraint is a relation among role features that acts as a restriction. This standard describes both static constraints (administratively controlled) and dynamic constraints (run time) delegation: As used in thi

36、s standard, delegation is the authorized reassignment of a role by a user who is already assigned to that role. external policy rules: Imported constraints and data values for use in making role-base access control decisions. feature: A feature is loosely defined as an item contained within an RBAC

37、design to provide functionality. object: As used in this standard, an object can be any system resource subject to access control, such as a file, printer, terminal, database record, or workflow. An object can be a container of other objects that share the protection properties of the container. Cop

38、yright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 494-2012 3 operation: An operation is an action executed on an object to perform some function for the user. permission: A pe

39、rmission is an approval to perform an operation on one or more RBAC protected objects. policy. A policy is a set of tuples consisting of object, operation, role, constraint. purpose of use. A purpose of use provides context to requests for information resources. role: A role is the representation of

40、 a job function within an information technology system. role name: A role name is a label that identifies a role. session: A session is a mapping between a user and an activated subset of roles that are assigned to the user. The user provides identification, authorization credentials, and uses reso

41、urces. A session is terminated by a system or by the user. user: A user is a representation within an information technology system of a human being. Although the concept of a user can be extended to include a machine, network, or intelligent autonomous agent, in this document the definition is limi

42、ted to a person. Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 494-2012 4 5 The RBAC Policy-Enhanced Reference Model The RBAC Policy-Enhanced reference model consists o

43、f an RBAC Engine (see Figure 1) that controls all decisions with interfaces to data and processes external to the RBAC Engine. It contains a representation of core RBAC (INCITS 359) that define its logical components. Core RBAC includes sets of five basic data elements called users (USERS), roles (R

44、OLES), objects (OBS), operations (OPS), and permissions (PRMS). This core RBAC representation includes user assignments, permission assignments, and permissions. Figure 1 RBAC Policy-Enhanced Reference Model There are three external interfaces defined in the RBAC Policy-Enhanced Reference Model. The

45、y include an External Policy interface, a standardized RIIS Management Functions interface, and an Audit Data interface. External policies are rules and data that implement constraints on the core role components within the RBAC Engine and define dynamic constraints that may be applied to users, rol

46、es, operations, objects, and permissions. RIIS Management Functions allow the import and export of RBAC operations as defined in INCITS 459 and serve to communicate RBAC system definitions within and external to the RBAC Engine. The Audit Data interface provides logging information to capture securi

47、ty relevant events. Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-INCITS 494-2012 5 The functional characteristics of the RBAC Policy-Enhanced Reference Model include: INCITS

48、359 RBAC components (core, hierarchical, constrained RBAC) RBAC Engine External Interfaces (RIIS, Policy, Audit) Enhanced Constraints (dynamic and static) 5.1 INCITS 359 RBAC Components 5.1.1 Core RBAC Subclause 5.1 of INCITS 359 defines core RBAC. This standard is based on the same definition. The core RBAC model provides the following access control policy. Core RBAC defines a minimum collection of RBAC elements, element sets, and relations needed to completely achieve an RBAC system. This includes user-role assignment and permission-role assignment relations, con