ANSI INCITS 494-2012 Information Technology C Role Based Access Control C Policy-Enhanced.pdf

《ANSI INCITS 494-2012 Information Technology C Role Based Access Control C Policy-Enhanced.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS 494-2012 Information Technology C Role Based Access Control C Policy-Enhanced.pdf（27页珍藏版）》请在麦多课文档分享上搜索。

1、American National StandardDeveloped byfor Information Technology Role Based Access Control Policy-EnhancedINCITS 494-2012INCITS 494-2012INCITS 494-2012American National Standardfor Information Technology Role Based Access Control Policy-EnhancedSecretariatInformation Technology Industry CouncilAppro

2、ved 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 consult thestandard to compare and evaluate pr

3、oducts. 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.Approval of an American National Standard requires review by ANSI

4、 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 interests. Substan

5、tial 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; theirexistence does not in a

6、ny 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 circumstances give an inte

7、rpretation 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 or sponsor whose n

8、ame 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. Purchasers of Amer

9、ican 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 2012 by Information Technology Indu

10、stry 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 610, Washington, DC 20005. Printed in the United States of AmericaCAUTION: The developers of

11、 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 apply to this stand

12、ard. 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 standard it proce

13、sses. No representation is made or impliedthat licenses are not required to avoid infringement in the use of this standard.i CONTENTS Foreword iv 1 SCOPE 1 2 CONFORMANCE 2 3 NORMATIVE REFERENCES 2 4 TERMS AND DEFINITIONS 2 5 THE RBAC POLICY-ENHANCED REFERENCE MODEL 4 5.1 INCITS 359 RBAC COMPONENTS 5

14、 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 INTERFACE 8 5.4 RBAC POLICY ENHANCED CONSTRAINTS 8 5.4.1 DYNAMIC CONSTRAINTS 9 5.4.1.1 Rol

15、e-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 (Static) 10 5.4.2.4 User-role (Static) 11 5.4.3 CONSTRAINT LANGUAGE 11 6 RBAC SYSTEM AN

16、D ADMINISTRATIVE FUNCTIONAL SPECIFICATION 13 6.1 POLICY-ENHANCED ADMINISTRATIVE COMMANDS 13 6.1.1 RPE ADMINISTRATIVE COMMANDS 13 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 C

17、OMMANDS 14 ANNEX A BIBLIOGRAPHY 15 ANNEX B RBAC 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 St

18、atic Constraints 11 Table 4. Syntax for Dyamic Constraints . 12 Table A.1. RIIS Management Functions for RBAC Reference Model Interface 16 iiiForeword (This foreword is not part of American National Standard INCITS 494-2012.)As defined in the original INCITS 359-2004 standard, Role Based Access Cont

19、rol(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 fa-cilitates user-permission management and provides additional security benefits (seethe NIST RBAC website http:/csrc.nist.gov

20、/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 control over the type of ac-cess that can be associated with users and resources. For example, users may needto list directori

21、es and modify existing files without creating new files, or they mayneed to append records to a file without modifying existing records. Increasing theflexibility of controlling access to resources strengthens the application of the princi-ple of least privilege.This standard describes RBAC features

22、 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 alter RBAC constraints as defined inthe body of this document. It also contains two annexes: Annex A - Informative Refer-ences, a

23、nd 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 constructs originally defined in INCITS 359.This standard builds on the features of the INCITS 359 standard, and is intended t

24、obe 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 Committee for InformationTechnology Standards (INCITS), Information Technology Industry Council, 1101 KStreet NW, Suite 610, Was

25、hington, 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 committee mem-bers voted for its approval. At the time it approved this standard, INCITS had thefollowing members:Don Wright, ChairJen

26、nifer Garner, SecretaryOrganization Represented Name of RepresentativeAdobe Systems, IncScott Foshee Steve Zilles (Alt.)AIM Global, Inc.Steve HallidayAppleHelene WorkmanDavid Singer (Alt.)Distributed Management Task Force John Crandall Jeff Hilland (Alt.)EMC Corporation .Gary Robinson Stephen Diamon

27、d (Alt.)Farance, IncFrank Farance Timothy Schoechle (Alt.)Futurewei Technologies, Inc.Yi ZhaoTimothy Jeffreies (Alt.)Wilbert Adams (Alt.)GS1 US .Frank SharkeyCharles Biss (Alt.)Hewlett-Packard Company Karen Higginbottom Paul Jeran (Alt.)ivOrganization Represented Name of RepresentativeIBM Corporatio

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

29、Alt.)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 ses

30、sion 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 bloc

31、ks 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

32、this 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 RB

33、AC 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.

34、INCITS 494-2012 3 operation: An operation is an action executed on an object to perform some function for the user. permission: A permission 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, constr

35、aint. purpose of use. A purpose of use provides context to requests for information resources. role: A role is the representation of 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

36、 activated subset of roles that are assigned to the user. The user provides identification, authorization credentials, and uses resources. 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 conce

37、pt of a user can be extended to include a machine, network, or intelligent autonomous agent, in this document the definition is limited to a person. INCITS 494-2012 4 5 The RBAC Policy-Enhanced Reference Model The RBAC Policy-Enhanced reference model consists of an RBAC Engine (see Figure 1) that co

38、ntrols 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 (ROLES), objects (OBS), operations (OPS),

39、 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. They include an External Policy interface,

40、 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, roles, operations, objects, and permission

41、s. 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 security relevant events. INCITS 494-2012 5 T

42、he functional characteristics of the RBAC Policy-Enhanced Reference Model include: INCITS 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 Subclaus

43、e 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

44、-role assignment and permission-role assignment relations, considered fundamental in any RBAC system. In addition, core RBAC introduces the concept of role activation as part of a users session within a computational environment. Core RBAC is required in any RBAC system, but constrained and hierarch

45、ical RBAC are independent of each other and may be implemented separately in accordance with the RBAC Implementation and Interoperability Standard (RIIS) INCITS 459-2011. 5.1.2 Constrained RBAC The INCITS 359 RBAC standard specifies constraints on how roles behave. The constraints specified in INCIT

46、S 359 consist solely of dynamic and static separation of duty and cardinality constraints. In this standard enhanced constraints on role behavior are defined as a larger set. The term “Policy-Enhanced” is used to indicate that policy rules external to the core RBAC model can be reflected when access

47、 control decisions are being made. These external policy rules can provide separation of duty and cardinality constraints as well as other constraints, such as time of day, geographical location, and data object value. In the Policy-Enhanced reference model, the RBAC Engine evaluates constraints and

48、 applies them to a core RBAC representation. 5.1.3 Hierarchical RBAC Hierarchies among roles are included in the policy enhanced RBAC reference model. The RBAC Engine evaluates hierarchies to reduce role structures to core RBAC constructs. This reduction is done to simplify the model and, ultimately

49、, to simplify access control decisions. If constraints exist, they are applied during the hierarchy evaluation process. This standard includes specifications for management of hierarchies. INCITS 494-2012 6 The hierarchical RBAC component adds relations for supporting role hierarchies. Mathematically, a hierarchy is mathematically a partial order defining a seniority relation between roles. Senior roles acquire the permissions of their junior roles via inheritance and junior roles in effect acquire the users of the roles senior to them. 5.2 RBAC Engin