Contributii Privind Auditul Sistemelor Informatice In Arhitecturi de Tip Cloud Computing
TEZĂ DE DOCTORAT
Contribuții privind auditul sistemelor informatice în arhitecturi de tip “Cloud Computing”
Contributions regarding the audit of information systems in “Cloud Computing” architectures
Cuprins
1. INTRODUCERE
1.1 SCOPUL LUCRĂRII
1.2 OPORTUNITATEA ALEGERII TEMEI
1.3 ORGANIZAREA PE CAPITOLE A LUCRĂRII
1.4 “CLOUD COMPUTING” – STADIU ACTUAL
1.5 CONCEPTE ȘI TERMINOLOGIE
ACKNOWLEDGEMENT
CAPITOLUL 2
2. CLOUD COMPUTING
2.1 MODELUL DE REFERINȚĂ AL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
2.1.1 Business Operation Support Services
2.1.2 Information Technology Operation & Support
2.1.3 Servicii de Prezentare
2.1.4 Servicii de Aplicație
2.1.5 Servicii de Informații
2.1.6 Servicii de Infrastructură
2.1.7 Gestiunea Securității și Riscului
2.2 MODELUL DE SECURITATE AL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
2.2.1 Cadrul arhitectural pentru cloud
2.2.2 Guvernanța și gestiunea riscului în medii de tip enterprise
2.3.4 Polemici legale: contracte și vizibilitate asupra mediilor electronice
2.2.5 Gestiunea conformității și auditului
2.2.6 Managementul riscului
2.2.6 Gestiunea informațiilor și a securității datelor
2.2.7 Interoperabilitate și portabilitate
2.2.8 Mecanisme tradiționale de securitate, continuitate în business și recuperarea datelor în caz de dezastru
2.2.9 Operațiuni la nivel de Data Center
2.2.10 Răspunsul în caz de incident
2.2.11 Securitatea Aplicațiilor
2.2.12 Criptarea și gestiunea cheilor de criptare
2.2.13 Gestiunea identităților, rolurilor și accesului în aplicații
2.2.14 Virtualizare
2.3 MODELE DE ARHITECTURI “CLOUD COMPUTING”
2.3.1 Clasificarea furnizorilor în funcție de nivelul serviciilor oferite
2.3.2 Clasificarea furnizorilor în funcție de localizarea spațiului de stocare al datelor
CAPITOLUL 3
3. AUDITUL PROCESULUI DE MIGRARE AL ARHITECTURILOR TRADIȚIONALE LA ARHITECTURI DE TIP “CLOUD COMPUTING”
3.1 DEFINIȚIA AUDITULUI PROCESULUI DE MIGRARE CĂTRE ARHITECTURI DE TIP “CLOUD COMPUTING”
3.1.1 Considerații generale
3.1.2 Etapa premergătoare migrării în cloud
3.1.3 Etapa de definire a strategiei de migrare în cloud
3.1.4 Evaluarea furnizorilor
3.1.5 Implementarea modelului de cloud ales
3.2 ELEMENTE ÎN PROCESUL DE AUDIT
3.3 METODA DE AUDITARE A PROCESULUI DE MIGRARE
3.3.1 Concepte arhitecturale folosite pentru auditarea procesului de migrare către arhitecturi de tip “Cloud Computing”
3.3.2 Evaluarea factorului de impact al migrării către cloud
CAPITOLUL 4
4. INTEGRAREA SISTEMELOR ÎN ARHITECTURI HIBRIDE
4.1 GESTIONAREA IDENTITĂȚILOR ÎN ARHITECTURA HIBRIDĂ
4.1.1 Problematica gestiunii de identități în arhitecturi hibride
4.1.2 Abordare proprie privind gestiunea de identități în arhitecturi hibride
4.2 GESTIONAREA COMUNICAȚIEI DATELOR CONFIDENȚIALE ÎNTRE SISTEMELE DIN INTERIORUL COMPANIEI ȘI CELE DIN EXTERIOR
4.2.1 Algoritmi de criptare
4.2.2 Abordare proprie privind securizarea datelor în arhitecturi hibride
CAPITOLUL 5
5. AUDITUL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
5.1 DEFINIȚIA PROCESULUI DE AUDIT AL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
5.2 FRAMEWORK-URI DE CONTROL PENTRU ARHITECTURI DE TIP CLOUD
5.2.1 ENISA Cloud Risk Assessment
5.2.2 COBIT
5.2.3 Programul de auditare și gestionare a arhitecturilor de tip cloud computing
5.2.4 CSA – Modelul de securitate în cloud
5.3 ELEMENTE ÎN PROCESUL DE AUDIT
5.4 METODE DE AUDITARE A ARHITECTURILOR DE TIP “CLOUD COMPUTING”
5.4.1 Concepte arhitecturale folosite pentru auditarea arhitecturilor de tip “Cloud Computing”
5.4.2 Evaluarea factorului de siguranță al arhitecturilor cloud
5.4.3 Evaluarea factorului de rentabilitate al arhitecturilor cloud
CAPITOLUL 6
6. IMPLEMELENTAREA TEHNICILOR DE AUDIT ÎN PROCESUL DE MIGRARE CĂTRE ARHITECTURI CLOUD
6.1 ARHITECTURA GENERALĂ A PROCESULUI DE MIGRARE
6.2 PROCESUL DE AUDIT
6.3 EVALUAREA IMPACTULUI MIGRĂRII A APLICAȚIILOR CĂTRE ARHITECTURI DE TIP “CLOUD COMPUTING”
6.3.1 Raportul de audit al procesului de migrare
6.4 CONCLUZII
CAPITOLUL 7
7. IMPLEMENTAREA TEHNICILOR DE AUDIT AL ARHITECTURILOR CLOUD
7.1 ARHITECTURA GENERALĂ A PROCESULUI DE AUDIT
7.2 PROCESUL DE AUDITARE
7.3 EVALUAREA FACTORULUI DE SIGURANȚĂ AL APLICAȚIILOR DIN ARHITECTURI DE TIP “CLOUD COMPUTING”
7.3.1 Rezultatele procesului de auditare și analiza acestora
7.4 EVALUAREA FACTORULUI DE RENTABILITATE AL APLICAȚIILOR DIN ARHITECTURI DE TIP “CLOUD COMPUTING”
7.4.1 Rezultatele procesului de auditare și analiza acestora
7.5 CONCLUZII
CONCLUZII
C.1. CONCLUZII GENERALE
C.2. CONTRIBUȚII ORIGINALE
C.3 DISEMINAREA REZULTATELOR
C.4 PERSPECTIVE DE DEZVOLTARE ULTERIOARĂ
9. ANEXE
A.1. ACRONIME
A.2 MECANISME DE SECURITATE ÎN ARHITECTURI CLOUD
A.3 VAL IT
A.4 LISTA DE FIGURI
A.5 LISTA DE TABELE
BIBLIOGRAFIE
Acknowledgement
Mulțumesc…
Mamei mele care a fost, este și va fi întotdeauna un exemplu pentru mine atât din perspectivă profesională cât și personală. Ea este persoana care m-a învățat că dacă îmi doresc ceva pot obține oricât de greu ar părea, m-a învățat să am încredere în mine și să asimilez greșelile ca pe o lecție din care să învăț întotdeauna ceva. Ea și sora mea mi-au demonstrat că ori de câte ori întâmpin vreo greutate, ele sunt alături de mine și au empatizat cu mine în toate emoțiile, stările de tensiune și stres din toate proiectele personale, academice și profesionale pe care le-am întreprins. Ralu și mama m-au înțeles și m-au susținut în fiecare sacrificiu la care au fost parte fără voia lor de cele mai multe ori și pentru asta le mulțumesc.
Bunicii mele care mă încurajează de fiecare dată când ne întâlnim, mă iubește și se gândește mereu la mine și la binele meu. Tot ei trebuie să îi mulțumesc pentru ambiția moștenită fără de care mi-ar fi fost greu să termin multe dintre lucrurile realizate.
Domnului Profesor coordonator care m-a înțeles și m-a susținut pe durata acestor studii doctorale și mi-a oferit întotdeauna sfaturi și observații constructive.
Familiei mele care este întotdeauna alături de mine și are încredere în mine și în reușitele mele: verișori, unchi, mătuși și prieteni.
Și nu în ultimul rând prietenului meu, Marius, care este în fiecare zi lângă mine și mă susține și mă iubește în toate stările mele de spirit.
INTRODUCERE
SCOPUL LUCRĂRII
În această lucrare am urmărit tratarea problematicilor existente în arhitecturile de tip cloud computing [1] prin evaluarea lor într-un mod eficient și relevant. În urma activităților de cercetare mi-am propus realizarea unei analize care, pe baza rezultatelor concrete să permită trasarea strategiilor viitoare de IT [2]. Astfel, plecând de la o imagine structurată și ușor de înțeles asupra arhitecturilor de tip “cloud computing” [3], am analizat circumstanțele în care se poate găsi o companie în raport cu acest model arhitectural. Am conturat astfel trei direcții de analiză:
Analiza migrării către arhitecturi de tip cloud [4]
Analiza arhitecturilor hibride care integrează servicii cloud și sisteme clasice din interiorul companiei [5]
Analiza serviciilor cloud [6]
Fiecare dintre aceste direcții de cercetare oferă foarte multe oportunități de dezvoltare și inovație, atât datorită multitudinii de modele arhitecturale existente, clasificate pe tipuri de aplicații și pe industrii specifice, cât și mulțumită specificului fiecărui flux informațional care manifestă cerințe tehnologice specifice.
Pentru adresarea primului domeniu mi-am propus realizarea unui studiu comparativ între sistemele aparținând arhitecturilor clasice și cele aparținând cloud computing-ului, în urma căruia să pot defini etapele procesului de migrare [7]. Fiecare etapă are caracteristicile ei specifice, acești diferențiatori având factor de impact diferit. Studiul de cercetare în acest domeniu constă în structurarea componentelor ce trebuie supuse analizei. Apoi, pe baza practicilor și principiilor din arhitecturile cloud, trebuie să se definească posibile abordări sau realizări ale componentelor ce au impact diferit asupra riscului manifestat de migrarea către cloud [8]. Odată realizat procesul de audit, acesta trebuie să ofere o imagine reală și concretă atât a factorului de impact cât și al surplusului, sau dimpotrivă, deficitului de siguranță pe care îl manifestă un model cloud față de un model tradițional.
Cea de-a două direcție de cercetare, a supus atenției mele o multitudine de situații și circumstanțe de analizat care se pot clasifica în principal în:
Problematici de comunicare din perspectiva standardelor de interoperabilitate [9]
Problematici privind siguranța datelor în tranzit și în repaus [10]
Problematici privind accesul autorizat la date [11]
Prima dintre ariile menționate mai sus este adresată de multitudinea de organisme de standardizare pentru interoperabilitatea sistemelor informatice. Celelalte două domenii, sunt consecințe secundare ale migrării în cloud care oferă oportunități de eficientizare și dezvoltare multiple. Pentru acestea, plecând de la abordările de integrare din sistemele tradiționale și mecanismele de siguranță existente, am creat două metode practice de sporire a siguranței din două perspective: accesul la date [12] și transportul, procesarea și stocarea lor în siguranță [13].
Cel de-al treilea domeniu studiat a fost cel al auditului soluțiilor de cloud. Acest domeniu este încă la început, așa încât analiza mea s-a bazat pe implementări reale prezentate la conferințe ale comunității cloud. Plecând de la modele arhitecturale consacrate și standardizate pentru companii [14], am adaptat aceste modele specificului cloud astfel încât să conturez o metodologie eficientă de auditare a serviciilor cloud. Procesul de audit propus se bazează pe model de evaluare propus de ISACA, în COBIT [15], care analizează gradul de guvernanță [16] al companiei în funcție de gradul de implementare al mecanismelor de securitate existente în cloud. Pentru realizarea setului de mecanisme de control, am plecat de la standardul de securitate oferit de CSA [17] pentru clasificarea aspectelor auditate în domenii de securitate. Pentru fiecare domeniu, am concretizat principalele metode și concepte de securitate ce reflectă gradul de siguranță al serviciului cloud. Apoi, prin încercări repetate am conturat o metodologie de calcul a factorului de siguranță plecând atât de la experiența proprie cât și de la statistici realizate la nivel mondial asupra implementărilor cloud.
Studiind toate cele trei domenii prezentate: cel al migrării unui sistem clasic în arhitecturi cloud, cel al adresării siguranței datelor din mai multe perspective în comunicația în arhitecturi hibride și cel de audit al serviciului cloud, am realizat o prezentare structurată asupra lor și mi-am adus contribuția în metodologia de definire a proceselor de audit și de analiză a rezultatelor obținute.
Scopul lucrării mele constă în oferirea unei abordări eficiente de răspuns la întrebări practice survenite odată cu dezvoltarea tehnologică și apariția nevoii de agilitate la nivel IT:
Când decide o companiei să migreze către arhitecturi de tip cloud?
Ce se întâmplă cu siguranța datelor odată ce una din aplicații este migrată în cloud?
Care este gradul de guvernare, gestiune și operare al cloud-ului?
La toate acestea am oferit soluții materializate în mecanisme eficiente de evaluare a oportunității de migrare, am creat abordări eficiente pentru securizarea datelor, am realizat metodologii de realizare a proceselor de audit și framework-uri de calcul ai unor factori tehnici și economici privind arhitecturile cloud.
OPORTUNITATEA ALEGERII TEMEI
Alegerea subiectului acestei teze de doctorat a survenit în urma curiozității specifice unei absolvente a facultății de “Automatică și Calculatoare” și a programului de masterat “Managementul și Protecția Informației”, devenită apoi consultant în securitatea informației de a afla cât mai multe lucruri noi în domeniul IT pentru a-și putea aduce contribuția în opui fiecărui flux informațional care manifestă cerințe tehnologice specifice.
Pentru adresarea primului domeniu mi-am propus realizarea unui studiu comparativ între sistemele aparținând arhitecturilor clasice și cele aparținând cloud computing-ului, în urma căruia să pot defini etapele procesului de migrare [7]. Fiecare etapă are caracteristicile ei specifice, acești diferențiatori având factor de impact diferit. Studiul de cercetare în acest domeniu constă în structurarea componentelor ce trebuie supuse analizei. Apoi, pe baza practicilor și principiilor din arhitecturile cloud, trebuie să se definească posibile abordări sau realizări ale componentelor ce au impact diferit asupra riscului manifestat de migrarea către cloud [8]. Odată realizat procesul de audit, acesta trebuie să ofere o imagine reală și concretă atât a factorului de impact cât și al surplusului, sau dimpotrivă, deficitului de siguranță pe care îl manifestă un model cloud față de un model tradițional.
Cea de-a două direcție de cercetare, a supus atenției mele o multitudine de situații și circumstanțe de analizat care se pot clasifica în principal în:
Problematici de comunicare din perspectiva standardelor de interoperabilitate [9]
Problematici privind siguranța datelor în tranzit și în repaus [10]
Problematici privind accesul autorizat la date [11]
Prima dintre ariile menționate mai sus este adresată de multitudinea de organisme de standardizare pentru interoperabilitatea sistemelor informatice. Celelalte două domenii, sunt consecințe secundare ale migrării în cloud care oferă oportunități de eficientizare și dezvoltare multiple. Pentru acestea, plecând de la abordările de integrare din sistemele tradiționale și mecanismele de siguranță existente, am creat două metode practice de sporire a siguranței din două perspective: accesul la date [12] și transportul, procesarea și stocarea lor în siguranță [13].
Cel de-al treilea domeniu studiat a fost cel al auditului soluțiilor de cloud. Acest domeniu este încă la început, așa încât analiza mea s-a bazat pe implementări reale prezentate la conferințe ale comunității cloud. Plecând de la modele arhitecturale consacrate și standardizate pentru companii [14], am adaptat aceste modele specificului cloud astfel încât să conturez o metodologie eficientă de auditare a serviciilor cloud. Procesul de audit propus se bazează pe model de evaluare propus de ISACA, în COBIT [15], care analizează gradul de guvernanță [16] al companiei în funcție de gradul de implementare al mecanismelor de securitate existente în cloud. Pentru realizarea setului de mecanisme de control, am plecat de la standardul de securitate oferit de CSA [17] pentru clasificarea aspectelor auditate în domenii de securitate. Pentru fiecare domeniu, am concretizat principalele metode și concepte de securitate ce reflectă gradul de siguranță al serviciului cloud. Apoi, prin încercări repetate am conturat o metodologie de calcul a factorului de siguranță plecând atât de la experiența proprie cât și de la statistici realizate la nivel mondial asupra implementărilor cloud.
Studiind toate cele trei domenii prezentate: cel al migrării unui sistem clasic în arhitecturi cloud, cel al adresării siguranței datelor din mai multe perspective în comunicația în arhitecturi hibride și cel de audit al serviciului cloud, am realizat o prezentare structurată asupra lor și mi-am adus contribuția în metodologia de definire a proceselor de audit și de analiză a rezultatelor obținute.
Scopul lucrării mele constă în oferirea unei abordări eficiente de răspuns la întrebări practice survenite odată cu dezvoltarea tehnologică și apariția nevoii de agilitate la nivel IT:
Când decide o companiei să migreze către arhitecturi de tip cloud?
Ce se întâmplă cu siguranța datelor odată ce una din aplicații este migrată în cloud?
Care este gradul de guvernare, gestiune și operare al cloud-ului?
La toate acestea am oferit soluții materializate în mecanisme eficiente de evaluare a oportunității de migrare, am creat abordări eficiente pentru securizarea datelor, am realizat metodologii de realizare a proceselor de audit și framework-uri de calcul ai unor factori tehnici și economici privind arhitecturile cloud.
OPORTUNITATEA ALEGERII TEMEI
Alegerea subiectului acestei teze de doctorat a survenit în urma curiozității specifice unei absolvente a facultății de “Automatică și Calculatoare” și a programului de masterat “Managementul și Protecția Informației”, devenită apoi consultant în securitatea informației de a afla cât mai multe lucruri noi în domeniul IT pentru a-și putea aduce contribuția în optimizarea proceselor computerizate existente, nu din perspectivă performanțe, ci din perspectivă fiabilitate și siguranță în funcționare.
Cariera mea profesională a debutat în dezvoltarea software în domeniul telecomunicațiilor. A urmat apoi activarea în domeniul securității informațiilor pe parcursul căreia am integrat soluții de securitate de la diferiți furnizori care adresează zone specifice de securitate – de la securizarea datelor în tranziție și în repaus până la gestiunea și controlul accesului la date la nivel de aplicație. Pe tot parcursul experienței mele profesionale am înțeles că, atât în mediul de afaceri cât și în cel personal cel mai important factor decizional este încrederea, exprimată atât prin încrederea manifestată de către client în furnizorul de servicii și de produse cât și prin încrederea pe care o au partenerii de afaceri unii în alții. Când discutăm despre încrederea manifestată în legătură cu domeniul IT, ne referim la două aspecte principale:
Încrederea în performanțele unui sistem care se traduce prin îndeplinirea SLA-urilor definite pentru acel sistem astfel încât scopul căruia îi deservește să fie atins
Încrederea în siguranța unui sistem care se traduce în gradul de auditare al acelui sistem și în securitatea datelor stocate de aplicația respectivă
Performanțele sistemice sunt obținute prin balansarea optimă între resursele hardware și configurațiile software care este adresată:
La nivel de infrastructură prin componente specifice de balansare a încărcării pe dispozitive și alte echipamente similare
La nivel de aplicație prin configurarea parametrilor de rulare a diferitelor procese ale aplicației, în funcție de resursele fizice ale mașinii pe care aplicația rulează.
În ceea ce pricește siguranța datelor și gradul de auditare ale unui sistem informatic, acestea se reflectă în măsurile de protecție și control al accesului la informațiile stocate, pe care aplicația le implementează, dar și la mecanismele de auditare ale acestor măsuri în vederea demonstrării conformității cu reglementările juridice și standardele aplicabile. Această preocupare devine din ce în ce mai accentuată datorită trendului prezent în domeniul IT de a se decupla hardware-ul de software, de a eficientiza puterea de calcul prin alocare și de-alocare la cerere de resurse, toate acestea minimizând costurile de întreținere și suport pentru echipamentele IT. Interesul meu pentru acest domeniu a survenit ca urmare a noilor provocări cauzate de schimbările din domeniul tehnologiei, provocări materializate într-o serie de întrebări la care companiile din ziua de azi trebuie să răspundă când conturează propria strategie de dezvoltare în domeniul IT:
Dacă sunt o companie nouă pe piață, este mai profitabil să investesc în infrastructură hardware sau să optez pentru un furnizor de cloud?
Este o infrastructură hardware profitabilă pe termen lung sau doar evită investiții inițiale mari și, după o perioadă de timp, devine mai costisitoare decât dacă ar exista infrastructură proprie?
Este profitabil să migrez infrastructura existentă către arhitecturi de tip cloud?
Aplicațiile în cloud pot stoca și date confidențiale care trebuie să respecte standarde de securitate impuse de reglementările juridice?
Cine răspunde pentru pierderea datelor din cloud?
Unde se află fizic datele aplicației mele? Respectă legislația de stocare și măsuri de siguranță aplicabilă în țara în care eu îmi desfășor activitatea?
Cum pot controla furnizorul de cloud să nu îmi acceseze datele?
Ce garanție am că datele mele stocate în cloud nu sunt accesate, vândute, oferite competitorilor mei care sunt clienți ai aceluiași furnizor cloud?
Odată ales furnizorul cloud, pot să îl schimb? Există interoperabilitate între diferiți furnizori?
Pot să contractez mai mulți furnizori de cloud pentru aplicații diferite și să am garanția unei comunicații sigure între ei?
La toate aceste întrebări, dar și la multe altele care survin pe măsură ce încerc să răspund la acestea, am încercat de-a lungul cercetării mele, să găsesc răspuns și metode de a evalua cât mai corect atât gradul de expunere al companiilor la atacuri informatice atunci când migrează către arhitecturi cloud, cât și factorul de impact pe care migrarea unei aplicații din interiorul companiei la arhitecturi cloud îl manifestă.
Cercetarea mea a început cu standardele aplicabile domeniului cloud din perspectiva securității informațiilor [18] [19] pe care am încercat apoi să le concretizez în formulare relevante diferitelor procese de audit. Am împărțit procesele de audit care făceau subiectul cercetării mele în două categorii:
Procese de evaluare impactului migrării unei aplicații existente în infrastructura companiei către arhitecturi de tip cloud. Pentru acest proces am studiat principalele domenii care trebuie vizate de o astfel de analiză și am realizat formularele de întrebări pe baza cărora am compus un algoritm de evaluare a impactului și al gradului de potrivire al aplicației analizate cu tipurile de servicii oferite de cei mai cunoscuți furnizori de cloud.
Procese de evaluare a gradului de siguranță și a celui de rentabilitate al unei aplicații migrate în cloud. Pentru a implementa acest proces, am plecat de la standardele de securitate oferite de CSA [17] și am realizat un formular de auditare al acestor standarde. Pe baza aspectelor privind securitatea, dar și pe baza altor caracteristici legate de mentenanța, suportul și găzduirea aplicațiilor am calculat factorul de siguranță și pe cel de rentabilitate.
Am realizat câte o implementare pentru fiecare proces în parte, în urma cărora am putut să validez abordările pe care le-am realizat.
ORGANIZAREA PE CAPITOLE A LUCRĂRII
Lucrarea de doctorat este structurată pe opt capitole, fiecare dintre ele prezentând procesele și conceptele care au condus la construirea unei abordări proprii privind auditul în arhitecturile de tip cloud computing.
Capitolul I reprezintă introducerea lucrării de doctorat care are menirea de a oferi o imagine de ansamblu a tezei, prin justificarea alegerii acestei tematici și prezentarea contextului în care ea a fost elaborată. Placând de la experiența mea profesională și academică, am explicat de ce mi-am concentrat atenția pe domeniul auditului în cloud computing și care a fost scopul acestui studiu de cercetare. În finalul capitolului de introducere am inclus o secțiune destinată terminologiei și conceptelor utilizate pe parcursul redactării lucrării.
Capitolul II reprezintă o prezentare structurată a arhitecturilor de tip cloud computing și a clasificării lor pe baza mai multor criterii. Capitolul introduce termenul de cloud computing alături de beneficiile și neajunsurile pe care acesta le manifestă, apoi este prezentat modelul de referință în astfel de arhitecturi așa cum este el oferit de CSA. Secțiunea 3 cuprinde modelul de securitate de referință pe care l-am utilizat pe parcursul activității mele de cercetare. Pe baza modelului de referință am prezentat modelele de arhitecturi cloud, clasificate pe criteriul nivelului de servicii folosit și pe cel al localizării spațiului de stocare.
Capitolul III prezintă procesul de audit al migrării arhitecturilor tradiționale către arhitecturi de tip cloud prin punctarea etapelor fundamentale ale acestui proces și a importanței pe care acest proces îl are în clasificarea unui proces de migrare ca fiind un succes sau, din contră, un eșec. Capitolul începe cu definirea procesului de audit pentru astfel de procese, și apoi prezintă caracteristicile fiecărei etape în parte și aspectele care trebuie vizate. Secțiunea 2 prezintă conceptele structurale folosite în abordarea proprie privind auditul. Secțiunea a 3-a a acestui capitol prezintă algoritmul dezvoltat pentru calcularea factorului de impact, plecând de la notațiile și semnificațiilor lor și încheindu-se cu algoritmul de evaluare al impactului propriu-zis.
Capitolul IV prezintă cele două abordări proprii privind protecția datelor partajate în arhitecturi hibride din perspectiva:
Accesului la date – prin propunerea unui model de generare de identități în cloud
Transportului, procesării și stocării datelor – prin propunerea unor mecanisme eficiente de criptare.
Astfel, am început prin a prezenta modele existente pentru soluții de Identity Management în cloud pe baza cărora am elaborat propria abordare. Secțiunea 2 cuprinde o prezentare succintă a principalilor algoritmi de criptare folosiți în protejarea datelor partajate de arhitecturi hibride, urmată de metoda proprie de securizare a informațiilor schimbate de aplicațiile interne și cele din cloud.
Capitolul V prezintă procesul de audit al arhitecturilor de tip cloud prin punctarea elementelor fundamentale ale acestui proces și aspectele pe care el le vizează. Capitolul începe cu definirea procesului de audit prin relatarea principalelor diferențe între auditul arhitecturilor tradiționale și a celor cloud. Secțiunea 2 prezintă principalele framework-uri și concepte care au stat la baza realizării metodologiei proprii de audit al serviciilor cloud. Secțiunea a treia a acestui capitol prezintă elementele specifice ale proces de audit în cloud. Ultima secțiune a acestui capitol structurează procesul de audit în două componente:
Componenta auditării factorului de siguranță
Componenta auditării factorului de rentabilitate
Pentru fiecare dintre aceste componente sunt prezentate conceptele care stau la baza organizării și implementării abordării mele privind auditul serviciilor cloud, precum și metodologiile de realizarea a auditului propriu-zise. Am descris în această secțiune algoritmii propuși de mine în vederea realizării unui proces de audit relevant atât departamentului tehnologic al unei companii cât și business-ului.
Capitolele VI și VII reprezintă implementările realizate pentru validarea metodologiei de audit propusă și descrise în capitolele III și V. Ele vizează, ambele, aplicații din domeniul telecomunicațiilor, și sunt prezentate folosind următoarea structură:
Arhitectura logică a studiului de caz constând în sistemele implicate în studiul de caz și particularitățile lor relevante
Evaluarea factorului specific fiecărui proces de audit
Rezultatele procesului de audit și analizarea acestora
Concluziile tezei de doctorat sunt structurate pe trei secțiuni și adresează concluziile generale privind procesele de audit din arhitecturi de tip cloud – fie că vorbim despre procesul de adopție al acestor arhitecturi, fie că vorbim de procesul de evaluare al acestor modele. A doua secțiune punctează contribuțiile personale aduse în domeniul auditului cu accent pe beneficiile pe care le-am obținut prin depunerea activității de cercetare, iar finalul acestui capitol este destinat prezentării dezvoltărilor viitoare pe care îmi propun să le aduc în această arie de cercetare.
“CLOUD COMPUTING” – STADIU ACTUAL
Cloud computing [20] nu se identifică cu noțiunile de Internet și cel de virtualizarea, ci reprezintă un nou concept arhitectural care, datorită existenței celorlalte două poate oferi un model de utilizare de resurse IT pentru timpul dorit, la performanțele dorite, în care utilizatorul plătește numai cât folosește. Mai mult decât atât, cloud-ul oferă avantajele decuplării platformei, utilizatorul nefiind obligat să instaleze niciun mediu de programare pe stația proprie.
Cloud computing poate însemna atât componentă software cât și hardware. Din perspectivă software, cloud-ul se definește prin sintagma “Software as a Service” și are următoarele caracteristici:
Disponibilitate prin browser web – SaaS nu necesită instalări de software-uri suplimentare, ci se accesează prin browser-ele web folosindu-se open standards sau plug-in-uri specifice care se instalează la accesarea serviciului
Disponibilitate la cerere – odată achiziționat serviciul de cloud, nu trebuie reluat procesul de cumpărare la schimbarea stației de lucru, acest serviciu fiind accesibil de la orice calculator care are conexiune la Internet, folosind credențialele clientului.
Plata licenței de folosire în funcție de utilizarea efectivă a serviciului – SaaS nu necesită nicio investiție în infrastructura proprie, ci doar o taxă de utilizare proporțională cu gradul de folosire al serviciului. Când serviciul nu mai este folosit de către client, taxele nu mai sunt plătite.
Cerințe IT minime – nu există necesitatea existenței unui server sau unei infrastructuri IT pentru a rula SaaS, însă, în funcție de complexitatea serviciului contractat, pot exista cerințe minime de configurare cum ar fi server DNS pentru aplicațiile Google Apps.
Multe dintre aplicațiile SaaS prezintă și caracteristica “multi-tenancy”. Acest lucru se traduce prin reducerea costurilor la nivel de client și prin accesul rapid la noi funcționalități [3].
Conceptul de hardware în cloud este, în general, mai greu de acceptat de către consumatorii de servicii cloud deoarece hardware-ul este asimilat unui lucru palpabil, pe care îl deții, nu îl licențiezi. Din perspectivă cloud, hardware înseamnă folosirea unui spațiu fizic pentru o perioadă limitată de timp și renunțarea apoi la acest dispozitiv, fără a știi unde se află fizic acel server. De aici pot apărea o serie de probleme și polemici în ceea ce privește modelul arhitectural de tip cloud care adresează provocări în domeniul localizării datelor, riscul și vulnerabilitățile la interceptări de date de către alți clienți care partajează aceleași resurse fizice fără a știi acest lucru, temeri legate de blocarea anumitor date la furnizorul de cloud care dă faliment și care nu implementează standarde de interoperabilitatea cu ceilalți furnizori etc. Pe lângă toate aceste provocări, oferirea de servicii hardware în cloud oferă beneficii evidente materializate în:
Dispariția grijilor privind planificare resurselor hardware în vederea achiziționării unor noi echipamente sau upgradării celor existente
Dispariția grijilor legate de rezolvarea problemelor dispozitivelor hardware
Dispariția grijilor legate de apariția unor dezastre naturale în zona unde este amplasat data center-ul companiei
Dispariția grijilor legate de stocarea și casarea echipamentelor învechite și a celor neutilizate
Dispariția grijilor legate de consumul de energie electrică atât al echipamentelor propriu-zise cât și al sistemelor de asigurare a condițiilor ambientale necesare funcționării optime a dispozitivelor și echipamentelor IT.
Datorită tuturor beneficiilor prezentate mai sus, implementarea arhitecturilor cloud devine din ce în ce mai des întâlnită la companii mari din domeniul telecomunicațiilor, la structuri și organisme guvernamentale, tendința fiind însă de implementare a unor noi soluții în cloud în detrimentul migrării celor existente. În acest fel, companiile văd în oportunitatea oferită de cloud computing și o ocazie de a optimiza procesele de business existente în vederea sporirii flexibilității lor și gradului de adaptare la noile schimbări cerute de natura pieței economice.
Preocupările pentru cloud nu se opresc la companiile dornice să exploateze acest concept din perspectiva consumatorului de servicii, ci s-au conturat, odată cu nașterea fenomenului cloud computing și noi nișe de exploatare privind furnizarea de servicii cloud. În zilele noastre există furnizori giganți de servicii cloud din perspectivă infrastructură și platforme, însă există și întreprinderi mici și mijlocii care s-au specializat pe dezvoltarea aplicațiilor cloud folosind drept infrastructură serviciilor celorlalți furnizori. Pentru toți acești actori, siguranța mediului informatic și încrederea pe care aceasta o poate impune sau din contră slăbi, este un factor esențial în cooperarea eficientă între ei. De aceea există o tendință de mediatizare puternică a tuturor experiențelor legate de cloud computing pentru a se conștientiza toate problemele survenite în experiențele actuale astfel încât să se poată crea o baza de cunoștință comună menită să faciliteze migrarea către aceste tipuri de infrastructuri și să rezolve cele mai des întâlnite probleme. Această mediatizare se realizează prin:
Conferințe la care participă furnizorii principali de cloud în care oferă informații despre gradul de adoptare a cloud-ului în diferite industrii
Prezentări despre noile realizări în domeniul cloud-ului
Prezentări ale unor consumatori de cloud despre experiența proprie cu arhitecturile cloud
Rapoarte privind securitatea cloud publicate pe internet care adresează analize realizate pentru organizații guvernamentale
Cărți electronice publicate de practicanții cloud care adresează acest nou concept din mai multe perspective pentru a oferi o imagine cât mai clară a ceea ce înseamnă cloud-ul de fapt și cum se poate exploata pentru obținerea de rezultate uimitoare
Cursuri și certificări asociate lor în urma promovării unor examene în vederea certificării profesioniștilor în domeniul cloud
Toate aceste preocupări denota amploarea acestui subiect și demonstrează în același timp că vremurile actuale au un puternic caracter schimbător fiind foarte receptive la inovație și la flexibilitate. Din acest motiv consider că fenomenul cloud computing reprezintă viitorul domeniului IT, mutându-se în acest fel accentul de pe implementarea tehnică a unei soluții pe aspecte privind funcționalități de business și facilități oferite clienților.
1.5 CONCEPTE ȘI TERMINOLOGIE
Cloud Computing reprezintă un nou concept arhitectural de gestionare de la distanță al resurselor de procesare și stocare de date. Plecând de la conceptul de virtualizare, cloud-ul oferă scalabilitate, elasticitate, eficiență economică, provizionare dinamică de resurse și performanțe ridicate.
Auditul reprezintă examinarea profesională a unei informații în vederea exprimării unei opinii responsabile și independente prin raportarea la un criteriu (standard, normă).
Procesul de auditare al adopției reprezintă procesul care, pe baza informațiilor existente despre aplicațiile analizate și ținând cont de toate aspectele specifice migrării către cloud, are ca finalitatea formularea unui raport de audit din care să reiasă oportunitatea migrării elementelor țintă către arhitecturi de tip cloud.
Procesul de auditare al arhitecturilor de tip cloud reprezintă procesul care, pe baza informațiilor existente despre aplicațiile analizate și ținând cont de toate aspectele de securitate, are ca finalitatea formularea unui raport de audit din care să reiasă gradul de conformitate al aplicațiilor în raport cu standardele analizate materializat în factorul de rentabilitate al arhitecturii cloud
Procesul de migrare în cloud reprezintă procesul prin care o companie decomisionează sistemele din infrastructura proprie pentru a contracta servicii cloud de găzduire.
Factor de impact reprezintă factorul calculat în procesul de audit al oportunității de migrare către cloud și constă cuantificarea efortului de adopție a cloud-ului.
Factor de siguranță reprezintă factorul calculat în procesul de audit al sistemelor cloud și constă în gradul de implementare al mecanismelor de securitate de către furnizorul și consumatorul de cloud, raportat la nivelul de risc asumat în legătură cu acel serviciu.
Factor de rentabilitate reprezintă factorul calculat în procesul de audit al sistemelor cloud și constă în gradul de maturitate al metodologiei de implementare programului cloud care conține sistemul analizat, în raport cu nivelul de maturitate așteptat.
Factorul de valoare adus de adopția cloud reprezintă cuantificarea surplusului de valoare pe care adopția de arhitecturi cloud îl aduce comparativ cu o arhitectură tradițională, ambele implementând același sistem. Acest factor este calculat în procesul de audit al oportunității de migrare.
Mecanism de securitate reprezintă o procedură, procedeu, control, proces sau metodologie a cărei implementare are drept scop adresarea unui risc de securitate.
ACKNOWLEDGEMENT
Rezultatele prezentate în această teză de doctorat au fost obținute cu sprijinul financiar al Ministerului Muncii, Familiei și Protecției Sociale prin Fondul Social European, Programul Operațional Sectorial Dezvoltarea Resurselor Umane 2007-2013, Contract nr. POSDRU/107/1.5/S/76903.
CAPITOLUL 2
CLOUD COMPUTING
Cloud computing [20] reprezintă un nou concept arhitectural de gestionare de la distanță al resurselor de procesare și stocare de date. Tehnologia s-a dezvoltat atât de mult încât, acum, este suficient să-ți creezi un cont pe Amazon sau Yahoo pentru a putea dezvolta și lansa aplicații în Cloud. Acestea sunt doar două dintre sistemele care sunt dezvoltate în cloud, însă, serviciile care se pot realiza au o varietate largă și pot include aproape orice domeniu de activitate (exemplu: baze de date relaționale, aplicații e-Commerce, aplicații CRM, aplicații ERP etc.). Cloud-ul, ca și concept, își propune eficientizarea utilizării de resurse fizice existente pentru o putere de procesare maximă și o eficacitate sporită semnificativ față de metodele tradiționale de procesare [21]. Acestea se traduc în: virtualizarea în întregime a stațiilor de lucru și a serverelor dedicate serviciilor – fie că sunt ele de procesare fie că sunt de stocare de date, alocarea dinamică a resurselor fizice acestor mașini virtuale în funcție de necesarul fiecăreia la un moment dat, existența unei conexiuni fiabile la Internet care să permită accesarea și procesarea acestor date de la distanță.
Gestiunea informațiilor și securizarea datelor în cloud [22] reprezintă cele mai importante preocupări din acest domeniu întrucât trecerea către astfel de tipuri de servicii impune dezvoltarea de noi strategii de securitate care să lase neafectate elasticitatea, disponibilitatea și integritatea datelor oferite de noua arhitectură logică.
Pe lângă avantajele evidente și semnificative pe care fenomenul ”Cloud Computing” le aduce în sfera IT-ului, există și o serie de temeri care se nasc odată cu apariția conceptului de externalizare a serviciilor privind stocarea și procesarea informațiilor confidențiale și foarte sensibile pentru o companie, care trebuie să respecte reglementările legale aplicabile domeniului de activitate al companiei deținătoare a datelor. Printre acestea se numără:
Temeri privind aspecte din securitatea tradițională [99] – aici trebuie amintite atacuri asupra rețelelor și a stațiilor de lucru/servere care, după părerea multor oameni de specialitatea, vor fi mult mai ușor de făcut odată cu migrarea în cloud întrucât posesorii datelor nu vor mai avea acces fizic la acestea. Acest argument este combătut de furnizorii de cloud prin aceea că, securitatea datelor este mult mai eficientă dacă ea este contractată ca un serviciu de la un terț decât dacă este lăsată la latitudinea posesorului. Acest domeniu a fost dezbătut pe larg în literatură și s-a ajuns la o categorisire a aspectelor privind atacurile în cloud. Acestea trebuie studiate din diferite puncte de vedere și anume: nivelurile de atac asupra mașinilor virtuale, vulnerabilitățile furnizorului de servicii în cloud, fenomenul de phishing în cloud, procesele de autentificare și autorizare în cloud, acțiuni criminale în cloud.
Disponibilitatea [23] – disponibilitatea este un subiect foarte sensibil care trebuie discutat având în vedere indicatorii de performanță obligatorii diferitelor domenii de activitate – indicatori care în unele cazuri sunt mai permisivi, iar în altele, din contră, reprezintă puncte critice. Printre acești factori se numără: timpul de funcționare în parametri optimi ai serverelor – furnizorii de servicii în cloud susțin ca acesta este comparabil cu cel al sistemelor tradiționale. Pe de altă parte consumatorii de servicii cloud susțin că furnizorii nu pot face o prioritizare corectă a aplicațiilor pentru toate companiile întrucât această prioritate diferă de la o companie la alta. Un alt factor de avut în vedere este faptul că furnizorul de servicii cloud este single point of failure – acest lucru este combătut de furnizor prin invocarea interoperabilității între cloud – urile existente [24]. Asigurarea integrității în procesarea datelor este o altă grijă a consumatorilor de servicii în cloud întrucât ei trebuie să se bazeze pe bunăvoința furnizorului.
Controlul asupra datelor unei organizații este translatat unui terț (furnizor de servicii în cloud). Aici se discută de implicații legale privind procesarea datelor confidențiale, probleme privind transparența datelor, aspecte privind procesul de auditare al datelor, aspectele contractuale care trebuie incluse în mod obligatoriu într-un angajament dintre un furnizor de servicii în cloud și clientul său, spionajul între furnizorii de cloud, blocarea datelor în spațiul de stocare al furnizorului de servicii, natura tranzitorie a datelor (acesta cuprinde reglementarea situațiilor în care furnizorul de servicii în cloud subcontractează alt furnizor).
Acestor probleme și griji le-au fost aduse diferite soluții [25] care rezolvă unele dintre ele, însă lasă altele tratate parțial sau chiar ridică alte probleme. Printre aceste soluții se numără: crearea cloud-urilor private – la nivel de companie – care rezolvă controlul asupra datelor, crearea standardelor de securitatea specializate pe serviciile oferite în cloud, realizarea unui proces de auditare care vizează toate nivelurile de securitate stringente companiei etc. Domeniul este însă foarte vast așa încât nu se poate contura o soluție care rezolvă tot – soluția perfectă – ci se poate discuta despre abordări optime, care, în funcție de specificul unei companii rezolvă problemele critice acesteia.
Pentru a putea obține rezultatele scontate – asigurarea mecanismelor eficiente de securizare a datelor și informațiilor în arhitecturi de tip cloud [26] trebuie să analizăm cum își propun furnizorii de astfel de servicii să colaboreze în vederea livrării premiselor de cloud computing. Cele mai importante și atrăgătoare caracteristici ale cloud-ului sunt abilitatea de a scala și de a proviziona în mod dinamic puterea de calcul, obținând astfel o optimizare a costurilor beneficiarilor, precum și abilitatea consumatorilor (utilizatorii finali, organizațiile sau personalul IT) de a consuma aceste resurse în vederea obținerii unor rezultate maxime, fără a se preocupa de gestionare complexității tehnologiei folosite. Arhitectura cloud, poate fi privată (atunci când este găzduită în interiorul companiei – fapt ce, din perspectivă infrastructură, se traduce în situarea resurselor în interiorul firewall-urilor companiei) sau publică (găzduită în Internet). Aceste caracteristici au dus la un set de valori scontate prin implementarea unei arhitecturi cloud:
Satisfacerea instantanee a necesităților de resurse de calcul;
Valoare sporită adusă tehnologiilor folosite prin diminuarea costurilor;
Platforme tehnologice standardizate care facilitează colaborarea;
Reducerea necesarului de personal specializat pentru suportul tehnologiei.
Odată cu toate aceste avantaje, cloud computing aduce și o serie de riscuri materializate în noua dimensiune dată colaborării între organizații și interacțiunii umane, noile dependințe organizaționale, modele noi de business generate datorită posibilității de satisfacere rapidă a oricăror cerințe de performanță din perspectiva puterii de calcul.
2.1 MODELUL DE REFERINȚĂ AL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
Fiecare furnizor de servicii cloud încearcă să își modeleze propriul model de referință în ceea ce privește arhitectura aplicațiilor și serviciilor livrate către clienții finali. Toți însă țin cont de principiile existente care guvernează poveștile de succes spuse în domeniul în care activează.
[1], [27] oferă abordări structurate și explicate în detaliu privind mecanismele, instrumentele, principiile și conceptele care stau la baza cloud computing-ului și care au făcut din acest concept o putere reală în implementarea soluțiilor tehnice datorită agilității sale atât din perspectivă tehnologică, cât și de business.
În acest capitol, plecând de la modelul arhitectural oferit de CSA, voi prezenta principalele componente incluse în arhitecturile de tip cloud.
Figura de mai jos prezintă o imagine de ansamblu a modelului de referință oferit de CSA:
Fig. 2.1: Model de referință CSA
Întregul model prezentat în figura anterioară este bazat pe principii fundamentale din arhitecturi tradiționale și pe modelele de referință existente [28]. De asemenea în folosirea modelului de referință indicat de CSA trebuie să se plece de la scenariile reale de utilizare a cloud computing-ului și să se respecte recomandări și best practice-uri din arhitecturile enterprise, printre care:
Definirea mecanismelor de protecție care asigură încrederea în furnizorul de servicii cloud
Dezvoltarea de capabilități și tipare pentru mai multe platforme bazate pe standarde open pentru furnizori open-source
Definirea direcțiilor de securizare a informațiilor protejate de reglementările juridice
Facilitarea accesului, administrării și folosirea datelor în deplină siguranță de către consumator
Arhitectura trebuie să faciliteze identificarea, autentificarea, autorizarea, administrarea și auditarea serviciilor implementate
Centralizarea politicilor de securitate, operațiunilor de mentenanță și funcțiilor complementare
Accesul la informații trebuie să fie securizat, dar ușor de obținut și rapid
Trebuie să existe abilitatea de a delega și de a federa accesul acolo unde specificitatea serviciilor o cere
Serviciile cloud trebuie să fie ușor de adoptat, consumat și trebuie să respecte șabloanele de securitate definite de standardele existente
Arhitectura trebuie să fie elastică, flexibilă și să aibă caracteristici de “multi-tenancy” și să fie implementată pe platforme multi-landlord
Arhitectura trebuie să adreseze mai multe niveluri de protecție – de la nivelurile rețea, sistem de operare, până la nivelul aplicație.
Toate principiile enunțate mai sus sunt bazate pe principalele standarde arhitecturale existente cum ar fi ITIL v3 [28], SABSA [29], TOGAF, JERICHO [30]. Aceste standarde sunt reprezentate de pilonii principali ai modelului arhitectural propus de CSA.
Scenariile de bază pe care orice furnizor cloud trebuie să le includă într-o arhitectură cloud sunt:
Utilizarea aplicațiilor cloud de către utilizatorii finali
Utilizarea aplicațiilor cloud de către companiilor consumatoare de astfel de servicii
Utilizarea aplicațiilor cloud de către companii care le pun la dispoziția utilizatorilor finali
În această secțiune voi prezenta componentele fiecărui pilon structural al modelului descris în figura de mai sus.
2.1.1 Business Operation Support Services
În această secțiune sunt incluse componentele descrise de figura de mai jos:
Fig. 2.2: Business Operation Support Services
Conformitate [30]– acest domeniu adresează următoarele aspecte:
Planificarea activităților și proceselor de audit [31]
Implicarea echipelor de audit independente
Solicitarea serviciilor echipelor de audit de la terțe părți specializate în astfel de servicii
Auditul intern
Maparea reglementărilor juridice aplicabile pe sistemele informatice folosite de companie
Protecția proprietății intelectuale
Mentenanța stării de conformitate și gestiunea comunicației cu furnizorul de cloud din perspectiva respectării reglementărilor juridice
Guvernanța de Date [32] – acest domeniu adresează următoarele aspecte:
Folosirea și deținerea datelor
Disponibilitatea sigură a datelor
Clasificarea datelor
Politica “clear desk”
Politici de securitate privind manipularea și categorisirea datelor
Reguli pentru prevenirea pierderii de date confidențiale (DLP)
Reguli pentru retenția datelor
Gestiunea riscului operațional [101]– acest domeniu adresează următoarele aspecte:
Comitetul care se ocupă de riscul operațional
Gestiunea situațiilor de criză
Analiza impactului în business
Indicatorii cheie ai riscului
Business Continuity
Planificare
Testare
Framework de gestiune a riscului
Evaluarea din perspectivă business
Evaluarea din perspectivă tehnică
Procese independente de gestiunea riscului
Securitatea Resurselor Umane – acest domeniu adresează următoarele aspecte:
Plecarea angajaților din companie
Gestiunea pregătirii și aptitudinilor profesionale ale angajaților
Roluri și responsabilități
Contracte individuale de muncă incluzând clauze specifice
Descrierea postului ocupat în fișa postului
Gradul de încunoștințare a personalului
Codul intern privind comportament angajaților
Servicii de monitorizare a securității [33] – acest domeniu adresează următoarele aspecte:
Platformă SIEM
Minarea evenimentelor
Monitorizarea Bazelor de date
Monitorizarea aplicațiilor
Honeypot
Monitorizarea dispozitivelor utilizatorilor finali
Corelarea evenimentelor survenite în infrastructură
Monitorizarea furnizorului de cloud
Jurnalizarea email-urilor
Market Thread Intelligence
Counter Thread Management
Portal SOC (Security Operational Center)
Servicii de securitate gestionate la nivelul companiei
Baza de cunoștințe a companiei
Protejarea mărcilor companiei
Anti-Phishing
Strategie de apărare împotriva atacurilor inter-rețele în timp real – SCAP (Security Content Automation Protocol) [70]
Comportamentul utilizatorilor și tipare de profile
Servicii juridice– acest domeniu adresează următoarele aspecte:
Contracte
E-Discovery
Pregătirea termenilor juridici ai procesului de răspuns la incident
Investigații interne– acest domeniu adresează următoarele aspecte:
Analiza dispersată în timp a evenimentelor
Jurnalizarea email-urilor
2.1.2 Information Technology Operation & Support
În această secțiune sunt incluse componentele prezentate în figura de mai jos:
Fig. 2.3:Information Technology Operation & Support
Operații IT [34]– acest domeniu adresează următoarele aspecte:
DRP (Disaster Recovery Plan):
Planificare
Testare
Guvernanță IT [100]
Guvernanța Arhitecturii
Standarde și recomandări
Project management Office– acest domeniu adresează următoarele aspecte:
Gestiunea programelor
Gestiunea proiectelor
Remediere
Gestiune resurselor– acest domeniu adresează următoarele aspecte:
Segregarea responsabilităților
Contractori
Gestiunea Portofoliului– acest domeniu adresează următoarele aspecte:
Modelul de maturitate
Roadmap
Strategie
Livrarea Serviciilor– acest domeniu adresează următoarele aspecte:
Service Level Management:
Obiective
OLA (Operational Level Agreement)
SLA-uri interne și externe
Gestiunea furnizorilor
Catalogul de servicii
Disponibilitatea IT
Gestiune disponibilității
Analiza procesului de obținere a datelor din spațiile de stocare
Planificarea capacităților
Gestiunea asset-urilor
Costurile serviciilor
Bugetare operațională
Charge back
Bugetarea investițiilor
Monitorizarea performanțelor aplicațiilor
Suportul serviciilor– acest domeniu adresează următoarele aspecte:
Gestiunea configurărilor
Planificarea capacității
Automatizarea procesului de descoperire a noilor asset-uri
Gestiunea componentelor software
Gestiunea configurărilor
Inventarierea componentelor fizice
Gestiunea incidentelor
Răspunsul la incidentele de securitate
Sistem de ticketing automat
Self-service
Sistemul de tichetare a incidentelor
Răspunsul la incidente cross-cloud
Gestiunea problemelor
Clasificarea evenimentelor
Root cause analysis
Analiza trend-urilor
Rezolvarea problemelor
Gestiunea incidentelor orfane
Gestiune cunoștințelor
Best practices
Analiza Trend-urilor
Benchmarking
Task-uri de securitate
Întrebări frecvente în securitate
Gestiunea schimbărilor
Provizionarea serviciilor
Procese de aprobare
Procese de validare a schimbărilor
Planificarea schimbărilor din proiect și cele operaționale
Moficări în caz de urgență
Gestiunea release-urilor
Planificare
Testare
Dezvoltare
Control al versionării
Gestiunea codului sursă
2.1.3 Servicii de Prezentare
În această secțiune sunt incluse componentele din figura de mai jos:
Fig. 2.4: Servicii de Prezentare
Modalitatea de prezentare– acest domeniu adresează următoarele aspecte:
Platforma aflată la nivelul consumatorului
Social media
Colaborativă
Motor de căutare
E-Readers
Platformă enterprise:
Business to Enterpise
Business to Business
Business to Consumer
Business to Mobile
Partner to Partner
Platforma de prezentare– acest domeniu adresează următoarele aspecte:
Dispozitive
Mobile
Calculatoare
Dispozitive medicale
Dispozitive inteligente
Recunoaștere vocală (IVR – Interactive Voice Response)
Scriere (ICR – Intelligent Character Recognition )
2.1.4 Servicii de Aplicație
În această secțiune sunt incluse componentele prezentate în figura de mai jos [35]:
Fig. 2.5: Servicii de Aplicație
Interfețe– acest domeniu adresează următoarele aspecte:
Validarea datelor de intrare
Ciclul proceselor de securitate– acest domeniu adresează următoarele aspecte:
Pattern-uri de securitate
Pattern-uri de atac
Exemple de coduri
Security Application Framework
Middleware de integrare
Proces de dezvoltare– acest domeniu adresează următoarele aspecte:
Self-service
Code review
Scanarea aplicației împotriva vulnerabilităților
Testare pentru volum și stres
Asigurarea calității software-ului
Conectivitate și livrare
Abstractizare
2.1.5 Servicii de Informații
În această secțiune sunt incluse componentele prezentate în figura de mai jos:
Fig. 2.6: Servicii de Informații
Livrarea serviciilor– acest domeniu adresează următoarele aspecte:
Catalog de servicii
SLA-uri
OLA-uri
Contracte
Planuri de recovery
Servicii de Raportare– acest domeniu adresează următoarele aspecte:
Dashboard
Minări de date
Instrumente de raportare
Business Intelligence
ITOS– acest domeniu adresează următoarele aspecte:
Strategie
Roadmap
PMO (Project Management Office)
Gestiunea problemelor
Gestiunea incidentelor
Gestiunea cunoștințelor
Gestiunea serviciilor
Gestiunea schimbărilor
Servicii de suport – acest domeniu adresează următoarele aspecte:
Reguli de configurare la nivel de metadate
Bază de date de gestiune a configurărilor
Spațiu de stocare al cunoștințelor
Logarea schimbărilor
Servicii de întreținere
Guvernanța datelor– acest domeniu adresează următoarele aspecte:
Evaluarea riscului
Datele non-production
Metadatele proceselor de pierdere de informații
Segregarea datelor
Gestiunea riscului– acest domeniu adresează următoarele aspecte:
GRC – Governance, Risk Management and Compliance Management
Recuperarea în caz de dezastru și procesele de backup
BIA – Business Impact Analysis
Evaluarea riscului
Monitorizarea securității– acest domeniu adresează următoarele aspecte [36]:
Servicii de transformare
Evenimente pe sesiuni de comunicație
Evenimente la nivelul bazelor de date
Evenimente de autorizare
Evenimente de autentificare
Evenimente de rețea
Evenimente de dispozitiv final
Evenimente în legătură cu privilegiile utilizatorilor
Evenimente la nivelul Access List-urilor
Evenimente de DLP
Evenimente de e-Discovery
Monitorizarea conformității
BOSS– acest domeniu adresează următoarele aspecte:
Evaluarea riscului
Găsirea neregulilor în procesul de auditarea
Clasificarea datelor
Process ownership
Datele personalului
Strategia de business
User Directory– acest domeniu adresează următoarele aspecte:
Servicii de Active Directory
LDAP
Servicii de registry
Servicii de localizare
Servicii de federare
Servicii de virtualizare de directory-uri
Servicii de Metadirectory
Spații de stocare DBMS (DataBase Management System)
2.1.6 Servicii de Infrastructură
În această secțiune sunt incluse componentele prezentate în figura următoare:
Fig. 2.7: Servicii de Infrastructură
Infrastructură internă– acest domeniu adresează următoarele aspecte:
Securitatea accesului fizic
Camere video de supraveghere
Bariere
Autentificarea fizică
Redundanță în sursa de energie electrică
Gestiunea patch-urilor
Mentenanța echipamentelor
Servicii de disponibilitate
Servere securizate și gestiunea imaginilor virtuale
Infrastructură virtuală– acest domeniu adresează următoarele aspecte:
Virtualizarea stațiilor client: local sau la distanță
Virtualizarea aplicațiilor
Client application streaming
Server application streaming
Workspace virtual
Virtualizarea serverelor
Virtualizarea spațiilor de stocare
Spațiul de adresare al dispozitivelor de rețea
Virtualizarea bazelor de date
Virtualizarea dispozitivelor mobile
Virtualizarea smartcard-urilor
2.1.7 Gestiunea Securității și Riscului
În această secțiune sunt incluse componentele prezentate în figura următoare [37]:
Fig. 2.8: Gestiunea Securității și Riscului
Guvernanța riscului și conformitate– acest domeniu adresează următoarele aspecte [38]:
Gestiunea conformității
Gestiunea politicilor
Excepții
Evaluare proprie
Gestiunea furnizorilor
Gestiunea proceselor de audit
Gestiunea riscului IT
Încunoștințarea personalului și instruirea lui
Gestiunea securității informației– acest domeniu adresează următoarele aspecte [39]:
Maparea aptitudinilor
Gestionarea portofoliului de riscuri
Raportarea riscurilor
Gestiunea infrastructurii de privilegii– acest domeniu adresează următoarele aspecte [40]:
Identity Management [41]
Domain unique identifier
Provizionare de identități [42]
Soluții de IDM federalizate [43]
Provizionarea de atribute
Servicii de autorizare [44]
Politici de solidificare a mecanismelor de autorizare
Gestiunea politicilor
Gestiunea datelor privind resursele
Gestiunea rolurilor [45]
Definirea politicilor
Gestiunea surselor de date
XACML (eXtensible Access Control Markup Language) – standard folosit pentru evaluarea cerințelor de acces în raport cu regulile definite în politici
Obligativitate
Servicii de autentificare
SAML Token
Risk Based Authentication
One Time Password
Caracteristici biometrice
Single Sign On
Smart card
Web Service securizat
Verificarea identității
Autentificare multifactor
Gestiunea parolelor
Autentificarea la nivel de rețea
Autentificarea la nivel de middleware
Gestiunea privilegiilor utilizatorilor
Logarea sesiunilor
Stocarea parolelor
Protejarea resurselor
Gestiune vulnerabilităților– acest domeniu adresează următoarele aspecte:
Gestiunea vulnerabilităților
La nivel aplicație
La nivel infrastructură
La nivel de bază de date
Testarea conformității
La nivel de baze de date
La nivel de servere
La nivel de rețea
Teste de penetrare
Interne
Externe
Gestiunea amenințărilor
Scanarea codului sursă
Clasificarea riscurilor
Servicii de protecție a infrastructurii– acest domeniu adresează următoarele aspecte:
Servere
White list-uri
Anti-virus
Intrusion detection system
Intrusion prevention system
Firewall
Network
Firewall
Filtrare pe conținut
Protecție wireless
Intrusion detection system
Intrusin prevention system
Link Layer Network Security
Blocare prin black list-uri
End point
Anti-virus, anti-spam, anti-malware
Media lockdown
Controlul spațiului de stocare
Filtrare pe conținut
White list
Host firewall
Dispozitive hardware de protecție
Intrusion detection system
Intrusin prevention system
Aplicații
Firewall la nivel aplicație
Colaborare securizată
Filtrare real time
Securizarea serviciilor de mesagerie
Protecția datelor– acest domeniu adresează următoarele aspecte:
Gestiunea ciclului de viață al datelor
Controlul metadatelor
eSignature
De-identificarea datelor
Gestiunea ciclului de viață
Mascarea datelor
Obscurizarea datelor
Etichetarea datelor
Semnarea datelor
Prevenirea pierderii datelor
La nivel de rețea
La nivel de dispozitiv final
La nivel de server
Protejarea proprietății intelectuale
Proprietate intelectuală
Gestiunea drepturilor digitale asupra datelor
Servicii criptografice
Gestiunea cheilor simetrice și asimetrice
PKI (Public Key Infratructure)
Servicii de semnătură digitală
Criptarea datelor în mișcare
Criptarea datelor folosite (in memory)
Criptarea datelor în repaus (în spațiile de stocare)
Politici și Standarde– acest domeniu adresează următoarele aspecte:
Politici privind securitatea informațiilor
Standarde privind securitatea tehnică
Clasificarea datelor și a asset-urilor
Best Practices & Corelarea reglementărilor juridice
Recomandări privind securitatea operațională
2.2 MODELUL DE SECURITATE AL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
Cloud Security Alliance oferă în [17] un model arhitectural pentru cloud, mapând pe acest model și cerințele de conformitate pe fiecare arie arhitecturală. Cloud Security Alliance categorisește aspectele care trebuie avute în vedere în securitatea în domenii funcționale descrise pe scurt în această secțiune.
2.2.1 Cadrul arhitectural pentru cloud
CSA propune un framework general pentru mediile de tip cloud. Acest framework este analizat din perspectiva inter-dependențelor existente între modelele de cloud computing (IaaS, PaaS, SaaS), inter-dependențe care își pun amprenta asupra securității datelor în cloud. IaaS conține întreaga stivă de resurse de infrastructură – de la funcționalitățile de bază, până la platformele hardware. Include capacitatea de abstractizare și de conectare logică a acestor resurse. De asemenea IaaS oferă un set de interfețe care permit gestiunea infrastructurii și interacțiunea consumatorilor de servicii IaaS cu aceasta.
PaaS este situată peste IaaS și adaugă niveluri de integrare cu framework-uri ce permit dezvoltarea de aplicații, capabilități middleware și funcții ca baze de date, servicii de mesaje și capabilități de prioritizare și cozi de așteptare. Aceste capabilități permit dezvoltatorilor să construiască aplicații pe platforma oferită ca serviciu de furnizorul de cloud.
SaaS este construit peste cele două modele prezentate mai sus și conține medii de gestiune și procesare a datelor care sunt folosite pentru a livra informațiile în formatul final către utilizatori – conținut, prezentare, aplicații și gestiunea capabilităților.
Această arhitectură este strâns legată de modelul de securitate care trebuie folosit, iar regula generală este aceea că furnizorul de cloud are o responsabilitate direct proporțională cu adâncimea stivei de servicii oferite – cu cât oferă mai puține niveluri din modelul din figura de mai jos, cu atât responsabilitatea consumatorului de servicii cloud din perspectiva asigurării securității de date crește.
Fig. 2.9: CSA – Framework-ul Cloud
Concomitent cu acest model de framework, CSA propune și un model de securitate de referință pentru arhitecturi de tip cloud care adresează relațiile dintre aceste clase de servicii și descrie controalele de securitate aferente lor.
Din perspectiva securității de date, CSA propune o abordare multidimensională a problematicii: implementarea și consumarea modalităților și serviciilor cloud nu trebuie privită, din perspectivă contextuală, doar ca mediu intern versus mediu extern, ci trebuie adresată din perspectiva localizării fizice a dispozitivelor, resurselor și informațiilor și a consumatorului de date. În această abordare se impune și stabilirea celui responsabil de guvernanța datelor, securității și conformității cu politici și standarde. De asemenea stabilirea și măsurarea riscurilor introduce la rândul său mai multe dimensiuni:
Tipul dispozitivelor, resurselor și informațiilor gestionate precum și localizarea lor on sau off premise
Cine gestionează toate resursele și cum
Ce mecanisme de control sunt implementate și cum sunt acestea integrate
Problematici privind conformitatea cu legislația în vigoare
Mapările dintre cele modelul arhitectural și cel de securitate sunt reprezentate în figura de mai jos:
Fig. 2.10: Mapările dintre modelul arhitectural de cloud și cel de securitate
Din perspectiva responsabilităților cu aspectele privind securitatea informațiilor în cloud, CSA afirmă că în modele SaaS mecanismele de securitate și sfera acestora de acțiune sunt negociate contractual: niveluri de servicii, confidențialitatea datelor și aspectele privind conformitatea cu legislația în vigoare, sunt toate subiecte ale negocierii în stabilitatea condițiilor contractuale. În medii IaaS, mecanismele de securitate aferente infrastructurii și nivelurilor de abstractizare aparțin furnizorului de servicii cloud, restul stivei aparține consumatorului. PaaS oferă un echilibru în repartizarea responsabilităților – securizarea platformei este responsabilitatea furnizorului de servicii cloud, iar securizarea aplicațiilor dezvoltate este responsabilitatea consumatorului de servicii cloud.
2.2.2 Guvernanța și gestiunea riscului în medii de tip enterprise
Guvernanța în procesele companiei [46] reprezintă un set de procese, tehnologii, practici, politici, legi și instituții care afectează modurile de a evolua, administra și controla ale unei companii. Guvernanța include relațiile dintre părțile implicate și obiectivele companiei. CSA propune 5 principii de bază care trebuie să stea la baza guvernanței proceselor:
1. Auditul mecanismelor de provizionare ale companiei
2. Gestionarea și structurarea proceselor de conducere ale companiei
3. Transparență financiară și confidențialitatea informațiilor
4. Responsabilizarea și asigurarea conformității cu legislația în vigoare a proceselor companiei
5. Structurarea participației și exercitarea drepturilor privind controlul proceselor enterprise.
Gestionarea riscului în medii de tip enterprise (Enterprise Risk Management = ERM) reprezintă procesul de identificare și înțelegere a expunerii la riscuri, capabilitatea de a gestiona această expunere și alinierea proceselor la un nivel tolerat de proprietarul datelor supuse riscului. În mediile cloud, gestionarea riscului presupune alegerea strategiei de răspuns la diferite categorii de riscuri identificate și analizate. Aceste strategii includ:
Evitarea prin întreruperea activităților care generează riscul
Reducerea prin luarea de acțiuni care reduc probabilitatea sau impactul asociat unui anumit risc
Partajarea sau asigurarea datelor prin transferarea sau partajarea unei părți din risc către un terț folosind mijloace financiare
Acceptarea prin neacționarea cauzată de raportul cost/beneficiu
2.3.4 Polemici legale: contracte și vizibilitate asupra mediilor electronice
Acest domeniu adresează particularitățile legale care s-au născut odată cu fenomenul de cloud computing întrucât prezintă principalele aspecte privind condițiile contractuale între furnizori și consumatori.
În [17] sunt prezentate o serie de inconsistențe legislative care pot apărea în diferite arii geografice din cauza reglementărilor juridice adoptate înainte de cloud și cea impusă de acest nou trend. CSA clasifică mecanismele de securitate imperative în orice arhitectură de tip cloud în funcție de aria vizată de acestea:
Considerații privind contractele între furnizorii de cloud și consumatori
Due Diligence
Condițiile contractuale propriu-zise
Monitorizarea, testarea și actualizarea
E-discovery – acest domeniu își are aplicabilitate în partea procesuală în Statele Unite ale Americii întrucât acolo există necesitatea existenței tuturor datele din cauze similare precum și a tuturor documentelor ce au aparținut lor
Posesia, custodia și controlul datelor
Aplicații în cloud relevante și mediul lor de dezvoltare
Abilitate de căutare și mecanisme de E-Discovery
Conservare și toate aspectele pe care ea le include: cost și stocare, dinamică și partajarea spațiului de stocare, domeniul conservării
Colectarea datelor: accesul și lărgimea de bandă asigurată în accesul la date, funcționalitatea datelor, analiză juridică, integritate, inaccesibilitate acceptabilă
Acces direct
Autentificare
Admisibilitate și credibilitate etc.
2.2.5 Gestiunea conformității și auditului
Odată cu migrarea infrastructurilor existente în cloud, se poate asigura un grad sporit de transparență și de calitate a datelor datorită centralizării lor și simplificării procesului de gestiune. Există o serie de legi care au fost formulate și pentru mediile virtuale sau pentru arhitecturile cloud.
CSA oferă o imagine de ansamblu a interacțiunii dintre domeniile de securitate prezentate anterior și cel de audit și conformitate cu legislația în vigoare.
Fig. 2.11: Interacțiunea între domeniile de securitate în arhitecturi cloud
Guvernanța la nivel de organizație [47] se referă la echilibrul controlului exercitat de părțile implicate, directori și manageri, într-o organizație. Acest echilibru conduce la procese consistente de gestiune, aplicare a politicilor ghidurilor și procedurilor din companie, generând decizii optime în situațiile de business întâlnite.
2.2.6 Managementul riscului
Întotdeauna una dintre cele mai grele decizii de business a fost stabilirea criteriilor de măsurare, gestionare și adresare a incertitudinilor. Incertitudinile sunt definite atât de oportunități cât și de riscuri și ele au abilitatea de a crește sau, din contră, de scădea valoarea unei organizații și strategia acesteia [48].
Managementul riscului [49] este procesul de identificare și înțelegere a gradului de expunere a unui furnizor de servicii cloud, unui risc, precum și capacitatea acestuia de a gestiona riscul prin aliniere la nivelul de toleranța stabilit de proprietarul datelor gestionate. Așadar, managementul riscului reprezintă punctul central de decizie pentru resursele IT dedicate care asigură confidențialitatea, integritatea și disponibilitatea datelor.
Procesul de management al riscului include metodele folosite de o organizație să gestioneze riscurile și să măsoare oportunitățile corespunzătoare cu obținerea obiectivelor proceselor de management a riscului. În mediile cloud există o serie de strategii de gestionare a riscului care includ:
Evitarea diferitelor tipuri de riscuri prin executarea unor activități specifice
Reducerea riscurilor prin reducerea probabilității de a se întâmpla anumite riscuri sau a impactului acestora
Partajarea sau constituirea de asigurări contra anumitor riscuri
Acceptarea riscurilor prin neacționarea în niciun fel
Relativ la riscurile la care se supune un consumator de servicii cloud, CSA a definit o serie de permisiuni și a făcut o serie de recomandări, descrise pe larg în [17].
2.2.6 Gestiunea informațiilor și a securității datelor
Acest capitol din standardul CSA structurează informația pe categoriile de arhitecturi cloud și oferă pentru fiecare dintre aceste categorii formele de structurare și stocare a datelor consumate [17].
Gestiunea informațiilor și a securității datelor este procesul care se ocupă de:
Dispersia informațiilor
Gestiunea informațiilor [50]
Ciclul de viață al datelor și securitatea lor în fiecare stare [51]
Locația și accesul la date [52]
Funcțiile, actorii și tipurile de control care trebuie să se exercite pentru fiecare dintre aceștia în gestiunea datelor și a procesului de securizare a datelor
Guvernanța datelor [52]
Securitatea datelor – incluzând aici prevenirea și detectare migrării datelor în cloud, protejarea mutării datelor în cloud, procesul de descoperire de conținut (Content Discovery) [52]
Criptarea datelor în diferitele arhitecturi cloud [53]
Prevenirea pierderii de date
Monitorizarea activității bazelor de date și a sistemelor de fișiere
Securitatea aplicațiilor [54]
Păstrarea confidențialității datelor în spațiile de stocare [55]
Gestiunea drepturilor digitale asupra datelor (Digital Rights Management – DRM) [56]
2.2.7 Interoperabilitate și portabilitate
Interoperabilitatea este cerința care permite componentelor unui ecosistem cloud să lucreze împreună pentru a-și îndeplini obiectivele. Într-un ecosistem cloud computing, componentele pot veni din surse diferite, atât din arhitecturi tradiționale cât și de cloud, publice și private (cunoscut sub numele de cloud hibrid). Interoperabilitatea impune că aceste componente să poată fi înlocuite cu componente noi sau componente de la diferiți furnizori și să continue să lucreze, atât ele ca și dispozitive cât și schimbul de date între sisteme.
CSA expune o serie de aspecte care pot duce la schimbarea furnizorului de servicii cloud, fapt posibil tocmai datorită cerințelor de interoperabilitate pe care orice furnizor de servicii cloud trebuie să le asigure în următoarele domenii:
Dispozitive fizice de stocare și procesare a datelor
Dispozitive fizice de conectare în rețea
Virtualizare
Framework
Securitate
Stocare
În [17], CSA face recomandări privind practicile care pot duce la obținerea interoperabilității la toate nivelurile enumerate mai sus.
Portabilitate definește abilitatea cu care componente ale aplicației sunt mutate și refolosite în altă arhitectură cloud, indiferent de furnizor, platformă, sistem de operare, infrastructură, localizare, depozitare, formatul de date sau API.
Aspectele care pot influența migrarea la servicii cloud și care sunt direct impactate de portabilitatea serviciilor furnizorilor de cloud includ:
Nivelul de serviciu asigurat de furnizor – SLA
Modele arhitecturale diferite – sistemele în cloud pot exista pe platforme dispersate. Este important să se țină cont de modul în care acestea vor limita portabilitatea și de dependințele de platforma implicate.
Securitate integrată
Mecanismele de autentificare și identificare a utilizatorilor și proceselor care accesează sistemele trebuie de asemenea să fie portabile și să poată fi operate pe toate platformele implicate.
Cheile de criptare trebuie gestionate de un terț sau păstrate local.
Metadatele digitale care, cu toate că nu sunt vizibile de utilizatorii finali sunt cele mai importante în manipularea datelor digitale. Odată cu mutarea fișierelor în cloud se mută și metadatele, fapt ce ar putea duce la o diminuare a securității dacă acest proces nu este gestionat corespunzător.
CSA oferă recomandări pentru fiecare tip de arhitectură de cloud în [17].
2.2.8 Mecanisme tradiționale de securitate, continuitate în business și recuperarea datelor în caz de dezastru
Acest capitol se referă la mecanismele tradiționale care trebuie păstrate și în arhitecturile cloud pentru diferitele niveluri de acces la date: de la cel fizic la cel de aplicație. Pentru a putea aplica mecanismele tradiționale trebuie să:
Se stabilească spațiile fizice care trebuie protejare
Se evalueze mijloacele tradiționale de securitate existente pentru astfel de spații incluzând aici: spațiul fizic al furnizorului de servicii cloud, revizuirea documentației privind recuperarea datelor în caz de dezastru, conformitatea cu standardele de securitate internaționale aplicabile în fiecare industrie în parte, inspectarea spațiului fizic al furnizorului pentru a se asigura existența tuturor spațiilor stipulate în standardele în vigoare, semnalizarea spațiului fizic, securitatea spațiului din perspectiva resurselor umane.
Pentru acesta, CSA propune o serie de stratificări ale măsurilor de securitate și abordări care pot conduce la rezultatele impuse de standardele de securitate. De asemenea sunt prezentate proceduri care ajută un furnizor cloud să fie în conformitate cu normele de securitate impuse lor.
Continuitatea în business adresează nivelurile de servicii necesare la migrarea în cloud pentru obținerea unui maxim de beneficii. De aceea această noțiune este strâns legata de recuperarea datelor în caz de dezastru. Cel din urmă proces vizează:
Timpul de răspuns al echipelor care intervin în caz de dezastru
Transparență în procesul de restaurare
Existența politicilor de restaurare
Prioritizarea proceselor de restaurare a datelor
2.2.9 Operațiuni la nivel de Data Center
CSA descrie în ghidul lor de securitate [17] abordarea recomandată în respectarea diferitelor standarde privind securitatea și confidențialitatea datelor aplicabile în diferite domenii de activitate.
Data center-urile reprezintă unul din factorii cheie ai arhitecturilor cloud computing întrucât acestea dau dimensiunea de localizare în cloud. [55] și [102] prezintă măsurile de securitate la nivel de data center care trebuie analizate pe durata evaluării gradului de securitate în cloud.
2.2.10 Răspunsul în caz de incident
Timpul de răspuns în caz de incident este un indice foarte important în serviciile de tip cloud. CSA prezintă în [17] elementele care afectează direct timpul de răspuns în caz de incident în arhitecturile cloud:
Natura serviciilor de tip cloud de a oferi disponibilitate imediată resurselor fără a fi necesară intervenția furnizorului duce la imposibilitatea unei cooperări optime între furnizorul și consumatorul serviciilor cloud în gestiunea unui incident de securitate.
Fenomenul de “resource pooling” (punerea în comun a resurselor) în arhitecturi de tip cloud în combinație cu nivelul crescut de elasticitate oferit de infrastructurile cloud pot complica dramatic procesele de răspuns la incidente, mai ales activitățile de analiză a incidentelor.
Fenomenul de “resource pooling” (punerea în comun a resurselor) cauzează probleme de confidențialitate pentru proprietarii datelor care sunt stocate pe același dispozitiv fizic cu privire la colectarea și analiza de telemetrie și artefacte asociate cu un incident Această provocare este de natură tehnică și trebuie adresată de furnizorul de servicii prin asigurarea unui proces corespunzător de colectare, separare și gestiune al incidentelor pentru datele stocate în mediul său.
Arhitecturile de tip cloud pot duce la dispersarea datelor pe mai multe arii geografice și jurisdicționale fără ca proprietarul lor să fie înștiințat. Procesul de conformitate cu legalitatea spațiului jurisdicțional în care se află datele poate conduce la o mai mică eficiență a răspunsului la incidente [57].
Există și o serie de oportunități în răspunsul la incidente posibile datorită arhitecturilor de tip cloud [17].
2.2.11 Securitatea Aplicațiilor
CSA clasifică securitatea aplicațiilor pe mai multe domenii:
Securizarea ciclului de viață al procesului de dezvoltare de aplicații software (Software Development Life Cycle) [58]
Procesele de conformitate cu arhitectura de securitate a aplicațiilor în cloud privind autentificarea și autorizarea [59]
Identitățile și consumarea identităților în procesele efectuate în arhitectura de securitate a aplicațiilor în cloud [59]
Procesele care vizează drepturile în aplicații și managementul accesului bazat pe risc așa cum sunt ele adresate de algoritmii de criptare în cloud și de aplicațiile în cloud. [45]
Managementul autorizării aplicațiilor în cloud (politici de autorizare și enforcement) [60]
Testare explicită pentru “Application Penetration”
Monitorizarea aplicațiilor în cloud
Autentificarea, conformitatea cu standardele în vigoare și managementul riscului și a infrastructurii partajate [60]
Diferența între evitarea codului malițios și asigurarea securității aplicațiilor.
Fiecare dintre aceste domenii este abordat pe larg in [17] și sunt propuse o serie de recomandări și practici care pot asigura securitatea aplicațiilor cloud din perspectiva domeniul respectiv.
2.2.12 Criptarea și gestiunea cheilor de criptare
CSA enumeră o serie de factori care trebuie luați în considerare în tratarea procesului de criptare de date în arhitecturi de tip cloud:
Criptarea datelor pe canalul de transmitere în arhitecturi de tip cloud nu asigură securitatea datelor – trebuia ca datele să rămână criptate pe tot parcursul stocării lor
Folosirea de tehnici de criptare încorporate în fișierele nestructurate ori de câte ori este posibil se recomandă în arhitecturi de tip cloud
Definirea unui proces de gestionare a ciclului de viață al cheilor de criptare este un aspect foarte important și trebuie menținut separat și independent de furnizorul de servicii cloud
Datele care sunt accesate frecvent cum ar fi fișiere de log, reprezintă căi foarte uzuale de scurgeri de informații și de aceea ele trebuie la rândul lor protejate
Algoritmul de criptare trebuie să fie unul sigur care să nu poată fi spart prin forță brută.
În arhitecturile de tip cloud se practică cu precădere două tipuri de criptare: criptarea pe baza conținutului și criptare care conservă formatul unui document.
De asemenea CSA oferă în [17] abordări alternative criptării printre care:
Folosirea token-ului
Anonimizarea datelor
Utilizarea diverselor mecanisme de control a accesului la bazele de date
Atunci când se măsoară eficiența uneia dintre metodele de protejare, fie că sunt ele de criptare sau alternative, incidentele luate în considerate se împart în 2 categorii: divulgarea datelor confidențiale și folosirea incorectă a acestora și acoperă următoarele arii:
Divulgarea publică accidentală
Divulgarea malițioasă sau accidentală
Divulgarea datelor de către părți terțe
Divulgarea datelor către organisme de guvernământ solicitată de legi
Folosirea incorectă a datelor de utilizator sau a celor de profil de rețea
Folosirea incorectă a datelor prin procese de inferență – de exemplu trasarea profilului unui utilizator pe baza primelor 2 comenzi realizate de acesta
De-anonimizarea datelor fapt ce duce la identificarea proprietarului de date.
CSA încheie secțiunea destinată acestui topic cu o serie de precizări despre gestiunea cheilor de criptare și recomandări privind practicile de criptare în arhitecturi cloud.
2.2.13 Gestiunea identităților, rolurilor și accesului în aplicații
În arhitecturile tradiționale există mecanisme de control ca firewall-urile și proxy-urile care asigură securitatea aplicațiilor și care nu se pot aplica la migrarea către cloud computing din cauza disponibilității oferite de arhitecturile de timp cloud.
www.rationalsurvivability.com oferă definiții despre terminologiile folosite în cloud:
Infostructură – se referă la conținut și context și este cuprins în aplicații, informații și servicii
Metastructură – metadatele necesare mecanismelor din cloud, aici se includ IPAM (IP Address Management), IAM (Identity and Access Management), BGP (Border Gateway Protocol), DNS (Domain Name Server)
Infrastructură – calculatoarele, infrastructura de rețea și de stocare care fac posibile oferirea de servicii în cloud și procesarea de date.
Gestiunea de identități nu trebuie privită și tratată ca o referință pentru mecanismul de autentificare, ci trebuie să asigure și necesarul de informații necesare pentru luarea de decizii în cadrul arhitecturilor cloud. [61] și [62] oferă abordări de implementare a procesului de gestionare a identităților care se pot aplica în arhitecturi de tip cloud. Principalele caracteristici ale acestora sunt acelea de standardizare, fapt ce asigură posibilitatea implementării lor în infrastructuri eterogene.
Identitățile includ și dispozitivele pe care rulează aplicațiile (mașinile virtuale), utilizatorii cu drepturi privilegiate care gestionează imaginea mașinii virtuale, identități pentru alte aplicații și servicii necesare pentru ca procesele să interacționeze, identități ale utilizatorilor administrativi care să gestioneze aplicațiile, identități externe companiilor consumatoare de cloud care necesită acces la aplicații ca Business to Business (B2B), Business to Community (B2C).
Deciziile relaționate cu accesul se vor lua pe baza atributelor care nu sunt legate de identitate, iar politicile de autorizare și mecanismele de gestionare trebuie să acomodeze aceste tipuri de gestiuni ale identităților, rolurilor și accesului în aplicații atribute (IdEAM). IdEAM conține cinci componente:
1. Autentificare
2. Autorizare și Controlul Accesului
3. Audit/Conformitate cu reglementările în vigoare
4. Politici
Autentificare
Autentificarea adresează aspectele relaționate cu stabilirea / afirmarea identității la cerere. Acest lucru se face de obicei în două etape. Prima etapă este procesul de clarificare a informațiilor privind identitatea și cea de a doua fază este validarea credențialelor introduse de utilizator. Cele mai importante caracteristici ale mecanismelor de autentificare pentru aplicațiile cloud sunt independența dispozitivului, interfețe comune și nesofisticate, și protocolul unic universal folosit de toate dispozitive. De asemenea, mulți furnizori de servicii expun serviciile lor în formă de API's76, și aceste API-uri sunt proiectate pentru a accepta token-uri, mai degrabă decât parolele.
Într-o aplicație tradițională, autentificarea se face folosindu-se credențiale de domeniu ale companiei (stocate în Active Directory sau LDAP), și mecanismul de autentificare folosește de obicei utilizator / parolă. Într-o arhitectură care folosește aplicații cloud, autentificarea realizată cu credențialele de companie devine mai complicată. Unele întreprinderi stabilesc tunel VPN de la furnizorul de servicii în rețeaua companiei, astfel încât acestea să poată folosi AD-ul companiei în scopul autentificării. Prin utilizarea unui astfel de mecanism se nasc o serie de provocări care trebuie adresate. Printre acestea se numără:
Probleme de latență
Probleme de conectivitate
Planificare detaliată pentru Business Continuity și pentru Disaster Recovery
Pentru a preîntâmpina toate aceste probleme, CSA sfătuiește folosirea standardelor de autentificare existente: SAML si WS-Federation. Există de asemenea situații în care, aplicațiile din interiorul unei companii trebuie accesate de către clienții companiei sau de către parteneri – scenarii pe care le găsim atât în arhitecturile tradiționale cât și în cele de cloud. Acești utilizatori nu doresc să-și creeze identități separate pentru accesul la sistemele terților (dar astăzi din păcate nu au de ales). Pentru a remedia această situație trebuie ca organizațiile să implementeze ceea ce se numește „Bring Your Own Identiy (BYOI)”, iar aplicațiile cloud trebuie să fie proiectate să „consume” identități și atributele aferente acestora care provin de la mai multe companii.
Deoarece aplicațiile din cloud sunt accesibile pe scară largă folosindu-se diferite tipuri de dispozitive, mecanismul de autentificare cu simplu identificator de utilizator / parola trebuie depreciat. Întreprinderile ar trebui să utilizeze un mecanism de autentificarea puternic – cum ar fi token RSA, mecanismul OTP (One Time Password) prin SMS sau telefon, smartcard / PKI, date biometrice etc). Acest lucru va permite transmiterea de identificatori și atribute cu un nivel ridicat de autentificare al utilizatorului (posesorul datelor) și luarea unei decizii optime pe bază de riscuri în ceea ce privește managementul accesului în interiorul aplicațiilor cloud – acest nivel se referă la nivelul de roluri în aplicații și este evaluat după ce are loc o autentificare cu succes a utilizatorului.
Întreprinderile ar trebui sa folosească autentificarea bazată pe risc pentru aplicații de cloud. Acest tip de autentificare se bazează pe identificator de dispozitiv, geolocalizare, ISP, informații euristice, etc. Aplicația Cloud nu ar trebui să efectueze numai autentificarea când realizează conectarea inițială, ci trebuie să efectueze, de asemenea, autentificarea bazată pe risc în funcție de tranzacțiile efectuate în cadrul aplicației.
Aplicațiile cloud ar trebui, de asemenea, să implementeze standarde ca SAML și Oauth în procesele de autentificare pe care le dețin. Serviciul cloud expune API-uri care acceptă autentificări cu token și nu parole, astfel încât un utilizator atunci când încearcă să acceseze serviciile de cloud de pe dispozitivul său mobil, să se autentifice mai întâi la furnizorul de identitate (probabil la AD-ul companiei), și să se genereze o aserțiune SAML care este transmis furnizorului de servicii cloud. După validarea cu succes a aserțiunii SAML, un token OAuth este generat și trimis dispozitivului mobil. Dispozitivul mobil, apoi folosește aceste token-uri pentru a accesa serviciile de cloud REST bazate pe API-uri.
Autorizare și Controlul Accesului
Autorizarea, într-un sens larg, se referă la aplicarea normelor prin care se acordă acces la resurse. Procesul de gestionare al rolurilor din aplicații implementează politicile de business, care, la rândul lor, se traduc prin acces repetat la resurselor întreprinderii. În cazul aplicațiilor cloud, autorizația trebuie să fie efectuată nu numai pe baza conținutului, dar și pe baza de context.
Pentru modelul de autorizare centrat pe utilizator (cunoscut sub numele de user-centric model), utilizatorul reprezintă punctul de decizie (PDP – Policy Decission Point). Utilizatorul determină accesul la resursele, și furnizorul de servicii acționează ca punct de execuție (PEP – Policy Enformenet Point). OAuth este utilizat pe scară largă pentru acest model. De asemenea există un alt tip de standard în curs de dezvoltare User Managed Access (UMA).
Pentru un model de autorizare centrat pe întreprindere, întreprinderea este PDP sau punct de acces în politica (PAP – Policy Access Point), iar furnizorul de servicii acționează ca PEP. În unele cazuri, întreprinderile implementează porți (gateway) de securitate cloud pentru PEP. Clientul de cloud ar trebui să utilizeze standarul XACML și un sistem centralizat de gestionare a politicilor.
Aplicațiile cloud ar putea implementa mobilizarea mai multor tipuri de servicii. Unele servicii ar putea fi aplicații existente în companie expuse ca servicii web folosind middleware-ul furnizorului, sau pot exista servicii web native cloud. Diversitatea lanțului de aprovizionare – livrare, deși abstractizată de servicii web, poate complica procesul de guvernare. Procesul de guvernare în faza de design include definirea, dezvoltarea, înregistrarea serviciilor, și implementarea mecanismului de punere în aplicare a politicilor de acces în cadrul acestor servicii. În faza Runtime, procesul de guvernanță include descoperirea serviciilor, implementarea restricțiilor de securitate pentru serviciile apelate, executarea restricțiilor de securitate pentru serviciile apelate și auditarea tuturor acceselor. Este recomandată utilizarea standardelor open cum ar fi W3C WS-policy pentru definirea aserțiunilor din politicile de securitate și de management, WS-Security pentru aplicarea restricțiilor de acces, WS-trust pentru implementarea de servicii Token Secure (STS), pentru a valida și emite jetoane, și schimb de formate simbolice, etc.
Există diferite tipuri de modele de autorizare și anume bazat pe roluri (Role Based), acces bază de reguli (Rule Based), bazat pe atribute (Attributes Based), bazat pe cereri (Claims Based), și autorizare bazată pe control acces (cum ar fi RBAC). Întreprinderile care deja au propriul mecanism de Access Web Management (WAM) trebuie să se folosească de el și să îl extindă pentru a proteja și aplicațiile cloud. Majoritatea acestor tipuri de mecanisme implementează modelul bazat pe reguli și pe cel bazat pe roluri.
Procesul de gestionare al rolurilor de aplicații trebuie să includă aceste tipuri de modele, astfel că organizațiile trebuie să migreze de la procesele de autorizare existente către cele bazate pe reguli, iar aceste reguli trebuie să se genereze pe baza atributelor și cererile utilizatorului.
Atunci când se utilizează modelul bazat pe atribute, furnizorul de identitate (IDP) transmite atribute furnizorului de servicii Cloud pentru ca acesta să execute procesul de autorizare. Furnizorii de identitate ar trebui să se asigure că:
Atributele atașate identității nu se referă strict la identitatea utilizatorului, cum ar fi nume, prenume, adresa de e-mail, etc. Acestea ar putea include, de asemenea, adresa IP, informații despre locație, apartenenta la un grup, numărul de telefon, etc.
Atributele care identifică în mod direct utilizatorul și sunt partajate cu furnizorul de cloud sunt protejate cum se cuvine, deoarece ridică probleme de confidențialitate.
Organizațiile ar trebui, de asemenea, să țină cont de complexitatea atributelor când definesc politicile de acces. Trebuie să se cunoască care este furnizorul diferitelor atribute. Există companii care oferă mecanisme de agregare de atribute. Acest lucru, fie ar putea complica sau simplifica încrederea între anumite sisteme și furnizor. Organizațiile trebuie să ia în considerare un proces complex de rezoluție a conflictelor, de manipulare a datelor incomplete, etc.
Organizațiile ar trebui să ia în considerare extensibilitatea unui atribut cum ar fi termenul de validitate (verificabilitate), termeni de utilizare, data, etc.
Organizațiile ar trebui să ia în considerare securitatea, politicile de eliberare atribute, și consimțământul. Exemplele includ directivele UE de confidențialitate, legile de stat și locale, etc.
Numai informații minime necesare pentru controlul accesului ar trebui incluse în identitatea cloud.
Organizațiile ar trebui să se asigure atributele care nu sunt identity-centric sunt de asemenea suportate de către furnizorii de cloud.
Organizațiile ar trebui să se asigure că politicile de acces și politicile de drepturi se pot gestiona și executa din punct de vedere tehnic. Posibile soluții includ utilizarea de tehnologii de automatizare a politicilor (pot fi incluse în instrumente de mash-up existente în PaaS).
Scopul principal al modelului bazat pe cereri este controlul schimbului de informații. Revendicările se bazează pe contextul tranzacției. Când se implementează modelul bazat pe cereri,trebuie să se țină cont de:
Utilizarea de cereri semnificative (adresa de e-mail reținută în memoria cache este verificată în prealabil în loc de a stoca doar adresa de e-mail)
Tip, siguranță, prospețimea și calitatea cererii (dacă cererea nu este ținută în memoria cache a furnizorului de cereri, atunci cererea nu are prospețime).
Mecanism eficient de autorizare a cererilor, pe baza contextului
Utilizarea de brokeri de cereri acolo unde este posibil pentru că aceștia ar putea fi utilizați pentru abstractizarea cererilor provenite de la diferiți furnizori de cereri.
Realizarea unui număr minim de cereri necesare anumitor tranzacții.
Aplicațiile cloud ar putea fi, de asemenea, un mash-up al altor aplicații cloud care rulează sau nu în cadrul aceluiași furnizor. Organizația trebuie să implementeze mecanisme de autentificare aplicabile tuturor serviciilor cloud indiferent de furnizor, de partajare a profilelor de utilizator cum ar fi apartenența la un grup, existența de drepturi, roluri, etc. pentru a asigura controlul acceselor granulat. Organizațiilor li se recomandă să utilizeze standarde open pentru aceste scenarii (SAML, OAuth, XACML, etc).
Sistemele de gestionare a accesului și a identităților (IDM) sunt axate în principal pe gestionarea utilizatorilor (provizionare) și gestionarea politicilor de acces (pentru aplicațiile din companie). IDM-ul (Identity Manager) este o componentă foarte importantă a IdEA (Identity, Entitlements and Access Management) pentru că furnizează acces în timp util, îl revocă atunci când utilizatorul părăsește serviciul și îl gestionează atunci când utilizatorul își modifică rolul. În cadrul companiei, sistemul de management al identităților este direct conectat la sursele de date (acestea conțin utilizatori, politici, etc). Ca și consecință directă a acestei implementări, acest sistem este caracterizat printr-un grad ridicat de customizare. Această abordare nu poate fi însă utilizată și în arhitecturile de tip cloud din cauza naturii lor de sisteme distribuite. Astfel ne aflăm în situația în care conexiunea directă sau integrarea cu toate sursele de date este imposibilă. Mai mult decât atât, nu există niciun API standard, care să poată fi utilizat pentru procesul de provizionare care ar putea permite o implementarea acestei abordări într-o manieră adaptată pentru arhitecturile cloud – mulți furnizori de servicii cloud nu au adoptat standardul SPML (Service Provisioning Markup Language) .
IDM-ul, în contextul cloud computing, nu ar trebui să gestioneze doar identitatea utilizatorilor. Ar trebui să se extindă această funcționalitate pentru a permite gestionare identitățile folosite de aplicațiile și serviciile cloud, politicile de control al accesului pentru aceste aplicații / servicii cloud, identități privilegiate pentru aplicații / servicii, etc
În prezent, procedeul de provizionare federalizat se realizează cu API-ul proprietare expuse de către furnizorul de servicii. Modelul PUSH, care este implementat în sistemele IDM nu va putea fi utilizat în aplicații cloud, deoarece ar produce o supraîncărcare a furnizorilor de servicii. Noul standard în curs de dezvoltare este Simple Cloud Identity Management (SCIM). Scopul principal al acestuia este gestionarea identităților într-un mod mai economic din perspectivă financiară, prin realizarea unui proces de implementare simplu și rapid. Obiectivul secundar este acela de a facilita migrarea unor identități de utilizator în și din cloud. SCIM este simplu, deoarece utilizează o schema de bază bine definită, propice pentru arhitecturile cloud, deoarece folosește API-uri care implementează REST suportate de mulți furnizori de servicii cloud, și sprijină procesul de management de identități, deoarece funcționează cu protocoalele existente, cum ar fi SAML, OpenID Connect etc. Pe baza acestor fapte, standardul SCIM ar putea să fie adoptat ca un standard al industriei pentru provizionarea de identități.
Unele dintre provocările pe care companiile trebuie să le aibă în vedere în procesul de management al identităților sunt:
Modalitatea de sincronizare a modificările realizate cu privire la identitatea / acces între companie și cloud, cloud-cloud, cloud-companie
Modalitatea de de-provizionare a identităților și acceselor în cloud și in interiorul companiei
Modalitatea de a asigna / actualiza / gestiona politicile de acces într-o manieră care să permită managementul eficient, scalabil, cu costuri de mentananță și transport reduse
Soluția actuală pentru multe companii este adoptarea unei soluții IDM hibride care să cuprindă atât aplicațiile companiei cât și pe cele din cloud. Managementul politicilor de acces este o provocare majoră de securitate și necesită de multe ori o soluție de automatizare eficientă din perspectiva securității: automatizarea politicilor de securitate este deosebit de importantă pentru cloud computing, deoarece utilizatorii vor cere conformitate cu legislația în vigoare privind confidențialitatea datelor, dar, în același timp, vor lua decizii de migrare sau nu la cloud în funcție de ROI-ul (Return On Investment) ale acelorași măsuri de cloud computing.
Audit/Conformitate cu reglementările în vigoare
Companii care utilizează serviciile de cloud trebuie să răspundă la trei întrebări fundamentale:
1. La ce resurse din cloud are un utilizator acces?
2. Ce resurse cloud accesează de fapt utilizatorul?
3. Care politici de acces au fost utilizate pentru luarea de decizii?
În implementările de cloud actuale, clienții enterprise au o vizibilitate foarte limitată în sursele de date ale furnizorilor de servicii cloud, fapt ce îngreunează procesul audit. O companie are nevoie de acces la aceste date nu numai pentru a desfășura o activitate profitabilă din perspectivă business, dar, și pentru a fi în conformitate cu reglementările din industrie și, de asemenea, pentru a se putea apăra în caz de fraudă.
În prezent, piața IDM se îndreaptă spre un concept extins – cel de Guvernanță a Identităților și Accesului (Identity and Access Governance – IAG). Companiile ar trebui să ia în considerare, de asemenea, utilizarea de instrumente SIEM (Security Incident & Event Management) pentru a corela logurile de acces la aplicațiile de cloud cu datele din politici în vederea generării de rapoarte de conformitate cu politicile, rapoarte care pot fi utilizate pentru a demonstra respectarea standardelor ca ISAE, HIPPA, PCI DSS, ISO27002, etc.
Considerații generale privind IdEA pentru aplicații de tip cloud:
Identitate, dreptul de acces în aplicație, și gestiune accesului nu trebuie considerate o preocupare ulterioară, ele trebuie integrate în ciclul de dezvoltare al unei aplicații încă de la stabilirea cerințelor acesteia.
În timpul fazei de proiectare trebuie să se țină cont de modul de a controla accesul la aplicație utilizând un mecanism de accesare bazat pe cerere (Claim based access) ori de câte ori este posibil.
Se pot folosi instrumente, cum ar fi SAPM (Shared Account Password Management) pentru gestionarea conturilor privilegiate în cadrul aplicației. Acest lucru permite separarea responsabilităților.
În cazul în care întreprinderea are deja instrumentele de Web Access Management, trebuie ca aceste instrumente să poată fi extinse într-un mediu cloud, adică, să permită implementarea de SAML.
Aplicațiile cloud pot extinde serviciile oferite de către furnizorii prin includerea capabilităților de logare, conectivitate la baze de date în vederea colectării de date utile de către consumatori, etc. Majoritatea furnizorilor de servicii expune aceste servicii sub formă de web service-uri sau API-uri. Accesul la aceste servicii ar putea fi controlate de token-uri OAuth. Astfel, aplicațiile cloud ar trebui să ia în considerare implementarea unor mecanisme care să permită folosirea de diverse tipuri de token-uri, cum ar fi OAuth, chei pentru API-urile apelate, etc.
Procesul de dezvoltare trebuie să prezinte agilitate, iar aplicația trebuie să fie modularizată. Acest lucru permite aplicației să utilizeze noile standarde care vor fi implementate în viitor, cum ar fi mecanismul browserID din Mozilla, Microsoft U-Prove, și mecanismul celor de la Kantara Initiative – UMA (User Managed Access).
Aplicațiile cloud prezintă următoarele amenințări:
Spoofing – scenariul în care atacatorul își asumă identitatea unui utilizator legitim
Tampering – scenariul în care atacatorul modifică datele în tranzit
Repudiere – negarea originii tranzacției (cerere sau răspuns)
Divulgarea de informații – dezvăluire neautorizată de date
Denial of Service – prejudicierea disponibilității
Escaladarea de privilegii – scenariul în care atacatorul își asumă un rol sau un drept ce nu îi corespunde de drept
Aceste amenințări ar putea fi adresate de IdEA prin următoarele mecanisme:
Spoofing – poate fi adresat printr-un mecanism eficient de Autentificare (autentificare puternică)
Falsificarea– poate fi adresată printr-un mecanism de Semnătura digitală sau Hash (așa cum este utilizat în SAML)
Repudiere – poate fi adresată printr-un mecanism de Semnătură digitală (așa cum este folosit în SAML), auditare a logurilor de acces
Divulgarea de informații– poate fi adresată prin mecanisme SSL, criptare care nu sunt specifice IdEA.
Denial of Service – poate fi adresat printr-un mecanism Security Gateway (dispozitive de control al traficului destinat web service-urilor)
Escaladare de privilegii– poate fi adresată printr-un mecanism de Autorizare (OAuth)
Politici
Managementul politicilor de acces (adesea numit "management al procesului de autorizare" atunci când este implementat mecanismul de access bazat pe rolurile din aplicații) este procesul de a specifica și menține politici care definesc access la resurse, pe bază de atribute, informații despre identitatea apelantului și atribute asociate (de exemplu, autentificarea apelantului), atribute context (de exemplu legate de mediul din care se face cererea / de componente IT), și atributele legate de destinația cererii (de exemplu, supraîncărcarea sau politicile de acces QoS) .
Procesul de management al rolurilor în aplicații reprezintă parte componentă a sistemului de management al identităților și accesului care, pe lângă această componentă, mai include și politicile asociate atributelor care nu sunt legate de identitatea, dar sunt necesare pentru a lua o decizie corectă privind accesul.
Acest proces de management al identităților și accesului, ia în considerare atribute care nu sunt în legătură directă cu identitatea cum ar fi:
Starea generală a mediului IT, procesele de afaceri, interconectarea sistemelor IT sau a proceselor de afaceri, etc. (de exemplu, nivelul de criză, situație de urgență)
Alte decizii luate de către alte entități (de exemplu, aprobările, deciziile anterioare)
Atributele legate de resursa țintă protejată (de exemplu QoS sau politicile supraîncărcarea)
De obicei, procesul care include managementul de autorizare, luarea de decizii și punerea în aplicare a acestora are loc într-unul din cele trei locuri:
1. Într-un punct central/extern de execuție al politicilor (Policy Enforcement Point)/ server de politici extern/central, serviciu cloud – Policy-as-a-Service.
2. Integrate ca parte componentă a aplicației Cloud
3. Folosind o Identity-AAS sau Persoana-AAS (o entitate Persoana este o identitatea împreună cu o serie de atribute selectate).
Recomandări
Recomandări privind Management Autorizării:
Trebuie să se stabilească dacă o perspectivă bazată pe identități-roluri în aplicație este cea mai eficientă pe necesitățile specifice ale unei companii și dacă permite un proces de mentenanță necostisitor (din perspectivă atât a resurselor cât și cele financiare) al politicilor de acces. În multe situații este posibil ca perspectiva bazată pe resursă este mai ușor de eficientizat și gestionat deoarece scopul multor companii este protejarea resurselor.
Trebuie să se definească politicile într-o manieră ușor de gestionat. Acest lucru include specificarea politicilor generice la un nivel de abstractizare care să fie inteligibil și relevant companiilor/liniilor de business/utilizatorilor care le folosesc. Există o serie de mecanisme care permit definirea de politici folosind metode automate de generare bazate pe modele de securitate.
Arhitecturi pentru interfațarea cu Furnizori de politici de acces
Punctele de decizie dintr-o politica și cele de aplicare a deciziei Policy Decission/Enforcement Point (PEP / lui PDP) care folosesc protocoale standard (de exemplu, XACML) sau protocoale proprietare (de exemplu, servicii web, sau alte apeluri middleware) pot accesa serverele de politici (care conține reguli pentru interconectarea mash-up-uri din cloud). Arhitectura conține de obicei un model de tip unul (server) la mai multe (PDP / PEP) în cazul în care politica se referă la un singur domeniu de încredere (de exemplu, un intranet al companiei). Cu toate acestea, în implementările la o scară largă, pot exista mai multe servere de politici federale care servesc multe PDP / PPE diferite. Există multe produse de management de acces care suportă regulile de gestionare de autorizare (de exemplu, în XACML), care pot fi folosite pentru a exprima drepturile identităților în aplicații. În plus, există produse de management al procesului de autorizare, care pot fi folosite pentru generarea politicile de autorizare dintr-o perspectivă bazată pe resursă.
Provizionarea politicile de acces
În arhitecturi de tip cloud computing nu mai sunt suficiente provizionarea de identitate și cea de atribute, trebuie incluse în acest proces și politicile de acces. Mai mult decât atât, atributele care nu sunt relaționate cu identitatea trebuie să fie furnizate către PDP/PEP și din această perspectivă momentul realizării acestui proces și corectitudinea lui joacă un rol crucial.
Recomandări privind procesul de autorizare în Cloud:
Trebuie să se efectueze o analiză în vederea stabilirii dacă implementarea unor politici de acces bazate pe resurse este mai eficientă decât implementarea politicilor bazate pe identități, ținându-se cont de specificitatea fiecărei companii dată prin natura business-ului, scenariile întâlnite în activitatea zilnică, prioritățile și strategiile stabilite de companie.
Asigurarea unui proces eficient de administrare a politicilor de acces, în special pentru schimbarea dinamică a mash-up-urilor cloud. Aceasta include coerența politicii, distribuția politicii, punerea în aplicare, și actualizarea acesteia. Este recomandabil să se utilizeze instrumente și abordări automate pentru a genera regulile de acces tehnice necesare pentru punerea în aplicare a politicilor.
Definirea unor responsabilități clare pentru managementul politicilor și auditul politica.
Furnizorul de cloud trebuie să ofere soluții de management al procesului de autorizare și PEP / PDP care pot fi configurate cu politici specifice consumatorilor de servicii, și să asigure că serverul de politică poate interacționa corect cu politica selectată.
Pentru serverul de politici se poate utiliza arhitectura "Politicy de-as-a-service" dacă mediul companiei necesită un server central de politici.
Recomandări privind selectarea serviciilor de autorizare:
Cea mai importantă caracteristică a serviciilor de gestionare a procesului de autorizare este posibilitatea de a gestiona politici specifice consumatorilor serviciilor cloud (subscriber policy), pentru că gestionarea politicilor de acces reprezintă cea mai mare provocare.
Serviciile oferite ar trebui să asigure un proces automatizat într-o proporție cât mai mare care să permită definirea și actualizarea politicilor, plecând de la cerințele furnizate într-o manieră intuitivă pentru oameni.
Dacă specificul companiei o permite și dacă există servicii de tip Policy as a Service, organizațiile ar trebuie sa opteze pentru externalizarea generării și actualizării de politici.
Serviciile trebuie să aibă o funcție de import-export într-un format standard ca OASIS/ XACML.
Serviciile companiei trebuie să poată interacționa cu PEP / PDP existente în infrastructura cloud și cu soluțiile de monitorizare de politici.
2.2.14 Virtualizare
Virtualizarea este o metodă ce permite rularea unuia sau mai multor “sisteme de operare” pe o singură platformă hardware. Așadar virtualizarea este procesul de decuplare al aplicațiilor software de caracteristicile hardware specifice sistemelor pe care operează.
Există trei tipuri de virtualizare:
Virtualizarea sistemelor de operare implică rularea peste un sistem de operare gazdă a unor containere în care rulează alte sisteme de operare; pe acestea din urma (în containere) rulează aplicațiile.
Avantajul acestui tip de virtualizare constă în ușurința cu care se poate instala și folosi software-ul necesar virtualizării; de asemenea, consumul de resurse al aplicației de virtualizare este redus, ceea ce înseamnă că acestea sunt disponibile aproape în totalitate sistemelor de operare oaspete (cele din containere).
Dezavantajul este acela că se limitează tipurile de sisteme de operare. Sistemul de containere implică ca sistemele oaspete să fie identice cu cel gazdă, uneori chiar și până la nivel de patch, ceea ce poate cauza probleme când se dorește folosirea unor programe ce au cerințe stricte în privința OS-ului.
Emularea hardware – în acest tip de virtualizare software-ul de virtualizare (numit hypervizor) prezintă un sistem hardware emulat pe care sistemele de operare oaspete lucrează; acest hardware emulat se numește de obicei Virtual Machine Monitor (VMM).
Această metodă dă posibilitatea aplicațiilor să ruleze într-un sistem de operare izolat. Astfel, datorită faptului că toate VMM-urile se bazează pe un singur hypervizor sistemul permite folosirea unor sisteme de operare oaspete diferite, atât la nivel de patch, cât și la nivel de sistem de operare diferite precum Windows și Linux simultan.
Dezavantajul îl reprezintă faptul că aplicațiile rulează mai încet pe un sistem virtual decât pe unul normal. De asemenea, un alt dezavantaj este legat tocmai de interfața hardware standardizata (VMM-ul); hypervizor-ul oferă o interfață directă VMM-ului și apoi traduce comenzile către resursele fizice ale sistemului. Asta înseamnă că hypervizor-ul trebuie să conțină interfețe către resursele mașinii pe care este rulat; aceste interfețe sunt numite drivere. Problema apare atunci când hypervizor-ul nu conține drivere pentru dispozitivele din sistem deoarece nu se pot instala drivere noi într-un hypervizor cum se poate la un sistem de operare. Astfel, dacă mașina are resurse hardware pentru care hypervizor-ul nu are drivere, software-ul de virtualizare nu va rula pe acel sistem. Problema este și mai acută când se dorește un upgrade la o componentă nou apăruta și pentru care nu există drivere în hypervizor.
Cel mai cunoscut software de virtualizare de acest tip este VMware, însă Microsoft oferă alternativa sa numită Virtual Server.
Paravirtualizare – în acest tip de virtualizare software-ul de virtualizare are rolul unui strat care multiplică accesul sistemelor de operare către resursele fizice ale mașinii pe care rulează (adică trimite mai multe mesaje simultan printr-un singur canal de comunicare), în loc să emuleze în întregime hardware-ul.
Această abordare are două avantaje majore: în primul rând consumă mai puține resurse datorită cantității mici de cod. Dacă emularea hardware insera un strat întreg de emulare între sistemul de operare oaspete și hardware-ul fizic, layerul software folosit în paravirtualizare lasă un OS oaspete să acceseze resursele fizice și oprește toate celelalte OS-uri din a accesa aceleași resurse în același timp.
Al doilea avantaj al paravirtualizării comparativ cu emularea hardware este că cea dintâi nu limitează accesul la driverele conținute în software-ul de virtualizare; de fapt, paravirtualizarea nu conține niciun driver, ci folosește driverele dintr-unul din sistemele de operare oaspete, numit oaspete privilegiat. Acest lucru ajută la upgrade-ul hardware fizic ulterior instalării sistemelor virtualizate chiar și dacă nu exista drivere specializate (în cazul emulării hardware acest lucru era imposibil).
Deși pare că paravirtualizarea ar fi principalul mod de a aborda problema există un impediment; datorită faptului că este un cod mic și că multiplică accesul la hardware-ul de bază, paravirtualizarea are nevoie ca sistemele de operare oaspete să fie modificate pentru a interacționa cu interfețele de paravirtualizare; ori acest lucru se poate realiza numai dacă avem acces la codul sursă al sistemului oaspete.
Virtualizarea este unul dintre elementele cheie ale arhitecturii de tip IaaS, și este tot mai folosită în partea de back-end a serviciului Platform as a Service (PaaS) și SaaS (Software as a Service). Virtualizarea este, de asemenea, în mod natural, o tehnologie cheie pentru desktop-uri virtuale, care sunt livrate din cloud private sau publice.
Principalele domenii tratate de securitatea mediilor virtuale includ:
Sporirea securității mașinii virtuale care este instalată pe o mașină fizică
Securitatea hipervizorului
Atacurile între mașinile virtuale și “blind spots”
Considerații privind performanța
Complexitatea operațională pentru mașinile virtuale
Criptarea mașinilor virtuale
Confuzia între date
Distrugere datelor în mașini virtuale
Manipularea imaginilor mașinilor virtuale
Mașini virtuale “în mișcare”
2.3 MODELE DE ARHITECTURI “CLOUD COMPUTING”
2.3.1 Clasificarea furnizorilor în funcție de nivelul serviciilor oferite
Există mai multe modele de arhitecturi în cloud [63] din perspectiva nivelurilor de servicii oferite, cele mai importante fiind:
Infrastructura ca Serviciu (Infrastructure as a Service IaaS) – acest serviciu se referă la stocarea datelor și cuprinde o serie de opțiuni disponibile utilizatorului: stocare pe rânduri (raw storage) care se referă la spațiul fizic de stocare al datelor – acesta poate fi mapat direct în unele cloud-uri private, stocare de volume (volume storage) de date prin care se înțelege volumul de date ce poate fi stocat într-o instanță IaaS, stocare la nivel de obiect (object storage) cunoscută și sub numele de stocare la nivel de fișier (file storage), content delivery network – acest concept se referă la faptul că datele sunt stocate în object storage și apoi sunt furnizate către mai multe noduri distribuite geografic pentru îmbunătățirea performanțelor la nivelul transferului de date în Internet.
Platforma ca Serviciu (Platform as a Service PaaS) – acest serviciu poate oferi: Bază de date ca Serviciu (Database as a Service), Hadoop/MapReduce/Big Data as a Service – se referă la volume mari și foarte mari de date care trebuie distribuite pe arii geografice largi și care necesită noi modele arhitecturale impuse de procesările de analiză și raportare care se fac la nivelul lor, Application Storage – această categorie se referă la toate stocările de date aferente aplicațiilor care nu se pot încadra în alte categorii de stocare. PaaS, ca și resurse consumă: baze de date, spațiile de stocare de fișiere/obiecte, volume de stocare și altele .
Software ca Serviciu (Software as a Service SasS) – acest serviciu, bazându-se pe cele de mai sus, poate furniza: spațiu de stocare și gestionare de informații (Information Storage and Management) – datele sunt introduse în spațiul de stocare prin interfețe web ce aparțin SaaS, Content/File Storage – conținut de date bazat pe fișiere poate fi stocat în aplicațiile SaaS (ex: rapoarte) care apoi pot fi accesibile prin interfețe web.
Fig. 2.12: Modele de arhitecturi Cloud Computing
2.3.2 Clasificarea furnizorilor în funcție de localizarea spațiului de stocare al datelor
Dacă ne referim la arhitecturi în cloud din perspectiva găzduirii datelor, putem face următoarea clasificare:
Cloud Privat (Private Cloud) – reprezintă arhitectura în care infrastructura este provizionată în vederea utilizării ei exclusive de o singură organizație care cuprinde mai mulți consumatori (de exemplu unități de business). Poate fi deținută, gestionată sau operată de însăși organizație, de o terță parte, sau de o combinație între cele două variante și poate exista on sau off premise (i.e. poate fi sau nu la sediul consumatorului).
Cloud Public (Public Cloud) – reprezintă arhitectura în care infrastructura este provizionată pentru libera utilizare a publicului general. Poate fi deținută, gestionată și operată de business, mediul academic, organizație guvernamentală sau o combinație a acestora. Există on premise la furnizorul de cloud.
Cloud Hibrid (Hybrid Cloud) – reprezintă arhitectura în care infrastructura este o compunere din două sau mai multe infrastructuri de cloud (publice, private sau de tip”community”) care rămân entități unice dar sunt consolidate și integrate cu ajutorul tehnologiilor standarde sau proprietare, fapt care permite portabilitatea datelor și a aplicațiilor (de exemplu aplicațiile de cloud bursting pentru load balancing între arhitecturi cloud).
Community Cloud – arhitectura în care infrastructura este provizionată pentru utilizarea exclusivă de o anumită comunitate de consumatori ce aparțin unor organizații ce împărtășesc aceleași preocupări (de exemplu au aceeași misiune, cerințe de securitate, politici și considerente de conformitate legislativă similare). Poate fi deținută, gestionată sau operată de una sau mai multe organizații din comunitate, de o terță parte, sau de o combinație între cele două variante și poate exista on sau off premise.
Personal Cloud – această arhitectură a fost dezvoltată de furnizorii de servicii în cloud și este adresată utilizatorilor finali care necesită o sincronizare între sursele lor de date pe dispozitive de stocare eterogene. Există mai multe abordări de personal cloud care se adresează unor grupuri diferite de consumatori:
Public/Personal cloud – este acea arhitectură folosită în medii non-business, exclusiv destinată indivizilor și care stochează date cu caracter personal.
Private/Personal cloud – aceasta se adresează mai mult business-ului, dar poate fi folosită și acasă de către consumatori individuali și de obicei acest tip de infrastructură este gestionat de un individ.
Fig. 2.13: Arhitecturi Cloud
Arhitecturile Cloud Hibride permit business-ului să acopere o parte din necesarul de servicii IT apelând la cloud public, iar restul de servicii să rămână în interiorul organizației. O altă caracteristică importantă a acestora o reprezintă capacitatea de a sincroniza infrastructura locală relevantă cu cea aflată în exteriorul companiei, furnizând astfel servicii de calitate superioară cu un randament sporit. Business-ul poate alege cărei resurse disponibile să aloce anumite date. Măsurile de securitate și cerințele de sincronizare vor determina locațiile întregului conținut de informații – în interiorul sau în afara companiei.
O strategie puternică de hibridizare în cloud include toate aspectele importante dintr-un business: management, automatizare și lansare. Pentru integrarea efectivă a unei arhitecturi hibride de cloud, este foarte importantă stăpânirea și îmbinarea mai multor proceduri de implementare cum ar fi: cloud intern, cloud găzduit, cloud public, pentru a ne asigura că aceste tipare sunt aliniate coerent cu modalitățile tradiționale de implementare în mediul virtual al cloud-ului.
Putem concluziona că dezvoltarea unei arhitecturi hibride de cloud atinge următoarele obiective:
Furnizează un mediu specific de exploatare a serviciilor de public cloud – o serie de servicii optimizate din arhitecturile publice de cloud sunt livrate din exteriorul companiei, iar restul sunt păstrate în interiorul acesteia.
Folosind un model hibrid se aduce o îmbunătățire importantă din perspectivă arhitecturală prin mixarea resurselor locale ieftine dar greu de scalat, cu cele scalabile și provizionabile la cerere.
Folosirea arhitecturilor hibride de cloud confirmă și validează faptul ca nu toate resursele IT trebuie să existe în cloud-ul public – de fapt există componente critice care nu ar trebui niciodată să existe în cloud-ul public. Din considerente juridice, cerințe de performanță și restricții de securitate, necesitatea unui mediu de stocare și prelucrare locală este obligatoriu. Experiența unei arhitecturi hibride ne ajută să înțelegem ciclurile de calcul și datele aferente lor care trebuie menținuți locali și ce poate fi procesat la distanță.
Fig. 2.14: Arhitecturi Cloud Hibride
CAPITOLUL 3
AUDITUL PROCESULUI DE MIGRARE AL ARHITECTURILOR TRADIȚIONALE LA ARHITECTURI DE TIP “CLOUD COMPUTING”
Migrarea unei companii către arhitecturi de tip cloud survine datorită avantajelor pe care acestea le oferă [64]. Însă există și provocări, prima dintre acestea fiind însăși alegerea tipului de arhitectură ce trebuie folosită: public sau privat. Acest proces de stabilire a tipului de model ce urmează a fi implementat trebuie să înceapă întotdeauna cu strategia de migrare la cloud computing care cuprinde [65]:
Obiectivele migrării la cloud
Modalitățile de atingere a obiectivelor, modalități materializate în facilități oferite de fiecare tip de arhitectură în parte.
Între verticalele cele mai importante în alegerea unui tip se arhitectură de cloud se numără:
Comparație între disponibilitatea și încărcarea în fiecare tip de arhitectură – arhitecturile private sunt un mediu controlabil, care oferă medii de calcul similare cu cele din infrastructura publică. Ambele infrastructuri oferă capacitate și putere de procesare flexibile. Totuși există un minus pentru arhitecturile publice cauzate de concurența pentru resurse între clienții aceluiași furnizor. Un alt aspect care trebuie luat în considerare atunci când se optează pentru cloud este ușurința de a obține acces la resursele din cloud. În mod convențional, accesul către resursele din arhitectura publică se fac prin Internet, pe când cele din cea privată se pot face prin WAN-uri private.
Securitate și conformitate legislativă [66] – cloud-urile publice sunt ușor de accesat de oricine. Totuși, ele pot fi victime atacurilor hacker-ilor. Cloud-urile private oferă un grad de securitate sporit pentru că resursele sunt clasificate din punct de vedere logic. Pentru găzduirea aplicațiilor se pot defini niveluri de securitate mai rigide la nivel de rețea pentru a reduce riscul, în cazul scenariilor de trafic nejustificat de ridicat. Locurile unde se află aplicațiile și datele considerate critice necesită un grad sporit de securitate și un circuit dedicat cu acces la resursele cloud și conectivitate controlată. Din această perspectivă cloud-ul privat este mai elastic datorită capacității sporite de backup.
Control și mentenanță [67]– cloud-urile publice oferă utilizatorilor control direct la capacitatea de procesare a resurselor furnizate. Există situații în care furnizorii de cloud nu pot modifica infrastructura existentă pentru că afectează toți clienții conectați (de exemplu aplicarea unui patch sau swap-ul de hardware)
3.1 DEFINIȚIA AUDITULUI PROCESULUI DE MIGRARE CĂTRE ARHITECTURI DE TIP “CLOUD COMPUTING”
3.1.1 Considerații generale
Auditul este un proces de evaluare a situației unei companii din perspectiva proceselor de business, a rolurilor angajaților în companie și a mapării acestora pe activitățile zilnice întreprinse, a sistemelor informatice și a modului în care acestea sunt capabile să asigure confidențialitate datelor sensibile [36]. Extrăgând principalele caracteristici din definiția de mai sus, putem spune că auditul asigură:
Vizibilitate asupra proceselor de business implementate folosind mai multe sisteme informatice [68].
O imagine de ansamblu asupra orchestrării diferitelor aplicații care deservesc unui scop comun – acest scop se materializează de cele mai multe ori într-un proces de business sau un flux de documente/date destinat satisfacerii necesității de raportare [71].
Vizibilitate asupra mediul IT din interiorul companiei și al utilizatorilor săi, împreună cu conturile acestora din aplicații și rolurile aferente lor [69].
Satisfacerea condițiilor necesare pentru a fi în conformitate cu legislația în vigoare sau cu anumite standarde (de cele mai multe ori conformitatea cu anumite standarde este dovedită prin existența unei certificări – unul din rolurile auditului este de a se asigura că o companie satisface condițiile și cerințele impuse de acel standard pentru a-i prelungi certificarea) [72].
Vizibilitate și control asupra procesului de Segregare a Responsabilităților (Segragation of Duties – SoD) [73].
Dată fiind importanța deosebită a procesului de auditare, este obligatorie implicarea echipei de audit chiar de la etapa de planificare a migrării către cloud computing a oricărei organizații. În funcție de etapa de migrare în care compania se află, echipa de audit are menirea de a răspunde la câteva întrebări specifice care asigură o tranziție eficientă și o diminuare a gradului de expunere la riscurile pe care le comportă o arhitectură de tip cloud.
Procesul de audit al unei arhitecturi de tip cloud computing este cu atât mai dificil cu cât vulnerabilităților și riscurilor la care se supune o arhitectură tradițională din perspectiva confidențialității datelor li se alătură și cele specifice cloud-ului. Etapele specifice procesului de audit în migrarea către o arhitectură cloud sunt:
Etapa premergătoare migrării în cloud
Etapa de definire a strategiei de migrare în cloud
Evaluarea furnizorilor
Implementarea modelului de cloud ales
Monitorizarea furnizorului
Monitorizarea companiei din perspectiva securizării datelor
3.1.2 Etapa premergătoare migrării în cloud
În etapa premergătoare migrării la cloud, companiile trebuie să analizeze următoarele aspecte:
Accesul privilegiat la date – cum va asigura furnizorul de servicii cloud accesul la date și mecanismul prin care acesta va combate accesul abuziv.
Conformitate cu reglementările juridice – cum poate compania să fie sigură că furnizorul său de cloud respectă legislația în vigoare din domeniul de activitate specific.
Localizarea și proprietatea datelor – unde exact sunt stocate datele în cloud – este data center-ul furnizorului în aceeași zona geografică ca și consumatorul?
Segregarea datelor – dacă aceleași servere stochează date aparținând mai multor companii, cum se asigură furnizorul că acestea nu accesează date aparținând altor consumatori?
Recuperare în caz de down time – ce se întâmplă când sistemele cloud sunt offline? Cine le readuce online?
Suport pentru investigarea necesităților ulterioare – ce se întâmplă în cazul unei atenționări din perspectivă legislativă de securizare suplimentară a datelor – va ajuta furnizorul cloud la implementarea acestei cerințe?
Viabilitate pe termen lung – ce se întâmplă cu datele companiei dacă furnizorul de cloud dispare de pe piață din cauza unei stări de faliment? Și dacă se migrează toate datele către servicii cloud, există vreo modalitate de recuperare a datelor în sensul migrării în sens invers – de la cloud la o arhitectură on-premise?
Controale generale IT – cum ne asigurăm că mediile cloud sunt securizate. Există controale tradiționale de IT implementate și la nivelul furnizorului cloud?
Servicii cloud care nu au vizibilitate – există vreun serviciu cloud deja implementat în companie de care nu se cunoaște sau care nu a fost supus unei proceduri de adopție potrivită?
3.1.3 Etapa de definire a strategiei de migrare în cloud
Odată definită strategia de migrare la cloud, echipa de audit are menirea să se asigure că această strategie este conformă cu necesitățile companiei. În cazul în care strategia nu este potrivită pentru companie, echipa de audit împreună cu managementul companiei trebuie să răspundă la următoarele întrebări:
Care este necesitatea migrării către arhitecturi cloud? Companiile trebuie să înțeleagă exact care este gradul de valoare adăugată prin migrarea arhitecturii tradiționale către una de tip cloud și să decidă dacă sunt capabile să facă față și să accepte riscurile pe care le comportă cloud-ul. Câteva întrebări clarificatoare în acest sens sunt: Există o arhitectură complexă în companie? Există vreo aplicație din infrastructura existentă pentru care furnizorul nu mai acordă suport sau care și-a atins sfârșitul vieții? – dacă acesta este cazul trebuie avut în considerare faptul că nici furnizorii de cloud nu vor putea oferi suport pentru acele aplicații. Dacă totuși decizia de migrare către cloud a fost luată ca urmare a unei analize ce a dezvăluit tendința de creștere exponențială a arhitecturii, atunci trecerea la o abordare scalabilă – cum este cloud-ul poate fi soluția [50].
Se aliniază decizia de migrare cu necesitățile business-ului? Considerente privind acest aspect ar trebui să conțină de răspunsul la întrebările: există vreo strategie de reducere a costurilor IT? Compania caută reducerea costurilor operaționale sau a celor aferente mâinii de lucru? [103]
Există o înțelegere consistentă a sistemelor și a datelor aferente care vor fi migrate în cloud? Este foarte important să se înțeleagă ce exact va fi migrat către cloud – date critice sau sensibile. Va continua compania să respecte cerințele legate de retenția datelor odată cu migrarea către cloud? Există vreo aplicație sau parte din infrastructură care va fi afectată de migrarea către cloud și va necesita re-proiectare din perspectiva comunicării de date? Volumul de date tranzacționate așteptat va depăși lungimea de bandă disponibilă a furnizorului? [75]
3.1.4 Evaluarea furnizorilor
Companiile tind întotdeauna să aleagă cel mai popular furnizor de cloud, totuși acesta nu se dovedește a fi de fiecare dată cel mai potrivit. În procesul de evaluare al furnizorilor trebuie să se ia în considerare următoarele întrebări:
Cine va gestiona relația cu furnizorul de cloud? Trebuie să se stabilească un om de legătură între companie și furnizorul de cloud, acesta va eficientiza comunicația între furnizor și departamentele interne ale consumatorului.
Cum se vor proteja datele și procesele de business? Datele joacă un rol foarte important într-o companie. Furnizorii de cloud trebuie să poată implementa mecanisme de securizare a datelor – de la proprietate intelectuală până la date confidențiale interne companiei și date critice legate de conturi bancare/informații medicale. Compania trebuie să înțeleagă toate aceste mecanisme ale furnizorului prin analizarea politicilor de securitate, testelor de penetrare și a vulnerabilităților furnizorului, procesului de atestare a controlului intern realizat de furnizor asupra propriilor medii.
Cum se divizează responsabilitățile? Compania trebuie să înțeleagă cine este responsabil cu protecția datelor la nivel operațional, cine monitorizează funcționarea corectă a serverelor, aplicațiilor, activităților din perspectiva lungimii de bandă utilizate de acestea, performanțele serviciilor etc.
Cum va impacta migrarea la cloud planul de recuperare în caz de dezastru? Procedura de acțiune în caz de dezastru are din ce în ce mai mare prioritate în mediile organizaționale. Unul din beneficiile migrării către cloud îl reprezintă procesul de fail over implementat de furnizor și optimizarea timpului în care sistemul este nefuncțional (downtime).
Cum gestionează furnizorul mai mulți consumatori care partajează aceleași resurse? Compania trebuie să cunoască mecanismele care se află implementate de către furnizorul de cloud pentru a gestiona separarea datelor clienților săi.
Cum se modifică mediul tehnologic în urma migrării la cloud? Printre modificările pe care le poate aduce migrarea la cloud se numără: topologia rețelei, interacțiunea dintre sisteme, fluxul de date.
Unde se stochează fizic datele? Dacă datele sunt stocate în altă țară față de cea a consumatorului, este posibil să fie necesare măsuri suplimentare de securitate pentru a asigura respectarea legilor aplicabile în țara consumatorului.
În ce măsură se aliniază riscurile și controalele definite de business-ul companiei cu perspectiva furnizorului? Prin realizarea unei analize de mapare a acestor două abordări se vor putea descoperi lipsurile pe care migrarea la cloud le aduce și de asemenea eventuale riscuri la care va fi supusă organizația. Pe baza acestei analize se vor putea lua decizii privind furnizorul cel mai potrivit.
3.1.5 Implementarea modelului de cloud ales
Odată ales furnizorul cel mai potrivit, auditul intern trebuie să treacă la procesul de evaluare a mecanismului de implementare. Auditul poate opina în legătură cu întregul proces de implementare sau doar privind procedura de migrare către cloud. Indiferent de procesul în care este implicată, echipa de audit trebuie să evalueze activitățile de aderare la cloud a ciclului de viață al dezvoltării unui sistem intern, de project management și metodologia de management a schimbărilor. Ori de câte ori aceste proceduri sunt modificate, auditul trebuie să se asigure că au fost supuse unui flux de aprobări și că au fost identificate principalele arii în care cloud-ul introduce riscuri suplimentare celor deja existente.
Întrebările la care trebuie să se răspundă pe parcursul implementării sunt:
Care sunt SLA (Service Level Agreement) și OLA (Operating Service Agreement)?
Care sunt responsabilitățile furnizorului în procesul de asigurare a conformității cu legislația în vigoare? Există o serie de specificații stipulate în legislație sau în standarde care trebuie luate în considerare când se migrează către o arhitectură cloud.
Cum se gestionează incidentele? Care este procesul de identificare și escalare a problemelor pentru a asigura eficiență și un timp de rezolvare optim? Este compania responsabilă cu adresarea problemelor către furnizor sau există o soluție de monitorizare care identifică comportamentul necorespunzător?
Cine determină drepturile de acces la date? În funcție de serviciul externalizat către furnizorul de cloud, provizionarea utilizatorilor se face automat sau manual – procesele de provizionare trebuie proiectate pentru toate scenariile posibile, plecând de la crearea utilizatorilor, continuând cu administrarea și terminând cu de-provozionarea conturilor. Aceste procese pot fi diferite de cele din arhitecturile tradiționale, dar trebuie să respecte aceleași politici de securitate, singurul lucru care poate fi schimbat fiind modul de implementare.
Cât de des se face backup datelor? Cine este responsabil cu acest proces? În funcție de responsabilitățile fiecăruia – ale consumatorului și ale furnizorului – trebuie să se stabilească procesul de gestionare al backup-urilor, de restaurare ale acestora, de identificare al eventualelor probleme, de escalare și de rezolvare al erorilor.
Cum vor fi informați și instruiți utilizatorii? Orice schimbare semnificativă în mediul IT trebuie să fie anunțată utilizatorilor și să fie instruiți corespunzător pentru că, fără un bagaj de cunoștințe complet, beneficiile aduse prin optimizarea proceselor de business nu pot fi valorificate.
ELEMENTE ÎN PROCESUL DE AUDIT
Procesul de auditare al adopției reprezintă procesul care, pe baza informațiilor existente despre aplicațiile analizate și ținând cont de toate aspectele invocate mai sus, are ca finalitatea formularea unui raport de audit din care să reiasă oportunitatea migrării elementelor țintă către arhitecturi de tip cloud. Auditul reprezintă, așadar, examinarea profesională a unei informații în vederea exprimării unei opinii responsabile și independente prin raportarea la un criteriu (standard, normă).
Caracteristicile fundamentale ale unui proces de audit sunt:
Examinarea unei informații trebuie să fie exclusiv o examinare profesională
Scopul examinării unei informații este acela de a exprima o opinie asupra acesteia
Opinia exprimată asupra unei informații trebuie să fie responsabilă și independentă, ceea ce presupune că persoana care face această examinare are anumite responsabilități pentru activitatea sa și trebuie să fie o persoană independentă
Examinarea trebuie să se facă după reguli stabilite, cuprinse într-un standard, normă legală ori profesională care constituie criteriu de calitate
Statutul de independență al persoanelor care realizează aceste misiuni de audit și autonomia organismului din care face parte auditorul.
Elementele oricărui proces de audit sunt:
Auditorul reprezintă persoana calificată să execute procesul de auditare. El poate fi:
Auditor intern – persoană fizică ori juridică, salariat al entității auditate, respectiv angajat prin contract care execută procesul de audit
Auditor extern – persoană fizică ori juridică care își exercită prerogativele în baza unui contract cu întreprinderea
Totalitatea auditorilor formează echipa de audit. Există situații, cum este și cel al auditării procesului de migrare în cloud în care auditorii sunt însoțiți de experți tehnici. Experții tehnici au menirea de a oferi toate detaliile necesare auditorului pentru a înțelege gradul de conformitate pe care un proces tehnic îl manifestă în raport cu criterii de evaluare.
Criteriile de audit reprezintă elementele factuale la care se raportează auditorul în procesul de audit. În mod concret acestea pot consta în:
Standardele ce reglementează anumite aspecte supuse auditării – în cazul procesului de migrare al unei aplicații către arhitecturi de tip cloud, aceste criterii includ mai multe tipuri de standarde care adresează aspecte diferite: primul dintre acestea se referă la faptul că, în procesul de auditare al migrării trebuie să se aibă în vedere capacitatea furnizorului de cloud de a respecta standardele aplicabile aplicației și informațiilor stocate în aplicația analizată. În vederea stabilirii gradului de conformitate a furnizorului cloud se pot folosi standarde specifice aplicabile acestor tipuri procedurilor.
Normele ce reglementează raporturile de obligativitatea la care sunt supuși consumatorii de servicii cloud de furnizare a anumitor informații și respectarea anumitor reguli privind stocarea și utilizarea datelor din aplicații cu date confidențiale, în raport cu clienții acestora sau cu proprietarii acelor date – de exemplu legislația europeană și cea românească privind stocarea și folosirea datelor personale.
Practicile întreprinse de comunitatea de auditare a migrării în cloud care oferă o serie de recomandări și blueprint-uri de procese de audit în vederea eficientizării acestui proces
Principiile de bază și metodologiile care stau la baza procesului analizat.
Probele de audit reprezintă înregistrări, elemente factuale și alte informații variabile care sunt relaționate cu criterii de auditare folosite în procesul de auditare. Probele de audit pot fi atât calitative cât și cantitative. Probele obiectivelor reprezintă informațiile care relevă existența unui proces/caracteristică sau care demonstrează valoarea de adevăr a unei afirmații.
Compania auditată reprezintă compania ale cărei procese, aplicații, proceduri sunt auditate în vedere demonstrării conformității cu criteriile auditate.
Raportul de audit reprezintă actul final al procesului de audit și cuprinde:
Concluziile procesului de audit – acestea sunt structurate și redactate de echipa de audit după încheierea procesul de auditare în care s-au luat în considerare faptele auditate și obiectivele procesului de audit. Concluziile auditului sunt formulate ca urmare a procesului de evaluare a probelor auditate și compararea lor cu criteriile de audit. În cazul procesului de audit al migrării către arhitecturi de tip cloud, concluziile constau în propunerea unui plan de adopție potrivit și mapat pe specificul aplicației analizate.
Rezultatele auditului – acestea reprezintă rezultatul procesului de evaluare a criteriilor de audit folosite pe probele de audit administrate. Rezultatele procesului de audit pot fi exprimate în vederea stabilirii conformității în raport cu criteriile de audit sau, din contră, în vederea stabilirii neconformității în raport cu criteriile de audit folosite. De asemenea, ele pot identifica best practice-uri sau oportunități de îmbunătățire. În cazul procesului de audit al migrării către arhitecturi de tip cloud, rezultatele constau în calcularea scorului de impact pentru sistemul analizat.
Planul de audit reprezintă modalitate de reprezentare a mecanismelor folosite pentru realizarea unui proces de audit. Planul de audit descrie activitățile întreprinse de echipa de audit pentru a obține obiectivele procesului de audit.
Programul de audit reprezintă un set de aranjamente care are ca scop obținerea unui obiectiv de audit într-un timp specific. Programul de audit include toate activitățile și resursele necesare pentru a planifica, organiza și realiza unul sau mai multe procese de audit.
Scopul procesului de audit constă în menționarea aspectelor urmărite de echipa de audit pe parcursul procesului de audit. Scopul procesului de audit prezintă întotdeauna granițe bine definite pe care nu le poate depăși, însă el poate fi definit prin prisma :
Scopului principal – reprezintă ținta principală a echipei de audit pe parcursul procesului de audit
Scopului extins – reprezintă extensii ale scopului principal care trebuie urmărite de echipa de audit în procesul de audit.
Scopul poate fi definit prin specificarea locației fizice unde se produce auditul, prin specificarea unităților organizatorice analizate sau prin specificarea proceselor și activităților incluse în procesul de audit și a timpului de desfășurare a acestuia.
METODA DE AUDITARE A PROCESULUI DE MIGRARE
În abordarea proprie privind auditul al migrării către arhitecturi de tip cloud, am implementat procesul de analiză prin raportare la noțiunile teoretice introduse în secțiunea anterioară, astfel:
Auditorul este reprezentat de persoana care realizează procesul de audit
Criteriile de audit sunt reprezentate de răspunsurile predefinite la întrebările de audit care își pun amprenta asupra calculului factorului de risc
Probele de audit folosite sunt caracteristicile aplicațiilor analizate care au influență directă asupra alegerii răspunsurilor întrebărilor – în funcție de aceste caracteristici auditorul va alege cel mai potrivit răspuns, cel care descrie cel mai fidel caracteristicile aplicației analizate în raport cu aspectul vizat de întrebare
Compania auditată este cea căreia aplicația analizată aparține
Raportul de audit este reprezentat de rezultatul final al aplicației de audit și constă în calcularea factorului de risc și oferirea unui plan de adopție al arhitecturilor de tip cloud
Compania auditată reprezintă compania ale cărei procese, aplicații, proceduri sunt auditate în vedere demonstrării conformității cu criteriile auditate. O companie poate avea mai multe clustere de aplicații, fiecare dintre aceste clustere, având mai multe aplicații în compunere.
Raportul de audit reprezintă rezultatul final al procesului de audit și cuprinde:
Concluziile procesului de audit – materializate în recomandările privind adopția cloud-ului pentru sistemul analizat. Aceste concluzii sunt exprimate în best practice-uri, etapele procesului de adopție și sugestiile privind furnizorii de cloud potriviți sistemului analizat
Rezultatele auditului – acestea reprezintă rezultatul procesului de evaluare ale criteriilor de audit folosite pentru probele de audit administrate. Rezultatele procesului de audit se reflectă în factorul de risc asociat adopției cloud-ului pentru sistemul auditat care va conduce la concluzia că aplicație se pretează sau nu a fi migrată în cloud conform practicilor și standardelor cloud existente.
Scopul procesului de audit constă în stabilirea gradului de potrivire al unei aplicații sau al unui cluster de aplicații cu arhitectura cloud :
Scopul principal – reprezintă stabilirea gradului de impact materializat prin factorul de risc calculat de aplicația de audit
Scopul extins – reprezintă trasarea unui proces de migrare în cazul în care sistemul analizat se potrivește arhitecturilor cloud, stabilirea best practice-urilor de care trebuie să se țină cont în acest proces de adopție și posibilii furnizori de servicii de cloud pe care i-ar putea contracta compania analizată.
Procesul de auditare este reprezentat în figura de mai jos:
Fig. 3.1: Procesul de auditare al migrării în cloud
Tabelul de mai jos descris în detaliu procesul reprezentat grafic:
Tabelul 3.1: Procesul de auditare al migrării
Concepte arhitecturale folosite pentru auditarea procesului de migrare către arhitecturi de tip “Cloud Computing”
În această secțiune sunt descrise conceptele utilizate în vederea manipulării și implementării procesului de audit al migrării către arhitecturi de tip cloud.
Compania reprezintă conceptul folosit pentru a manipula date specifice de companie. Acest concept conține unul sau mai multe clustere de aplicații, iar fiecare cluster conține una sau mai multe aplicații. Compania aparține unei industrii.
De asemenea, compania aparține unei tipologii: companie mică, mijlocie, mare sau foarte mare.
Clusterele de aplicații reprezintă clasificarea logică a aplicațiilor pe baza funcțiilor îndeplinite de acestea. Aplicațiile sunt sistemele din interiorul companiei care urmează a fi analizate din perspectiva migrării către cloud computing. Atât clusterele, cât și aplicațiile pot fi ținta procesului de migrarea, ca atare este sunt și subiectul procesului de audit al migrării.
Furnizorul de Cloud reprezintă compania care oferă servicii de tip cloud computing consumatorilor. Fiecare furnizor de cloud are punctele sale slabe și punctele forte. În funcție de acestea și de rezultatul procesului de audit, se evaluează cât de potrivit este un furnizor de cloud migrării aplicației țintă.
Auditul reprezintă procesul de audit. Auditul poate avea drept țintă o aplicație sau un cluster. Procesul de audit constă într-un set de întrebări la care auditorul împreună cu expertul în aplicațiile analizate trebuie să răspundă. Aceste întrebări au răspunsuri predefinite, din care trebuie să se aleagă cel mai potrivit răspuns. Întrebările sunt structurate pe domenii. Rezultatul final al unui proces de audit este reprezentat de scorul obținut de ținta procesului de audit calculat pe baza răspunsurilor oferite de experți. Există trei tipuri de scoruri – fiecare fiind caracteristic unui model de cloud. Pe baza acestor scoruri se calculează factorul mediu de impact al migrării aplicațiilor.
Procesul de adopție reprezintă succesiunea de etape ce trebuie urmată de companie în vederea migrării aplicației analizată în procesul de audit. Procesul de adopție se poate realiza atât la nivelul clusterelor de aplicații, cât și la nivelul aplicațiilor. Procesul de adopție face parte din concluziile procesului de audit și include, pe lângă cele menționate mai sus, și o serie de best practice-uri aplicabile migrării analizate.
Figura de mai jos descrie legăturile între conceptele folosite de procesul de audit:
Fig. 3.2: Concepte manipulate de procesul de audit
Fiecare proces de audit poate conține unul sau mai multe procese de adopție, în funcție de ținta procesului de audit. Dacă ținta procesului de audit este un cluster de aplicații, auditorul poate decide să realizeze procesul de adopție pentru fiecare dinte aplicațiile existente în clusterul respectiv.
Fiecare proces de adopție conține etape ale procesului de migrare. Aceste etape sunt predefinite prin aplicarea recomandărilor practicilor mondiale din domeniul cloud și definesc la nivel înalt activitățile care trebuie întreprinse în procesul de migrare. Asocierea între procesul de adopție și activitățile care trebuie executate se realizează pe baza modelului de livrare și a arhitecturii de tip cloud cu impact minim.
Figura de mai jos descrie legăturile între conceptele folosite de procesul de adopție:
Fig. 3.3: Obiecte manipulate de procesul de adopție
3.3.2 Evaluarea factorului de impact al migrării către cloud
Procesul de auditare al migrării în cloud este bazat pe un algoritm de calculare al impactului. Impactul reprezintă nivelul de risc asociat procesului de migrare al unei anumite componente, din perspectiva adresată de întrebarea care impune acel factor de impact.
Procesul de audit constă într-un set de întrebări la care expertul trebuie să răspundă. O întrebare poate avea următoarele ținte:
Aplicație – acest lucru semnifică faptul că întrebarea va fi inclusă în procesul de audit al migrării numai dacă ținta procesului de audit este o aplicație.
Cluster – acest lucru semnifică faptul că întrebarea va fi inclusă în procesul de audit al migrării numai dacă ținta procesului de audit este un cluster.
Ambele – acest lucru semnifică faptul că întrebarea va fi inclusă în procesul de audit al migrării indiferent de ținta procesului de audit.
Fiecare întrebare are multiple răspunsuri posibile, fiecare dintre ele având mai multe scoruri asociate. Scorurile asociate depind de modelul de arhitectură de cloud către care se migrează. Pe durata procesului de audit, auditorul împreună cu expertul trebuie să aleagă un singur răspuns pentru fiecare întrebare.
După finalizarea chestionarului de audit, se realizează următoarele scoruri:
Scorul aferent modelului de cloud public – acest scor reprezintă nivelul de risc pe care îl manifestă ținta procesului de audit dacă aceasta va fi migrată către arhitecturi publice de cloud computing. Dacă acest scor este scorul minim obținut, se va căuta cel mai potrivit furnizor de servicii cloud care oferă servicii în arhitecturi de tip cloud public pentru a-l propune în procesul de adopție. După alegerea furnizorului cel mai potrivit, se prezintă lista de puncte forte și puncte slabe ale furnizorului și best practice-uri existente în procesul de migrare către arhitecturi de cloud public.
Scorul aferent modelului de cloud hibrid – acest scor reprezintă nivelul de risc pe care îl manifestă ținta procesului de audit dacă aceasta va fi migrată către arhitecturi hibride de cloud computing. Dacă acest scor este scorul minim obținut, se va căuta cel mai potrivit furnizor de servicii cloud care oferă servicii în arhitecturi de tip cloud hibrid pentru a-l propune în procesul de adopție. După alegerea furnizorului cel mai potrivit, se prezintă lista de puncte forte și puncte slabe ale furnizorului și best practice-uri existente în procesul de migrare către arhitecturi de cloud hibrid. Dacă procesul de audit va evalua ca cel mai potrivit model pe cel hibrid, raportul de audit va furniza și o listă elemente sensibile care trebuie cuprinse în arhitecturi cloud private. Aceste elemente sunt obținute folosindu-se de întrebările care au cel mai ridicat scor pentru arhitecturi publice de cloud.
Scorul aferent modelului de cloud privat – acest scor reprezintă nivelul de risc pe care îl manifestă ținta procesului de audit dacă aceasta va fi migrată către arhitecturi private de cloud computing. Dacă acest scor este scorul minim obținut, se va căuta cel mai potrivit furnizor de servicii cloud care oferă servicii în arhitecturi de tip cloud privat pentru a-l propune în procesul de adopție. De obicei acest scor este minim pentru aplicații care conțin date cu un gradul de sensibilitate sporit, deoarece best practice-urile existente în comunitățile cloud sugerează păstrarea aplicațiilor cu informații confidențiale și protejate de lege în interiorul companiei. Față de aplicațiile care sunt dedicate utilizării în interiorul companiei, aplicațiile care se pretează a fi migrate către arhitecturi private de cloud prezintă particularitatea că ele trebuie accesate și de persoane din exteriorul companiei și necesită o scalare dinamică.
Scorul aferent aplicațiilor dedicate utilizării în interiorul companiei – acest scor reprezintă nivelul de risc pe care îl manifestă ținta procesului de audit dacă aceasta nu poate fi migrat către arhitecturi cloud. De obicei acest scor este minim pentru aplicații care conțin date cu un gradul de sensibilitate sporit și care trebuie accesate doar de persoane din interiorul companiei. În cazul în care acest scor este minim, nu se evaluează furnizorii de servicii cloud, ci oferă recomandări de standardizare și auditare a unor astfel de aplicații sensibile.
Figura de mai jos descrie conceptele manipulate în procesul de calculare a scorurilor descrise mai sus:
Fig. 3.4: Obiecte manipulate de procesul de calculare a scorului
În procesul de calculare al scorurilor menționate anterior, se iau în considerare răspunsurile întrebărilor conținute în chestionarul de audit. Aceste întrebări adresează diferite domenii materializate în perspective de auditare în funcție de care trebuie să se calculeze impactul migrării aplicației în arhitecturi cloud. Domeniile incluse sunt:
Complexitatea Implementării – acest domeniu include întrebări care adresează provocări privind complexitatea procesului de migrare a unei aplicații din arhitecturi tradiționale în arhitecturi de tip cloud. Aceste provocări sunt cauzate de gradul scăzut de flexibilitate pe care aplicațiile cloud îl au în comparație cu plaja largă de variație a necesităților de business. Astfel se poate întâmpla ca o aplicație cloud livrată ca Software as a Service să nu ofere o capabilitate vitală de care organizația care migrează către cloud are nevoie, fapt ce duce fie la necesitatea unor personalizări complexe, fie chiar la categorisirea acelui furnizor ca fiind nepotrivit.
Risc și Conformitate – acest domeniu include întrebări care adresează provocări privind riscurile și procesul de demonstrare a legalității migrării unei aplicații din arhitecturi tradiționale în arhitecturi de tip cloud. Întrebările din acest domeniu includ domenii legate de securitatea informațiilor confidențiale care sunt protejate de legiferări riguroase cum ar fi domeniul medical etc.
Infrastructură – acest domeniu include întrebări legate de provocările la nivel de infrastructură pe care compania trebuie să le aibă în vedere în procesul de migrarea către arhitecturi de tip cloud. În acest domeniu sunt incluse întrebări relative la necesitatea companiei de existență a unor dispozitive fizice care să asigure un grad sporit de siguranță cum ar fi sisteme de Intrusion Detection System etc.
Performanță – acest domeniu include întrebări legate de provocările la nivel de performanță. Aceste întrebări sunt strâns legate de SLA-uri, OLA-uri și trebuie avute în vedere și stipulate ca și termeni contractuali la migrare.
Toate – acest domeniu include întrebări legate de provocări generale pe parcursul procesului de migrare. Întrebările incluse aici conțin aspecte ce țin de mai multe domenii din cele prezentate anterior.
În procesul de calculare al scorului unei ținte a procesului de audit a migrării către arhitecturi cloud, se iau în considerare răspunsurile tuturor întrebărilor cuprinse în chestionarul de audit, dar și dependințele între întrebări.
Scorul este calculat folosind următoarea formulă:
, relația (3.1)
Unde:
este scorul aplicației care evaluează răspunsurile a n întrebări independente
este scorul întrebării independente i
Dacă există dependințe între întrebări, scorul este calculat folosind următoarea formulă:
, relația (3.2)
Unde:
este scorul aplicației care evaluează răspunsurile a n întrebări
este scorul aplicației care evaluează răspunsurile primelor n-1 întrebări independente
este scorul întrebării i care este dependentă de întrebarea
este scorul întrebării de care este dependentă întrebarea curentă.
Pentru evaluarea furnizorilor de servicii cloud se folosește scorul general al migrării ca fiind minimul scorurilor individuale calculate:
, relația (3.3)
Unde:
este scorul general al procesului de audit
este scorul aferent modelului de cloud public
este scorul aferent modelului de cloud hibrid
este scorul aferent modelului de cloud privat
este scorul aferent aplicațiilor dedicate utilizării în interiorul companiei
În funcție de acest scor, se evaluează furnizorii de cloud pentru a se recomanda cel mai potrivit.
Rezultatul final al procesului de audit constă în impactul general asociat țintei procesului de audit. Acesta este calculat prin medierea impactului rezultat, folosind următoarea formulă:
, relația (3.4)
Unde:
este impactul rezultat din procesul de audit
este scorul general al procesul de audit
este scorul maxim de audit care se obține prin alegerea răspunsurilor cu cel mai mare impact în urma migrării către modelul care a generat scorul general
este scorul minim de audit care se obține prin alegerea răspunsurilor cu cel mai mic impact în urma migrării către modelul care a generat scorul general
Pentru cuantificarea surplusului de beneficii adus de arhitecturile cloud se calculează factorul de valoare cloud ca fiind:
, relația (3.5)
Unde:
este factorul de valoare adus de arhitecturile cloud
este impactul rezultat din procesul de audit pentru arhitecturi de cloud publice
este impactul rezultat din procesul de audit pentru arhitecturi de cloud hibride
este impactul rezultat din procesul de audit pentru arhitecturi de cloud private calculat
este impactul rezultat din procesul de audit pentru arhitecturi de interne calculat
Dacă în urma calculării acestui impact se obține o valoare negativă, înseamnă că arhitectura cloud nu se pretează acelei aplicații, ci ea trebuie menținută în arhitectura tradițională.
CAPITOLUL 4
INTEGRAREA SISTEMELOR ÎN ARHITECTURI HIBRIDE
Odată adoptată arhitectura de tip cloud computing, una dintre cele mai mari provocări în dezvoltarea și gestionarea unei arhitecturi descentralizate de acest tip este menținerea unei conectivități consistente între sursele de date care nu sunt considerate a fi de încredere și asigurarea unui mecanism rezistent la eroare (fault tolerant). Cea mai mare oportunitate de dezvoltare în domeniul cloud o reprezintă definirea unui ecosistem care permite conectarea aplicațiilor aparținând mai multor companii proprietare, fie ei furnizori de cloud sau consumatori de cloud. Din acest punct de vedere, unul dintre cele mai importante aspecte îl reprezintă partajarea datelor între sisteme într-o manieră sigură, asigurându-se astfel securitatea datelor din perspectiva:
Accesului la date
Protejării datelor în tranzit, în procesare și în spațiul de stocare.
În cele ce urmează, am prezentat două abordări eficiente de conectarea a sistemelor din arhitecturi tradiționale cu sisteme din cloud, integrări ce au obiective diferite:
Sistemul de Identity Management urmărește, prin integrarea cu serviciul cloud, asigurarea procesului de autentificare, autorizare și audit al utilizatorilor aplicației cloud – asigurând astfel prima măsură de securitate – accesul controlat la datele partajate
Mecanism de protecție a datelor confidențiale care urmărește, într-o arhitectură hibridă în care sunt integrate sisteme din interiorul companiei și servicii cloud, asigurarea procesului de furnizare a datelor cu caracter confidențial către aplicația cloud și stocare și manipularea acestora într-o manieră sigură
4.1 GESTIONAREA IDENTITĂȚILOR ÎN ARHITECTURA HIBRIDĂ
4.1.1 Problematica gestiunii de identități în arhitecturi hibride
Sistemele dedicate gestiunii identităților și proceselor de autentificare și autorizare a accesului la aplicații și la datele stocate și manipulate de acestea operează următoarele noțiuni [109]:
Identități – acest concept este reprezentarea unei persoane care are asociate mai multe atribute și mai multe conturi în sistemele pe care le folosește
Conturile – acest concept reprezintă un profil asociat într-o aplicație care oferă anumite privilegii și drepturi de acces în sistemul respectiv. Conturile pot fi asociate persoanelor, adică identităților dar și non-persoanelor – acestea fiind conturi administrative necesare operării, administrării, gestionării și integrării diferitelor sisteme.
Specific unei arhitecturi hibride este faptul că, fiecărui nivel de implementare îi corespund atât conturile sale, cât și identitățile utilizatorilor – aceștia la rândul lor fiind clasificați în funcție de relația lor cu compania consumatoare de servicii cloud. Astfel, în arhitecturile de tip cloud, trebuie să se controleze accesul utilizatorilor finali la serviciile cloud, dar și cel al serviciilor cloud la datele sensibile ale utilizatorului.
Pentru a răspunde acestor provocări, [109] propune o abordare centralizată bazată pe:
Agregarea rolurilor și a drepturilor de acces în aplicație – astfel se obține definirea rolurilor și a regulilor de alocare a acestora în funcție de tip utilizatorului și de regulile de business specifice fiecărei categorii
Unificarea surselor autoritare de date specifice fiecărui tip de utilizator – se obține astfel un spațiu de stocare comun care conține atributele tuturor utilizatorilor implicați, în funcție de categoriile lor.
Accesul administrativ – acest concept modelează toate conturile de aplicații necesare non-persoanelor pentru a gestiona, opera, integra și oferi mentenanță soluțiilor IT.
Conturi pentru provizionarea sistemelor cloud – acest concept modelează credențialele folosite atât de utilizatorii interni ai companiei consumatoare de cloud, cât și cei externi acesteia, în vederea provizionării sistemelor cloud cu resurse.
Depozit central de identități – acesta se obține prin agregarea și normalizarea regulilor care definesc politicile de acces și a datelor utilizatorilor.
Figura de mai jos prezintă în mod grafic abordarea centralizată:
Fig. 4.1: Sistem Centralizat de Identity Management
Această abordare presupune existența unui sistem care centralizează toate informațiile cu privire la identități și conturi, și are drept dezavantaje principale faptul că necesită spațiu de stocare foarte mare, este Sigle Point of Failure și poate prezenta probleme la replicarea datelor de pe sistemele satelit, la nivel central.
O altă abordare constă în Federalizarea surselor de identități existente [110], concept care are la bază existența furnizorului de identitate, constând în sistemul care generează identitatea folosită în arhitecturi. [110] oferă mai multe abordări propuse pentru federalizarea surselor, printre care:
Soluțiile bazate pe cereri
Identity-as-a-Service
Compliance-as-a-Service
4.1.2 Abordare proprie privind gestiunea de identități în arhitecturi hibride
În studiul meu de cercetare mi-am propus îmbinarea abordărilor prezentate în vederea obținerii unui maxim de beneficii. Astfel am propus o soluție bazată pe sistemul de Identity Management existent în interiorul companiei pe care l-am extins pentru a oferi un control complet asupra ciclului de viață al identității cloud și pentru a gestiona eficient atât accesul serviciului cloud la datele confidențiale ale utilizatorului incluse în identitate, cât și pe cel al utilizatorului la funcționalitățile oferite de serviciul cloud.
Sistemul de Identity Management
Sistemul de Identity Management (IdM) [41] reprezintă sursa autoritară de date pentru aplicațiile companiei din perspectiva provizionării de conturi și de roluri de aplicație aferente conturilor create.
Sistemul de Identity Management folosit în abordarea proprie, operează cu următoarele concepte:
Sursă autoritară de date – aceasta este materializată într-un sistem informatic cu care soluția de Identity Management se integrează, care furnizează datele privind identitățile stocate în IdM. Pe baza datelor citite din sursa autoritară de date, IdM creează, modifică sau șterge identități pentru a-și sincroniza datele cu cele existente în sursă. Așadar, integrarea cu sistemele sursă de date este unidirecțională – fluxul de date venind din sursă și fiind stocate în IdM.
Sistem țintă – acesta reprezintă orice sistem cu care se integrează soluția de IdM în care IdM provizionează conturi. Din perspectiva IdM, utilizatorii creați în aplicațiile țintă reprezintă conturi ale identităților din IdM, iar în sistemul țintă acestea reprezintă utilizatori. În ceea ce privește integrarea cu sistemele țintă, aceasta poate fi bidirecțională sau unidirecțională. În cazul unei integrări unidirecționale, IdM provizionează date către sistemele țintă, și nu primește niciodată date din sistem. În acest caz nu se poate asigura o sincronizare perfectă între imaginea existentă în IdM cu privire la situația conturilor din sistemele țintă și situația reală din aplicații. În cazul în care integrarea este bidirecțională, IdM implementează un proces de sincronizare a datelor extrase din sistemele țintă cu imaginea proprie. În mod normal acest proces de sincronizare se realizează rescriind imaginea pe care o are IdM cu imaginea din țintă. În infrastructură analizată în acest studiu de caz, IdM este sursa autoritară de date, așa încât ori de câte ori IdM depistează, în procesul de reconciliere a datelor cu cele din sistemele țintă, o modificare în raport cu imaginea pe care o avea, trimite operații de modificare către sistem în vederea alinierii acestuia cu IdM-ul. În acest mod se realizează controlul rolurilor la nivel de aplicație.
Rol de aplicație – reprezintă cumulul de privilegii și mecanisme de acces pe care un utilizator le are în aplicație. Provizionarea rolurilor de aplicație este realizat de IdM fie automat pe baza unor reguli de business, fie manual prin cereri înaintate spre aprobare făcute de utilizatorii care necesită în mod legitim privilegii suplimentare.
Identitate – reprezintă conceptul de modelare al angajaților, partenerilor și colaboratorilor companiei. Acest obiect este materializat prin obiectul utilizator de IdM. Fiecare utilizator de Idm (care reprezintă o identitate la nivel de companie) are unul sau mai multe atribute stocate în sursa de date, și unul sau mai multe conturi de aplicații (care reprezintă utilizatori în sistemele țintă).
Cont – reprezintă conturile utilizatorilor de IdM provizionate în sistemele țintă. Acestea pot avea asociate roluri de aplicație. Din perspectiva sistemelor țintă, conturile provizionate de IdM reprezintă utilizatorii de aplicații.
Mecanism de autentificare – reprezintă sursa datelor folosite în mecanismul de autentificare. IdM permite definirea unor surse externe de autentificare în acest sistem cum ar Active Directoy sau alte sisteme de tip Directory Server, soluții de Access Management, de Single Sign On etc. În structura analizată, IdM se autentifică folosind ca sursă de date sistemul Active Directory. Mai mult decât atât, IdM poate fi folosit el însuși ca sursă pentru mecanismul de autentificare.
Figura de mai jos descrie arhitectura companiei din perspectiva sistemului de Identity Management.
Fig. 4.2: Sistemul de Identity Management
Sistemul de Identity Management este o componentă de securitate introdusă în cadrul infrastructurii companiei care permite controlul accesului utilizatorilor la aplicații. Mai mult decât atât, prin intermediul soluției de IdM, s-a impus în toate sistemele companiei care se integrează cu soluția de IdM, un model de acces RBAC [45] bazat pe reguli de business, în care există un mecanism de monitorizare și control al excepțiilor implementat prin procese de certificare ale acestora și prin fluxuri de aprobare.
Arhitectura soluției de Identity Management
Arhitectura folosită pentru conturarea soluției de Identity Management este reprezentată în figura de mai jos:
Fig. 4.3: Arhitectura soluției de Identity Management
Procesul de gestiune a identităților în arhitectura hibridă s-a realizat folosind următoarele sisteme:
Sistemul de Identity Management din interiorul companiei – acest sistem stochează toți angajații companiei și atributele acestora, împreună cu conturile din aplicațiile țintă pe care aceștia le dețin. Provizionarea conturilor în aplicațiile destinație se face prin două mecanisme diferite – automat prin intermediul unor reguli definite la nivelul companiei care evaluează anumite atribute ale utilizatorilor și la cerere prin solicitări inițiate de utilizatorii finali care sunt supuse procesului de aprobare definit pentru fiecare aplicație în parte, în funcție de gradul de criticalitatea al acesteia.
Sistemul de stocare al certificatelor electronice considerat a fi de încredere – acest sistem eliberează certificate electronice, iar principalul său scop este de verifica validitatea și legitimitatea folosirii certificatelor în procesul de autentificare și integritatea datelor conținute de acestea.
Un sistem în cloud care oferă servicii de raportare – Business Inteligence (BI)
Într-o arhitectură hibridă – care conține atât sisteme în cloud cât și sisteme tradiționale din interiorul companiei, procedura de autentificare include mai mulți actori:
Identity Provider (IdP) – această componentă eliberează identitatea digitală. În cazul nostru, IdP este soluția de Identity Manager din interiorul companiei și este o sursă de încredere de identități pentru serviciul din cloud. Acest sistem va loga fiecare activitate de generare de identității pentru monitorizarea acestui proces, prin specificarea următoarelor informații:
Adresa IP de la care se inițiază cererea de autentificare la serviciul cloud
Răspunsul oferit de sistemul de gestionare a certificatelor digitale privind validitatea certificatului care este folosit la inițierea cererii
Utilizatorul identificat ca fiind inițiatorul cererii împreună cu atributele sale specifice
Nivelul de acces al utilizatorului în serviciul în care acesta solicită acces
Pentru stocarea acestor loguri cu caracter confidențial, se va folosi un mecanism de criptare simetrică.
Service Provider (SP) – această componentă oferă acces la servicii identităților care au roluri corespunzătoare. În cazul nostru SP este sistemul de raportare (BI). Această componentă va stoca informații cu privire la atributele utilizatorului care au fost folosite în procesările inițiate de utilizatori, precum și date referitoare la momentele primirii identității cloud și cel al distrugerii acesteia. Din perspectivă audit, aceste informații sunt relevante atât pentru monitorizarea corectitudinii utilizării datelor și a aplicației, cât și ca probe în procesul de verificare a indicatorilor de performanță.
Entity – o entitate reprezintă actorul pentru care se fac cererile. În scenariul nostru, entitatea este chiar utilizatorul final.
Identity Verifier – această componentă reprezintă sistemul care verifică identitatea digitală. În scenariul nostru, este o abordare puțin diferită, în sensul că, această verificare se face înainte de a se genera identitatea pentru a verifica că entitatea care solicită identitatea este legitimă. Acest sistem este sistemul de stocare al certificatelor digitale, iar procesul de verificare este inițiat de Identity Management.
Fig. 4.4: Fluxul de date în generarea unei identități digitale
Figura de mai sus prezintă fluxul de informații în procesul de generare al unei identități:
Utilizatorul are un token de la furnizorul de servicii cloud care generează parola necesară autentificării la acesta, pe baza unui cod de client furnizat de serviciul cloud.
Pe stația de lucru aparținând companiei, pe care utilizatorul o deține, există stocat certificatul digital (DC) care conține, pe lângă informațiile specifice certificatului (cum ar fi furnizorul, data expirării, identificatorul unic al certificatului etc.), identificatorul unic al angajatului din sistemele companiei și informații referitoare la dispozitivul de unde certificatul este folosit pentru autentificare.
Procesul de autentificare are următorii pași:
Utilizatorul accesează serviciul cloud și, pentru a se autentifica folosește certificatul digital.
Serviciul de cloud generează un cod de client pe care îl trimite înapoi utilizatorului.
Utilizatorul, folosind token-ul primit de la companie, generează parola și o introduce în fereastra de autentificare a serviciului cloud,
Dacă parola generată în pasul 1.2 este corectă, serviciul cloud trimite DC către sistemul de Identity Management împreună cu codul generat la pasul 1.1.
Sistemul de Identity Management trimite DC către Depozitul de certificate de încredere pentru a verifica validitatea, legitimitatea și integritatea datelor acestuia. Un certificat este considerat a fi valid dacă data expirării este ulterioară celei în care s-a inițiat procesul de autentificare. Un certificat este considerat a fi legitim dacă cererea de autentificare a fost inițiată de către un dispozitiv căruia îi este permisă folosirea acelui certificat. Integritatea datelor certificatului este asigurată când datele personale de pe certificat și cele stocate de către Depozitul de certificate de încredere sunt egale. Dacă toate aceste trei validări se încheie cu succes, Depozitul de certificate de încredere trimite către Identity Management identificatorul unic al utilizatorului din sistemele companiei.
Comunicația între sistemul de Identity Management și cel de certificate este criptată, folosind o abordare hibridă, descrisă în [108].
Folosind identificatorul unic al utilizatorului din sistemele companiei, sistemul de Identity Management generează identitatea digitală pe baza funcției utilizatorului și a contului și rolurilor aferente acestuia pe care utilizatorul le are în serviciul de cloud care a cerut această identitate.
Sistemul de Identity Management criptează identitatea digitală folosind cheia primită de la furnizorul de cloud (aceasta constă în parola trimisă de utilizator, generată de token-ul serviciului cloud) și o trimite serviciului.
În funcție de privilegiile pe care le are utilizatorul în aplicația cloud, funcționalitățile disponibile îi sunt afișate utilizatorului.
După ce se efectuează toate operațiunile dorite în aplicația cloud și utilizatorul se deloghează, identitatea digitală este distrusă de furnizorul de cloud.
Dacă oricare dintre validările și verificările descrise mai sus nu este realizată cu succes, un mesaj de eroare este afișat utilizatorului și accesul la aplicația cloud este restricționat.
Procesul descris mai sus este reprezentat în figura de mai jos din perspectiva interacțiunii dintre sisteme.
Fig. 4.5: Procesul de Autentificare
Identitatea digitală creată de sistemul de Identity Management conține următoarele informații:
Informații personale despre entitatea care a inițiat cererea, informații necesare pentru a realiza operațiile dorite care îi sunt permise.
Date despre drepturile de a accesa informațiile personale care specifică ce operații implementate în aplicații cloud pot folosi informațiile cu caracter personal.
Politicile de acces necesare pentru a defini serviciile din aplicația cloud la care are acces utilizatorul care a inițiat cererea, în funcție de roluri pe care acesta le are asociate contului cloud (rolurile asociate conturilor utilizatorului din toate aplicațiile sunt stocate în sistemul de Identity Management)
Informații despre sistemul de Identity Management (IdP) – aceste informații sunt utilizate pentru a preveni atacul de tipul man in the middle. Procesul de verificare are loc atunci când aplicația cloud primește identitatea digitală.
Pentru a proteja integritatea datelor din identitatea digitală am folosit un proces de criptare sincronă, cheia de criptare fiind codul de client generat de aplicația de cloud la pasul 1.1.
Fig. 4.6: Identitatea Digitală
Figura de mai jos prezintă modul de utilizare al datelor din identitatea digitală de către aplicația cloud:
Serviciul cloud decriptează informațiile incluse în identitatea digitală
Serviciul cloud citește politicile de acces pentru a-i furniza utilizatorului doar serviciile la care acesta are drept.
Când utilizatorul realizează o anumită operație, aplicația cloud accesează informațiile personale în conformitate cu drepturile de acces incluse în identitatea digitală.
Fig. 4.7: Consumarea identității digitale
Mecanismul de criptare al datelor transmise între sistemul de Identity Management și sistemul de gestiune al certificatelor se bazează pe o abordare hibridă între mecanisme de criptare simetrice și asimetrice. Pentru integritatea datelor se folosește un mecanism de hash aplicat mesajelor schimbate de către cele două sisteme, iar pentru autentificarea sistemului de IdM se folosește mecanismul de semnătură digitală. Semnătura digitală se aplică pe hash-ul mesajului trimis astfel încât, cele două sisteme să poată verifica sursa pachetelor primite.
Figura de mai jos prezintă mecanismul de criptare:
Fig. 4.8: Mecanismul de criptare hibridă
Există două sisteme de generare și gestionare de chei de criptare:
Sistemul de generare și gestionare pentru cheile 3 DES
Sistemul de generare și gestionare pentru cheile RSA folosit pentru comunicația dintre sistemul de Identity Management și sistemul de gestiune a certificatelor digitale. Acest sistem generează atât cheia publică cât și cheile private ale sistemelor. Așadar, acest sistem este accesibil atât sistemului de Identity Management, cât și celui de gestiune a certificatelor digitale.
Mecanismul de criptare folosește cheile de criptare generate de sistemele menționate anterior și conține următorii pași:
Mesajului inițial i se aplică algoritmul în urma căruia se obține hash-ul mesajului. Acest hash este semnat cu cheia RSA privată
Mesajul inițial este criptat cu cheia 3 DES, obținându-se astfel mesajul criptat
Cheia 3 DES este criptată cu cheia publică RSA.
Mesajul trimis către sistemul de gestiune a certificatelor conține: hash-ul mesajului semnat, mesajul criptat și cheia de decriptare a mesajului criptată cu un algoritm RSA.
Figura de mai jos prezintă mecanismul de decriptare care are loc în sistemul de gestiune a certificatelor:
Fig. 4.9: Mecanism de decriptare
Mecanismul de decriptare conține următorii pași:
Folosind cheia privată RSA, sistemul de gestiune de certificate decriptează cheia 3 DES
Folosind cheia 3 DES, se decriptează mesajul. Pentru a se verifica integritatea mesajului, se aplică asupra acestuia algoritmul MD5
Folosind cheia publică se verifică hash-ul semnat și se obține hash-ul mesajului care se compară cu rezultatul de la pasul 2. Dacă această verificare se realizează cu succes înseamnă că mesajul este integru. Dacă această verificare eșuează, sistemul de gestiune a certificatelor returnează eroare sistemului de Identity Management, așa încât procesul de generare de identități eșuează.
Principalele beneficii ale acestei abordări sunt:
Utilizatorul nu trebuie să știe niciodată identitatea sa digitală, fapt ce nu îi permite alterarea drepturilor de acces la aplicația cloud
Există un proces cu 2 pași de verificare contra furtului de certificate digitale:
Primul pas este acela în care utilizatorul trebuie să introducă parola generată de token-ul companiei pentru a continua procesul de autentificare – dacă atacatorul fură certificatul digital fără a avea și token-ul, autentificarea nu se realizează
Al doilea pas este verificarea realizată de Depozitul de certificate de încredere – acest pas îl completează pe primul în sensul ca dacă un atacator reușește să fure atât certificatul cât și token-ul, pentru a putea realiza autentificarea trebuie ca ea să fie inițiată de la un dispozitiv autorizat.
Procesul de autentificare implică mai multe sisteme, fapt ce face imposibil un atac de tipul man in the middle cu un singur pas de penetrare.
Identitatea digitală conține doar informațiile necesare serviciilor din aplicația cloud care îi sunt permise utilizatorului
Identitatea digitală este distrusă după ce este folosită, fără a fi stocată în aplicația cloud.
Comunicația între sistemele care asigură generarea identității digitale este criptată, fapt ce împiedică pierderea datelor confidențiale în caz de penetrare.
Componenta de audit a acestui proces
Acest proces oferă un mare beneficiu companiilor cu arhitectură hibridă pentru că pot demonstra prin intermediul interacțiunii dintre sisteme că mediul electronic este sigur întrucât oferă mecanisme de autentificare în mai mulți pași. Prin consumare identităților cloud generate se asigură că datele cu adevărat sensibile, cele referitoare la datele personale ale utilizatorului, nu sunt stocate niciodată la furnizor, permițând astfel realizarea unor controale severe asupra lor.
Prin procesarea logurilor care conțin toate sesiunile de generare și utilizare a identităților electronice, sistemul de audit poate controla activitatea utilizatorilor și poate descoperi comportamente inadecvate. Astfel de statistici includ:
Orele de vârf în utilizarea aplicației de generare a identităților
Gazda care a inițiat cel mai mare număr de cereri în cel mai scurt timp
Timpul mediu petrecut în aplicația cloud (timpul cuprins între momentul autentificării unei identități și cel al consumării acesteia)
Populația companiei care folosește cel mai mult aplicația – clasificare realizată în funcție de atribute specifice ca departament, funcție etc.
Gradul de utilizare al aplicației
Timpul de răspuns mediu al aplicației.
Acest proces descrie o activitate premergătoare auditării care adresează aspecte importante din gestionarea securității în cloud și care contribuie semnificativ la procesul de auditare prin îmbunătățirea proceselor de business și logarea etapelor semnificative din acestea.
4.2 GESTIONAREA COMUNICAȚIEI DATELOR CONFIDENȚIALE ÎNTRE SISTEMELE DIN INTERIORUL COMPANIEI ȘI CELE DIN EXTERIOR
4.2.1 Algoritmi de criptare
Criptare 3 DES
DES (Data Encryption Standard) reprezintă un mecanism de criptare simetrică bazat pe chei constituite din blocuri numerice, care a fost realizat de NIST. Astfel, algoritmul are drept intrare un bloc text de 64 de biți, iar la ieșire un text criptat de aceeași dimensiune prelucrat folosind o cheii de 56 de biți. Procesul de criptare se realizează în trei pași:
Textului inițial de 64 de biți i se aplică permutarea inițială IP, obținându-se:
, relația ( 4.1)
Unde:
este textul inițial transformat
este permutarea inițială aplicată textului
este textul inițial
sunt primii 32 de biți din
sunt ultimii 32 de biți din
Se efectuează 16 iterații folosind o funcție stabilită și secvențe de 48 de biți din cheia de criptare. La fiecare iterație se calculează:
, relația (4.2)
, relația (4.3)
Unde:
reprezintă primii 32 de biți din textul transformat la pasul i
reprezintă ultimii 32 de biți din textul transformat la pasul i
este XOR (sau exclusiv a două secvențe binare)
reprezintă secvența de 48 de biți din cheia de criptare de la pasul i obținută prin metode de “key schedule”
reprezintă funcția Feistel
Funcția f operează pe o jumătate de bloc (32 biți) la un moment dat și este formată din patru pași:
Expansiune — jumătatea de bloc de 32 de biți este extinsă la 48 de biți folosind funcția de expansiune prin duplicarea unor biți.
Amestecare — rezultatul este combinat cu o subcheie folosind operația XOR.
Substituție — după combinarea cu subcheie, blocul este divizat în opt părți de 6 biți fiecare. Pentru procesare se folosesc S cutii, numite cutii de substituție. Fiecare din cele opt cutii S înlocuiește cei șase biți de intrare cu patru biți conform unei transformări neliniare, oferită sub forma unui tabel de căutare. Cutiile S reprezintă securitatea lui DES — fără ele, cifrul ar fi liniar și ușor de spart.
Permutare — în final, cele 32 de ieșiri din matricile S sunt rearanjate conform permutării fixe P.
Blocului obținut la a 16-a permutare i se aplică inversa permutării inițiale pentru a se obține textul criptat:
, relația (4.4)
Unde:
reprezintă textul criptat
reprezintă primii 32 de biți din textul transformat la pasul 16
reprezintă ultimii 32 de biți din textul transformat la pasul 16
inversa permutării inițiale
Triplu DES (cunoscut și sub numele 3DES sau – mai rar – DES − ede) este un sistem derivat din DES. 3 DES este definit de formula:
, relația (4.5)
Unde:
reprezintă textul inițial
reprezintă textul criptat
sunt chei DES de 56 biți
reprezintă criptarea DES cu cheia
reprezintă decriptarea DES cu cheia
Utilizarea a trei pași este esențială pentru protejarea contra unui atac de tipul meet-in-the-middle. În cazul unei duble criptări, acest atac este destul de eficient.
Criptarea Homomorfică
Criptarea homomorfică reprezintă procesarea datelor criptate astfel încât prin decriptarea rezultatului final să se obțină datele inițiale procesate. Criptarea homomorfică se bazează pe latici.
Gentry a oferit în [96] primul mecanism de criptare homomorfic, urmându-i-se apoi acestei lucrări și alte studii de cercetare [111], [112].
Criptarea homomorfică este definite de un cvadruplu de algoritmi polinomiali:
, relația (4.6)
Unde:
reprezintă sistemul de criptarea homomorifică
reprezintă algoritmul de generare al cheilor de criptare. Astfel în sistemele cu chei publice acest algoritm are ca intrare și ca ieșiri – cheia publică, cheia secretă și – cheia de evaluare. În sistemele de criptare simetrice acest algoritm are ca intrare și ca ieșiri – cheia secretă și cheia de evaluare.
reprezintă algoritmul de criptare și constă în:
relația (4.7)
Unde:
reprezintă textul în clar
reprezintă cheia de criptare care constă în în algoritmii cu chei publici și în cei simetrici
reprezintă algoritmul de decriptare și constă în:
, relația (4.8)
Unde:
reprezintă textul în clar
reprezintă cheia de criptare care constă în în algoritmii cu chei publici și în cei simetrici
reprezintă algoritmul de evaluare și constă calcularea efectului aplicării funcției f pe un text criptat compus din i blocuri:
,relația (4.9)
Unde:
reprezintă textul cifrat
reprezintă cheia de evaluare
reprezintă funcția de procesare.
Schema de mai jos descrie criptarea homomorfică [113]:
Fig. 4.10: Criptare homomorifică
Principalele caracteristici ale acestei metodologii de criptare sunt:
Securizarea datelor și a funcțiilor de procesare, fapt ce o face deosebit de utilă și avantajoasă pentru aplicațiile care presupun procesări ale mai multor sisteme și delegări computaționale
Maleabilitate țintă – această proprietate presupune că numai un set de funcții specifice poate modifica datele criptate pentru păstrarea consistenței lor. Astfel, chiar dacă este posibilă alterarea datelor de către un terț, fapt ce nu se dorește într-o schemă de criptare sigură, există mecanisme de verificare prin care mecanismul de decriptare se asigură de legitimitatea transformării.
Putere de calcul și posibilități de verificare – aceste două caracteristici se referă la posibilitățile pe care le proprietarul datelor de a verifica sistemul care a realizat procesarea în vederea stabilirii corectitudinii acesteia.
Gradul de potrivire între datele criptate și datele criptate procesate
Calcul paralel – pentru funcțiile de procesare care permit calculul paralel, acesta poate fi folosit și pentru criptarea homomorfică, sporind astfel performanțele.
4.2.2 Abordare proprie privind securizarea datelor în arhitecturi hibride
În arhitecturi hibride în care sistemele din interiorul companiei partajează date cu serviciile cloud, trebuie să se acorde o atenție sporită securizării datelor confidențiale, care vizează:
Securizarea datelor în tranzit – constând în securizarea canalelor de comunicație care integrează sistemele țintă
Securizarea datelor în procesare – constând în mecanismele de protejare a datelor pe durata prelucrării lor de către sisteme, astfel încât, componentele sistemice neautorizate să nu aibă acces la informațiile confidențiale
Securizarea datelor stocate – constând în mecanismele de criptare ale datelor stocate.
Prin asigurarea protecției în toate cele trei scenarii menționate mai sus și a accesului la date adresat în secțiunea anterioară, propun o abordare menită să asigure atât conformitate cu standardele și reglementările în vigoare privind depozitarea și folosirea datelor confidențiale, cât și un mecanism eficient de protecție împotriva atacurilor informatice, reducând semnificativ rata de pierdere a datelor și de accesare neautorizată a acestora.
Arhitectura folosită în acest model este prezentată în figura de mai jos:
Fig. 4.11: Arhitectura sistemului de securizare a comunicației în arhitecturi hibride
Arhitectura mediului folosit pentru implementarea acestui mecanism de securitate este definită de următoarele particularități:
Aplicația de retenții se află în interiorul companiei și stochează date confidențiale despre informațiile financiare ale clienților companiei. Datele stocate sunt criptate folosind un algoritm simetric 3 DES
Pentru implementarea algoritmului de criptare se folosește un sistem dedicat de gestiune și generare a cheilor de criptare
Aplicația de raportare cloud comunică cu aplicația de retenții prin web service securizat folosind un mecanism de autentificare
Aplicația de retenții oferă datele solicitate serviciului cloud criptate, folosindu-se un algoritm homomorfic [96] ale cărui chei de criptare sunt generate și gestionate de un sistem dedicat.
Criptarea homomorfică reprezintă mecanismul prin care se permite procesarea unui set de date criptate și generarea în acest mod a unui rezultat criptat. Acest tip de criptare prezintă particularitatea că, aplicând cheia de decriptare folosită pentru textul inițial pe rezultatul final, se obține textul inițial necriptat asupra căruia s-au realizat transformările procesate asupra intrării criptate. Datorită acestor caracteristici, algoritmul homomorfic este foarte folosit pentru sistemele de comunicație moderne, fapt ce m-a determinat să îl aleg pentru această abordare.
Algoritmul homomorfic utilizat este cel prezentat în [96] și este importat ca o librărie funcțională în aplicația de retenții.
Utilizatorul final se autentifică atât la aplicația cloud de raportare, cât și la sistemele din interiorul companiei în vederea obținerii cheii de decriptare pentru datele oferite de serviciul cloud.
Utilizatorul final are un agent instalat pe stația de lucru ce aparține companiei prin care se descriptează datele. Agentul este instalat la nivelul browser-ului web.
Integrarea între cele două aplicații se realizează astfel:
Utilizatorul se autentifică la aplicația de raportare prin introducerea credențialelor. După validarea acestora, utilizatorul selectează serviciul dorit care necesită stabilirea unei comunicații cu aplicația de retenții.
Aplicația de raportare se conectează la aplicația de retenții prin invocarea unui web service care are implementat un mecanism de autentificare. Odată stabilită cu succes comunicația dintre cele două sisteme prin validarea credențialelor de autentificare ale serviciului cloud, aplicația de raportare solicită datele de care are nevoie în vederea rezolvării solicitării utilizatorului.
Aplicația de retenții comunică cu sistemul intern de gestiune a cheilor de criptare pentru algoritmul 3 DES și, folosind cheia de decriptare pe care acesta i-o trimite, decriptează datele solicitate de aplicația de raportare.
Aplicația de retenții comunică cu sistemul intern de gestiune al cheilor de criptare pentru algoritmul HEA.
Folosind cheia de criptare pe care sistemul intern de gestiune a cheilor de criptare pentru algoritmul HEA i-o trimite, aplicația de retenții criptează datele solicitate de aplicația de raportare și i le trimite acesteia.
Aplicația de raportare procesează datele criptate și le trimite utilizatorului ca răspuns la solicitarea sa.
Agentul instalat pe stația de lucru a utilizatorului se autentifică cu rețeaua internă a companiei.
Odată autentificat, agentul obține cheia de decriptare pentru algoritmul HEA folosit la pasul 5 de aplicația de retenții.
Agentul instalat la nivelul browser-ului stației de lucru decriptează informația primită de la aplicația de raportare.
Flux informațional se realizează conform figurii de mai jos:
Fig. 4.12: Procesul de securizare al comunicației în arhitecturi hibride
Pentru a minimiza riscul asociat cu pierderea datelor sensibile sau a folosirii neautorizate ale acestora, am folosit următoarea abordare:
Datele stocate în aplicația de retenții sunt criptate folosind un algoritm puternic de criptare, sincron care oferă avantajele unei procesări rapide a algoritmului de decriptare.
Existența unui sistem dedicat de gestiune și generare a cheilor de criptate folosit de algoritmul simetric 3 DES care comunică cu sistemul de retenții ori de câte ori acesta trebuie să se realizeze procesul de decriptare sau criptare de date. Datorită faptului că ambele sisteme se află în rețeaua companiei, nu există niciun algoritm de autentificare implementat între ele, considerându-se a fi o comunicație de încredere. Acest sistem este cel care oferă sistemului de retenții cheia potrivită de decriptare, ținând cont de următoarele aspecte:
Momentul de timp la care au fost ultima dată alterate datele
Contextul din care au fost modificate datele
Tipul de date modificate
Aplicația de retenții expune un web service SPML [97] care permite altor aplicații aflate atât în interiorul companiei cât și în afara lor să acceseze datele aplicației. Web service-ul are implementat un mecanism de autentificare.
Aplicația de raportare din cloud se autentifică la aplicația de retenții ori de câte ori această solicită date din interiorul companiei.
Pentru integritatea datelor în tranzit între serviciul cloud și aplicația de retenții am propus folosirea protocolului HTTP peste TLS, așa cum este descris în [98].
După realizarea cu succes a procesului de autentificare, datele din aplicația de retenții sunt decriptate local și criptate folosind algoritmul HEA.
Toate cheile de criptare HEA sunt stocate în interiorul companiei.
Datele criptate folosind algoritmului homomorfic sunt transferate apoi către aplicația de raportare pentru ca aceasta să le proceseze și să le ofere utilizatorului care le-a solicitat.
Toate datele stocate în cloud sunt criptate, iar cheile de decriptare sunt stocate numai în sistemul dedicat aflat în interiorul companiei.
Utilizatorul final realizează două procese de autentificare: unul la aplicația de raportare din cloud și unul la rețeaua companiei, fapt ce atestă legitimitatea lui de a folosi acele date.
Principalele avantaje ale acestei abordări sunt:
Toate datele confidențiale sunt stocate criptat, chiar și cele din interiorul companiei, fapt ce asigură atât conformitatea cu standardele și reglementările în vigoare cât și un grad sporit de protecție împotriva atacurilor informatice
Există trei mecanisme folosite pentru asigurarea AAA:
Mecanismul de autentificare al aplicației cloud la aplicația de retenții
Două mecanisme de autentificare a utilizatorului final
Chiar dacă există un eveniment de atac soldat cu accesul neautorizat la datele stocate în aplicația cloud, atacatorul nu va putea dispune de aceste informații întrucât al doilea mecanism de autentificare a utilizatorului final va eșua și datele nu vor putea fi decriptate
Algoritmul de criptare sincronă folosit în procesul de criptare al datelor stocate în interiorul companiei asigură un timp de răspuns scurt pentru procesul de decriptare, oferind în același timp și un mecanism puternic de protecție pentru confidențialitatea datelor sensibile.
Componenta de audit a acestui proces
Acest proces oferă un mare beneficiu companiilor cu arhitectură hibridă pentru că pot demonstra prin intermediul interacțiunii dintre sisteme că mediul electronic este sigur întrucât asigură stocarea datelor în format criptat și comunicarea lor prin medii de comunicație ce folosesc protocoale securizate. Prin criptarea datelor în repaus atât în interiorul companiei cât și în cloud, se asigură că, în eventualitatea unor acțiuni malițioase, atacatorul nu va putea folosi acele date întrucât nu are cheia de decriptare a algoritmilor folosiți pentru criptarea lor. Totodată, prin implementarea la nivelul companiei a mecanismelor de criptare se pot obține controale severe asupra accesului la date.
Prin procesare logurilor care conțin toate sesiunile de comunicație între aplicația de retenții și cea de raportare, sistemul de audit poate controla activitatea utilizatorilor și poate descoperi comportamente inadecvate sau neconforme cu reglementările contractuale dintre furnizor și consumator. Astfel de statistici includ:
Performanțele aplicației cloud materializate în SLA-uri
Timpul mediu de răspuns al aplicației de raportare care permite propunerea unor soluții de optimizare a abordării folosite
Gradul de utilizare al aplicației de raportare
Timpul de răspuns mediu al aplicației de retenții ținând cont de toate activitățile de procesare pe care aceasta trebuie să le realizeze. Prin astfel de statistici se pot identifica oportunități de îmbunătățire a infrastructurii companiei, pentru optimizarea performanțelor.
Acest proces reprezintă o probă de audit pentru procesul de audit realizat la nivel de companie, întrucât stochează și loghează informații ce stau la baza factorilor decizionali atât cu privire la conformitatea companiei din perspectiva standardelor de securitate aplicabile datelor cu caracter confidențial, cât și cu privire la strategia de mentenanță și îmbunătățire a mediului electronic din interiorul companiei.
CAPITOLUL 5
AUDITUL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
5.1 DEFINIȚIA PROCESULUI DE AUDIT AL ARHITECTURILOR DE TIP “CLOUD COMPUTING”
Procesul de audit al arhitecturilor de tip cloud computing reprezintă practica prin care se asigură respectarea anumitor standarde, metode și practici aplicabile acestui tip de arhitectură [74]. În funcție de tipul de audit, auditorul examinează gradul de conformitate cu criteriile de audit stabilite. În procesul de audit al arhitecturilor de tip cloud computing trebuie să se înțeleagă mai întâi necesitățile de business ale companiei analizate, iar apoi trebuie analizate sistemele și procesele tehnice care implementează aceste cerințe [75]. Pe baza acestora, echipa de audit va defini obiectivele procesului de audit și mecanismele de control ale acelor procese care urmează a fi analizate în procesul de auditare.
Arhitecturile de cloud implementează modele de securitate specifice, care, plecând de la conceptele din arhitecturile tradiționale [76], se materializează în mecanisme specifice [77]. Aceste modele, din perspectiva securității includ:
Securizarea la nivel de arhitectură
Securizarea la nivel de date
Securizarea la nivel strategic prin implementarea best practice-urilor existente
Evaluarea securității
De aceea, se observă în cadrul arhitecturilor de tip cloud computing o tendință de adoptare a framework-urilor de control folosite în sistemele tradiționale [78] (cum ar fi cele furnizate de NIST sau ISACA). Aceste framework-uri sunt implementate la nivelul furnizorului de servicii cloud și sunt oferite consumatorilor. Cu toate că aceste modele oferă contextul potrivit procesului de control al arhitecturilor cloud, ele trebuie adaptate pe caracteristicile specifice ale acestui tip de arhitectură.
Există o serie de aspecte și scenarii în care procesul de audit al unei arhitecturi cloud diferă esențial de cel folosit în cazul unei arhitecturi tradiționale [74], cum ar fi:
Există scenariile în care migrarea unui sistem din arhitectura tradițională către cea de tip cloud nu implică, în mod automat, și migrarea mecanismelor de securitate și control pe care aceasta le avea în arhitectura tradițională. Un exemplu pentru acest scenariu îl reprezintă cazul în care sistemul era protejat în arhitectura tradițională prin mecanisme de control eficiente la nivel de rețea (LAN). În arhitecturile tradiționale există foarte multe aplicații care nu au datele criptate în mediul lor de stocare sau care au mecanisme de autentificare și acces slabe întrucât sunt considerate a fi sigure pentru că se află în interiorul companiei. Odată migrate aceste aplicații către arhitecturi de tip cloud, datele sensibile sunt transportate către spațiul de stocare al furnizorului prin Internet, ceea ce înseamnă că lipsa criptării și a mecanismelor puternice de autentificare și acces poate duce la compromiterea integrității datelor – atât a celor în tranzit cât și a celor stocate.
Sistemele dezvoltate in-house vor avem același nivel de securitate ca cel pe care îl au în interiorul companie, însă există situații în care compania proprietară a acestor tipuri de sisteme nu este conștientă de gradul sporit de risc pe care aplicațiile in-house îl au. Pentru a exemplifica acest scenariu ne putem gândi la aplicațiile in-house care nu sunt testate suficient pentru scenariile de externalizare a aplicației. Aceste teste trebuie să includă: teste contra vulnerabilităților comune Internetului, teste contra cross-site scripting, data-breaches, botnets și worm-uri. De asemenea aceste tipuri de aplicații trebuie să oferă mecanisme sigure pentru autentificare, acces și monitorizare.
Soluțiile de Identity Management menite să ofere companiei un spațiu central de stocare a identităților companiei care să fie folosit pentru autentificarea utilizatorilor în sistemele folosite pot deveni foarte complexe și pot introduce riscuri suplimentare prin sporirea gradului de complexitatea. Pentru a adresa aceste riscuri se pot introduce mecanisme suplimentare de control a accesului, însă acestea trebuie testate suficient pentru a acoperi o arie cât mai largă de scenarii posibile.
Securizarea dispozitivelor finale [79] – acest aspect devine mai important întrucât dispozitivele nu mai sunt securizate la nivel de rețea prin firewall-uri. Se întâmplă deseori la nivel de companie ca utilizatorii finali ai echipamentelor să dezactiveze firewall-uri setate pe mașinile lor pentru că se așteaptă să fie protejați la nivel de infrastructură a companiei. În astfel de cazuri, calculatoarele respective sunt compromise când încearcă să aibă acces legitim la aplicațiile cloud.
Serverele care găzduiesc aplicațiile cloud sunt în mentenanța furnizorului și sunt testate și upgradate folosind o abordare generică, ceea ce le face pe acestea pasibile de generare de erori în cazul unor sisteme specifice. Ca atare, procesul de audit al aplicațiilor din cloud trebuie să realizeze și comunicarea strânsă între consumator și furnizor astfel încât să se asigure diminuarea acestor situații.
Mediile cloud folosite modifică esențial procesul de audit care pentru arhitecturile tradiționale era mărginit de limitele rețelei companiei. Trebuie să se analizeze atent comunicația între furnizorii de servicii cloud și rețeaua internă a companiei. Acest fapt poate duce la îmbunătățirea metodelor de control și monitorizare existente în companie.
Cei mai mulți dintre auditori consideră că infrastructura cloud este asemănătoare cu cea tradițională, însă există anumite domenii pe care trebuie să se pună accent în arhitecturile cloud și care trebuie îmbunătățite față de arhitecturile tradiționale. Acestea sunt: controlul accesului la aplicații, procesul de autorizare, framework-ul de control. În procesul de auditare trebuie să se țină cont de funcționalitățile de business care sunt migrate către arhitecturi de tip cloud atât din perspectiva implementării lor cât și din perspectivă operațională – aceea de a oferi suport pentru aplicațiile respective.
Există domenii de audit care pot introduce riscuri suplimentare și care trebuie analizate suplimentar în arhitecturi de tip cloud. Acestea includ:
Latență în comunicarea dintre rețeaua internă a companiei și cea a furnizorului de cloud.
Notificări în caz de acces neautorizat la datele stocate la furnizorul de cloud.
Legi internaționale privind stocare, accesarea și procesarea anumitor date cu caracter confidențial – aceste legi au impact în situațiile în care furnizorul de cloud are data center-uri în mai multe arii geografice.
Procesul de audit în cloud trebuie să se supună acelorași principii de audit ca și procesul de audit din infrastructuri standard [80], printre care se numără: imparțialitatea și obiectivitatea echipei de audit în analizarea conformității arhitecturii cloud, independența echipei de audit, principiile practice profesionale de audit, competența tehnică de auditare, redactare conformă a rapoartelor de audit.
Procesul de audit în cloud îmbracă diferite forme, după cum el adresează un anumit model de serviciu: Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS). Diferențele fundamentale însă între procesele de audit vor fi la nivel de model de arhitectură cloud: cloud public, cloud privat, cloud hibrid pentru că trebuie analizate contractele realizate între furnizor și consumator și de cele mai multe ori, și aranjamente și clauze adiționale pentru respectarea standardelor și reglementărilor juridice atașate contractului inițial. Mai mult, deoarece folosirea arhitecturilor de tip cloud reprezintă o extensie în Internet a rețelei companiei, toate modelele cloud oferă diferite mecanisme și controale de audit care trebuie analizate și considerate de către echipa de audit pe durata procesului de audit.
5.2 FRAMEWORK-URI DE CONTROL PENTRU ARHITECTURI DE TIP CLOUD
Odată cu decizia de migrare către arhitecturile cloud atât auditorii interni cât și cei externi trebuie să ia în considerare nu numai considerentele de business [81], dar și riscurile pe care astfel de schimbări strategice le generează. Framework-ul de control și conformitate pentru arhitecturi de tip cloud nu este încă bine definit și structurat, considerându-se că framework-urile existente pentru arhitecturile tradiționale reprezintă un punct de plecare bun pe baza cărora se poate dezvolta o strategie personalizată în funcție de specificitatea fiecărui mediu supus auditului. Există alianțe și organizații care au investit în standardizarea conceptelor privind securitatea în arhitecturi de tip cloud, printre care și CSA al cărui model de referință l-am expus în capitolul 2. Toate acestea au puncte comune în ceea ce privește procesul de audit al arhitecturilor de tip cloud și formulează recomandări comune, printre care:
Sistemele găzduite în arhitecturi de tip cloud nu pot fi protejate folosindu-se aceleași mecanisme ca în cazul sistemelor din arhitecturi tradiționale. De cele mai multe ori, controalele de securitate și de respectare a standardelor și reglementărilor juridice trebuie mutate mai aproape de sisteme și de locul de stocare al datelor [82].
De cele mai multe ori auditorii sunt puși în situația de a consolida și adapta controalele din arhitecturile tradiționale întrucât acestea nu pot fi decomisionate fără un motiv puternic. Totuși, trebuie să existe un echilibru între riscurile pe care o organizație și le asumă din cauza neacoperirii întregii varietăți de scenarii cu controalele de securitate și realizarea multor mecanisme de monitorizare și control costisitoare care adresează doar cazuri excepționale și foarte rare [83].
Trebuie implementate noi controale și îmbunătățite cele existente în următoarele domenii: monitorizarea de evenimente, gestiunea identităților, securitatea fizică, securizarea mediilor virtuale [84].
În toate procesele de audit trebuie să se înțeleagă foarte bine scopul – acesta cuprinde atât criteriile de audit folosite cât și definirea granițelor mediului analizat. Echipa de audit trebuie să înțeleagă foarte bine topologia mediul supus auditării deoarece arhitectura cloud va produce modificări în arhitectura companiei analizate prin extinderea acesteia în Internet. Astfel, vor fi introduse conexiuni cu dispozitivele din rețeaua internă, cu rețelele partenerilor și pot fi situații în care să apară conexiuni între furnizori diferiți de cloud.
Există mai multe abordări pentru adresarea acestor aspecte, unele dintre ele propun rezolvarea unora dintre provocări direct la nivelul furnizorilor de cloud prin certificarea acestora ca sisteme de încredere, cu un grad sporit de monitorizare în raport cu standarde de securitate existente. În această privință, există furnizori de cloud care au început să dezvolte medii de control pentru conformitatea cu standardele folosite de industrii specifice, cum ar fi: SAS 70, Payment Card Industry (PCI), Sarbanes-Oxley (SOX), Federal Information Security Act (FISMA) etc.
5.2.1 ENISA Cloud Risk Assessment
ENISA (European Network and Information Security Agency) este o organizație care are menirea de a oferi recomandări cu privire la diferite aspecte de securitate. În Noiembrie 2009, această organizație a realizat analiza riscurilor implicate de arhitecturile de tip cloud punctând cele mai semnificative provocări din acest domeniu, clasificate în funcție de aria funcțională pe care ele se manifestă.
Plecând de la cele mai stringente riscuri, [85] prezintă principalele avantaje pe care o arhitectură de tip cloud le poate aduce consumatorului de astfel de servicii. Acestea se materializează în:
Beneficiile oferite de scalarea mecanismelor de securitate – acestea pot fi explicate prin simplul fapt că orice mecanism implementat la scară largă devine mai puțin costisitor. De aceea, cu aceleași investiții, în arhitecturile de tip cloud se asigură un grad de protecție sporit.
Securitatea ca diferențiator în piață – securitatea este o prioritate pentru mulți consumatori de cloud și ca atare majoritatea vor alege furnizorii de servicii cloud pe considerente de reputație în domeniul confidențialității, integrității și rezistenței serviciilor de securitate oferite de furnizor. Acesta este un motiv foarte bun pentru ca furnizorii de cloud să își îmbunătățească practicile de securitate.
Interfețe standardizate pentru serviciile de securitate – furnizorii de servicii cloud oferă interfețe standardizate bazate pe standarde open pentru a gestiona serviciile de securitate oferite la nivel de arhitecturi cloud.
Scalare rapidă și inteligentă a resurselor – abilitatea furnizorilor de cloud de a aloca dinamic resurse suplimentare pentru filtrarea traficului, pentru mecanismele de autentificare și criptare, în funcție de necesar, oferă un grad sporit de elasticitate și protecție.
Audit și monitorizare – furnizorii de cloud oferă ca și serviciu punerea la dispoziția echipelor de audit a imaginilor mașinilor virtuale folosite în cloud, fără a fi necesară oprirea sistemelor din funcționare. De asemenea pot oferi un spațiu de stocare mai puțin costisitor pentru loguri, permițând astfel detalierea amănunțită a evenimentelor stocate în log, fapt ce permite îmbunătățirea proceselor de monitorizare și control a sistemelor.
Administrarea în mod eficient a imaginilor virtuale ale mașinilor folosite de clienți – acest avantaj are două aspecte: pe de o parte este avantajul obținerii rapide a unei imagini default de sistem care a fost testată și a ajuns la maturitatea necesară folosirii ei pentru un sistem sensibil, pe de altă parte, consumatorul de cloud nu trebuie să se mai preocupe de aplicarea patch-urilor sistemelor de operare sau anumitelor componente hardware, acestea fiind responsabilitatea furnizorului de cloud care are oameni specializați pe aceste procese.
Beneficiile concentrării resurselor – acestea se traduc în costuri scăzute pentru consumator, atât a componentelor hardware cât și a mecanismelor de securitate existente.
Riscuri cele mai importante care au fost subiectul acestui studiu și care trebuie adresate fie de furnizorul de cloud, fie de consumator prin impunerea unor prevederi contractuale mai riguroase sunt [86]:
Lipsa guvernanței este cauzată de specificul arhitecturilor de tip cloud de a controla alocarea resurselor sistemelor și accesul la datele stocate. Pot exista cazuri în care SLA-urile specificate în contractul dintre furnizor și consumator să nu acoperă necesarul de guvernanță al companiei-client fapt ce duce la diminuarea securității.
Blocarea datelor la furnizorul de cloud este cauzată de faptul că în prezent există puține mecanisme, proceduri și instrumente care să asigure portabilitatea datelor, aplicațiilor și serviciilor existente într-un serviciu cloud aparținând unui furnizor specific. Acest risc se manifestă prin dificultatea migrării de la un furnizor la altul, sau de la arhitecturi cloud, la arhitecturi tradiționale.
Isolation Failure este cauzată de caracteristica de multi-tenancy a sistemelor cloud care partajează resursele fizice între diferiți consumatori. Acest domeniu de riscuri acoperă atacurile de tip “guest-hopping” care se manifestă prin disfuncționalitatea mecanismelor de separare a spațiilor de stocare, de rutare, de memorie între consumatori diferiți ce partajează aceleași resurse fizice.
Riscurile de Conformitate sunt cauzate de necesitatea investițiilor din partea furnizorilor în vederea certificării serviciilor lor pe anumite standarde de securitate pentru ca organizațiile consumator să își poată păstra propriile certificări existente pe arhitectura tradițională.
Compromiterea gestiunii interfețelor cu consumatorul este cauzată de necesitatea Internetului în vederea accesării acestor mecanisme de integrare, fapt ce duce la sporirea traficului extern care poate ajunge la supra-solicitare. Acest risc este augmentat de situațiile în care este necesar și accesul la distanță la anumite resurse precum și de vulnerabilitățile existente în browser-ele web.
Riscurile raportate la protejarea datelor sunt cauzate de dificultățile întâmpinate de consumatori, în rolul lor de control asupra folosirii datelor stocare la furnizorul de cloud, de a monitoriza mecanismele de manipulare și utilizare a datelor astfel încât să fie siguri că acestea respectă prevederile juridice din domeniul în care compania activează. Există totuși o serie de furnizori de servicii cloud care pune la dispoziția clienților lor procedurile de procesare și securizare a datelor precum și controalele existente pentru monitorizarea datelor.
Riscurile legate de ștergerea datelor printr-un proces nesigur sau incomplet sunt cauzate de mecanismele existente de ștergere a informațiilor digitale, chiar și la nivelul arhitecturilor tradiționale: când se vrea ștergerea unor date, acestea nu sunt, de obicei, șterse fizic de pe spațiul de stocare. În plus, mecanismele de ștergere a datelor stocate în cloud sunt mai expuse procesării incomplete deoarece pot exista copii ale acestora pe discuri neaccesibile, sau, discurile pe care sunt stocate sunt partajate și de alți clienți, fapt ce face imposibilă ștergerea discului. Aceste riscuri sunt mai pronunțate pentru sistemele care folosesc resurse partajate cu alte sisteme, decât în cazul celor cu dispozitive hardware dedicate.
Riscurile legate de atacuri din interior sunt cauzate de specificul arhitecturilor de tip cloud care presupune crearea unor roluri puternice pentru furnizorul de cloud cu grad foarte mare de risc. Aceste pot fi: administrator de sistem, furnizorii de servicii de securitate etc.
Studiul oferă studii de caz practice menite să ajute auditorul în evaluarea unei companii care implementează sau utilizează servicii cloud și punctează principalele recomandări prin clasificarea lor în:
Măsuri de asigurare pentru consumatorii de cloud care trebuie realizate sub formă de formulare pe care furnizorul de cloud trebuie să le completeze, în care sunt specificate măsuri eficiente de securizare împotriva atacurilor informatice. Furnizorul de cloud trebuie să bifeze mecanismele, procedurile și controalele pe care le are implementate astfel încât, pe baza acestor răspunsuri, consumatorul să poată:
Evalua riscul adopției serviciilor cloud
Compara diferite oferte de la mai mulți furnizori cloud
Obține asigurări din partea furnizorilor de cloud că răspunsurile oferite de aceștia sunt în concordanță cu realitatea
Reduce riscurile de nealiniere a înțelegerii consumatorului și a furnizorului de cloud cu privire la oferirea unor anumitor servicii.
Recomandări juridice – majoritatea problemelor și controverselor juridice între consumatorii de cloud și furnizori se rezolvă prin formularea adecvată a contractului de servicii dintre aceștia. Acest contract este obținut, în general, în urma alegerii consumatorului între mai mulți furnizori, ca atare subiectul negocierilor celor două părți pot fi doar anumite aspecte specifice, contractul fiind specific furnizorului de servicii.
Recomandări pentru viitorii consumatori de cloud pentru a îmbunătăți mecanismele de securitate existente în cloud. Acestea sunt materializate în:
Obținerea încrederii între furnizorul de servicii cloud și consumator. Scepticismul pentru arhitecturile de tip cloud se hrănește în primul rând din imposibilitatea răspunderii la întrebările adresate de clienții cloud în legătură cu localizarea datelor stocate în aplicațiile cloud și apoi din cumulul de riscuri pe care o astfel de arhitectură îl manifestă.
Protejarea datelor în mediile foarte mari care încorporează granițe internaționale în vederea combaterii acțiunilor criminale și atacurilor informatice și manipulării și gestionării eficiente a incidentelor.
Interoperabilitatea sistemelor, elasticitatea și monitorizarea serviciilor cloud astfel încât să se diminueze riscurile ce privesc blocarea datelor în sistemele anumitor furnizori sau imposibilitatea renunțării la serviciile unui furnizor de cloud din cauza incompatibilității modelelor de date și aplicațiilor folosite ce acesta cu alte servicii similare de cloud aparținând unor alți furnizori.
Figura de mai jos descrie reprezentarea grafică a abordării folosită de ENISA în lucrarea [85] în vederea evaluării riscului adopției arhitecturilor de tip cloud:
Fig. 5.1: Analiza riscului adopției arhitecturilor de tip cloud în viziune ENISA
Așa cum se poate observa, studiul structurează aspectele de baza în auditul în cloud pe trei direcții interdependente, așa cum au fost prezentate în această secțiune:
Beneficii
Riscuri
Recomandări
5.2.2 COBIT
COBIT 5 reprezintă un framework implementat de ISACA [15] pentru standardizarea măsurilor de guvernanță și gestiune a componentelor IT din cadrul unei organizații. Acest standard adresează în principal arhitecturi tradiționale, dar conține principii de guvernanță care pot fi aplicate și în arhitecturi de tip cloud. COBIT definește obiectivele controalelor din arhitectura IT care pot fi ajustate pe baza analizei riscului, pentru a se defini rezultatele clare pe care acel control trebuie să le aibă în arhitectura IT. Acest framework a ajuns la maturitate prin îmbunătățiri succesive aduse de-a lungul versiunilor în care a fost publicat și a fost creat pe baza multor standarde de securitate existente în practica digitală. COBIT se bazează pe cinci principii fundamentale.
Implementarea necesităților părților interesate – acest principiu descrie obiectivele COBIT din perspectiva necesităților din domeniul IT care formalizează în interiorul unei companii necesitățile de business ale acesteia. Orice obiectiv la nivel de companie se mapează direct sau indirect unui obiectiv IT, iar obiectivele IT se pot realiza prin folosirea optimă a proceselor și a mecanismelor existente. Combinarea obiectivelor la nivel de companie cu cele din domeniul IT aferente lor, care le fac realizarea posibilă și implementabilă, se numește, în termenii ISACA, Cascada de obiective.
Adresarea companiei end-to-end – acest principiu descrie abordarea COBIT de a adresa aspectele legate de guvernanța și gestiunea componentelor IT prin cuprinderea tuturor funcțiilor și proceselor din interiorul companiei.
Aplicarea unui framework unic, integrat – acest principiu descrie modalitatea prin care COBIT reușește să integreze toate procesele și funcțiile unei companii într-un singur framework.
Folosirea unei abordări holistice – acest principiu prezintă guvernanța și gestiunea IT într-o modalitate sistemică, fiind controlată de un model generic propus de cei de la ISACA. Acest model se bazează pe șapte categorii de activatoare [15]:
Principii, politici și framework-uri existente – acestea ajută la traducerea comportamentului dorit în recomandări practice în viața de zi cu zi
Procese – acestea descriu un set organizat de practici și activități realizate în vederea obținerii unor anumite obiective și produc un set de ieșiri care ajută la realizarea obiectivelor IT.
Structurile organizaționale – acestea sunt factorii de decizie într-o companie
Cultură, etică și comportamentul angajaților – aceste reprezintă un factor important în succesul implementării unui proces eficient de guvernanță și gestiune IT și este adesea desconsiderat.
Informații – acestea sunt propagate în interiorul oricărei companii și includ totalitatea datelor și informațiilor create și utilizate într-o companie. Informațiile sunt necesare pentru a putea funcționa orice companie, iar la nivel operațional, informațiile reprezintă cheia de definiție a companiei însăși.
Servicii, infrastructură și aplicații – această categorie include infrastructura, tehnologiile și aplicațiile care oferă companiei putere de procesare și servicii IT.
Oameni, abilități și competențe – aceste activatoare sunt relaționate direct cu oamenii de care este nevoie pentru îndeplinirea cu succes a activităților întreprinse pentru obținerea obiectivelor. De asemenea, tot în această categorie sunt incluse și calitățile oamenilor de a lua decizii corecte, oportune și inspirate.
Unele dintre principiile prezentate mai sus, reprezintă de asemenea resurse în interiorul unei companii. Acestea sunt:
Informații – acestea trebuie gestionate ca resurse, dar reprezintă și factori de activare dacă ne gândim la rapoarte și informații structurate și prezentate de aplicațiile de Business Intelligence
Servicii, infrastructură și aplicații
Oameni, abilități și competențe
Figura de mai jos prezintă modelul propus de COBIT pentru descrierea factorilor de activare [15]:
Fig. 5.2:COBIT – Folosirea unei abordări holistice [15]
COBIT propune un model generic de activare al procesului de gestiune și guvernanță a componentelor IT care se bazează pe patru dimensiuni:
Părțile interesate – fiecare activator are o parte interesată care joacă un rol activ în exploatarea acelui activator și care are un interes în eficientizarea activatorului. Necesitățile părților interesate se traduc în obiective la nivel de companie, care la rândul lor se traduc în obiective la nivel IT.
Obiective – fiecare activator are o serie de obiective, iar valoarea dată de activator companiei constă în îndeplinirea obiectivelor sale. Obiectivele se pot defini ca rezultate așteptate în urma implementării unui activator sau aplicarea / operarea activatorului însuși. Obiectivele activatoarelor reprezintă ultima etapă în definirea Cascadei de obiective și pot fi clasificate în:
Calitate intrinsecă – calitatea activatoarelor de a lucra corect și obiectiv și de a oferi rezultate obiective, cu grad sporit de acuratețe
Calitate contextuală – calitatea activatoarelor de a funcționa conform scopurilor pentru care au fost implementate în contextul în care ele operează.
Acces și securitate – calitatea activatoarelor de a avea rezultate securizate la nivel de acces
Controlul ciclului de viață al activatoarelor – ciclul de viață al activatoarelor este alcătuit din următoarele etape: planificare, design, implementare/ dezvoltare/ creare/ achiziție, folosire/ operare, evaluare/ monitorizare, updatare/ decomisionare
Recomandări cu privire la activatoare – pentru fiecare activator în parte există o serie de recomandări si best practice-uri disponibile materializate în exemple de utilizare, standarde, framework-uri etc.
Figura de mai jos prezintă modelul generic propus de ISACA pentru activatoare:
Fig. 5.3: COBIT – Model Generic [15]
Separarea procesului de guvernanță de cel de gestiune [87] – acest principiu prezintă diferențele între cele două procese și modalitățile de interconectare între ele. Procesul de guvernanță asigură că necesitățile, condițiile și opțiunile părților interesate sunt analizate și evaluate pentru a se defini obiectivele companiei. În procesul de definire a obiectivelor companiei se setează priorități și factori decizionali folosiți în procesul de guvernanță. De asemenea, în definirea obiectelor se stabilesc și criteriile de monitorizare a performanței și gradului de realizare a obiectivelor stabilite.
Procesul de management reprezintă totalitatea activităților de panificare, construire, creare, realizare și monitorizare a activităților, în concordanță cu direcțiile stabilite în procesul de guvernanță pentru a se îndeplini obiectivele companiei.
Figura de mai jos reprezintă modelul de referință al procesului de guvernanță și management al componentelor IT:
Fig. 5.4:Domenii principale în procesul de gestiune și guvernanță a componentelor IT [11]
Pe baza acestor principii, ISACA a realizat un model de procesare a tuturor capabilităților unei companii din perspectiva guvernanță și gestiune de componente IT.
Figura de mai jos prezintă modelul procesului de evaluare a capabilităților proceselor IT:
Fig. 5.5: Modelul procesului de evaluare a capabilităților proceselor IT [15]
Există șase niveluri de capabilitate pe care un proces le poate avea, incluzând stadiul de “proces incomplet” dacă operarea lui nu generează scopul acelui proces:
Proces Incomplet – la acest nivel se află procesele care nu sunt implementate sau procesele a căror implementare nu ating obiectivele pentru care procesul a fost creat. La acest nivel există foarte puține realizări sistematice în ceea ce privește scopul procesului
Proces executat – procesul a fost executat și și-a atins obiectivele pentru care a fost creat
Proces gestionat – procesul executat la nivelul anterior este implementat folosind o abordare care permite gestionarea lui, iar rezultatele lui pot fi stabilite, controlate și întreținute.
Proces stabilit – procesul descris la nivelul anterior este implementat folosind un proces definit capabil să obține rezultate.
Proces predictibil – procesul descris la nivelul anterior este operat în limitele definite pe parcursul proiectării procesului în vederea obținerii rezultatelor scontate
Proces optimizat – procesul descris la nivelul anterior îmbunătățit în mod continuu pentru a se obține obiectivele relevante pentru care el a fost construit și definit.
Fiecare nivel de capabilitate poate fi obținut numai când nivelul înaintea lui a fost atins cu succes. Există o diferență fundamentală între procesul care a atins nivelul de capabilitate 1 și procesul care a atins niveluri de capabilitate superioare acestuia deoarece, la nivelul 1 trebuie ca procesul să fi atins atributele de performanță definite pentru el. Acest lucru înseamnă că procesul a fost executat cu succes și rezultatele obținute în urma execuției sunt cele definite de companie. Nivelurile superioare adaugă atribute noi procesului analizat.
5.2.3 Programul de auditare și gestionare a arhitecturilor de tip cloud computing
ISACA a realizat, de asemenea, “Programul de auditare și gestionare a arhitecturilor de tip cloud computing” [57] care descrie o metodă de analizare a mecanismelor de control oferite de furnizorii de cloud. Această analiză este realizată de echipa de audit în vederea stabilirii nivelului de conformitate cu obiectivele procesului de control impuse la nivelul companiei. Acest mecanism este unul sofisticat care poate fi folosit pentru analizarea aspectelor contractuale dintre consumatori și furnizori și pentru controlul problemelor întâlnite în arhitecturi cloud, dar care nu asumă existența mecanismelor de guvernanță la nivelul de business.
Acest instrument de analiză și evaluare este realizat pe baza COBIT [15] și COSO (Committee of Sponsoring Organizations of the Treadway Commission). COSO [32] oferă un framework de control intern care permite organizațiilor să își evalueze gradul de conformitate cu standardele și reglementările legislative din domeniile în care activează. În modelul COSO, devenit în 2004 ERM (Enterprise Risk Management) [88] sunt cuprinse opt componente:
Mediul intern – acesta este format din totalitatea percepțiilor și activităților companiei care se materializează în modul cum este perceput riscul la nivelul angajaților, incluzând filosofia de tratare a riscului, gradul de asumare al riscului, valorile de integritate și etică profesionale și mediul de lucru în care personalul își desfășoară activitatea.
Setarea obiectivelor – obiectivele trebuie să existe înainte ca procesul de gestionare să evalueze gradul lor de realizare și să analizeze riscurile care pot duce la neîndeplinirea lor. Gestiunea riscului la nivelul companiei asigură că procesul de management cuprinde un proces de setare a obiectivelor, și că obiectivele alese ca fiind definitorii pentru companie sunt aliniate cu misiunea companiei și sunt în concordanță cu gradul de asumare al riscului.
Identificarea evenimentelor – evenimentele interne și externe care pot afecta obținerea obiectivelor trebuie să fie identificate, prin diferențierea lor între riscuri și oportunități. Oportunitățile sunt îndreptate către strategia companiei sau către procesul de stabilire a obiectivelor.
Evaluarea riscului – riscurile sunt analizate, prin evaluare probabilității de producere ale acestora și a impactului pe care îl produc. Această evaluare are drept scop stabilirea unui proces de adresare a riscurilor și de diminuare a lor. Domeniile supuse riscurilor sunt evaluate incremental, pe baza evaluării anterioare.
Răspunsul la risc – managementul este cel care alege ce răspunsuri vor fi oferite riscurilor întâmpinate prin dezvoltarea unor seturi de acțiuni menite să alinieze riscurile la care este expusă compania cu gradul de asumare al riscului și cu toleranța la risc a companiei. Acestea pot fi: evitarea riscului, acceptarea riscului, reducerea riscului, partajarea riscului.
Activități de control – acestea constau în politici și proceduri setate și implementate în vederea asigurării răspunsurilor la riscuri.
Informații și comunicație – informațiile relevante trebuie identificate, capturate și comunicate într-o manieră eficientă (ceea ce se traduce prin comunicarea într-o formă relevantă și intuitivă într-un timp util) către oamenii care le procesează în vederea realizării activităților de răspuns la riscuri.
Monitorizare – toate activitățile întreprinse în companie sunt monitorizate în mod continuu prin procese de evaluare, activități de gestiune etc.
Aceste componente, împreună cu modelul definit de COBIT reprezintă baza Programului de auditare și gestionare a arhitecturilor de tip cloud computing [57] care are drept obiective:
Stabilirea unor mecanisme de evaluare a controalelor interne folosite de către furnizorii de cloud pe care părțile interesate le pot folosi în procesul de audit
Identificarea deficiențelor în procesul de control realizat de consumatorul de cloud furnizorului de servicii
Stabilirea unor mecanisme de evaluare a calității serviciilor contractate de la furnizorul de cloud și de atestare a mecanismelor de control intern implementate de furnizor în arhitectura cloud
Procesul de audit este structurat pe următoarele domenii:
Gestiunea identităților – dacă sistemul de Identity Management din companie este integrat cu serviciile cloud contactate [89]
Gestiunea incidentelor de securitate – pentru gestiunea și tratarea incidentelor de securitate petrecute la nivelul arhitecturii cloud
Securitatea rețelei – aceasta este privită din perspectiva punctului de acces la internet, necesar utilizării serviciilor cloud
Dezvoltarea sistemelor implementate în arhitectura cloud [90]
Managementul de proiect
Gestiunea Riscului IT
Gestiunea datelor transmise și stocate în cloud
Gestiunea vulnerabilităților
[50] prezintă procesul de guvernanță in arhitecturi de tip cloud prin combinarea mai multor framework-uri existente în acest domeniu:
Risk IT [91] – reprezintă un standard implementat de ISACA pe baza următoarelor principii:
Framework-ul de evaluare a riscului este întotdeauna conectat la obiectivele de business
Alinierea procesului de management cu riscurile IT cauzate de deciziile și necesitățile de business
Realizarea echilibrului între costuri și beneficii în procesul de gestionare a riscurilor IT
Promovarea comunicării corecte și deschisă a riscurilor din domeniul IT
Stabilirea nivelului de toleranță la risc corect ținând cont de factori operaționali în gestiunea riscului
Gestiunea riscului este un proces continuu
Figura de mai jos reprezintă framework-ul propus de ISACA în [91]:
Fig. 5.6: Framework-ul Risk IT [14]
Val IT [92] reprezintă un framework care permite organizațiilor să evalueze valoarea în business adusă de investițiile din IT. Acest framework este creat pentru a se integra cu COBIT și definește un set de principii de guvernanță, procese și practici pentru evaluarea gradului de rentabilitate a investițiilor în domeniul IT. COBIT definește framework-ul necesar proiectării și livrării de servicii IT de înaltă calitate, iar Val IT stabilește criterii de evaluare a rezultatelor proceselor de guvernanță implementate folosind COBIT. Ca atare, Val IT oferă un mecanism de evaluare, optimizare și monitorizare a investițiilor în domeniul IT atât din perspectivă financiară cât și din perspective funcționale.
COBIT – prezentat în secțiunea anterioară
Framework-ul Risk IT pentru arhitecturi de tip Cloud
Riscul asociat migrării către arhitecturi de tip cloud trebuie inclus în planul de gestionare al riscului de la nivelul companiei. Impactul migrării la arhitecturi de tip cloud se manifestă în toate cele șase domenii ale riscului:
Strategie – la nivel strategic, compania trebuie să răspundă la următoarele întrebări: Poate departamentul de IT al companiei să execute nou program de migrare în cloud cu succes, fără depășirea timpului și bugetului alocate? Va aduce adopția cloud-ului beneficiile scontate? Va genera nemigrarea la cloud riscuri suplimentare în companie?
Mediul IT – la nivel de mediu IT, compania trebuie să răspundă la următoarele întrebări: Va oferi proiectul de cloud un mediu intuitiv și ușor de folosit utilizatorilor (fie că aceștia sunt angajați interni ai companiei, parteneri sau clienți)? Va adresa noul mediul cloud necesitățile de business ale companie și va fi capabil să acomodeze necesități definite după implementarea arhitecturii cloud?
Piața – la nivel de piață, compania trebuie să răspundă la următoarele întrebări: Va oferi arhitectura cloud utilizatorilor finali un mediu care să depășească performanțele oferite de competitori? Va reprezenta migrarea către arhitecturi cloud o experiență bună pentru utilizatorii existenți și cei noi?
Credit – la nivel de credit, compania trebuie să răspundă la următoarele întrebări: Va fi proiectul de migrare finalizat și apoi întreținut consumându-se doar bugetul estimat sau se vor depăși valorile preconizate?
Operațional – la nivel operațional, compania trebuie să răspundă la următoarele întrebări: Va oferi furnizorul de cloud suport pentru aplicațiile implementate în arhitecturile sale care să respectele standardele de performanță la nivel operațional existente în companie?
Conformitate – la nivel de conformitate, compania trebuie să răspundă la următoarele întrebări: Poate furnizorul de cloud demonstra respectarea standardelor și reglementărilor legale existente în domeniul în care activează compania?
Figura de mai jos reprezintă riscul asociat domeniul de IT în ierarhia riscului la nivelul companie [50]:
Fig. 5.7: Riscul în domeniul IT în ierarhia riscurilor la nivel de companie [14]
Modelul Val IT pentru arhitecturi de tip Cloud
Acest model este folosit în companiile care migrează către cloud pentru evaluarea valorii aduse de implementarea arhitecturilor de tip cloud. Această evaluare, împreună cu cea realizată folosind framework-ul Risk IT oferă companie raportul riscuri/beneficii introdus de adopția serviciilor de tip cloud computing.
Folosind o abordare structurată pe patru arii diferite, Val IT oferă o perspectivă holistică de cuantificare a valorii adusă de implementarea serviciilor cloud în arhitecturi tradiționale. Întrebările la care orice companie trebuie să răspundă în evaluarea gradului de rentabilitate introdus de contractarea serviciilor cloud sunt:
Este adoptarea arhitecturilor de tip cloud oportună situației companiei? Se va alinia inițiativa de migrare la cloud strategiei de business existente în companie? Prin analiza detaliată a acestor aspecte se pot descoperi beneficii financiare aduse de migrare precum și oportunități de creștere și inovare în domeniul businessului care au fost desconsiderate din motive financiare exprimate în costuri ridicate necesare pentru domeniul IT pentru ca acesta să poată susține inovațiile funcționale
Folosește compania procesul de migrare optim contextului în care acesta se află? Este modelul arhitectural potrivit modelului companiei sau trebuie adaptat prin acceptare unor măsuri de compromis? Trend-ul cloud computing oferă oportunitatea companiilor de a se dezvolta fără investiții mari la nivel IT.
Evoluează procesul de adopție al arhitecturilor de tip cloud conform principiilor practicilor? Sunt serviciile cloud implementate eficient? Migrarea către arhitecturi de tip cloud este o decizie de business care trebuie cântărită foarte bine înainte de a se lua. O modalitate eficientă de a realiza acest lucru este prezentată în capitolul 3 din această lucrare. Odată luată decizia de migrare, este foarte important ca tranziția să se realizeze conform unui proces determinat. Guvernanța și managementul sunt factori critici în schimbarea politicilor companiei și a proceselor de business, schimbări impuse de adopția arhitecturilor de tip cloud. În plus, trebuie definite metrici de raportare a statusului procesului de implementare pentru a evalua rata de succes a acestuia.
Oferă implementarea serviciilor cloud beneficiile scontate? Performanța și obiectivele trebuie stabilite înainte de tranziția către cloud. Este important să se cunoască necesitățile businessului din perspectivă disponibilitate, flexibilitate, scalabilitate, nivel de auditare etc. astfel încât, prin măsurarea acestor factori să se poată determina rata de succes a migrării către arhitecturi de tip cloud.
Figura de mai jos prezintă cele patru arii de analiză a framework-ului Val IT:
Fig. 5.8: Ariile adresate de framework-ul Val IT [92]
Cele patru domenii prezentate în figura anterioară trebuie analizate în raport cu mai mulți factori. Astfel, răspunsul la prima întrebare trebuie să se analizeze ținându-se cont de următoarele aspecte:
Gradul de aliniere al strategiei serviciilor cloud cu strategiile companiei
Consistența caracteristicilor serviciilor cloud contractate cu principiile de business ale companiei
Contribuția serviciilor cloud în strategia companiei din perspectiva îndeplinirii obiectivelor
Aportul optim de valoare, prin raportarea prețului serviciilor la un nivel acceptabil de risc
Răspunsul la cea de-a doua întrebare trebuie să se exprime după analizarea următorilor factori:
Existența unei înțelegeri clare și corecte asupra beneficiilor așteptate
Existența factorilor de monitorizare ai beneficiilor
Metrici relevante
Un proces efectiv de realizare a beneficiilor care cuprinde tot ciclul de viață al investițiilor economice
Răspunsul la cea de-a treia întrebare trebuie să se exprime după analizarea următorilor factori:
Existența unui proces de management eficient și disciplinat pentru gestiunea livrării și modificărilor ulterioare implementării
Existența resurselor tehnice și de business competente și disponibile pentru a livra capabilitățile cerute, schimbările la nivel organizațional necesare pentru exploatarea capabilităților implementate
Răspunsul la cea de-a patra întrebare trebuie să se exprime după analizarea următorilor factori relativi la investiție:
Alinierea acesteia cu arhitectura companiei
Consistența dintre aceasta și principiile companiei
Alinierea acesteia cu alte inițiative din interiorul companiei
[93] Oferă metodologia de fructificare a framework-ului Val IT într-o companie.
COBIT în arhitecturi de tip cloud
COBIT adresează controale dezvoltate pentru evaluarea riscurilor din domeniul IT. Aceste controale sunt clasificate în următoarele domenii:
Planificare și Organizare (PO) – asigură direcțiile de dezvoltare care trebuie urmate de soluția livrată și de serviciul livrat
Achiziție și Implementare (AI) – oferă soluții care apoi se transformă în servicii
Livrare și Suport (DS = Delivery and Support) – primește ca și intrare soluțiile și le face utile utilizatorilor finali
Monitorizare și Evaluare (ME) – monitorizează toate procesele pentru a se asigura că acestea urmează calea dorită
COBIT oferă șapte criterii ce trebuie analizate în raport cu informațiile existente în procesul de guvernanță și gestiune:
Eficacitate – informațiile sunt relevante și pertinente procesului de business și sunt livrate în timp util, asigurând consistența și corectitudinea datelor
Eficiență – informațiile sunt provizionate folosind gradul de utilizare optim al resurselor – cel mai productiv și economic
Confidențialitate – informațiile sensibile sunt protejate împotriva folosirii neautorizate
Integritate – informațiile sunt complete și prezintă acuratețe și sunt valide comparativ cu setul de valori definit în companie și cu așteptările acesteia
Disponibilitate – informațiile sunt disponibile ori de câte ori este nevoie de ele în procesele de business și sunt stocate întotdeauna sigur
Conformitate – compania este capabilă să adreseze procese care dovedesc respectarea standardelor, legilor, reglementărilor juridice și clauzelor contractuale aplicabile proceselor de business – acestea reprezintă criterii de business externe companiei
Fiabilitate – sistemele IT oferă procese de gestiune cu informații relevante care sunt utilizate în domeniul operațional
Mapare procesului de guvernanță în arhitecturi de tip cloud pe modelele COBIT, Risk IT și Val IT
Evaluarea riscului folosind doar framework-ul COBIT ar fi suficientă dacă aceasta ar adresa doar deciziile privind guvernanța departamentului de IT. Cu toate acestea, migrarea către cloud va cauza o schimbare fundamentală și în procesele de business, fapt ce impune implicarea businessului în analizarea riscurilor manifestate de adopția cloud-ului. Prezentarea evaluării riscului trebuie să se realizeze într-o manieră ușor de înțeles și de comunicat către toate departamentele afectate de această schimbare. Aici este etapa în care se folosesc framework-urile Risk IT și Val IT. Risk IT oferă un model de evaluare a riscului în IT bazat pe COBIT și pe ERM. Val IT oferă o abordare similară, prezentată însă din perspectiva investițiilor. Pentru realizarea procesului de evaluare a riscului introdus de contractarea serviciilor de tip cloud computing trebuie îndeplinite următoarele cerințe:
Cerințe Tactice – guvernanța companiei în proiectele cloud necesită cunoașterea reglementărilor existente atât la sursa datelor cât și la locul de stocare al acestora. Noi provocări juridice se conturează odată cu migrarea către cloud, de aceea trebuie să se acorde o atenție sporită procesului de negociere a termenilor contractuali utilizați cu furnizorul de servicii cloud
Reglementări în domeniul stocării și utilizării informațiilor digitale. Odată ce furnizorul de cloud stochează date din mai multe surse, aceste cerințe vor reprezenta o reală provocare ținând cont de faptul că spațiul fizic de stocare poate fi localizat în altă zonă geografică față de cea a consumatorului. Există reglementări aplicabile surselor de date, dar există și reglementări aplicabile spațiului de stocare al datelor. Obligația consumatorilor de servicii cloud este să se asigure că datele stocate și folosite în și de cloud respectă reglementările la nivel național și internațional privind confidențialitatea datelor medicale, financiare etc. Acesta este un alt domeniul în care framework-ul Risk IT oferă posibilitatea aprofundării reglementărilor specifice diferitelor industrii.
Problemele legale se raportează la soluționarea anumitor polemici cum ar fi: cine este proprietarul datelor consumatorului de servicii cloud, au furnizorii de servicii cloud certificări care dovedesc respectarea anumitor standarde și reglementări
Auditul intern trebuie să asigure cunoașterea furnizorului de cloud înaintea contractării lui, posibilitate de audit a sistemelor implementate în arhitecturi cloud prin stabilirea mecanismelor de control a securității implementate de furnizorul de cloud, asigurarea continuității serviciilor cloud, transparența politicilor de securitate și a proceselor implementate în soluțiile cloud pentru procesele de backup și cele de recovery.
Activități operaționale – acestea conțin activități de benchmarking la nivelul furnizorului de servicii cloud și analizarea celor mai bune oferte din acest domeniu. De asemenea în acest domeniu se pot analiza și SLA – urile incluse în contractul dintre consumator și furnizor. Factorii cheie care trebuie analizați sunt:
Panouri de monitorizare în timp real a performanțelor aplicațiilor dezvoltate în cloud, a mecanismelor de securitate și a procesului de gestiune a identităților
Nivelul de funcționalitate al sistemelor furnizorului de cloud materializat în timpul de funcționare în parametrii optimi (uptime)
Gradul de auditare al aplicației din perspectiva modificării sistemului de Identity Management folosit de serviciul cloud
Furnizorul ar trebui să analizeze împreună cu consumatorul practicile folosite pentru backup-ul sistemelor și pentru disaster recovery
Furnizorul trebuie să ofere referințe despre clienți existenți.
Contractele încheiate cu furnizorul și verificarea finală a SLA-urilor trebuie confirmate în toate procesele de adopție a arhitecturilor de tip cloud din perspectiva termenilor, condițiilor și SLA-urilor înscrise în înțelegere. De asemenea trebuie incluse toate clauzele necesare respectării procesului de audit impus de reglementările aplicabile în domeniul de funcționare al consumatorului de servicii cloud precum și cele relative la mecanismele de securitate implementate la nivelul furnizorului care au reprezentat factori decizionali substanțiali în alegerea furnizorilor respectiv.
5.2.4 CSA – Modelul de securitate în cloud
Cloud Security Alliance (CSA) a publicat în 2009 Security Guidance for Critical Areas of Focus in Cloud Computing. Acest document a fost updatat ulterior pentru a îmbunătăți modelul expus. Modelul de securitate propus de CSA reprezintă o abordare unitară a problemelor de securitate din arhitecturile cloud, prin extinderea mecanismelor de control și monitorizare tradiționale și adaptarea acestora la specificul cloud-ului [94].
CSA subliniază faptul că o mare parte din responsabilitatea pentru respectarea reglementărilor va trebui asigurată de consumator, ceea ce face se traduce în compensarea, de către clientul cloud a deficitului de informații și dificultăților de comunicare pentru echipa de audit. Acest lucru este valabil în măsura în care business-ul este cel responsabil cu planificarea și monitorizarea respectării standardelor și reglementărilor juridice.
Cu toate acestea, această lucrarea oferă recomandări cu privire la abordarea problemelor legate de conformitatea furnizorilor de servicii cloud cu standardele și cu reglementările juridice.
Modelul reprezintă atât structurarea aspectelor de securitate pe domenii funcționale și logice cât și recomandări cu privire la modalități de adresare a provocărilor specifice fiecărui domeniu. Acest model este prezentat pe larg în capitolul 2 al acestei lucrări.
5.3 ELEMENTE ÎN PROCESUL DE AUDIT
Procesul de auditare al arhitecturilor de tip cloud reprezintă procesul care, pe baza informațiilor existente despre aplicațiile analizate și ținând cont de toate aspectele de securitate invocate în secțiunea anterioară, are ca finalitatea formularea unui raport de audit din care să reiasă gradul de conformitate al aplicațiilor în raport cu standardele analizate materializat în factorul de siguranță al arhitecturii cloud. Auditul reprezintă, așadar, examinarea profesională a unei arhitecturi de tip cloud computing în vederea exprimării unei opinii responsabile și independente prin raportarea la criteriile (standarde, norme) specificate mai sus asupra securității arhitecturii [95].
Elementele oricărui proces de audit sunt:
Auditorul reprezintă persoană calificată să execute procesul de auditare. El poate fi:
Auditor intern – persoană fizică ori juridică, salariat al entității auditate,respectiv angajat prin contract care execută procesul de audit
Auditor extern – persoană fizică ori juridică care își exercită prerogativele în baza unui contract cu întreprinderea
Totalitatea auditorilor formează echipa de audit. Există situații, cum este și cel al auditării arhitecturilor de tip cloud computing în care auditorii sunt însoțiți de experți tehnici. Experții tehnici au menirea de a oferi toate detaliile necesare auditorului pentru a înțelege gradul de conformitate pe care un proces tehnic îl manifestă în raport cu criterii de evaluare.
Criteriile de audit reprezintă elementele factuale la care se raportează auditorul în procesul de audit. În mod concret acestea pot consta în:
Standardele ce reglementează anumite aspecte supuse auditării – în cazul procesului audit al unei arhitecturi de tip cloud, aceste criterii includ standarde de securitate a datelor stocate în cloud, standarde de disponibilitate a datelor stocate în cloud, standarde de performanță a aplicațiilor dezvoltate în arhitecturi de tip cloud.
Normele ce reglementează raporturile de obligativitatea la care sunt supuși consumatorii de servicii cloud, de furnizare a anumitor informații și respectarea anumitor reguli privind stocarea și utilizarea datelor din aplicații cu date confidențiale, în raport cu clienții acestora sau cu proprietarii acelor date – de exemplu legislația europeană și cea românească privind stocarea și folosirea datelor personale.
Principiile de bază și metodologiile care stau la baza procesului analizat.
Probele de audit reprezintă înregistrări, elemente factuale și alte informații variabile care sunt relaționate cu criterii de auditare folosite în procesul de auditare. Probele de audit pot fi atât calitative cât și cantitative. Probele obiectivelor reprezintă informațiile care relevă existența unui proces/caracteristică sau care demonstrează valoarea de adevăr a unei afirmații.
Compania auditată reprezintă compania ale cărei procese, aplicații, proceduri sunt auditate în vedere demonstrării conformității cu criteriile auditate.
Raportul de audit reprezintă actul final al procesului de audit și cuprinde:
Concluziile procesului de audit – acestea sunt structurate și redactate de echipa de audit după încheierea procesul de auditare în care s-au luat în considerare faptele auditate și obiectivele procesului de audit. Rezultatele auditului rezultă din procesul de evaluare a probelor auditate și compararea lor cu criteriile de audit. În cazul auditării arhitecturilor de tip cloud, concluziile procesului de audit constau în recomandări cu privire la domeniile care pot fi îmbunătățite și impactul pe care aceste îmbunătățiri îl pot avea în arhitectura analizată.
Rezultatele auditului – acestea reprezintă rezultatul procesului de evaluare al criteriilor de audit folosite pe probele de audit administrate. Rezultatele procesului de audit pot fi exprimate în vederea stabilirii conformității în raport cu criteriile de audit sau, din contră, în vederea stabilirii neconformității în raport cu criteriile de audit folosite. De asemenea, ele pot identifica best practice-uri sau oportunități de îmbunătățire. În cazul auditului arhitecturilor cloud, rezultatul procesului de auditare constă în calcularea factorului de siguranță și al celui de rentabilitate ai adopției arhitecturii cloud.
Planul de audit reprezintă modalitate de reprezentare a mecanismelor folosite pentru realizarea unui proces de audit. Planul de audit descrie activitățile întreprinse de echipa de audit pentru a obține obiectivele procesului de audit.
Programul de audit reprezintă un set de aranjamente care au ca scop obținerea unui obiectiv de audit într-un timp specific. Programul de audit include toate activitățile și resursele necesare pentru a planifica, organiza și realiza unul sau mai multe procese de audit.
Scopul procesului de audit constă în menționarea aspectelor urmărite de echipa de audit pe parcursul procesului de audit. Scopul procesului de audit prezintă întotdeauna granițe bine definite pe care nu le poate depăși, însă el poate fi definit prin prisma :
Scopului principal – reprezintă focusul principal al echipei de audit pe parcursul procesului de audit
Scopului extins – reprezintă extensii ale scopului principal care trebuie urmărite de echipa de audit în procesul de audit.
Scopul poate fi definit prin specificarea locației fizice unde se produce auditul, prin specificarea unităților organizatorice analizate sau prin specificarea proceselor și activităților incluse în procesul de audit și a timpului de desfășurare a acestuia.
Competența reprezintă capacitatea echipei de audit de a aplica cunoștințele și aptitudinile pe care le au în vederea obținerii rezultatelor dorite prin procesul de audit.
Conformitatea reprezintă respectarea cerințelor. A fi în conformitate înseamnă a îndeplini criteriile de evaluare a unor standarde sau norme.
Neconformitatea reprezintă opusul conformității. Este eșecul în îndeplinirea anumitor criterii de evaluare în raport cu standarde și norme.
Observatorul reprezintă persoana care este martor la activitățile de audit întreprinse de auditor. Observatorul nu este parte din echipa de audit, și ca atare nu îndeplinește funcții de audit. Observatorul nu influențează și nici nu intervine în procesul de auditare. El poate reprezenta organizația auditată sau alte părți interesate.
Riscul, conform ghidului 73 ISO, reprezintă efectul incertitudinilor asupra obiectivelor. Efectul poate fi o deviație pozitivă sau negativă de la rezultatul așteptat.
METODE DE AUDITARE A ARHITECTURILOR DE TIP “CLOUD COMPUTING”
În abordarea creată de mine am implementat procesul de auditare al sistemelor dezvoltate în arhitecturi de tip cloud computing [113]. Raportându-mă la noțiunile teoretice introduse în secțiunea anterioară, voi prezenta elementele acestui proces:
Auditorul este reprezentat de cel care realizează auditul
Criteriile de audit sunt reprezentate de practicile comunităților care au impus standardele de securitate aplicabile în arhitecturi de tip cloud computing și se materializează în întrebările adresate în chestionarul de audit și coeficientul de siguranță și a celui de rentabilitate asociate răspunsurile predefinite ale acestora
Probele de audit folosite sunt caracteristicile aplicațiilor analizate care au influență directă asupra alegerea răspunsurilor întrebărilor – în funcție de aceste caracteristici auditorul va alege cel mai potrivit răspuns, cel care descrie cel mai fidel caracteristicile aplicației analizate în raport cu aspectul vizat de întrebare
Raportul de audit este reprezentat de rezultatul final al aplicației de audit și constă în calcularea factorului de siguranță al soluției cloud și a celui de rentabilitate, scoțând în evidență domeniile cu cele mai mici scoruri pentru caracteristicile analizate
Raportul de audit reprezintă rezultatul final al procesului de audit și cuprinde:
Concluziile procesului de audit – în aplicația de audit acestea contau în prezentarea domeniilor cu cei mai mici factori de siguranță și rentabilitate în vederea atragerii atenției asupra lor.
Rezultatele auditului – acestea reprezintă rezultatul procesului de evaluare al criteriilor de audit folosite pentru probele de audit administrate. Rezultatele procesului de audit se reflectă în factorii de siguranță și cel de rentabilitate asociați soluției cloud care face obiectul auditului. Pe baza acestui rezultat, compania care a realizat procesul de audit poate să stabilească gradul de succes al implementării serviciilor cloud.
Scopul procesului de audit constă în stabilirea gradului de succes al implementării serviciilor cloud :
Scopul principal – reprezintă stabilirea gradului de siguranță și beneficiilor aduse de implementarea serviciilor cloud materializate în factorii de siguranță și de rentabilitate calculați de aplicația de audit
Scopul extins – reprezintă punctarea domeniilor în care gradul de succes este scăzut.
Procesul de auditare este reprezentat în figura de mai jos:
Fig. 5.9: Procesul de auditare al serviciilor cloud
Tabelul de mai jos descris în detaliu procesul reprezentat grafic:
Tabelul 5.1: Procesul de auditare al serviciilor cloud
Concepte arhitecturale folosite pentru auditarea arhitecturilor de tip “Cloud Computing”
Abordarea privind auditul serviciilor cloud analizează aplicațiile implementate în arhitecturi cloud din două perspective:
Din perspectiva gradului de siguranță pe care aplicația în cloud îl are în raport cu mecanismele de control analizate.
Din perspectiva gradului de rentabilitate pe care aplicația în cloud îl oferă companiei.
Pe baza acestor factori, se poate obține un raport complet și relevant privind domeniile în care aplicația trebuie să sufere îmbunătățiri. De asemenea, pe baza rezultatului se poate clasifica adopția cloud-ului ca fiind o investiție de succes sau din contră, nerentabilă.
În vederea manipulării și implementării procesului de audit al serviciilor dezvoltate în arhitecturi de tip cloud, am folosit mai multe concepte prezentate în această secțiune.
Compania reprezintă conceptul folosit pentru a manipula date specifice de companie. Compania conține unul sau mai multe portofolii, fiecare portofoliu conține unul sau mai multe programe, iar fiecare program conține unul sau mai multe proiecte.
Portofoliul reprezintă o suită de programe de business gestionate și optimizate în vederea îmbunătățirii valorii companiei. Altfel spus, portofoliul reprezintă o grupare a elementelor care deservesc aceluiași interes. Aceste elemente pot fi: programe de investiții, servicii IT, proiecte IT, resurse și asset-uri. Portofoliile sunt alcătuite din mai multe programe.
Programele reprezintă un seturi structurate de proiecte care sunt necesare și suficiente pentru a obține beneficiile de business dorite și pentru a livra un spor de valoare companiei, incluzând aici procesele de gestiune a schimbărilor în business, procesele de business, instruirea angajaților etc. Programele sunt asimilate deseori cu unitatea de bază a investițiilor. Astfel, programele au o durată asignată și un nivel de maturitate impus ca țintă. De asemenea, fiecare program are asociat lui un nivel de risc asumat. Acesta este agreat la nivel de management al programului din care aplicația face parte ținându-se cont de următoarele criterii:
Criticalitatea proceselor de business implementate în program– cu cât aceasta este mai mare cu atât nivelul de risc asumat este mai mic
Confidențialitatea datelor – dacă aplicațiile din program manipulează și stochează date cu caracter personal, nivelul de risc asumat va fi scăzut
Criticalitatea programului materializată prin dependența funcționării optime a altor programe în condiții de nefuncționalitate a aplicațiilor din programul analizat – dacă există sisteme a căror funcționare depinde de funcționarea programului analizat, aceasta va avea un nivel de risc asumat mai mic.
Proiectele reprezintă seturi structurate de activități realizate în vederea obținerii unei capabilități tehnice definite pe baza unul plan și a unui buget agreate (această condiție este necesară dar nu și suficientă pentru a putea demonstra obținerea rezultatului scontat). Proiectele sunt definite la nivel de livrare de componente IT (fie ca sunt ele soluții sau aplicații) care sunt necesare, dar nu suficiente pentru obținerea beneficiilor de business.
Aplicațiile Cloud sunt serviciile contractate de către companie de la furnizorii de cloud care urmează a fi analizate din perspectiva gradelor de siguranță și rentabilitate. Fiecare aplicație este definită de caracterul său de sensibilitate. O aplicație cloud este catalogată ca fiind sensibilă sau nu în funcție de caracterul de confidențialitate al datelor.
Nivel de risc asumat este o caracteristică a programului și reprezintă, pe o scală de la 1 la 3, gradul de incertitudine pe care managementul programului este dispus să și-l asume în implementarea acelui program. Nivelul de risc asumat are influență directă asupra riscului aplicației asumat, factor ce intervine în calcularea gradului de siguranță al aplicației cloud.
Domeniul de securitate reprezintă domeniul în raport cu care se evaluează gradul de implementare al mecanismelor de control ce adresează caracteristici ale domeniul în procesul de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud.
Siguranța reprezintă conceptul care implementează procesul de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud. Siguranța poate avea drept țintă diferite domenii de securitate analizate în raport cu o aplicație implementată în cloud. Procesul de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud constă în analizarea unui set de mecanisme de control ce trebuie implementate de către furnizor în domeniul supus evaluării. Această analiză se realizează prin specificarea gradului de implementare a mecanismelor menționate în chestionarul de audit. Există grade de implementare predefinite, fiecare dintre acestea având asociat un grad de siguranță. Rezultatul final al unui proces de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud este reprezentat de factorul de siguranță obținut de ținta procesului de audit calculat pe baza gradelor de implementare a mecanismelor de securitate ce compun chestionarul procesului de audit. Algoritmul de calculare a factorului de siguranță este descris in secțiunea 5.3.2.
Figura de mai jos descrie legăturile între conceptele folosite de procesul de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud:
Fig. 5.10: Concepte folosite în calcularea factorului de Siguranță
Un proces de audit cuprinde unul sau mai multe domenii de securitate existente pentru servicii de tip cloud. Aceste domenii sunt analizate din perspectiva mecanismelor de control și siguranță care sunt implementate pentru aplicația respectivă. În funcție de gradul de implementare și de maturitatea al acestora se calculează scorul de siguranță. Pentru calcularea factorului de siguranță se folosește algoritmul descris în secțiunea 5.3.2.
Rentabilitatea reprezintă conceptul care implementează procesul de audit care are drept obiectiv evaluarea rentabilității unui serviciu cloud. Rentabilitate poate avea drept țintă programul sau portofoliul din care face parte proiectul aplicației supusă procesul de audit care are drept obiectiv evaluarea siguranței. Procesul de audit care are drept obiectiv evaluarea rentabilității unui serviciu cloud constă în analizarea unui set de metrici de procese pentru ținta procesului de audit în vederea stabilirii gradului de realizare al acestora. Această analiză se realizează prin specificarea gradului de maturitate a metricilor menționate în chestionarul de audit. Există grade de maturitate predefinite, fiecare dintre acestea având asociat un scor de îndeplinire. Rezultatul final al unui proces de audit care are drept obiectiv evaluarea rentabilității unui serviciu cloud este reprezentat de factorul de rentabilitate obținut de ținta procesului de audit calculat pe baza gradelor de maturitate a mecanismelor de securitate ce compun chestionarul procesului de audit. Algoritmul de calculare a factorului de rentabilitate este descris in secțiunea 5.3.3.
Rentabilitatea se calculează în raport cu toate domeniile de analiză existente în modelul Val IT prezentat în A.3 Val IT.
Figura de mai jos descrie legăturile între conceptele folosite de procesul de audit care are drept obiectiv evaluarea rentabilității unui serviciu cloud:
Fig. 5.11: Concepte folosite în calcularea factorului de rentabilitate
Procesul de audit cuprinde analiza rentabilității portofoliului sau a programului din care face parte aplicația supusă procesului de audit. Ținta rentabilității este analizată din perspectiva metricilor de rentabilitate definite pentru fiecare dintre domeniile adresate de modelul Val IT. În funcție de gradul de maturitatea al acestora se calculează scorul de rentabilitate. Pentru calcularea factorului de rentabilitate se folosește algoritmul descris în secțiunea 5.3.3.
Chestionarul reprezintă conceptul care manipulează răspunsurile unui proces de audit. Figura de mai jos descrie legăturile între chestionare și celelalte concepte ale procesului de audit:
Fig. 5.12: Relațiile între chestionare și celelalte obiecte manipulate în procesul de audit
Fiecare proces de audit are atașat un chestionar astfel încât să se poată realiza auditarea incrementală – analizarea aspectelor modificate în raport cu ultimul proces de audit nu a întregului set de controale și mecanisme.
Evaluarea factorului de siguranță al arhitecturilor cloud
Abordarea proprie implementează procesul de auditare al unui serviciu cloud contractat de companie care analizează ținta din perspectiva factorului de siguranță pe care acesta îl prezintă și a factorului de rentabilitate al programului prin care s-a adoptat serviciul cloud. Din perspectiva evaluării factorului de siguranță, procesul de audit este implementat sub forma unor chestionare ce adresează mecanismele de securitate care asigură un grad sporit de siguranță, clasificate pe diferite domenii. Fiecare mecanism de securitate are șase niveluri de implementare, auditorul trebuind să selecteze pe cel aplicabil serviciului cloud analizat.
Procesul de audit ce are drept obiectiv evaluarea siguranței unui serviciu cloud poate avea drept țintă unul sau mai multe domenii de securitate. Definirea acestei ținte determină echipa de audit să selecteze ca și componente ale chestionarului de audit numai mecanismele de securitate ce adresează aspecte aparținând domeniilor alese. Domeniile adresate de procesul de audit sunt cele prezentate în capitolul 2, la secțiunea modelului de securitate recomandat de CSA. Astfel, pentru domeniile de securitate adresate de procesul de audit, am definit definite mecanisme de control. Pentru fiecare mecanism de securitate sunt definite niveluri de implementare din care auditorul trebuie să selecteze cel mai potrivit răspuns. Aceste niveluri sunt descrise în tabelul de mai jos.
Tabelul 5.2: Niveluri de implementare a mecanismelor de siguranță de către furnizorii de cloud
Cu cât nivelul de implementare este mai ridicat cu atât riscul asociat domeniul de securitate din care mecanismul supus evaluării face parte este mai mic.
Figura de mai jos descrie conceptele manipulate în procesul de calcul al factorului de siguranță:
Fig. 5.13: Obiecte manipulate în procesul de evaluare al factorului de siguranță
Procesul de calcul al factorului de siguranță al unei aplicații cloud poate avea drept țintă unul sau mai multe domenii. Astfel:
Dacă procesul de calcul al factorului de siguranță adresează un singur domeniu atunci scorul aferent de siguranță pentru procesul de audit va fi egal cu factorul de siguranță domeniul vizat
Dacă procesul de calcul al factorului de siguranță adresează un mai multe domenii atunci scorul aferent de siguranță pentru procesul de audit va fi egal media aritmetică a factorului de siguranță al domeniilor analizate.
Factorul de siguranță este dependent de următoarele mărimi:
Riscul aplicației supusă analizei din perspectiva domeniului evaluat.
Gradul de sensibilitate al aplicației influențează riscul prin introducerea unor constante de corecție.
Riscul asumat al aplicației supusă analizei din perspectiva domeniului evaluat.
Ca atare, factorul de siguranță poate fi exprimat prin procesul reprezentat în figura următoare:
Fig. 5.14: Procesul de calcul al factorului de siguranță
Riscul aplicației reprezintă factorul de incertitudine pe care îl manifestă securitatea aplicației cloud în raport cu vulnerabilitățile existente în domeniul adresat de procesul de evaluare al riscului. Altfel spus, riscul aplicației este calculat pe fiecare domeniu în parte.
Valoarea riscului aplicației din perspectiva domeniului analizat este dată de expresia:
, relația (5.1)
Unde:
este riscul aplicației în raport cu domeniul i
este constanta de corecție a riscului și este egală cu valoarea minimă a constantelor de corecție introduse în calcularea riscului. Ea are valoarea de 0.01 și este introdusă din considerente practice: nu există niciun domeniu care are risc asociat 0.
este gradul de implementare al mecanismului de securitate k
este constanta de corecție aplicată riscului aferent unui mecanism de securitate. Dacă aplicația în raport cu care se face evaluarea este definită ca fiind sensibilă, constanta de corecție crește întrucât se consideră că orice scădere a nivelului de implementare al unui mecanism de securitate pentru o aplicație sensibilă crește simțitor riscul asociat acelei aplicații. Constanta de corecție aplicată riscului este stabilită înainte de procesul de audit în funcție de industria în care activează compania supusă analizei și de domeniul și datele manipulate de aplicația evaluată.
n este numărul total de mecanisme de securitate incluse în chestionarul de audit
Constanta de corecție reprezintă recomandarea comunității de cloud și diferă în funcție de industrie, în sensul măririi ei pentru domeniul financiar, medical și nuclear – acestea fiind considerate domenii cu un grad sporit de senzitivitate.
Formula de calcul a constantei de corecție pentru domeniile care nu prezintă un grad sporit de pericol este:
,relația (5.2)
Riscul asumat al aplicației supusă analizei din perspectiva domeniului evaluat este influențat de nivelul de risc asumat specificat în definiția aplicației cloud. Riscul asumat al aplicației este definit de relația 5.3:
, relația (5.3)
Unde:
este riscul asumat pentru aplicația analizată în raport cu domeniul i
este nivelul de risc asumat al aplicației
n este numărul total de mecanisme de control din domeniul i
Factorul de siguranță al aplicației supusă analizei în raport cu domeniului evaluat este:
, relația (5.4)
Unde:
este factorul de siguranță al aplicației în raport cu domeniul i
este riscul aplicației în raport cu domeniul i
este riscul asumat pentru aplicația analizată pentru domeniul i
este constanta de corecție aplicată riscului aferent unui mecanism de securitate
n este numărul total de mecanisme de securitate incluse în chestionarul de audit pentru domeniul supus auditării
Factorul de siguranță este exprimat procentual în raport cu gradul ideal de siguranță care este considerat a fi obținut în ipoteza în care nu există risc asociat acelui domeniu. Pentru calcularea factorului total de siguranță, se folosește următoarea relație:
, relația (5.5)
Unde:
FS este factorul total de siguranță
este factorul de siguranță al aplicației în raport cu domeniul i
n este numărul de domenii evaluate în procesul de audit
În continuare, mi-am propus să calculez gradul de conformitate al aplicației analizate în raport cu:
Standardele folosite pentru implementarea abordării procesului de auditare:
CSA în modelul de securitate prezentat în capitolul 2.
ISACA în framework-urile de control folosite pentru evaluarea gradului de guvernanță a companiei. Framework-urile adresate în acest audit sunt:
COBIT 5
Cloud Computing Management Audit/Assurance Program
Risk IT
Practicile existente privind analiza guvernanței și controlul operativității companiei
Pentru stabilirea gradului de conformitate cu cele prezentate mai sus, s-a considerat nivelul de risc asumat în raport cu care s-a definit gradul minim de siguranță necesar pentru a se putea concluziona că un domeniu respectă standardele specificate.
Astfel, factorul minim de siguranță este definit de:
, relația (5.6)
Unde:
este factorul minim de siguranță în raport cu care se evaluează conformitatea
este nivelul de risc asumat.
este constanta de conformitate și este dat de practica mondială, în funcție de nivelul de risc asumat conform tabelului de mai jos:
Tabelul 5.3: Constanta de conformitate în funcție de nivelul de risc asumat
Gradul de conformitate al unui domeniu în raport cu standardele este definit de relația:
, relația (5.7)
Unde:
este nivelul de conformitate al domeniului i
este factorul minim de siguranță în raport cu care se evalueză conformitatea
este factorul de siguranță al domeniului i
este conformitatea domeniului i, care se calculează folosind următoarea formulă:
, relația (5.8)
Unde:
este conformitatea domeniului i. Acesta asigură că, dacă nu este atins factorul minim de siguranță, atunci nivelul de conformitate al acelui domeniu este zero.
este factorul minim de siguranță în raport cu care se evaluează conformitatea
este factorul de siguranță al domeniului i
Evaluarea factorului de rentabilitate al arhitecturilor cloud
Procesul de audit conține și analiza serviciului cloud din perspectiva factorului de rentabilitate al programului prin care s-a adoptat serviciul cloud. Evaluarea factorului de rentabilitate este implementată sub forma unor chestionare ce adresează metrici de procese care trebuie analizate în stabilirea valorii adăugate adusă de programul/portofoliul respectiv, metrici ce sunt clasificate pe diferite domenii. Fiecare metrică are șase niveluri de maturitate, auditorul trebuind să selecteze pe cel aplicabil programului sau portofoliului analizat.
Procesul de audit ce are drept obiectiv evaluarea rentabilității unui serviciu cloud poate avea drept țintă un program sau un portofoliu de programe. Acest proces este bazat framework-ul Val IT [16] descris în Anexe. Independent de tipul de țintă ales, fie că este el program sau portofoliu, analiza adresează metricile de proces definite pentru toate domeniile. Pentru fiecare metrică de proces sunt definite niveluri de implementare din care auditorul trebuie să selecteze cel mai potrivit răspuns. Aceste niveluri sunt descrise în tabelul de mai jos.
Tabelul 5.4: Niveluri de implementare a mecanismelor de siguranță de către furnizorii de cloud
Cu cât nivelul de maturitate este mai ridicat cu atât factorul de rentabilitate va fi mai mare.
Pentru calcularea factorului de rentabilitate am folosit următoarele concepte:
Rentabilitate – este o reprezentare numerică a procesului de audit căreia i se asociază un factor de rentabilitate
Portofoliu / Program – reprezintă ținta procesului de audit care are ca scop evaluarea factorului de rentabilitate. Dacă portofoliul este ținta procesului de audit factorul de rentabilitate se calculează în raport cu toate programele din interiorul portofoliului
Aplicația cloud – reprezintă ținta procesului de audit și este evaluată atât din perspectiva factorului de siguranță (care influențează direct factorul de rentabilitate), cât și din perspectiva factorului de rentabilitate. Aplicația face parte dintr-un proiect implementat de companie, care, la rândul său face parte din programul supus analizei pentru evaluarea factorului de rentabilitate
Metrici de proces – reprezintă componente de proces existente în companiei, pentru care se evaluează gradul de maturitate. În funcție de scorul de maturitate, se calculează indicele de nerealizare a obiectivelor care e influențează direct factorul de rentabilitate
Investiție – reprezintă toate datele financiare ale programului supus analizei. Fiecare program are un obiect de tip investiție pe baza căruia se calculează factorul de rentabilitate.
Figura de mai jos descrie conceptele manipulate în procesul de calcul al factorului de rentabilitate:
Fig. 5.15: Obiecte manipulate în procesul de evaluare al factorului de siguranță
Procesul de calcul al factorului de rentabilitate al unei aplicații cloud poate avea drept țintă programul din care aplicația face parte, sau portofoliul de care aparține programul aplicației. Astfel:
Dacă procesul de calcul al factorului de rentabilitate adresează programul atunci scorul aferent de rentabilitate pentru procesul de audit va fi egal cu factorul de rentabilitate pentru programul analizat.
Dacă procesul de calcul al factorului de rentabilitate adresează portofoliul atunci scorul aferent de rentabilitate pentru procesul de audit va fi calculat în funcție de toți factorii de rentabilitate ai programelor componente, cu mențiunea că, în calculul celorlalte programe în afara celui din care face parte aplicația analizată, rata de actualizare va fi egală cu costul investiției aferent programului respectiv.
Factorul de rentabilitate calculat de aplicația de audit este dependent de următoarele mărimi:
Nivelul așteptat de maturitate al programului din care face parte aplicația supusă analizei.
Investițiile totale realizate în programul din care face parte aplicația supusă analizei.
Costul investițiilor realizate în programul din care face parte aplicația supusă analizei din perspectiva domeniului evaluat.
Durata programului din care face parte aplicația supusă analizei.
Venitul mediu estimat pentru programul din care face parte aplicația supusă analizei.
Costul operațional așteptat pentru programul din care face parte aplicația supusă analizei.
Riscul asociat aplicației supusă analizei.
Ca atare, factorul de siguranță poate fi exprima prin procesul reprezentat în figura următoare:
Fig. 5.16 Procesul de calcul al factorului de rentabilitate
Factorul de rentabilitate a investiției reprezintă rata de fructificare a surselor de finanțare imobilizate sub forma investiției. Factorul de rentabilitate se calculează raportându-se la anumite criterii generale ce vizează mai multe domenii de guvernanță în domeniul IT.
Astfel, în procesul de calculare al factorului de rentabilitate, abordarea proprie pleacă de la gradul de maturitate al metricilor de proces ale programului analizat și, pe baza acestuia introduce un factor de corecție în rata de actualizare a veniturilor și cheltuielilor care are influență directă în calcului valorii anuale nete. Factorul de rentabilitate este dat de valoarea actualizată netă întrucât aceasta exprimă în ce măsură a investiția a fost sau nu profitabilă.
Scorul de maturitate reprezintă gradul de maturitate al programului supus analizei și este dat de expresia:
, relația (5.9)
Unde:
SM este scorul de maturitate al programului supus analizei
este scorul de maturitate al metricii i
m este numărul total de metrici de proces incluse în chestionarul de audit
Pe baza scorului de maturitate, se calculează indicele de realizare ca fiind raportul dintre scorul de maturitate și nivelul de maturitate așteptat pentru proiectul respective:
, relația (5.10)
Unde:
este indicele de realizare al programului supus analizei
SM este scorul de maturitate al programului supus analizei
ML este nivelul așteptat de maturitate al programului supus analizei
Pe baza indicelui de realizare, se calculează indicele de nerealizare ca complementul său:
, relația (5.11)
Unde:
este indicele de nerealizare al programului supus analizei
este indicele de realizare al programului supus analizei
este realizarea programului/portofoliului supus analizei, care se calculează folosind următoarea formulă:
, relația (5.12)
Unde:
este realizarea programului/portofoliului. Acesta asigură că, dacă nivelul de maturitate rezultat în urma procesului de audit este mai mare decât nivelul așteptat, indicele de nerealizare va fi zero
este indicele de realizare al programului supus analizei
Indicele de nerealizare are impact direct în rata de actualizare.
Rata de actualizare este metoda prin care se asigură comparabilitatea parametrilor economici și a indicatorilor financiari ce se realizează în perioade diferite de timp, putându-se astfel clasifica o investiție ca fiind rentabilă sau nu. Pentru exprimarea factorului de rentabilitate a unei aplicații din arhitecturi cloud, rata de actualizare este exprimată sub forma:
, relația (5.13)
Unde:
i este rata de actualizare folosită pentru calculul factorului de rentabilitate
este indicele de nerealizare al programului supus analizei
este costul investiției asociată programului din care face parte aplicația analizată
R este factorul de risc asociat cu aplicația analizată
Pentru procesele de evaluare a factorului de rentabilitate a portofoliilor, pentru programele pentru care nu se pot calcula indicele de nerealizare asociat și factorul de risc asociat aplicațiilor din programele respectiv, se va considera rata de actualizare ca fiind egală cu costului investiției:
, relația (5.14)
Unde:
i este rata de actualizare folosită pentru calculul factorului de rentabilitate
este costul investiției asociată programului din care face parte aplicația analizată
Pentru procesele de evaluare a factorului de rentabilitate a programelor, rata de actualizare este calculată folosind următoarea expresie:
, relația (5.15)
Unde:
i este rata de actualizare folosită pentru calculul factorului de rentabilitate
este indicele de nerealizare al programului supus analizei
este costul investiției asociată programului din care face parte aplicația analizată
R este factorul de risc asociat cu aplicația analizată
Factorul de risc este calculat ca fiind media riscurilor asociate cu domeniile supuse procesului de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud, mediată de numărul total de domenii, astfel:
, relația (5.16)
Unde:
R este factorul de risc asociat cu aplicația analizată
n este numărul total de domenii supuse procesului de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud
este factorul de siguranță aplicației în raport cu domeniul k
Valoarea actualizată netă (VAN) reprezintă o metodă de evaluare a investițiilor care este direct dependentă de costurile implicate și de veniturile pe care acestea le generează. VAN face compararea între fluxul monetar degajat pe durata derulării programului analizat și efortul investițional implicat în realizarea acestuia. Formula de calcul a acesteia este:
relația (5.17)
Unde:
VAN este valoarea actualizată netă pentru programul supus analizei
reprezintă costurile totale aferente programului
reprezintă veniturile totale estimate aferente programului
Veniturile totale aferente programului analizat se calculează ținând cont de următorii factori:
Venituri anuale estimate angajate de aplicația analizată
Perioada programului – aceasta este de obicei exprimată în ani
Rata de actualizare
Astfel, definiția veniturilor totale asociate programului este:
relația (5.18)
Unde:
reprezintă veniturile totale aferente programului
y reprezintă numărul de ani constând în durata proiectului
reprezintă venituri anuale estimate aferente programului
i reprezintă rata de actualizare folosită pentru calculul factorului de rentabilitate
Costurile totale aferente programului analizat se calculează ținând cont de următorii factori:
Investiții inițiale
Costuri operaționale
Perioada programului – aceasta este de obicei exprimată în ani
Rata de actualizare
Astfel, definiția costurilor totale asociate programului este:
relația (5.19)
Unde:
reprezintă costurile totale aferente programului
reprezintă investițiile totale ale programului
y reprezintă numărul de ani constând în durata proiectului
reprezintă costurile operaționale anuale aferente programului
i reprezintă rata de actualizare folosită pentru calculul factorului de rentabilitate
Ținând cont de relațiile 5.18 și 5.19, valoarea actualizată netă se exprimă ca:
, relația (5.20)
Pentru procesele de audit în care ținta analizei factorului de rentabilitate constă într-un portofoliu, valoarea actualizată netă se calculează pentru fiecare program în parte, cu mențiunea că rata de actualizare a programelor care nu conțin aplicația supusă auditului va fi calculată folosind relația 5.14, spre deosebire de rata de actualizare a programului care conține aplicația supusă auditului, aceasta fiind calculată folosind relația 5.15.
Pe baza valorii actualizate netă, se calculează factorul de rentabilitate ca fiind:
, relația (5.21)
Unde:
reprezintă factorul de rentabilitate al programului
VAN este valoarea actualizată netă pentru programul supus analizei
Pentru procesele de audit în care ținta analizei factorului de rentabilitate constă într-un portofoliu, factorul de rentabilitate se calculează folosind următorul mecanism:
, relația (5.22)
Unde:
reprezintă factorul de rentabilitate al programului
VAN este valoarea actualizată netă pentru programul supus analizei
În vedere evaluării unui termen economic specific domeniului investițional, și anume rata internă a rentabilității, folosim următoarea formulă:
, relația (5.23)
Unde:
RIR este valoarea ratei interne de rentabilitate a investiției supusă analizei
reprezintă valoarea actualizată netă pozitivă (cea care denotă că investiția este oportună).
reprezintă valoarea actualizată netă negativă (cea care denotă că investiția nu este oportună).
reprezintă rata de actualizare folosită pentru calculul
reprezintă rata de de actualizare folosită pentru calculul
Pentru a calcula toate valorile necesare aflării ratei interne de rentabilitate se procedează după cum urmează:
Dacă VAN calculat în procesul de audit al aplicației din perspectiva factorului de rentabilitate este pozitiv, atunci se vor folosi următoare valori:
, relația (5.24)
Unde:
reprezintă valoarea actualizată netă pozitivă (cea care denotă că investiția este oportună)
reprezintă valoarea actualizată netă calculată în procesul de evaluare a factorului de rentabilitate.
, relația (5.25)
Unde:
reprezintă rata de actualizare folosită pentru calculul
reprezintă rata de actualizare folosită în procesul de evaluare a factorului de rentabilitate pentru calculul
Pentru aflarea și , se realizează un proces iterativ:
se calculează valoare VAN:
relația (5.26)
dacă VAN calculată la pasul anterior este negativă,
, relația (5.27)
Unde:
reprezintă valoarea actualizată netă negativă (cea care denotă că investiția nu este oportună)
reprezintă valoarea actualizată netă calculată la pasul c,
, relația (5.28)
Unde:
reprezintă rata de actualizare folosită pentru calculul
reprezintă rata de actualizare calculată la pasul b
Dacă VAN calculată la pasul anterior este pozitivă se reia procesul de la pasul b.
Dacă VAN calculat în procesul de audit al aplicației din perspectiva factorului de rentabilitate este negativ, atunci se vor folosi următoare valori:
, relația (5.29)
Unde:
reprezintă valoarea actualizată netă negativă (cea care denotă că investiția nu este oportună)
reprezintă valoarea actualizată netă calculată în procesul de evaluare a factorului de rentabilitate.
, relația (5.30)
Unde:
reprezintă rata de actualizare folosită pentru calculul
reprezintă rata de actualizare folosită în procesul de evaluare a factorului de rentabilitate pentru calculul
Pentru aflarea și , se realizează un proces iterativ:
se calculează valoare VAN conform relației 5.20:
relația (5.31)
dacă VAN calculată la pasul anterior este pozitivă,
, relația (5.32)
Unde:
reprezintă valoarea actualizată netă pozitivă (cea care denotă că investiția este oportună)
reprezintă valoarea actualizată netă calculată la pasul c,
, relația (5.33)
Unde:
reprezintă rata de actualizare folosită pentru calculul
reprezintă rata de actualizare calculată la pasul b
Dacă VAN calculată la pasul anterior este pozitivă se reia procesul de la pasul b.
CAPITOLUL 6
IMPLEMELENTAREA TEHNICILOR DE AUDIT ÎN PROCESUL DE MIGRARE CĂTRE ARHITECTURI CLOUD
6.1 ARHITECTURA GENERALĂ A PROCESULUI DE MIGRARE
Pentru validarea metodologiei propusă pentru procesul de audit al migrării în cloud, am folosit mediul IT dintr-o companie de telecomunicații. Întrucât mi-am dorit analizarea oportunității adopției arhitecturilor de cloud computing doar pentru o aplicație specifică, în alegerea arhitecturii de analiză am ales sistemul supus evaluării și componentele care prezintă relevanță în procesul de migrare, în sensul că am inclus și aplicațiile care vor fi impactate direct de adopția cloud.
Figura de mai jos descrie sistemele existente în infrastructura analizată:
Fig. 6.1: Arhitectura Studiului de caz
Infrastructura în care am realizat această analiză include:
Aplicația de Identity Management – acest sistem este integrat cu soluția supusă procesului de auditare și stochează date relevante despre aceasta privind numărul de utilizatori, numărul de accesări pe zi, furnizând totodată mecanismul de autentificare pentru aplicația analizată.
Sistemul de stocare a certificatelor digitale – acest sistem este utilizat pentru generarea, validarea și retragerea certificatelor digitale utilizate la nivelul companiei atât pentru comunicarea între sisteme, cât și pentru autentificarea utilizatorilor în sistemele care au implementat un mecanism de autentificare cu certificate digitale. Acest sistem este clasificat drept un sistem de încredere.
Sistemul de Directory Server – acest sistem este sursa de date a sistemului de Identity Management pentru informațiile angajaților companiei. Este un sistem de încredere la nivel global pentru compania analizată.
Aplicația de Retenții – acest sistem conține date confidențiale în interiorul companiei și reprezintă sursa de date pentru o parte din funcționalitățile Aplicației de Raportare. Aplicația de retenții este business critical, iar stocarea și manipularea datelor pe care aceasta le folosește sunt subiectul standardelor de securitate și a reglementărilor juridice privind confidențialitatea datelor cu caracter personal. Din acest motiv toate datele stocate în această aplicație sunt criptate folosind un algoritm simetric 3 DES.
Sistemul de gestiune a cheilor 3 DES este un sistem dedicat generării, stocării, furnizării și ștergerii cheilor de criptare folosite în algoritmul 3 DES. Comunicația între sistemul de gestiune a cheilor 3 DES și toate celelalte sisteme ale companiei care îl folosesc este considerată a fi sigură. Ca atare, nu există mecanism de autentificare pe căile de comunicație din interiorul companiei.
Aplicația de raportare reprezintă sistemul supus analizei. Pentru aceasta am analizat oportunitatea adopției arhitecturilor de tip cloud.
Necesitatea de adopție a arhitecturilor de tip cloud computing a survenit ca urmare a unei tendințe existente în companie de a migra componentele software cu rol esențial în activitatea de business la nivel global. Ca atare, sursele de date ale aplicației de raportare au fost migrate către infrastructurile globale, sursele locale fiind decomisionate. Astfel, aplicația de raportare comunică cu sursele adiacente de date prin intermediul internetului. Singura sursă de date care nu a fost mutată la nivel global este aplicația de retenții din cauza gradului mare de customizare a acesteia, realizat pentru implementarea specificului juridic din România.
Astfel, în urma realizării ultimului inventar al domeniului IT al companiei, s-a constat că sistemul fizic pe care era implementată aplicația de raportare trebuie îmbunătățit pentru satisfacerea necesităților de performanță solicitate de business, având în vedere migrarea surselor de date la nivel global și accesarea lor prin intermediul Internetului. Performanțele sistemului au fost grav avariate din acest motiv, impunându-se astfel îmbunătățirea lui. S-a conturat astfel contextul specific adopției arhitecturilor de cloud care oferă:
Grad ridicat de scalabilitate – astfel arhitecturile de tip cloud pot oferi scalarea necesară aplicației de raportare pentru a funcționa în parametrii optimi în caz de creștere substanțială a datelor
Elasticitate – arhitectura de tip cloud oferă un grad sporit de adaptare la dispozitivele folosite de utilizatorii finali pentru accesul aplicației de raportare
Eficiență din perspectiva costurilor – în arhitecturi de tip cloud computing consumatorul plătește numai pentru resursele utilizate
Alocare dinamică de putere de calcul în funcție de necesitățile de procesare ale aplicației de raportare.
Caracteristicile aplicației și ale sistemului pe care aceasta este implementată sunt prezentate în tabelul următor:
Tabelul 6.1: Caracteristici ale aplicației supusă procesului de auditare a migrării în cloud
În urma discuției cu business-ul privind necesitățile lor de performanță în raport cu aplicația de raportare, am evaluat caracteristicile de sistem pe care aplicația de raportare îmbunătățită ar trebui să le aibă pentru a răspunde eficient solicitărilor, fie că sunt contractate de la furnizorul de cloud, fie că este îmbunătățit sistemul intern. Aceste caracteristici sunt prezentate în tabelul următor:
Tabelul 6.2: Caracteristici necesare ale aplicației de raportare
PROCESUL DE AUDIT
Procesul de audit al migrării aplicației de raportare către arhitecturi de tip cloud computing este definit de următorii parametrii:
Auditorul a fost un auditor extern întrucât eu am fost cea care a realizat acest proces. Scopul meu în compania analizată era de a evalua gradul de impact pe care aplicația de raportare îl manifestă în raport cu migrarea către cloud. De asemenea trebuie menționat faptul că, la momentul auditului dețineam date tehnice despre infrastructura companiei analizate și cunoșteam fluxurile informaționale implementate de procesele de business.
Echipa de audit a fost constituită din:
Auditorul extern
Un observator din rândul business-ului care a supravegheat întreg procesul de auditare în vederea garantării imparțialității auditorului extern în adresarea chestionarului de audit. Astfel s-a dorit balansarea aprecierii tehnice cu cea de business în procesul de auditare, observatorul fiind cel care m-a sfătuit asupra persoanelor de contact din companie care îmi pot oferi răspunsuri de o acuratețe superioară celei oferite de mine din perspectivă tehnică, prin analizarea percepției business-ului asupra anumitor aspecte
Expert tehnic ce aparține companiei analizate – rolul lui a fost acela de a-mi oferi detaliile necesare acolo unde gradul de profunzime al aspectelor adresate de chestionarul de audit depășea cunoștințele mele
Criteriile de audit au constat în:
Standarde de definire a gradului de mapare a furnizorului cloud pe necesitățile companiei auditate
Normele ce reglementează raporturile de obligativitatea la care sunt supuși consumatorii de servicii cloud de furnizare a anumitor informații și respectarea anumitor reguli privind stocare și utilizarea datelor din aplicații cu date confidențiale, în raport cu clienții acestora sau cu proprietarii acelor date – în studiul de față au prezentat interes reglementările cu privire la stocarea și manipularea datelor financiare. După analizarea acestei problematici complexe am oferit o abordare alternativă de tratare a acestui aspect descrisă în capitolul 4 care ne-a permis simplificarea procesului de audit și rezolvarea confidențialității datelor la nivelul companiei consumator. În acest fel, reglementările juridice cu privire la siguranța datelor financiare nu au afectat și nici nu au impactat procesul de auditare al migrării în cloud
Principiile de bază și metodologiile care stau la baza procesului implementat de aplicația de raportare privind fluxurile de date pe care le manipulează și mecanismele de integrare cu aplicațiile și sursele de date externe.
Probele de audit au constat în:
Minute de ședințe realizate în urma întâlnirilor cu business-ul care vizau anumite aspecte punctuale adresate de chestionarul de audit
Documentația tehnică existentă în companie cu privire la aplicația supusă auditării și la mecanismele de integrare ale acesteia cu alte sisteme externe
Blueprint-urile proceselor existente în aplicația analizată
Cerințele de performanță pentru aplicația analizată
Raportul de audit a cuprins:
Concluziile procesului de audit – acestea au fost redactate plecând de la rezultatele procesului de audit, exprimate prin propunerea unui plan de adopție potrivit și mapat pe specificul aplicației de raportare.
Rezultatele auditului – acestea constau în calcularea scorului de impact pentru aplicația de raportare.
Planul de audit a fost construit în funcție de disponibilitatea persoanelor de contact specializate pe anumite domenii și s-a bazat pe următoarele principii:
Procesul de audit se va întinde pe durata a 5 zile lucrătoare, în fiecare dintre acestea adresându-se întrebările aferente unui domeniu
Procesul de audit se realizează de către auditor, asistat de expertul tehnic și de observator în fiecare dintre cele 5 zile de audit
Pe durata auditării unui domeniu, persoanele competente să ofere suport în eventualitatea necesității de informații detaliate acordă prioritate răspunderii la solicitările venite din partea echipei de audit în detrimentul activităților lor de lucru
Ultima zi de audit este destinată adresării întrebărilor din chestionarul de audit cu caracter de generalitate și a întocmirii raportului de audit
La sfârșitul ultimei zi de audit, echipa de audit prezintă rezultatele obținute factorilor decizionali din interiorul companiei și interpretarea acestora.
Domeniile adresate în procesul de audit au fost:
Complexitatea Implementării
Risc și Conformitate
Infrastructură
Performanță
Toate – acest domeniu include întrebări legate de provocări generale pe parcursul procesului de migrare.
Programul de audit a fost realizat de către echipa de audit și a constat în prezentarea factorilor de decizie ai companiei a tuturor activitățile și resursele necesare pentru a planifica, organiza și realiza unul sau mai multe procese de audit.
Scopul procesului de audit:
Scopul principal a fost calcularea impactului migrării către cloud a aplicației de raportare
Scopul extins a fost realizarea unui plan de acțiune în vederea adopției arhitecturilor de tip cloud. Scopul extins a fost tratat de aceeași echipă, însă a fost realizat în afara planului de audit întrucât a necesitat suplimentarea timpului alocat.
EVALUAREA IMPACTULUI MIGRĂRII A APLICAȚIILOR CĂTRE ARHITECTURI DE TIP “CLOUD COMPUTING”
Procesul de audit a fost realizat folosind metodologia expusă în capitolul 3 [115].
În urma realizării procesului de audit, s-a calculat scorul aplicației de raportare în funcție de suma răspunsurilor la întrebările independente și de factorul de dependință dintre întrebările chestionarului de audit al căror răspunsuri se influențau reciproc.
Exprimat în expresii matematice, scorul se calculează:
, relația (6.1)
Unde:
este scorul aplicației care evaluează răspunsurile a n întrebări independente
este scorul întrebării independente i
În cazul dependințelor între întrebări, scorul are expresia:
, relația (6.2)
Unde:
este scorul aplicației care evaluează răspunsurile a n întrebări
este scorul aplicației care evaluează răspunsurile primele întrebări independente
este scorul întrebării i care este dependentă de întrebarea
este scorul întrebării de care este dependentă întrebarea curentă.
Scorul exprimat în expresiile anterioare s-a calculat pentru cele patru modele de arhitecturi implementate în aplicația de audit. Astfel s-au obținut următoarele scoruri:
Pentru modelul de Cloud Public:
Pentru modelul de Cloud Hibrid:
Pentru modelul de Cloud Privat:
Pentru modelul de aplicații dedicate utilizării în interiorul companiei:
Pentru evaluarea furnizorilor de servicii cloud se folosește scorul general al migrării ca fiind minimul scorurilor individuale calculate:
, relația (6.3)
Unde:
este scorul general al procesului de audit
este scorul aferent modelului de cloud public
este scorul aferent modelului de cloud hibrid
este scorul aferent modelului de cloud privat
este scorul aferent aplicațiilor dedicate utilizării în interiorul companiei
În funcție de acest scor, se evaluează furnizorii de cloud pentru a se recomanda cel mai potrivit.
Rezultatul final al procesului de audit constă în impactul general asociat țintei procesului de audit. Acesta este calculat prin medierea impactului rezultat, folosind următoarea formulă:
, relația (6.4)
Unde:
este impactul rezultat din procesul de audit
este scorul general al procesul de audit
este scorul maxim de audit care se obține prin alegerea răspunsurilor cu cel mai mare impact în urma migrării către modelul care a general scorul general
este scorul minim de audit care se obține prin alegerea răspunsurilor cu cel mai mic impact în urma migrării către modelul care a general scorul general
Pentru cuantificarea surplusului de beneficii adus de arhitecturile cloud se calculează factorul de valoare cloud ca fiind:
, relația (6.5)
Unde:
este factorul de valoare adus de arhitecturile cloud
este impactul rezultat din procesul de audit pentru arhitecturi de cloud publice
este impactul rezultat din procesul de audit pentru arhitecturi de cloud hibride
este impactul rezultat din procesul de audit pentru arhitecturi de cloud privat
este impactul rezultat din procesul de audit pentru arhitecturi de interne
Raportul de audit al procesului de migrare
Raportul de audit este format:
Rezultatele auditului – acestea constau în calcularea scorului de impact pentru aplicația de raportare
Concluziile procesului de audit – acestea au fost redactate prin propunerea unui plan de adopție potrivit și mapat pe specificul aplicației de raportare.
Rezultatele procesului de audit
În urma efectuării procesului de audit pentru aplicația de raportare, s-au obținut următoarele valori:
Tabelul 6.3: Scorurile Procesului de audit
Figura de mai jos prezintă grafic rezultatele obținute în urma adresării chestionarului de audit:
Fig. 6.2: Scoruri obținute în procesul de audit
Din graficul de mai sus, se poate observa că cel mai mic impact l-a manifestat implementarea folosind modelul cloud public. Considerentele folosirii unei arhitecturi de tip cloud computing au fost de natură financiară, luându-se în calcul atât aspectele legate de investițiile necesare pentru obținerea factorilor de performanță solicitați de business, cât costurile operaționale aferente menținerii aplicației în infrastructură internă. Aceste costuri sunt constituite din:
Costuri pentru serviciile de suport
Costuri pentru găzduirea aplicației
Costuri pentru întreținerea aplicației din perspectiva aplicării de patch-uri la nivel de sistem de operare, de bază de date etc.
În urma calculării acestora, s-a exprimat scorul general ca cel obținut pentru arhitectura de cloud public.
Impactul general al procesului migrării cât și cele particulare calculate pentru obținerea factorului de valoare au ținut cont de constantele reprezentând scorul maxim de audit care se obține prin alegerea răspunsurilor cu cel mai mare impact în urma migrării către modelul i și rezentând scorul minim de audit care se obține prin alegerea răspunsurilor cu cel mai mic impact în urma migrării către modelul i.
Valorile acestora sunt prezentate în tabelul de mai jos:
Tabelul 6.4: Scoruri de referință pentru calculul impactului
Folosind valorile prezentate mai sus precum și scorurile obținute în procesul de audit, s-au calculat factorii de impact:
, relația (6.6)
Unde:
este impactul rezultat din procesul de audit pentru arhitectura i
este scorul general al procesul de audit pentru arhitectura i (în acest caz pentru arhitectura de tip cloud public)
este scorul maxim de audit care se obține prin alegerea răspunsurilor cu cel mai mare impact în urma migrării către modelul i (în acest caz pentru arhitectura de tip cloud public)
este scorul minim de audit care se obține prin alegerea răspunsurilor cu cel mai mic impact în urma migrării către modelul i (în acest caz pentru arhitectura de tip cloud public)
Rezultatele sunt prezentate în tabelul de mai jos:
Tabelul 6.5: Impactul migrării
Reprezentarea grafică a factorilor de impact:
Fig. 6.3: Factorii de impact obținuți în procesul de audit
În urma analizei realizate, s-a constat că migrarea către o infrastructură de tip cloud a aplicației de raportare este oportună, fapt indicat și de factorul de valoare obținut de arhitecturile cloud computing în detrimentul implementării interne:
, relația (6.7)
Decizia de companiei a fost cea de adopție a unei arhitecturi de tip public cloud, pe model de Infrastructure as a Service deoarece aplicația migrată este implementată, astfel încât îmbunătățirile care trebuie să i se aducă vizează doar performanțele și costul. Totodată, această aplicație este dezvoltată direct pe necesitățile de business ale companiei, așa încât are un grad sporit de customizare.
Pe baza factorului de impact, s-a evaluat lista furnizorilor de cloud public care oferă servicii de Infrastructure as a Service și s-a propus folosirea furnizorului Amazon.
Punctele forte ale acestui furnizor sunt:
Costuri eficiente pentru serviciile oferite
Maturitate pe piața serviciilor cloud
Mecanisme eficiente de contractare
Gamă largă de produse și piață de distribuție și desfacere mare – fapt ce permite companiei să folosească experiența comunității atât în procesul de adopție, cât și în cel de guvernanță
Valoarea pe care o pune Amzon pe client dovedită de menținerea gradului de satisfacție prin asigurarea calității contractate de consumator, servicii de fidelizare a companiilor etc.
Concluziile procesului de audit
Concluziile procesului de audit sunt formulate sub forma unor activități ce trebuie executate înainte de începerea demersurilor efective de adopție a arhitecturilor cloud. Aceste activități sunt prezentate în tabelul de mai jos.
Tabelul 6.6: Etape propuse de aplicația de migrare
Plecând de la rezultatele furnizate de procesul de audit al migrării aplicației de raportare către arhitecturi de tip cloud, se poate concluziona că adopția acestor modele arhitecturale în compania analizată este fezabilă. Modelul cu cel mai mic impact, conform rezultatelor prezentate anterior, îl reprezintă cel de cloud public, iar compania a ales Infrastructure as a Service întrucât aceasta este cea mai rentabilă variantă în scenariul de față.
Procesul de implementare aplicabil oricărei adopții de cloud care are drept țintă migrarea unor aplicații existente din arhitecturi tradiționale către arhitecturi de tip cloud conține următoarele etape:
Consolidare și Unificare – acesta este procesul prin care se colectează datele sistemului din toate sursele de date existente și se integrează prin tehnici de de-duplicare, consolidare și îmbunătățire a calității datelor în vederea obținerii unei surse de date omogene care asigură integritatea datelor pentru diferite sisteme și servicii
Virtualizarea – virtualizarea reprezintă metoda prin care este posibilă rularea mai multor sisteme de operare pe același suport fizic. Acest proces este cunoscut și sub numele de virtualizare de platformă și este creat de un software care simulează mediile fizice și permite dispozitivului să găzduiască componente software specifice mediului virtual. Această etapă este necesară în procesul de adopție a arhitecturilor de tip cloud pentru a asigura alocarea de resurse dinamic[ și provizionarea la cerere a puterii de calcul. Figura de mai jos descrie pașii care trebuie realizați în această etapă pentru a asigura virtualizarea cu succes a infrastructurii:
Identificarea dispozitivelor țintă – în acest pas companiile trebuie să decidă care dispozitive fizice din infrastructura existentă fac subiectul procesului de virtualizare. În scenariul nostru, acestea sunt constituie de mașinile fizice pe care este găzduită aplicația supusă migrării
Planificarea capacității – pe baza activității zilnice întreprinsă în companie, se estimează o rată de capacitate necesară sistemelor migrate în cloud, care se folosește pentru planificarea eficientă a capacității necesare aplicației migrate. În studiul realizat de noi, s-a observat o rată 10% pe an de creștere a volumului de date stocate de aplicație, și un flux de accesări de 5 utilizatori concurenți. În funcție de acești parametrii, la contractarea serviciilor cloud se va ține cont în prevederea condițiilor contractuale privind capacitățile.
Calcularea ratei de rentabilitate – acesta este un proces cu caracter economic care stă la baza deciziei de migrare și care exprimă gradul de fructificare a investițiilor realizate
Migrarea propriu-zisă de la mașini fizice la medii virtuale – acest pas constă în decomisionarea arhitecturii învechite și crearea mediului virtual.
Standardizare – acesta este procesul în care compania definește fluxul informațional necesar implementării proceselor de business și fluxurilor de lucru pentru asigurarea înaltei performanțe a sistemelor informatice și un grad sporit de satisfacție în rândul clienților
Sisteme distribuite – acest proces constă în implementarea și stocarea dispersată a serviciilor pe diferite medii virtuale
Adopția arhitecturilor cloud computing – în această etapă, companiei îi sunt disponibile servicii cloud la cerere.
Fig. 6.4: Etape de migrare către cloud
6.4 CONCLUZII
Această implementare a fost realizată în vederea validării mecanismului de auditare a migrării unei aplicații existente în interiorul unei companii, către arhitecturi de tip cloud computing. În urma procesului de audit am observat un rezultat pozitiv, în sensul obținerii factorului de impact minim pentru modelul de livrare Infrastructure as a Service într-o arhitectură de cloud public – ceea ce demonstrează utilitatea modelului cloud în acest scenariu, iar furnizorul de cloud recomandat pe motive de rentabilitate și fiabilitate a fost Amazon. Am putut demonstra astfel eficiența mecanismului de evaluare al procesului de migrare. Acesta prezintă următoarele avantaje:
Metodologia de audit oferă un mediu de evaluare al impactului migrării către soluții de tip cloud, plecând de la practicile existente în comunitățile cloud, compensând astfel procese de evaluare costisitoare
Algoritmul de calcul al factorului de impact este bazat atât pe experiența existentă în procesele de migrare în ceea ce privește setarea scorurilor aferente fiecărei întrebări din chestionarul de audit, cât și pe interdependența dintre întrebări, considerând astfel în analiza factorului de risc totalitatea variabilelor contextuale din procesul de migrare
Procesul de audit oferă companiei un raport clar și ușor de citit cu privire la riscurile implicate de procesul de migrare și acțiunile care pot fi întreprinse în vederea adresării și diminuării lor.
După evaluarea factorului de risc și luarea deciziei de migrare, procesul de audit a continuat cu expunerea etapelor principale ale procesului de adopție. Acesta cuprinde, pe lângă activități clare premergătoare migrării în cloud și o serie de best practice-uri de care compania trebuie să țină cont pentru a spori adaosul de valoare adus de contractarea serviciilor cloud.
CAPITOLUL 7
IMPLEMENTAREA TEHNICILOR DE AUDIT AL ARHITECTURILOR CLOUD
ARHITECTURA GENERALĂ A PROCESULUI DE AUDIT
Procesul de audit a avut drept scop validarea abordării propusă în capitolul 5 privind procesul de auditare al serviciilor cloud din perspectiva:
Siguranței, definită în raport cu mecanismele de securitate implementate la nivelul aplicației analizate și cu gradul de implementare al acestora
Rentabilității, definită ca fiind invers proporțională cu diferența dintre rezultatele așteptate și cele realizate.
În vederea auditării am ales sistemul salesforce.com. Acesta reprezintă o aplicație CRM, livrată ca Software as a Service, într-o arhitectură de tip cloud public. Această aplicație a fost integrată în mediul companiei analizate ca urmare a unui studiu de fezabilitate realizat la nivel global pentru organizație, iar invențiile au fost suportate în mod partajat astfel:
60% din investiția totală a fost obținută de la nivel global
40% din investiția totală a fost suportată de către sucursala locală – la nivel de țară
În analiza privind rentabilitatea, am inclus în parametrul de investiție inițial atât fondurile globale cât și pe cele locale.
Figura de mai prezintă arhitectura implementării:
Fig. 7.1: Arhitectura Studiului de caz
Infrastructura în care am realizat acest studiu de caz include:
Aplicația de Identity Management este sistemul care provizionează conturi în aplicația salesforce.com. Astfel, în funcție de atributele specifice ale utilizatorului, creează următoarele tipuri de utilizatori în salesforce (care din perspectivă IdM reprezintă contul identității din sistemul de gestiune a identităților):
Utilizatori interni – aceștia sunt angajați ai companiei și au acces la roluri și profile de salesforce definite pentru acest tip de utilizatori în salesforce.
Utilizatori parteneri – aceștia sunt utilizatori externi companiei și prezintă particularitatea că, în salesforce aparțin unei alte organizații decât cea analizată. Pentru acest tip utilizatori sunt definite atât profile cât și roluri separate față de cele ale utilizatorilor interni menite a limita accesul utilizatorilor externi la datele sensibile ale companiei.
IdM provizionează atât utilizatori cât și profile și roluri acestora care oferă utilizatorilor de salesforce.com niveluri de acces diferite. Odată cu provizionarea utilizatorului, IdM trimite și identificatorul unic care este folosit de soluția de Federalizare de Identități pentru autentificarea utilizatorilor în salesforce.
Sistemul IdM comunică cu salesforce.com pentru provizionarea de utilizatori și roluri asignate acestora.
Sistemul de Federalizare de Identități și Single Sign On – acest sistem este folosit pentru procesul de autentificare al utilizatorului în salesforce.com. Mai mult decât atât, el are o componentă de Single Sign On, fapt ce ajută la îmbunătățirea experienței utilizatorului și oferă un grad sporit de securitate din perspectiva faptului că, nefiind necesară introducerea parolei, aceasta nu va fi supusă riscului de furt. Sistemul de Federalizare de Identități și Single Sign On folosește ca sursă de date Sistemul de Directory Server al companiei. Autentificarea se face pe baza unui identificator unic generat de Directory Server care nu dezvăluie date despre atributele utilizatorului care să poată fi interpretate la prima vedere.
Sistemul de Directory Server – acest sistem este sursa de date a sistemului de Identity Management pentru informațiile identitățile companiei. Este un sistem de încredere la nivel global pentru compania analizată. De asemenea, el reprezintă depozitul de date pentru Sistemul de Federalizare de Identități și Single Sign On. Sistemul de Directory Server este cel care generează username-ul folosit în toate sistemele companiei, username, care, așa cum am precizat, nu conține identificatori evidenți ai persoanei căreia aparține.
Sistem de criptare a traficului – acest sistem se află în DMZ și este o componentă ce criptează toate datele transmise din interiorul companiei către salesforce. Acest sistem este caracteristic companiei analizate, în sensul că, fiecare dintre sucursalele companiei mama – la nivel global, are un astfel de sistem.
Salesforce.com – acest sistem este cel supus analizei. El implementează o serie din funcționalitățile de CRM, mai exact cele specifice oportunităților companiei. Din perspectiva structurii de date, de interes pentru procesul de audit sunt următoarele entități:
Organizație reprezintă entitatea ce manipulează companiile din care fac parte utilizatorii provizionați de IdM
Utilizatorii reprezintă entitatea ce manipulează conturile consumatorilor de salesforce.com. Aceștia sunt de două feluri: interni, aparținând companiei analizată, și parteneri, aparținând unei alte companii.
Rolurile reprezintă o dimensiune de acces care permite utilizatorilor să folosească anumite obiecte din salesforce.
Profilele reprezintă o dimensiune de acces care permite utilizatorilor să aibă anumite drepturi pentru atributele obiectelor la care ei sunt autorizați conform rolului pe care îl au.
Exceptând organizațiile, toate celelalte obiecte sunt gestionate de IdM. Din perspectiva rolurilor și profilelor, acestea pot fi atât alocate de IdM cât și direct în salesforce.com de către un utilizator cu drepturi potrivite.
Toate datele procesate de către salesforce sunt stocate în cloud, însă, prin natura proceselor de business implementate la nivelul aplicației, ele nu prezintă grad sporit de confidențialitate.
Caracteristicile programului de implementare ale aplicației salesforce.com sunt prezentate în tabelul de mai jos.
Tabelul 7.1: Caracteristici ale aplicației supusă procesului de auditare a migrării în cloud
Datele prezentate în tabelul de mai sus reprezintă date de intrare pentru algoritmul de calcul al factorilor de siguranță și de rentabilitate.
PROCESUL DE AUDITARE
Procesul de audit este definit de următorii parametrii:
Auditorul a fost un auditor extern întrucât eu am fost cea care a realizat acest proces. Scopul meu în compania analizată era de a evalua gradul de siguranță și de rentabilitate a soluției salesforce. Această analiză a survenit ca urmare a tendinței companiei de inovație în domeniul IT. Astfel s-a dorit ca plecând de la povestea salesforce.com, să se analizeze impactul și valoarea adăugată pe care aceasta a adus-o companiei în vederea stabilirii strategiei de agilitate a departamentului IT.
Echipa de audit a fost constituită din:
Auditorul extern
Un observator din companie care a supravegheat întreg procesul de auditare în vederea garantării imparțialității auditorului extern în adresarea chestionarelor de audit.
Expert tehnic ce aparține companiei analizate – rolul lui a fost acela de a-mi oferii detaliile necesare acolo unde gradul de profunzime al aspectelor adresate de chestionarul de audit depășea cunoștințele mele, iar componentele respective adresau sisteme ale companiei și particularități de implementare.
Criteriile de audit au constat în:
Val IT – standard ce permite cuantificarea valorii adăugate pe care un proiect IT îl aduce companiei, descris în Anexe.
Modelul de securitate CSA prezentat în capitolul 2
COBIT – standard ce permite auditarea guvernanței într-o companie, prezentat în capitolul 5.
Principiile de bază și metodologiile care stau la baza procesului implementat de aplicația salesforce, privind fluxurile de date pe care le manipulează.
Normele ce reglementează raporturile de obligativitatea la care sunt supuși consumatorii de servicii cloud de furnizare a anumitor informații și respectarea anumitor reguli privind stocare și utilizarea datelor din aplicații cu caracter confidențial aparținând angajaților.
Probele de audit au constat în:
Minute de ședințe realizate în urma întâlnirilor cu business-ul care vizau anumite aspecte punctuale adresate de chestionarul de audit (acestea adresau în principal proceduri existente în companiei privind diferite procese de business și metodologia de abordare, gestionare și control al acestora)
Documentația tehnică existentă în companie cu privire la aplicația supusă auditării și la mecanismele de integrare a acesteia cu alte sisteme externe
Blueprint-urile proceselor existente în aplicația analizată
Cazul de business care a stat la baza deciziei de implementare
Livrabilele proiectului de implementare
Documentele programului din care sistemul de salesforce.com face parte
Strategia companiei privind departamentul IT.
Procedurile, procesele și metodologiile din interiorul companiei relaționate cu sistemul salesforce.com.
Raportul de audit a cuprins:
Concluziile procesului de audit – acestea au fost redactate plecând de la factorul de siguranță și cel de rentabilitate și au vizat gradul de îndeplinire a așteptărilor pentru programul din care face parte aplicația supusă auditării. Mai mult decât atât, pe durata procesului de auditare s-au folosit mai multe standarde și abordări de guvernanță și auditare, realizându-se astfel și maparea dintre contextul aplicației analizate și recomandările organismelor de audit certificate.
Rezultatele auditului – acestea constau în calcularea factorilor de impact și al celui de rentabilitate, precum și în validarea conformității cu practicile de securitate recomandate de CSA la un nivel mai mare decât cel minim acceptat la debutul programului din care aplicația analizată face parte.
Planul de audit a fost construit în funcție de disponibilitatea oamenilor specializați pe anumite domenii și s-a bazat pe următoarele principii:
Procesul de audit se va întinde pe durata a 15 zile lucrătoare, în fiecare dintre acestea adresându-se întrebările aferente unui domeniu supus auditării
Procesul de audit se realizează de către auditor, asistat de experții tehnici și de observator în fiecare dintre cele 15 zile de audit
Pe durata auditării unui domeniu, persoanele competente să ofere suport în eventualitatea necesității de informații detaliate oferă prioritate răspunderii la solicitările venite din partea echipei de audit în detrimentul activităților lor de lucru
În cursul ultimei săptămâni de audit, au loc întâlniri cu toate departamentele interesate în vederea comunicării rezultatelor de audit și a prezentării raportului de audit. Aceste întâlniri vor avea drept scop și interpretarea contextuală, în funcție de punctele de interes ale audienței, a rezultatelor prezentate.
Mecanismele de control supuse auditării sunt prezentate în A.2 Mecanisme De Securitate În Arhitecturi Cloud. Domeniile adresate în procesul de audit din perspectiva factorului de siguranță al aplicației de tip cloud sunt:
Governance and Enterprise Risk Management [2]
Traditional Security, Business Continuity and Disaster Recovery [104]
Compliance and Audit [6]
Portability and Interoperability [63]
Incident Response, Notification and Remediation [106]
Application Security [105]
Encryption and Key Management [99]
Identity and Access Management [11]
Virtualization [107]
Data Center Operations [58]
Information Management and Data Security [99] [58]
Din perspectiva evaluării factorului de rentabilitate, procesul de audit a adresat programul din care soluția de salesforce.com face parte.
Programul de audit a fost realizat de către echipa de audit și a constat în prezentarea persoanelor interesate din compania supusă analizei a tuturor activitățile și resursele necesare pentru a planifica, organiza și realiza unul sau mai multe procese de audit.
Scopul procesului de audit:
Scopul principal a fost calcularea factorului de siguranță și a celui de rentabilitate pentru aplicația auditată
Scopul extins a fost maparea arhitecturii existentă în programul salesforce cu recomandările și best practice-urile din domeniile de securitate și a celor de guvernanță a proceselor IT.
Procesul de audit a fost realizat folosind metodologia expusă în capitolul 5 [114].
EVALUAREA FACTORULUI DE SIGURANȚĂ AL APLICAȚIILOR DIN ARHITECTURI DE TIP “CLOUD COMPUTING”
În urma realizării planului de audit, s-a aplicat algoritmul de calcul al factorului de siguranță.
Riscul aplicației reprezintă factorul de incertitudine pe care îl manifestă securitatea aplicației cloud în raport cu vulnerabilitățile existente în domeniul adresat de procesul de evaluare al riscului. Altfel spus, riscul aplicației este calculat pe fiecare domeniu în parte.
Valoarea riscului aplicației din perspectiva domeniului analizat este dată de expresia:
, relația (7.1)
Unde:
este riscul aplicației în raport cu domeniul i
este constanta de corecție a riscului și este egală cu valoarea minimă a constantelor de corecție introduse în calcularea riscului. Ea are valoarea de 0.01 și este introdusă din considerente practice: nu există niciun domeniu care are risc asociat 0.
este gradul de implementare al mecanismului de securitate k
este constanta de corecție aplicată riscului aferent unui mecanism de securitate. În acest studiu de caz
n este numărul total de mecanisme de securitate incluse în chestionarul de audit. În acest studiu de caz s-au evaluat 262 de mecanisme de securitate, structurate pe domeniile supuse auditului astfel:
Governance and Enterprise Risk Management: n=41
Traditional Security, Business Continuity and Disaster Recovery: n=17
Compliance and Audit: n=40
Portability and Interoperability: n=8
Incident Response, Notification and Remediation: n=17
Application Security: n=12
Encryption and Key Management: n= 33
Identity and Access Management: n=62
Virtualization: n=10
Data Center Operations: n=17
Information Management and Data Security: n=5
Riscurile manifestate de aplicație în raport cu toate domeniile supuse analizei sunt:
Governance and Enterprise Risk Management:
Traditional Security, Business Continuity and Disaster Recovery:
Compliance and Audit:
Portability and Interoperability:
Incident Response, Notification and Remediation:
Application Security:
Encryption and Key Management:
Identity and Access Management:
Virtualization:
Data Center Operations:
Information Management and Data Security:
Riscul asumat al aplicației supusă analizei din perspectiva domeniului evaluat este influențat de nivelul de risc asumat specificat în definiția aplicației cloud. Pentru studiul de caz realizat, riscul asumat al aplicației este definit de relația de mai jos:
, relația (7.2)
Unde:
este riscul asumat pentru aplicația analizată în raport cu domeniul i
n este numărul total de mecanisme de control din domeniul i
este constanta de corecție aplicată riscului aferent unui mecanism de securitate
Riscurile asumate pentru aplicația auditată în raport cu toate domeniile supuse analizei sunt:
Governance and Enterprise Risk Management:
Traditional Security, Business Continuity and Disaster Recovery:
Compliance and Audit:
Portability and Interoperability:
Incident Response, Notification and Remediation:
Application Security:
Encryption and Key Management:
Identity and Access Management:
Virtualization:
Data Center Operations:
Information Management and Data Security:
Factorul de sigurață al aplicației supusă analizei în raport cu domeniului evaluat este:
, relația (7.3)
Unde:
este factorul de siguranță al aplicației în raport cu domeniul i
este riscul aplicației în raport cu domeniul i
AR este riscul asumat pentru aplicația analizată
este gradul de implementare al mecanismului de securitate k
este constanta de corecție aplicată riscului aferent unui mecanism de securitate
n este numărul total de mecanisme de securitate incluse în chestionarul de audit pentru domeniul i
Factorii de siguranță pentru aplicația auditată în raport cu toate domeniile supuse analizei sunt:
Governance and Enterprise Risk Management:
Traditional Security, Business Continuity and Disaster Recovery:
Compliance and Audit:
Portability and Interoperability:
Incident Response, Notification and Remediation:
Application Security:
Encryption and Key Management:
Identity and Access Management:
Virtualization:
Data Center Operations:
Information Management and Data Security:
Factorul de siguranță este exprimat procentual în raport cu gradul ideal de siguranță care este considerat a fi obținut în ipoteza în care nu există risc asociat acelui domeniu. Pentru calcularea factorului total de siguranță, aplicația de audit folosește următoarea relație:
, relația (7.4)
Unde:
FS este factorul total de siguranță
este factorul de siguranță al aplicației în raport cu domeniul i
n este numărul de domenii evaluate în procesul de audit
Așadar, factorul de siguranță al aplicației saleforce.com în raport cu cele 11 domenii analizate și raportat la un risc asumat 1 este de 97%, ceea ce demonstrează investiția sigură și eficientă din perspectiva securității datelor.
Rezultatele procesului de auditare și analiza acestora
Rezultatele procesul de audit sunt sumarizate în tabelul următor:
Fig. 7.2: Rezultatele procesului de audit al aplicației salesforce.com din perspectiva siguranței
În urma analizei acestor rezultate, se poate observa că domeniul a fost cel mai mult analizat a fost cel de Identity și Access Management, aceasta datorându-se atenției sporite pe care compania analizată o are asupra realizării unui mediu de acces al aplicațiilor companiei controlat, bazat pe reguli și fluxuri clare de aprobare și verificare a excepțiilor de acordare de surplus de drepturi. În analiza acestui domeniu s-a pus accent atât pe mecanismul de provizionare de utilizatori, cât și pe regulile de acordate de privilegii acestora ținându-se cont de Segregarea de Responsabilități, de procesul de Cerificare.
De menționat este faptul că, domeniul “Information Management and Data Security” are cel mai mic număr de mecanisme de control supuse analizei pentru că acesta se suprapuse în procente diferite cu alte domenii:
Encryption and Key Management
Application Security
Figura de mai jos reprezintă în mod grafic, gradul de analiză al fiecăruia dintre cele 11 domenii:
Fig. 7.3: Gradul de analiză al domeniilor adresate din perspectiva numărului de controale
Astfel, s-a acordat o atenție sporită următoarelor domenii:
Identity and Access Management
Governance and Enterprise Risk Management
Compliance and Audit
Encryption and Key Management
Aceasta a survenit ca urmare a strategiei IT existente la nivelul companiei de a îmbunătăți aspectele de securitate, întrucât în urma ultimului audit extern s-au descoperit o serie de neajunsuri cu impact negativ asupra companiei.
Din perspectiva riscului manifestat de aplicații, cel mai mic risc raportat la numărul total al controalelor îl manifestă Information Management and Data Security. Aceasta se datorează faptului că, așa cum am menționat și mai devreme, acest domeniu conține cele mai puține mecanisme de control de analizat întrucât se suprapune și cu alte domenii. Mai mult decât atât, în analiza riscului unei aplicații trebuie se țină cont de raportul dintre riscul rezultat în urma procesului de audit și riscul asumat (care din perspectiva guvernanței IT este cel acceptat).
Figura de mai jos prezintă în mod grafic, rapoartele dintre riscurile rezultate în urma procesului de audit și riscurile asumate pentru domeniile analizate:
Fig. 7.4: Raportul dintre riscul aplicației și riscul asumat
Așa cum se poate observa din figura de mai sus, domeniile în care s-a depășit gradul de risc asumat sunt:
Incident Response, Notification and Remediation
Application Security
Encryption and Key Management
Acestea sunt ariile în care compania trebuie să mai investească în integrarea cu salesforce.com.
Din perspectiva factorului de siguranță, acesta a variat de la 94.625% până la 98.623%, obținându-se o medie de 97.305%, fapt ce recomandă salesforce.com ca un sistem sigur.
Figura de mai jos prezintă în mod grafic, factorii de siguranță obținuți pentru fiecare domeniu în parte:
Fig. 7.5: Analiză comparativă între factorii de siguranță obținuți
Odată validat gradul de siguranță al aplicației, atenția mea s-a îndreptat către stabilirea gradului de conformitate mediului supus auditării cu recomandările realizate de :
CSA în modelul de securitate prezentat în capitolul 2.
ISACA în framework-urile de control folosite pentru evaluarea gradului de guvernanță a companiei. Framework-urile adresate în acest audit sunt:
COBIT 5
Cloud Computing Management Audit/Assurance Program
Risk IT
Practicile existente privind analiza guvernanței și controlul operativității companie
Aceste referințe bibliografice au fost cele folosite în definirea mecanismelor de control ce au fost supuse analizei.
Pentru stabilirea gradului de conformitate cu cele prezentate mai sus, s-a considerat nivelul de risc asumat în raport cu care s-a definit gradul minim de siguranță necesar pentru a se putea concluziona că un domeniu respectă standardele specificate.
Astfel, factorul minim de siguranță este definit de:
, relația (7.5)
Unde:
este factorul minim de siguranță în raport cu care se evaluează conformitatea
este nivelul de risc asumat – care în studiul nostru de caz este 2.
este constanta de conformitate și este dată de nivelul de risc asumat.
Gradul de conformitate al unui domeniu în raport cu standardele este definit de relația:
, relația (7.6)
Unde:
este nivelul de conformitate al domeniului i
este factorul minim de siguranță în raport cu care se evaluează conformitatea
este factorul de siguranță al domeniului i
este conformitatea domeniului i, care se calculează folosind următoarea formulă:
, relația (7.7)
Unde:
este conformitatea domeniului i. Acesta asigură că, dacă nu este atins factorul minim de siguranță, atunci nivelul de conformitate al acelui domeniu este zero.
este factorul minim de siguranță în raport cu care se evaluează conformitatea
este factorul de siguranță al domeniului i
Factorii de conformitate pentru aplicația auditată în raport cu toate domeniile supuse analizei sunt:
Governance and Enterprise Risk Management:
Traditional Security, Business Continuity and Disaster Recovery:
Compliance and Audit:
Portability and Interoperability:
Incident Response, Notification and Remediation:
Application Security:
Encryption and Key Management:
Identity and Access Management:
Virtualization:
Data Center Operations:
Information Management and Data Security:
Figura de mai jos prezintă rezultatele în mod grafic:
Fig. 7.6: Factori de conformitate ai domeniilor analizate în raport cu standardele folosite
Se poate concluziona că, aplicația salesforce.com este conformă cu cerințele de securitate care definesc o aplicație ca fiind sigură în 10 din cele 11 domenii analizate. Domeniul neconform este Portability and Interoperability. Analizând mecanismele de control ale acestui domeniu s-a constatat că interoperabilitatea cu alte sisteme este asigurată, însă la domeniul portabilitate salesforce.com trebuie să aducă îmbunătățiri.
Acest domeniu nu a fost considerat ca având prioritate așa încât raportul de audit a concluzionat conformitatea cu standardele și a catalogat aplicația salesforce.com implementată pe modelul de arhitectură prezentat în secțiunea 7.1 este sigură.
Din perspectiva factorului de siguranță, raportul de audit a recomandat îmbunătățirea controalelor din următoarele domenii:
Portability and Interoperability
Application Security
EVALUAREA FACTORULUI DE RENTABILITATE AL APLICAȚIILOR DIN ARHITECTURI DE TIP “CLOUD COMPUTING”
Factorul de rentabilitate calculat de aplicația de audit este dependent de următoarele mărimi:
Nivelul așteptat de maturitate al programului din face parte salesforce.com
Investițiile totale realizate în programul din face parte salesforce.com
Costul investițiilor realizate în programul din face parte salesforce.com din perspectiva domeniului evaluat.
Durata programului din face parte salesforce.com
Venitul mediu estimat pentru programul din face parte salesforce.com
Costul operațional așteptat pentru programul din face parte salesforce.com
Riscul asociat aplicației salesforce.com
Tabelul de mai jos prezintă datele specifice aplicației, relevante procesului de evaluare al factorului de rentabilitate:
Tabelul 7.2: Caracteristici ale aplicației supusă procesului de auditare a migrării în cloud
Procesul de calculare al factorului de rentabilitate pleacă de la gradul de maturitate al metricilor de proces ale programului analizat și, pe baza acestuia introduce un factor de corecție în rata de actualizare a veniturilor și cheltuielilor care are influență directă în calculul valorii anuale nete. Factorul de rentabilitate este dat de valoarea actualizată netă întrucât aceasta exprimă gradul de profitabilitate a investiției.
Scorul de maturitate reprezintă gradul de maturitate al programului supus analizei și este dat de expresia:
=3.22, relația (7.8)
Unde:
SM este scorul de maturitate al programului supus analizei
este scorul de maturitate al metricii i
m este numărul total de metrici de proces incluse în chestionarul de audit
Pe baza scorului de maturitate, se calculează indicele de realizare ca fiind raportul dintre scorul de maturitate și nivelul de maturitate așteptat pentru proiectul respective:
, relația (7.9)
Unde:
este indicele de realizare al programului supus analizei
SM este scorul de maturitate al programului supus analizei
ML este nivelul așteptat de maturitate al programului supus analizei, iar în acest studiu de caz acesta este egal cu 3
Pe baza indicelui de realizare, se calculează indicele de nerealizare ca complementul său:
=0, relația (7.10)
Unde:
este indicele de nerealizare al programului supus analizei
este indicele de realizare al programului supus analizei
este realizarea programului/portofoliului supus analizei, care se calculeză folosind următoarea formulă:
, relația (7.11)
Unde:
este realizarea programului/portofoliului. Acesta asigură că, dacă nivelul de maturitate rezultat în urma procesului de audit este mai mare decât nivelul așteptat, indicele de nerealizare va fi nul. În studiu de caz realizat acesta este 1, așadar indicele de nerealizare are valoarea 0.
este indicele de realizare al programului supus analizei
Indicele de nerealizare are impact direct în rata de actualizare.
Rata de actualizare este metoda prin care se asigură comparabilitatea parametrilor economici și a indicatorilor financiari ce se realizează în perioade diferite de timp, putându-se astfel clasifica o investiție ca fiind rentabilă sau nu. Pentru exprimarea factorului de rentabilitate a unei aplicații din arhitecturi cloud, rata de actualizare este exprimată sub forma:
, relația (7.12)
Unde:
i este rata de actualizare folosită pentru calculul factorului de rentabilitate
este indicele de nerealizare al programului supus analizei. În studiul de caz analizat acesta are valoarea 0.
este costul investiției asociată programului din care face parte aplicația analizată. În studiul de caz analizat acesta are valoarea 0.05 conform detaliilor aplicației prezentate anterior.
R este factorul de risc asociat cu aplicația analizată
Având în vedere că ținta acestui proces de audit a fost evaluarea programului din care face parte salesforce.com și ca atare pentru ea există calculat riscul asociat acestei aplicații, rata de actualizare este calculată folosind următoarea expresie:
, relația (7.13)
Unde:
i este rata de actualizare folosită pentru calculul factorului de rentabilitate
este indicele de nerealizare al programului supus analizei
este costul investiției asociată programului din care face parte aplicația analizată
R este factorul de risc asociat cu aplicația analizată
Factorul de risc este calculat ca fiind media riscurilor asociate cu domeniile supuse procesului de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud, mediată de numărul total de domenii, astfel:
, relația (7.14)
Unde:
R este factorul de risc asociat cu aplicația analizată
n este numărul total de domenii supuse procesului de audit care are drept obiectiv evaluarea siguranței unui serviciu cloud
este factorul de siguranță aplicației în raport cu domeniul k
Valoarea actualizată netă (VAN) reprezintă o metodă de evaluare a investițiilor care este direct dependentă de costurile implicate și de veniturile pe care acestea le generează. VAN face compararea între fluxul monetar degajat pe durata derulării programului analizat și efortul investițional implicat în realizarea acestuia. Formula de calcul a acesteia este:
relația (7.15)
Unde:
VAN este valoarea actualizată netă pentru programul supus analizei
reprezintă costurile totale aferente programului
reprezintă veniturile totale estimate aferente programului
Pentru calcularea acestor valori am folosit datele de intrare prezentate în tabelul 6.2, pe care le-am reorganizat conform următorului tabel:
Tabelul 7.3: Detaliile financiare ale programului salesforce.com
Veniturile totale aferente programului analizat se calculează ținând cont de următorii factori:
Venituri anuale estimate angajate de aplicația analizată
Perioada programului – aceasta este de obicei exprimată în ani.
Rata de actualizare
Astfel, definiția veniturilor totale asociate programului este:
relația (7.16)
Unde:
reprezintă veniturile totale aferente programului
y reprezintă numărul de ani constând în durata proiectului
reprezintă venituri anuale estimate aferente programului
i reprezintă rata de actualizare folosită pentru calculul factorului de rentabilitate
Costurile totale aferente programului analizat se calculează ținând cont de următorii factori:
Investiții inițiale
Costuri operaționale
Perioada programului – aceasta este de obicei exprimată în ani
Rata de actualizare
Astfel, definiția costurilor totale asociate programului este:
relația (7.17)
Unde:
reprezintă costurile totale aferente programului
reprezintă investițiile totale ale programului
y reprezintă numărul de ani constând în durata proiectului
reprezintă costurile operaționale anuale aferente programului
i reprezintă rata de actualizare folosită pentru calculul factorului de rentabilitate
Ținând cont de relațiile 7.16 și 7.17, valoarea actualizată netă se exprimă ca:
, relația (7.18)
Pe baza valorii actualizate netă, se calculează factorul de rentabilitate ca fiind:
, relația (7.19)
Unde:
reprezintă factorul de rentabilitate al programului
VAN este valoarea actualizată netă pentru programul supus analizei. În studiul de caz acesta are o valoare pozitivă, fapt ce face investiția rentabilă.
Așadar , factorul de rentabilitate în studiul de caz prezentat este 1.
În vedere evaluării celuilalt termen economic specific domeniului investițional, și anume rata internă a rentabilității, folosim următoarea formulă:
, relația (7.20)
Unde:
RIR este valoarea ratei interne de rentabilitate a investiției supusă analiză
reprezintă valoarea actualizată netă pozitivă (cea care denotă că investiția este oportună).
reprezintă valoarea actualizată netă negativă (cea care denotă că investiția nu este oportună).
reprezintă rata de actualizare folosită pentru calculul .
reprezintă rata de actualizare folosită pentru calculul .
Metodologia folosită pentru aflarea și este:
se calculează valoare VAN:
relația (7.21)
Așadar:
, relația (7.22)
Unde:
reprezintă valoarea actualizată netă negativă (cea care denotă că investiția nu este oportună)
reprezintă valoarea actualizată netă calculată la pasul c,
Iar
, relația (7.23)
Unde:
reprezintă rata de actualizare folosită pentru calculul
reprezintă rata de actualizare calculată la pasul b
Rata internă de rentabilitate a aplicației salesforce.com, pentru acest studiu de caz este:
, relația (7.24)
Putem concluziona că rata internă de rentabilitate a aplicației salesforce.com este de 14%.
Rezultatele procesului de auditare și analiza acestora
Rezultatele procesului de auditare s-au obținut pe baza metricilor de proces adresate conform cu modelul Val IT, ținând cont de practicile actuale în astfel de procese.
Tabelul de mai jos prezintă scorurile de maturitate obținute pe fiecare domeniu Val IT analizat:
Tabelul 7.4:Nivelurile de maturitate al programului Salesforce rezultate în urma auditului
Figura de mai jos prezintă scorul de maturitate obținut pe fiecare domeniu, prin comparație cu scorul total și cel estimat:
Fig. 7.7: Scorul de maturitate obținut în analiza factorului de rentabilitate pentru programul Salesforce
După cum se poate observa în datele prezentate mai sus, gradul cel mai mare de maturitate este în domeniul de gestiune a portofoliului. Plecând de la aceste valori s-a calculat indicele de realizare pentru fiecare domeniu, reprezentate în figura următoare:
Fig. 7.8: Indicii de Realizare ai programului Salesforce
Valorile prezentate mai sus relevă faptul că programul și-a atins scopul din toate perspectivele, având evoluția cea mai mare în domeniul de gestiune de portofoliu unde a depășit așteptările inițiale. Acest aspect este foarte important deoarece relevă gradul de maturitate la care a ajuns compania în managementul unei componente strategice aparținând trend-ului de adopție al arhitecturilor de tip cloud. Întrucât toate domeniile au indice de realizare cel puțin egal cu unitatea, nu există corecție negativă impusă de această componentă a procesului de audit în calculul factorului de rentabilitate.
Astfel, pentru calcularea ratei de actualizare care are impact direct asupra factorului de rentabilitate, s-au luat în calcul riscurile introduse de fiecare dintre cele 11 domenii supuse auditului pentru stabilirea gradului de securitate al aplicației saleforce.com.
Figura de mai jos prezintă riscurile aplicației salesforce.com, a căror medie aritmetică a inclus un factor de corecție pozitiv al ratei de actualizare, în sensul că rata de actualizare a crescut, fapt ce a determinat scăderea Valorii Actualizate Nete:
Fig. 7.9: Risc al domeniilor supuse auditării privind siguranța aplicației
Valorile prezentate mai sus relevă faptul că cel mai mic coeficient de risc este în domeniul Identity and Access Management și că analiza riscului manifestat de aplicația de cloud are un aport negativ în Valoarea Actualizare Netă mai mic decât costul investiției, ceea ce demonstrează încă o dată gradul sporit de stabilitate al soluției salesforce.com.
Plecând de la analizarea factorului de siguranță al aplicației salesforce.com și al celui de maturitate al programului Salesforce s-a calculat Valoarea Actualizată Netă, reprezentând un factor economic care specifică, în funcție de valoarea sa pozitivă sau negativă, dacă investiția realizată în programul analizat este sau nu reușită. În studiul de caz prezent, a fost o valoare pozitivă care a condus la stabilirea factorului de rentabilitate la unitate, recomandând astfel programul de implementare a soluției salesforce ca fiind rentabil din perspectiva valorii de business pe care a adus-o companiei. Mai mult decât atât, acest program a demonstrat depășirea maturității așteptate de către business oferind astfel cadrul propice dezvoltării unei strategii de inovație în IT bazată pe arhitecturi de tip cloud.
Valoarea Actualizare Netă obținută în analiza factorului de rentabilitate a fost ulterior folosită în calcularea următorului indice economic, cel al ratei interne de rentabilitate.
Tabelul de mai jos reprezintă în mod schematic datele utilizate pentru calculul Valoarea Actualizare Netă pentru programul auditat:
Tabelul 7.5: Datele financiare ale programului Salesforce
Reprezentarea grafică comparativă a cheltuielilor și veniturilor actualizate pe durata proiectului este prezentată în figura următoare:
Fig. 7.10: Raportul cheltuieli venituri pentru programul Salesforce
Pentru calcularea valorii negative a Valorii Actualizate Anuală necesară pentru estimarea ratei interne de rentabilitate am crescut rata de actualizate cu 0.03, obținând rezultatele prezentate în tabelul de mai jos:
Tabelul 7.6: Datele financiare folosite în calculul rentabilității
Reprezentarea grafică comparativă a cheltuielilor și veniturilor actualizate pe durata proiectului pentru noua valoare a ratei de actualizare este prezentată în figura următoare:
Fig. 7.11: Cheltuieli și venituri pentru proiectul Salesforce în cazul majorării ratei de actualizare
Se poate observa astfel că veniturile se diminuează considerabil, fapt ce duce la o Valoare Actualizată Netă negativă.
Folosind aceste valori, am calculate rate internă de rentabilitate:
, relația (7.25)
Considerând că dobânda medie anuală la băncile din România este de 6 % pe an, programul Salesforce a reușit, conform ratei interne de rentabilitate prezentată mai sus, să valorifice investițiile realizate cu o eficiență mai mult decât dublă decât scenariul în care investițiile erau pătrate în bancă, fapt ce o califică drept o investiție profitabilă.
7.5 CONCLUZII
Acest studiu de caz a fost realizat în vederea validării mecanismului de auditare a soluțiilor cloud propuse în capitolul 5 al acestei lucrări. Scopul abordării oferite a fost acela de a verifica și evalua atât gradul de siguranță pe care îl oferă serviciile de tip cloud din perspectiva mecanismelor de securitate cât și acela de a evalua gradul de guvernanță al companiei consumatoare asupra infrastructurii sale IT care este extinsă cu ocazia adopției arhitecturii cloud în Internet. Am vrut să analizez astfel gradul de îndeplinire al obiectivelor programului Salesforce de a aduce un plus de valoare companiei.
Astfel, plecând de la mecanisme de securitate specifice arhitecturile tradiționale [99] și moștenite de arhitecturile de tip cloud datorită gradului sporit de aplicabilitate, și incluzând controalele specifice conceptului de cloud computing, am analizat gradul lor de implementare în arhitectura supusă auditului atât din perspectiva consumatorului de servicii cloud.
Am adresat în procesul de audit 11 domenii recomandate de CSA [17]. Prin corelarea tuturor probelor de audit specificate în secțiunea 7.2, am răspuns celor două chestionare de auditare – cel pentru evaluarea gradului de implementare al mecanismelor de control și securitate și cel pentru stabilirea gradului de maturitate din perspectiva îndeplinirii scopului proiectului.
Am obținut în acest fel date concludente care au demonstrat gradul sporit de guvernanță pe care compania analizată îl are asupra aplicației cloud, dar și operabilitatea eficientă de care dispune raportat la același serviciu. Am obținut un factor de siguranță care asigura un risc mai mic decât cel asumat, iar salesforce.com s-a dovedit a fi în conformitate cu standardele folosite pentru evaluare în 10 din cele 11 domenii auditate.
Ce-a de-a doua analiză a fost realizată pe considerente economice, în sensul cuantificării aportului de valoare pe care aplicația salesforce.com și-a adus-o la nivelul companiei, dar și pentru a evalua corecția negativă asupra Valorii Actualizate Nete pe care indicele de nerealizare al obiectivelor privind maturitatea proceselor de gestiune și guvernanță asupra programului o impune. Datorită strategiei sănătoase și eficiente de dezvoltare în domeniul IT pe care compania analizată a demonstrat-o, această corecție a rezultat nulă, gradul de realizarea al țintei fiind mai mare sau egal cu unitate, în toate domeniile analizate. Astfel, singura corecție realizată asupra ratei de actualizare anulă în sensul creșterii ei, s-a materializat în riscul descoperit la nivelul domeniilor analizate în prima parte a procesului de audit. Ținând cont de toți acești factori am obținut o Valoare Actualizată Netă pozitivă, fapt ce recomandă investiția ca fiind de succes. Rata internă de rentabilitate a fost evaluată la 14% care, comparativ cu rata internă medie de rentabilitate la nivelul companiei pe departamentul IT care este de 10%, a demonstrat că strategia de inovație a departamentului IT trebuie să se bazeze pe implementarea soluțiilor cloud.
Sumarizând rezultatele procesului de audit, putem concluziona următoarele aspecte:
Aplicația salesforce.com implementată în arhitectura descrisă în secțiunea 7.1 prezintă un factor de siguranță de 97% fapt ce o califică drept o aplicație stabilă, care implementează la un grad înalt de performanță mecanisme de securitate consacrate care și-au dovedit eficiența și fiabilitatea de-a lungul proiectelor și dezvoltărilor din domeniul IT.
Aplicația saleforce.com este conformă cu standardele folosite pentru analizarea acesteia în 10 din cele 11 domenii analizate, media gradului de conformitate pe aceste 10 domenii fiind de 97.7%.
Gradul de conformitate din perspectiva tuturor domeniilor este de 90.9% tradus în faptul că 10 din cele 11 domenii de securitate analizate au avut factor de siguranță mai mare sau cel puțin egal cu 95%. Domeniul neconform a avut un factor de siguranță 94.62% ceea ce înseamnă că efortul pentru a deveni conform nu este semnificativ.
Programul de implementare al aplicației supusă auditului a depășit nivelul de maturitate așteptat, ceea ce demonstrează gradul de adaptabilitate crescut al companiei la schimbare, precum și tendința de acomodare rapidă și eficientă cu abordarea oferită de arhitecturile cloud. Acest lucru consacră surplusul de valoare adus de astfel de arhitecturi în companii atât din perpectivă IT, cât și business.
Programul de implementare al aplicației și-a demonstrat rentabilitate și din perspectivă economică prin obținerea unei rate interne de rentabilitate superioară mediei celorlalte programe implementate în departamentul de IT.
Așadar putem concluziona că, salesforce.com este o poveste de succes în compania supusă analizei, care poate fi invocată în vederea susținerii dezvoltării strategiei de inovație în departamentul IT către arhitecturi de tip cloud computing.
CONCLUZII
C.1. CONCLUZII GENERALE
Dezvoltarea tehnologică a zilelor noastre a evoluat într-o manieră galopantă în ultimul timp, făcând orice informație, cunoștință, statistică sau abordare disponibilă oricărui consumator de Internet prin simpla accesare a acestuia. Odată cu acest volum exorbitant de date a apărut necesitatea clasificării și totodată cea a protejării ei, atât din perspectiva accesului, cât și a transportării și stocării ei. Conceptul de proprietate intelectuală sau de proprietate a datelor digitale s-a dezvoltat în complexitate, atrăgând după sine preocupări intense de standardizare și reglementare a normele menite să protejeze datele confidențiale.
Pe fondul acestor schimbări radicale la nivel tehnologic, in 2008 a venit și criza economică, fapt ce a declanșat necesitatea de remodelare a mediilor IT în vederea optimizării proceselor de business, atât din perspectiva lansării de noi produse care să satisfacă nevoile unei clientele schimbătoare care nu mai dispune de putere de cumpărare mare, cât și din perspectiva eficientizării costurilor IT asociate cu operarea, gestionarea și întreținerea echipamentelor hardware și componentele software care implementează fluxurile de date din companie.
Flexibilitatea și agilitatea în domeniul IT au devenit astfel din ce în ce mai stringente, conturându-se tendințe de externalizare a acestor tipuri de servicii. În acest context, cloud computing-ul vine în întâmpinarea tuturor necesităților menționate mai sus, oferind un mediu dinamic, disponibil și el, ca orice informație de pe Internet, la o simplă accesare a paginii web a unui furnizor.
În realizarea acestei teze am dorit ca, plecând de la conceptele de baza care fundamentează cloud computing-ul ca și model de alocare și folosire a infrastructurii hardware, să analizez componentele cheie ale acestui concept, astfel încât să pot formula o părere obiectivă despre raportul beneficii/riscuri caracteristic acestei arhitecturi.
Odată cu alegerea acestei tematici, în mintea mea s-au conturat trei direcții de cercetare, având ca scop răspunsul la următoarele întrebări:
Cum decide o companie că este oportun să migreze sper un anumit model de cloud?
Într-o arhitectură hibridă, cum se protejează accesul partajat la datele confidențiale?
Odată contractat serviciul cloud, cum poate o companie să se asigure că sunt îndeplinite condițiile contractuale privind securitate datelor?
Răspunsul la aceste întrebări este același:”auditul”.
Procesul de audit este cel care asigură compania că a luat decizia corectă pentru infrastructura IT și mediul de business de migrare către un anumit model de cloud, prin adresarea aspectelor relevante acelei arhitecturi și evaluarea caracteristicilor specifice aplicației sau sistemului suspus migrării. Prima componentă de audit prezentată în această lucrare demonstrează rolul fundamental al auditului chiar din faza incipientă a procesului de adopție, aducând următoarele avantaje care fac diferența între o decizie corectă și una incorectă:
Auditul de evaluare al procesului de migrare către arhitecturi de tip cloud oferă vizibilitate în cadrul companiei, din perspectiva încunoștințării factorilor decizionali de aspectele cheie ale aplicației supuse adopției cloud. Astfel, acest proces poate prezenta caracteristicile aflate pe durata evaluării care trebuie supuse unor procese de îmbunătățire în vederea optimizării fluxurilor informaționale implementate la nivelul lor
Auditul de evaluare al procesului de migrare către arhitecturi de tip cloud oferă oportunitatea familiarizării cu acest concept în companie, prin oferirea unor imagini comparative privind furnizorii de astfel de servicii și modelele arhitecturale existente
Auditul de evaluare al procesului de migrare către arhitecturi de tip cloud oferă o analiză specifică pe sistemul respectiv, care ia în calcul toate componentele particulare și integrările specifice implementate, astfel că, decizia nu se ia pe motive de trend-uri tehnologice, ci din raționamente bazate pe analize
Auditul de evaluare al procesului de migrare către arhitecturi de tip cloud oferă o imagine clară asupra rentabilității modelului de cloud cel mai potrivit companiei care solicită un astfel de audit prin punctarea clară a beneficiilor și neajunsurilor. Prin procesul de audit se evită neajunsurile survenite ca urmare a neînțelegerii unor termeni specifici prezentați de diferiți furnizori sau terți care promovează și comercializează astfel de arhitecturi.
Auditul de evaluare al procesului de migrare către arhitecturi de tip cloud asigură stabilirea unei strategii corecte de migrare, luând în considerare toți parametrii factuali și contextuali în care se realizează migrarea. De asemenea, un astfel de proces punctează și etapele fundamentale într-o strategie de inovației IT și stabilește măsurile premergătoare care trebuie să se realizeze la nivelul companiei analizate
Auditul de evaluare al procesului de migrare către arhitecturi de tip cloud asigură evaluarea corectă a termenilor contractuali care trebuie punctați în eventualitatea migrării către cloud, astfel încât, bazându-se pe analiza obiectivă a situației as-is și pe cerințele de business și necesitățile de îmbunătățire, conturează situația to-be
Având în vedere toate avantaje menționate mai sus precum și neajunsurile implicite rezultate de acestea în cazul neantrenării procesului de audit în vederea evaluării procesului de migrare către cloud, este evidentă necesitatea unei proceduri standardizate pentru astfel de procese, standardizare care oferă următoarele avantaje:
Cadru comun la nivel comunitar de adresare a problematicilor legate de migrarea în cloud, fapt ce asigură atât un sistem de valori comun cât și un grad de satisfacere a nevoilor ridicat
Realizarea unor best practice-uri care și-au demonstrat eficiența și eficacitatea în situații practice reale
Posibilitatea certificării unui anumit proces, fapt ce face ca decizia de business să fie controlată, sporind astfel încrederea în rândul factorilor decizionali
Adresarea tuturor dependințelor survenite cu ocazia migrării într-un mod unitar, standardizat, bazat pe practici consacrate
Asigurarea realizării tuturor cerințelor premergătoare, acestea fiind definite în funcție de aria funcțională din care fac parte
În ceea ce privește evaluarea serviciilor cloud, aceasta este adresată tot de către componenta de audit, însă de această data, din alte perspective. Așadar o altă direcție de cercetare pe care am urmat-o a vizat stabilirea unui framework de auditare a componentelor cloud pentru a oferi o cuantificare a riscului legate de cloud.
Cercetările în acest domeniu sunt încă la început, însă s-au făcut progrese semnificative, practica ajungând la stadiul de dezvoltare ce oferă:
Standardele de modelare și definire a modelul de securitate în cloud oferit de CSA
Aplicarea standardelor ISACA de guvernanță și risc din arhitectura tradițională în arhitectura cloud, prin adaptarea lor la specificitățile cloud-ului
Best practice-uri și recomandări de control al furnizorilor de cloud
Exemple practice de mecanisme de control și monitorizare a activității furnizorilor
Povești de succes ale implementărilor în cloud și mecanismele de securitate aplicabile în acele scenarii
Plecând de la această bază generoasă de cunoștințe, auditul în cloud computing se dezvoltă din ce în ce mai mult și odată cu trecerea anilor și mărirea numărului de practicanți, se și maturizează. Dacă implementarea unui proces de audit privind evaluarea impactului migrării la cloud este opțională, fiind recomandată din motivele expuse mai sus, procesul de audit în cloud este obligatoriu, el înlocuindu-l pe cel tradițional în cazul companiilor care au optat pentru acest model IT. Cu toate acestea ținta procesului de auditare a arhitecturilor cloud este mai complexă decât auditul în arhitecturi tradiționale din mai multe perspective .
Așadar, procesul de audit este cel care are un rol foarte important în abordarea unei arhitecturi cloud, putând asigura și certifica conformitatea cu standardele de calitate existente și implementarea la nivelul furnizorilor principiilor și mecanismelor de securitate, control și guvernanță care să asigure un grad de operabilitate crescut și performanțe optime.
În încheierea acestei secțiuni de concluzii, vreau să reiterez faptul că, fenomenul Cloud Computing este, cu siguranță, una dintre cele mai ispititoare arii tehnologice din zilele noastre atât datorită costurilor reduse pe care le implică cât și datorită flexibilității de care dă dovadă. Această nouă tehnologie oferă foarte multe beneficii rezultate din capacitățile sale de optimizare în procesarea datelor, dar prezintă și o serie de riscuri care pot fi de multe ori mai semnificative decât avantajele. Concluzia la care am ajuns în urma activităților de cercetare pe care le-am desfășurat a fost aceea că acest tip de concept este benefic și potrivit în orice fel de împrejurare – ceea ce face diferența între o poveste de succes a cloud-ului și un eșec nu ține de tehnologie în sine, ci de procesele de evaluare și analiză a potrivirii anumitor modele de cloud pe necesitățile consumatorului. Astfel, pot spune că, un proces de audit eficient împreună cu proprietățile caracteristice ale cloud computing-ului vor oferi în orice împrejurare un surplus de valoare companiei care le implementează.
C.2. CONTRIBUȚII ORIGINALE
Scopul cercetării mele a fost acela de a veni în întâmpinarea necesității unei companii de a răspunde prezent acestui nou concept – cloud. Plecând de la această idee, am căutat un mod eficient de adresa toate neajunsurile, riscurile și provocările acestui domeniu. Activitatea mea s-a desfășurat pe trei direcții de cercetare:
Procesul de evaluare al adopției arhitecturilor cloud computing cu toate aspectele ținând de etapele premergătoare migrării, criterii de evaluare a diferitelor modele și furnizori de cloud, analiza oportunității inovației mediul IT dintr-o companie pentru adresarea necesității de flexibilitate și agilitate a componentelor IT
Integrarea sistemelor în arhitecturi hibride care conțin atât aplicații din interiorul companiei cât și componente cloud – acest subiect a fost analizat din perspectiva securizării datelor în mișcare, în procesare și în repaus, precum și din perspectiva controlului accesului la informații.
Procesul de auditare al serviciilor cloud prin evaluarea mecanismelor de control existente într-o infrastructură catalogată drept sigură, dar și din perspectiva factorilor financiari implicați în adopția cloud materializată în factorul de rentabilitate.
În domeniul ce vizează auditul procesului de migrare către arhitecturi de tip cloud, am implementat o nouă abordare de tratare a unui proces de migrare. Astfel, plecând de la principiile de bază și conceptele arhitecturale existente în arhitecturi de tip cloud, am realizat o corelare între arhitecturile tradiționale și cele cloud, în urma căreia, am conturat următoarele domenii funcționale din perspectiva căror trebuie analizat un proces de adopție al cloud-ului:
Complexitatea Implementării
Risc și Conformitate
Infrastructură
Performanță
General – acesta include aspecte ce se mapează pe mai multe din cele 4 domenii menționate anterior
Am analizat apoi aspectele și mecanismele de control recomandate la nivelul practicii mondiale în domeniul cloud, în urma cărora, pe baza principiilor, standardelor și a studiile de caz, am realizat un set de întrebări și răspunsuri posibile pentru fiecare dintre acestea. Acestor răspunsuri le sunt asociate scoruri de impact calculate de mine bazându-mă pe experiența personală și pe studiile de caz analizate. De asemenea am definit, în procesul de audit și noțiunea de dependință între întrebări care modelează influența pe care o are răspunsul unei întrebări în factorul de impact al răspunsului întrebării de care ea este dependentă. Am inclus toate aceste concepte și variabile contextuale într-un algoritm ce mi-a permis:
Cuantificarea factorului de risc al migrării aplicației cloud
Realizarea unor statistici reale privind principalele diferențe între abordare tradițională și abordarea cloud a aplicației supusă auditării. Astfel am putut pune accent pe ariile funcționale cu risc ridicat
Analiza comparativă a factorilor de risc asociați cu diferitele modele de cloud
Oferirea de sugestii privind un anume furnizor care se mapează pe cerințele aplicației analizate, luând în considerare factorul minim de risc pentru modelul de cloud adresate
Analiza mea a mers mai departe, în sensul realizării unui plan de adopție prin propunerea etapelor generale ce trebuie urmate în eventualitatea migrării aplicației alese. Aceste procese au fost predefinite și au luat în considerare o serie de etape fixe – aplicabile tuturor adopțiilor de cloud, și o serie de etape specifice atât modelelor de cloud, cât și anumitor domenii funcționale adresate de chestionarul de audit.
Principalele beneficii ale abordării propuse de mine sunt:
Realizarea unei analize ample, holistice, a aplicației pretabilă procesului de adopție, prin exprimarea caracteristicilor sale în concepte auditabile, materializă în factorul de impact
Crearea unui mecanism eficient de calculare al factorului de impact care oferă o imagine contextuală asupra aplicației, având ca ieșiri scoruri calculate pentru fiecare tip de model implementat
Oferirea vizibilității în cadrul companiei asupra aplicației supusă auditării atât din perspectiva caracteristicilor sale critice, cât și din perspectiva integrările pe care aceasta le are implementate asupra căror va exista impact în eventualitatea migrării
Oferirea unui suport decizional în vederea stabilirii strategiei de migrare către cloud sau, din contră de investire în arhitecturi tradiționale
Pentru validarea acestei abordări am realizat o implementare care a demonstrat utilitatea aportului meu în analizarea perspectivei de migrare.
Cercetarea mea a continuat în acest domeniu, cu analiza interacțiunii dintre sistemele din interiorul companiei și cele din cloud și am realizat două modele de abordare a unor problematici stringente din domeniul cloud:
Comunicația între un sistem intern de date care stochează informații confidențiale a căror stocare nu se poate migra către cloud
Extinderea conceptului de Identity Management de la nivelul companiei la nivel arhitectural logic, extinzând practic granițele companiei în internet.
Pentru adresarea primei problematici am realizat un proces eficient care manipulează date confidențiale criptat, asigurând că decriptarea se face în condiții sigure de autentificare și autorizare.
În această cercetare, am plecat de la standardele existente în securitatea informației privind modalitate de stocare, manipulare și ștergere a datelor cu caracter confidențial, analizând cerințele esențiale specifice fiecăreia dintre fazele ciclului de viață al datelor. Am analizat apoi sistemele implicate în fiecare dintre aceste etape într-o arhitectură interactivă care conține sisteme aparținând mai multor companii.
Clasificând sistemele interesate în stocare, procesarea sau ștergerea datelor cu caracter confidențial în sisteme de încredere și sisteme externe – cele ale furnizorului, am stabilit cu exactitate în ce pas al ciclului de viață intervine fiecare sistem în parte. Mai mult, în funcție de această clasificare am ales și mijloacele de protecție a informațiilor astfel încât să deservească eficient scopului pentru care au fost implementate, fără a introduce latențe inutile în sistem. Altfel spus, prin workshop-uri repetate pe aceeași arhitectură, am ales algoritmul de criptare al datelor din interiorul companiei ca fiind cel cu performanțele cele mai bune, considerând că, gradul de vulnerabilitate al sistemului este mai mic întrucât este protejat și de firewall. Pentru sistemele externe, am realizat o abordare eficientă care să asigure stocarea în siguranță a datelor, fără ca acestea să fie disponibile furnizorului. Astfel, furnizorul este capabil să le proceseze, dar nu le poate interpreta și folosi în scopuri malițioase deoarece el manipulează datele criptate cu un mecanism al cărui chei de decriptare sunt în interiorul companiei.
Prin metodologia realizată am obținut următoarele beneficii:
Toate datele confidențiale sunt stocate criptat, chiar și cele din interiorul companiei, fapt ce asigură atât conformitatea cu standardele și reglementările în vigoare cât și un grad sporit de protecție împotriva atacurilor informatice
Există trei mecanisme folosite pentru asigurarea AAA fapt ce sporește gradul de securitate al aplicației:
Mecanismul de autentificare al aplicației cloud la aplicația de retenții
Mecanismul de autentificare al utilizatorului final la aplicația cloud
Mecanismul de autentificare al utilizatorului la sistemele companiei
Chiar dacă există un eveniment de atac soldat cu accesul neautorizat la datele stocate în aplicația migrate în cloud, atacatorul nu va putea dispune de aceste informații
Algoritmul de criptare sincronă folosit în procesul de criptare al datelor stocate în interiorul companiei asigură un timp de răspuns scurt pentru procesul de decriptare, oferind în același timp și un mecanism puternic de protecție for confidențialitatea datelor sensibile
Tot în domeniul interacțiunii între sistemele din interiorul companiei și cele din cloud, am realizat o abordare eficientă a aspectelor legate de Identity Management prin creșterea gradului de complexitate în autentificarea utilizatorilor la sistemele cloud. Această necesitate a survenit ca urmare a problemelor specifice existente în cloud legate de manipularea datelor utilizatorilor cu caracter confidențial, de accesul aplicației cloud la aceste date și de distrugerea identității cloud.
Astfel, plecând de la una dintre caracteristicile fundamentale ale cloud computing-ului, cea de disponibilitate, am analizat multitudinea de contexte din care un utilizator al internetului poate accesa serviciul cloud, mapând fiecare situației identificată cu posibile activități malițioase. În analiza atacurilor informatice am ținut cont de gradul de identificare al atacatorului și de elementele fundamentale care duc la descoperirea sursei fraudei cibernetice. Sumarizând această activitate de analiză, am identificat principalele caracteristici de care, un sistem eficient de Identity Management trebuie să țină cont pentru a asigura un proces de autentificare eficient și sigur.
Folosind aceste elemente de identificare am integrat mai multe sisteme din interiorul companiei capabile pe de o parte să verifice legitimitatea cererii utilizatorului, iar pe de altă parte să ofere informații utile procesului de audit al securității.
Pentru componenta procesului de autentificare care se petrece în serviciul cloud, am folosit abordarea de “one time identity”, astfel încât să mă asigur că stocarea în cloud datelor confidențiale despre utilizator nu se justifică. Mai mult decât atât am impus aplicației cloud reguli clare de acces la datele sensibile stocate în identitatea digitală și am securizat ambele canale de comunicație care transportă date cu caracter confidențial.
Această abordare are la bază mai multe elemente de autentificare, oferind un mecanism eficient de înlăturare a riscului cauzat de atacurile informatice prin implementarea în mai mulți pași de validare și compunere a entității folosite de aplicația cloud în vederea autentificării utilizatorului final.
Principalele beneficii ale acestei abordări sunt:
Utilizatorul nu știe niciodată identitatea sa digitală, fapt ce nu îi permite alterarea drepturilor de acces la aplicația cloud
Există un proces cu 2 pași de verificare contra furtului de certificate digitale:
Primul pas este acela în care utilizatorul trebuie să introducă parola generată de token-ul companiei pentru a continua procesul de autentificare – dacă atacatorul fură certificatul digital fără a avea și token-ul, autentificarea nu se realizează
Al doilea pas este verificarea realizată de Depozitul de certificate de încredere – acest pas îl completează pe primul în sensul ca dacă un atacator reușește să fure atât certificatul cât și token-ul, pentru a putea realiza autentificarea trebuie ca ea să fie inițiată de la un dispozitiv autorizat.
Procesul de autentificare implică mai multe sisteme, fapt ce face imposibil un atac de tipul man in the middle cu un singur pas de penetrare.
Identitatea digitală conține doar informațiile necesare serviciilor din aplicația cloud care îi sunt permise utilizatorului
Identitatea digitală este distrusă după ce este folosită, fără a fi stocată în aplicația cloud
Comunicația între sistemul de Identity Management și cel de gestiune a certificatelor digitale este criptată folosind un algoritm cu grad de siguranță sporit față de protocoalele existente.
Aceste caracteristici asigură un grad sporit de securitate serviciului cloud prin implementarea unor mecanisme de securitate eficiente.
Pentru validarea eficienței metodei am folosit o abordare centrată pe entitate prezentată în [42] pe care am adaptat-o scenariului și metodologiei mele. Am oferit astfel o metodă eficientă de control al:
Accesului utilizatorilor din perspectiva privilegiile la aplicația din cloud prin includerea politicilor de acces în identitatea digitală
Accesului aplicației cloud la datele confidențiale ale utilizatorului prin includerea regulilor de acces la zona identității digitale ce stochează date personale
Ciclului de viață al identității digitale care este distrusă după folosire
În domeniul auditului aplicațiilor cloud computing, mi-am propus să realizez o metodologie de audit eficientă care să ofere o cuantificare măsurilor de siguranță pe care orice consumator trebuie să le analizeze. Astfel, plecând de la conceptul de guvernanță a proceselor de business și fluxurilor informaționale implementate în arhitecturi de cloud computing, și de la domenii de securitate prezentate în singurul model de securitate de referință existent, am creat o abordare holistică a procesului de audit.
Procesul de audit al serviciilor cloud implementat de mine are două subdomenii și anume:
Stabilirea factorului de siguranță din perspectivă tehnologică și de business pe care serviciul o asigură
Stabilirea factorului de rentabilitate investițională pe care programul de adopție al serviciului cloud îl manifestă
Pentru primul aspect, am definit mecanisme de control aplicabile domeniilor de securitate prezentate în [17], pentru evaluarea căror am folosit framework-ul de control definit de ISACA în care se bazează pe șase niveluri de implementare, plecând de la 0 – cel în care mecanismul de control există în stare incompletă sa nu există deloc, până la 5 – în care mecanismul este matur și și-a demonstrat eficiență și vulnerabilitatea scăzută.
Așadar auditorul, având la dispoziție chestionarul de audit care privește aspectele esențiale care trebuie să capteze atenția evaluării, trebuie ca, pe baza probelor de audit să ofere gradul de implementare pentru fiecare dintre aceste controale. Metodologia propusă de mine cu caracter de noutate, pleacă de la acest formular de audit și, pe baza unui nivel de risc asumat în programul de implementare al serviciului cloud, calculează gradul de siguranță al serviciului prin raport la riscul asumat.
Algoritmul de calcul prezentat în secțiunea 5.3.2 se bazează pe gradul de senzitivitate al aplicației, pe nivelul de risc asumat și pe răspunsurile chestionarului de audit pentru a oferi o cuantificare a gradului de siguranță al aplicației. Fiecare dintre cele 3 mărimi de intrare specificate introduce o corecție riscului general domeniului supus auditării.
În acest domeniu, am studiat și un aspect derivat al stabilirii factorului de siguranță, și anume stabilirea gradului de conformitate al soluției supusă analizei cu principiile, standardele și cerințele folosite de mine în definirea metodologiei de audit. Astfel acest grad de conformitate se stabilește în raport cu nivelul de risc asumat în implementarea acelei soluții și cu factorul de siguranță calculat prin algoritmul prezentat la 5.3.2.
Principalele contribuții în acest domeniu ale abordării mele constau în:
Propunerea unui algoritm eficient de stabilire a factorului de siguranță ce ia în calcul toți factorii contextuali ai procesului de audit
Evaluarea principalelor mecanisme de control al securității recomandate de organismele de standardizare – atât cele de standardizare a aspectelor privind cloud computing-ul cât și cele care adresează arhitecturile tradiționale prin adaptarea best practice-urilor și principiilor consacrate la particularitățile conceptului de cloud computing
Cuantificarea guvernanței și securității aplicației analizate prin factorul de siguranță care, pe lângă garanția oferită privind implementarea mecanismelor de securitate recomandate, demonstrează și conformitatea cu standardele folosite de mine în definirea setului de controale aplicabile soluției analizate.
Cuantificare gradului de conformitate cu standardele folosite pentru generarea chestionarului de audit prin raportarea la un prag minim de siguranță impus de nivelul de risc asumat. Am oferit astfel o dimensiune conformității demonstrate de aplicația cloud, prin raportarea factorului de siguranță care măsoară gradul de implementare al mecanismelor de control de securitate, la nivelul de risc asumat.
Oferirea unei analize detaliate, obiective, corecte și concrete privind toate aspectele incluse în domeniile de securitate supuse analize.
Evaluarea atât din perspectiva guvernanței cât și a operabilității soluției de cloud propunând o abordare holistică a procesului de audit
Abordarea personală a procesului de audit al soluțiilor de cloud computing cuprinde și un al doilea sub-domeniu care adresează componenta economică a strategiei și gradul de maturitate pe care procesele de guvernanță și gestiune ale programelor în această arie arhitecturală îl au. Astfel, în acest subiect am plecat de la framework-urile existente ce evaluează sporul de valoare adus de investițiile în programele IT, și am definit metrici de măsurare a gradului de maturitate a proceselor de business și fluxurilor informatice, metrici care ajută la stabilirea gradului de îndeplinire al programului ce vizează domeniul IT. Chestionarul de audit este evaluat în raport cu gradul de maturitate al metricilor alese de mine.
Așadar auditorul, având la dispoziție chestionarul de audit care conține principalele metrici de cuantificare a sporului de valoare pe care programul investițional l-a adus companiei, trebuie ca, pe baza probelor de audit să ofere gradul de maturitate pentru fiecare dintre aceste metrici. Metodologia propusă de mine cu caracter de noutate, pleacă de la acest formular de audit și, pe baza unui nivel de maturitate așteptat pentru componentele de gestiune și metodologie de implementare în programul de implementare al serviciului cloud, calculează indicele de realizare ale acestor obiective (obiectivele sunt considerate a fi atingerea gradului de maturitate așteptat pentru toate ariile acoperite de metricile supuse evaluării).
Indicele de realizare reprezintă măsura gradului de îndeplinire a scopului programului și alături de riscul asociat soluției de cloud a cărui metodologie de calcul am sumarizat-o mai sus, au efect direct asupra valorii actualizate nete a programului, care definește reprezentarea economică a factorului de rentabilitate.
Această abordare prezintă originalitate din perspectiva metodologiei de implementare a corecțiilor aduse de rezultatul procesului de audit privind cuantificarea siguranței, în stabilirea unor indici economici care evaluează programul din perspectiva gradului de fructificare a investițiilor realizate. Asftel metodologia de calcul a rentabilității soluțiilor de cloud oferă următoarele beneficii:
Propunerea unui algoritm eficient de stabilire a factorului de rentabilitate prin cuantificarea aportului adus de mecanismele din departamentul IT în măsurile financiare ale programului care a finanțat implementarea soluției informatice
Propunerea unei metodologii de cuantificare a programului investițional pe baza gradului de maturitate al proceselor de business, procedurilor companiei și gestiunea programelor din domeniul IT, fapt ce dă o dimensiune beneficiilor și surplusului de valoare adus de mecanismele IT în business
Evaluarea unui program din cadrul companiei pentru stabilirea strategiei companiei, fapt ce oferă suport decizional în privința alegerii direcției de dezvoltare
Analiza completă a programului de implementare al soluției cloud, fapt ce oferă posibilitatea evidențierii domeniilor celor mai mature și a acelora în care trebuie aduse îmbunătățiri. Această analiză poate sta la baza deciziile strategice de guvernanță și management al riscului din companie, dar și folosirea drept referință a soluției analizată în dezvoltarea altor business case-uri supuse evaluării în vederea includerii lor în portofoliul companiei.
Pentru validarea metodologiei originale prezentate, am realizat o implementare care analiza soluția salesforce.com într-o arhitectură specifică atât din perspectiva factorului de siguranță cât și din perspectiva factorului de rentabilitate.
Abordarea studiului de cercetare în acest domeniu s-a bazat în principal pe analizarea și documentarea principiilor, standardelor, practicilor și framework-urilor existente în vederea prezentării acestora într-o manieră comparativă. Plecând de la aceasta, am structurat best practice-urile mondiale într-un framework comun pentru care am definit reguli și interdependențe. Acestea au conturat procese de abordare a diferitelor problematici supuse analizei, care prin viziunea proprie asupra aspectelor factuale și contextuale care generau anumite scenarii, au dus la implementarea unor metodologii originale și eficiente de îmbunătățire a proceselor din domeniul auditului cloud computing, validate de implementările realizate.
C.3 DISEMINAREA REZULTATELOR
Lista de lucrări prezentate la conferințe internaționale:
G. Mateescu, M. Vlădescu, V. Sgârciu, The Design and Implementation of an Experimental Model for Secure Management of Personal Data Based on Electronic Identity Card and PKI Infrastructure, 2012, 14th IFAC Symposium on Information Control Problems in Manufacturing, INCOM
G. Mateescu, M. Vlădescu, V. Sgârciu, The Design and Validation of an Experimental Model for the Secure and Efficient Medical Services based on PKI Infrastructures and Smart-Cards, 2012, 14th IFAC Symposium on Information Control Problems in Manufacturing, INCOM
Georgiana Mateescu, Marius Vlădescu, Identity Management Approach for Software as a Service, 2013, The Eighth International Conference on Systems and Networks Communications, ICSNC 2013
Georgiana Mateescu, Marius Vlădescu, Secure On Premise – On Demand Services Communication, 2013 , System Theory, Control and Computing (ICSTCC), 2013 17th International Conference, ISBN 978-1-4799-2227-7
G. Mateescu, M. Vlădescu, A hybrid approach of system security for small and medium enterprises: Combining different cryptography techniques , 2013, Computer Science and Information Systems (FedCSIS)
Lista de lucrări publicate în reviste:
Georgiana Mateescu, Marius Vlădescu – Auditing Hybrid IT Environments – International Journal of Advanced Computer Science and Applications (http://thesai.org/Publications/IJACSA ) – Aprilie 2014
Lista de lucrări în curs de publicare:
Georgiana Mateescu, Marius Vlădescu, Identity Management Approach for Software as a Service [versiunea extinsă] – International Journal On Advances in Software (IARIA Journals), 2014
Georgiana Mateescu, Valentin Sgârciu, Cloud Computing Audit – Scientific Bulletin UPB (Submission ID 2801), 2014
Georgiana Mateescu, Marius Vlădescu, Valentin Sgârciu, Auditing Cloud Computing Migration – IEEE 9th International Symposium on Applied Computational Intelligence and Informatics, SACI 2014
Lista de lucrări trimise spre publicare:
Marius Vlădescu, Georgiana Mateescu, Valentin Sgârciu, Security measures for laptop loss or theft in enterprises, – 2014 IEEE International Conference on Automation, Quality and Testing, Robotics, AQTR
Georgiana Mateescu, Marius Vlădescu, Valentin Sgârciu, Addressing Identity Management in Cloud Computing Architectures – 2014 IEEE International Conference on Automation, Quality and Testing, Robotics, AQTR
Marius Vlădescu, Georgiana Mateescu, Valentin Sgârciu, Event Correlation for enterprise intername security – 7th International Conference on Security for Information Technology and Communications – SECITC’14
Georgiana Mateescu, Marius Vlădescu, Valentin Sgârciu, – Holistic approach to evaluate the cloud adoption 7th International Conference on Security for Information Technology and Communications – SECITC’14
C.4 PERSPECTIVE DE DEZVOLTARE ULTERIOARĂ
Perspectivele de dezvoltare ulterioară a contribuțiilor personale în domeniului auditului în cloud vizează, ca și activitatea mea de cercetare, trei direcții diferite, al căror punct comun îl constituie cloud computing-ul:
Procesul de evaluare al adopției arhitecturilor cloud computing
Integrarea sistemelor în arhitecturi hibride
Procesul de auditare al serviciilor cloud
În ceea ce privește procesul de evaluare al adopției privind arhitecturi cloud computing se poate extinde metodologia propusă de mine către clasificarea proceselor de audit din perspectiva industriei din care fac parte, realizându-se astfel un framework specific pe industrie. Acest lucru se poate realiza plecând de la o analiză amplă asupra sistemelor specifice industriei, a standardelor obligatorii care reglementează procesele și fluxurile informaționale ale acelor domenii și materializând aceste aspecte în factori adresabili la nivelul chestionarului de audit. De asemenea, în această direcție se pot ajusta factorii de impact ai întrebărilor existente pentru a reflecta o acuratețe mai mare în raport cu specificitatea industriei pentru care este creat framework-ul.
O altă direcție de îmbunătățire este aceea de a extinde metodologia expusă și pentru evaluarea proceselor ce vizează adoptarea unei strategii de business în cloud computing incluzând aici:
Strategie de a deveni furnizor de cloud
Strategie de a deveni broker de cloud
Strategia unei companii de dezvoltare software de a-și migra mediile de dezvoltare către PaaS
În ceea ce privește metodologia de integrare a sistemelor în arhitecturi hibride, se poate pleca de la abordarea propusă care manifestă un grad sporit de securitate și dezvolta în sensul adoptării acestei metodologii și în alte integrări prin adaptarea lui la situații specifice. De asemenea oportunități de dezvoltare în acest caz sunt și în alegerea și optimizarea algoritmilor de criptare.
În ceea ce privește abordarea de gestiune a identităților în arhitecturi de tip cloud, aceasta se poate îmbunătăți prin sporirea performanțelor sistemului.
În ceea ce privește procesul de audit al serviciilor de tip cloud computing, acesta trebuie să sufere continue ajustări prin adaptarea mecanismelor de securitate supuse evaluării și a metricilor de proces conform cu dezvoltările din domeniul tehnologiei. De asemenea, și această direcție, ca și cea referitoare la migrare, poate oferi dezvoltări ulterioare în vederea particularizării pe industrii. Astfel, pe lângă domeniile aplicabile la nivel general în cloud pe care aceasta le adresează, în funcție de industria în care compania consumator activează, se pot crea funcționalități modulare care să adreseze integrări specifice și procese particulare cu cerințe speciale.
Cele trei domenii de cercetare oferă o serie largă de oportunități de îmbunătățire, în primul rând datorită caracteristicii de noutate a cloud computing-ului cât și datorită necesității de minimizare a impactului migrării către astfel de arhitecturi, fapt ce face ca analiza și auditarea modelelor cloud să fie un domeniu de interes în practica prezentă și viitoare a direcțiilor de cercetare și dezvoltare IT.
c
A.3 VAL IT
Val IT este un model de evaluare a valorii adusă companiei de investițiile din domeniul IT. Acest framework se bazează pe următoarele principii fundamentale care permit aducerea unui spor de valoare companiei prin intermediul mediului IT:
Investițiile în domeniul IT vor:
Fi gestionate ca un portofoliu de investiții
Include toate activitățile necesare pentru obținerea beneficiilor în business
Fi gestionate de-a lungul întregului ciclu de viață economic al acestora
Practicile folosite pentru livrarea beneficiilor și implicit a sporurilor de valoare vor:
Clasifica investițiile astfel încât, în funcție de specificitatea fiecăreia, acestea să fie evaluată diferit
Defini și monitoriza metrici cheie și vor răspunde prompt la orice modificare sau deviație
Implica toate părțile interesate și vor acorda atenția cuvenită livrării capabilităților și realizării beneficiilor de business
Fi monitorizate, evaluate și îmbunătățite în mod continuu
Val IT operează cu următoarele concepte:
Proiect – proiectul reprezintă un set structurat de activități realizat în vederea obținerii unei capabilități tehnice definite pe baza unul plan și a unui buget agreate (această condiție este necesară dar nu și suficientă pentru a putea demonstra obținerea rezultatului scontat). Proiectele sunt definite la nivel de livrare de componente IT (fie ca sunt ele soluții sau aplicații) care sunt necesare dar nu suficiente pentru obținerea beneficiilor de business.
Program – programul reprezintă un set structurat de proiecte care sunt necesare și suficiente pentru a obține beneficiile de business dorite și pentru a livra un spor de valoare companiei, incluzând aici procesele de gestiune a schimbărilor în business, procesele de business, instruirea angajaților etc. Programul reprezintă unitatea primară de investiție în framework-ul Val IT.
Portofoliu – portofoliul reprezintă o suită de programe de business gestionate și optimizate în vederea îmbunătățirii valorii companiei. Altfel spus, portofoliul reprezintă o grupare a obiectelor care deservesc aceluiași interes. Aceste obiecte pot fi: programe de investiții, servicii IT, proiecte IT, resurse și asset-uri. Acest concept reprezintă factorul principal de interese pentru Val IT.
Figura de mai jos prezintă relația între conceptele prezentate anterior din perspectiva gestiunilor:
Fig. 9.1: Proiect, Program, Portofoliu
Val IT oferă 22 de procese clasificate în trei domenii:
Guvernanța Valorii (VG) – scopul acestui domeniu este de a se asigura că practicile cele mai eficiente din domeniu sunt aplicate în companie, ducând astfel la realizarea obiectivelor într-un mod eficient.
Managementul Portofoliilor (PM) – obiectivul acestui domeniu este de a asigura alocarea optimă de resurse în investițiile realizate în domeniul IT.
Managementul Investițiilor (IM) – obiectivul acestui domeniu este de a asigura că investițiile realizate în domeniul IT aduc contribuții importante în creșterea valorii companiei.
Fiecare domeniu cuprinde un set de procese de business care sunt numerotate în funcție de domeniul din care fac parte. Un proces de business reprezintă o colecție de activități interconectate efectuate respectând regulile impuse de management [15].
Figura de mai jos definește relația dintre aceste trei domenii:
Fig. 9.2: Legătura între domeniile și procesele Val IT
Metricile folosite în procesul de auditare al serviciilor cloud sunt prezentate în tabelul de mai jos:
Tabelul 9.3: Metrici folosite în procesul de audit
A.4 LISTA DE FIGURI
Fig. 2.1: Model de referință CSA 18
Fig. 2.2: Business Operation Support Services 19
Fig. 2.3:Information Technology Operation & Support 21
Fig. 2.4: Servicii de Prezentare 23
Fig. 2.5: Servicii de Aplicație 24
Fig. 2.6: Servicii de Informații 24
Fig. 2.7: Servicii de Infrastructură 26
Fig. 2.8: Gestiunea Securității și Riscului 27
Fig. 2.9: CSA – Framework-ul Cloud 30
Fig. 2.10: Mapările dintre modelul arhitectural de cloud și cel de securitate 31
Fig. 2.11: Interacțiunea între domeniile de securitate în arhitecturi cloud 33
Fig. 2.12: Modele de arhitecturi Cloud Computing 47
Fig. 2.13: Arhitecturi Cloud 48
Fig. 2.14: Arhitecturi Cloud Hibride 49
Fig. 3.1: Procesul de auditare al migrării în cloud 57
Fig. 3.2: Concepte manipulate de procesul de audit 59
Fig. 3.3: Obiecte manipulate de procesul de adopție 60
Fig. 3.4: Obiecte manipulate de procesul de calculare a scorului 62
Fig. 4.1: Sistem Centralizat de Identity Management 66
Fig. 4.2: Sistemul de Identity Management 68
Fig. 4.3: Arhitectura soluției de Identity Management 69
Fig. 4.4: Fluxul de date în generarea unei identități digitale 70
Fig. 4.5: Procesul de Autentificare 72
Fig. 4.6: Identitatea Digitală 73
Fig. 4.7: Consumarea identității digitale 73
Fig. 4.8: Mecanismul de criptare hibridă 74
Fig. 4.9: Mecanism de decriptare 75
Fig. 4.10: Criptare homomorifică 79
Fig. 4.11: Arhitectura sistemului de securizare a comunicației în arhitecturi hibride 80
Fig. 4.12: Procesul de securizare al comunicației în arhitecturi hibride 82
Fig. 5.1: Analiza riscului adopției arhitecturilor de tip cloud în visiune ENISA 90
Fig. 5.2:COBIT – Folosirea unei abordări holistice [15] 92
Fig. 5.3: COBIT – Model Generic [15] 93
Fig. 5.4:Domenii principale în procesul de gestiune și gurvernanță a componentelor IT [11] 93
Fig. 5.5: Modelul procesului de evaluare a capabilităților proceselor IT [15] 94
Fig. 5.6: Frameworkul Risk IT [14] 97
Fig. 5.7: Riscul în domeniul IT în ierahia riscurilor la nivel de companie [14] 98
Fig. 5.8: Ariile adresate de frameworkul Val IT [92] 99
Fig. 5.9: Procesul de auditare al serviciilor cloud 105
Fig. 5.10: Concepte folosite în calcularea factorului de Siguranță 108
Fig. 5.11: Concepte folosite în calcularea factorului de rentabilitate 109
Fig. 5.12: Relațiile între chestionare și celelalte obiecte manipulate în procesul de audit 110
Fig. 5.13: Obiecte manipulate în procesul de evaluare al factorului de siguranță 111
Fig. 5.14: Procesul de calcul al factorului de siguranță 112
Fig. 5.15: Obiecte manipulate în procesul de evaluare al factorului de siguranță 116
Fig. 5.16 Procesul de calcul al factorului de rentabilitate 117
Fig. 6.1: Arhitectura Studiului de caz 123
Fig. 6.2: Scoruri obținute în procesul de audit 129
Fig. 6.3: Factorii de impact obținuți în procesul de audit 131
Fig. 6.4: Etape de migrare către cloud 134
Fig. 7.1: Arhitectura Studiului de caz 136
Fig. 7.2: Rezultatele procesului de audit al aplicației salesforce.com din perspectiva siguranței 143
Fig. 7.3: Gradul de analiză al domeniilor adresate din perspectiva numărului de controale 144
Fig. 7.4: Raportul dintre riscul aplicației și riscul asumat 144
Fig. 7.5: Analiză comparativă între factorii de siguranță obținuți 145
Fig. 7.6: Factori de conformitate ai domeniilor analizate în raport cu standardele folosite 147
Fig. 7.7: Scorul de maturitate obținut în analiza factorului de rentabilitate pentru programul Salesforce 153
Fig. 7.8: Indicii de Realizare ai programului Salesforce 153
Fig. 7.9: Risc al domeniilor supuse auditării privind siguranța aplicației 154
Fig. 7.10: Raportul cheltuieli venituri pentru programul Salesforce 155
Fig. 7.11: Cheltuieli și venituri pentru proiectul Salesforce în cazul mjorării ratei de actualizare 156
Fig. 9.1: Proiect, Program, Portofoliu 188
Fig. 9.2: Legătura între domeniile și procesele Val IT 189
A.5 LISTA DE TABELE
Tabelul 3.1: Procesul de auditare al migrării 55
Tabelul 5.1: Procesul de auditare al serviciilor cloud 103
Tabelul 5.2: Niveluri de implementare a mecanismelor de siguranță de către furnizorii de cloud 109
Tabelul 5.3: Constanta de conformitate în funcție de nivelul de risc asumat 112
Tabelul 5.4: Niveluri de implementare a mecanismelor de siguranță de către furnizorii de cloud 113
Tabelul 6.1: Caracteristici ale aplicației supusă procesului de auditare a migrării în cloud 122
Tabelul 6.2: Caracteristici necesate ale aplicației de raportare 123
Tabelul 6.3: Scorurile Procesului de audit 127
Tabelul 6.4: Scoruri de referință pentru calculul impactului 128
Tabelul 6.5: Impactul migrării 129
Tabelul 6.6: Etape propuse de aplicația de migrare 130
Tabelul 7.1: Caracteristici ale aplicației supusă procesului de auditare a migrării în cloud 136
Tabelul 7.2: Caracteristici ale aplicației supusă procesului de auditare a migrării în cloud 145
Tabelul 7.3: Detaliile financiare ale programului salesforce.com 148
Tabelul 7.4:Nivelurile de maturitate al programului Salesforce rezultate în urma auditului 150
Tabelul 7.5: Datele finianciare ale programului Salesforce 152
Tabelul 7.6: Datele financiare folosite în calculul rentabilității 153
Tabelul 9.1:Acronime 166
Tabelul 9.2: Mecanismele de control folosite în procesul de auditare al factorului de siguranță 168
Tabelul 9.3: Metrici folosite în procesul de audit 187
BIBLIOGRAFIE
Rajkumar Buyya, James Broberg and Andrzej M. Goscinski, Cloud Computing: Principles and Paradigms, 2011, John Wiley & Sons ISBN:[anonimizat]
Wim Van Grembergen, Steven De Haes, Enterprise Governance of Information Technology: Achieving Strategic Alignment and Value, 2008 , Springer ISBN:9780387848815
George Rees, Cloud Application Architectures, 2009, O'Reilly Media, ISBN:978-0-596-15636-7
Anca Daniela Ionita, Marin Litoiu, Grace Lewis, Migrating Legacy Applications: Challenges in Service Oriented Architecture and Cloud Computing Environments, 2013, IGI Global, ISBN:[anonimizat]
Jatinder N. D. Gupta, Sushil K. Sharma, Handbook of Research on Information Security and Assurance, 2009, IGI Global, ISBN:9781599048550
Irene Maria Portela, Maria Manuela Cruz-Cunha, Information Communication Technology Law, Protection and Access Rights: Global Approaches and Issues, 2010, IGI Global,ISBN:9781615209750
Charles Babcock, Management Strategies for the Cloud Revolution: How Cloud Computing Is Transforming Business and Why You Can't Afford to Be Left Behind, 2010, MgGraw-Hill ISBN:9780071740753
Michael Hugos, Derek Hulitzky, Business in the Cloud: What Every Business Needs to Know About Cloud Computing, 2011, John Wiley & Sons ISBN:9780470616239
Ronald L. Krutz, Russell Dean Vines, Cloud Security: A Comprehensive Guide to Secure Cloud Computing, 2010, John Wiley & Sons ISBN:9780470589878
Andrew Vladimirov, Konstantin Gavrilenko, Andriej Michajlowski, Assessing Information Security: Strategies, Tactics, Logic And Framework, 2010, IT ISBN:9781849280365
Elisa Bertino,Kenji Takahashi, Identity Management: Concepts, Technologies, and Systems, 2011, Artech House ISBN:9781608070398
Georgiana Mateescu, Marius Vlădescu, Identity Management Approach for Software as a Service, 2013
Georgiana Mateescu, Marius Vlădescu, Secure On Premise – On Demand Services Communication, 2013 ISBN 978-1-4799-2227-7
Chris Davis, Mike Schiller, Kevin Wheeler, IT Auditing: Using Controls to Protect Information Assets, Second Edition, 2011, McGraw-Hill/Osborne ISBN:9780071742382
ISACA, COBIT 5: A Business Framework for the Governance and Management of Enterprise IT, 2012, ISACA ISBN:9781604202373
Michael Workman, Daniel C. Phelps, John N. Gathegi, Information Security for Managers, 2013, Jones and Bartlett Publishers ISBN:9780763793012
Cloud Security Alliance, Security Guidance for critical areas of focus in cloud computing v3.0, 2011 https://cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf
Bel G. Raggad, Information Security Management: Concepts and Practice, 2010, Auerbach Publications ISBN:9781420078541
Vincent Nestler, Wm. Arthur Conklin, Gregory White Matthew Hirsch, Principles of Computer Security CompTIA Security+ and Beyond Lab Manual, Second Edition, 2011, McGraw-Hill/Osborne ISBN:9780071748568
Perhuru Raj, Cloud Enterprise Architecture, 2012, Auerbach Publications ISBN:9781466502321
Joe Weinman, Cloudonomics: The Business Value of Cloud Computing, 2012, John Wiley & Sons ISBN:[anonimizat]
ISACA, IT Control Objectives for Cloud Computing: Controls and Assurance in the Cloud, 2011, ISACA ISBN:9781604201826
Maria Toeroe, Francis Tam, Service Availability: Principles and Practice,2012, John Wiley & Sons, ISBN:9781119954088
Massimo Villari, Ivona Brandic, Francesco Tusa, Achieving Federated and Self-Manageable Cloud Infrastructures: Theory and Practice 2012,IGI Global © 2012 (489 pages) Citation ,ISBN:9781466616318
Lee Newcombe, Securing Cloud Services: A Pragmatic Approach to Security Architecture in the Cloud, 2012, IT Governance ISBN:9781849283960
Xiaoyu Yang, Lu Liu, Principles, Methodologies, and Service-Oriented Approaches for Cloud Computing, 2013, IGI Global,ISBN:9781466628540
Kris Jamsa, Cloud Computing, 2013, Jones and Bartlett Publishers ISBN:9781449647391
Robert R. Moeller, Executive's Guide to IT Governance: Improving Systems Processes with Service Management, COBIT, and ITIL, 2013 John Winley & Sons ISBN:9781118138618
W. Krag Brotby, Gary Hinson, PRAGMATIC Security Metrics: Applying Metametrics to Information Security, 2013, Auerbach Publications, ISBN:9781439881521
Jared Carstensen, Bernard Golden, JP Morgenthal, Cloud Computing: Assessing the Risks, 2012, IT Governance ISBN:9781849283595
ISACA, Monitoring Internal Control Systems and IT: A Primer for Business Executives, Managers and Auditors on How to Embrace and Advance Best Practices, 2010,
ISACA ISBN:9781604201109
Robert R. Moeller, COSO Enterprise Risk Management: Establishing Effective Governance, Risk, and Compliance, Second Edition, 2011, John Wiley & Sons ISBN:9780470912881
Mark Rhodes-Ousley, The Complete Reference: Information Security, Second Edition, 2013, McGraw-Hill/Osborne,ISBN:9780071784351
Maxine Attong , Terrence Metz, Change or Die: The Business Process Improvement Manual, 2013, Productivity Press ISBN:9781466512511
Alberto M. Bento, Anil K Aggarwal Cloud Computing Service and Deployment Models: Layers and Management, 2013, IGI Global ISBN:9781466621879
Sandra Senft, Frederick Gallegos, Information Technology Control and Audit, Third Edition, 2009, Auerbach Publications ISBN:9781420065503
Tim Mather, Subra Kumaraswany, Shahed Latif, Cloud Security and Privacy. An Enterprise Perspective on Risk and Compliance, O’Reilly United States of America, first version 2009
John Rittinghouse, James Ransome, Cloud Computing Implementation, Management and Security, CRC Press, London Taylor and Francis Group, 2010
Harold F. Tipton, Micki Krause Nozaki, Information Security Management Handbook, Sixth Edition, Volume 5, 2012, Auerbach Publications ISBN:9781439853450
Matthew Metheny, Federal Cloud Computing: The Definitive Guide for Cloud Service Providers, 2013, Syngress Publishing ISBN:9781597497374
Raj Sharman, Sanjukta Das Smith, Manish Gupta, Digital Identity and Access Management: Technologies and Frameworks, 2012, IGI Global ISBN:9781613504987
Pelin Angin, Bharat Bhargava, Rohit Ranchal, Noopur Singh, Lotfi Ben Othmane, Leszek Lilien, Mark Linderman, An Entity-centric Approach for Privacy and Identity Management in Cloud Computing, 2010
Jeff Scheidel, Designing an IAM Framework with Oracle Identity and Access Management Suite, 2010, Oracle Press ISBN:9780071741378
Vivek Santuka, Premdeep Banga, Brandon J. Carroll, AAA Identity Management Security, 2011 , Cisco Press ISBN:9781587141447
Edward J. Coyne, John M. Davis, Role Engineering for Enterprise Security Management, 2008, Artech House, ISBN:9781596932180
Pail Hpkin, Fundamentals of Risk Management: Understanding, Evaluating and Implementing Effective Risk Management, Second Edition, 2012, Kogan Page ISBN:9780749465391
Craig S. Wright, The IT Regulatory and Standards Compliance Handbook: How to Survive Information Systems Audit and Assessments, 2008, Syngress Publishing ISBN:[anonimizat]
James S. Tiller, Adaptive Security Management Architecture, 2011, Auerbach Publications ISBN:9780849370526
ISACA, IT Risk Management Audit/Assurance Program, 2012, ISACA ISBN:9781604202342
ISACA, IT Control Objectives for Cloud Computing: Controls and Assurance in the Cloud, 2011, ISACA ISBN:9781604201826
NIST, Guidelines on Security and Privacy in Public Cloud Computing , 2011
Roger Reid, Gareth Fraser-King, W. David Schwaderer, Data Lifecycles: Managing Data for Strategic Advantage, 2007, John Wiley & Sons, ISBN:9780470016336
Mingqiang Li, On the Confidentiality of Information Dispersal Algorithms and Their Erasure Codes, 2012
David G. Rosado, Daniel Mellado, Eduardo Fernandez-Medina, Mario Piattini, Security Engineering for Cloud Computing: Approaches and Tools, 2013, IGI GLOBAL ISBN:9781466621251
Greg Schulz, Cloud and Virtual Data Storage Networking: Your Journey to Efficient and Effective Information Services, 2012, Auerbach Publications ISBN:9781439851739
Jude C. Umeh, The World beyond Digital Rights Management, 2007, BCS, ISBN:9781902505879
ISACA, Cloud Computing Management Audit/Assurance Program, 2010
Seymour Bosworth, M.E. Kabay, Eric Whyne, Computer Security Handbook, Fifth Edition, 2009,John Wiley & Sons ,ISBN:9780471716525
James M. Stewart, Mike Chapple and Darril Gibson, CISSP: Certified Information Systems Security Professional Study Guide, Sixth Edition, 2012, Sybex ISBN:9781118314173
S. Hubner. PRIME, https://www.prime-project.eu/ , 2010.
W. Alrodhan and C. Mitchell, Improving the Security of CardSpace, EURASIP Journal on Info Security Vol. 2009.
OPENID, http://openid.net/ , 2010.
Nick Antonopoulos, Lee Gillam, Cloud Computing: Principles, Systems and Applications, 2010, Springer ISBN:[anonimizat]
Thomas M. Koulopoulos, Cloud Surfing: A New Way to Think About Risk, Innovation, Scale and Success, 2012, Bibliomotion ISBN:9781937134099
Pamela K. Isom, Kerrie Holley, Is Your Company Ready for Cloud?: Choosing the Best Cloud Adoption Strategy for Your Business, 2012, IBM Press SBN:9780132599849
Siani Pearson, George Yee , Privacy and Security for Cloud Computing, 2013, Springer ISBN:9781447141884
Paul Brant, Denis Guyadeen, How to Trust the Cloud: “Be Careful Up There”, 2010, EMC
ISACA, Business Continuity Management Audit/Assurance Program, 2011, ISACA ISBN:9781604201864
ISACA, IT Strategic Management Audit/Assurance Program, 2011, ISACA ISBN:9781604202335
http://scap.nist.gov/
Justine Simpson, John Taylor, Corporate Governance, Ethics and CSR, 2013, Kogan Page ISBN:9780749463854
Alan Calder, Corporate Governance: A Practical Guide to the Legal Frameworks and International Codes of Practice, 2008, Kogan Page ISBN:9780749448172
Jennifer L. Bayuk,Cyber Security Policy Guidebook, 2012, John Wiley & Sons ISBN:9781118027806
Ben Halpert, Auditing Cloud Computing: A Security and Privacy Guide, 2011, John Wiley & Sons ISBN:9780470874745
Veena Hingarh, Arif Ahmed, Understanding and Conducting Information Systems Auditing, 2013, John Wiley & Sons ISBN:9781118343746
Chris Davis, Mike Schiller, Kevin Wheeler, IT Auditing: Using Controls to Protect Information Assets, Second Edition, 2011 McGraw-Hill/Osborne ISBN:9780071742382
Vic (J.R.) Winkler, Securing the Cloud: Cloud Computer Security Techniques and Tactics, 2011, Syngress Publishing ISBN:9781597495929
Xiaoyu Yang, Lu Liu, Principles, Methodologies, and Service-Oriented Approaches for Cloud Computing, 2013, IGI Global,ISBN:9781466628540
Caroline Wong, Security Metrics: A Beginners Guide, 2012, McGraw-Hill/Osborne ISBN:9780071744003
ISACA, Implementing and Continually Improving IT Governance, 2009, ISACA ISBN:9781604201192
Paul Brant, Above the Clouds: Best Practices in Creating a Sustainable Computing Infrastructure to Achieve Business Value and Growth, 2010, EMC
Jason Bloomberg, The Agile Architecture Revolution: How Cloud Computing, REST-Based SOA, and Mobile Computing Are Changing Enterprise IT, 2013, John Wiley & Sons ISBN:9781118409770
Mark G. O'Neill, Green IT for Sustainable Business Practice: An ISEB Foundation Guide, 2010, BCS ISBN:9781906124625
Kevin T. McDonald, Above the Clouds: Managing Risk in the World of Cloud Computing, 2010, IT Governance ISBN:9781849280327
ENISA, Cloud Computing Risk Assessment, Noiembrie 2009 – http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment
ENISA (European Network and Information Security Agency), Cloud Computing – Benefits, risks and recommendations for information security, 2009
Jake Sorofman, How to Achieve the Strategic Value of Cloud While Delivering Real ROI. www.eweek.com , March 2009
John J. Hampton, Fundamentals of Enterprise Risk Management: How Top Companies Assess Risk, Manage Exposures, and Seize Opportunities, 2009, AMACOM, ISBN:9780814414927
ISACA, Identity Management Audit/Assurance Program, 2009, ISACA http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Identity-Management-Audit-Assurance-Program.aspx
ISACA, Implementing and Continually Improving IT Governance, 2009, ISACA ISBN:9781604201192
ISACA, The Risk IT Framework , 2009 – http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-Management/Pages/Risk-IT1.aspx , ISACA ISBN:[anonimizat]
ISACA, Enterprise Value: Governance of IT Investments: The Val IT Framework 2.0, 2008 http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Val-IT-Framework-2.0.aspx , ISACA ISBN:9781604200669
ISACA, The Business Case Guide: Using Val IT 2.0, 2010, ISACA ISBN:9781604201055
Gautam Shroff, Enterprise Cloud Computing: Technology, Architecture, Applications, 2010, Cambridge University Press ISBN:9780521760959
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
Craig Gentry, A fully homomorphic encryption scheme, 2009, Phd Thesis
https://www.oasis-open.org/committees/download.php/4136
http://www.ietf.org/rfc/rfc2246.txt
John R. Vacca, Computer and Information Security Handbook, Second Edition, 2013, Morgan Kaufmann ISBN:9780123943972
San Murugesan, G.R. Gangadharan, Harnessing Green IT: Principles and Practices, 2012, John Wiley & Sons ISBN:9781119970057
Michael Gregg, Billy Haines, CASP CompTIA Advanced Security Practitioner Study Guide (Exam CAS-001), 2012, Sybex ISBN:[anonimizat]
Dimosthenis Kyriazis, Athanasios Voulodimos, Spyridon V. Gogouvitis, Theodora Varvarigou, Data Intensive Storage Services for Cloud Environments, 2013, IGI Global ISBN:9781466639348
ISACA, Value Management Guidance for Assurance Professionals: Using Val IT 2.0, 2010, ISACA ISBN:[anonimizat]
Kurt J. Engemann and Douglas M. Henderson, Business Continuity and Risk Management: Essentials of Organizational Resilience, 2012, Rothstein Associates ISBN:9781931332545
Lee Chao, Cloud Computing for Teaching and Learning: Strategies for Design and Implementation, 2012, IGI Global ISBN:9781466609570
N. K. McCarthy, Computer Incident Response Planning Handbook: Executable Plans for Protecting Information at Risk, 2012, McGraw-Hill/Osborne, ISBN:9780071790390
Diane Barrett, Greg Kipper, Virtualization and Forensics: A Digital Forensic Investigator's Guide to Virtual Environments, 2010, Syngress Publishing , ISBN:9781597495578
G. Mateescu, M. Vlădescu, A hybrid approach of system security for small and medium enterprises: Combining different cryptography techniques , 2013, Computer Science and Information Systems (FedCSIS)
Ian Lim, E. Coleen Coolidge, Paul Hourani, Securing Cloud and Mobility: A Practitioner's Guide, 2013, Auerbach Publications, ISBN:9781439850558
John W. Rittinghouse, James F. Ransome, Cloud Computing: Implementation, Management, and Security, 2010, Auerbach Publications, ISBN:9781439806807
Michael Drmota, The development of homomorphic cryptography From RSA to Gentry's privacy homomorphism, Teză de doctorat
Iti Sharma, Fully Homomorphic Encryption Scheme with Symmetric Keys, 2013 Lucrare de Disertație
Georgiana Mateescu, Marius Vlădescu – Auditing Hybrid IT Environments – International Journal of Advanced Computer Science and Applications (http://thesai.org/Publications/IJACSA ) – Aprilie 2014
Georgiana Mateescu, Valentin Sgârciu, Cloud Computing Audit – Scientific Bulletin UPB (Submission ID 2801), 2014
Georgiana Mateescu, Marius Vlădescu, Valentin Sgârciu, Auditing Cloud Computing Migration – IEEE 9th International Symposium on Applied Computational Intelligence and Informatics, SACI 2014
BIBLIOGRAFIE
Rajkumar Buyya, James Broberg and Andrzej M. Goscinski, Cloud Computing: Principles and Paradigms, 2011, John Wiley & Sons ISBN:[anonimizat]
Wim Van Grembergen, Steven De Haes, Enterprise Governance of Information Technology: Achieving Strategic Alignment and Value, 2008 , Springer ISBN:9780387848815
George Rees, Cloud Application Architectures, 2009, O'Reilly Media, ISBN:978-0-596-15636-7
Anca Daniela Ionita, Marin Litoiu, Grace Lewis, Migrating Legacy Applications: Challenges in Service Oriented Architecture and Cloud Computing Environments, 2013, IGI Global, ISBN:[anonimizat]
Jatinder N. D. Gupta, Sushil K. Sharma, Handbook of Research on Information Security and Assurance, 2009, IGI Global, ISBN:9781599048550
Irene Maria Portela, Maria Manuela Cruz-Cunha, Information Communication Technology Law, Protection and Access Rights: Global Approaches and Issues, 2010, IGI Global,ISBN:9781615209750
Charles Babcock, Management Strategies for the Cloud Revolution: How Cloud Computing Is Transforming Business and Why You Can't Afford to Be Left Behind, 2010, MgGraw-Hill ISBN:9780071740753
Michael Hugos, Derek Hulitzky, Business in the Cloud: What Every Business Needs to Know About Cloud Computing, 2011, John Wiley & Sons ISBN:9780470616239
Ronald L. Krutz, Russell Dean Vines, Cloud Security: A Comprehensive Guide to Secure Cloud Computing, 2010, John Wiley & Sons ISBN:9780470589878
Andrew Vladimirov, Konstantin Gavrilenko, Andriej Michajlowski, Assessing Information Security: Strategies, Tactics, Logic And Framework, 2010, IT ISBN:9781849280365
Elisa Bertino,Kenji Takahashi, Identity Management: Concepts, Technologies, and Systems, 2011, Artech House ISBN:9781608070398
Georgiana Mateescu, Marius Vlădescu, Identity Management Approach for Software as a Service, 2013
Georgiana Mateescu, Marius Vlădescu, Secure On Premise – On Demand Services Communication, 2013 ISBN 978-1-4799-2227-7
Chris Davis, Mike Schiller, Kevin Wheeler, IT Auditing: Using Controls to Protect Information Assets, Second Edition, 2011, McGraw-Hill/Osborne ISBN:9780071742382
ISACA, COBIT 5: A Business Framework for the Governance and Management of Enterprise IT, 2012, ISACA ISBN:9781604202373
Michael Workman, Daniel C. Phelps, John N. Gathegi, Information Security for Managers, 2013, Jones and Bartlett Publishers ISBN:9780763793012
Cloud Security Alliance, Security Guidance for critical areas of focus in cloud computing v3.0, 2011 https://cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf
Bel G. Raggad, Information Security Management: Concepts and Practice, 2010, Auerbach Publications ISBN:9781420078541
Vincent Nestler, Wm. Arthur Conklin, Gregory White Matthew Hirsch, Principles of Computer Security CompTIA Security+ and Beyond Lab Manual, Second Edition, 2011, McGraw-Hill/Osborne ISBN:9780071748568
Perhuru Raj, Cloud Enterprise Architecture, 2012, Auerbach Publications ISBN:9781466502321
Joe Weinman, Cloudonomics: The Business Value of Cloud Computing, 2012, John Wiley & Sons ISBN:[anonimizat]
ISACA, IT Control Objectives for Cloud Computing: Controls and Assurance in the Cloud, 2011, ISACA ISBN:9781604201826
Maria Toeroe, Francis Tam, Service Availability: Principles and Practice,2012, John Wiley & Sons, ISBN:9781119954088
Massimo Villari, Ivona Brandic, Francesco Tusa, Achieving Federated and Self-Manageable Cloud Infrastructures: Theory and Practice 2012,IGI Global © 2012 (489 pages) Citation ,ISBN:9781466616318
Lee Newcombe, Securing Cloud Services: A Pragmatic Approach to Security Architecture in the Cloud, 2012, IT Governance ISBN:9781849283960
Xiaoyu Yang, Lu Liu, Principles, Methodologies, and Service-Oriented Approaches for Cloud Computing, 2013, IGI Global,ISBN:9781466628540
Kris Jamsa, Cloud Computing, 2013, Jones and Bartlett Publishers ISBN:9781449647391
Robert R. Moeller, Executive's Guide to IT Governance: Improving Systems Processes with Service Management, COBIT, and ITIL, 2013 John Winley & Sons ISBN:9781118138618
W. Krag Brotby, Gary Hinson, PRAGMATIC Security Metrics: Applying Metametrics to Information Security, 2013, Auerbach Publications, ISBN:9781439881521
Jared Carstensen, Bernard Golden, JP Morgenthal, Cloud Computing: Assessing the Risks, 2012, IT Governance ISBN:9781849283595
ISACA, Monitoring Internal Control Systems and IT: A Primer for Business Executives, Managers and Auditors on How to Embrace and Advance Best Practices, 2010,
ISACA ISBN:9781604201109
Robert R. Moeller, COSO Enterprise Risk Management: Establishing Effective Governance, Risk, and Compliance, Second Edition, 2011, John Wiley & Sons ISBN:9780470912881
Mark Rhodes-Ousley, The Complete Reference: Information Security, Second Edition, 2013, McGraw-Hill/Osborne,ISBN:9780071784351
Maxine Attong , Terrence Metz, Change or Die: The Business Process Improvement Manual, 2013, Productivity Press ISBN:9781466512511
Alberto M. Bento, Anil K Aggarwal Cloud Computing Service and Deployment Models: Layers and Management, 2013, IGI Global ISBN:9781466621879
Sandra Senft, Frederick Gallegos, Information Technology Control and Audit, Third Edition, 2009, Auerbach Publications ISBN:9781420065503
Tim Mather, Subra Kumaraswany, Shahed Latif, Cloud Security and Privacy. An Enterprise Perspective on Risk and Compliance, O’Reilly United States of America, first version 2009
John Rittinghouse, James Ransome, Cloud Computing Implementation, Management and Security, CRC Press, London Taylor and Francis Group, 2010
Harold F. Tipton, Micki Krause Nozaki, Information Security Management Handbook, Sixth Edition, Volume 5, 2012, Auerbach Publications ISBN:9781439853450
Matthew Metheny, Federal Cloud Computing: The Definitive Guide for Cloud Service Providers, 2013, Syngress Publishing ISBN:9781597497374
Raj Sharman, Sanjukta Das Smith, Manish Gupta, Digital Identity and Access Management: Technologies and Frameworks, 2012, IGI Global ISBN:9781613504987
Pelin Angin, Bharat Bhargava, Rohit Ranchal, Noopur Singh, Lotfi Ben Othmane, Leszek Lilien, Mark Linderman, An Entity-centric Approach for Privacy and Identity Management in Cloud Computing, 2010
Jeff Scheidel, Designing an IAM Framework with Oracle Identity and Access Management Suite, 2010, Oracle Press ISBN:9780071741378
Vivek Santuka, Premdeep Banga, Brandon J. Carroll, AAA Identity Management Security, 2011 , Cisco Press ISBN:9781587141447
Edward J. Coyne, John M. Davis, Role Engineering for Enterprise Security Management, 2008, Artech House, ISBN:9781596932180
Pail Hpkin, Fundamentals of Risk Management: Understanding, Evaluating and Implementing Effective Risk Management, Second Edition, 2012, Kogan Page ISBN:9780749465391
Craig S. Wright, The IT Regulatory and Standards Compliance Handbook: How to Survive Information Systems Audit and Assessments, 2008, Syngress Publishing ISBN:[anonimizat]
James S. Tiller, Adaptive Security Management Architecture, 2011, Auerbach Publications ISBN:9780849370526
ISACA, IT Risk Management Audit/Assurance Program, 2012, ISACA ISBN:9781604202342
ISACA, IT Control Objectives for Cloud Computing: Controls and Assurance in the Cloud, 2011, ISACA ISBN:9781604201826
NIST, Guidelines on Security and Privacy in Public Cloud Computing , 2011
Roger Reid, Gareth Fraser-King, W. David Schwaderer, Data Lifecycles: Managing Data for Strategic Advantage, 2007, John Wiley & Sons, ISBN:9780470016336
Mingqiang Li, On the Confidentiality of Information Dispersal Algorithms and Their Erasure Codes, 2012
David G. Rosado, Daniel Mellado, Eduardo Fernandez-Medina, Mario Piattini, Security Engineering for Cloud Computing: Approaches and Tools, 2013, IGI GLOBAL ISBN:9781466621251
Greg Schulz, Cloud and Virtual Data Storage Networking: Your Journey to Efficient and Effective Information Services, 2012, Auerbach Publications ISBN:9781439851739
Jude C. Umeh, The World beyond Digital Rights Management, 2007, BCS, ISBN:9781902505879
ISACA, Cloud Computing Management Audit/Assurance Program, 2010
Seymour Bosworth, M.E. Kabay, Eric Whyne, Computer Security Handbook, Fifth Edition, 2009,John Wiley & Sons ,ISBN:9780471716525
James M. Stewart, Mike Chapple and Darril Gibson, CISSP: Certified Information Systems Security Professional Study Guide, Sixth Edition, 2012, Sybex ISBN:9781118314173
S. Hubner. PRIME, https://www.prime-project.eu/ , 2010.
W. Alrodhan and C. Mitchell, Improving the Security of CardSpace, EURASIP Journal on Info Security Vol. 2009.
OPENID, http://openid.net/ , 2010.
Nick Antonopoulos, Lee Gillam, Cloud Computing: Principles, Systems and Applications, 2010, Springer ISBN:[anonimizat]
Thomas M. Koulopoulos, Cloud Surfing: A New Way to Think About Risk, Innovation, Scale and Success, 2012, Bibliomotion ISBN:9781937134099
Pamela K. Isom, Kerrie Holley, Is Your Company Ready for Cloud?: Choosing the Best Cloud Adoption Strategy for Your Business, 2012, IBM Press SBN:9780132599849
Siani Pearson, George Yee , Privacy and Security for Cloud Computing, 2013, Springer ISBN:9781447141884
Paul Brant, Denis Guyadeen, How to Trust the Cloud: “Be Careful Up There”, 2010, EMC
ISACA, Business Continuity Management Audit/Assurance Program, 2011, ISACA ISBN:9781604201864
ISACA, IT Strategic Management Audit/Assurance Program, 2011, ISACA ISBN:9781604202335
http://scap.nist.gov/
Justine Simpson, John Taylor, Corporate Governance, Ethics and CSR, 2013, Kogan Page ISBN:9780749463854
Alan Calder, Corporate Governance: A Practical Guide to the Legal Frameworks and International Codes of Practice, 2008, Kogan Page ISBN:9780749448172
Jennifer L. Bayuk,Cyber Security Policy Guidebook, 2012, John Wiley & Sons ISBN:9781118027806
Ben Halpert, Auditing Cloud Computing: A Security and Privacy Guide, 2011, John Wiley & Sons ISBN:9780470874745
Veena Hingarh, Arif Ahmed, Understanding and Conducting Information Systems Auditing, 2013, John Wiley & Sons ISBN:9781118343746
Chris Davis, Mike Schiller, Kevin Wheeler, IT Auditing: Using Controls to Protect Information Assets, Second Edition, 2011 McGraw-Hill/Osborne ISBN:9780071742382
Vic (J.R.) Winkler, Securing the Cloud: Cloud Computer Security Techniques and Tactics, 2011, Syngress Publishing ISBN:9781597495929
Xiaoyu Yang, Lu Liu, Principles, Methodologies, and Service-Oriented Approaches for Cloud Computing, 2013, IGI Global,ISBN:9781466628540
Caroline Wong, Security Metrics: A Beginners Guide, 2012, McGraw-Hill/Osborne ISBN:9780071744003
ISACA, Implementing and Continually Improving IT Governance, 2009, ISACA ISBN:9781604201192
Paul Brant, Above the Clouds: Best Practices in Creating a Sustainable Computing Infrastructure to Achieve Business Value and Growth, 2010, EMC
Jason Bloomberg, The Agile Architecture Revolution: How Cloud Computing, REST-Based SOA, and Mobile Computing Are Changing Enterprise IT, 2013, John Wiley & Sons ISBN:9781118409770
Mark G. O'Neill, Green IT for Sustainable Business Practice: An ISEB Foundation Guide, 2010, BCS ISBN:9781906124625
Kevin T. McDonald, Above the Clouds: Managing Risk in the World of Cloud Computing, 2010, IT Governance ISBN:9781849280327
ENISA, Cloud Computing Risk Assessment, Noiembrie 2009 – http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment
ENISA (European Network and Information Security Agency), Cloud Computing – Benefits, risks and recommendations for information security, 2009
Jake Sorofman, How to Achieve the Strategic Value of Cloud While Delivering Real ROI. www.eweek.com , March 2009
John J. Hampton, Fundamentals of Enterprise Risk Management: How Top Companies Assess Risk, Manage Exposures, and Seize Opportunities, 2009, AMACOM, ISBN:9780814414927
ISACA, Identity Management Audit/Assurance Program, 2009, ISACA http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Identity-Management-Audit-Assurance-Program.aspx
ISACA, Implementing and Continually Improving IT Governance, 2009, ISACA ISBN:9781604201192
ISACA, The Risk IT Framework , 2009 – http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-Management/Pages/Risk-IT1.aspx , ISACA ISBN:[anonimizat]
ISACA, Enterprise Value: Governance of IT Investments: The Val IT Framework 2.0, 2008 http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Val-IT-Framework-2.0.aspx , ISACA ISBN:9781604200669
ISACA, The Business Case Guide: Using Val IT 2.0, 2010, ISACA ISBN:9781604201055
Gautam Shroff, Enterprise Cloud Computing: Technology, Architecture, Applications, 2010, Cambridge University Press ISBN:9780521760959
http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
Craig Gentry, A fully homomorphic encryption scheme, 2009, Phd Thesis
https://www.oasis-open.org/committees/download.php/4136
http://www.ietf.org/rfc/rfc2246.txt
John R. Vacca, Computer and Information Security Handbook, Second Edition, 2013, Morgan Kaufmann ISBN:9780123943972
San Murugesan, G.R. Gangadharan, Harnessing Green IT: Principles and Practices, 2012, John Wiley & Sons ISBN:9781119970057
Michael Gregg, Billy Haines, CASP CompTIA Advanced Security Practitioner Study Guide (Exam CAS-001), 2012, Sybex ISBN:[anonimizat]
Dimosthenis Kyriazis, Athanasios Voulodimos, Spyridon V. Gogouvitis, Theodora Varvarigou, Data Intensive Storage Services for Cloud Environments, 2013, IGI Global ISBN:9781466639348
ISACA, Value Management Guidance for Assurance Professionals: Using Val IT 2.0, 2010, ISACA ISBN:[anonimizat]
Kurt J. Engemann and Douglas M. Henderson, Business Continuity and Risk Management: Essentials of Organizational Resilience, 2012, Rothstein Associates ISBN:9781931332545
Lee Chao, Cloud Computing for Teaching and Learning: Strategies for Design and Implementation, 2012, IGI Global ISBN:9781466609570
N. K. McCarthy, Computer Incident Response Planning Handbook: Executable Plans for Protecting Information at Risk, 2012, McGraw-Hill/Osborne, ISBN:9780071790390
Diane Barrett, Greg Kipper, Virtualization and Forensics: A Digital Forensic Investigator's Guide to Virtual Environments, 2010, Syngress Publishing , ISBN:9781597495578
G. Mateescu, M. Vlădescu, A hybrid approach of system security for small and medium enterprises: Combining different cryptography techniques , 2013, Computer Science and Information Systems (FedCSIS)
Ian Lim, E. Coleen Coolidge, Paul Hourani, Securing Cloud and Mobility: A Practitioner's Guide, 2013, Auerbach Publications, ISBN:9781439850558
John W. Rittinghouse, James F. Ransome, Cloud Computing: Implementation, Management, and Security, 2010, Auerbach Publications, ISBN:9781439806807
Michael Drmota, The development of homomorphic cryptography From RSA to Gentry's privacy homomorphism, Teză de doctorat
Iti Sharma, Fully Homomorphic Encryption Scheme with Symmetric Keys, 2013 Lucrare de Disertație
Georgiana Mateescu, Marius Vlădescu – Auditing Hybrid IT Environments – International Journal of Advanced Computer Science and Applications (http://thesai.org/Publications/IJACSA ) – Aprilie 2014
Georgiana Mateescu, Valentin Sgârciu, Cloud Computing Audit – Scientific Bulletin UPB (Submission ID 2801), 2014
Georgiana Mateescu, Marius Vlădescu, Valentin Sgârciu, Auditing Cloud Computing Migration – IEEE 9th International Symposium on Applied Computational Intelligence and Informatics, SACI 2014
ANEXE
A.1. ACRONIME
Tabelul 9.1:Acronime
A.2 MECANISME DE SECURITATE ÎN ARHITECTURI CLOUD
Tabelul 9.2: Mecanismele de control folosite în procesul de auditare al factorului de siguranță
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Contributii Privind Auditul Sistemelor Informatice In Arhitecturi de Tip Cloud Computing (ID: 112793)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.