REQUIREMENTS.

Transcript

1 2014 REQUIREMENTS

2 LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità o idoneità per uno scopo particolare. LiveBox Srl si riserva il diritto di rivedere questa pubblicazione e di apportare modifiche al suo contenuto, in qualsiasi momento, senza alcun obbligo di notificare qualsiasi persona o entità di tali revisioni o modifiche. Inoltre, LiveBox Srl non rilascia dichiarazioni o garanzie in merito ad alcun software e in particolare disconosce qualsiasi garanzia espressa o implicita di commerciabilità o idoneità per uno scopo particolare. LiveBox Srl si riserva il diritto di apportare modifiche a qualsiasi parte del software LiveBox in qualsiasi momento, senza alcun obbligo di notificare qualsiasi persona o entità di tali cambiamenti LiveBox Srl. Tutti i diritti riservati. Nessuna parte di questa pubblicazione può essere riprodotta, fotocopiata, memorizzata su un sistema di recupero, o trasmessa senza l espresso consenso scritto dell'editore. 1

3 LiveBox è un software di private cloud che permette di memorizzare, condividere e modificare i documenti archiviati all interno del datacenter aziendale offrendo un elevato livello di sicurezza. È un sistema multipiattaforma accessibile da tutti i device mobili e remoti che garantisce la continuità del business salvaguardando in ogni momento dati e documenti aziendali. Per gli approfondimenti relativi alle funzionalità della piattaforma LiveBox ed all utilizzo delle sue applicazioni vi preghiamo di far riferimento al nostro sito web: ed alla documentazione tecnica in esso contenuta. LiveBox Support Team 2

4 Sommario 1. LIVEBOX, UN FILE SHARING PRIVATO REQUISITI E INSTALLAZIONE... 5 REQUISITI... 5 REQUISITI DEI PROTOCOLLI UTILIZZATI: REGOLE FIREWALL... 7 REQUISITI MINIMI PER LA PUBBLICAZIONE SU INTERNET TIPOLOGIE DI INSTALLAZIONE... 9 INSTALLAZIONE ONE TIER (STANDALONE)... 9 INSTALLAZIONE TWO TIER INSTALLAZIONE THREE TIER INSTALLAZIONE IN MODALITÀ BUSINESS CONTINUITY

5 1. LIVEBOX, UN FILE SHARING PRIVATO LiveBox è una piattaforma di file sharing di tipo privato in architettura client/server. Il server risiede all interno dell infrastruttura del cliente, garantendo la riservatezza e la sicurezza del dato. Disponendo di una connettività Internet con IP pubblico (o registrato su un servizio di naming dinamico) è altresì possibile garantire l accessibilità da remoto. Essa può essere effettuata da browser complaint con lo standard HTML5 (IE 10, Firefox, Chrome, Opera, Safari), da sistemi OS Android (4.x), da sistemi ios (da 6.x), da sistemi Windows (da XP SP3, 32 bit o 64 bit), da Mac OSX (>= 10.7). Nel corso del 2014 si garantirà il supporto a piattaforme Windows Phone 8. Due i paradigmi che hanno portato allo sviluppo della nostra piattaforma: L installazione e l utilizzo all interno della propria infrastruttura Hardware. La condivisione dei contenuti, in modo privato, sicuro e senza movimentazione dei files. 4

6 2. REQUISITI E INSTALLAZIONE Il sistema LiveBox consta di quattro server principali, ciascuno dei quali ne definisce un ruolo: Server web (termina le sessioni HTTPS verso il client, e fornisce la funzione operativa al linguaggio dell applicazione) contenente l integrazione con LDAP+SAMBA (per proxare la richiesta proveniente dall application server senza interferirne con la privacy delle sue credenziali di dominio o LDAP) esso contiene l application server, che esegue il codice PHP per eseguire tutte le operazioni dell utente File server (repository del dato fisico crittografato) Database server (comunica con l application server per scambiare i dati relativi ai permessi, le condivisioni dei file, la creazione di gruppi di lavoro, etc; non contiene dati costituite da credenziali; contiene l hash dei dispositivi salvati ed autorizzati) Push Server (esegue la sincronizzazione dei dati per gli utenti sui dispositivi mobile o su PC) Per ambienti di dimensioni medie i primi tre ruoli sono gestiti da un server (il cui IP viene pubblicato su Internet) per ricevere tutto il flusso applicativo da client a server LiveBox. Il ruolo di Database è gestito da un server fisico (protetto in un area della rete di DMZ interna, non accessibile da Internet). L ultimo ruolo è generalmente gestito da un server fisico, il cui scopo è sincronizzare i dati sui dispositivi (da e verso), pertanto anche esso deve essere raggiungibile da e verso Internet attraverso un unico IP (NAT One-to-One). Per installazioni in ambienti virtuali, si consigliano le seguenti best practices: Le virtual machine del servizio livebox devono avere virtual disk eagerzeroed thick Le virtual machine del servizio livebox devono essere configurate con almeno X GB di RAM, Y vcpu, 1NIC gb-eth (per i valori X e Y, consultare la tabella [2.1]) Eliminazione di tutte le snapshot non necessarie Installazione dei vmware-tools Policy di power management del server fisico configurate per High performance (BIOS setting e Esx server setting) 2.1 REQUISITI I requisiti dell installazione minima, con un solo server che svolge tutti i ruoli applicativi, sono di seguito elencati: 0 to 500 users: 4 CPU Multi Core and 6 Gb RAM Storage depends on how big must be users home folder. 500 to 1000 users: 4 CPU Multi Core and 8 Gb RAM. Storage depends on how big must be users home folder. 5

7 1000 to 2000 users: 2 Frontend with: o 4 CPU Multi Core and 8 Gb RAM. 3 DBMS: with: 4 CPU Multi Core and 12 Gb RAM. o Storage depends on how big must be users home folder to 3000 users: 3 Frontend with: o 4 CPU Multi Core and 8 Gb RAM. 3 DBMS with: o 4 CPU Multi Core and 12 Gb RAM. Storage depends on how big must be users home folder to 4000 users: 4 Frontend with: o 4 CPU Multi Core and 8 Gb RAM. 5 DBMS with: o 4 CPU Multi Core and 12 Gb RAM. Storage depends on how big must be users home folder to 5000 users: 5 Frontend with: o 4 CPU Multi Core and 8 Gb RAM. DBMS with: o 4 CPU Multi Core and 12 Gb RAM. Storage depends on how big must be users home folder. Si tenga inoltre presente che l assegnamento dello spazio per utente deve includere il 10% per la quota cestino e il 20% per la quota file versioning. Il sistema operativo necessario a LiveBox è GNU/Linux. Il software è compatibile con tutte le distribuzioni di derivazione Debian e Redhat. 6

8 Inoltre, le dipendenze per l installazione sono: Apache 2 Openssl MariaDB (>= 10.x) Openfire Openldap Samba 4 PHP >= 5.5 Git L operazione di installazione è facilitata da un installer che, oltre al setup dell environment, installa le dipendenze necessarie elencate pocanzi. REQUISITI DEI PROTOCOLLI UTILIZZATI: REGOLE FIREWALL Comunicazione client applicazione web All_WAN IP_pubblico_Application_Server All_LAN IP_privato_Application_Server Comunicazione server/client applicazione push All_WAN IP_pubblico_Push_Server All_LAN IP_privato_Push_Server IP_pubblico_Push_Server All_WAN IP_privato_Push_Server All_LAN Comunicazione server con LDAP, DNS e mail server IP_Application_Server,IP_Push_Server,IP_DB_Server DNS_Server IP_Application_Server,IP_Push_Server LDAP_Server IP_Application_Server,IP_Push_Server MAIL_Server Comunicazione server installazione multilivello IP_Application_Server IP_Push_Server IP_Application_Server IP_DB_Server Comunicazione per licensing, aggiornamenti, installazione (da distro Debian): IP_LB_Servers hub.liveboxcloud.com, git.liveboxcloud.com, ftp.de.debian, security.updates.org HTTPS HTTPS TCP_5222,TCP_5223 TCP_5222,TCP_5223 TCP_5222,TCP_5223 TCP_5222,TCP_5223 UDP_53 TCP_389 TCP_25 TCP_9090 TCP_3306 TCP_80, TCP_

9 REQUISITI MINIMI PER LA PUBBLICAZIONE SU INTERNET Il sistema LiveBox è consultabile da dispositivi mobile e PC remoti. In una architettura tipica i client accedono ad un IP che corrisponde al server dell applicazione web (in https). I client accedono e sono acceduti da un ulteriore IP, su protocollo XMPP, Almeno 1 IP pubblico (la pubblicazione in https dell Application_Server; pubblicazione delle porte 5222 e 5223 per server Push; l IP pubblico del server push deve essere del tipo NAT One_to_One) Per esporre il certificato web in https è necessario conoscere il manteiner DNS del dominio di secondo livello rispetto al quale registrare il nome dell applicazione LiveBox. Il certificato web può essere anche autogenerato da una propria Certification Authority interna, purchè sia singolarmente importato su ogni dispositivo manualmente (con ovvia riduzione della manutenibilità). Il sistema LiveBox si integra nell Active Directory nell ipotesi che siano validati i seguenti requisiti: Disporre delle credenziali di un utente in sola lettura in LDAP Disporre del DN (Distinguished Name) dell utente Disporre del DN del dominio Disporre del BN (Base Name) attraverso cui effettuare la query di ricerca utenti L applicazione può importare solo utenti che dispongano del campo mail non vuoto (il campo mail è mandatario per l invio del messaggio di benvenuto iniziale che avvisa che l utente in AD è stato aggiunto come utente LiveBox). 8

10 3. TIPOLOGIE DI INSTALLAZIONE L installazione di LiveBox può essere realizzata in funzione delle caratteristiche dell infrastruttura del cliente, dei livelli di sicurezza, di ridondanza e di gestione. Di seguito si riportano solo alcune delle possibili configurazioni, basate su schemi di architettura multilivello. INSTALLAZIONE ONE TIER (STANDALONE) In questo caso il sistema si compone di un unico server, che svolge tutte le funzioni: Applicazione web locale Server Push Servizi REST Database delle opzioni e degli utenti LiveBox I vantaggi di questa infrastruttura risiedono in una minore complessità del sistema, che ne può però esporre ad minore grado di resilienza in termini di sicurezza logica o fisica. Figura 1: Layout di installazione in modalità standalone 9

11 INSTALLAZIONE TWO TIER In questa tipologia, il sistema si compone di due server: Reverse Proxy in DMZ su server 1 Applicazione + Server Push e Database I vantaggi di questa infrastruttura risiedono nella separazione fisica dei server esposti all accesso dei client (da Internet e da Intranet), che può garantire un maggiore grado di resilienza in termini di sicurezza logica o fisica. Figura 2: Layout di installazione su due livelli 10

12 INSTALLAZIONE THREE TIER In questo caso il sistema si compone di tre server: Reverse Proxy in DMZ su server 1 Applicazione + Server Push su server 2 Database su server 3 I vantaggi di questa infrastruttura risiedono nella separazione fisica dei server esposti all accesso dei client, (da Internet e da Intranet), che può garantire un maggiore grado di resilienza in termini di sicurezza logica o fisica; il database delle configurazioni e degli utenti LiveBox è fisicamente collocato in un server separato fisicamente e trovantesi in una rete separata da FW rispetto all Applicazione Web. Figura 3: Layout di installazione su tre livelli 11

13 INSTALLAZIONE IN MODALITÀ BUSINESS CONTINUITY In ambienti enterprise è necessario che i servizi siano raggiungibili senza discontinuità. In questo caso ognuno dei livelli che possono rappresentare un PoF (Point of Failure) sono replicati, al fine di garantirne la funzionalità del singolo livello. In generale non è possibile escludere un degrado del servizio, poiché il passaggio attraverso nodi di rete che possono preservare il TTL delle sessioni (FW con stateful inspection), possono richiedere che una sessione TCP necessiti di una re-transmission. Meccanismi di persistenza, caching del browser, e altri possono ulteriormente inficiare la fruibilità del servizio da parte dell utente, ma non la funzionalità del servizio nella sua globalità piuttosto che l integrità del dato. In questo caso il sistema si compone almeno di 8 server: Reverse proxy in configurazione Active / Passive di Apache Applicazione web in configurazione Active / Passive di Apache Database delle opzioni e degli utenti in configurazione Cluster Active / Passive di Mysql Storage contenenti lo spazio disco dei due server database e i dati dei file criptati su una configurazione in NFS su record host con rsync tra i due storage o tramite multipath, anche su server fisici separati Ai vantaggi relativi ad una infrastruttura senza PoF, si contrappone una maggiore complessità di gestione. 12