Archite(ure  per  la  riservatezza,  integrità  e  disponibilità  dei  da8  nei  sistemi  Cloud  

Relatore:  Prof.  Michele  Colajanni    Correlatore:  Ing.  Mirco  MarcheA  

Candidato:  Adriano  Enrico  Scaruffi  

Università  di  Modena  e  Reggio  Emilia  

Facoltà  di  Ingegneria  “Enzo  Ferrari”  

Anno  Accademico  2010  -­‐  2011  

Corso  di  Laurea  SpecialisEca  in  Ingegneria  informaEca  

Cloud  CompuEng:  tecnologia  dirompente  

•  La  crescente  diffusione  del  modello  dovuta  ai  vantaggi  offerE:  –  Tariffazione  al  consumo  –  CosE  iniziali  pressoché  nulli  –  Scalabilità  quasi  immediata  –  InfrastruMure  di  alto  livello  a  

basso  costo,  prima  non  accessibili  alle  piccole  organizzazioni  

•  CompuEng  come  uElity:  

–  fornitura  di  risorse  computazionali,  tariffata  al  consumo  e  usufruibile  mediante  la  rete  internet,  in  analogia  ad  altre  uElity  

 

ObieQvo  della  tesi  Affrontare  le  principali  problema8che  che  limitano  la  diffusione  del  Cloud  Compu8ng  sopra(u(o  nell’esternalizzazione  dei  da8  aziendali:    •  Riservatezza    

–  DaE  da  affidare  ad  un  unico  fornitore  –  In  chiaro,  non  cifraE  

•  Disponibilità  –  Interruzioni  del  servizio  

•  Integrità  dei  da8    –  Corruzione  e  perdita  

•  Vendor  Lock-­‐In:  difficoltà  nel  cambiare  fornitore  •  AspeA  legali:  gesEone  e  localizzazione  geografica  

ProgeMo  

•  Riservatezza:    –  Cifratura  •  DaE:  Disk  EncrypEon  •  Traffico:  VPN  

–  Suddivisione  (stripe)  •  FS  distribuito  

•  Disponibilità:    –  Replica  distribuita  •  FS  distribuito  

•  Integrità:  –  Replica  •  FS  distribuito:  

–  Hashing  –  Individuazione  e  

correzione  errori  con  copie  integre  

DBMS File  SystemApplicationPhysical  Data

Trusted

Clear  Data

in-­‐house

STRIPE REPLICA

Disk  Encryption

VPN

Encrypted  Data

Untrusted

Internet

•  Modello  DaaS:  prevede  outsourcing  della  memorizzazione  dei  daE  •  InfrastruMure  avverEte  come  sicure  se  di  proprietà  

DBMS File  SystemApplicationPhysical  Data

Trusted Untrusted

IDS/IPS  

Cloud  Provider  1-­‐1 Cloud  Provider  1-­‐N

Cloud  Provider  M-­‐1 Cloud  Provider  M-­‐N

VPN

VPN  1-­‐1 VPN  1-­‐N

VPN  M-­‐1 VPN  M-­‐N

REPLICA

STRIPE

ArchiteMura  •  Cifratura  dei  daE  sulle  infrastruMure  client  a  livello  

di  file  system  •  UElizzo  di  molteplici  Cloud  provider  •  Realizzazione  di  una  VPN  cifrata  per  ogni  sistema  

–  Gateway  VPN  locale  come  centro-­‐stella  

•  Suddivisione  dei  daE  tra  M  provider  (striping)  •  Replica  su  N  sistemi  

Realizzazione  •  ProtoEpo  per  verificare  la  faQbilità  del  progeMo:  –  2  Cloud  Provider:  per  striping  –  1  PC  con  CentOS  Linux:  lato  utente  –  GlusterFS:  striping,  replica,  integrità    –  dm-­‐crypt:  cifratura  dei  daE  –  OpenVPN  –  PostgreSQL  +  pgbench  

dm-­‐cryptGlusterFSOpenVPN

Netfilter

Cloud  Provider  1Amazon  AWS    EC2

Cloud  Provider  2Rackspace  Cloud  Server

VPN

Public  IP:  xxx.xxx.xxx.xxxVPN  Private  IP:10.8.0.1/24

Default  Gateway    

Public  IP:  yyy.yyy.yyy.yyyVPN  Private  IP:  10.8.0.4/30

Public  IP:  zzz.zzz.zzz.zzzVPN  Private  IPs:  10.8.0.8/30

PostgreSQLpgbench

Single  PC  equipped  with  CentOS  6.2  x86_64

Problemi  di  latenza  •  Prime  realizzazioni  su  datacenter  statunitensi    

à  ampi  tempi  di  latenza  ed  elevaE  tempi  di  risposta  

•  SOLUZIONE:  Trasferimento  delle  risorse  da  datacenter  americani  a  europei    •  Migliori  tempi  di  latenza  e  risposta  

•  Dimostrata  vendor  independence  

USA   EU  

Latenza   120ms   20ms  

Banda   3MB/s   5MB/s  

Scalabilità  e  stress  tesEng  •  UElizzo  di  mulEple  istanze  su  un  Cloud  provider:  GoGrid  

–  Uniformità  delle  prestazioni,  banda,  latenza  •  CriMografia    

–  Disk  encrypEon  su  disposiEvo  a  blocchi  virtuale  •  VPN  con  gateway  centro-­‐stella  

–  Due  subnet  VPN  •  Striping  con  FS  distribuito  

VPN  poin-­‐to-­‐point  1

dm-­‐cryptGlusterFSOpenVPN

Netfilter

Cloud  Provider:GoGrid  Cloud  Server

VPN

PostgreSQLpgbench

Single  PC  equipped  with  CentOS  6.2  x86_64

VPN  poin-­‐to-­‐point  2

GGEServer1

GGEServer2

Public  IP:  xxx.xxx.xxx.xxxVPN  Private  IP:10.8.0.1/24

Default  Gateway    

VPN  point-­‐to-­‐point  1  

VPN  point-­‐to-­‐point  2  

Test  comparaEvi:  locale  vs  Cloud  

pgbench

Client

PostgreSQL

Dm-­‐crypt

GlusterFS  Client

OpenVPN  Server

Internet

GlusterFS  Server

OpenVPN  Client

Netfilter

GlusterFS  Server

OpenVPN  Client

Netfilter

GGEServer1 GGEServer2

Netfilter

•  Test  comparaEvi  tra:  –  macchina  locale,  latenza  media  

4ms,  banda  80MB/s  –  sistema  remoto  su  Cloud,  latenza  

media  20ms,  banda  5MB/s  

•  Benchmark  eseguiE  con  pgbench  –  Test  effeMuabili  (tps):  •  TPC-­‐B:  ogni  transazione  prevede  5  

operazioni  SELECT-­‐INSERT-­‐UPDATE  –  SvolE  aumentando  il  numero  di  

client  concorrenE  •  Ricerca  del  punto  di  saturazione  

delle  risorse  

•  UElizzato  un  database:  –  Dimensione:  15GB  –  Contenuto  in  un  file  immagine  

cifrato  di  20GB  nel  caso  di  uElizzo  del  modulo  criMografico  dm-­‐crypt  

Locale   Cloud  

Latenza   4ms   20ms  

Banda   80MB/s   5MB/s  

RisultaE  Sperimentali  •  Banda  e  latenza  sono  il  collo  di  boQglia  

•  La  latenza  è  il  principale  faMore  limitante,  è  5  volte  superiore  al  caso  locale,  che  oQene  prestazioni  di  picco  tra  le  5  e  le  10  volte  superiori  al  caso  Cloud  

•  Nonostante  la  banda  sia  16  volte  inferiore,  risulta  poco  influente,  più  rilevante  al  crescere  del  numero  di  nodi  

•  L’uElizzo  della  VPN  influisce  marginalmente  sulla  latenza,  ma  richiede  maggiori  risorse  estendendo  l’architeMura  

•  Comportamento  similare  tra  le  due  soluzioni,  tranne  che  nel  caso  di  uso  della  cifratura  con  sistema  Cloud  (a  causa  del  mancato  caching)  

0  

10  

20  

30  

Chiaro   Cifrato  Tran

sazion

i  per  se

cond

o  

Locale   Cloud  �����������

�� ���

� �� ��� ����

�

�

��

��

��

��

��

������� ����� ����� ������� ��������� �����

������ ����� ����� ������ ��������� �����

����� � ��������� ��!����

���

���

!��

��� �

����

� "�

��#

Locale  

Cloud  

Conclusioni  •  Conclusioni  

ü  L’architeMura  progeMata  è  in  grado  di  fornire  migliori  garanzie  di  riservatezza,  disponibilità  e  integrità  dei  daE  su  sistemi  Cloud,  consentendo  così  una  maggior  confidenza  nel  loro  uElizzo  

ü  Si  riducono  le  problemaEche  di  vendor  lock-­‐in,  rendendo  possibile  migrare  i  daE  

ü  La  soluzione  proposta  è  trasparente  per  l’utente,  compaEbile  con  numerose  applicazioni,  poiché  opera  a  livello  di  file  system  

 

•  Ulteriori  approfondimenE  e  sperimentazioni:  

Ø  Esecuzione  di  test  su  datacenter  con  minor  latenza  

Ø  Test  con  DBMS  differenE,  anche  con  funzionalità  di  TDE  per  evitare  l’impiego  del  modulo  di  cifratura  che  invalida  l’uso  della  cache  locale