Print this chapterPrint this chapter

Lezione

10. Compendio

10. Compendio

10.1. GDPR, criptazione e sicurezza

Nelle precedenti pagine abbiamo affrontato gli aspetti tecnici ed esecutivi per realizzare un web server e pubblicarlo. In realtà questo non è sufficiente per avere un sito completamente compliant soprattutto se introduciamo servizi come iscrizioni, automazioni, news letter, eshop, ecc…

Spendiamo qualche parola circa i tre elementi irrinunciabili: GDPR, criptazione e sicurezza.

10.1.1. GDPR

Si tratta di un regolamento europeo stringente ed ineludibile. Dobbiamo o studiarlo o chiedere una consulenza ad un esperto per gli eventuali adeguamenti.

Ipotizzando che il nostro web server esponga contenuti, senza servizi e usando solo cookies tecnici che restano nel sito web ci si adegua con poca fatica:

  • studiamo la situazione e stendiamo il nostro piano GDPR;

  • pubblichiamo nel sito un articolo corretto con le giuste informazioni circa finalità, trattamento e che non ci sono cookies di terze parti;

  • aggiungiamo un sistema al nostro sito che notifichi al navigatore che accede la prima volta tutto questo e chieda la conferma di lettura e consapevolezza.

È oltre gli obiettivi di questo manuale entrare nel merito in modo esaustivo. Pertanto dobbiamo per forza rimandare i lettori ad una consulenza o all’assoldamento di un esperto.

10.1.2. Criptazione

Il GDPR e la sicurezza introducono una serie di attenzioni obbligatorie. Uno degli aspetti è la criptazione anche dei file per evitare che un accesso o un’esfiltrazione di file e di dati faccia uscire informazioni sensibili.

Dobbiamo distinguere tra criptazione stretta e pseudonimizzazione:

  • criptazione: si tratta della codifica di tutto quello che viene scritto sul nostro hard disk. Normalmente è un’operazione che viene fatta alla creazione del server adottando un file system criptato.

    La scelta in questo senso è molto buona, ma ha un impatto da considerare e valutare:

    • ad ogni avvio dobbiamo sbloccare l’accesso al disco. Se gestiamo un server remoto è un’operazione decisamente antipatica perché dovremmo accedere alla console remota del VPS;

    • la criptazione del file system aggiunge calcolo e rallenta il nostro server ed i servizi. Anche se in ambiente *nix con l’hardware di oggi abbiamo overload trascurabili, è bene valutarne l’adozione alla luce di tutto il pacchetto.

  • Pseudonimizzazione: si tratta di una separazione delle informazioni che non compariranno mai aggregate e che possiamo riunire solo tramite una sigla che in se non dice nulla.

    Ad esempio l’anagrafica ed i dati medici di Mario Rossi li possiamo dividere su più tabelle del nostro database e identifichiamo tutte queste informazioni con la sigla di fantasia ABCD1234FFT1. Se prendiamo i dati sparsi nelle tabelle non riusciremo mai a riunificarli. Pertanto individuato il nome Mario Rossi non riusciamo a sapere se è diabetico o meno. Solo se prendiamo la ABCD1234FFT1 possiamo sapere quali sono i dati corretti correlati a Mario Rossi.

    Questa tecnica comporta un po’ di programmazione alla portata di ogni sviluppatore. È una buona soluzione per database, ma non aiuta, ad esempio, con i dati su file o su hard disk.

    È utile considerare che in un web server coesistono diverse tecnologie, diversi servizi e lo possiamo usare a scopi diversi. Il nostro web server, ad esempio, può ospitare solo locandina e programma delle attività ricreative estive o potrebbe ospitare il sistema di gestione completa delle attività estive compresi pagamenti, iscrizioni, database dei partecipanti, ecc...

    Pertanto la pseudonimizzazione viene a rispondere a bisogni di anonimizzare i dati per il portale dei servizi delle attività estive, senza dover criptare il server o dover criptare il database.

10.1.3. Sicurezza

La sicurezza è un concetto più estensivo previsto anche dalle normative GDPR.

Alcuni aspetti sono sostanzialmente obbligatori:

  • attivare il firewall interno al web server;

  • avere una procedura di disaster recovery;

  • avere una politica di backup;

  • adottare solo password sicure e dove è possibile, l’accesso tramite certificato e non tramite password;

  • usare esclusivamente connessioni HTTPS.

Se decidiamo di andare in produzione con servizi reali tutto questo va anche correttamente documentato e gestito.

Altro aspetto da tenere in doverosa considerazione è la sicurezza intrinseca dei portali web:

  • affidiamoci a soluzioni consolidate, in uso da tempo e che hanno alle spalle un’azienda manteiner o una community consolidata come per Joomla e WordPress;

  • teniamoli costantemente aggiornati e monitoriamoli con una adeguata frequenza;

  • rinunciamo a componenti aggiunti esotici di programmatori improbabili;

  • sviluppo e prove facciamole sempre su un sito gemello sulla propria work station, mai online sul sito in produzione;

  • non concediamo accessi privilegiati o possibilità di gestione a persone inesperte o non formate.

Ebbene: internet è come l’oceano, ma a differenza dell’oceano c’è uno squalo affamato ogni 3 metri quadrati.

10.2. Apache: Host e VHost

Installando il certificato con certbot abbiamo visto che Apache ha una configurazione “Virtual Host” associata al nome FQDN del nostro sito: cosa significa?

Abitualmente i web server ospitano tanti siti web e sevizi web. Per indicare ad Apache Server HTTP quale sito deve offrire al navigatore tra tutti quelli che contiene può o usare l’indirizzo IP o usare il nome FQDN.

Se usiamo l’indirizzo IP significa che il nostro server deve possedere tanti IP quanti sono i siti ospitati. Questa pratica da tempo non si usa più perché gli indirizzi IP sono limitati e sono diventati una risorsa preziosa.

La seconda soluzione è che il nostro server ha un solo indirizzo IP, ma ci sono diversi nomi FQDN che puntano a un solo indirizzo IP. Apache capisce quale sito web deve servire leggendo l’FQDN con cui viene interrogato.

I web server permettono una configurazione mista: un pool di IP con gruppi di nomi FQDN che puntano a uno degli IP assegnati al web server.

Apache usa il tag <VirtualHost> insieme alle direttive ServerName e ServerAlias per individuare quale sito offrire tra tutti quelli presenti al suo interno.

Non è oggetto di questo manuale approfondire l’argomento, ma potendo gestire un web server abbiamo molte possibilità che ci permettono da una parte di sfruttare bene le potenzialità e dall’altra parte di costruire soluzioni utili e interessanti.

10.3. Accelerare PHP

PHP è un linguaggio popolare e largamente conosciuto. Soffre di diversi limiti. In particolare, proprio per la sua architettura di fondo, è lento.

Per mitigare questo importante limiti si sono sviluppate soluzioni diverse nel tempo.

Sono nati framework di programmazione che ottimizzano il codice riducendo al minimo i cicli di calcolo necessari.

Si è intervenuti sull’integrazione tra il web server e PHP andando a rimpiazzare il primo modulo PHP per Apache con soluzioni alternative.

Parallelamente sono sorte applicazioni di cache che riducono il riprocessamento degli script introducendo benefici a volte molto, molto importanti.

Accanto alle soluzioni cache sono venute alla luce implementazioni di database no SQL che fanno da cache. Anche queste contribuiscono ad ottenere accelerazioni molto importanti.

Spesso è una sapiente combinazione di questi elementi che da i risultati migliori.

Appreso il concetto l’argomento è oltre gli obiettivi di questo manuale. Però offriamo di seguito un elenco parziale delle tecnologie di accelerazione di PHP prendendo in considerazione le forme di collegamento tra il web server (Apache o Nginx) e le cache più usate.

  • FastCGI: è stata la prima mitigazione introdotto. Si basa sull’esternalizzazione dei processamenti degli script PHP e il loro riutilizzo. Quando viene chiesta la stessa elaborazione non viene rifatto il calcolo, ma viene offerto direttamente il risultato;

  • FPM: acronimo di FastCGI Process Manager. Si tratta di un modulo che sostituisce il vecchio FastCGI. Funziona sullo stesso principio di FastCGI, ma è molto più performante e permette molta più flessibilità;

  • OPCache: è una cache all’interno di PHP. Di norma è attiva e ha una configurazione base già impostata. Serve per accelerare tutte le operazioni di processamento degli script e funziona a livello globale;

  • APCu: è un modulo aggiuntivo di PHP e crea una cache gestita direttamente da PHP a fattor comune, esterna al core, usata direttamente dalle applicazioni;

  • Memcached: si tratta di un software server aggiuntivo da installare nel server. Una volta lanciato crea nella RAM una cache molto veloce e performante che viene usata dalle applicazioni come Joomla, WordPress e altre;

  • Redis: implementa la stessa filosofia di Memcached, ma realizza l’obiettivo attraverso un forma di database no SQL molto rapido. Non si presta molto bene per una cache generalista, ma gestisce molto bene, ad esempio, la tenuta delle sessioni.

10.4. Ruby, Node.js, Go

PHP è stato tra i primi linguaggi di scripting nati per il Web. La sua facilità, le potenzialità e la sua natura open source ne hanno decretato un successo rapido e universale.

L’uso così vasto, però, ha messo ben in luce i limiti ulteriormente evidenziati dalle sfide più recenti che arrivano dalla crescita della rete, dalla progressiva sistematica digitalizzazione di tutto, dei big data e dell’AI.

Da queste provocazioni hanno preso vita altri progetti che si propongono di nascere senza alcuni difetti e risolvere nativamente le nuove sfide della rete.

Vediamo un piccole elenco selezionato delle tecnologie emergenti a cui guarda come alternativa a PHP o come tecnologia necessaria per far girare alcune applicazioni.

10.4.1. Ruby on Rail

«Un linguaggio open source dinamico che dà particolare rilevanza alla semplicità e alla produttività, dotato di una sintassi elegante, naturale da leggere e facile da scrivere» recita la descrizione ufficiale di questo linguaggio disponibile all’URL https://www.ruby-lang.org .

Il suo punto di forza è la sintassi semplice e intuitiva. Adotta formalismi più recenti e più performanti come Yaml e, durante la progettazione, ha preso il meglio dalla altre tecnologie analoghe.

Ruby on Rail è un framework per applicazioni web basato sul linguaggio Ruby. Pensato per costruire applicazioni web di livello aziendale realizza software veramente performanti, sicuri e in grado di gestire grandi volumi di lavoro.

10.4.2. Node.js

Si tratta di un ambiente runtime open source per eseguire codice JavaScript lato server. Il sito del progetto è https://nodejs.org .

Permette di sviluppare applicazioni minimizzando le conoscenze necessarie. Semplifica parte della complessità di Java, migliora le performance delle tradizionali applicazioni Java in Application Server (vedete qui di seguito), gestisce in modo eccellente scalabilità e i cicli di deploy delle applicazioni e. soprattutto, è molto veloce.

10.4.3. Go

Sempre una soluzione open source, nota anche con il nome GoLang, disponibile al sito https://go.dev .

Creato dalla Google ha l'obiettivo di risultare efficiente, leggibile e semplice da apprendere. Decisamente veloce, soprattutto in compilazione, lo troviamo integrato in molte applicazioni di tipo aziendale.

10.5. Java a AS

Java è una tecnologia nata nel 1991. Fu un linguaggio che introdusse innovazioni dirompenti. In particolare la possibilità di funzionare su qualsiasi computer, di operare con vesti diverse e di essere open. Fu presto adottato dal mondo aziendale portando a sviluppare standard industriali noti come J2EE e JSR.

Non mancano le controindicazioni: dichiarato morto più volte continua a vivere, ma si trascina limiti di rilievo, come l’esigenza di risorse hardware, una gestione vecchia dell’esaurimento della RAM, log di errore chilometrici per qualsiasi tipo di problema, una sintassi abbastanza complessa e poco intuitiva.

Nel tempo sono stati sviluppati diversi framework che permettono di ridurre notevolmente il numero di righe di codice da scrivere e/o introducono funzioni di alta affidabilità con solo un paio di istruzioni.

Java lo troviamo a totale libero uso nella versione OpenJava (noto anche come OpenJDK e OpenJRE) disponibile all’URL https://openjdk.org . Offre fondamentalmente due versioni di se stesso:

  • JDK: per gli sviluppatori e completo dell’ambiente per far girare le applicazioni;

  • JRE: per l’utente comune con il solo ambiente per far girare le applicazioni.

Java permette di fare applicazioni in scripting, ma anche applicazioni binarie che girano nella tradizionale forma desktop o come app per tablet e cellulari.

In ambiente web può funzionare come script puro all’interno di una pagina HTML, o come script server-side come PHP, Ruby o Node.js, ma anche in forma di applicazione vera e propria (in gergo Portlet). In questa forma dobbiamo mettere l’applicazione dentro un Application Server (da qui in poi AS) e sarà l’AS a parlare con il web server.

Detto questo, allo scopo di un web server, vale la pena conoscere alcune caratteristiche. In particolare sapere che esistono diverse razze di Java. In secondo luogo l’architettura attraverso gli AS e, infine, la tecnologia dei reverse proxy.

10.5.1. Java: quale razza?

Java fu inventato dalla Sun. Distribuito come open source, dopo una lunga guerra di brevetti con la Microsoft, ha visto degli spin off con IBM all’inizio. Nasceva e viveva bene anche Open Java.

Nel 2009 la Sun fu comprata dalla Oracle. Dopo una prima fase di grigio e di cambio licenza di Java, si è tornati ad avere una versione di libero uso targata, però, Oracle.

Pertanto al momento abbiamo, tra i più noti, Open Java, Oracle Java e IBM Java.

Questa varietà ha portato gli sviluppatori ad usare, a volte porzioni di codice esclusivo di un brand. Pertanto possiamo incappare in una applicazione che se fatta girare con Open Java si blocca perché cerca una classe Oracle.

Pertanto i Java sono tutti uguali, ma anche tutti diversi...

10.5.2. Java e gli AS

Gli AS sono dei particolari programmi che servono per far girare i programmi web scritti in Java.

Come per il linguaggio esistono diversi AS perché varie house software hanno realizzato il loro AS. Come per il linguaggio non sono tutti veramente equivalenti e non tutte le applicazioni girano in tutti gli AS.

Tra gli AS più noti c’è:

  • TomCat, https://tomcat.apache.org , è sicuramente il più noto. Mantenuto dalla fondazione Apache è open source, abbastanza completo, non ha particolari requisiti per girare ed è anche dotato di un pannello web di gestione;

  • GlassFish, https://glassfish.org , sviluppato in origine da Sun, ora è mantenuto dalla fondazione Apache. È rimasto open source, completo in tutti gli aspetti necessari ad un AS enterprise lo si gestisce completamente tramite un’interfaccia web;

  • Jetty, https://eclipse.dev/jetty , lo possiamo definire un TomCat senza la pagina web. È concepito per ridistribuire applicazioni in pacchetti demo autoconsistenti. Leggero, veloce, open source manca, oltre al pannello web, anche di tutto lo strato enterprise;

  • WildFly, https://www.wildfly.org , è il fratello open source di JBoss, un AS completo di tutto di livello industriale;

  • JBoss, https://www.jboss.org , è un AS prodotto dalla Red Hat. È un piccolo mostro nel senso che è completo di tutto ed è di livello enterprise in tutti i sensi.

10.5.3. Java e i reverse proxy

Immaginiamo per un momento che il nostro CMS sia stato realizzato in java. Per farlo girare lo mettiamo dentro un AS, ma se proviamo a collegarci alla nostra URL www.example.com non vedremo nulla.

Questo accade perché gli AS pubblicano le applicazioni sulle porte 8080 e 8443. Tornando al nostro CMS java dobbiamo correggere l’URL in www.example.com:8080 .

Perché questa stranezza e come gestirla?

Gli AS sono pensati per girare in un ambiente isolato e staccato da internet. Motivo per cui non usano le porte web standard. Per rimettere le pagine sulle porte standard dobbiamo mettere uno speciale programma tra l’AS e internet. La funzione di questo programma è di fare da “reverse proxy”.

Gli AS usano questa architettura fondamentalmente per tre motivi:

  • sicurezza: l’AS, i suoi applicativi e tutti i dati sono in uno spazio digitale isolato fisicamente e a livello software rispetto a internet;

  • bilanciamento: pensando ad applicazioni che offrono servizi di grande dimensioni (es.: il pagamento dei bollettini postali che contava una media di 400 transazioni al minuto) il software di reverse fa anche da bilanciatore, passando le richieste al server libero;

  • alta disponibilità: il reverse può garantire la continuità di servizio costruendo un nodo ad alta disponibilità. Pensiamo al caso di una manutenzione bloccante su un server il bilanciatore ridirige tutto sul server online in modo del tutto invisibile all’utente.

10.6. IIS e .NET

La soluzione LAMP e LEMP sono molto popolari, sono dietro a moltissimi siti web, ma si riferiscono al mondo *nix anche se non mancano i porting, per sviluppo o prototipazione o per produzione, anche nel mondo Windows.

Microsoft offre come default una soluzione diversa basata su IIS e .NET. Le applicazioni che girano in questo ambiente si caratterizzano per l’estensione .ASP delle pagine web:

  • IIS: è l’acronimo di Internet Information Services. L’applicativo è disponibile in tutte le versioni Windows anche se l’uso, come server pubblico, è vincolato da licenze software da acquistare;

  • .NET: in prima battuta lo possiamo definire come il PHP di Microsoft. Di fatto funziona con la stessa logica. Da qualche anno il core è diventato uno spin-off ed è disponibile per tutti come open source.

È da considerare che la combinata IIS + .NET funziona bene ed è ben integrata con tutto l’ecosistema Microsoft. Anche lo sviluppo di applicazioni è semplice e con poche righe si integra sia Word, piuttosto che Excel o SQL Server.

È una tecnologia di cui averne sicuramente consapevolezza insieme al dato che per metterla in produzione dobbiamo comprare alcune licenze.

10.7. Altre tecnologie

Allo scopo introduttivo e didattico di questo manuale è opportuno far presente che “abbiamo guardato dal buco della chiave”.

Le tecnologie per realizzare un web server non sono solo queste.

È importante averne consapevolezza e conoscere i seguenti punti:

  • alcune tecnologie sono verticali, legate a una sola azienda e realizzate per uno scopo preciso;

  • altre tecnologie sono nate con l’aspirazione a diventare standard per contrastare altre aziende o conquistare quote di mercato;

  • l’iniziale libertà che aveva e permetteva internet è diventata progressivamente uno spazio con standard precisi. Pertanto guardando a tecnologie diverse il criterio fondamentale è che siano conformi agli standard pubblici consolidati.
    Per capirci un’eventuale app pubblicata oggi che fa brillantemente un determinato servizio internet è da prendere in seria considerazione se è conforme agli standard internet.