Introducción A La Seguridad en Cloud

Introducció a la
seguretat en cloud
computing
PID_00286161
Jordi Guijarro Olivares
Temps mínim de dedicació recomanat: 2 hores

© FUOC • PID_00286161 Introducció a la seguretat en cloud computing
Jordi Guijarro Olivares
Director d'innovació en cibersegure-

tat a i2CAT (http://www.i2cat.net),
el Centre de Recerca a Internet. En-
ginyer en Informàtica per la Univer-
sitat Oberta de Catalunya (UOC) i
màster en Gestió de les TIC per la
Universitat Ramon Llull (URL). Ex-
pert en cloud computing i ciberse-
guretat, ha participat en projectes
de recerca i innovació de la Comis-
sió Europea del programa Horizon
2020.
jordi.guijarro@i2cat.net
L'encàrrec i la creació d'aquest recurs d'aprenentatge UOC han estat coordinats

pel professor: Josep Jorba Esteve
Primera edició: febrer 2022

© d'aquesta edició, Fundació Universitat Oberta de Catalunya (FUOC)
Av. Tibidabo, 39-43, 08035 Barcelona
Autoria: Jordi Guijarro Olivares
Producció: FUOC
Tots els drets reservats
Cap part d'aquesta publicació, incloent-hi el disseny general i la coberta, no pot ser copiada,
reproduïda, emmagatzemada o transmesa de cap manera ni per cap mitjà, tant si és elèctric com
mecànic, òptic, de gravació, de fotocòpia o per altres mètodes, sense l'autorització prèvia
per escrit del titular dels drets.
© FUOC • PID_00286161 Introducció a la seguretat en cloud computing
Índex
1. Introducció a la seguretat en cloud computing......................... 5

1.1. Garanties per als clients en cloud computing................................ 7
1.2. Primeres recomanacions legals ................................................... 7
2. Àmbit, responsabilitats i models de seguretat en el núvol..... 9
3. Models de seguretat en el núvol.................................................... 12
4. Un model simple de procés de seguretat en el núvol................ 14
5. Principals riscos, patrons i mitigació proactiva d'amenaces. 15

5.1. Amenaça núm. 1: fuga d'informació .......................................... 15
5.2. Amenaça núm. 2: credencials compromeses i suplantació en
l'autenticació ............................................................................... 16
5.3. Amenaça núm. 3: interfícies i API hackejades.............................. 17
5.4. Amenaça núm. 4: vulnerabilitats ................................................ 17
5.5. Amenaça núm. 5: segrest de comptes ........................................ 18
5.6. Amenaça núm. 6: intrusos maliciosos ........................................ 18
5.7. Amenaça núm. 7: el paràsit APT ................................................ 19
5.8. Amenaça núm. 8: pèrdua permanent de dades .......................... 19
5.9. Amenaça núm. 9: inadequada diligència ................................... 20
5.10. Amenaça núm. 10: abusos dels serveis en el núvol .................... 20
5.11. Amenaça núm. 11: atacs DoS ..................................................... 21
5.12. Amenaça núm. 12: tecnologia compartida, perills compartits ... 21
6. Control de proveïdors. Procediments operatius de seguretat 22

6.1. Seguiment del servei ................................................................... 22
6.2. Gestió de canvis .......................................................................... 23
6.3. Gestió d'incidents ........................................................................ 24
6.4. Suport i recuperació de dades ..................................................... 25
6.5. Continuïtat del servei ................................................................. 25
6.6. Finalització del servei .................................................................. 26
7. Supervisió i auditoria....................................................................... 27
8. Recomanacions................................................................................... 29
9. Cas d'ús: COVID-19 i cloud computing.......................................... 30
Bibliografia................................................................................................. 33
© FUOC • PID_00286161 5 Introducció a la seguretat en cloud computing
1. Introducció a la seguretat en cloud computing
El model de servei TI basat en cloud i el constant augment de les amenaces in-

formàtiques impliquen un canvi en el concepte de seguretat informàtica en les
organitzacions, especialment en la importància estratègica que té la seguretat
en cloud computing. Estem involucrats en una transformació de paradigmes en
les tecnologies de la informació i comunicació (TIC) en la qual la transforma-
ció digital basada en models cloud és la tònica general. El creixement del cloud
incorpora de manera nativa la web, i aquest creixement deriva en grans reptes
per a la seguretat informàtica.
El ciberdelicte és desenvolupat per organitzacions internacionals que tenen

com a objectiu perjudicar empreses i entitats governamentals. Per aquest mo-
tiu, les organitzacions necessiten tractar la seguretat en el cloud d'una manera
estructurada. En el moment en el qual una organització decideix confiar les
seves dades sensibles, com la informació dels seus clients, l'organització ha de
controlar en tot moment:
• La localització de la informació;
• el proveïdor i model del servei cloud, i
• els nivells de servei respecte a la integritat i la disponibilitat de les dades.
A més, cal tenir en compte el pla de continuïtat de negoci, és a dir, si aquest

proveïdor presenta vulnerabilitats en els seus sistemes de seguretat, quins se-
rien els potencials riscos en el negoci.
La gran majoria de proveïdors de cloud asseguren que la seguretat, en última

instància, és responsabilitat del client. AWS, RackSpace, Google i altres només
es responsabilitzen dels seus centres de dades i infraestructura, la seva seguretat
està certificada per les màximes autoritats en la matèria. En particular, AWS ho
denomina «entorn de responsabilitat compartida». Com a usuaris de diferents
serveis cloud som responsables de les dades que allotgem en servidors i bases
de dades dels proveïdors de cloud. Recordem llavors que la seguretat no sols és
important, sinó que hem de treballar en aquesta.
Figura 1. Models de servei del cloud computing
Els proveïdors� de� plataforma� com� a� servei� (PaaS) s'encarreguen de la se-

guretat de la capa d'infraestructura i plataforma, mentre que el client ha
d'encarregar-se de la seguretat en la capa d'aplicació.
En el cas dels proveïdors�infraestructura�com�a�servei�(IaaS) s'encarreguen de

la seguretat de la capa d'infraestructura, mentre que el client ha d'encarregar-
se de les altres dues.
En la capa de plataforma hem d'utilitzar totes les mesures necessàries per a

mantenir els nostres servidors, bases de dades i còpies de seguretat accessibles
només a personal autoritzat, usant el principi de menor privilegi, atorgant a
cadascun el mínim privilegi necessari per a fer el seu treball.
Els analistes i programadors han d'ocupar-se de la capa d'aplicació; no té gaire

sentit blindar les dades i servidors si l'aplicació permet accessos no legítims a
les dades o a funcions crítiques dels servidors.
El cloud computing és una revolució en el món de les TIC. Posseeix en el seu

desenvolupament una atractiva perspectiva per a les organitzacions, grans o
petites, respecte a un millor aprofitament dels recursos interns i a un model
de gestió optimitzat.
Aquest nou model ofereix a les organitzacions la possibilitat de tenir un focus

més clar en els seus negocis a partir del moment en el qual les tecnologies
de la informació passen a ser tractades com un subministrament més de les
seves cadenes productives, i com en tot nou concepte l'aspecte de la seguretat

informàtica és sempre un dels punts més importants, i que cal tenir en compte
especialment en moments d'intensa transformació.
En aquest apartat dotarem l'estudiant de la visió dels principals riscos:

com la fugida d'informació o les credencials compromeses i la suplantació
en l'autenticació, així com els principals patrons i la mitigació proactiva
d'amenaces mitjançant els procediments operatius de seguretat per al control
de proveïdors.
1.1. Garanties per als clients en cloud computing
Els clients en el núvol necessiten que se'ls garanteixi que els proveïdors apli- Exemples de riscos
quen pràctiques adequades de seguretat per a mitigar els riscos als quals
Alguns exemples dels riscos als
s'enfronten el client i el proveïdor. Necessiten aquesta garantia per a poder quals s'enfronten el client i el
prendre decisions de negoci correctes i per a mantenir o obtenir certificats proveïdor són els atacs distri-
buïts de denegació de servei (o
de seguretat. Un símptoma inicial d'aquesta necessitat d'asseguració és que DDoS).
nombrosos proveïdors en núvol (PN) es veuen bombardejats amb sol·licituds

d'auditories.
Per aquest motiu, hem expressat moltes de les recomanacions de l'informe en

forma de llistat de qüestions que pot ser utilitzat per a oferir o rebre aquestes
garanties.
Els documents basats en la llista de comprovació han d'aportar als clients mit-
jans per a:
• avaluar el risc d'utilitzar serveis en el núvol;

• comparar les ofertes dels diferents proveïdors en el núvol;
• obtenir garanties dels proveïdors en el núvol seleccionats, i
• reduir la càrrega del risc respecte als proveïdors en el núvol.
La llista de comprovació de seguretat abasta tots els aspectes dels requisits en

matèria de seguretat, inclosos la seguretat física i les implicacions legals, polí-
tiques i tècniques.
1.2. Primeres recomanacions legals
La majoria de les qüestions legals associades a la computació en núvol se solen

resoldre durant l'avaluació (és a dir, en comparar els diferents proveïdors) o la
negociació�del�contracte. El cas més comú de computació en núvol és la se-
lecció dels diferents contractes que ofereix el mercat (avaluació de contractes),
en contrast amb la negociació del contracte. No obstant això, podria haver-hi
oportunitats perquè clients potencials de serveis en núvol seleccionessin pro-
veïdors amb contractes negociables.
A diferència dels serveis tradicionals d'internet, es recomana revisar detingu-

dament les clàusules estàndard del contracte, a causa de la naturalesa de la
computació en núvol. Les parts del contracte han de prestar especial atenció
als seus drets i obligacions pel que fa a les notificacions d'incompliment dels
requisits de seguretat, transferències de dades, creació d'obres derivades, can-
vi de control i accés a les dades per part de les forces policials. Pel fet que el
núvol pot utilitzar-se per a subcontractar infraestructura interna crítica, i que
la interrupció d'aquesta infraestructura pot tenir conseqüències de gran abast,
les parts han de considerar detingudament si les limitacions estàndard de la
responsabilitat s'ajusten a les assignacions de responsabilitat, atès l'ús del nú-
vol per les diferents parts, o a les responsabilitats quant a la infraestructura.
Fins que els reglaments i precedents legals abordin les preocupacions concretes
en matèria de seguretat relatives a la computació en núvol, els clients i els
proveïdors en núvol han d'assegurar-se que les condicions del seu contracte
aborden de manera efectiva els riscos de seguretat.
2. Àmbit, responsabilitats i models de seguretat en el

núvol
Pot sonar simplista, però la seguretat en el núvol i el compliment inclouen tot

el que un equip de seguretat és responsable avui dia, només que en el núvol.
Tots els dominis de seguretat tradicionals romanen, però la naturalesa dels
riscos, rols i responsabilitats, i la implementació dels controls, canvien, sovint
dramàticament.
Encara que l'abast general de la seguretat i el compliment no canvien, certa-

ment sí que canvien les peces de les quals qualsevol actor del núvol és respon-
sable de fer en particular. Penseu-ho d'aquesta manera: la computació en el
núvol és un model de tecnologia compartida on les diferents organitzacions
són responsables, sovint, d'implementar i administrar les diferents parts de la
pila. Com a resultat, les responsabilitats de seguretat també es distribueixen
en la pila, i per tant per mitjà de les organitzacions involucrades.
Això es coneix comunament com el model�de�responsabilitat�compartida.

Pensa en això com una matriu de responsabilitat que depèn del proveïdor de
serveis en el núvol en particular i la característica/producte, el model de servei
i el model d'implementació.
En un nivell alt, la responsabilitat de seguretat es correlaciona amb el grau de

control que té un actor donat sobre l'arquitectura en pila:
• Programari�com�a�servei. El proveïdor de serveis en el núvol és respon-

sable de gairebé tota la seguretat, ja que l'usuari de serveis en el núvol no-
més pot accedir i administrar el seu ús de l'aplicació, i no pot alterar el
funcionament d'aquesta. Per exemple, un proveïdor de SaaS és responsa-
ble de la seguretat del perímetre, el registre/monitoratge/auditoria i la se-
guretat de l'aplicació, mentre que el consumidor només pot administrar
l'autorització i els drets.
• Plataforma�com�a�servei. El proveïdor de serveis en el núvol és responsa-

ble de la seguretat de la plataforma, mentre que el consumidor és respon-
sable de tot el que implementa en la plataforma, inclosa la forma en la qual
configuren les característiques de seguretat ofertes. Les responsabilitats es
divideixen de manera més semblant. Per exemple, quan s'utilitza una base
de dades com a servei, el proveïdor gestiona la seguretat, els pedaços i la
configuració central, mentre que l'usuari de serveis en el núvol és respon-
sable de tota la resta, incloses les funcions de seguretat de la base de dades,
els comptes d'administració o fins i tot els mètodes d'autenticació.
• Infraestructura�com�a�servei. Igual que PaaS, el proveïdor és responsable

de la seguretat de base, mentre que l'usuari de serveis en el núvol és res-
ponsable de tot el que construeix en la infraestructura. A diferència de Pa-
aS, això atorga molta més responsabilitat al client. Per exemple, és proba-
ble que el proveïdor de IaaS controli el seu perímetre per cercar atacs, però
el consumidor és totalment responsable de com defineixen i implementen
la seva seguretat de xarxa virtual, segons les eines disponibles en el servei.
Figura 2. Models de responsabilitat
Aquestes funcions es compliquen encara més quan s'utilitzen cloud brokers o

altres intermediaris i socis. La consideració de seguretat més important és saber
exactament qui és responsable de què, en qualsevol projecte en el núvol. És
menys important si un proveïdor de serveis en el núvol en particular ofereix
un control de seguretat específic, sempre que sàpiga exactament què ofereixen
i com funciona. Pot omplir els buits amb els seus propis controls o triar un
proveïdor diferent si no pot tancar la bretxa de controls. La seva capacitat per
a fer això és molt alta per a IaaS, i menys per a SaaS.
Aquesta és l'essència de la relació de seguretat entre un proveïdor de serveis en

el núvol i el consumidor. Què fa el proveïdor? Què necessita fer el consumidor?
El proveïdor de serveis en el núvol permet al consumidor fer el que necessita?
Què està garantit en els contractes i en l'acord de nivell de servei, i què implica
la documentació i els detalls de la tecnologia?
Aquest model de responsabilitat compartida es correlaciona directament amb

dues�recomanacions:
1) Els proveïdors de serveis en el núvol han de documentar clarament els seus

controls interns de seguretat i les característiques de seguretat del client perquè
l'usuari de serveis en el núvol pugui prendre una decisió informada. Els prove-
ïdors també han de dissenyar i implementar adequadament aquests controls.
2) Els usuaris de serveis en el núvol, per a qualsevol projecte donat en aquest,

han de crear una matriu de responsabilitats per a documentar qui està imple-
mentant quins controls i com. Això també hauria d'alinear-se amb els estàn-
dards de compliment necessaris.
A tall d'exemple, la Cloud Security Alliance proporciona dues�eines per a aju-

dar a complir aquests requisits:
1) El qüestionari�d'iniciativa�d'avaluacions�de�consens�(CAIQ). Una planti- Enllaços recomanats

lla estàndard perquè els proveïdors de serveis en el núvol documentin els seus
Podeu consultar el qüestiona-
controls de seguretat i compliment. ri d'iniciativa d'avaluacions
de consens (CAIQ) aquí.
Podeu consultar la matriu
2) La matriu�de�controls�del�núvol�(CCM), que enumera els controls de se- de controls del núvol (CCM)
guretat en el núvol i els mapa en múltiples estàndards de seguretat i compli- aquí.
ment. La CCM també es pot utilitzar per a documentar les responsabilitats de

seguretat. Tots dos documents necessitaran ajustos per a requisits específics
d'organització i projecte, però proporcionen una plantilla d'inici completa i
poden ser especialment útils per a garantir que es compleixin els requisits de
compliment.
3. Models de seguretat en el núvol
Els models de seguretat en el núvol són eines per a ajudar a orientar les deci-
sions de seguretat. El terme model es pot utilitzar de forma una mica nebulosa,
per la qual cosa per als nostres propòsits es descompon en els tipus següents:
• Els models o frameworks conceptuals inclouen visualitzacions i descripci-

ons utilitzades per a explicar conceptes i principis de seguretat en el núvol,
com el model lògic de CSA.
• Models de control o marcs de treball que categoritzen i detallen controls

de seguretat en el núvol específics o categories de controls, com la CCM
de CSA.
• Les arquitectures de referència són plantilles per a implementar la segure-

tat en el núvol, generalment generalitzades (per exemple, una arquitectura
de referència de seguretat IaaS). Poden ser molt abstractes, vorejant el con-
ceptual, o bastant detallats, baixant fins a controls i funcions específics.
• Els patrons de disseny són solucions reutilitzables per a problemes parti-

culars. En seguretat, un exemple és l'administració de recursos IaaS. Igual
que amb les arquitectures de referència, poden ser més o menys abstractes
o específiques, fins i tot baixar fins a patrons d'implementació comuns en
plataformes de núvol particulars.
Les línies entre aquests models sovint es difuminen i se superposen, segons els
objectius del desenvolupador del model. Fins i tot agrupar-los tots junts sota
l'encapçalament «model» és probablement inexacte, però, atès que veiem els
termes usats de manera intercanviable en diferents fonts, té sentit agrupar-los.
La Cloud Security Alliance (CSA) ha revisat i recomana els models següents:
• CSA arquitectura empresarial.
• CSA matriu de controls en el núvol.
• L'esborrany NIST. L'arquitectura de referència de seguretat de cloud compu-

ting (NIST Special Publication 500-299), que inclou models conceptuals,
arquitectures de referència i un marc de control.
• ISO/IEC FDIS 27017. Tecnologia de la informació, tècniques de seguretat i

codi de pràctica per a controls de seguretat de la informació basat en ISO/
IEC 27002 per a serveis en el núvol.
Figura 3. Frameworks de referència

4. Un model simple de procés de seguretat en el núvol
Si bé els detalls d'implementació, controls necessaris, processos específics i di-

verses arquitectures de referència i models de disseny varien molt segons el
projecte específic del núvol, hi ha un procés relativament senzill i d'alt nivell
per a administrar la seguretat en el núvol:
• identificar els requisits de seguretat i compliment necessaris i qualsevol

control existent;
• seleccionar el proveïdor de serveis en el núvol, servei i models
d'implementació;
• definir l'arquitectura;
• avaluar els controls de seguretat;
• conèixer les llacunes de control;
• dissenyar i implementar controls per a omplir els buits, i
• gestionar canvis al llarg del temps.
Atès que els diferents projectes en el núvol, fins i tot en un sol proveïdor, Avaluació per propis
probablement aprofitaran conjunts de configuracions i tecnologies completa- mèrits
ment diferents, cada projecte ha d'avaluar-se pels seus propis mèrits. Per exemple, els controls de
seguretat per a una aplicació
implementada en IaaS pur en
un proveïdor poden semblar
La clau és identificar els requisits, dissenyar l'arquitectura i identificar molt diferents d'un projecte si-
milar que en el seu lloc utilitza
els buits en funció de les capacitats de la plataforma subjacent del núvol. més PaaS d'aquest mateix pro-
veïdor.
És per això que necessita conèixer l'arquitectura i el proveïdor de serveis
en el núvol abans de començar a traduir els requisits de seguretat en
controls.
Figura 4. Fases en l'adopció

5. Principals riscos, patrons i mitigació proactiva

d'amenaces
La naturalesa compartida en els catàlegs de serveis en el camp de la computa-

ció en el núvol introdueix l'aparició de noves bretxes de seguretat que poden
amenaçar els beneficis obtinguts en el canvi cap a tecnologies basades en el
núvol. Organitzacions com la CSA adverteixen que és important considerar
que els serveis en el núvol per naturalesa permeten als usuaris ometre les po-
lítiques de seguretat de tota l'organització utilitzant serveis externs. A aquest
fenomen se'l denomina «Shadow IT». Per això és important establir nous con-
trols per a la detecció, el control i la conscienciació dels riscos d'aquesta nova
situació.
Figura 5. Models i àrees en el cloud computing
En termes generals, en funció del tipus de servei contractat, segons va incre-

mentant-se el nivell d'abstracció disminueix el control que el client té sobre la
infraestructura. De la mateixa manera, com més gran control té l'organització
client sobre la infraestructura que proporciona el servei, major nivell de segu-
retat i control pot aplicar sobre aquesta i, per tant, sobre la informació tractada.
5.1. Amenaça núm. 1: fuga d'informació
Els entorns en el núvol s'enfronten a moltes de les amenaces que ja trobem

en les xarxes corporatives tradicionals, però aquestes s'accentuen a causa de la
gran quantitat de dades emmagatzemades en servidors en el núvol i els pro-
veïdors es converteixen en un objectiu més atractiu. Si parlem de dades/in-

formació, és molt important tenir en compte que la gravetat del dany depèn
en gran manera de la sensibilitat de les dades exposades. La informació finan-
cera exposada tendeix a sortir en els titulars de premsa generalista, però les
infraccions que involucren informació de salut, secrets comercials i propietat
intel·lectual són les més devastadores.
Quan té lloc una fugida de dades, les empreses poden incórrer en multes, o
poden enfrontar-se a demandes o fins i tot a càrrecs criminals. També cal con-
siderar aspectes com les recerques de la infracció i les notificacions cap als
clients que per danys d'imatge poden afegir costos molt significatius. Efectes
indirectes, com danys a la marca i la pèrdua de negoci, poden afectar les orga-
nitzacions durant diversos anys.
Al final, els proveïdors de núvol implementen controls de seguretat per a pro-

tegir els seus entorns, però cal recordar que, en última instància, les organitza-
cions són responsables de protegir les seves pròpies dades dins de l'organització
i també en el núvol. És molt recomanable que les organitzacions utilitzin me-
canismes com l'autenticació multifactor i el xifratge de dades per a protegir-se
contra les fugides d'informació.
5.2. Amenaça núm. 2: credencials compromeses i suplantació en

l'autenticació
Les bretxes de dades i altres atacs sovint resulten d'un sistema d'autenticació
«pobre», com permetre contrasenyes febles i una mala administració de claus
o certificats. Les organitzacions sovint lluiten amb la gestió d'identitats a me-
sura que tracten d'assignar permisos adequats a la funció de treball de l'usuari.
Però, en algunes ocasions, la falta de gestió correcta de les baixes provoca que
aquestes no siguin efectives en el moment en el qual la funció de treball canvia
o el mateix usuari abandona l'organització.
Els sistemes d'autenticació multifactor, com les contrasenyes d'un sol ús,
l'autenticació mitjançant dispositius mòbils i les targetes intel·ligents, prote-
geixen els serveis en el núvol perquè dificulten que els atacants iniciïn sessió
amb contrasenyes robades. Hi ha multitud d'exemples d'organitzacions i ser-
veis d'internet, molt coneguts, que han exposat milions de registres de clients
o usuaris, com a resultat de credencials d'usuari robades. En la majoria dels
casos associat a fallades en el desplegament d'un procés d'autenticació de ti-
pus multifactor, així que una vegada que els atacants obtenen les credencials,
només cal esperar que el procés que s'encarrega a la resposta a incidents sigui
efectiu.
Molts desenvolupadors cometen l'error d'incrustar credencials i claus cripto-

gràfiques en el codi font i deixar-les en repositoris orientats al públic com Git-
Hub. Les claus necessiten estar adequadament protegides, i una infraestructura
de clau pública ben assegurada és necessària. També necessiten ser canviades

periòdicament perquè sigui més difícil per als atacants utilitzar claus que han
obtingut sense autorització.
Les organitzacions que planegen federar la identitat amb un proveïdor del

núvol necessiten entendre les mesures de seguretat que el proveïdor utilitza per
a protegir la plataforma d'identitat. Centralitzar la identitat en un sol repositori
té els seus riscos i en cada cas s'ha de valorar molt bé la protecció i salvaguardes
associades.
5.3. Amenaça núm. 3: interfícies i API hackejades
Pràcticament, tots els serveis i aplicacions en el núvol ara ofereixen API per a
facilitar tasques d'automatització i interoperabilitat. Els equips de TI utilitzen
interfícies i API per a gestionar i interactuar amb serveis en el núvol, inclosos
aquells que ofereixen aprovisionament en autoservei, gestió remota, orques-
tració, monitoratge i supervisió en el núvol.
La seguretat i la disponibilitat dels serveis en el núvol, des de l'autenticació

i el control d'accés fins al xifratge i el monitoratge d'activitats, depenen de
la seguretat de l'API. El risc augmenta amb tercers que depenen de les API
i es basen en aquestes interfícies, ja que les organitzacions poden necessitar
exposar més serveis i credencials. Les interfícies febles i les API exposen les
organitzacions a qüestions de seguretat relacionades amb la confidencialitat,
la integritat, la disponibilitat i la rendició de comptes.
Les API i les interfícies tendeixen a ser la part més exposada d'un sistema per-
què normalment són accessibles des d'internet. Es recomanen controls ade-
quats com la «primera línia de defensa i detecció». Les aplicacions i els sistemes
de modelatge d'amenaces, inclosos els fluxos de dades i l'arquitectura/disseny,
es converteixen en parts importants del cicle de vida del desenvolupament.
També es recomana fer revisions de codi enfocades a la seguretat i rigoroses
proves de penetració.
5.4. Amenaça núm. 4: vulnerabilitats
Les vulnerabilitats del sistema, o bugs explotables en els programes, no són

noves, però s'han convertit en un problema major amb l'accentuació dels sis-
temes d'informació multitenant en el model de cloud computing. Les organitza-
cions comparteixen memòria, bases de dades i altres recursos en estreta pro-
ximitat entre si, creant noves superfícies d'atac.
Afortunadament, els atacs a les vulnerabilitats del sistema poden ser mitigats
amb «processos de TI bàsics». Les millors pràctiques inclouen l'exploració re-
gular de vulnerabilitats, l'administració ràpida de pedaços i un ràpid seguiment
de les amenaces informades.
És important considerar que els costos de mitigar les vulnerabilitats del siste-
ma «són relativament petits en comparació amb altres despeses de TI». El cost
de posar els processos de TI en el lloc que els correspon, amb l'objectiu de
controlar, detectar i reparar vulnerabilitats, és petit en comparació amb el mal
potencial. Les organitzacions necessiten posar pedaços el més ràpid possible,
preferiblement com a part d'un procés automatitzat i recurrent. Els processos
de control de canvis que tracten els pedaços d'emergència asseguren que les
activitats relacionades amb el manteniment del programari estiguin deguda-
ment documentades i revisades pels equips tècnics.
5.5. Amenaça núm. 5: segrest de comptes
La pesca electrònica (phishing), el frau i les explotacions de codi continuen

tenint èxit, i els serveis en el núvol agreguen una nova dimensió a l'amenaça,
pel fet que els atacants poden interceptar activitat, manipular transaccions i
modificar dades. A això s'ha d'afegir que els atacants també poden utilitzar
l'aplicació en el núvol per a llançar altres atacs de manera encadenada.
Les estratègies més comunes en la defensa en profunditat poden contenir

els danys ocasionats per una infracció. Les organitzacions han de prohibir
l'intercanvi de credencials de compte entre usuaris i serveis, així com habili-
tar sistemes d'autenticació multifactor quan estiguin disponibles. Els comptes,
fins i tot els de servei, han de ser monitorats perquè cada transacció pugui
ser rastrejada i identificar un usuari unipersonal si fos necessari. Una part de
l'estratègia és protegir les credencials dels comptes d'usuari per a evitar que
aquestes siguin robades.
5.6. Amenaça núm. 6: intrusos maliciosos
Aquesta amenaça té moltes cares: un empleat o un antic empleat, un admi-

nistrador de sistemes, un client o fins i tot un partner. L'activitat maliciosa pot
venir motivada des del robatori de dades fins a la venjança. En un escenari en
el núvol, un actor privilegiat pot destruir infraestructures senceres o manipu-
lar dades. Els sistemes que depenen únicament d'un proveïdor de serveis en el
núvol, com podrien ser els de xifratge, corren sens dubte un major risc.
Es recomana que siguin les mateixes organitzacions les que controlin el procés
de xifratge i les claus, segregant les tasques i minimitzant l'accés donat als
usuaris. Les activitats de registre, monitoratge i auditoria dels administradors
també són considerades avui com a crítiques.
En entorns de cloud computing, és fàcil interpretar erròniament un intent d'atac

per part d'un procés rutinari com a activitat «malintencionada» sobre infor-
mació privilegiada. Un exemple seria un administrador que copia accidental-
ment una base de dades confidencial de clients en un servidor accessible pú-
blicament. La formació i la prevenció per a prevenir aquests errors es tornen

aspectes més crítics en el núvol, a causa d'una major exposició dels sistemes
i serveis.
5.7. Amenaça núm. 7: el paràsit APT
La CSA anomena encertadament a les amenaces persistents avançades (APT,

per les seves sigles en anglès) formes «paràsites» d'atac. Les APT s'infiltren en els
sistemes per a establir-se en un punt de suport, i després exfolien furtivament
les dades i la propietat intel·lectual durant un període prolongat de temps.
Normalment, les APT es mouen lateralment per la xarxa i es barregen amb el

trànsit normal, per la qual cosa són difícils de detectar. Els principals proveï-
dors de núvol apliquen tècniques avançades per a evitar que les APT s'infiltrin
en la seva infraestructura, però els clients han de ser tan diligents en la detec-
ció de compromisos APT en els comptes del núvol com ho farien en els seus
sistemes locals.
Entre els punts d'entrada comuns s'inclouen la pesca electrònica, els atacs di-
rectes, unitats USB precarregades amb un programa maligne i xarxes de tercers
compromeses. En particular, es recomana entrenar els usuaris perquè recone-
guin les tècniques de pesca electrònica o phishing.
Els programes de conscienciació mantenen els usuaris en alerta i són menys

propensos a ser enganyats perquè una APT ingressi en la xarxa, a més que els
departaments de TI han de mantenir-se informats dels últims atacs avançats.
Els controls de seguretat avançats, la gestió de processos, els plans de resposta a
incidents i la capacitació del personal de TI condueixen a majors pressupostos
de seguretat. Les organitzacions han de sospesar aquests costos enfront del
possible dany econòmic infligit pels atacs reeixits d'APT.
5.8. Amenaça núm. 8: pèrdua permanent de dades
A mesura que el núvol s'ha madurat, els informes de pèrdua permanent de

dades a causa de l'error del proveïdor s'han tornat extremadament estranys. No
obstant això, se sap que els hackers maliciosos eliminen de manera permanent
les dades del núvol per a danyar les empreses, i els centres de dades en el núvol
són tan vulnerables a desastres naturals com qualsevol instal·lació.
Els proveïdors de núvol recomanen distribuir dades i aplicacions mitjançant

múltiples zones per a una major protecció. Les mesures adequades de suport
de dades són essencials, així com l'adhesió a les millors pràctiques en la con-
tinuïtat del negoci i la recuperació de desastres. La còpia de seguretat diària
de dades i l'emmagatzematge fora de lloc continuen sent importants per als
entorns en el núvol.
La càrrega d'evitar la pèrdua de dades no és tot en el proveïdor de serveis en el

núvol. Si un client xifra dades abans de pujar-les al núvol, llavors aquest client
ha d'anar amb compte de protegir la clau de xifratge. Una vegada que es perd
la clau, també es perden les dades.
Les polítiques de compliment sovint estipulen quant temps les organitzaci-

ons han de conservar els registres d'auditoria i altres documents. La pèrdua
d'aquestes dades pot tenir greus conseqüències reguladores. Les noves normes
de protecció de dades de la UE també tracten la destrucció de dades i la cor-
rupció de dades personals com a infraccions de dades que requereixen una
notificació adequada. Cal conèixer les regles per a evitar problemes.
5.9. Amenaça núm. 9: inadequada diligència
Les organitzacions que abracen el núvol sense entendre completament

l'entorn i els seus riscos associats poden trobar-se amb un «increment de riscos
comercials, financers, tècnics, legals i de compliment». El grau del risc depèn
de si l'organització està intentant migrar al núvol o fusionar-se (o treballar)
amb una altra companyia en el núvol. Per exemple, les organitzacions que no
examinen un contracte de servei poden no ser conscients de la responsabilitat
del proveïdor en cas de pèrdua de dades o algun tipus d'incompliment.
Els problemes operacionals i d'arquitectura sorgeixen si l'equip de desenvolu-

pament d'una empresa no està familiaritzada amb les tecnologies en el núvol,
ja que les aplicacions es despleguen en un núvol en particular i no són habi-
tuals avui dia els models híbrids o de tipus multicloud.
5.10. Amenaça núm. 10: abusos dels serveis en el núvol
Els serveis en el núvol poden ser utilitzats per a donar suport a activitats
il·legals, com l'ús de recursos de computació en el núvol per a trencar una clau
de xifratge i llançar un atac. Altres exemples inclouen el llançament d'atacs
DDoS, l'enviament de correus electrònics d'spam i phishing, i l'allotjament de
contingut maliciós.
Els proveïdors han de reconèixer aquests tipus d'abús –com l'anàlisi del trànsit
per a reconèixer els atacs DDoS– i oferir eines perquè els clients puguin super-
visar la salut dels seus entorns cloud. Els clients han d'assegurar-se que els pro-
veïdors ofereixin un mecanisme per a notificar l'abús. Encara que els clients
no poden ser víctimes directes d'accions malicioses, l'abús en el servei en el
núvol pot generar problemes de disponibilitat de serveis i pèrdua de dades.
5.11. Amenaça núm. 11: atacs DoS
Els atacs DoS han existit durant anys, però han guanyat prominència gràcies
a la computació en el núvol, ja que sovint afecten de manera destacada la
disponibilitat. Els sistemes poden alentir-se o estar fora de joc.
«Experimentar un atac de denegació de servei és com estar atrapat en un embús de trànsit

en hora punta; hi ha una manera d'arribar a la seva destinació i no hi ha res que pugui
fer sobre aquest tema, excepte asseure's i esperar».
Els atacs de DoS consumeixen grans quantitats de processament, una factura

que el client pot finalment haver de pagar. Encara que els atacs DDoS de gran
volum no són molt comuns, les organitzacions han de ser conscients dels atacs
asimètrics en l'àmbit d'aplicació de DoS, que es dirigeixen a vulnerabilitats de
servidor web i altres components crítics com les bases de dades.
La norma habitual és que els proveïdors de núvol tendeixin a estar més ben
preparats per a controlar atacs de DoS que els seus clients. La clau és tenir un
pla per a mitigar l'atac abans que ocorri, per la qual cosa els administradors
tenen accés a aquests recursos quan els necessiten.
5.12. Amenaça núm. 12: tecnologia compartida, perills

compartits
Les vulnerabilitats en la tecnologia compartida suposen una amenaça signifi-

cativa per a la computació en el núvol. Els proveïdors de serveis en el núvol
comparteixen infraestructura, plataformes i aplicacions, i si sorgeix una vul-
nerabilitat en qualsevol d'aquestes capes, afecta tot i tothom. «Una sola vul-
nerabilitat o mala configuració pot portar a un compromís per mitjà del núvol
d'un proveïdor sencer».
Si un component es veu compromès –diguem, un hipervisor, un component

de plataforma compartida o una aplicació–, exposa tot l'entorn a un possible
compromís i violació. En definitiva, és molt recomanable una estratègia de
defensa en profunditat, incloent-hi l'autenticació multifactor en tots els hosts,
sistemes de detecció d'intrusos basats tant a nivell de host com en xarxa, apli-
cant el concepte de privilegis mínims, segmentació de xarxa i pedaç de recur-
sos compartits.
6. Control de proveïdors. Procediments operatius de

seguretat
Algunes operacions del servei han de ser realitzades de manera conjunta per
totes dues parts: contractada i contractant, i cal establir els rols, les respon-
sabilitats (capacitat d'autoritzar i obligació de rendir comptes) i els protocols
adequats per a dur-les a terme.
Cal destacar les activitats següents, sense que siguin les úniques que s'han de
procedimentar:
• Manteniment i gestió de canvis.

• Gestió d'incidents.
• Continuïtat - recuperació de desastres.
• Gestió del personal.
• Configuració de seguretat.
• Recuperació de dades de còpies de seguretat.
6.1. Seguiment del servei
En els serveis prestats per tercers a l'organització, tan important és l'acord con-
tractual amb el proveïdor de serveis com el seguiment que cal realitzar del
servei prestat. Per a poder tenir el control dels serveis, i per tant també poder
exigir-li al proveïdor el compliment de qualssevol mesures de seguretat apli-
cables, cal un monitoratge d'aquests.
• El mesurament del compliment del servei i el procediment per a restaurar

les desviacions estipulades contractualment.
• El procés de coordinació per al manteniment dels sistemes implicats.
• El procés de coordinació davant d'incidents o desastres.
Quant al primer aspecte, i donades les característiques de la prestació de serveis

en el núvol, a vegades amb aspectes rellevants fora del control de l'organització
client i també atesa la seva forma de pagament, en funció de l'ús, és molt im-
portant reflectir d'una manera clara els termes del compliment. És necessari
identificar en el contracte els drets de l'organització client per a poder moni-
torar el funcionament del servei i d'aquesta manera comprovar el compliment
de les mesures de seguretat, els controls i les polítiques que garanteixen la in-
tegritat, confidencialitat i disponibilitat de les dades, i de la mateixa manera
poder realitzar la comprovació que el nivell de prestació és el pactat. La defi-
nició i el control dels SLA són vitals per a poder garantir el compliment del
que s'estipula al contracte.
L'organització ha de monitorar de manera independent el compliment dels

termes establerts al contracte, bé per mitjà de controls tècnics propis, bé mit-
jançant la revisió i aprovació periòdica dels informes de servei proporcionats
pel CSP.
És necessari executar aquest monitoratge sobre almenys els controls�de�segu-

retat�i�servei següents amb independència de la categoria del sistema:
• Nivells de qualitat, disponibilitat i capacitat del servei ofert, incloent-hi el

compliment de les obligacions de servei acordades i la resposta oferta pel
proveïdor davant de desviacions significatives.
• Gestió d'incidents de seguretat, incloent-hi tota la informació necessària

per a determinar orígens, objectius, riscos, etc., associats a qualsevol inci-
dent rellevant.
• Controls d'accés als serveis, incloent-hi un llistat actualitzat d'usuaris au-

toritzats per a utilitzar els serveis disponibles, i els privilegis associats en
cada cas.
• Compliment normatiu i legislatiu entre el prestador i el client dels serveis,

incloent-hi els aspectes de compliment d'aplicació sobre el prestador que
corresponguin en cada cas, com auditories LOPD, ISO, financeres, etc.
• Situació actualitzada de les mesures de protecció de la informació establer-

tes pel proveïdor, incloent-hi aspectes de seguretat física, protecció contra
programari maliciós, seguretat del personal, còpies de seguretat, etc.
• Mecanismes de comprovació regular dels controls de seguretat per part del

proveïdor i resultats d'aquestes comprovacions.
Tota la informació dels controls anteriors proporcionada periòdicament pel

proveïdor de serveis ha d'incloure de manera obligatòria qualssevol anomali-
es o desviacions significatives produïdes durant el període, així com les acci-
ons executades en cada cas com a resposta a aquestes situacions susceptibles
d'introduir riscos en l'organització. Addicionalment, hem de sol·licitar al pro-
veïdor de serveis la informació d'auditoria i no conformitats d'aplicació en
cada cas, per a poder verificar que les mesures de seguretat preses per aquest
són les correctes i oportunes per a solucionar desviacions trobades durant el
procés d'auditoria.
6.2. Gestió de canvis
Un altre aspecte que cal tractar en la gestió diària del servei és el referent a
la gestió� i� coordinació� del� manteniment� dels� sistemes. En aquest sentit,
s'haurà d'establir contractualment d'acord amb els requisits mínims de nor-
matives, com l'Esquema Nacional de Seguretat (ENS), l'obligació de mantenir

actualitzats els sistemes per a garantir el seu correcte funcionament, així com
eliminar les possibles vulnerabilitats que poden afectar els sistemes.
Haurà de definir-se un procediment de coordinació en el manteniment de sis-

temes entre totes dues parts per a prevenir parades o errors en la prestació del
servei; aquest procediment estarà en línia amb el procés de gestió de canvi i in-
clourà la notificació amb suficient antelació de la realització de manteniments
per part del proveïdor, identificant els temps en els quals pot interrompre's
el servei. La notificació es realitzarà prèviament i posteriorment al manteni-
ment i després d'aquest es demanarà al client conformitat del funcionament
correcte del servei.
D'altra banda, sempre que el manteniment o actualització impliqui un can-

vi més gran o pugui suposar el funcionament incorrecte dels sistemes de
l'organització client, el proveïdor habilitarà prèviament un entorn actualitzat
perquè el client pugui verificar el correcte funcionament dels seus sistemes en
preproducció. A més, el proveïdor haurà d'informar periòdicament dels man-
teniments i les actualitzacions realitzats en els sistemes que alberguen els sis-
temes del client.
6.3. Gestió d'incidents
D'acord amb normatives vigents i bones pràctiques, el proveïdor haurà

de disposar d'un procediment� de� gestió� d'incidents. S'haurà d'informar
l'organització client de:
• El procediment de notificació d'incidents.

• La tipologia d'incidents inclosos en el servei.
• Els procediments específics davant incidents de seguretat.
• Els temps de resposta i resolució d'incidents.
• El manteniment i la gestió del registre d'incidents.
Haurà de definir-se un procediment de coordinació davant d'incidents que

puguin afectar els sistemes del client, procediment que haurà de contemplar
els fluxos d'informació i les interaccions entre client i proveïdor durant la ges-
tió de l'incident. Al seu torn, el proveïdor haurà d'informar periòdicament dels
incidents que han afectat els sistemes que suporten els sistemes del client.
En els nivells de servei, en el cas d'incidents que afectin la informació o els

serveis de l'organisme contractant, el proveïdor haurà de facilitar tota la infor-
mació forense necessària per a analitzar l'incident i la seva gestió.
6.4. Suport i recuperació de dades
El proveïdor haurà de disposar d'un�procediment�de�còpies�de�seguretat que

garanteixi la restauració de la informació com descriu [mp.info.9]. El proveïdor
haurà d'informar l'organització client de:
• la política de còpies de seguretat;

• les mesures de xifratge d'informació en suport;
• el procediment de sol·licitud de restauracions de suport;
• la realització de proves de restauració;
• l'abast dels suports, i
• el trasllat de còpies de seguretat (si escau).
6.5. Continuïtat del servei
D'acord amb normatives com l'Esquema Nacional de Seguretat (ENS) o normes

com l'ISO27001, els sistemes afectats hauran de disposar de mesures�per�a�la
continuïtat�del�servei. Si bé els nivells de disponibilitat, així com els temps de
recuperació en la prestació de serveis, es troben recollits contractualment en
els SLA, s'haurà de sol·licitar al proveïdor evidència de l'existència d'un pla de
continuïtat de negoci que garanteixi la restauració dels serveis. El proveïdor
haurà d'informar l'organització client de:
• l'existència d'un pla de continuïtat de negoci;

• l'evidència satisfactòria de l'execució periòdica de proves de continuïtat, i
• l'anàlisi d'impacte del servei proporcionat.
On es consideraran els aspectes següents en funció del nivell de disponibilitat

requerit:
• S'haurà de requerir al proveïdor evidència de l'existència d'un pla de conti-

nuïtat de negoci l'abast del qual inclogui els serveis objecte de la prestació.
• S'exigirà constància que els temps de recuperació identificats en l'anàlisi

d'impacte estan alineats amb els criteris definits en els SLA, quant a temps
de recuperació del servei.
• Haurà de definir-se un procediment de coordinació davant d'incidents i

desastres que puguin afectar els sistemes del client, procediment que hau-
rà de contemplar els fluxos d'informació i les interaccions entre client i
proveïdor durant la gestió tant d'incidents com de desastres.
• Al seu torn el proveïdor haurà d'informar periòdicament dels incidents

que han afectat els sistemes que suporten els sistemes del client.
• Es realitzaran proves periòdiques que involucrin l'organisme i els diferents

proveïdors i subproveïdors per a validar el correcte funcionament dels
plans i el compliment dels terminis i serveis mínims previstos.
6.6. Finalització del servei
Excepte quan la part contractant disposi d'una còpia actualitzada de la seva

informació, s'hauran d'establir els procediments�perquè�la�part�contractant
recuperi�la�informació�lliurada�al�proveïdor. En aquests procediments s'han
de fixar formats de dades i temps.
Excepte quan la part contractant no hagi transferit informació en clar al pro-

veïdor, s'hauran d'establir procediments�per�a�l'eliminació�de�les�còpies�en
els�equips�del�proveïdor. Aquests procediments han d'incloure els mecanis-
mes d'esborrat i les garanties que han estat aplicats correctament. Els temps
de destrucció de la informació hauran de tenir en compte els requisits legals
de retenció, si n'hi hagués.
Els procediments anteriors han de tenir en el proveïdor la part corresponent

per a prolongar-los a possibles tercers proveïdors subcontractats.
7. Supervisió i auditoria
L'organització client, com a responsable última dels possibles riscos que afec-
tin tant la informació com els serveis prestats, haurà de disposar d'un determi-
nat nivell de control sobre aquests serveis. En aquest sentit, i per a garantir el
compliment de les mesures de seguretat d'aplicació en cada cas, l'organització
haurà d'avaluar�la�conveniència�de�disposar�del�dret�d'auditoria, amb la
profunditat corresponent, sobre el proveïdor de serveis o de sol·licitar-li la do-
cumentació següent:
• Una declaració d'aplicabilitat de les mesures que han d'aplicar-se.

• Una auditoria que verifiqui mitjançant evidències el compliment de les
mesures de seguretat que siguin aplicable d'acord amb el nivell del sistema.
• Auditories de compliment de normativa necessària per a satisfer els requi-
sits de seguretat de la informació de l'organisme contractant. Per exemple,
GDPR, SAS70, PCI-DSS, etc.
El proveïdor pot disposar de certificacions o acreditacions en matèria de se-

guretat. Aquestes certificacions poden simplificar l'auditoria completa del ser-
vei prestat, en la seva condició d'evidències de compliment que ha de valorar
l'equip auditor.
Exemples de certificacions o acreditacions
• Auditories recomanades per ENISA per a proveïdors de serveis en el núvol [ENISA-

CCSL].
• Sistema de gestió de la seguretat de la informació (SGSI) [ISO/IEC 27001:2013].
• Sistema de gestió de la continuïtat [ISO 22301:2012].
• Cloud Controls Matrix [CCM].

Taula 1. Control de mesures de seguretat basades en la norma ISO 27001 i Cloud Control Ma-
trix (CSA)
Mesures de seguretat ISO 2700 CCM
org Marc organitzatiu nivell 2005 2013 nivell v3
org. 1 Política de seguretat 1 27001: 27001: 1 GRM-05

• 4.2.1 • 4 GRM-09
• 5.1 • 5.2
27002: • 5.3
• 5.1.1
27002:
• 5.1.2 • 6.1.1
• 6.1.2 • 18.1.1
• 6.1.3
• 15.1.1
8. Recomanacions
Heus aquí algunes recomanacions finals:
• Comprendre les diferències entre la computació en el núvol i la infraes-

tructura tradicional o la virtualització, i com l'abstracció i l'automatització
afecten la seguretat.
• Familiaritzar-se amb el model NIST per a computació en el núvol i

l'arquitectura de referència CSA.
• Usar eines com ara el qüestionari de la iniciativa d'avaluacions de consens

de CSA (CAIQ) per a avaluar i comparar proveïdors de serveis en el núvol.
• Els proveïdors de serveis en el núvol han de documentar clarament les

seves característiques i controls de seguretat i publicar-los utilitzant eines
com CSA CAIQ.
• Utilitzar eines com la matriu de controls de núvol de CSA per a avaluar i

documentar els requisits i controls de compliment i seguretat del projecte
en el núvol, així com qui és responsable de cadascun.
• Usar un model de procés de seguretat en el núvol per a seleccionar prove-

ïdors i arquitectures de disseny, identificar bretxes de control i implemen-
tar controls de seguretat i compliment.
9. Cas d'ús: COVID-19 i cloud computing
En els primers dies de la pandèmia de COVID-19, va haver-hi un ràpid aug-

ment en la demanda de serveis en el núvol. En qüestió de mesos, el percentat-
ge d'empleats que treballen de manera remota va saltar del 20 al 71 %. A més,
les empreses van escalar ràpidament la seva despesa en el núvol en el tercer
trimestre de 2020 (juliol-setembre), un augment del 28 % respecte al mateix
trimestre de 2019. El moment és significatiu perquè l'Organització Mundial
de la Salut (OMS) va declarar la COVID-19 una pandèmia el març de 2020. En
el tercer trimestre de 2020, el treball remot va augmentar i les organitzacions
van accelerar plans de migració al núvol, de manera que es va experimentar
un augment massiu any rere any.
Basant-se en un estudi de la Unit42 de Paloalto Networks i utilitzant dades

extretes de la seva gamma global de sensors, els investigadors d'amenaces en
el núvol van trobar una correlació entre l'augment de la despesa en el núvol
a causa de la COVID-19 i els incidents de seguretat.
Organitzacions a escala mundial van augmentar les seves càrregues de treball

en el núvol en més del 20 % (entre desembre de 2019 i juny de 2020), la qual
cosa va implicar una explosió d'incidents de seguretat. La recerca mostra que
els programes de seguretat en el núvol per a organitzacions a escala mundial
encara estan en bolquers quan es tracta d'automatitzar els controls de seguretat
(és a dir, DevSecOps). Tot això ens porta a la conclusió que el ràpid escalat i la
complexitat del núvol sense una seguretat automatitzada són una combinació
amb un risc multiplicador, i és necessari disposar de controls integrats en tot
el procés de desenvolupament.
És important tenir en compte que en recerques anteriors van trobar que el

65 % dels incidents de seguretat divulgats públicament en el núvol van ser el
resultat de configuracions incorrectes del client.
Figura 6. Creixement del núvol i incidents de seguretat

Enllaç recomanat
Es pot consultar l'estudi Unit

42 Cloud Threat Report, 1H
2021. COVID-19’s global im-
pact on security posture aquí.
Bibliografia
Beck, Kent i altres (2001, febrer). Manifesto for Agile Programari Development [en línia].
http://agilemanifesto.org
Cunningham, Ward (1992, 26 de març). «The WyCash Portfolio Management System».
Guijarro Olivares, Jordi; Caparrós, Joan; Cubero, Lorenzo (2019). Devops i Seguretat
Cloud. Barcelona: UOC.
Marick, Brian (2003, 22 d'agost). Agile testing directions: tests and examples [en línia]. http://
www.exampler.com/old-blog/2003/08/22/http://www.exampler.com/old-blog/2003/08/22/
Enllaços recomanats
Additional bookmark (Government of Canada)
CSA - CCSK
DevSecOps: l'evolució de la seguretat del programari
EUCS - Cloud Services Scheme

Introducción A La Seguridad en Cloud

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introducción A La Seguridad en Cloud

Uploaded by

Copyright:

Available Formats

Introducció a la

Jordi Guijarro Olivares

Temps mínim de dedicació recomanat: 2 hores

Jordi Guijarro Olivares

Director d'innovació en cibersegure-

L'encàrrec i la creació d'aquest recurs d'aprenentatge UOC han estat coordinats

Primera edició: febrer 2022

1. Introducció a la seguretat en cloud computing......................... 5

2. Àmbit, responsabilitats i models de seguretat en el núvol..... 9

3. Models de seguretat en el núvol.................................................... 12

4. Un model simple de procés de seguretat en el núvol................ 14

5. Principals riscos, patrons i mitigació proactiva d'amenaces. 15

6. Control de proveïdors. Procediments operatius de seguretat 22

9. Cas d'ús: COVID-19 i cloud computing.......................................... 30

1. Introducció a la seguretat en cloud computing

El model de servei TI basat en cloud i el constant augment de les amenaces in-

El ciberdelicte és desenvolupat per organitzacions internacionals que tenen

A més, cal tenir en compte el pla de continuïtat de negoci, és a dir, si aquest

La gran majoria de proveïdors de cloud asseguren que la seguretat, en última

Figura 1. Models de servei del cloud computing

Els proveïdors� de� plataforma� com� a� servei� (PaaS) s'encarreguen de la se-

En el cas dels proveïdors�infraestructura�com�a�servei�(IaaS) s'encarreguen de

En la capa de plataforma hem d'utilitzar totes les mesures necessàries per a

Els analistes i programadors han d'ocupar-se de la capa d'aplicació; no té gaire

El cloud computing és una revolució en el món de les TIC. Posseeix en el seu

Aquest nou model ofereix a les organitzacions la possibilitat de tenir un focus

seves cadenes productives, i com en tot nou concepte l'aspecte de la seguretat

En aquest apartat dotarem l'estudiant de la visió dels principals riscos:

1.1. Garanties per als clients en cloud computing

nombrosos proveïdors en núvol (PN) es veuen bombardejats amb sol·licituds

Per aquest motiu, hem expressat moltes de les recomanacions de l'informe en

• avaluar el risc d'utilitzar serveis en el núvol;

La llista de comprovació de seguretat abasta tots els aspectes dels requisits en

1.2. Primeres recomanacions legals

La majoria de les qüestions legals associades a la computació en núvol se solen

A diferència dels serveis tradicionals d'internet, es recomana revisar detingu-

2. Àmbit, responsabilitats i models de seguretat en el

Pot sonar simplista, però la seguretat en el núvol i el compliment inclouen tot

Encara que l'abast general de la seguretat i el compliment no canvien, certa-

Això es coneix comunament com el model�de�responsabilitat�compartida.

En un nivell alt, la responsabilitat de seguretat es correlaciona amb el grau de

• Programari�com�a�servei. El proveïdor de serveis en el núvol és respon-

• Plataforma�com�a�servei. El proveïdor de serveis en el núvol és responsa-

• Infraestructura�com�a�servei. Igual que PaaS, el proveïdor és responsable

Figura 2. Models de responsabilitat

Aquestes funcions es compliquen encara més quan s'utilitzen cloud brokers o

Aquesta és l'essència de la relació de seguretat entre un proveïdor de serveis en

Aquest model de responsabilitat compartida es correlaciona directament amb

1) Els proveïdors de serveis en el núvol han de documentar clarament els seus

2) Els usuaris de serveis en el núvol, per a qualsevol projecte donat en aquest,

A tall d'exemple, la Cloud Security Alliance proporciona dues�eines per a aju-

1) El qüestionari�d'iniciativa�d'avaluacions�de�consens�(CAIQ). Una planti- Enllaços recomanats

ment. La CCM també es pot utilitzar per a documentar les responsabilitats de

3. Models de seguretat en el núvol

• Els models o frameworks conceptuals inclouen visualitzacions i descripci-

• Models de control o marcs de treball que categoritzen i detallen controls

• Les arquitectures de referència són plantilles per a implementar la segure-

• Els patrons de disseny són solucions reutilitzables per a problemes parti-

La Cloud Security Alliance (CSA) ha revisat i recomana els models següents:

• CSA arquitectura empresarial.

• CSA matriu de controls en el núvol.

• L'esborrany NIST. L'arquitectura de referència de seguretat de cloud compu-

• ISO/IEC FDIS 27017. Tecnologia de la informació, tècniques de seguretat i