1、Designation: E2595 07 (Reapproved 2013) An American National StandardStandard Guide forPrivilege Management Infrastructure1This standard is issued under the fixed designation E2595; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, t
2、he year of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () indicates an editorial change since the last revision or reapproval.INTRODUCTIONThis guide arises from the ongoing development and implementation of privilege managementinfrastructures (P
3、MIs) within the healthcare environment. The healthcare 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
4、service-oriented architecture environments. This 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 a
5、re increasingly accessing multiple applicationsto 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 increas
6、ed access is made possiblethrough a common network 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 typical
7、ly involves authentication ofthe user to the 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 aspect
8、s of the application.Determining the level of 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 wit
9、h groups or roles using alocal database or flat 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 logicdetermini
10、ng authorization is distinctive to each application. 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 control
11、over a shared user base. However, the resulting 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.S
12、toring information specific to each application 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 ofa
13、uthorization regardless of their group affiliation 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 hea
14、lthcare applications to the contemporary healthcare enterprise.1. Scope1.1 This guide defines interoperable mechanisms to manageprivileges in a distributed environment. This guide is orientedtowards support of a distributed or service-oriented architec-ture (SOA) in which security services are thems
15、elves 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 (forCopyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United StatesNOT
16、ICE: This standard has either been superseded and replaced by a new version or withdrawn.Contact ASTM International (www.astm.org) for the latest information1example, Guide E1986 and Specification E2084). The privilegemechanisms in this guide support policy-based access control(including role-, enti
17、ty-, and contextual-based access control)including the application of policy constraints, patient-requested restrictions, and delegation. Finally, this guide sup-ports hierarchical, enterprise-wide privilege management.1.3 The mechanisms defined in this guide may be used tosupport a privilege manage
18、ment infrastructure (PMI) usingexisting public key infrastructure (PKI) technology.1.4 This guide does not specifically support mechanismsbased on secret-key cryptography. Mechanisms involvingprivilege credentials are specified in ISO 9594-8:2000 (attri-bute certificates) and Organization for the Ad
19、vancement 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 current systems require only local privilege man-agement functionality (on a single computer system).
20、 Suchsystems frequently use proprietary mechanisms. This guidedoes not address this type of functionality; rather, it addressesan environment in which privileges and capabilities (authori-zations) shall be managed between computer systems acrossthe enterprise and with business partners.1.6 This stan
21、dard 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 and determine the applica-bility of regulatory limitations prior to use.2. Referenced Documents2.1 A
22、STM Standards:2E1762 Guide for Electronic Authentication of Health CareInformationE1985 Guide for User Authentication and AuthorizationE1986 Guide for Information Access Privileges to HealthInformationE2084 Specification for Authentication of Healthcare Infor-mation Using Digital Signatures (Withdra
23、wn 2009)3E2212 Practice for Healthcare Certificate Policy2.2 ANSI Standards:4X9.45 Enhanced Management Controls Using Digital Sig-natures and Attribute CertificatesINCITS 359 Role-Based Access Control2.3 HL7 Standard:5Health Level 7 Context Management “CCOW” (ClinicalContext Object Workgroup) Standa
24、rd, Version 1.52.4 IETF Standards:6RFC 3198 Terminology for Policy-Based ManagementRFC 3280 Internet X.509 Public Key Infrastructure Certifi-cate and Certificate Revocation List (CRL) ProfileRFC 3881 Security Audit and Access Accountability Mes-sage XML Data Definitions for Healthcare Applications2.
25、5 ISO Standards:7ISO 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 available as ITU-TX.812: 1995ISO/TS 21298 Functional and Structure RolesISO/TS 22600-2:20
26、06 Health InformaticsPrivilege Man-agement and Access ControlPart 2: Formal Models2.6 OASIS Standards:8Security Assertion Markup Language (SAML) v2.0SAML 2.0 Profile of XACMLSecurity Provisioning Markup Language (SPML) v2.0,(OASIS)Web Services Business Process Execution Language (WS-BPEL v2)WS-Trust
27、 (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 Publication 800-33 Underlying TechnicalModels for Information Technology Security,(Stonebu
28、rner), 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, et al), October2006FIPS PUB 66 Standard Industrial Classification (SIC)Codes93. Terminol
29、ogy3.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.1This guide is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is
30、 the direct responsibility of Subcommittee E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved March 1, 2013. Published March 2013. Originallyapproved in 2007. Last previous edition approved in 2007 as E259507. DOI:10.1520/E2595-07R13.2For referenced
31、ASTM standards, 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.3The last approved version of this historical standard is referenced onwww.as
32、tm.org.4Available from American National Standards Institute (ANSI), 25 W. 43rd St.,4th Floor, New York, NY 10036, http:/www.ansi.org.5Available from Health Level Seven, Inc., 3300 WashtenawAve., Suite 227,AnnArbor, MI 48104.6Available from Internet Engineering Task Force, www.ieft.org/rfc.html.7Ava
33、ilable from International Organization for Standardization (ISO), 1 rue deVaremb, Case postale 56, CH-1211, Geneva 20, Switzerland, http:/www.iso.ch.8Available from www.oasis-open.org/specs/index.php.9Withdrawn Feb. 8, 2005.E2595 07 (2013)23.1.2 access control enforcement function (AEF),nspecialized
34、 function that is part of the access path betweena requestor and a protected resource that enforces the decisionsmade 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 c
35、ertificate (AC), ndata structure that in-cludes some attribute values and identification informationabout 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 gu
36、arantee of the binding between the attributes and theirowner.3.1.4.1 DiscussionTypes: role specification and role as-signment described in Ref (1).103.1.5 attribute authority (AA), nauthority, trusted by theverifier to delegate privilege, that issues attribute certificates.3.1.6 attribute authority
37、revocation list (AARL),nrevocation list containing attribute certificates issued toattribute authorities that 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 l
38、onger considered valid by the certificateissuer.3.1.8 authority, nentity responsible for the issuance ofcertificates.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 authori
39、zation, ngranting of rights that includes thegranting of access based on access rights.3.1.10 authorization 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
40、 considered valid by the certificate issuer.3.1.12 authority certificate, ncertificate issued to an au-thority (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 responsibiliti
41、esbetween subscribers to a privilege management infrastructure(PMI) and between cooperating PMI implementations.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
42、 identify re-voked public-key certificates or attribute certificates and mayrepresent revocation of certificates 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
43、.15 certificate validation, nprocess of ensuring that acertificate is valid, including possibly the construction 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 servicebe per
44、formed or provided by a verifier based on the claimantsprivileges as identified in its proffered attribute assertion,attribute certificate, or subject directory attributes extension oftheir public-key certificate.3.1.17 credential, ninformation describing the securityattributes (identity or privileg
45、es or both) of a user or otherprincipal.3.1.17.1 DiscussionCredentials are claimed through au-thentication 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 cred
46、entialsthat can be processed to verify the authenticity of a claimantsprivilege.3.1.20 domain, nset of objects 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
47、available through somelocal means to a verifier (for example, time of day or currentaccount balance).3.1.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
48、roles provide detailed per-missions defining what a user can do within the context of anapplication. Examples 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 int
49、eroperable role, nas defined by HL7, a jobfunction within the context of two or more organizationsrepresenting 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 to thatprivilege by presenting authoritative credentials to a verifierand acting as a claimant for its privilege.3.1.25 permission, n
