ASTM E2595-2007 Standard Guide for Privilege Management Infrastructure《权限管理基础组织的标准指南》.pdf

《ASTM E2595-2007 Standard Guide for Privilege Management Infrastructure《权限管理基础组织的标准指南》.pdf》由会员分享，可在线阅读，更多相关《ASTM E2595-2007 Standard Guide for Privilege Management Infrastructure《权限管理基础组织的标准指南》.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、Designation: E 2595 07Standard Guide forPrivilege Management Infrastructure1This standard is issued under the fixed designation E 2595; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the year of last revision. A number in parenthe

2、ses indicates the year of last reapproval. Asuperscript epsilon (e) indicates an editorial change since the last revision or reapproval.INTRODUCTIONThis guide arises from the ongoing development and implementation of privilege managementinfrastructures (PMIs) within the healthcare environment. The h

3、ealthcare environment supported bythis guide is enterprise-wide and extends beyond traditional borders to include external providers,suppliers, and other healthcare partners. This guide supports privilege management within distributedcomputing as well as service-oriented architecture environments. T

4、his guide supports a distributedsecurity environment in which security is also a distributed service.The healthcare sector is continually improving the delivery of care by leveraging technical advancesin computer-based applications. Health professionals are increasingly accessing multiple applicatio

5、nsto schedule, diagnose, and administer patient care. These disparate applications are typicallyconnected to a common network infrastructure that typically supports patient, business, andnonbusiness services, communications, and protocols. Because increased access is made possiblethrough a common ne

6、twork infrastructure, secure access to these distributed, and often looselycoupled applications, is even more important than when these applications were accessed asstand-alone devices.Secure access to legacy computer-based healthcare applications typically involves authentication ofthe user to the

7、application using single-factor identification, such as a password, or multifactoridentification, such as a password combined with a token or biometric devices. After authentication,the application determines the authority that user may have to use aspects of the application.Determining the level of

8、 authority a user has is typically done, if at all, by each application. Theapplication may restrict operations (such as read, write, modify, or delete) to an application-specificgroup or role affiliation. Authenticated users are frequently associated with groups or roles using alocal database or fl

9、at file under the control of an application administrator.The use of a local mechanism for authorization creates a patchwork of approaches difficult toadminister centrally across the breadth of a healthcare enterprise. That is, the software logicdetermining authorization is distinctive to each appli

10、cation. In some cases, applications can be adaptedto use a network database that contains a trusted source of name-value pairs. This information allowsapplications to determine the users group or role affiliation. This approach permits centralized controlover a shared user base. However, the resulti

11、ng granularity of control over user authorization is coarseand shall be interpreted by each application specialist. Granularity of user authority can only beimproved by increasing the number of application-specific groups or roles in the shared database.Storing information specific to each applicati

12、on causes exponential growth of roles per user and resultsin provisioning difficulties. The better solution is to associate industry standard permissions to users.Each application can examine the permissions listed for a user and determine their level ofauthorization regardless of their group affili

13、ation within the healthcare organization.The resulting system is a PMI. By the nature of the problem, the privileges shall be defined in anindustry standard way. This guide will discuss various aspects of identifying a PMI standard tovendors providing healthcare applications to the contemporary heal

14、thcare enterprise.1Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.1. Scope1.1 This guide defines interoperable mechanisms to manageprivileges in a distributed environment. This guide is orientedtowards support of a distributed or ser

15、vice-oriented architec-ture (SOA) in which security services are themselves distrib-uted and applications are consumers of distributed services.1.2 This guide incorporates privilege management mecha-nisms alluded to in a number of existing standards (forexample, Guide E 1986 and Specification E 2084

16、). The privi-lege mechanisms in this guide support policy-based accesscontrol (including role-, entity-, and contextual-based accesscontrol) including the application of policy constraints, patient-requested restrictions, and delegation. Finally, this guide sup-ports hierarchical, enterprise-wide pr

17、ivilege management.1.3 The mechanisms defined in this guide may be used tosupport a privilege management infrastructure (PMI) usingexisting public key infrastructure (PKI) technology.1.4 This guide does not specifically support mechanismsbased on secret-key cryptography. Mechanisms involvingprivileg

18、e credentials are specified in ISO 9594-8:2000 (at-tribute certificates) and Organization for the Advancement ofStructured Information Standards (OASIS) Security AssertionMarkup Language (SAML) (attribute assertions); however, thisguide does not mandate or assume the use of such standards.1.5 Many c

19、urrent systems require only local privilege man-agement functionality (on a single computer system). Suchsystems frequently use proprietary mechanisms. This guidedoes not address this type of functionality; rather, it addressesan environment in which privileges and capabilities (authori-zations) sha

20、ll be managed between computer systems acrossthe enterprise and with business partners.1.6 This standard does not purport to address all of thesafety concerns, if any, associated with its use. It is theresponsibility of the user of this standard to establish appro-priate safety and health practices

21、and determine the applica-bility of regulatory limitations prior to use.2. Referenced Documents2.1 ASTM Standards:2E 1762 Guide for Electronic Authentication of Health CareInformationE 1985 Guide for User Authentication and AuthorizationE 1986 Guide for Information Access Privileges to HealthInforma

22、tionE 2084 Specification for Authentication of Healthcare In-formation Using Digital SignaturesE 2212 Practice for Healthcare Certificate Policy2.2 ANSI Standards:3X9.45 Enhanced Management Controls Using Digital Sig-natures and Attribute CertificatesINCITS 359 Role-Based Access Control2.3 HL7 Stand

23、ard:4Health Level 7 Context Management “CCOW” (ClinicalContext Object Workgroup) Standard, Version 1.52.4 IETF Standards:5RFC 3198 Terminology for Policy-Based ManagementRFC 3280 Internet X.509 Public Key Infrastructure Certifi-cate and Certificate Revocation List (CRL) ProfileRFC 3881 Security Audi

24、t and Access Accountability Mes-sage XML Data Definitions for Healthcare Applications2.5 ISO Standards:6ISO 9594-8 The Directory: Public-Key and Attribute Cer-tificate Frameworks; also available as ITU-T X.509: 2000ISO 10181-3-00 Security Frameworks for Open Systems:Access Control Framework; also av

25、ailable as ITU-TX.812: 1995ISO/TS 21298 Functional and Structure RolesISO/TS 22600-2:2006 Health InformaticsPrivilege Man-agement and Access ControlPart 2: Formal Models2.6 OASIS Standards:7Security Assertion Markup Language (SAML) v2.0SAML 2.0 Profile of XACMLSecurity Provisioning Markup Language (

26、SPML) v2.0,(OASIS)Web Services Business Process Execution Language (WS-BPEL v2)WS-Trust (WS-Trust 1.3)eXtensible Access Control Markup Language (XACML)v2.0XACML Profile for Role Based Access Control (RBAC):Committee Draft 01XACML Profile for Web Services (WS-XACML)2.7 NIST Standards:NIST Special Pub

27、lication 800-33 Underlying TechnicalModels for Information Technology Security, (Stoneb-urner), December 2001NIST Special Publication 800-95 (Draft) Guide to SecureWeb Services, (Singhal, et al), September 2006NIST Special Publication 800-100 Information SecurityHandbook:AGuide for Managers, (Bowen,

28、 et al), October2006FIPS PUB 66 Standard Industrial Classification (SIC)Codes83. Terminology3.1 Definitions:3.1.1 access control decision function (ADF),nspecialized function that makes access control decisions byapplying access control policy rules to a requested action; seepolicy decision point.1T

29、his guide is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcommittee E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved Nov. 15, 2007. Published January 2008.2For referenced ASTM standard

30、s, visit the ASTM website, www.astm.org, orcontact ASTM Customer Service at serviceastm.org. For Annual Book of ASTMStandards volume information, refer to the standards Document Summary page onthe ASTM website.3Available from American National Standards Institute (ANSI), 25 W. 43rd St.,4th Floor, Ne

31、w York, NY 10036, http:/www.ansi.org.4Available from Health Level Seven, Inc., 3300 WashtenawAve., Suite 227,AnnArbor, MI 48104.5Available from Internet Engineering Task Force, www.ieft.org/rfc.html.6Available from International Organization for Standardization (ISO), 1 rue deVaremb, Case postale 56

32、, CH-1211, Geneva 20, Switzerland, http:/www.iso.ch.7Available from www.oasis-open.org/specs/index.php.8Withdrawn Feb. 8, 2005.E25950723.1.2 access control enforcement function (AEF),nspecialized function that is part of the access path betweena requestor and a protected resource that enforces the d

33、ecisionsmade by the ADF; see policy enforcement point.3.1.3 access control information (ACI), nany informationused for access control purposes, including contextual infor-mation.3.1.4 attribute certificate (AC), ndata structure that in-cludes some attribute values and identification informationabout

34、 the owner of the attribute certificate, all digitally signedby an attribute authority (this includes certificates that anauthority issues to itself) and this authoritys signature servesas the guarantee of the binding between the attributes and theirowner.3.1.4.1 DiscussionTypes: role specification

35、and role as-signment described in Ref (1).93.1.5 attribute authority (AA), nauthority, trusted by theverifier to delegate privilege, that issues attribute certificates.3.1.6 attribute authority revocation list (AARL),nrevocation list containing attribute certificates issued toattribute authorities t

36、hat are no longer considered valid by thecertificate issuer.3.1.7 attribute certificate revocation list (ACRL),nrevocation list containing attribute certificates issued toclaimants that are no longer considered valid by the certificateissuer.3.1.8 authority, nentity responsible for the issuance ofce

37、rtificates.3.1.8.1 DiscussionTwo types are defined in this guide:certificate authority that issues public-key certificates andattribute authority that issues attribute certificates.3.1.9 authorization, ngranting of rights that includes thegranting of access based on access rights.3.1.10 authorizatio

38、n credential, nsigned assertion of ausers permission attributes.3.1.11 authority revocation list (ARL), nrevocation listcontaining public-key certificates issued to authorities that areno longer considered valid by the certificate issuer.3.1.12 authority certificate, ncertificate issued to an au-tho

39、rity (for example, either to a certification authority or to anattribute authority).3.1.13 business partner agreement, ndocument used todemarcate the legal, ethical, and practical responsibilitiesbetween subscribers to a privilege management infrastructure(PMI) and between cooperating PMI implementa

40、tions.3.1.14 certificate revocation list (CRL), nsigned list indi-cating a set of certificates that are no longer considered valid bythe certificate issuer.3.1.14.1 DiscussionCRLs may be used to identify re-voked public-key certificates or attribute certificates and mayrepresent revocation of certif

41、icates issued to authorities or tousers. The term CRL is also commonly used as a generic termapplying to all the different types of revocation lists, includingCRLs, ARLs, ACRLs, and so forth.3.1.15 certificate validation, nprocess of ensuring that acertificate is valid, including possibly the constr

42、uction andprocessing of a certification path, and ensuring that all certifi-cates in that path have not expired or been revoked.3.1.16 claimant, nentity requesting that a sensitive ser-vice be performed or provided by a verifier based on theclaimants privileges as identified in its proffered attribu

43、teassertion, attribute certificate, or subject directory attributesextension of their public-key certificate.3.1.17 credential, ninformation describing the securityattributes (identity or privileges or both) of a user or otherprincipal.3.1.17.1 DiscussionCredentials are claimed through au-thenticati

44、on or delegation and used by access control.3.1.18 delegation, nconveyance of privilege from oneentity that holds such privilege to another entity.3.1.19 delegation path, nordered sequence of credentialsthat can be processed to verify the authenticity of a claimantsprivilege.3.1.20 domain, nset of o

45、bjects that a subject is allowed toaccess.3.1.21 environmental variables, nthose aspects of policyrequired for an authorization decision that are not containedwithin structural structures but are available through somelocal means to a verifier (for example, time of day or currentaccount balance).3.1

46、.22 functional role, njob function within the context ofan organization whose permissions are defined by operationson tasks, scenarios, aggregations, or data objects.3.1.22.1 DiscussionFunctional roles provide detailed per-missions defining what a user can do within the context of anapplication. Exa

47、mples include permissions to create an order,permission to sign a check, permission to read a database row,and so forth. A functional role applies to a workflowsindividual process tasks.3.1.23 interoperable role, nas defined by HL7, a jobfunction within the context of two or more organizationsrepres

48、enting the lowest common level of interoperable permis-sions defined by a standardized vocabulary.3.1.24 owner, nentity to whom some privilege has beendelegated either directly from the source of authority orindirectly through another attribute authority.3.1.24.1 DiscussionAn owner asserts its claim

49、 to thatprivilege by presenting authoritative credentials to a verifierand acting as a claimant for its privilege.3.1.25 permission, napproval to perform an operation onone or more protected objects.3.1.26 permission attributes, noperations and objects thatdefine a permission.3.1.27 policy, na set of rules, and an identifier for therule-combining algorithm and (optionally) a set of obligations(OASIS XACML).3.1.28 policy decision point (PDP), nsystem entity thatevaluates applicable policy and renders an authorization deci-sion.3.1.28.1 Discuss