Activa System - Network, Web & Software applications

Separazione Web server e Database server

Activa System — Tue, 02 Mar 2010 23:00:00 +0100

Tratto da http://escher07.altervista.org

Generalità
In questo documento si ipotizza di dover mettere su web un applicativo con tecnologia
adeguata (ASP/IIS, PHP/Apache etc…). Si vogliono discutere pregi e difetti delle varie
possibili soluzioni.

Soluzione Scenario Difetti Prerequisiti Scenario di utilizzo

Unico Server

E’ la soluzione più semplice ed è quella normalmente adottata in contesti intranet. Esiste
un solo server dove risiedono l’applicativo ed il DB, entrambi in INSIDE. I due livelli
possono essere separati ma solo per motivi prestazionali, ovvero possono essere usati un
Application Server ed un DB Server ma entrambi sulla LAN. E’ ovvio che essendo per
ipotesi la INSIDE un’area con politiche omogenee per entrambi le protezioni sono solo
quelle locali (sistema operativo e applicativi).
I dati viaggiano in chiaro quindi non c’è alcuna protezione nei confronti di possibili sniffing
o tentativi di accesso/Dos dalla INSIDE. Del resto si suppone che per politiche aziendali
e/o sorveglianze interne e/o scarse capacità tecniche degli utenti etc… questi eventi siano
estremamente improbabili.

Separazione DB/Application

Ipotizziamo che la stessa applicazione di cui in precedenza debba ora essere resa
disponibile su internet. Rispetto al caso precedente ci sono alcune differenze di fondo,
ovvero:
• presenza di un firewall
• i servizi esterni devono essere posizionati in una opportuna area (detta DMZ)
ed essere accessibili tramite uno o più IP pubblici (fisici o tipicamente NAT
operati dal firewall stesso)
Dunque ciò che deve essere pubblico deve andare in un’area “demilitarizzata”. La prima
idea è quella di sostituire l’unico server precedente con due (o più) server uno più esposto
ed uno meno. Cosicché se crolla il primo almeno i danni sono limitati alla sola DMZ e non
comportano perdita dei dati almeno finchè non crolla anche il secondo. In pratica lo
scenario è questo:
In sostanza il server web esterno raccoglie una richiesta http destinata ad un server dati
(tipicamente in INSIDE, dove interno=senza indirizzo pubblico) soddisfacendola e
restituendo al PC remoto l’HTML giusto. E’ da evidenziare che il server esterno naviga
dentro la LAN al posto del PC remoto, quindi la differenza rispetto ad un normale link è
che i diritti a livello di firewall saranno solo su di lui e non sul PC, cosa (impensabile) che
comporterebbe l’apertura del server interno a tutti.
Ci sono vari possibili modi con cui il server esterno dialoga con l’interno.Il più semplice è
quello di interrogare direttamente il servizio interno interessato : ad esempio se
quest’ultimo è un DB Oracle opererà una richiesta sulla porta 1521. Ci sono poi metodi
alternativi per cui la richiesta generica è impacchettata in una di tipo http (Web
Service/Reverse Proxy). In tutti i casi il firewall deve avere una regola di questo tipo:
Permit Web server -> Server Dati Port=P0
…dove P0 è rispettivamente 1521 o 80 nei nostri esempi.
In una situazione di questo tipo la sicurezza viene demandata essenzialmente
• Alla stabilità del Web Server Esterno
• Al servizio che raccoglie le richieste sul server dati (Oracle Listener o Servizio
WWW)

Un eventuale crash del primo apre le porte della DMZ. Un eventuale crash del secondo
apre le porte della LAN, dato che evidentemente conquistare un server di una certa area
corrisponde (a meno delle sicurezze locali, ovvero firewall applicativi e password) ad avere
a disposizione tutta quell’area.
In questo caso la sicurezza dell’applicazione è certo importante ma il quanto questa debba
essere sicura dipende soprattutto dai dati. In altre parole gli eventi più pericolosi possono
essere questi:
1. l’intruso esegue sniffing sui dati trasmessi su internet
2. l’intruso manda in crash l’applicativo
3. l’intruso riesce ad eseguire del codice sul web server e invia comandi dannosi per il
server interno
questi eventi sono in ordine crescente di difficoltà e di pericolosità. In altre parole se
l’applicazione invia dati “delicati” deve sempre implementare tecniche tipo SSL (per
proteggersi dal primo evento) : detto questo gli altri due eventi riguardano tutti i possibili
siti web anche se qui c’è da valutare bene il rapporto costo/beneficio di spendere risorse in
un adeguato tuning/hardening del sistema.
Reverse Proxy
E’ in pratica una caso particolare del precedente nel senso che la richiesta DMZ-INSIDE
non è generica ma di tipo http ed è rivolta quindi ad un application server in INSIDE, che
normalmente accorpa anche le funzioni di DB (ovvero non lo fa ma solo per motivi
prestazionali, tanto una volta su quello in LAN già ci saremmo). Quindi introduce un livello
aggiuntivo di sicurezza nel senso che per far crollare questa architettura occorre
“sfondare” il Web Server, poi l’application tramite codice inviato sulla porta 80, poi il DB,
eventualmente su una terza macchina.
Da notare che in ambiente Unix il servizio Apache può fare anche funzioni di reverse proxy
mentre in ambiente Windows non vale lo stesso per IIS : in tal caso occorre utilizzare ISA,
ovvero il proxy di Microsoft.
Il reverse proxy ha anche un altro vantaggio rispetto alla generica architettura a “due
livelli” di cui in precedenza : non è indispensabile avere un indirizzo IP per ogni servizio
esposto ma, al limite un solo indirizzo pubblico e un Web Server che supporta il virtual
hosting (sia Apache che IIS lo fanno).
Il principale problema di questa soluzione è la presenza di un singolo point of failure. Un
attacco DoS al Web Server provoca una interruzione di servizio di tutti i servizi per cui
questo fa reverse proxy.
Inoltre il reverse proxy non protegge in alcun modo dallo sniffing di dati, dato che non
opera alcuna crittografia che deve essere implementata dall’application server. Se questo
non lo fornisce ed i dati sono “sensibili” non va usato.
Virtual Private Network
Questa soluzione serve tipicamente per espandere l’utilizzo di un applicativo intranet (o
addirittura client/server) ad una serie di sedi remote della stessa organizzazione.
In pratica la sede remota tramite adeguato client (esempio Cisco VPN Client) instaura un
dialogo con la logica PKI con un adeguato apparato hardware della rete interna (detto
VPN Concetrator) , tipicamente il firewall.
Questi eseguita l’autenticazione tramite proprie access list o più spesso tramite il dialogo
con un server dedicato detto AAA (Authentication Authorization Accounting server) crea un
canale criptato in cui viaggiano i dati.
Fisicamente tramite internet ma virtualmente in modo punto-punto fra PC remoto e
application server (se come di norma la VPN è configurata per poter accedere solo a quella
macchina e a quel servizio ossia porta).
Questo tipo di architettura replica in sintesi lo scenario intranet fra sedi connesse tramite
internet, per cui l’application server (+db o meno a seconda delle prestazioni) è di norma
in INSIDE, ovvero in una DMZ dove si trovano tutti i server per la intranet se di è decisa
questa architettura.
Le principali criticità di questa soluzione sono :
• il numero comunque limitato di sedi collegabili, necessariamente note a priori;
• la necessità di apparati dedicati (VPN Concetrator, AAA server)
• il traffico che si genera e l’impegno per gli apparati che eseguano la decrittazione;
Il vantaggio principale è che diventa abbastanza irrilevante la sicurezza intrinseca
dell’applicazione : anzi si può dire che questa soluzione ha senso solo se il dialogo
client/server avviene in chiaro (come avviene per tutte le applicazioni originariamente
pensate per contesti LAN), altrimenti si sovrappone inutilmente crittografia (VPN) a
crittografia (SSL) oltre a portarsi dietro tutti i vincoli di cui sopra.
Duplicazione DB e Application
Questa è la soluzione normalmente attuata in presenza di molti client che accedono da
internet e di dati delicati, come ad esempio succede nei progetti e-commerce.
La duplicazione del DB porta evidentemente dei costi di licenze significativi (nel caso di
software non Open Source) ma permette di essere sempre abbastanza tranquilli sul fatto
che i dati più delicati non siano compromessi.

In pratica in DMZ si trova un application server che normalmente implementa tecniche tipo
SSL ed un DB server che contiene i suoi dati, che costituiscono solo una piccola parte
dell’archivio (ad esempio gli ordini raccolti in giornata). Application e DB possono trovarsi
anche sulla stessa macchina e/o sono separati più per motivi prestazionali che per altro.
Questo application consente in genere funzionalità estremamente limitate quali ad
esempio l’inserimento dell’ordine ma non la sua modifica e/o cancellazione sia per motivi
funzionali (in nessun markeplace il cliente può cambiare idea su ciò che vuole quando
vuole) ma anche per motivi tecnici (il DB in DMZ contiene proprio per ragioni si sicurezza
solo le minime informazioni possibili).

In INSIDE si trova invece un secondo application e un secondo DB, eventualmente anche
qui sulla stessa macchina. Il dialogo fra questi due servizi avviene con le politiche tipiche
della LAN e quindi di norma con piene funzionalità del client (es. inserimento, modifica,
cancellazione) e con dati che viaggiano in chiaro.
In tempi prestabiliti i due DB dialogano fra loro : in genere è quello interno che attraverso
una impostazione di questo tipo:
Permit Application Interno -> Application Esterno Port=80
… ovvero (se si utilizzano stored procedures o simili) di questo tipo:
Permit DB Interno -> DB Esterno Port=P0
… preleva i dati da quello esterno, portandoli sulle proprie tabelle e facendoli entrare nel
“giro” (es. contabilità) ordinario.

Microsoft: VMs in Azure gi� a Marzo? Cloud computing in competizione con Amazon

Activa System — Sat, 27 Feb 2010 23:00:00 +0100

Microsoft Azure è una delle più grandi novità del 2010 di Microsoft, segna di fatto l'ingresso definitivo della compagnia nel mondo del cloud computing e pone importanti sfide sul cammino della software house, il primo su tutti inerente il modello di business che ha permesso a Microsoft di arrivare a oggi. Azure è già disponibile ma non permette ancora di avere le funzionalità di una piattaforma PaaS. Questo significa che ad oggi non è possibile attivare una vps "nuda" come avviene ad esempio in Amazon EC2, che è una piattaforma IaaS.

Microsoft potrebbe introdurre questa possibilità già dal prossimo Marzo. Si tratterà ovviamente di VMs con Windows installabile, sulle quali quindi i clienti potranno portare il software che già utilizzano all'interno del proprio data center, avendo però a disposizione una fonte di risorse più vasta e probabilmente contratti Microsoft dedicati per l'assistenza.

L'ingresso di Microsoft potrebbe porre in difficoltà la più famosa piattaforma IaaS di oggi: Amazon EC2 è ancora tra le più utilizzate e tra le meno costose, per questo motivo potrebbe risentire di una politica aggressiva di Microsoft, soprattutto per i clienti che già oggi acquistano software e servizi prodotti da Redmond.

Software as a service (SaaS): aspetti giuridici e negoziali

Activa System — Thu, 21 Jan 2010 23:00:00 +0100

Il software è l'elemento che, più di ogni altro, ha contribuito alla diffusione della scienza informatica, grazie alle sue caratteristiche di strumento idoneo a supportare l'automazione di processi ed attività in funzione del business aziendale.

L'utilizzo del software attraverso le cd. licenze d'uso si è però sempre contraddistinto per la presenza di problematiche connesse, in particolar modo, con gli oneri della gestione in proprio (capacity planning, installazione, manutenzione, update, sicurezza) e dei costi (licenze, hardware, personale).

L'evoluzione informatica, segnata dall'avvento di Internet e dalla diffusione dei web browser, ha portato alla fine degli anni 90, nel pieno della cd. bolla tecnologica, allo sviluppo del modello degli ASP, acronimo di Application Service Provider, in base al quale si sosteneva che qualsiasi software potesse essere in realtà trasformato in un servizio, così da permetterne la fruizione da remoto evitando, nel contempo, tutti gli inconvenienti connessi alla sua gestione tradizionale.

Sono ormai passati diversi anni dalla fine di quel periodo ma un nuovo modello si sta diffondendo grazie anche all'accesso in banda larga, ad una infrastruttura Internet più matura e robusta ed all'affermarsi di modelli di distribuzione dello storage e delle capacità elaborative derivanti dalla necessità di supportare le sempre più diffuse tecnologie mobili.

Parliamo di SaaS, acronimo di Software as a Service, una delle tipologie di servizio alla base del paradigma del cloud computing, che rappresenta una tendenza evolutiva dell' outsourcing, termine con il quale si intende la pratica di affidare all'esterno la gestione delle funzioni non facenti parte del core business aziendale.

La principale novità è rappresentata da un nuovo modello di delivery dei servizi IT che focalizza l'attenzione su ciò che le tecnologie consentono di realizzare, piuttosto che sulle tecnologie in sè, con il risultato che il software non è più un asset gestito in proprio dall'utilizzatore ma è quest'ultimo che sceglie i servizi di cui usufruire, in base alle proprie reali necessità, contribuendo alla diffusione di un modello economico orientato al consumo IT.

Si tratta quindi di servizi che permettono di soddisfare con grande flessibilità alcune esigenze tipiche delle infrastrutture informatizzate quali:

* supporto dei più comuni processi aziendali (gestione di magazzino, CRM, gestione del personale, ecc...)

* applicazioni verticali per garantire soluzioni ad hoc in settori od attività molto specifici

* applicazione connesse con la gestione dei dati e delle informazioni (data mining, business intelligence, backup remoto, ecc...)

* spazi virtuali per il team collaborativo (gestione condivisa di progetti, memorizzazione e scambio di documentazione, pianificazione, messaggistica instantanea, ecc...)

* servizi più comuni (webmail, calendario, ecc...)

Caratteristiche ed aspetti legali

Il modello Saas prevede la fornitura di applicativi software, ospitati all'interno della infrastruttura dello stesso fornitore, ai quali il cliente accede mediante Internet. I vantaggi per il fruitore sono per lo più rappresentati da:

* riduzione dei costi di licenza e di gestione connessi con l'infrastruttura IT

* semplificazione od eliminazione degli oneri di gestione

* trasferimento, in parte, del rischio di esercizio sul fornitore

* scalabilità che permette di realizzare soluzioni di capacity on demand

* completo supporto per le esigenze di mobilità aziendale

A ben vedere, alcuni dei benefici citati rendono questo modello appetibile soprattutto per le startup e le piccole e medie imprese, tradizionalmente alle prese con problemi di budget e con la mancanza, al loro interno, di professionalità specifiche nel campo IT.

Tuttavia non mancano implicazioni di natura differente, anche legali, innanzitutto sotto il profilo dell'inquadramento giuridico della fattispecie.

Da questo punto di vista, come già ricordato, il SaaS rappresenta una evoluzione dell'outsourcing che nel nostro ordinamento giuridico è un contratto atipico.

La prevalenza di una prestazione di fare, avente ad oggetto la fornitura di uno o più servizi software o di altra natura, unitamente alla presenza di una organizzazione dotata di mezzi e gestione propri ed al pagamento di un corrispettivo sono tutti elementi che fanno propendere per la configurabilità di un appalto di servizi, sia pure avente ad oggetto prestazioni continuative o periodiche.

La prima diretta conseguenza di tale inquadramento è che l'obbligazione dell'appaltatore costituisce una obbligazione di risultato, anche se nella pratica non mancano casi di soggetti interessati a far figurare nel contratto i propri obblighi come di mezzi.

D'altra parte l'utilizzo delle capacità elaborative e di memorizzazione del fornitore, da questo direttamente controllate, con la finalità di supportare le varie attività ed i processi di business di una organizzazione pone altre questioni concernenti:

* il rispetto di comprovati standard di sicurezza informatica

* l'adempimento di obblighi di conformità di natura normativa (es. quelli posti dal d.lgs. 196/03 in materia di protezione dei dati personali) o contrattuale

* la necessità di fare affidamento su livelli di servizio misurabili in base a parametri tecnici oggettivi

* la protezione della proprietà intellettuale ed industriale

Si tratta ovviamente di aspetti di non facile soluzione che finiscono per incidere in modo significativo sulla posizione dell'uno o dell'altro contraente, anche dal punto di vista di una eventuale responsabilità, soprattutto nel caso in cui emerga un difetto di due diligence.

E' necessario quindi che tali questioni siano prontamente affrontate e risolte, in un ottica di bilanciamento dei contrapposti interessi, nell'ambito di una trattativa diretta alla predisposizione di un regolamento contrattuale il cui oggetto deve essere ben chiaro e dettagliato.

E' inoltre opportuno che il contratto sia accompagnato da allegati contenenti la descrizione degli aspetti tecnici e la determinazione dei parametri dei livelli di servizio (SLA) connessi all'esecuzione delle varie prestazioni.

Sicurezza informatica

Nel mondo odierno le informazioni rappresentano per le organizzazioni, di ogni genere e dimensione, uno dei principali asset da preservare per il raggiungimento dei propri obiettivi.

Ciò vale, a maggior ragione, quando una quota, più o meno consistente, di tali informazioni diventa oggetto dei processi di elaborazione e memorizzazione di una infrastruttura informatica gestita da una parte estranea, come appunto nel caso di specie.

Il richiamo all'importanza delle informazioni in gioco serve perciò a sottolineare la necessità che il fornitore, in primis, offra specifiche garanzie e dettagli sull'adozione dei migliori standard e delle misure di sicurezza, tecniche ed organizzative, ritenute idonee, sulla base di una analisi del rischio, a proteggere le informazioni da tutte le minacce, interne od esterne, che siano tali da comprometterne la riservatezza, la disponibilità e l'integrità.

In questa prospettiva può essere utile accertare nella fase negoziale, e successivamente dare conto nel contratto, di alcune condizioni o status dell'outsourcer relativi a:

* il possesso di certificazioni attinenti l'ambito dei servizi offerti (ad es. SAS70, ISO27001,...)

* l'impiego di personale altamente qualificato e certificato

* l'adeguatezza dimensionale e qualitativa delle infrastrutture informatiche e di comunicazione

Una valutazione a parte deve essere invece riservata alla questione della responsabilità nel caso di eventuali violazioni od incidenti di sicurezza.

Mentre la disponibilità dell'outsourcer ad assumere contrattualmente il rischio di tali violazioni deve essere valutata come un segnale di apertura che la dice lunga sulla sua affidabilità complessiva, purtroppo nella prassi contrattuale si ravvisa una tendenza di segno completamente opposto che si manifesta attraverso clausole, dal contenuto spesso poco chiaro, cui è bene prestare la massima attenzione, tenendo comunque presente che il codice civile (art. 1229) sancisce la nullità di qualsiasi patto diretto ad escludere o limitare preventivamente la responsabilità di una delle parti per dolo o colpa grave.

Protezione dei dati personali

Una species della sicurezza informatica è quella riguardante i cd. dati personali, da considerare anch'essi alla stregua di un asset ed oggetto di stringenti obblighi di protezione imposti dal codice della privacy (D.Lgs. 196/03).

Tra questi obblighi, la cui violazione è fonte di responsabilità civili, penali ed amministrative, vanno annoverati quelli relativi all'adozione delle misure di sicurezza minime (art. 33 ed All. B) e di tutte le altre, idonee e preventive, che, sulla base delle conoscenze acquisite mediante il progresso tecnico e dell'importanza dei dati trattati, possano ridurre al minimo i rischi di distruzione, perdita, accesso non autorizzato o trattamento non consentito o non conforme alle finalità della raccolta (art. 31).

Si tratta, come noto, di obblighi che permangono in capo al titolare, anche quando egli decida di avvalersi di soggetti esterni alla sua organizzazione per l'esecuzione di attività o la fornitura di servizi strumentali al trattamento dei dati.

In questi casi l'appaltatore che, per poter eseguire la propria prestazione, si trova nella condizione di partecipare al trattamento dei dati, di cui è titolare il committente, dovrebbe perciò fornire idonee garanzie al riguardo ed essere designato quale responsabile esterno del trattamento.

Ciò comporta, di fatto, la necessità di includere nel contratto, generalmente sotto forma di allegato:

* la designazione e l'accettazione dell'incarico da parte del responsabile del trattamento

* le istruzioni alle quali il responsabile deve attenersi

* l'indicazione delle specifiche tecniche e delle misure di sicurezza da applicare in relazioni ai rischi

* i poteri di vigilanza e controllo da parte del titolare e le modalità con le quali essi potranno essere esercitati

* la ripartizione del carico di responsabilità tra le parti

Infine, ma non certo per importanza, c'è la doverosa verifica che l'outsourcing non comporti un trasferimento di dati personali in un paese posto al di fuori dei confini della comunità Europea a causa dei limiti imposti dalla normativa vigente.

A questo proposito occorre riflettere sul fatto che tale rischio può anche essere connesso all'utilizzo da parte dell'outsourcer di strutture di storage e trasmissione ridondanti, situate in posti geograficamente distanti, per far fronte alle inevitabili esigenze di disaster recovery.

I livelli di servizio

La natura dei servizi da erogare e la necessità di soddisfare particolari esigenze, specie del committente, impongono, in alcuni casi, il rispetto di particolari modalità di esecuzione della prestazione che vengono concordate tra le parti ed il cui contenuto è definito attraverso parametri tecnici, qualitativi e quantitativi, oggettivi e misurabili. Tra questi parametri i più critici sono in genere rappresentati dai seguenti:

* uptime, cioè la garanzia della disponibilità dei servizi secondo una determinata percentuale (es. 99%) riferita ad unità di tempo (settimana, mese, anno, ecc...)

* tempi di risposta, cioè la velocità con la quale devono essere eseguite particolari funzioni elaborative. Si tratta di una variabile differente dal tempo di risposta che gli utenti sperimentano durante l'accesso da remoto alle applicazioni software

* varie metriche di servizio che esprimono misurazioni diverse come il periodo di operatività del servizio tecnico, il tempo di presa in carico o di correzione degli eventuali errori o malfunzionamenti, ecc...

L'atto con il quale le parti esprimono il loro accordo viene normalmente definito Service Level Agreement (SLA), può assumere la forma di allegato al contratto principale e prevedere, a fronte del mancato rispetto dei livelli concordati di servizio, il pagamento di penali oppure, nei casi più gravi, una clausola risolutiva espressa ai sensi dell'art. 1456 c.c.

Le clausole di un SLA, quando previste, possono incidere in modo significativo sulla portata delle obbligazioni contrattuali e, perciò, su di esse deve concentrarsi buona parte dell'attenzione dei contraenti.

Proprietà intellettuale ed industriale

A volte le informazioni gestite mediante il software possono avere natura riservata per cui il committente può essere portatore di un legittimo interesse ad includere nel regolamento contrattuale delle apposite clausole di riservatezza, salvagardia o rivendicazione dei diritti di proprietà intellettuale od industriale propri o di terzi.

Questo non toglie che un esigenza analoga possa essere manifestata anche dall'appaltatore con riferimento ad ipotesi specifiche (es. personalizzazioni del software eseguite su richiesta ed a vantaggio del committente).

Ulteriori aspetti negoziali

Rimangono, infine, alcuni punti che, a causa delle complessità sottese alla loro regolamentazione o delle conseguenze particolarmente gravose che ne possono derivare, richiedono un attenta considerazione durante la fase delle trattative ed in sede di stipula:

* durata del contratto ed eventuali penali in caso di recesso anticipato

* parametri assunti come riferimento per il calcolo dei corrispettivi del servizio

* eventuali personalizzazioni del software con indicazione delle specifiche tecniche di sviluppo, della procedura per l'accettazione delle modifiche, della titolarità dei diritti sul codice custom sviluppato

* procedure e modalità per la restituzione, all'atto della cessazione del rapporto, dei dati di titolarità del committente

* responsabilità del committente per i casi in cui le informazioni dallo stesso gestite attraverso i sistemi dell'appaltatore integrino violazioni di norme di legge (proprietà intellettuale, privacy, diffamazione, ecc...)

* procedure di backup e disaster recovery

* accordi per l'accrescimento on demand della capacità elaborativa o di storage su richiesta del committente

* criteri per dirimere le eventuali controversie che sorgono in relazione al contratto (giuridsdizione competente, clausola arbitrale, ecc...)

In conclusione il SaaS rappresenta un modello di distribuzione di servizi innovativo, dotato di caratteristiche che lo rendono idoneo a supportare la domanda IT sulla base di criteri di flessibilità e dinamicità delle metriche di servizio e dei prezzi.

Nel contempo, però, le implicazioni legali e la complessità delle questioni che ne derivano, soprattutto in un ottica di bilanciamento di interessi contrapposti, richiedono un attenta valutazione di tutti gli aspetti insiti nel regolamento negoziale.

Articolo pubblicato in data 18/12/2008 su Altalex

Cloud computing

Activa System — Thu, 21 Jan 2010 23:00:00 +0100

In informatica, con il termine cloud computing si intende un insieme di tecnologie informatiche che permettono l'utilizzo di risorse hardware (storage, CPU) o software distribuite in remoto. Nonostante il termine sia piuttosto vago e sembri essere utilizzato in diversi contesti con significati differenti tra loro, si possono distinguere tre tipologie fondamentali di Cloud Computing:

* SaaS (Software as a Service) - Consiste nell'utilizzo di programmi in remoto, spesso attraverso un server web. Questo acronimo condivide in parte la filosofia di un termine oggi in disuso, ASP (Application service provider).

* PaaS (Platform as a Service) - È simile al SaaS, ma non viene utilizzato in remoto un singolo programma, ma una piattaforma software che può essere costituita da diversi servizi, programmi, librerie, etc.

* IaaS (Infrastructure as a Service) - Utilizzo di risorse hardware in remoto. Questo tipo di Cloud è quasi un sinonimo di Grid Computing, ma con una caratteristica imprescindibile: le risorse vengono utilizzate su richiesta al momento in cui un cliente ne ha bisogno, non vengono assegnate a prescindere dal loro utilizzo effettivo.

Una caratteristica del Cloud Computing è di rendere disponibili all'utilizzatore tali risorse come se fossero implementate da sistemi (server o periferiche personali) "standard". L'implementazione effettiva delle risorse non è definita in modo dettagliato; anzi l'idea è proprio che l'implementazione sia un insieme eterogeneo e distribuito – the cloud, in inglese nuvola – di risorse le cui caratteristiche non sono note all'utilizzatore.

Il termine cloud computing si differenzia da grid computing che è un paradigma orientato al calcolo distribuito, e in generale, richiede che le applicazioni siano progettate in modo specifico.

Continua su Wikipedia

Monweb Crea il tuo sito web in 5 minuti

Michele Siano — Sun, 10 Jan 2010 23:00:00 +0100

Monweb è la prima piattaforma professionale per la gestione dei contenuti, chiamata in linguaggio tecnico CMS (Content Management System), resa intuitiva e flessibile per venire incontro alle esigenze di tutti coloro che vogliono un sito internet subito ma professionale, facile da aggiornare e a basso costo.

Con Monweb crei e gestisci il tuo sito direttamente on-line ottenendo risultati eccezionali in pochi minuti, senza dover acquistare alcun software e imparare linguaggi di programmazione.