Hosting e cloud per imprese: ubicazione dati, SLA e criteri di scelta

Hosting e cloud per imprese: cosa valutare davvero

Hosting e cloud non sono sinonimi: l'hosting è l'ospitalità di un server o di un'applicazione in una struttura gestita da terzi, mentre il cloud è un modello di erogazione di risorse di calcolo, memoria e storage accessibili da remoto via rete, con costi legati all'utilizzo effettivo. Molte offerte sono ibride: un'impresa può avere applicazioni in cloud pubblico, un server dedicato in housing e un database gestito dal fornitore, tutto nello stesso disegno infrastrutturale.

Microsoft Azure ricorda che il cloud computing è ormai un pilastro delle operazioni aziendali moderne e che, per le organizzazioni di ogni settore, spostare i carichi di lavoro nel cloud può portare a maggiore scalabilità, a un risparmio sui costi dell'infrastruttura IT e all'accesso a tecnologie come intelligenza artificiale e apprendimento automatico. La stessa fonte sottolinea che la scelta del provider richiede di valutare molti fattori, tra cui l'impegno del fornitore a offrire strumenti flessibili e scalabili per innovare in modo sicuro anche in prospettiva futura.

Ubicazione dei dati e territorialità: residenza, sovranità e prossimità

Quando si parla di ubicazione dei dati conviene distinguere residenza e sovranità. La residenza riguarda il luogo, fisico o logico, in cui i dati sono archiviati ed elaborati: un'area geografica, un data center, una regione cloud. La sovranità riguarda invece l'insieme di leggi, autorità e poteri che si applicano a quei dati e che possono incidere su chi vi può accedere e a quali condizioni. Sono piani diversi: un dato residente in Italia può essere sottoposto a obblighi di fornitori esteri, mentre un dato ospitato all'estero può rientrare in un assetto contrattuale che ne limita l'accesso.

Oracle rileva che più di 100 Paesi dispongono di leggi e normative sulla privacy e sulla sicurezza dei dati, il che rende la conformità complessa per le aziende che operano a livello globale. Per un'impresa italiana la posizione dei dati non è solo una scelta di prestazioni, ma un elemento da verificare rispetto agli obblighi di protezione dei dati applicabili.

In Italia il tema della territorialità è tornato di stretta attualità con il GDPR, il regolamento sulla gestione della privacy e dei dati che mira a normare i nuovi paradigmi IT. TechCompany360 osserva che molti provider che hanno investito nella costruzione di nuovi data center hanno insistito sul valore, per le imprese, di avere sul proprio territorio uno spazio cloud sicuro a cui affidare server, dati e informazioni. Nella stessa analisi i data center vengono descritti come il cuore pulsante del business: sale che ospitano server, storage, gruppi di continuità e tutte le apparecchiature che consentono di governare processi, comunicazioni e servizi a supporto delle attività aziendali.

Accanto agli aspetti legali c'è la prossimità fisica, che ha effetti pratici: la distanza tra i sistemi dell'impresa, gli utenti e il data center incide sulla latenza percepita; la collocazione dei backup e delle copie di sicurezza determina quanto rapidamente si può ripartire dopo un incidente; la vicinanza geografica può rendere più semplici interventi, trasferimenti di grandi volumi di dati e verifiche. Prima di firmare è utile farsi indicare per iscritto non solo il Paese, ma anche la regione e, dove possibile, la struttura che ospiterà dati e repliche.

Evolutione della territorialità dei dati nel cloud in Italia

Modelli di servizio: pubblico, privato, ibrido, housing e colocation

Il cloud pubblico è gestito da un provider esterno e mette a disposizione risorse condivise tra più clienti. In questo modello un cloud server è un server virtuale, o un insieme di server, che opera in un ambiente di cloud computing e rende disponibili risorse di calcolo, memoria e storage accessibili da remoto tramite rete. A differenza di un server fisico installato e gestito internamente, è ospitato presso data center di terze parti ed erogato come servizio, con costi commisurati all'utilizzo effettivo: un'impresa può così memorizzare dati e accedere alle proprie applicazioni senza dover conservare tutto su server locali.

Il cloud privato è un'infrastruttura dedicata a una singola organizzazione, ospitata presso il fornitore o presso l'impresa stessa. Il cloud ibrido combina i due approcci: consente di tenere su ambienti dedicati o on-premise i carichi più sensibili o quelli con requisiti di latenza stringenti, e di usare il pubblico per le parti che devono crescere o ridursi rapidamente, come picchi di traffico, ambienti di test o elaborazioni temporanee.

Housing e colocation rappresentano l'altra grande famiglia di opzioni, in cui il cliente mantiene la proprietà del proprio hardware. Nell'housing il server di proprietà dell'impresa viene ospitato in un data center di terzi; nella colocation il fornitore mette a disposizione spazio, alimentazione, raffrescamento e connettività, mentre il cliente installa e gestisce le proprie macchine. TechCompany360 cita espressamente housing e colocation tra le offerte presenti sul mercato italiano, accanto ai data center dei grandi provider nati per erogare servizi pay per use. Queste formule interessano le imprese che hanno hardware già ammortizzato, requisiti di controllo particolare o vincoli che rendono preferibile non cedere la gestione dello stack.

Il criterio pratico per orientarsi è quanta parte dello stack si vuole gestire internamente. Più si sale verso housing e colocation, maggiore è il controllo su configurazione, prestazioni e sicurezza, ma anche l'onere di manutenzione, aggiornamenti e gestione degli incidenti. Più si scende verso il cloud pubblico, minore è il carico operativo, ma si dipende dalle scelte del fornitore su architetture, tempi di aggiornamento e costi di uscita. Il modello di costo segue la stessa logica: il cloud tende a essere pay per use, mentre housing e colocation comportano canoni più stabili e legati allo spazio e all'energia occupati.

Confronto tra modelli di servizio cloud: pubblico, privato, ibrido, housing e colocation

Vantaggi e svantaggi dei principali modelli cloud per le imprese italiane

SLA: definizione, tipologie e clausole essenziali

Un accordo sul livello di servizio, o SLA, è un contratto tra un fornitore di servizi e un cliente che definisce il servizio da fornire e il livello di prestazioni previsto. Come spiega IBM, uno SLA descrive anche come le prestazioni verranno misurate e approvate e cosa succede se i livelli di prestazioni non vengono soddisfatti. È uno strumento tipico dei contratti di outsourcing e dei fornitori di tecnologia dell'informazione, perché fornisce una visione end-to-end del rapporto di lavoro, definisce le aspettative del cliente, responsabilizza il fornitore e aiuta a risolvere in anticipo incertezze e punti di contesa. Non tutti gli SLA sono stipulati con soggetti esterni: le aziende li usano anche internamente, per formalizzare accordi tra dipartimenti o team.

Le tipologie più comuni sono tre. Lo SLA a livello di cliente copre tutti i servizi utilizzati da quel cliente e contiene, secondo AWS, i dettagli specifici dei servizi, le disposizioni sulla disponibilità, la definizione delle responsabilità, le procedure di escalation e i termini per la cancellazione. Lo SLA a livello di servizio descrive un singolo servizio offerto con le stesse condizioni a più clienti: è la forma usata quando il fornitore eroga lo stesso livello di servizio e assistenza indipendentemente dal cliente. Lo SLA multilivello integra in un unico sistema più livelli di condizioni ed è adatto ai fornitori che servono clienti diversi a tariffe o con livelli di servizio differenti. IBM e AWS indicano queste tre tipologie come le principali.

Alcuni elementi non dovrebbero mai mancare. Anzitutto la panoramica del contratto, con le date di inizio e fine e il perimetro del servizio. Poi le metriche: quali parametri vengono misurati, con quale metodo, su quale finestra temporale e da chi. AWS cita tra i parametri tipici i tempi di attività, di consegna, di risposta e di risoluzione. Accanto a questo servono la definizione delle responsabilità delle parti, le procedure di escalation con i canali e i referenti da attivare, e le azioni previste in caso di mancato rispetto degli impegni.

Un punto spesso trascurato è il regime delle esclusioni: manutenzioni programmate, interventi di emergenza sulla sicurezza, eventi fuori dal controllo del fornitore. Vanno letti con attenzione perché possono svuotare di significato una percentuale di disponibilità dichiarata in copertina. Infine, lo SLA standard offerto da un grande provider è un documento pensato per una pluralità di clienti: è il punto di partenza della trattativa, non necessariamente l'assetto definitivo, soprattutto quando i carichi di lavoro hanno carattere critico.

Metriche e penali: disponibilità, latenza, sicurezza e crediti di servizio

Le metriche di uno SLA per hosting e cloud si concentrano su alcune famiglie ricorrenti. La disponibilità è la più nota: viene espressa in percentuale su un periodo, di norma mensile, e indica quanto spesso il servizio è risultato accessibile e operativo. AWS richiama tra i parametri anche i tempi di consegna, di risposta e di risoluzione, cioè quanto tempo passa tra la segnalazione di un problema e le diverse fasi della sua gestione. Accanto a queste vanno considerate la latenza, la capacità di elaborazione garantita, la frequenza e la tempistica dei backup, la finestra di ripristino in caso di incidente.

Per capire come si traducono questi principi in soglie concrete è utile guardare a un modello pubblicato per gli SLA di rete aziendale, che propone disponibilità minima dal 99,9% al 99,95% misurata dal punto di vista dell'autenticazione dell'utente finale e non del semplice ping dell'hardware; latenza di autenticazione inferiore al secondo; crittografia TLS 1.2 o superiore per i dati in transito e AES-256 per i dati a riposo; finestre di patch da 24 a 48 ore per le vulnerabilità di sicurezza critiche; crediti di servizio a livelli, dal 10% al 50% della fattura mensile, collegati a tempi di inattività o violazioni verificate. Sono esempi riferiti a contesti di connettività, ma il criterio metodologico vale anche per hosting e cloud: la disponibilità va misurata dal punto di vista del processo o dell'utente che deve lavorare, non solo dalla presenza di tensione nel rack.

Sul fronte delle penali, il meccanismo più diffuso nel cloud è il credito di servizio: una riduzione proporzionale dell'importo fatturato quando la violazione viene accertata secondo le regole previste dal contratto. AWS cita espressamente, tra le azioni da intraprendere quando i requisiti non sono soddisfatti, il supporto aggiuntivo o gli sconti sui prezzi. È importante verificare come si attiva il credito: se è automatico o va richiesto, entro quali termini, con quali prove, e se esistono soglie minime di interruzione al di sotto delle quali non scatta nulla.

Un'ultima distinzione utile è quella tra SLA e KPI. Un KPI è un indicatore che si monitora per capire l'andamento del servizio; lo SLA è un impegno contrattuale con conseguenze definite in caso di violazione. Un fornitore può esporre una dashboard ricca di KPI senza che questo si traduca automaticamente in obblighi e penali. Prima di firmare conviene quindi chiedere esplicitamente quali indicatori siano coperti da impegno contrattuale e quali siano invece solo informativi.

Criteri di scelta del provider: scalabilità, costi, sicurezza, supporto e ubicazione

La scalabilità è il primo criterio da valutare. Per le organizzazioni spostare i carichi di lavoro nel cloud può portare a una maggiore scalabilità e a un risparmio sui costi dell'infrastruttura IT, ma questo dipende dal fornitore: Azure invita a considerare l'impegno del provider a offrire strumenti flessibili e scalabili per innovare in modo sicuro anche in prospettiva futura. In concreto significa chiedersi quanto rapidamente si possono aggiungere o togliere risorse, se esistono limiti contrattuali alla crescita, se i servizi offerti coprono le tecnologie che l'impresa intende usare nei prossimi anni.

Il secondo criterio è il costo complessivo, non il prezzo di listino. Oltre al canone o al consumo base, vanno considerati il traffico in uscita, lo spazio di backup e la sua replicazione, le licenze, il supporto a livelli superiori e gli interventi professionali. Il modello pay per use tipico del cloud premia la flessibilità ma richiede controllo costante, perché la spesa segue l'utilizzo; housing e colocation offrono maggiore prevedibilità, ma con costi fissi legati allo spazio e all'energia. Un confronto onesto mette a fianco queste voci su un orizzonte di più anni.

Il terzo criterio è la sicurezza: crittografia dei dati in transito e a riposo, gestione degli accessi e dei privilegi, segregazione tra ambienti, log delle attività, procedure di gestione delle vulnerabilità e tempi di applicazione delle patch. A questo si collega la conformità: se il fornitore non è in grado di documentare dove risiedono i dati e quali misure adotta, l'impresa si assume un rischio che non può trasferire.

Il quarto criterio è il supporto: canali disponibili, orari di copertura, lingua, presenza di referenti tecnici identificati, tempi di risposta garantiti e procedure di escalation. Un fornitore economico ma irraggiungibile nei momenti critici ha un costo reale molto più alto di quanto appaia in fattura.

Il quinto criterio è l'ubicazione: dove si trovano i data center che ospitano dati, repliche e backup, e in quali Paesi. TechCompany360 ricorda che la questione della territorialità è diventata centrale per le imprese, e molti provider hanno investito in strutture sul territorio italiano proprio per rispondere a questa esigenza. A chiusura del quadro va valutata la portabilità: formati dei dati, possibilità di esportarli, uso di tecnologie standard, tempi e costi di uscita dal contratto. Un fornitore trasparente su questi punti è generalmente un fornitore più affidabile anche sul resto.

Checklist per l'impresa: domande da fare e punti da verificare prima di firmare

Sui dati e la loro ubicazione: in quali Paesi e in quali strutture risiedono i dati di produzione, le repliche e i backup? Sono previsti trasferimenti verso altre regioni e in quali circostanze? Il fornitore è in grado di documentare per iscritto la localizzazione e le misure di sicurezza adottate? Quali soggetti, anche appartenenti a ordinamenti esteri, possono accedere ai dati e a quali condizioni?

Sul livello di servizio: qual è la disponibilità garantita e su quale finestra temporale viene misurata? Come viene calcolata e chi produce i dati di misurazione? L'impresa ha accesso diretto ai dati e ai log di monitoraggio? Quali eventi sono esclusi dal calcolo della disponibilità?

Su penali ed escalation: quali crediti di servizio sono previsti, in quale misura e a quali condizioni si attivano? Il riconoscimento è automatico o deve essere richiesto, entro quali termini e con quali prove? Quali sono i tempi di risposta e di risoluzione garantiti e come si distinguono per gravità dell'incidente? Chi si contatta, con quali canali, in orario e fuori orario? Esiste una procedura di escalation con referenti nominativi?

Su sicurezza e gestione operativa: quali standard di crittografia sono applicati ai dati in transito e a riposo? Con quale tempistica vengono applicate le patch alle vulnerabilità critiche e come vengono comunicate all'impresa? Come sono gestiti accessi, privilegi e tracciamento delle attività? Come vengono eseguiti e verificati i ripristini da backup, non solo i backup stessi?

Su costi e vincoli contrattuali: qual è il costo complessivo considerando traffico, backup, licenze e supporto? Esistono penali o costi aggiuntivi legati all'aumento dell'utilizzo o al superamento di soglie? Quali sono la durata del contratto, i termini di preavviso e le condizioni di rinnovo? Cosa accade alla fine del rapporto: in quali formati e in quali tempi vengono restituiti i dati, con quali costi di uscita?

Una volta raccolte le risposte, la verifica più utile è la coerenza: se il fornitore garantisce una certa disponibilità ma non indica come la misura, se promette trasparenza sulla localizzazione ma non la mette per iscritto, se le penali esistono solo sulla carta, il rischio contrattuale resta in capo all'impresa. Le domande di questa checklist servono anche a questo: distinguere ciò che è documentato da ciò che è soltanto dichiarato.