Open Data Center Alliance Usage: Infrastructure as a Service (IaaS) Privileged User Access rev. 1.0

Transcription

1 sm Open Data Center Alliance Usage: Infrastructure as a Service (IaaS) Privileged User Access rev. 1.0

2 Table of Contents Legal Notice... 3 Executive Summary... 4 Related Usage Models... 5 Reference Framework... 5 Applicability... 6 Taxonomy... 6 Usage Scenarios... 7 Privileged User Access... 7 Industry Call to Action...10 References

3 Legal Notice This Open Data Center Alliance SM Usage Model: Infrastructure as a Service (IaaS) Privileged User Access is proprietary to the Open Data Center Alliance, Inc. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Open Data Center Alliance Participants only have the right to review, and make reference or cite, this document. Any such references or citations to this document must give the Open Data Center Alliance, Inc. full attribution and must acknowledge the Open Data Center Alliance, Inc. s copyright in this document. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Open Data Center Alliance Participants is subject to the Open Data Center Alliance s bylaws and its other policies and procedures. OPEN CENTER DATA ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo SM are service marks owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document and its contents are provided AS IS and are to be used subject to all of the limitation set forth herein. Users of this document should not reference any initial or recommended methodology, metric, requirements, or other criteria that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. Any proposals or recommendations contained in this document including, without limitation, the scope and content of any proposed methodology, metric, requirements, or other criteria does not mean the Alliance will necessarily be required in the future to develop any certification or compliance or testing programs to verify any future implementation or compliance with such proposals or recommendations. This document does not grant any user of this document any rights to use any of the Alliance s trademarks. All other service marks, trademarks and trade names referenced herein are those of their respective owners. Published April,

4 sm Open Data Center Alliance Usage: Infrastructure as a Service (IaaS) Privileged User Access rev. 1.0 Executive Summary When an administrator manages a cloud resource on behalf of multiple users or when an administrator accesses resources in the cloud, this role becomes significant in terms of security. The level of access granted to administrators is enhanced in the administrator role and, therefore, the potential risk to the organization is increased. Access breaches that use administrative accounts can lead to significant problems for an enterprise. It is therefore desirable to provide enhanced security controls for these accounts. Many organizations that are considering purchasing cloud-based resources will already have solved this internally by using multi factor authentication (MFA) techniques and seek to use the existing systems to provide initial username/password logon and further factors of authentication to enhance security. This usage model defines a mechanism for extending existing strong authentication methods used in the enterprise to cloud-based resources. It provides cloud providers and subscribers clear guidelines for development of identity management and administrative systems for cloudbased resources. Following these guidelines will promote a single, consistent approach for administrative logon to these resources. It is assumed throughout this usage model that existing Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) standards, using an agreed upon profile, will be used for communication between subscriber and provider systems. This document serves a variety of audiences. Solution providers and technology vendors will benefit from its content to better understand customer needs and tailor service and product offerings. Standards organizations will find the information helpful in defining end-user relevant and open standards. 4

5 Related Usage Models This usage model should be read in conjunction with the ODCA Identity Management Interoperability Guide 1 and the ODCA Provider Assurance Usage Model 2. The Interoperability Guide defines the interaction between the different technical usage models in the identity management area. The Provider Assurance Usage Model defines the overall requirements for security in the cloud and defines where identity management should be used. Reference Framework The following diagram shows a framework of the functional areas of identity management. This framework provides a reference model for the usage models described below. This usage model covers one of the potential cases in strong authentication. Identity and Access Management Framework Identity and Access Management Identity Lifecycle Management Identity and Authentication Management Authorization and Permission Lifecycle Management Authorization and Permission Management Identity Governance Identity Creation/ Validation Identity Federation Entitlement Externalization Access Control Services Confirm Validation Identity Provisioning (add/modify/delete) Directory Services / User Repositories Entitlement Provisioning Policy Enforcement Point (PEP) Auditing and Reporting Mover / Leaver Process Authentication Mover / Leaver Process Policy Decision Point (PDP) Monitoring Strong Authentication Role Mining and Discovery Weak Authentication Reporting for Audit / Compliance Checks Sign On Multiple Sign On Reduced Sign On (web, desktop) Single Sign On Credential Management Policy Enforcement Point (PEP) 1 InteropGuide_Rev1.0_final.pdf 2 5

6 Applicability This usage model is applicable to all types of cloud service including Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The usage model should be applied in cases where Bronze, Silver, Gold or Platinum levels of security, as defined in the ODCA Cloud Provider Assurance Usage Model 2, are required. Correlation of applicability to other use cases can be found in the ODCA Identity Management Interoperability Guide 1 Taxonomy Actor Cloud Subscriber Cloud Subscriber User Cloud Subscriber Administrator Cloud Provider Administrator Cloud Administrator Cloud Provider Identity Provider Description A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. An organization providing network services and charging cloud subscribers. A (public) cloud provider provides services over the Internet. An administrator type of user of a cloud subscriber organization that performs (cloud) system related administration tasks for the cloud subscriber organization. An administrator type of user of a cloud provider organization that performs system related administration tasks on systems that host services for the cloud subscriber organization. An administrator type user that performs administration tasks on a system providing services to a cloud subscriber organization. This is independent of whether the administrator is part of the cloud subscriber organization or whether he/she is part of a cloud provider organization working on resources supplied to the cloud subscriber. An organization providing network services and charging cloud subscribers. A (public) cloud provider provides services over the Internet. An entity that is responsible for establishing and maintaining the digital identity associated with a person, organization, or (in some cases) a software program. [e.g., National Strategy for Trusted Identities in Cyberspace NSTIC] 6

7 Usage Scenarios Privileged User Access This usage model is to be adopted where an administrator of a cloud-based resource requires strong authentication due to the enhanced privileges and higher risk associated with the account. Actors: cloud subscriber, cloud administrator, cloud provider Goal: The cloud subscriber requires the cloud administrator to authenticate by using a further factor of authentication before access is granted to the administrative area of a cloud provider s system. Assumptions: The following assumptions are made regarding authentication: Assumption 1: The cloud subscriber and cloud provider both operate (or have operated for them) identity management systems that are capable of SAML transactions and have provisioned further factor systems that are also SAML capable. The relevant systems that are within the cloud subscriber organization must be accessible by the cloud provider. Assumption 2: Where possible, the identity management systems of the cloud subscriber can generate a SAML message identifying that the cloud subscriber administrator has already completed both authentication steps. Assumption 3: The OASIS SAML standard will be used during all transactions between cloud provider and cloud subscriber. Assumption 4: All transactions between cloud provider and cloud subscriber will only be made using secure protocols. Assumption 5: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: A cloud subscriber administrator is only able to authenticate to the administrative areas of a cloud provider s system or application following a multiple factor authentication at the start of, or during, the session. Steps: 1. The cloud subscriber administrator accesses the administrative area of a cloud-based resource. 2. The cloud provider s system makes a SAML request to the cloud subscriber to confirm the authorization level of the cloud subscriber administrator. 3. If the cloud subscriber administrator is already authenticated using both factors then, a. The identity management system of the cloud subscriber returns a SAML response indicating that access may be granted. b. The cloud provider then allows access to the administrative area of a cloud-based resource. 4. If the cloud subscriber administrator is already authenticated using only a single method of authentication then, a. The cloud provider s system identifies the requirement for a further factor of authentication and passes the cloud subscriber administrator to a web page controlled by the cloud subscriber which allows authentication using a further authentication factor. b. Once successfully authenticated the identity management system of the cloud subscriber returns a SAML message indicating that access may be granted. c. The cloud provider then allows access to the administrative area of a cloud-based resource. 7

8 5. If the cloud subscriber administrator is not authenticated then, Failure Condition 1: a. The cloud provider s system identifies the requirement for authentication and passes the cloud subscriber administrator to a web page controlled by the cloud subscriber which allows authentication. b. Once successfully authenticated, using both factors, the identity management system of the cloud subscriber returns a SAML message indicating that access may be granted. c. The cloud provider then allows access to the administrative area of a cloud-based resource. A cloud provider does not receive all required confirmations from the cloud subscriber s identity management systems. Failure Handling 1: Access to the administration area of the cloud provider s system is denied. In this model, the cloud provider s system should also provide appropriate error and audit messages back to the cloud subscriber administrator and the identity management system of the cloud subscriber. Success Scenario 2: A cloud provider administrator is only able to authenticate to the administrative areas of a cloud provider s system or application, on which services of the cloud subscriber are hosted, following a multiple factor authentication at the start of, or during, the session. Steps: 1. The cloud provider administrator accesses the administrative area of a cloud-based resource. 2. The cloud provider s system makes a SAML request to the internal identity management system to confirm the authorization level of the cloud provider administrator. 3. If the cloud provider administrator is already authenticated using both factors then, a. The identity management system of the cloud provider returns a SAML response indicating that access may be granted. b. The cloud provider then allows access to the administrative area of a cloud-based resource. 4. If the cloud provider administrator is already authenticated using only a single method of authentication then, a. The cloud provider s system identifies the requirement for a further factor of authentication and passes the cloud provider administrator to a system to provide a further factor of authentication. b. Once successfully authenticated, the identity management system of the cloud provider returns a SAML message indicating that access may be granted. c. The cloud provider then allows access to the administrative area of a cloud-based resource. 5. If the cloud provider administrator is not authenticated then, a. The cloud provider s system identifies the requirement for authentication and passes the cloud provider administrator to the systems controlled by the cloud provider which allow authentication. b. Once successfully authenticated using both factors the identity management system of the cloud provider returns a SAML message indicating that access may be granted. c. The cloud provider then allows access to the administrative area of a cloud-based resource. 8

9 Failure Condition 2: A cloud provider does not receive all required confirmations from the internal identity management systems. Failure Handling 2: Access to the administration area of the cloud provider s system is denied. In this model the cloud provider s system should also provide appropriate error and audit messages back to the cloud provider administrator and the event logging systems within the cloud provider organization. Success Scenario 3: A Cloud administrator is only able to complete a specific administrative task on a cloud provider s system or application following further authentication by using a multi factor authentication system. Steps: 1. The cloud administrator requires the completing of a task that requires confirmation of administrative status. 2. The cloud provider s system makes a SAML request to the same system that provided the further factor of authentication at the start of the session. 3. Once authenticated the relevant system will return a SAML response indicating that access may be granted. Failure Condition 3: A cloud provider does not receive all required confirmations from the internal identity management systems. Failure Handling 3: The complete administrative session is terminated, requiring the privileged user to restart the logon process. In this model the cloud provider s system should also provide appropriate error and audit messages back to the cloud provider administrator and the event logging systems within the cloud provider organization. 9

10 Industry Call to Action The following further actions are required: The ODCA requires providers of identity management systems for the enterprise and cloud providers to produce reference models and proofof-concept implementations that will show compliance to this requirement. References OASIS Service Provisioning Markup Language (SPML) Version 2 3 OASIS Security Assertion Markup Language (SAML) Version 2 4 Any use or other implementation of the above cited OASIS markup language specifications / protocols ( OASIS Language ) are subject to any and all intellectual property rights and other rights held by, and any other limitations or restrictions which may be asserted by, OASIS and/or its members as the owner or owners of said OASIS Language ( Proprietary Rights ). ODCA takes no position regarding the validity or scope of any such Proprietary Rights that might be claimed or asserted by OASIS and/ or its members which may pertain to the use or other implementation of said OASIS Language or the extent to which any license of any such Proprietary Rights might or might not be available; nor does it represent that it has made any independent effort to identify any such Proprietary Rights. Each user and implementer of the OASIS Language is solely responsible for obtaining any and all licenses which may be needed in order to use or otherwise implement said OASIS Language. Requests for information regarding the Proprietary Rights and any applicable licenses should only be directed to OASIS and should not be made to the ODCA. Copies of any Proprietary Rights disclosures that may have been made, or potential licenses to be made available, or the result of an attempt made to obtain a license or other permission for the use or implementation of such Proprietary Rights by any implementer or user of the OASIS Language should only be directed to OASIS. This reference to, or citation of, the OASIS Language is provided on an AS IS basis and THE OPEN DATA CENTER ALLIANCE AND ITS PARTICIPANTS AND MEMBERS HEREBY DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY WARRANTY THAT THE USE OR OTHER IMPLEMENTATON OF THE OASIS LANGUAGE (AS DEFINED ABOVE) WILL NOT INFRINGE ANY PROPRIETARY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE