Practical Guide to Cloud Service Agreements Version 2.0

Transcription

1 Practical Guide t Clud Service Agreements Versin 2.0 April 2015

2 Cntents Acknwledgements... 3 Revisins... 3 Intrductin... 4 The Current CSA Landscape... 4 Guide fr Evaluating Clud Service Agreements... 6 Step 1: Understand Rles & Respnsibilities... 6 Step 2: Evaluate Business Level Plicies... 9 Step 3: Understand Service and Deplyment Mdel Differences Step 4: Identify Critical Perfrmance Objectives Step 5: Evaluate Security and Privacy Requirements Step 6: Identify Service Management Requirements Step 7: Prepare fr Service Failure Management Step 8: Understand the Disaster Recvery Plan Step 9: Develp an Effective Gvernance Prcess Step 10: Understand the Exit Prcess Summary f Keys t Success Wrks Cited Additinal References Cpyright 2015 Clud Standards Custmer Cuncil Page 2

3 2015 Clud Standards Custmer Cuncil. All rights reserved. Yu may dwnlad, stre, display n yur cmputer, view, print, and link t the Practical Guide t Clud Service Level Agreements at the Clud Standards Custmer Cuncil Web site subject t the fllwing: (a) the Guidance may be used slely fr yur persnal, infrmatinal, nncmmercial use; (b) the Guidance may nt be mdified r altered in any way; (c) the Guidance may nt be redistributed; and (d) the trademark, cpyright r ther ntices may nt be remved. Yu may qute prtins f the Guidance as permitted by the Fair Use prvisins f the United States Cpyright Act, prvided that yu attribute the prtins t the Clud Standards Custmer Cuncil Practical Guide t Clud Service Level Agreements Versin 1.0 (2012). Acknwledgements The majr cntributrs t this whitepaper are: Claude Baudin (cébé IT & Knwledge Management), Beniamin Di Martin (Secnd University f Naples), Marln Edwards (Hbken Cnsulting Grup, LLC), Mike Edwards (IBM), David Harris (Being), Ryan Kean (The Krger C.), Yves Le Rux (CA Technlgies), Gerge Malekks (Pwersft Cmputer Slutins Ltd), Jhn McDnald (CludOne Crpratin), Jhn Meegan (IBM), Gerry Murray (Frt Technlgies), Massimilian Rak (Secnd University f Naples), Dave Russell (IBM), Karlyn Schalk (Garden f The Intellect LLC), Gurpreet Singh (Ekartha), Annie Skl (NIST), Je Talik (AT&T), Salvatre Venticinque (Secnd University f Naples), Steven Wdward (Clud Perspectives) Revisins Much has changed in the realm f clud cmputing service agreements since the riginal Practical Guide t Clud Service Agreements whitepaper was published in April, Versin 2.0 f the dcument includes the fllwing updates: Terminlgy changes have been made; specifically, the term service level agreement (SLA) has been replaced by clud service agreement (CSA) t reference the brad agreement that is established between clud custmers and prviders. The term SLA is nw used t reference that part f the brader CSA that deals specifically with service levels. The Current CSA Landscape sectin has been updated substantially t reflect current market dynamics. All ten steps in the Guide fr Evaluating Clud Service Agreements sectin have been updated t reflect current best practices. Significant changes have been made t steps 1, 5 and 9. References t clud cmputing standards have been updated. References have been added t several CSCC whitepapers that have been recently published. Cpyright 2015 Clud Standards Custmer Cuncil Page 3

4 Intrductin The Practical Guide t Clud Service Agreements prvides a practical reference t help enterprise infrmatin technlgy (IT) and business decisin makers analyze clud service agreements (CSAs) frm different clud service prviders. The paper infrms decisin makers f what t expect and what criteria t use as they evaluate CSAs frm such ptential suppliers. CSAs are primarily written t set clear expectatins fr service between the clud custmer (buyer) and the clud prvider (seller), but shuld als exist between a custmer and ther clud entities, such as the clud carrier, the clud brker and even the clud auditr. This Guide fcuses primarily n the CSA details between the clud custmer and clud prvider. There may be different requirements fr the cntent f a CSA accrding t the service delivery mdel selected: Infrastructure as a Service (IaaS), Platfrm as a Service (PaaS), r Sftware as a Service (SaaS). In this Guide, we fcus n the requirements that are cmmn acrss the varius service mdels. The Current CSA Landscape sectin explains the dynamics that currently exists between clud custmers and prviders, and the impact that cmpany size has n the pwer t negtiate terms. This sectin als highlights the nuances f CSA develpment fr different service mdels. The Guide fr Evaluating Clud Service Agreements sectin is the heart f the paper. It prvides a prescriptive series f steps that clud custmers shuld take t evaluate CSAs in rder t cmpare multiple clud prviders r t negtiate terms with a selected prvider. This sectin takes int accunt the realities f tday s clud cmputing ecsystem and pstulates hw it is likely t evlve, including the imprtant rle that standards will play t imprve interperability and cnsistency acrss prviders. A related dcument, the Public Clud Service Agreements: What t Expect and What t Negtiate [1], prvides additinal details n evaluating CSAs frm prspective public clud prviders. The Current CSA Landscape CSAs are a set f dcuments r agreements that cntain the terms gverning the relatinship between the clud custmer and the clud service prvider. Because the clud cmputing market is still develping, clud custmers shuld be aware that there may be a mismatch between their expectatins and the clud prviders actual service terms. Fr example, a CSA may nt specify the gegraphic lcatin where custmer data will be stred. This culd be a shwstpper fr custmers subject t exprt restrictins f certain types f data frm the U.S., r the exprt f persnal data frm the Eurpean Ecnmic Area (EEA). It is cmmn fr disputes t arise ver the structure f the agreements, thus clud custmers must pay clse attentin t the language and clauses f the CSA. Large clud prviders can be inflexible with their CSAs, while small clud prviders may seem mre flexible, but tend t verprmise in rder t btain clients. Cpyright 2015 Clud Standards Custmer Cuncil Page 4

5 In general, the CSA is cmprised f three majr artifacts: Custmer Agreement Acceptable Use Plicy (AUP) Service Level Agreement (SLA) This classificatin is nt cmplete, nr is it unifrmly adpted by the clud industry: n standard nmenclature is used acrss the varius clud prviders t specify their CSAs. Furthermre, clud prviders can mdify their cntract structure and terms at any time. The Custmer Agreement sectin f the CSA describes the verall relatinship between the custmer and prvider. Since service management includes the prcesses and prcedures used by the clud prvider, explicit definitins f the rles, respnsibilities and executin f prcesses need t be frmally agreed upn. The Custmer Agreement fulfills this need. Varius synnyms such as Master Agreement, Terms f Service, r simply Agreement may be used by certain prviders. An Acceptable Use Plicy (AUP) is cmmnplace within a CSA. The AUP prhibits activities that prviders cnsider t be an imprper r utright illegal use f their service. This is ne area f a CSA where there is cnsiderable cnsistency acrss clud prviders. Althugh specific details f acceptable use will vary amng IaaS, SaaS and PaaS prviders, the scpe and effect f these plicies is the same, and these prvisins typically generate the least cncerns r resistance. A typical Service Level Agreement (SLA) within the CSA describes levels f service using varius attributes such as availability, serviceability r perfrmance. The SLA specifies threshlds and financial penalties assciated with vilatins f these threshlds. Well-designed SLAs can significantly cntribute t aviding cnflict and can facilitate the reslutin f an issue befre it escalates int a dispute. T guarantee an agreed service level, service prviders must measure and mnitr relevant metrics. There is ften a mismatch between the metrics cllected and mnitred by the service prvider and the higher-level functinal (r end-t-end ) metric relevant t custmers. This issue is cmmn acrss service mdels, but is mre acute fr SaaS since custmers want service levels t be met at the applicatin level where they can be impacted by many factrs. This is ne reasn why CSAs fr SaaS usually lack stringent service level guarantees. Service level guarantees fr IaaS are better defined than fr SaaS r PaaS, but that des nt mean that they meet the custmer s expectatins. Mst public clud infrastructure services are available nly thrugh nn-negtiable standard cntracts which strictly limit the prvider s liability. As a result, the remedies ffered in case f nn-cmpliance d nt match the cst t the custmer f the ptential service disruptins. Furthermre, mst IaaS prviders put the burden f SLA vilatin ntificatin and credit request n their custmers. In many cases, clud SLAs d nt ffer refunds f charges but rather service credits against future use. Whether the relief is in the frm f a credit r a refund, it is usually subject t a cap such as ne mnth s standard billing. Credits against future billing will be f little r n benefit t custmers that decide t Cpyright 2015 Clud Standards Custmer Cuncil Page 5

6 switch prviders fllwing unsatisfactry service and they clearly are meant t encurage the custmer t stay with the current prvider. This rather biased situatin is starting t evlve. As custmers becme mre knwledgeable and cmpetitin increases, clud prviders are beginning t ffer different service ptins that better shield custmers frm such risks. Fr clud custmers, size als matters. In general, the larger the custmer deplyment, which translates t higher setup and mnthly fees, the mre pwer the custmer can exert in negtiating mre favrable CSAs, even with SaaS prviders. N such imprvements may be ffered t small and medium businesses, but ver time we expect the changes impsed by larger custmers t trickle dwn t all ther custmers. Better CSAs will inevitably becme a cmpetitive factr. Eventually, custmers f all sizes will be able t chse frm a range f service terms that are mre favrable and mre flexible. Guide fr Evaluating Clud Service Agreements Befre getting t the pint f evaluating any CSA, custmers must first perfrm a number f strategic steps (develp a cmprehensive business case and strategy, select clud service and deplyment mdels, etc.) that are detailed in the Practical Guide t Clud Cmputing [2]. With this strategic analysis as a prerequisite, this sectin prvides a prescriptive series f steps that shuld be taken by clud custmers t evaluate CSAs in rder t cmpare multiple clud prviders r t negtiate terms with a selected prvider. The fllwing steps are discussed in detail: 1. Understand rles and respnsibilities 2. Evaluate business level plicies 3. Understand service and deplyment mdel differences 4. Identify critical perfrmance bjectives 5. Evaluate security and privacy requirements 6. Identify service management requirements 7. Prepare fr service failure management 8. Understand the disaster recvery plan 9. Develp an effective gvernance prcess 10. Understand the exit prcess Requirements and best practices are highlighted fr each step. In additin, each step takes int accunt the realities f tday s clud cmputing landscape and pstulates hw this space is likely t evlve in the future, including the imprtant rle that standards will play t imprve interperability and cmparability acrss prviders. Step 1: Understand Rles & Respnsibilities Frm the clud service custmer perspective, ne f the significant areas f risk invlved with clud cmputing is assciated with the divisin f activities and respnsibilities between the clud service custmer and the clud service prvider. It is necessary t have a full understanding f wh is Cpyright 2015 Clud Standards Custmer Cuncil Page 6

7 respnsible fr which activities t ensure that there are n gaps which culd lead t prblems when using clud services. The ISO/IEC clud cmputing reference architecture standard 1 has 3 main rles fr clud cmputing: Clud service custmer Clud service prvider Clud service partner The clud service prvider and the clud service custmer are the mst significant rles in the prvisin and use f clud services while the clud service partner is a party engaged in supprt f the activities f the clud service custmer and/r the clud service prvider. There are a number f subrles f each f the majr rles the subrles are shwn in Figure 1: Clud Service Partner Clud service user Clud Service Custmer Clud service administratr Clud service business manager Clud service integratr Clud service develper Clud Service Prvider Clud auditr clud service peratins manager clud service deplyment manager clud service administratr clud service business manager Clud service brker custmer supprt & care representative inter-clud prvider clud service security & risk manager netwrk prvider Figure 1. Clud Cmputing Rles and Subrles Each f the subrles in Figure 1 has a set f activities and respnsibilities which are described in highlevel terms in ISO/IEC There are als relatinships between the subrles - fr example, the clud service administratr f the custmer may interact with the custmer supprt and care representative f the prvider in cases where custmer persnnel experience prblems using the clud service. 1 See fr the ISO standard. Cpyright 2015 Clud Standards Custmer Cuncil Page 7

8 Sme f the subrles may appear in a CSA, r they may have a direct r indirect relatinship t sme aspects f the CSA. The subrles f the clud service custmer and the clud service prvider, in particular, are invlved in the split f respnsibilities that is typical fr clud services - the CSA shuld make clear statements abut thse respnsibilities. Clud service custmers need t understand the activities and respnsibilities f the varius subrles and ensure that the CSA and its assciated SLA cntains apprpriate cmmitments and service level targets t address thse activities and respnsibilities fr the clud service(s) cvered by the CSA. One imprtant area fr custmers t cnsider is wh is respnsible fr detecting and then reprting incidents where the clud service fails t meet sme aspect f the CSA r SLA. This can include utages where the clud service is unavailable, r may include cases where perfrmance fails t meet stated service levels (fr example, respnse times are t lng). Hw such incidents are detected must be established - it may be the respnsibility f the custmer and the custmer may need t put in place apprpriate mnitring technlgy. It is als necessary t be clear abut hw incidents are then reprted and tracked until reslved. One partner rle that is particularly relevant t the CSA and t SLAs is the clud auditr. It is unlikely that the clud service custmer has direct insight int the peratins f the clud service prvider, particularly regarding aspects such as security and the prtectin f sensitive data such as persnally identifiable infrmatin (PII). It is typical fr clud service prviders t ffer assurances abut these aspects f their clud services thrugh certificatins r attestatins which are prvided by third party clud auditrs wh inspect the clud service prvider s peratins and issue reprts typically based n ne r mre standards r certificatin schemes. Each CSA may be unique based upn the custmers requirements and the clud services under cnsideratin. CSAs can cntain varius elements and are nt limited t quantitative measures, but can include ther qualitative aspects such as alignment with standards and data prtectin. It is strngly recmmended that clud service custmers gain a slid understanding f the spectrum f CSAs that currently exist fr clud service prviders in rder t cmpare clud services ffered by different prviders and assess tradeffs between cst and service levels. Refer t the CSCC whitepaper Public Clud Service Agreements: What t Expect and What t Negtiate [1] fr details. It is imprtant t recgnize that the cntent f a CSA and assciated SLA is likely t vary depending n the categry f the clud service. Cnsideratins fr an IaaS service ffering cmpute and strage infrastructure are likely t be very different frm thse fr a SaaS service that ffers cmplete applicatin functinality fr sme business functins. At the very least, the split f respnsibilities between the prvider and the custmer are ging t be different fr these different cases, and this is necessarily reflected in differences in the CSA and SLA. The fllwing sectins, which cver the clud CSA evaluatin steps in detail, each elabrate n the expected respnsibilities f the custmer and the prvider fr bth business level and service level bjectives. In rder t make sund business decisins, it is imprtant that custmers understand what Cpyright 2015 Clud Standards Custmer Cuncil Page 8

9 t expect frm their clud service prvider. This, in turn, will help them clarify their wn respnsibilities and help them assess the true cst f mving t clud cmputing. Step 2: Evaluate Business Level Plicies Custmers must cnsider the plicy and cmpliance requirements relevant t them when reviewing a CSA since there are interdependencies between the plicies expressed in the CSA and the business strategy and plicies develped acrss the lines f business. The data plicies f the clud prvider, as expressed in the CSA, are perhaps the mst critical business level plicies and shuld be carefully evaluated. The bligatins a clud prvider has t its custmers and their data is gverned by a ptentially cmplex cmbinatin f: custmer requirements, the data prtectin legislatin applicable t the custmer as well as t its individual users (which may nt be under the same jurisdictin in a multinatinal cmpany) the laws and regulatins applicable where the data resides r is made available. Custmers shuld carefully cnsider these legal requirements and hw the CSA deals with issues such as mvement f data when redundancy acrss multiple sites means subjecting the data t different jurisdictins at different times. The issue f jurisdictin takes n additinal cmplexity when glbal cmpliance is taken int cnsideratin and mre than ne clud prvider is used. In these instances the custmer may have t crdinate negtiatins between prviders t ensure the necessary data management. Table 1 highlights the critical data plicies that need t be cnsidered and included in the clud CSA. Table 1. CSA Data Plicies Data Plicy Data Preservatin and Redundancy Descriptin / Guidance Timely and efficient capturing and preservatin f data is critical t maintaining the rganizatinal memry f a business r the general user. Custmers shuld therefre ensure they have an apprpriate data preservatin strategy that addresses redundancy within the system. Clud custmers shuld ensure the CSA supprts their data preservatin strategy that includes surces, scheduling, backup, restre, integrity checks, etc. They shuld be cncerned as t the prtectins ffered r mitted by the service prvider. It must be pssible t test the CSA t demnstrate the required level f service availability. Cpyright 2015 Clud Standards Custmer Cuncil Page 9

10 Data Plicy Descriptin / Guidance Data Lcatin CSAs that cver lcatins under different jurisdictins are challenging. Custmers shuld cnsider hw the CSA specifies where their data resides, where it is prcessed, and hw this meets the varius applicable regulatins. Custmers shuld als understand where the data is viewed r delivered, and whether this results in a transbrder data flw with regulatry r tax implicatins. Fr example, can the prvider truly deliver a sund technical slutin when sensitive data spans several jurisdictins with cnflicting laws? Des the prvider cmmit, in the CSA, t the specific lcatin(s) where the custmer s data will be stred? If the prvider reserves the right t add new lcatins r change data mvement plicies, will they give the custmer advice ntice? Preferably, will they btain the custmer s permissin t relcated its data? Is there a means t verify the current lcatin f a data set? Data Seizure Legal pwers enable law enfrcement and ther gvernment agencies t seize data under certain circumstances. Custmers shuld ensure the CSA prvides fr sufficient ntificatin f such events. Custmers shuld als ensure there are arrangements in place t make their data available in the event that their prvider ges ut f business. in the event that the prvider lcks access t its systems because f a billing dispute r a security issue, the custmer s date shuld nt be held hstage while the issue is being reslved. Data Privacy The prvider s data privacy plicy shuld be included in the CSA, and shuld ensure that the prvider will cnduct business in cmpliance with applicable laws n data privacy prtectin. This includes identifying the data sets gathered, data retentin plicies, hw the data is cmmunicated, hw persnal data is stred and used, etc. Data privacy in a clud cntext is nt just abut the prtectin f the infrmatin abut the custmer s agents in its dealing with the prvider (this is the narrw meaning in many existing Service Level Agreements), it als includes the privacy f the infrmatin that may be stred abut the custmer s wn custmers. Refer t the Privacy sectin within Step 5 fr mre infrmatin. Data Availability Assess whether the prvider s maintenance schedules might interfere with business prcesses subject t external cnstraints, such as financial reprting r the business s hurs f peratin in certain regins. Change management and ntificatin The change management and change ntificatin bligatins f the prvider shuld be carefully reviewed, especially the amunt f time allwed t prepare fr a change. The prvider may als ask the custmer t prvide certain change ntificatins, which is a gd pprtunity t strengthen the custmer s wn change management plicies. Cpyright 2015 Clud Standards Custmer Cuncil Page 10

11 In additin t data plicies, there are a number f ther business level plicies expressed in the CSA that require careful evaluatin. Uptime and availability are anther area where custmer requirements and plicies may nt match up with the language f the vendr, and where lcatin and jurisdictin may cme int play. Fr example, if the uptime guarantee is fr regular business hurs, then rganizatins with multiple lcatins in different time znes need t clarify whether the guarantee cvers nly the headquarters lcatin r all regins. Similarly, week-ends r hlidays have different meanings in different cuntries. Fr sme multinatinal custmers with ffices in all cntinents, the sun literally never sets n their empire, and the prvider may nt be ready t cmmit t supprting them 24x365. All f these plicies will impact and influence the custmer s clud strategy and business case. In many cases, these plicies, as defined in the CSA, are nn-negtiable and are similar acrss different clud prviders. Hwever, there will be instances where sme f these plicies can be negtiated and/r sme f these plicies differ sufficiently acrss different clud prviders t warrant careful cnsideratin frm custmers. 2 Table 2 belw highlights the critical business level plicies that need t be cnsidered and addressed in the CSA. Table 2. CSA Business Level Plicies Plicy Descriptin / Guidance Guarantees CSA guarantees shuld be defined, bjective and measurable with an apprpriately scaled penalty matrix that matches the impact f nn-perfrmance by the prvider. 3 The CSA shuld clarify: What cnstitutes excused r excluded perfrmance Escalatin prcedures Hw service-level bnuses and penalties are administered Remedy circumstances and mechanisms Guarantees shuld be expressed as a measurable number, fr example a percentage such as % fr service availabliity, denting the amunt f time the service is guaranteed t be wrking. Other guarantees will refer t matrics in ther units, such as time-t-repair in minutes, etc. Availability measures need t include the measurement windw. 2 Refer t the already cited Public Clud Service Agreements: What t Expect and What t Negtiate. [1] 3 Guarantees including measurable metrics will be cvered in greater detail in the sectins that fllw. Cpyright 2015 Clud Standards Custmer Cuncil Page 11

12 Plicy Descriptin / Guidance Acceptable Use Plicy List f Services Nt Cvered The acceptable use plicy will clearly describe hw the custmer may use the service and the agreement generally will describe what actins the prvider may take in the event f a breach. In tday s clud envirnment, this plicy is typically nn-negtiable and the terms generally favr the clud prvider. Custmers need t understand the impact f such plicies if they use the clud slutin t in turn prvide a service t end users ver whm they have limited cntrl, The CSA will state under what cnditins and with which described services the custmer is supprted. The CSA may als state what is excluded and what cnstitutes illegal use. Custmers shuld lk fr explicitly stated exceptins and understand why the prvider has excluded them. Excess Usage Prviders perate business mdels t drive revenue. While elasticity is a fundamental benefit f using the clud, custmers may find that usage abve their cntracted threshlds will incur high incremental rates which can be punitive and disrupt their budgets. Custmers shuld crrectly size their usage requirements, reduce the pprtunity fr usage creep and cnsider and understand the what-ifs f exceeding their usage threshlds. Activatin The time at which the service becmes active must be defined precisely, in rder t prvide a reference starting pint fr the measurement f perfrmance. This is imprtant t measure certain metrics that are assciated with a specific time windw (e.g., number f utages per 30-day perid). It impacts whether an event triggers a penalty clause. Payment and penalty mdels Gvernance / Versining Frm a CSA cmpliance perspective, it is imprtant fr custmers t understand the trigger pints under the CSA s they can independently measure event timing. The CSA shuld clarify when/hw payment is t be made. Prvider payment mdels vary. Mnthly recurring r pay as yu use mdels are typical. There may be credit terms that require advanced payment r payment every 30 days. Just in time service prviders are sensitive t pr credit cntrl and are likely t be mre diligent in suspending service. Equally, the custmer needs t be diligent in btaining service credit payments fr utages. Prvider services evlve. New features may be added, thers will g ut f warranty, and sme may persist indefinitely. Where the assumptins r cnditins under which the CSA was initially accepted are changed, the custmer shuld review the impact n their specific situatin. A gd prvider will maintain a practive plicy f advising custmers f changes t their CSA and practice versin cntrl. Custmers shuld ensure that there is a mechanism t infrm them f changes and, if nt, amend their cntract t put the nus n the prvider t prvide reasnable advance ntice f updates. Cpyright 2015 Clud Standards Custmer Cuncil Page 12

13 Plicy Descriptin / Guidance Renewals Renewals are an pprtunity t bargain fr better rates r services levels, r relcate t anther prvider if necessary. Prviders may write in their cntracts an autmatic renewal clause that kick in in the absence f a 90-day cancellatin ntice befre the cntract s anniversary date. It is cmmn fr custmers t verlk this deadline and be bligated t renew the cntract withut having had a chance t negtiate changes r even cancel the service. Custmers shuld read the terms and cnditins f the renewal arrangements, and cnsider the cnditins under which a prvider may vary the service terms (r revise prices) upn renewal. Transferability Custmers shuld cnsider the ptential need t transfer an agreement in the event their business is sld. Cnversely, if the prvider s business is acquired, the custmer may nt wish t s business with the new wner, and shuld have the ptin t migrate t a new service withut penalties. Custmers may perate several accunts with a prvider and want t ffset accunt credits between accunts. Is this supprted in the prvider s cntract terms? Supprt Custmers must fllw the prvider s rules t reprt prblems, in rder t ensure that the supprt terms specified in the CSA are activated, and that the clck starts ticking fr apprpriate escalatin and penalties. An example f a supprt and escalatin matrix related t service availability is prvided belw. All fur target times in the table are assciated with the cmmencement time stamp f the service r the ntificatin f a service affecting event. Pririty Descriptin Target Respnse Time P1 P2 Prductin sftware unusable/prductin clud servers inaccessible Partial sftware functinality unusable/partial service unavailable 1 hur, Prvider s executive ntified f issue P3 Csmetic issue 1 wrking day P4 Infrmatin request 2 wrking days Target Update Time 1hr Target Fix Time Immediate - wrk cmmences and cntinues until issue reslved r wrkarund deplyed 4 hurs 1day 2 days, subject t available maintenance slt 1 wrking day 2 wrking days Next sftware release/service update n/a Cpyright 2015 Clud Standards Custmer Cuncil Page 13

14 Plicy Planned Maintenance Subcntracted Services Descriptin / Guidance All systems require maintenance. Cmplex systems may be designed t include sufficient redundancy s that maintenances can be carried ut withut affecting the service. The CSA may, hwever, describe uptime as an availability percentage (e.g %). This is the equivalent f 8.5 hurs dwntime per year. CSAs may state that this des nt include planned maintenance. Thus, the prvider may have a service utage fr 8.5 hurs. plus maintenance time, and the custmer is nt entitled t cmpensatin under the CSA. This highlights the imprtance f defining the measurement windw. If the availability percentage is measured each mnth, this allws 12 utages nut each f them cannt last mre than 42 minutes withut triggering a penalty. Prviders smetimes include in their CSA a clause that the CSA f an upstream (subcntracted) prvider will gvern the services prvided by the sibcntract, and that the nly available penalties are thse frm the upstream prvider even thugh its CSA may be less rigrus. The custmer s expectatin, based n reviewing the CSA f their immediate prvider, may thus be vilated. Therefre, the custmer shuld ensure that the immediate prvider CSA states unambiguusly that its CSA applies t the cmplete service, regardles whether parts f the service cme frm third parties. Licensed Sftware Clud services may include third party licensed sftware which is sld n a mnthly licensed basis under a service prvider license agreement. Such sftware is updated regularly by its manufacturer. Industry Specific Standards Additinal terms fr different gegraphic regin r cuntries Prviders may pt t pass the respnsibility fr updating the licensed sftware ver t the custmer nce they have started t use the service. This abslves the prvider f the risk f disrupting the custmer s peratin thrugh an unfreseen sftware cnflict r bug. Alternately, the prvider may push the update, in which case the CSA shuld require that the custmer be given advance ntice f the update. The custmer shuld have the ability t pt ut, r at least t defer the update. Hwever, the supplier may be unwilling t cntinue t supprt lder versins indefinitely, and there shuld be a legitimate exceptin fr updates that crrect serius security vulnerabilities. Regulated industries, like gvernment, financial services, and healthcare, are subject t specific and ften quite nerus standards which must be addressed in the CSA and implementatin. Custmers wh perate in these regulated industries shuld ensure that the their legal team is fully invlved n the negtiatin f the CSA. Custmers shuld cnsider the prvider s rigins and primary market. Detailed refinements t the hme market CSA may be required t prperly cver custmers wh are lcated in remte markets. Data prtectin legislatin is ne aspect f this, but custmers shuld nt limit their examinatin f the agreement t this sle aspect. Cpyright 2015 Clud Standards Custmer Cuncil Page 14

15 Step 3: Understand Service and Deplyment Mdel Differences Services ffered by clud prviders typically fall int ne f the three majr service mdels: Infrastructure as a Service (IaaS), Platfrm as a Service (PaaS), r Sftware as a Service (SaaS). Each categry presents significant differences in the levels f clud resurce abstractin, service level bjectives, and key perfrmance indicatrs that may be addressed in a CSA. In additin, the level f clarity varies significantly acrss service mdels. Effective CSAs shuld state specific cmpnents in measurable terms, including: The service t be perfrmed and utcme expectatins Key Perfrmance Indicatrs (KPIs) and the level f service that is acceptable fr each The manner in which service is t be measured The parties invlved and their respnsibilities The reprting guidelines and requirements Incentives fr the service prvider t meet the agreed target levels f quality The CSA is ften the best indicatr f hw, and hw ften, the prvider expects their service t fail. In the end, custmers must remember that dwntime, pr perfrmance, security breaches and data lsses are their wn business risks. Table 3 highlights the different CSA cnsideratins fr each f the clud service mdels. In additin t service mdels, service deplyment terms shuld be included in a CSA. These terms shuld clarify the infrmatin required t verify the crrectness f deplyment actins. Specifically, these terms shuld identify: The deplyment mdel (Private, Cmmunity, Public r Hybrid clud) The deplyment technlgies adpted Custmers must understand the characteristics and differences between these deplyment mdels, since thw ptential value and risk varies significantly. Refer t the Practical Guide t Clud Cmputing [2] fr the selectin f a deplyment mdel. Table 4 highlights the different CSA cnsideratins acrss the deplyment mdels. 4 4 The Cmmunity deplyment mdel is nt called ut explicitly in the table since it is very similar t the Public deplyment mdel. Cpyright 2015 Clud Standards Custmer Cuncil Page 15

16 Table 3. CSA Cnsideratins acrss Service Mdels Service Mdel CSA Cnsideratins IaaS IaaS CSAs are similar t SLAs fr netwrk services, hsting, and data center utsurcing. The main issues cncern the mapping f high level applicatin requirements t infrastructure services levels. Metrics are well understd acrss the IaaS abstractins (cmpute, netwrk, and strage). Custmers shuld expect t find sme f the fllwing metrics in their clud SLA: Cmpute metrics: availability, utage length, server rebt time Netwrk metrics: availability, packet lss, bandwidth, latency, mean/max jitter Strage metrics: availability, input/utput per secnd, max restre time, prcessing time, latency with internal cmpute resurce Cmpute metrics d nt usually include specific cmputing perfrmance. Custmers are simply guaranteed availability f the cmpute resurces fr which they pay. Custmers must distinguish between IaaS develpment envirnments and IaaS prductin envirnments when reviewing their IaaS CSAs. Prductin envirnments shuld have mre stringent service level bjectives than develpment envirnments. Netwrk metrics in a clud SLA generally cver the clud prvider's data center cnnectivity t the Internet as a whle, nt t any specific prvider r custmer. End-tend netwrk service levels may require a cmbinatin f separate agreements between the prvider, the carrier, and the custmer. Custmers shuld ask their clud prviders t cmmit t supprting pen standard interfaces, frmats and prtcls t increase interperability and prtability. 5 PaaS Tw main appraches exist fr building PaaS slutins: integrated slutins and deplybased slutins. When reviewing the PaaS service agreement, custmers shuld cnsider tradeffs in flexibility, cntrl, and ease f use t determine which apprach best meets their business needs. Integrated slutins are web-accessible develpment envirnments that enable develpers t build an applicatin using the infrastructure and middleware services supprted by the clud prvider. Management f the applicatin and its executin is primarily cntrlled by the clud prvider. Typically, service develpers nly have access t a prvider-defined set f APIs, which ffer limited cntrl n the crdinatin f cde executin. 5 There are several standardizatin effrts within the IaaS space which help describe and manage the services ffered: DMTF CIMI (Clud Infrastructure Management Interface), DMTF OVF (Open Virtualizatin Frmat), SNIA CDMI (Clud Data Management Interface), The Open Grup s SOCCI (Service-Oriented Clud-Cmputing Infrastructure), OGF OCCI (Open Clud Cmputing Interface), and ISO JTC1/SC 38 Wrking Grup 3 n Clud Cmputing. Open-surce IaaS fferings are having a prfund impact n the market and shuld be cnsidered (OpenStack in particular). Cpyright 2015 Clud Standards Custmer Cuncil Page 16

17 Service Mdel CSA Cnsideratins Deply-based slutins enable deplyment f middleware n tp f resurces acquired frm an IaaS clud prvider, ffering t custmers deplyment services that autmate the prcess f installing and cnfiguring the middleware. 6 These PaaS slutins ffer a rich set f management capabilities, including the ability t autmatically change the number f machines assigned t an applicatin, and selfscaling accrding t the applicatin s usage. At a minimum, PaaS SLAs shuld inherit IaaS SLAs fr the the underlying infrastructure. Custmers must distinguish between PaaS develpment envirnments and PaaS prductin envirnments when reviewing their PaaS CSAs. Prductin envirnments shuld have mre stringent service level bjectives than develpment envirnments. Standards are emerging t identify, prvisin and manager PaaS services ffered by clud prviders. Standards like OASIS Tplgy and Orchestratin Specificatin fr Clud Applicatins (TOSCA) 7 address prtability and interperability acrss prviders. In additin, PaaS pen surce fferings such as Clud Fundry and OpenShift are starting t build mmentum in the market. Custmers shuld ensure their CSA includes supprt fr such pen standards, as they becme available, t reduce vendr lck-in. SaaS Custmers shuld insist n flexible CSAs that are measurable against their bjectives, nt the clud prviders reprting needs. Given the wide variatin f services prvided at the SaaS level, it is difficult t prvide a cmprehensive and representative list f SaaS service level bjectives fr custmers t require in their CSAs. These bjectives will be largely applicatin-specific. This being said, ustmers shuld expect general SaaS service level bjectives like mnthly cumulative applicatin dwntime, applicatin respnse time, persistence f custmer infrmatin, and autmatic scalability t be included in their CSA. Custmers shuld ensure that data maintained n the prvider s clud resurces is stred using standard frmats t ensure data prtability in the event that a mve t a different prvider is required. 6 Deply-based slutins are supprted by cmmercial prviders such as IBM, Oracle and Micrsft as well as gvernment-spnsred prjects like OPTIMIS, CONTRAIL, Clud4SOA and mosaic in Eurpe. 7 See fr details n TOSCA. Cpyright 2015 Clud Standards Custmer Cuncil Page 17

18 Table 4. CSA Cnsideratins Acrss Deplyment Mdels Deplyment Mdel CSA Cnsideratins Private (On-site) CSA cnsideratins fr a Private (On-site) clud are similar t thse f a traditinal enterprise data center SLA. Hwever, given that data center resurces may be shared by a larger number f internal users, custmers must ensure that critical service bjectives like availability and respnse time are met via nging measurement and tracking. In effect, identifying the shared resurces as a private clud frce the IT rganizatin t cntract with its internal users in the same way an external vendr wuld. Private (Outsurced) CSA cnsideratins fr Private (Outsurced) are similar t Private (On-site) except thst clud services are nw being prvided by an external prvider. The fact that IT resurces frm the prvider are dedicated t a single custmer mitigates the ptential security and availability risks. Custmers shuld cnsider whether the criticality f the service being deplyed justifies the added expense f this mdel ver the Public mdel (due t lwer ecnmies f scale). Custmers shuld ensure the CSA specifies security techniques fr prtecting the custmer's perimeter and the cmmunicatins link with the prvider. Public A CSA fr a Public mdel must include strnger requirements than the Private (Outsurced) mdel since the prvider s IT resurces are nw shared acrss multiple custmers. Specifically, the prvider must address the added security, availability, reliability and perfrmance risks intrduced by multi-tenancy. The ability t measure and track specific service level bjectives becmes mre imprtant in the Public deplyment mdel. Hybrid CSA cnsideratins fr the Hybrid mdel are similar t the Public mdel, with the increased likelihd f unique service and data integratin requirements between clud and enterprise services (e.g., s that external clud can be used seamlessly t handle an verflw f demand beynd the capacity f the internal clud). A specific dcument shuld describe the private/public interface, alng with quality metrics, perfrmance characteristics and security requirements assciated with the interface. Fr example, if the interface is a web service, there may be authenticatin and authrizatin requirements with implicatins n an LDAP directry architecture. Cpyright 2015 Clud Standards Custmer Cuncil Page 18

19 In additin t specifying the deplyment mdel, the CSA shuld clarify hw a service is made available t service users by a given clud prvider. Fr example: A web applicatin is deplyed n an applicatin server as a Web applicatin ARchive (WAR). 8 A grid applicatin is deplyed n a grid cntainer as a Grid ARchive (GAR) file. A virtual machine is deplyed n an IaaS prvider as a virtual machine disk image that may be represented in ne f many different frmats. Adptin and supprt fr standards like the Distributed Management Task Frce (DMTF) Open Virtualizatin Frmat 9 (OVF) is recmmended. CSAs shuld specify the technlgies invlved in the deplyment f services. Nte that there is a clse relatinship between deplyment technlgies and the kind f services being ffered. Step 4: Identify Critical Perfrmance Objectives Perfrmance gals within the cntext f clud cmputing are directly related t the efficiency and accuracy f service delivery by the clud prvider. Typical perfrmance cnsideratins include availability, respnse time and prcessing speed, but they can include many ther perfrmance and system quality perspectives. 10 The relevant perfrmance factrs depend n the service mdel (IaaS, PaaS r SaaS) and the type f services prvided within that mdel (fr example, netwrk, strage and cmputing services fr IaaS). Clud custmers must decide which perfrmance bjectives are mst critical t their specific requirements, ensure the bjectives are measureable and auditable, and make sure these measures are included in the SLA in rder t supprt ratinal discussins between the parties. It must be clear hw each metric will be used t make decisins t align service perfrmance t specific gals and bjectives. This sectin fcuses n tw perfrmance metrics: availability and respnse time. The intentin is t prvide a basic framewrk t identify and define meaningful and cnsistent clud metrics. This framewrk can then be applied t ther ptential metrics nt cvered in this dcument. While many f the metrics may already be supprted by yur clud prvider, they may interpret the definitin differently than the custmer des. An agreed definitin in the cntext f a specific clud slutin is critical. Sme calibratin may be required if a measurement captured by a prvider des nt exactly match the definitin in the SLA. 8 See fr mre infrmatin n the WAR (Web applicatin ARchive) file. 9 See fr mre details. 10 Additinal system quality measures that culd be included in service perfrmance include accuracy, prtability, interperability, standards cmpliance, reliability, scalability, agility, fault tlerance, serviceability, usability, durability, and mre. Cpyright 2015 Clud Standards Custmer Cuncil Page 19

20 Industry standards shuld be used when pssible t achieve cnsistency. Fr instance, IEEE has gd measurement definitins and categrizatins fr activities such as maintenance. 11 Here are the generally accepted definitins fr the tw metrics f interest: Availability. Percentage f uptime fr a service in a given bservatin perid. Respnse time. Elapsed time frm when a service is invked t when it is cmpleted (typically measured in millisecnds). Table 5 describes three example scenaris (netwrk availability, strage availability, and service respnse time) and the specific perfrmance infrmatin required fr each. Bth hardware and facilities shuld be cnsidered when assessing critical perfrmance levels in an IaaS cntext. Hardware includes: cmputers (CPU and memry), netwrks (ruters, firewalls, switches, netwrk links and interfaces), strage cmpnents (hard drives, strage area netwrk cntrllers), and any ther physical cmputing infrastructure elements. Facilities include: heating, ventilatin and air cnditining (HVAC), pwer cnsumptin and dissipatin, cmmunicatins, backup, and ther aspects f the physical plant. In the case f PaaS r SaaS slutins, it can be presumed that the unavailability r sub-par perfrmance f any f these cmpnents will affect the verall services, therefre it is nt necessary t specify them the measurements shuld be end t end expressed in terms f the user experience. Mrever, particularly in the IaaS case, higher level business bjectives may dictate what critical resurces fall within the scpe f the metrics. Fr example, the pwer cnsumptin r the heat dissipatin may r may nt be included, depending whether the custmer has established a crprate carbn ftprint bjective. In summary, when cnsidering perfrmance metrics in a clud SLA, it is recmmended that cnsumers: Understand the business level perfrmance bjectives (fr example, reduce cst and time t market per unit f sftware functinality). Identify the metrics that are critical t achieving and managing the business level perfrmance bjectives. Ensure these metrics are defined at the right level f granularity that can be mnitred n a cntinuus basis (in a cst-effective manner). Identify standards that prvide cnsistency in metric definitins and methds f cllectin. Analyze and leverage the metrics n an nging basis as a tl fr influencing business decisins. 11 Other standard rganizatins wrking n measures relevant t clud services include the Internatinal Functin Pint Users Grup (IFPUG), which frmed a Clud Measurement Interest Grup in Sme f these effrts leverage existing sftware measurement guidelines, such as ISO/IEC 20926, which are used fr benchmarking. IFPUG wrks clsely with the Internatinal Sftware Benchmarking Standards Grup. Cpyright 2015 Clud Standards Custmer Cuncil Page 20

21 Table 5. Availability and Respnse Time Objectives (Examples) Netwrk Availability Strage Availability Service Respnse Time Metric Name in SLA Netwrk Percentage Available (Critical Business Hurs) Strage Percentage Available Service XXX Respnse Time in a Given Hur Service YYY Respnse Time in a Given Hur. Cnstraints Critical time is defined as 12AM GMT t 12PM GMT Mnday thrugh Friday Nne Respnse times will nly be evaluated fr services XXX and YYY, which are PaaS reuseable services that will be invked by ur applicatins. Cllectin Methd Autmated Autmated Autmated Cllectin Descriptin Using DMTF, OGF 12, r ther standard t cnsistently cllect the measures. Using DMTF, OGF, r ther standard t cnsistently cllect the measures. Using DMTF, OGF, r ther standard t cnsistently cllect the measures. Frequency f Cllectin The netwrk is pinged at ne-minute intervals. Specific strage services are randmly exercised (bth read and update) at ne-minute intervals. Fr each XXX and YYY service invked, the respnse time is cllected at five-minute intervals. Other Infrmatin 60 secnds f uptime will be recrded fr each successful ping. 60 secnds f uptime will be recrded fr each successful invcatin. Each service will be reprted separately. Hurly averages will be calculated. Clarificatin N reference t quality r availability f specific service. This is exclusively a measure f netwrk availability. N reference t quality r availability f specific service. This is exclusively a measure f strage availability. N individual service reprting is needed (fr example, listing f all services that exceeded the SLA-agreed respnse time). Usage 1 in SLA Netwrk availability shall be 99.5% r higher during critical time. Strage availability shall be 99.9% r higher. Respnse time fr XXX service shall be less than 500 ms, YYY service less than 200 ms. Usage 2 in SLA Fr any day when netwrk availability is less than 99.5%, a 20% discunt will be applied fr the entire day s netwrk charges. Fr any day when strage availability is less than 99.9%, a 50% discunt will be applied fr the entire day s strage charges. If in any given hur the respnse times as stated are nt met, all services f that type during that hur will be prcessed at n charge. 12 Refer t fr mre infrmatin n the Open Grid Frum. Cpyright 2015 Clud Standards Custmer Cuncil Page 21

22 Step 5: Evaluate Security 13 and Privacy Requirements Security cntrls in clud cmputing are, fr the mst part, n different than security cntrls in any IT envirnment. Hwever, because f the clud service mdels emplyed, the peratinal mdels, and the technlgies used t enable clud services, clud cmputing may present different risks t an rganizatin frm traditinal IT slutins. Refer t the Security fr Clud Cmputing: 10 Steps t Ensure Success [3] whitepaper fr details n security requirements fr clud cmputing. There are tw asset categries that require security and privacy cnsideratin fr clud cmputing: Infrmatin (which belngs t the custmer but has been mved int the prvider s clud) Applicatins, functins r prcesses (being executed In the clud t prvide the required service t the custmer) A required fundatin fr security, regardless f whether a clud slutin is used, is a security classificatin scheme that applies thrughut the enterprise, based n the criticality and sensitivity f enterprise data. This scheme shuld include details abut data wnership, definitin f apprpriate security levels and prtectin cntrls, and data retentin and destructin requirements. The classificatin scheme shuld be used as the basis fr applying access cntrls, archiving, and encryptin methds. In rder t determine which level f security is required fr a specific asset, a rugh assessment f an asset s sensitivity and imprtance is required. Fr each asset, the fllwing questins shuld be asked: Hw wuld the business be harmed if 1. The asset became publicly available and distributed? 2. An emplyee f ur clud prvider accessed the asset? 3. The prcess r functin was manipulated by an utsider? 4. The prcess r functin failed t prvide expected results? 5. The infrmatin was unexpectedly altered? 6. The asset was unavailable fr a perid f time? Table 6 belw highlights the key steps custmers shuld take t ensure their CSA sufficiently addresses their unique security requirements. 13 The security part f this sectin is based n the Clud Security Alliance Security Guidance fr Critical Areas f Fcus in Clud Cmputing, V3.0 and qutes prtins f this dcument. The dcument is available at Cpyright 2015 Clud Standards Custmer Cuncil Page 22