# Blog — lymphatechnologies.com Fonte: · Lingua: it · Contenuti: 19 · Aggiornato: 2026-08-31T10:17:18+02:00 ### [Come lo abbiamo fatto: infrastruttura critica sanitaria, due Data Center e il disaster recovery che non aspetta il disastro](https://www.lymphatechnologies.com/it/come-lo-abbiamo-fatto-infrastruttura-critica-sanitaria-due-data-center-e-il-disaster-recovery-che-non-aspetta-il-disastro) Pubblicato: 2026-08-31 · Autore: Redazione Lympha · Categorie: Casi di successo > Un sistema dedicato alla sanità regionale che non può fermarsi mai, due siti speculari a decine di chilometri di distanza e una regola semplice: ogni singolo guasto deve essere già stato previsto. In questo articolo - Il contesto e la sfida - Le criticità da cui siamo partiti - Due siti gemelli: l'hardware - Lo storage: le performance sono una politica, non un numero - Virtualizzazione open source dove conta - Il dato: perché Data Guard e non il mirroring dello storage - La rete: a caccia di single point of failure - Il backup: la granularità che cambia le domande - La lezione ← Tutti gli articoli Il contesto e la sfida Ci sono sistemi informativi che possono permettersi una finestra di manutenzione. Poi ci sono quelli che governano la disponibilità di servizi critici per un'intera regione. Il progetto riguardava il sistema informativo di una rete di medicina, verticale e di visibilità regionale (volutamente teniamo generico il riferimento al fine di poter scendere più nel dettaglio tecnico realizzativo senza esporre inforamzioni del Cliente): il gestionale che accompagna ogni attività medica, i servizi dipartimentali collegati, il bus d'integrazione verso i sistemi delle aziende sanitarie, il data warehouse per la programmazione e il governo clinico. Un ecosistema di oltre quarante macchine virtuali per sito, distribuite su tre ambienti — produzione, test e collaudo — con database Oracle mission critical (RAC e DataGuard) al centro di tutto. Il requisito non era negoziabile: il servizio deve restare disponibile anche se un intero data center diventa irraggiungibile. "Ripartire in qualche giorno" non era una possibilità valutabile. L'unica era restare disponibili, ovvero piena e cruda Business Continuity. La risposta non è stata un prodotto, ma un'architettura. E una scelta di metodo che ha guidato tutto il resto: due siti identici, configurati specularmente, in due città diverse della regione. Non un sito di produzione "vero" e un DR di serie B, ma due gemelli. Quando primario e secondario sono la stessa macchina, ogni procedura di ripristino diventa più corta, più prevedibile e — soprattutto — provabile. Le criticità da cui siamo partiti Progettare per la continuità significa prima di tutto elencare i modi in cui le cose si rompono. L'analisi iniziale ha messo in fila i punti di attenzione classici di queste infrastrutture: - guasti hardware puntuali: un disco, un alimentatore, una scheda di rete, un intero nodo di virtualizzazione; - guasti di rete: un cavo, uno switch, un router, un firewall; - perdita del dato: il database che si corrompe, il backup che non è granulare abbastanza; - il caso estremo: l'intero sito primario indisponibile, per giorni o settimane. L'obiettivo dichiarato: arrivare a fine progetto potendo dire, guasto per guasto, chi lo assorbe e come. Vediamo come. Due siti gemelli: l'hardware Ogni sito è stato equipaggiato con tre server fisici Lenovo ThinkSystem SR630: due nodi dedicati alla virtualizzazione — CPU Intel Xeon Gold 6330 a 28 core e 768 GB di RAM ciascuno — e un terzo nodo a uso misto per virtualizzazione, management e monitoraggio, con Xeon Silver 4310T. Quei 768 GB per nodo non sono sovradimensionamento: sono la condizione perché, alla caduta di un host, l'altro possa accogliere tutte le VM critiche migrate senza degrado. La resilienza intra-sito non si compra a listino, si dimensiona: è lo stesso capacity planning che mettiamo nella progettazione di server farm e data center. La connettività è affidata a schede Broadcom a 25 Gbit/s (4 porte per server in active-backup, due canali ad alta disponibilità per le VLAN di servizio), che si attestano su una coppia di switch/router NVIDIA Mellanox con porte a 100 Gbit/s per ogni sito. Ogni server espone la propria BMC per il controllo remoto completo, anche a macchina spenta: quando il sito secondario è a decine di chilometri, "vado a vedere di persona" non è un piano di gestione. Lo storage: le performance sono una politica, non un numero Su entrambi i siti la persistenza è affidata a coppie di storage Lenovo DE4000H, con tre livelli di tierizzazione per tre lavori diversi: SSD SAS + NVME Cache per i database Oracle e i carichi mission critical, dischi SAS 10K per le VM applicative ad alte performance, dischi SATA capacitivi dedicati esclusivamente al backup. La protezione segue la stessa logica a strati. RAID 6 su tutti i volume group — si tollerano due dischi guasti contemporaneamente senza fermarsi — più un hot-spare per ogni tipologia di disco. Doppio controller con 4+4 porte a 25 Gbit/s in bilanciamento e failover: lo storage resta operativo fino alla perdita della settima porta su otto. Due dettagli che spesso mancano nei progetti "a listino": il multi-tiering automatico, cache per i dati caldi e i workload paralleli configurati direttamente sulle controller — profili di ottimizzazione distinti per database Oracle, hypervisor, VM applicative e job di backup. Lo stesso storage, quattro comportamenti diversi a seconda di chi lo interroga. La tierizzazione dei dischi ha un parallelo esatto nella protezione del dato: il continuum RPO–RTO con i sette tier di recuperabilità, dove ogni servizio va collocato nel punto giusto della curva. Virtualizzazione open source dove conta L'hypervisor scelto è Oracle Linux Virtualization Manager (OLVM), l'evoluzione enterprise del progetto open source oVirt, costruito su KVM — lo standard de facto della virtualizzazione Linux. Niente licenze per socket, niente lock-in su un ecosistema proprietario, e tutte le funzionalità che servono davvero: live migration, gestione centralizzata via Hosted Engine (a sua volta protetta: se cade l'host che la ospita, riparte automaticamente altrove), monitoraggio nativo con Grafana integrato. È lo stesso approccio — virtualizzazione aperta, nessun lock-in — su cui poggia il nostro private cloud e VDC. Sopra, un parco di oltre quaranta VM Oracle Linux per sito e diverse Windows Server 2019: bilanciatori Apache in coppia, application server ridondati, il bus di integrazione WSO2 in doppia istanza, il data warehouse con lo strato di business intelligence. Ogni componente di produzione che può essere doppio, è doppio. Il dato: perché Data Guard e non il mirroring dello storage Qui sta una delle scelte tecniche più importanti del progetto, e vale la pena spiegarla perché è il punto dove molte architetture DR si giocano tutto. Il database principale gira su Oracle Real Application Cluster: due nodi attivi che si proteggono a vicenda dentro il sito. Ma la replica tra i siti non è affidata al mirroring remoto dello storage, come si fa spesso. È affidata a Oracle Data Guard in configurazione physical standby: il sito secondario riceve i redo log del primario e li riapplica, blocco per blocco, mantenendo una copia fisica esatta e validata del database. La differenza non è soltanto accademica. Il mirroring di una SAN replica blocchi che non sa interpretare: non può certificare che ciò che arriva a destinazione sia un database consistente, e la scoperta dell'inconsistenza avviene nel momento peggiore possibile — durante il failover. Data Guard valida ogni singolo pacchetto con i meccanismi nativi di Oracle e ricostruisce la sequenza corretta delle transazioni. Nel giorno del disastro, la differenza è tra ripartire e sperare. Le modalità di protezione (Maximum Performance, Availability, Protection) permettono poi di scegliere esplicitamente il compromesso tra prestazioni del primario e garanzia di zero perdita dati — una decisione di business resa configurabile. Per le istanze singole fuori dal RAC, lo stesso Data Guard garantisce l'allineamento verso il sito di DR. Le VM applicative seguono una via più pragmatica: sincronizzazione file-level schedulabile, avendo cura di non replicare i file di configurazione che puntano ai database. Le macchine in DR restano così allineate e pronte all'attivazione, senza il rischio di accensioni accidentali contro il dato sbagliato. Ansible completa l'opera permettendo l'orchestrazione di Playbook scritti ad adhoc per la conduzione dell'infrastruttura e il day-by-day. Non è l'unico modo di disegnare la continuità fra due siti. In un Ente Regionale il sito secondario eroga servizi tutti i giorni invece di aspettare il disastro: è il modello both-active che abbiamo raccontato in 600+ applicazioni, un Ente Regionale e la continuità che si ripaga da sola. La rete: a caccia di single point of failure L'esercizio finale è stato passare al setaccio ogni anello della catena e chiedersi: se si rompe questo, chi lo sostituisce? Doppie schede in teaming sui nodi. Doppi router Mellanox in port-channel per sito. Uplink verso gli switch dell'operatore di rete regionale aggregati in MLAG: il risultato è che si può perdere un cavo, uno switch o un intero router senza interruzione. Il traffico di frontiera è gestito dai firewall dell'operatore regionale, anch'essi collegati in doppia via. Alla fine del setaccio resta un solo single point of failure per sito: il firewall di frontiera, che non è nel nostro perimetro. In caso di down del sito attivo che per gravità porta alla dichiarazione di DR, il traffico viene rediretto dall'operatore verso il data center secondario, dove l'intera infrastruttura — speculare, allineata, già in ascolto — è pronta a erogare (*). Che è esattamente ciò che un piano di continuità dovrebbe fare: non promettere l'assenza di guasti, ma non farsi mai trovare senza risposta. Con un'avvertenza: nessuna ridondanza si autogoverna. Perché il failover parta nel momento giusto serve qualcuno che veda l'evento per primo, ed è il mestiere di un NOC attivo 24×7×365. (* Allo stato attuale dell'infrastruttura siamo in grado di gestire lo switch PDC -> SDC completo in 15 min) Il backup: la granularità che cambia le domande Il backup è organizzato a livelli indipendenti, con un sistema autonomo per ciascun sito. Le configurazioni logiche dell'hypervisor si salvano da sole. Le VM sono protette da Veeam Backup & Replication con salvataggi full e incrementali a livello di volume, indicizzati, organizzati in protection group omogenei, con possibilità di recupero del singolo file. Ma il punto di svolta è sui database: il backup application-aware degli archive log Oracle ha una granularità che arriva a 5 minuti, con retention che può superare i 45 giorni per singola copia. È la differenza tra chiedersi "quanto abbiamo perso?" e chiedersi "a che minuto torniamo?". E c'è un ultimo tassello, quello che chiude il cerchio: la doppia copia dei backup viene parallelizzata in tempo reale verso lo storage del sito di DR, dove un'installazione Veeam gemella è già integrata e pronta alla restore. Anche il backup, come tutto il resto, esiste due volte. Resta la regola che vale in ogni progetto: una copia non è una ripartenza, e l'unico modo per saperlo è cronometrare un restore vero — il motivo per cui il backup da solo non basta. Cosa ci portiamo a casa Niente numeri di marketing: solo ciò che questa architettura eroga by design. - Nessun single point of failure interno all'infrastruttura: ogni componente — disco, porta, scheda, switch, router, nodo, controller — ha un sostituto pronto. L'unico SPOF residuo è esterno al perimetro ed è coperto dal sito gemello. - Perdita dati misurata in minuti, non in giorni: replica continua e validata dei database via Data Guard, archive log salvati con granularità fino a 5 minuti, doppia copia real-time dei backup sul sito di DR. - Ripristino provabile: siti configurati specularmente significa procedure di failover brevi, documentate e ripetibili — non un'ipotesi da verificare durante l'emergenza. - Tre ambienti separati (produzione, test, collaudo) sulla stessa infrastruttura (in questo caso è richiesto dalla complessità e dal "peso" degli ambienti di test e collaudo). - Costi sotto controllo: virtualizzazione open source (KVM/oVirt) senza licenze per socket, storage dimensionato e ottimizzato per tipologia di lavoro da svolgere. La lezione La continuità operativa non si aggiunge, la si progetta. In questo caso nessun componente è stato scelto chiedendosi solo "quanto è veloce?" o "quanto costa?", ma sempre anche "cosa succede quando si rompe?". È un modo di lavorare che apparentemente costa di più, sulla carta, ma infinitamente meno il giorno in cui serve: analisi, progettazione, realizzazione e supporto sono le quattro fasi del nostro metodo, e ogni scelta resta verificabile insieme al cliente. Vuoi capire come applicare questo approccio alla tua infrastruttura? ParliamoneOppure sfoglia gli altri casi di successo. ### [Come lo abbiamo fatto: 600+ applicazioni, un Ente Regionale e la continuità che si ripaga da sola](https://www.lymphatechnologies.com/it/come-lo-abbiamo-fatto-600and-applicazioni-un-ente-regionale-e-la-continuita-che-si-ripaga-da-sola) Pubblicato: 2026-08-11 · Autore: Redazione Lympha · Categorie: Casi di successo · Tag: ITSM, ITIL, business continuity, disaster recovery, governance operativa, pubblica amministrazione > Caso reale di IT Service Management in un Ente Regionale: 600+ applicazioni su tre filiere, governance ITIL su tre livelli, cruscotto unico open source, processi fondamentali, IMaaS e business continuity «both-active» — con il rischio sui servizi critici In questo articolo - Il contesto e le sfide - Modello organizzativo e governance - Il Sistema di Governance Operativa: un solo cruscotto, quasi tutto open source - Business Continuity e Disaster Recovery: la continuità che si ripaga da sola - La gestione del servizio applicativo - Formazione, knowledge management e trasferimento del know-how - Risorse e competenze - Risultati e benefici - Gli elementi di innovazione - Conclusioni ← Tutti gli articoli Con questo articolo apriamo «Come lo abbiamo fatto»: una serie in cui prendiamo un progetto reale e lo raccontiamo com'è andato — senza nomi, per riservatezza, ma con i numeri e le scelte vere. Cominciamo da uno dei più impegnativi: la gestione pluriennale, l'evoluzione e la continuità operativa delle infrastrutture tecnologiche di un grande Ente Regionale italiano. Abbiamo partecipato attivamente alla progettazione, implementazione e gestione di un modello completo di IT Service Management per un Sistema Informativo in rapida evoluzione, con un data center multi-sede di elevata complessità tecnologica. La fornitura ha riguardato la gestione e lo sviluppo delle infrastrutture a supporto di oltre 650 applicazioni distribuite su tre filiere tecnologiche, al servizio di migliaia di utenti interni ed esterni, con un team dedicato di professionisti specializzati. Il progetto ha introdotto elementi di forte innovazione: un Sistema di Governance Operativa integrato, una soluzione di Business Continuity e Disaster Recovery con modello both-active e un approccio metodologico basato sulle best practice ITIL, garantendo piena conformità al D.Lgs. 235/2010 (art. 50-bis del CAD) e alle direttive dell'Agenda Digitale. 600+ applicazioni gestite su tre filiere tecnologiche +15% di crescita delle applicazioni in un biennio −50% di rischio di perdita dei servizi critici 4 h di RTO sui servizi critici, con RPO di 1 ora Il contesto e le sfide L'Ente si trovava ad affrontare una trasformazione profonda del proprio Sistema Informativo. Da un'infrastruttura IT di tipo mid-range, progettata per le esigenze interne dell'Amministrazione, si era progressivamente passati a un data center dotato di un'infrastruttura tecnologica particolarmente complessa a livello di networking, storage e server, a supporto di servizi erogati non solo all'Ente stesso, ma anche a numerosi enti locali, associazioni di categoria, aziende private e cittadini del territorio. Il processo di federalismo regionale aveva sostanzialmente modificato, sia in termini qualitativi che quantitativi, il perimetro del Sistema Informativo, comportando una crescita significativa dei volumi, dei sistemi e delle applicazioni da gestire: il numero di applicazioni pubblicate era cresciuto del 15% in un solo biennio, nelle tre filiere tecnologiche. Le criticità identificate L'analisi del contesto AS-IS aveva evidenziato problemi che chi lavora nella Pubblica Amministrazione riconoscerà al volo: - frammentazione degli strumenti di monitoraggio: molteplici tool diversi (trouble ticketing, monitoraggio, CMDB, project management) con dati scorrelati e assenza di una visione integrata dei servizi IT; - scollamento tra sviluppo ed esercizio: la mancata «saldatura» tra il ciclo di vita del progetto software e il ciclo di vita del servizio rappresentava l'anello debole della catena di controllo; - assenza di un piano strutturato di Business Continuity e Disaster Recovery, in violazione degli obblighi normativi introdotti dal D.Lgs. 235/2010; - storage non classificato secondo logiche di tier (performance, capacità, affidabilità), con conseguenti inefficienze operative; - single point of failure a livello di connettività internet e protezione perimetrale; - backup su nastro con finestre temporali insufficienti per i servizi critici; - assenza di un cruscotto integrato per la governance operativa e la rendicontazione dei servizi. Gli obiettivi strategici L'Ente aveva definito obiettivi chiari — e nessuno di questi era «comprare tecnologia»: - adottare una metodologia di gestione dei servizi IT orientata ai processi, con il livello di qualità percepito dagli utenti come cardine di azione; - dotarsi di un piano di Business Continuity e Disaster Recovery conforme alla normativa vigente; - implementare una piattaforma integrata di governance per il controllo end-to-end dei servizi IT; - garantire la continuità operativa senza soluzione di continuità durante la transizione; - assicurare la piena misurabilità e trasparenza dei servizi erogati attraverso SLA e KPI oggettivi. Modello organizzativo e governance Abbiamo quindi progettato un modello organizzativo snello e flessibile, con chiari ruoli decisionali, strutturato su tre livelli di governance: - Livello strategico — IT Steering Group: comitato esecutivo composto da rappresentanti dell'Amministrazione, con il compito di assicurare l'allineamento degli obiettivi strategici, valutare gli investimenti necessari e il percorso di evoluzione dell'infrastruttura IT; - Livello tattico — Comitato di Controllo dei Servizi IT: organo operativo per la pianificazione e il coordinamento delle azioni attuative, con la figura del Technical Manager come interfaccia principale per le attività giornaliere di controllo, gestione e progettazione; - Livello operativo — tre team integrati, descritti nella tabella che segue. Team · Ambito · Attività principali Team Gestione Operativa (TGO) · Service Operation, Service Transition · Monitoring end-to-end, operation control, backup/scheduling, help desk di II livello, deploy & configuration, facility management Team Supporto Sistemistico Centralizzato (TSSC) · Service Operation, Transition, Design · Gestione infrastrutturale specialistica su 6 aree verticali (Infrastruttura, Middleware, Database, Cartografia, OpenSource, SAP), system integration, help desk di III livello Team Sviluppo Progetti (TSP) · Service Design, Service Strategy · Progettazione e implementazione di nuove architetture, help desk di III livello per casi critici, avviamento alla presa in carico Area Change: integrazione del ciclo di vita del software e del servizio Uno degli elementi più innovativi della soluzione è stata la creazione dell' Area Change, un'unità organizzativa trasversale ai tre team dedicata alla fase di «presa in carico» del software prodotto e successiva «trasformazione» in servizio all'utente — lo stesso principio che oggi applichiamo lungo tutto il ciclo di vita del servizio. L'Area Change ha garantito: - l'integrazione tra la fase di progettazione e sviluppo dell'applicazione (Service Design) e la fase di erogazione del servizio (Service Operation); - una forte attenzione alle fasi di test e validazione del servizio (Service Transition); - la pianificazione delle attività di rilascio di ogni nuovo servizio/prodotto; - l'individuazione e la proposta di strategie e percorsi di innovazione nel ciclo di vita dei servizi; - il coordinamento degli interventi delle risorse dedicate alla definizione e al controllo degli standard e delle linee guida. Area Audit e Miglioramento Per garantire una valutazione costante e oggettiva della qualità dei servizi, abbiamo istituito l' Area Audit e Miglioramento, con le seguenti responsabilità: - monitoraggio continuo dei parametri di qualità predefiniti (KPI e SLA); - pianificazione di azioni di miglioramento anche in presenza di livelli soddisfacenti; - supporto alla redazione di una Carta dei Servizi ICT per formalizzare il «patto di servizio» tra il Servizio Informativo e le Direzioni Generali fruitrici; - gestione del processo di customer satisfaction; - raccolta degli indicatori statistici per la rendicontazione periodica. Il Sistema di Governance Operativa: un solo cruscotto, quasi tutto open source Alla frammentazione degli strumenti abbiamo risposto partecipando all'implementazione di una piattaforma completa e integrata a supporto delle funzioni e dei processi IT — il cuore di quella che chiamiamo IT governance — strutturata in tre aree principali, costruite in larga parte su componenti open source. Governance dei servizi - gestione integrata di incidenti, problemi, change e configuration management tramite CMDBuild; - strumento di trouble ticketing ( RT) per il tracciamento delle richieste di servizio e degli incident; - interazione con i sistemi di bilanciamento ( LBL LoadBalancer) per il Capacity Management; - knowledge base basata su Alfresco per la gestione documentale centralizzata. Governance dell'infrastruttura - Storage Management: gestione dei dati, backup e ripristino; - System Fault & Performance Management: monitoraggio in tempo reale tramite Zabbix con console centralizzata, filtraggio e correlazione degli eventi; - Application Performance Management: controllo dei servizi dal punto di vista utente con transazioni campione; - storicizzazione dei dati in un data warehouse open source SpagoBI per analisi e reporting. Gestione della conoscenza - repository documentale centralizzato basato su Alfresco; - organizzazione, persistenza e fruizione della conoscenza prodotta nell'ambito dell'erogazione dei servizi; - supporto alle attività di formazione e addestramento. Cruscotto Monitor di governance Sopra tutto, il Cruscotto Monitor realizzato su tecnologia SpagoBI. Per un'amministrazione pubblica non è un dettaglio estetico: è la differenza tra dichiarare la qualità del servizio e poterla dimostrare, numero per numero. Il cruscotto ha offerto: - vista d'insieme «semaforica» sullo stato globale dei servizi; - navigazione dei KPI associati a ciascun servizio erogato; - approfondimenti per dimensioni e periodi temporali diversi (real-time, giorno, settimana, mese); - report, OLAP, data mining e QBE; - Libro di Bordo: visione d'insieme su tutti gli eventi che caratterizzano l'erogazione dei servizi, con filtraggio per momento temporale, servizio, sistema, evento scatenante e tipologia; - modulo di rendicontazione con ribaltamento dei costi sulle direzioni fruitrici; - gestione delle presenze e dei turni del personale tecnico; - Site Activity per la tracciatura di «chi fa che cosa»; - attivazione progetti con visione dello stato di avanzamento tramite Redmine. I processi fondamentali ITIL È stato quindi implementato un set completo di Processi Fondamentali (PF) basati su ITIL v3, contestualizzati sulle specifiche esigenze dell'Ente: Processo · Ambito PF01 — Incident Management · Ripristino dell'operatività nel minor tempo possibile PF02 — Problem Management · Identificazione delle root cause PF03 — Gestione Servizio Applicativo · Presa in carico, evoluzione e terminazione dei servizi (processo creato ad hoc) PF04 — Change Management · Gestione controllata dei cambiamenti PF05 — Service Asset & Configuration Management · Gestione del CMDB PF06 — Release & Deploy Management · Gestione dei rilasci PF07 — Service Level Management · Monitoraggio e reporting SLA PF08 — Capacity Management · Pianificazione e allocazione delle risorse PF09 — Knowledge Management · Gestione della conoscenza Change Management e IMaaS Per la gestione dei cambiamenti infrastrutturali abbiamo introdotto il concetto di «Infrastructure Model as a Service» (IMaaS): il Team Sviluppo Progetti eroga modelli infrastrutturali che, una volta approvati, vengono trasformati in architetture IT operative. Il processo di change si articola in: - Request For Change e analisi di fattibilità; - Service Design secondo le 4 P di ITIL (People, Products, Processes, Partners); - rilascio del Service Design Package (SDP) contenente requisiti, specifiche tecniche, piani di test, transition plan e operation plan; - approvazione da parte dell'Ente; - Transition: sviluppo ambienti di test e collaudo; - messa in produzione con supporto del Team Gestione Operativa; - CSI (Continual Service Improvement) trasversale a tutte le fasi. È stato inoltre proposto un laboratorio virtuale (IaaS) per la simulazione delle fasi di transizione, con l'obiettivo di semplificare il processo di adozione e gestione del cambiamento, standardizzare le attività di transizione, garantire l'integrità delle configurazioni dell'infrastruttura di produzione e ridurre problemi e incident in produzione. Business Continuity e Disaster Recovery: la continuità che si ripaga da sola Il capitolo più innovativo è la business continuity. La soluzione è stata progettata in piena conformità con: - D.Lgs. 30 dicembre 2010, n. 235, art. 50-bis (continuità operativa); - direttive DigitPA (ora AgID) per gli studi di fattibilità tecnica; - standard ISO 22301 / BS 25999 per il Business Continuity Management; - framework ITIL — processo di IT Service Continuity Management (ITSCM); - metodologia M_o_R (Management of Risk) per la risk analysis e il risk management. Architettura multi-sito L'approccio classico prevede un sito secondario che costa, consuma e resta spento in attesa dell'emergenza. Qui abbiamo fatto l'opposto, articolando l'architettura su più livelli. Business Continuity Site (BCS) — all'interno del campus dell'Ente: - modello both-active: il BCS non è un costo passivo ma partecipa attivamente all'erogazione dei servizi in tempo reale; - replica asincrona a livello storage (Tier 4) per i servizi critici, tramite virtualizzatori IBM SVC e sistemi Global Mirror/FlashCopy; - replica tramite agenti/snapshot (Tier 3) per i servizi a criticità inferiore, tramite VMware Site Recovery Manager e vSphere Replication; - dorsale ethernet a 10 Gbit e Storage Area Network estesa con doppio fabric in fibra ottica; - connettività internet autonoma e sistemi di protezione perimetrale dedicati. Disaster Recovery Site (DRS) — presso provider esterno a oltre 80 km: - predisposizione architetturale nativa per l'attivazione in emergenza; - interconnessione tramite tecnologie DWDM (Dense Wavelength Division Multiplexing) per distanze superiori ai 100 km; - infrastruttura prevalentemente virtualizzata con possibilità di bare metal restore. Un sito di continuità che resta spento è un costo in attesa di un disastro. Uno che lavora ogni giorno è capacità produttiva — e si ripaga da solo. LBL Surface Cluster: orchestrazione e prevenzione dello split brain Il rischio tecnico più insidioso di un'architettura a due siti attivi è lo split brain: entrambi i siti convinti di essere quello «vero», con corruzione logica dei dati. Per la gestione delle procedure di failover/failback e la prevenzione di questo scenario, grazie alla collaborazione con il partner Oplon abbiamo introdotto la suite LBL Surface Cluster (Decision Engine e WorkFlow), con le seguenti funzionalità: - algoritmo «Split Brain Assassin»: prevenzione della corruzione logica dei dati in caso di alimentazione parallela delle basi dati; - Decision Engine: 3 istanze clusterizzate per sito, per la verifica costante del funzionamento dei servizi critici e la presa di decisioni; - WorkFlow: esecuzione coordinata delle sequenze di attività (script, riavvii, spegnimenti) tramite comandi remoti RWC (Remote Workflow Command); - auto-documentazione delle procedure di failover e failback; - web console intuitiva per la riattivazione dei servizi anche da parte di personale non specializzato — perché nelle emergenze vere lo specialista potrebbe non esserci. Livelli di protezione (Tier) Non tutti i servizi valgono uguale, e la Business Impact Analysis lo ha tradotto in livelli di protezione differenziati — lo stesso principio che raccontiamo in «Il backup non basta»: RTO e RPO si definiscono per servizio, non per l'organizzazione intera. Tier · RPO · RTO · Tecnologia · Servizi Tier 4 · 1 ora · 4 ore · Replica asincrona storage (Global Mirror) · Servizi critici end-to-end Tier 3 · 4 ore · 4 ore · Agenti software, snapshot, Site Recovery Manager · Servizi a criticità media Tier 2 · — · — · Vaulting con TSM, snapshot, VTL con deduplica · Backup consolidati Tier 1 · — · — · TSM, snapshot · Servizi non critici I piani: BCP, DRP, BIA e analisi dei rischi Si è quindi redatto un corpo documentale completo, mantenuto nel tempo: - il Business Continuity Plan (BCP): identificazione dell'esposizione a pericoli interni ed esterni, asset hardware/software e processi atti a prevenire e ripristinare i servizi; - il Disaster Recovery Plan (DRP): procedure operative step-by-step, check list, schemi tecnici per le fasi reattive di Response e Recovery; - la Business Impact Analysis (BIA): quantificazione dell'impatto dell'interruzione dei servizi IT sul business; - la Risk Analysis e il Risk Management: identificazione delle minacce, valutazione della probabilità di accadimento e definizione delle contromisure. La gestione del servizio applicativo Il processo — creato ad hoc — che governa l'intera vita di un'applicazione in esercizio, dalla nascita alla dismissione. Presa in carico e avviamento Il processo di presa in carico di un nuovo servizio applicativo ha previsto: - verifica della completezza e adeguatezza della documentazione; - analisi di impatto e gestione del cambiamento (CAB); - allestimento dell'ambiente di esercizio (software di base, applicativo, base dati); - allestimento dell'ambiente di monitoraggio (sonde e regole specifiche); - allestimento dell'ambiente di gestione (parametrizzazione e passaggio di consegne); - registrazione dei Configuration Item nel CMDB; - collaudo dell'intera infrastruttura; - formazione del Team Gestione Operativa. Evoluzione del servizio Per le evoluzioni (nuove funzionalità, cambi di configurazione), il processo ha previsto l'identificazione delle modifiche e l'analisi di impatto, l'esecuzione del regression test prima del rilascio in produzione e l'aggiornamento del CMDB e della documentazione operativa. Terminazione del servizio Per la dismissione di un servizio: verifica dell'impatto sugli altri servizi, salvataggio degli archivi, disinstallazione della componente applicativa, aggiornamento del CMDB e riallocazione delle risorse tramite il Capacity Management. Formazione, knowledge management e trasferimento del know-how Una fornitura pluriennale si giudica anche da come finisce: la conoscenza, alla fine, deve restare a chi la deve esercitare. Addestramento del personale Si è implementato un processo di knowledge sharing continuo con: - un numero congruente di giornate di formazione annue per ciascuna risorsa; - percorsi certificativi ITIL (Foundation, Service Strategy, Service Design, Service Operation, CSI) per i responsabili di unità; - corsi presso la Scuola di Alta Formazione ICT interna; - formazione a distanza (FAD) e seminari in presenza; - auto-formazione su manuali di prodotto e risorse documentali. Knowledge management Il processo di knowledge management si è articolato in due fasi ricorsive: l' organizzazione della conoscenza (identificazione dei bisogni, ricerca, catalogazione in un repository classificato per processi di servizio) e la valorizzazione della conoscenza (distribuzione, utilizzo e continuo aggiornamento del know-how raccolto). Trasferimento del know-how a fine fornitura Il piano di exit management ha previsto: - Step 1 — Programmazione: predisposizione della documentazione, riunioni preparatorie, allestimento di seminari, verifica dello stato dei sistemi tramite check list; - Step 2 — Affiancamento: sessioni di apprendimento frontale, esecuzione autonoma di compiti specifici, valutazione e autovalutazione, training on the job; - due mesi di assistenza on-demand successivi al termine della fornitura (e-mail, telefono, comunicazione online). Risorse e competenze Il Team Supporto Sistemistico Centralizzato ha operato con presidio H24 su sei aree verticali: - Infrastruttura (server blade IBM/HP, networking, virtualizzazione VMware/Citrix); - Middleware (WebSphere, JBoss, IIS, Apache, Tomcat); - Database (Oracle, SQL Server, PostgreSQL, MySQL, DB2); - Cartografia (sistemi GIS e territoriali); - OpenSource (Linux, Red Hat, soluzioni FOSS); - SAP (ambienti ERP, BW, CRM). Il tutto sostenuto da un sistema di certificazioni e partnership: ISO 9001ISO 14001ISO/IEC 27001CMMI Livello 3ITIL v3PMPPRINCE2 Risultati e benefici Indicatore · Risultato Disponibilità del servizio · SLA rispettati e migliorati rispetto ai requisiti contrattuali Presidio operativo · Copertura garantita H24 su 6 aree tecnologiche critiche Attivazione supporto specialistico (bloccante) · Entro il next business day Attivazione supporto specialistico (non bloccante) · Entro 5 giorni lavorativi Rischio di perdita servizi critici · Ridotto del 50% grazie al modello BCS attivo ROI della Business Continuity · Ritorno sull'investimento pressoché immediato Applicazioni gestite · +15% in un biennio Trasparenza e controllo · Cruscotto unico con KPI real-time e rendicontazione per direzione Conformità normativa · Piena aderenza al D.Lgs. 235/2010 e alle linee guida AgID Benefici infrastrutturali - affidabilità: soluzione certificata dai fornitori e validata attraverso implementazioni analoghe; - elasticità: componenti hardware e software scelte per rispondere con minimo impatto a cambiamenti infrastrutturali; - standardizzazione: confronto costante con standard ISO, framework ITIL e normative di settore; - resilienza: corretto dimensionamento delle infrastrutture e scelta ponderata delle tecnologie; - controllo: gestione globale di tutti i siti tramite strumenti centralizzati. Benefici economici - economia di scala: il BCS attivo ha incrementato complessivamente i servizi erogati; - virtualizzazione: riduzione del costo totale di possesso (TCO) dell'infrastruttura; - ottimizzazione dello storage: razionalizzazione tramite tecnologia multi-tier (EasyTier) con dischi SSD per i dati critici e dischi capacitivi per il resto; - riuso degli asset esistenti: limitazione dell'acquisto di nuovo hardware grazie alla ridistribuzione di risorse già in possesso dell'Ente. Benefici organizzativi - superamento del conflitto sviluppo/esercizio grazie all'Area Change; - miglioramento continuo istituzionalizzato tramite l'Area Audit e il processo CSI; - trasparenza nella cooperazione tra Ente e fornitore; - Carta dei Servizi ICT come formalizzazione del patto di servizio; - rendicontazione e ribaltamento dei costi sulle direzioni fruitrici. Gli elementi di innovazione Modello «both-active» Il Business Continuity Site non è un costo passivo ma partecipa attivamente all'erogazione dei servizi, generando ROI immediato. Area Change integrata Superamento del conflitto strutturale tra team di sviluppo e team di esercizio, con presa in carico controllata e documentata di ogni nuovo servizio. Piattaforma SGO unificata Superamento della frammentazione di strumenti in un unico ecosistema integrato: CMDBuild, RT, Zabbix, Alfresco, Redmine, SpagoBI, LBL. LBL Surface Cluster come orchestratore di DR Automazione e auto-documentazione delle procedure di failover/failback, con gestione del rischio split brain a livello di intero data center. Approccio IMaaS Infrastructure Model as a Service: industrializzazione del processo di progettazione infrastrutturale, con riutilizzo di modelli e componenti in logica «industriale». Laboratorio virtuale per la transizione Simulazione delle fasi di collaudo in ambiente virtuale (IaaS) per ridurre rischi e incident in produzione. Cruscotto Monitor con vista semaforica Navigazione intuitiva dei KPI con approfondimenti multidimensionali e reportistica automatizzata (OLAP, data mining, RSS). Conclusioni Il progetto realizzato rappresenta un caso di eccellenza nella gestione integrata delle infrastrutture tecnologiche per la Pubblica Amministrazione. La combinazione di competenze specialistiche, metodologia ITIL, strumenti open source di governance e soluzioni innovative di Business Continuity ha consentito all'Ente di: - garantire la continuità operativa dei propri servizi IT in conformità alla normativa vigente; - ottenere una visione integrata e trasparente dell'intera infrastruttura tecnologica; - ridurre i rischi operativi e di disastro del 50%; - ottimizzare i costi attraverso la virtualizzazione, il riuso degli asset e il modello BCS attivo; - migliorare continuamente la qualità dei servizi erogati attraverso processi strutturati di auditing e CSI; - preservare il patrimonio di conoscenze attraverso un piano strutturato di knowledge management e trasferimento del know-how. La soluzione si è dimostrata scalabile, sostenibile e pienamente integrata con il contesto organizzativo e tecnologico dell'Ente: un modello replicabile per altre Amministrazioni Pubbliche di analoghe dimensioni e complessità — ne parliamo nella pagina dedicata alla PA locale, mentre il nostro approccio a misura, analisi e miglioramento continuo è raccontato nel metodo. Se la tua organizzazione sta affrontando una transizione simile — governance da costruire, continuità da mettere a norma, servizi che crescono più in fretta della capacità di gestirli — parliamone. Per riservatezza non citiamo l'Ente; dati e indicatori si riferiscono al periodo di erogazione del servizio. ### [Modelli distillati off-grid: quando l'IA locale ha davvero senso in azienda](https://www.lymphatechnologies.com/it/modelli-distillati-off-grid-quando-l-ia-locale-ha-davvero-senso-in-azienda) Pubblicato: 2026-08-07 · Autore: Redazione Lympha · Categorie: IA & Dati · Tag: RAG, on-premise, IA locale, modelli distillati, quantizzazione, Ollama, edge > La domanda dei clienti è cambiata di segno: non più «possiamo usare l'IA generativa?», ma «possiamo elaborare questi documenti senza che escano dal nostro perimetro?». Oggi la risposta è sì — per una classe precisa di casi d'uso. In questo articolo - Distillazione e quantizzazione, senza mitologia - Lo stack minimo, e cosa manca quasi sempre - Tre scenari in cui il locale funziona davvero - Dove il locale non conviene - Dimensionare l'hardware: regole pratiche - Tre domande per decidere (e l'architettura che ne esce) - Un percorso di adozione in 90 giorni - In sintesi ← Tutti gli articoli Negli ultimi diciotto mesi la domanda più frequente dei clienti enterprise è cambiata di segno. Non è più «possiamo usare l'IA generativa?», ma una versione molto più specifica: «possiamo elaborare questi documenti senza che escano dal nostro perimetro?». È una domanda legittima e oggi ha una risposta tecnicamente solida per una parte significativa dei casi d'uso. L'hanno resa possibile tre fattori insieme: modelli compatti finalmente utili, un tooling maturato al punto da essere gestibile da un team IT ordinario, e una pressione normativa crescente (GDPR, AI Act, NIS2, requisiti settoriali su sanità e finanza) che rende il confine del dato un tema di governance, non di preferenza tecnica. Questo articolo prova a distinguere il segnale dal rumore. Distillazione e quantizzazione, senza mitologia L'accessibilità dei modelli locali poggia su due tecniche distinte, spesso confuse. La distillazione addestra un modello «studente» compatto a riprodurre il comportamento di un modello «insegnante» molto più grande: non è una compressione senza perdite, è un trasferimento selettivo di competenza. Il risultato si comporta molto meglio di quanto la dimensione suggerirebbe — ma resta un modello da 3–8 miliardi di parametri. La quantizzazione riduce invece la precisione numerica dei pesi, tipicamente da 16 a 4–5 bit (formati come GGUF): l'occupazione di memoria cala di circa quattro volte, con una perdita marginale nella maggior parte dei task applicativi. Dal modello frontier all'esecuzione locale Schema animato in quattro fasi: un modello insegnante da circa 70 miliardi di parametri; la distillazione in un modello compatto da 3 a 8 miliardi di parametri; la quantizzazione da 16 a 4 bit per peso, con circa quattro volte meno memoria; l'esecuzione su laptop o server interno, con i documenti che restano dentro il perimetro aziendale. Dal Data Center alla scrivania Come un modello frontier diventa eseguibile in locale, senza far uscire il dato dal perimetro 1 · Modello insegnante Modello frontier da decine di miliardi di parametri. Prestazioni elevate, ma eseguibile solo in data center. 2 · Distillazione Un modello compatto impara a riprodurre il comportamento dell'insegnante sui task che servono davvero. 3 · Quantizzazione La precisione dei pesi scende da 16 a 4 bit (GGUF): circa quattro volte meno memoria richiesta. 4 · Esecuzione locale Il modello gira su laptop o server interno. I documenti non lasciano il perimetro aziendale. ≈ 70B parametri · FP16 · ~140 GB 3–8B parametri · stessi task, meno peso FP16 — 16 bit per peso 4 bit per peso (GGUF) ≈ 4× meno memoria occupata Perimetro aziendale documenti locali · indicizzazione RAG La pipeline in quattro fasi: modello insegnante, distillazione, quantizzazione a 4 bit, esecuzione nel perimetro. L'animazione rispetta «riduci animazioni». Clic per ingrandire. Chiudi Il punto che raramente viene detto è che il degrado non è uniforme. I task ristretti e verificabili — estrazione di entità, classificazione, riassunto estrattivo, normalizzazione di dati — reggono molto bene; il ragionamento lungo multi-passaggio e l'analisi su contesti molto ampi degradano in modo netto. La conseguenza progettuale è semplice: si progetta per il task, non per il benchmark. Un modello da 7B che risolve bene tre casi d'uso definiti vale più di un generalista che ne risolve venti in modo mediocre. Lo stack minimo, e cosa manca quasi sempre Il runtime. Ollama si è imposto come standard di fatto per l'esecuzione locale: gestisce download, versioni ed esposizione dei modelli via API, con un'esperienza che ricorda Docker: eccellente per il singolo utente e per i pilota; per scenari server multi-utente conviene valutare fin da subito runtime orientati al throughput come vLLM, perché in produzione il collo di bottiglia non è la memoria ma le richieste concorrenti. Il contesto. Un modello locale, da solo, non conosce l'azienda: serve un livello di retrieval che indicizzi documenti, wiki e ticket e passi al modello i frammenti pertinenti. Implementazioni leggere come LightRAG rendono questo strato accessibile senza infrastruttura pesante. E vale la pena essere espliciti: in gran parte dei progetti documentali la qualità dipende più dal retrieval che dal modello — ne abbiamo scritto in dettaglio, ed è la stessa lezione che ci ha insegnato la nostra piattaforma, costruita proprio su questi componenti: Ollama, vLLM, LightRAG. L'adattamento. Strumenti come Unsloth hanno reso il fine-tuning con tecniche LoRA/QLoRA praticabile su hardware modesto. Il consiglio operativo, però, è considerarlo la terza opzione, non la prima: prima il prompt, poi il retrieval, e solo se entrambi falliscono in modo misurabile si introduce un artefatto da versionare e rimettere alla prova a ogni cambio di modello base. Quello che manca nei tutorial. Tra un proof of concept e un sistema aziendale c'è uno strato che nelle guide non compare: identità e permessi (l'indice deve rispettare i permessi dell'utente), logging, valutazione continua della qualità, processo di aggiornamento dei modelli. È qui che si concentra la maggior parte del costo reale. Tre scenari in cui il locale funziona davvero 1 · Pre-triage documentale su dati riservati. Contratti, fascicoli HR, documentazione clinica, pratiche assicurative. Il modello non decide: estrae, classifica, evidenzia clausole anomale e prepara il lavoro a un revisore umano. Il valore è nel tempo di lettura risparmiato; il rischio è contenuto perché l'output è sempre verificato. 2 · Ricerca semantica sul patrimonio interno. Verbali, documentazione tecnica, storico ticket: recupero in linguaggio naturale su archivi che nessuno riesce più a navigare per cartelle. Anche qui il grosso lo fa il retrieval; il modello sintetizza. 3 · Assistenza allo sviluppo in ambienti isolati. Difesa, infrastrutture critiche, ambienti certificati: il codice proprietario non lascia il repository e spesso la rete verso l'esterno semplicemente non esiste. Qui il locale non è un'ottimizzazione — è l'unica opzione. Si aggiunge un quarto scenario in crescita: l'operatività su edge — cantieri, impianti, siti remoti — dove la connettività è intermittente e l'affidabilità conta più della qualità marginale della risposta. Dove il locale non conviene L'onestà su questo punto distingue una valutazione tecnica da una campagna di marketing. Il ragionamento esteso — analisi comparative complesse, sintesi su decine di documenti eterogenei, testo di qualità editoriale — resta territorio dei modelli frontier, e il divario non si colma con la quantizzazione. I carichi multi-utente non dimensionati: un modello che risponde in due secondi sul laptop può impiegarne venti con dieci richieste concorrenti; si dimensiona sul throughput, non sulla memoria. E il costo totale nascosto: un modello locale non aggiornato è debito tecnico — servono rivalutazioni periodiche, test di regressione e qualcuno che se ne occupi. Sotto una certa soglia di volume, l'API resta largamente più economica della gestione interna. Dimensionare l'hardware: regole pratiche - Regola empirica: per un modello quantizzato a 4 bit, i GB di memoria necessari sono circa i miliardi di parametri × 0,6 — più lo spazio per la finestra di contesto. - Apple Silicon: la memoria unificata aiuta — con 16 GB si gestiscono modelli 7–8B, con 32–64 GB si sale a 14–32B. - GPU dedicata: 8–12 GB di VRAM coprono bene la fascia 7–8B a velocità interattiva. - Solo CPU: adatta alle elaborazioni batch notturne, molto meno all'interazione sincrona. - Server condiviso: una GPU da 24–48 GB serve una decina di utenti concorrenti su modelli 7–8B. Oltre le venti persone è quasi sempre più efficiente — anche gestionalmente — dell'installazione su ogni endpoint. Tre domande per decidere (e l'architettura che ne esce) Tre domande, in quest'ordine: il dato può uscire dal perimetro? (domanda organizzativa prima che tecnica); il task è ristretto e verificabile? (se non si sa dire cosa sia una risposta corretta, nessuna infrastruttura salverà il progetto); il volume giustifica l'infrastruttura? (sotto certe soglie l'API è la scelta razionale). Nella maggior parte dei casi la risposta non è binaria, e l'architettura più sensata è ibrida: un livello di routing che indirizza le richieste sui dati riservati verso il modello locale — nel perimetro dedicato — e tutto il resto verso il cloud, con policy esplicite e tracciabili. La sovranità sul dato diventa una proprietà del sistema, non una rinuncia funzionale. L'architettura ibrida: il router di policy Un router di policy legge la classificazione del dato: se riservato, la richiesta va al modello locale nel perimetro aziendale; altrimenti ai servizi cloud, con policy esplicite e tracciabili. Richiesta + il suo dato Router di policy classificazione del dato, regole esplicite e tracciabili riservato non riservato Perimetro aziendale Modello locale i dati riservati restano qui Servizi cloud dati non riservati L'architettura ibrida: il router di policy tiene i dati riservati sul modello locale, nel perimetro; il resto va al cloud. Clic per ingrandire. Chiudi Un percorso di adozione in 90 giorni Settimane 1–3 · Perimetro. Classificazione dei dati e selezione di due casi d'uso reali, ciascuno con un referente di business. Settimane 4–8 · Prova sul campo. Prototipo funzionante e, soprattutto, un set di valutazione: 30–50 casi reali con la risposta attesa — l'investimento più sottovalutato, quello che distingue una misura di successo da un'impressione. Settimane 9–12 · Pilota. Rilascio a 10–20 utenti, metriche, decisione documentata: estendere, correggere o fermarsi. In sintesi L'IA locale non sostituisce il cloud e non è una risposta universale. Risolve in modo elegante una classe di problemi ben definita: il dato non può muoversi, il task è circoscritto, la verificabilità conta più della brillantezza. Per quella classe — che nelle organizzazioni regolamentate è tutt'altro che marginale — la tecnologia è matura, gira su hardware spesso già in azienda e si valuta in un trimestre con un investimento contenuto. Il resto, come sempre, è una questione di architettura: se volete impostarla con un minimo di serietà, parliamone. ### [Data center d'interesse strategico: cosa c'è davvero dietro gli 8 miliardi per Milano e Trino](https://www.lymphatechnologies.com/it/data-center-d-interesse-strategico-cosa-c-e-davvero-dietro-gli-8-miliardi-per-milano-e-trino) Pubblicato: 2026-07-29 · Autore: Redazione Lympha · Categorie: Governance · Tag: data center, sovranità digitale, interesse strategico, Decreto Asset, Equinox, Cavour Hyperscale Campus > Il 24 luglio il Governo ha dichiarato di «preminente interesse strategico nazionale» due programmi di data center da 8 miliardi di euro complessivi, a Milano e a Trino (Vercelli). In questo articolo - Cosa significa «interesse strategico nazionale» - Il contesto: un Paese piccolo che accelera - Il primo programma: «Equinix per l'Italia» - Il secondo programma: il «Cavour Hyperscale Campus» di Trino - Tre riserve oneste - Sovranità è controllo, non solo geografia ← Tutti gli articoli Il 24 luglio 2026 il Consiglio dei Ministri ha fatto una cosa che in Italia non era mai stata fatta per questo settore: ha dichiarato due programmi di data center «di preminente interesse strategico nazionale». Non è una formula di cortesia — è un atto amministrativo, previsto dall'articolo 13 del cosiddetto Decreto Asset, che cambia le regole del gioco per due progetti da circa 4 miliardi di euro ciascuno: sette nuovi data center nell'area milanese e un campus hyperscale nel vercellese. Vale la pena capire bene cosa è successo, perché tocca un tema di cui ci siamo già occupati: la sovranità digitale europea — e la differenza, tutt'altro che teorica, tra annunciare un'infrastruttura e accenderla. Cosa significa «interesse strategico nazionale» In pratica, la dichiarazione attiva una corsia amministrativa dedicata: per ciascun programma verrà nominato, d'intesa con le Regioni interessate, un commissario straordinario di Governo con il compito di coordinare le amministrazioni coinvolte, accelerare il rilascio dell'autorizzazione unica e seguire l'attuazione degli interventi. Perché serve un commissario per costruire un edificio pieno di server? Perché il vero collo di bottiglia dei data center in Italia non è il capitale, e nemmeno la tecnologia: sono i tempi autorizzativi e gli allacciamenti alla rete elettrica in alta e altissima tensione. Un progetto da centinaia di megawatt attraversa conferenze di servizi, valutazioni ambientali e interlocuzioni con il gestore di rete che possono durare anni — e in un mercato dove la domanda di capacità di calcolo cresce alla velocità dell'IA generativa, anni di attesa possono rendere un progetto obsoleto prima del primo scavo. Il contesto: un Paese piccolo che accelera I numeri dell'Osservatorio Data Center del Politecnico di Milano danno la misura del punto di partenza. L'Italia dispone oggi di circa 600 MW di potenza operativa — una frazione modesta della capacità europea. L'area metropolitana di Milano da sola concentra il 68% della potenza nazionale (414 MW) e, secondo le stime dell'Osservatorio, supererà il gigawatt entro il 2028. Il movimento però è forte: dopo circa 7 miliardi di euro investiti nel triennio 2023-2025, gli annunci per il periodo 2026-2028 superano i 25 miliardi, distribuiti su 83 siti riconducibili a una trentina di operatori — di cui 19 nuovi entranti sul mercato italiano. Sempre secondo l'Osservatorio, Milano potrebbe attrarre da sola quasi un quarto degli investimenti attesi nei 13 principali hub europei. Il primo programma: «Equinix per l'Italia» Il programma milanese prevede sette nuovi data center nei comuni di Settimo Milanese e Cusago, realizzati tra il 2026 e il 2033 con un investimento di 4 miliardi: strutture per colocation, connettività e carichi hyperscale ad alta intensità computazionale — il profilo tipico dei carichi IA. - Energia: fabbisogno coperto al 100% da fonti rinnovabili. - Recupero del calore: grazie a una partnership con A2A, il calore di scarto dei server di Settimo Milanese sarà immesso nella rete di teleriscaldamento milanese — fino a 225 GWh termici l'anno, sufficienti a scaldare oltre 21.000 abitazioni. È lo stesso principio di economia circolare che rende un data center un asset energetico del territorio, non solo un consumatore. - Occupazione: circa 1.500 addetti in fase di realizzazione, oltre 500 posti diretti e indiretti a regime. Il secondo programma: il «Cavour Hyperscale Campus» di Trino Il progetto piemontese è un caso da manuale di riconversione industriale: nell'area della ex centrale termoelettrica «Galileo Ferraris» di Trino (Vercelli), ferma dal 2013, nascerà un campus da 300-400 MW. La scelta del sito non è casuale — è un brownfield con due doti rare: - una sottostazione elettrica a 380 kV già collegata alla rete di trasmissione nazionale, eredità della centrale; - l'adiacenza a uno dei più grandi parchi fotovoltaici del Nord Italia, l'impianto Enel Green Power da 87,5 MW con circa 160.000 pannelli bifacciali, affiancato da un sistema di accumulo a batterie. Il cronoprogramma dichiarato è serrato: conferenza di servizi entro fine 2026, autorizzazione unica entro fine 2027, primo lotto operativo entro fine 2028. Sul fronte occupazionale si parla di circa 1.200 lavoratori medi in fase di costruzione (con picchi oltre i 2.000), 300-350 posti qualificati a regime e circa un migliaio nell'indotto. Tre riserve oneste L'ambizione è fondata, ma chi lavora sulle infrastrutture sa che tra il comunicato stampa e il primo rack acceso passa un mondo. Tre cose da tenere a mente: - Il divario tra annunci e cantieri. Nel triennio 2023-2025, a fronte di 10,5 miliardi di investimenti annunciati, se ne sono concretizzati 7,1: il 68%. I ritardi — rileva l'Osservatorio — si sono concentrati soprattutto sui nuovi operatori internazionali, che hanno sottovalutato la complessità autorizzativa italiana. È esattamente il problema che i commissari dovrebbero risolvere: la prova sarà nei fatti. - La concentrazione geografica. Milano assorbe già due terzi della potenza nazionale, ed entrambi i programmi strategici stanno nel quadrante nord-ovest. Un'infrastruttura nazionale resiliente ha bisogno anche di capacità diffusa — vicina ai distretti produttivi e alle amministrazioni che la usano. - La rete elettrica. Ogni nuovo campus da centinaia di megawatt è un carico che la rete di trasmissione deve poter servire, insieme agli altri 80 progetti annunciati. Senza un potenziamento coordinato della rete, i server restano spenti — e non è un rischio teorico: è già oggi la prima causa dei ritardi. Sovranità è controllo, non solo geografia Nell'articolo sulla sovranità digitale scrivevamo che un data center in Europa non basta: conta chi lo controlla, con quali standard, con quale via d'uscita. Questi due programmi vanno nella direzione giusta — capacità fisica sul territorio, energia rinnovabile, recupero di siti industriali — e per una volta l'Italia gioca d'anticipo invece di rincorrere. Ma per la maggior parte delle organizzazioni italiane la sovranità non si eserciterà affittando un piano di un campus hyperscale: si esercita sapendo dove sono i propri dati, chi li amministra e con quali garanzie. È il mestiere del private cloud in un perimetro dedicato e della progettazione di infrastrutture su misura — dove i megawatt si contano sulle dita, ma il controllo è totale. Il nostro data center a emissioni zero dimostra da anni che efficienza e sostenibilità non sono un privilegio degli hyperscaler. Se il tema vi riguarda, parliamone. Fonti e riferimenti: Ministero delle Imprese e del Made in Italy, comunicato «Data Center: ok Cdm a strategicità per due investimenti in Lombardia e Piemonte per 8 mld» (24 luglio 2026); Osservatorio Data Center, Politecnico di Milano — School of Management (comunicato «Data Center: già investiti 7 miliardi nel triennio 2023-2025, ulteriori 25 previsti nel prossimo triennio», gennaio 2026); MilanoFinanza, «Data center, in Italia investimenti annunciati per 10,5 miliardi nel 2023-2025. Ma realizzati solo per 7,1 miliardi» (gennaio 2026). I dati sui singoli programmi provengono dal comunicato governativo e dalla stampa di settore alla data di pubblicazione. ### [Quanti data center ci sono in Italia? La mappa di un mercato che cambia pelle](https://www.lymphatechnologies.com/it/quanti-data-center-ci-sono-in-italia-la-mappa-di-un-mercato-che-cambia-pelle) Pubblicato: 2026-07-27 · Autore: Redazione Lympha · Categorie: Data Center & Green IT · Tag: PSN, mercato, Italia, hyperscale, edge computing, data center, colocation > Circa 250 impianti censiti, 600 MW di potenza operativa, una sola area metropolitana che concentra i due terzi di tutto. Ma la fotografia del mercato italiano dei data center dice più delle cifre: chi costruisce, chi paga, quali progetti si faranno davver In questo articolo - Quanti sono davvero - La geografia: Milano, e poi il resto - Chi muove il mercato: tre famiglie di operatori - L'economia del mattone digitale - Gigafactory o rete diffusa? Probabilmente entrambe - E per un'azienda «normale», cosa cambia? ← Tutti gli articoli Dietro ogni ricerca, ogni videoconferenza e ogni risposta di un modello di intelligenza artificiale c'è un'infrastruttura fisica che non si vede quasi mai: il data center. In Italia se ne parla molto — anche per la recente dichiarazione di interesse strategico sui programmi da 8 miliardi — ma spesso senza una fotografia d'insieme. Proviamo a scattarla: quanti sono, dove sono, chi li gestisce e quali forze stanno ridisegnando il mercato. Quanti sono davvero Secondo la mappatura di Data Center Map, alla data di pubblicazione l'Italia conta circa 250 impianti: intorno a 190 operativi, una ventina in costruzione e oltre 30 pianificati. La potenza operativa nazionale è di circa 600 MW (dati Osservatorio Data Center del Politecnico di Milano) — per dare un termine di paragone, una frazione a una cifra della capacità europea complessiva. Un'avvertenza onesta sui numeri: i censimenti differiscono tra loro (cosa conta come «impianto»? un campus con quattro edifici è uno o quattro?), e i progetti «pianificati» dichiarano spesso potenze obiettivo notevoli — da 50 fino a 120-240 MW IT per singolo campus. Dietro molti di questi annunci ci sono attese per le autorizzazioni e, soprattutto, per l' allaccio alla rete elettrica in alta tensione: come abbiamo raccontato nell'analisi sui programmi strategici, nel triennio scorso quasi un terzo degli investimenti annunciati non si è concretizzato. La mappa, insomma, va letta con la matita: ciò che è acceso è certo, ciò che è annunciato è un'ipotesi. La geografia: Milano, e poi il resto Nessuna sorpresa sul baricentro: la Lombardia, e in particolare l'area metropolitana di Milano, concentra il 68% della potenza nazionale (414 MW), in rotta verso il gigawatt entro il 2028. Le ragioni sono strutturali — la densità di interconnessioni e punti di scambio Internet, la prossimità ai mercati europei, la disponibilità (contesa) di energia e aree. Ma il paradigma si sta allargando: cresce l'interesse per siti di secondo livello, più vicini ai distretti industriali e alle amministrazioni locali. Le ragioni sono buone: ridurre la latenza per gli usi che la sentono davvero, decongestionare la rete, e rendere l'infrastruttura nazionale più resiliente di quanto possa esserlo un sistema con un solo, enorme baricentro. Chi muove il mercato: tre famiglie di operatori Semplificando un panorama affollato, gli attori si dividono in tre famiglie con ruoli diversi: - La colocation «neutrale» — operatori che affittano spazio, energia e connettività restando indipendenti dai carrier: player nazionali storici (Aruba, Retelit), piattaforme europee e globali (Data4, Digital Realty, Equinix, OVHcloud) e una generazione di nuovi entranti che punta proprio sulle città di secondo livello. È la spina dorsale del mercato «visibile». - Le telco — TIM Enterprise su tutte, con Wind Tre e, sul fronte abilitante della connettività, Open Fiber: infrastrutture nate per le telecomunicazioni che restano un presidio capillare sul territorio. - Gli sviluppatori per gli hyperscaler — la famiglia meno nota e oggi più dinamica. I giganti del cloud (AWS, Google, Microsoft, Oracle) raramente costruiscono in prima persona: si affidano a operatori specializzati che realizzano campus su misura nell'hinterland milanese e pavese — nomi come CloudHQ, CyrusOne, Stack, Vantage, Virtus. Il modello si chiama anchor tenancy: si costruisce solo con un contratto pluriennale già firmato dal grande inquilino. L'economia del mattone digitale Perché l' anchor tenancy? Perché i numeri in gioco non ammettono scommesse. Le stime di settore collocano l'investimento infrastrutturale di base — edificio, alimentazione, raffreddamento — tra 12 e 14 milioni di euro per MW IT installato. E per i campus destinati all'IA c'è un moltiplicatore che sorprende chi ragiona in termini immobiliari: l'hardware che va dentro l'edificio (GPU e acceleratori) può costare diverse volte l'investimento edilizio — con l'aggravante che il suo ciclo di vita utile si misura in 2-3 anni, contro i decenni dell'involucro. Messi insieme, questi due fatti spiegano quasi tutto il comportamento del mercato: un campus da centinaia di MW «a pieno carico» di hardware IA rappresenta un impegno finanziario dell'ordine delle decine di miliardi, che si ripresenta a ogni ciclo di refresh. Nessun investitore muove cifre simili senza contratti blindati — ed ecco perché gli annunci si concretizzano solo quando c'è già un inquilino àncora, e perché il divario tra «pianificato» e «operativo» resta così ampio. Gigafactory o rete diffusa? Probabilmente entrambe La traiettoria più credibile per l'Italia non è un aut-aut, ma un bilanciamento: - da un lato pochi grandi campus ottimizzati per l'IA — raffreddamento a liquido, densità elevate, PUE spinto verso l'unità; - dall'altro una capacità diffusa ed «edge», federata con il Polo Strategico Nazionale per i dati della PA: è il modello che serve alla Pubblica Amministrazione e alle imprese critiche per tenere i dati in un perimetro noto, riducendo la dipendenza da attori extra-UE. È la stessa tesi della federazione dei provider piccoli e medi: la sovranità non abita solo nei gigawatt, abita nella struttura del mercato. E per un'azienda «normale», cosa cambia? Quasi nulla di ciò che precede riguarda direttamente la maggior parte delle organizzazioni italiane: i loro carichi non sono hyperscale e non lo diventeranno. Per loro le domande giuste sono più semplici e più concrete: dove sono i miei dati? chi amministra l'infrastruttura? quanto è efficiente, e chi risponde quando qualcosa si ferma? È il terreno su cui lavoriamo ogni giorno: un private cloud su infrastruttura dedicata in un data center che conosciamo rack per rack, la progettazione di sale dati su misura e un metodo di valutazione della maturità — il DCMM — che non richiede di essere un hyperscaler per fare le cose bene. Il nostro data center a emissioni zero è la prova in scala che efficienza e controllo non dipendono dalle dimensioni. Se state ragionando su dove far vivere la vostra infrastruttura, parliamone. Fonti e riferimenti: Data Center Map (mappatura Italia, luglio 2026); Osservatorio Data Center, Politecnico di Milano — School of Management (comunicati gennaio 2026); MilanoFinanza su dati Osservatorio (investimenti annunciati vs realizzati 2023-2025). Le stime di costo per MW e sul ciclo di vita dell'hardware IA riflettono valori correnti di settore e vanno intese come ordini di grandezza. ### [AI Act: cosa scatta davvero il 2 agosto 2026 (e perché ti riguarda anche se non «fai IA»)](https://www.lymphatechnologies.com/it/ai-act-2-agosto-2026) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Governance · Tag: AI Act, compliance, trasparenza, chatbot, GenAI, governance IT, Digital Omnibus > Hai letto ovunque che «l'AI Act è stato rinviato al 2027» e ti sei rilassato. Male: è slittato solo l'alto rischio. Il 2 agosto arrivano trasparenza, sanzioni e autorità operative — e riguardano chiunque abbia un chatbot sul sito o pubblichi contenu… In questo articolo - Il rinvio, tecnicamente, non è ancora legge - Il calendario, a strati - Il quadro in una tabella - Cosa fare prima di agosto (non «entro il 2027») - Cinque cose che senti dire e sono sbagliate - Le domande che ci sentiamo fare - Avvertenza (e da dove cominciare) ← Tutti gli articoli Aggiornato al 12 luglio 2026 — su questo dossier due settimane cambiano il quadro: controlla la data prima di fidarti, e per le decisioni fai fede solo a EUR-Lex. Hai letto ovunque che «l'AI Act è stato rinviato al 2027». Ti sei rilassato. Male. Quello che è slittato è una parte: gli obblighi sui sistemi ad alto rischio. Tutto il resto corre, e il 2 agosto 2026 — tra tre settimane — porta in dote la cosa che ti tocca davvero se hai un chatbot sul sito, generi contenuti con l'IA o hai integrato un modello dentro un prodotto: l'articolo 50, la trasparenza. E c'è un dettaglio ancora più scomodo, che quasi nessuno scrive. Il rinvio, tecnicamente, non è ancora legge Ricostruiamo, perché qui i dettagli procedurali contano: Quando · Cosa 19 nov 2025 · La Commissione propone il «Digital Omnibus» sull'IA (COM/2025/836) 7 mag 2026 · Accordo provvisorio in trilogo 16 giu 2026 · Il Parlamento europeo approva 29 giu 2026 · Il Consiglio UE adotta formalmente oggi · Mancano firma e pubblicazione in Gazzetta ufficiale UE Il regolamento modificativo entra in vigore tre giorni dopo la pubblicazione in Gazzetta. Fino a quel momento si applica l'AI Act nella versione 2024, con il calendario originario. Traduzione per chi deve decidere: Chi oggi pianifica soltanto sulle nuove date sta ragionando su un testo definito ma non ancora vigente. La pubblicazione è attesa entro luglio, proprio per arrivare prima del 2 agosto: è un'aspettativa fondata, non una certezza giuridica. Il calendario, a strati L'errore mentale più comune è trattare l'AI Act come un blocco unico che si sposta. Non lo è: è un mosaico, e ogni tessera ha la sua data. Già in vigore (dal 2025) I divieti — social scoring, manipolazione subliminale, sfruttamento di vulnerabilità — sono operativi da oltre un anno, zero rinvii. E c'è l'obbligo più ignorato d'Europa: l'AI literacy — chi usa sistemi IA deve capirne funzionamento e limiti, e sapere quando serve l'occhio umano. È anche il più economico da chiudere: un piano di formazione documentato si mette in piedi in settimane, e il Digital Omnibus lo conferma. Dal 2025 sono in vigore anche gli obblighi per chi pubblica modelli di uso generale; in Italia la vigilanza su questi è in capo all'ACN (Legge 132/2025 — l'assetto delle competenze nazionali è però materia in movimento: da verificare con un legale). 2 agosto 2026 — la data che conta ora Il rinvio non tocca niente di quanto segue. L'articolo 50 impone tre obblighi distinti, che spesso vengono confusi in uno: - I sistemi che interagiscono con le persone devono dichiararsi come IA. Il chatbot di customer care deve dire che è un chatbot. Non «tanto si capisce»: deve dirlo. - I contenuti sintetici devono essere marcati in modo leggibile dalla macchina — testo, immagini, audio, video, con metadati di provenienza su formati aperti (in pratica: C2PA / Content Credentials). L'obbligo grava sul fornitore del sistema generativo. - Deepfake e testi di interesse pubblico vanno segnalati in modo visibile all'utente. Questo grava sul deployer, cioè su chi pubblica. Chi si deve svegliare adesso, in ordine di urgenza: chi ha un chatbot o un assistente conversazionale in produzione; gli e-commerce che generano descrizioni prodotto con un modello; agenzie, editori e media che pubblicano contenuti generati o manipolati; chi rivende un prodotto che incorpora un modello generativo. Non è un tema da big tech: è un tema da chiunque abbia messo un LLM in un flusso rivolto al pubblico. Sempre dal 2 agosto: le autorità nazionali di vigilanza diventano pienamente operative e la gran parte delle norme sanzionatorie diventa applicabile. Finora l'AI Act era, per molti, un esercizio accademico; da agosto ha qualcuno che bussa. E vale la regola generale: ciò che non è espressamente rinviato, si applica. 2 dicembre 2026 — il dettaglio che quasi nessuno scrive I sistemi generativi già sul mercato prima del 2 agosto 2026 hanno quattro mesi extra per adeguarsi alla marcatura dei contenuti; quelli lanciati dopo devono nascere conformi. La conseguenza operativa che sfugge a tutti: Serve sapere la data di messa in produzione di ogni sistema, perché è quella a determinare quale scadenza si applica. Se l'inventario IA non traccia il «quando è andato in produzione», non sei nemmeno in grado di dire a quale regime appartieni. Stessa data per l'unico punto in cui l'Omnibus stringe: due nuovi divieti, sulle app di «nudificazione» (immagini intime non consensuali di persone identificabili) e sul materiale di abuso su minori — con responsabilità del fornitore anche quando l'output è ragionevolmente prevedibile in assenza di salvaguardie tecniche. Per chi costruisce strumenti di generazione immagini è un requisito di progettazione, non una riga di policy. 2027–2028 — il pezzo davvero rinviato (con una sottigliezza) Gli obblighi sull'alto rischio slittano, ma non a data fissa: è un rinvio condizionato. Scattano 6 o 12 mesi dopo che la Commissione conferma con decisione formale la disponibilità degli standard tecnici; in assenza di quella decisione valgono comunque due date limite — 2 dicembre 2027 per l'alto rischio «autonomo» (selezione del personale, scoring creditizio, servizi pubblici, istruzione, infrastrutture critiche) e 2 agosto 2028 per quello integrato in prodotti già regolati (per esempio i dispositivi medici). Il motivo del rinvio è che gli standard europei sono in ritardo. Ma il cronometro può ripartire prima del previsto: non è un condono, è una pausa con la sveglia già puntata. Slittano di un anno anche le sandbox normative nazionali — il punto più criticabile del pacchetto, perché servivano proprio alle PMI. Il quadro in una tabella Data · Cosa · Rinviato? 2 feb 2025 · Divieti · AI literacy · già in vigore 2 ago 2025 · Modelli di uso generale · governance · già in vigore 2 ago 2026 · Trasparenza (art. 50) · sanzioni · autorità · NO — conta ora 2 dic 2026 · Marcatura per i sistemi pre-esistenti · nuovi divieti · nuovo termine 2 ago 2027 · Sandbox normative nazionali · sì (+12 mesi) 2 dic 2027 · Alto rischio «autonomo» · sì, condizionato 2 ago 2028 · Alto rischio integrato in prodotti regolati · sì, condizionato Cosa fare prima di agosto (non «entro il 2027») - 1 · Inventario dei sistemi IA. Un foglio o un database: per ogni sistema in uso, in sviluppo o in acquisto — fornitore, finalità, ruolo (fornitore o utilizzatore), data di messa in produzione, dati trattati, classe di rischio. Non dipende dagli standard, non dipende dalla Gazzetta: si fa oggi, ed è il prerequisito di tutto il resto. - 2 · Classificazione. Vietato / alto rischio / trasparenza / minimo. Attenzione al punto cieco: l'IA usata per screening dei CV, valutazione delle performance, assegnazione dei task, monitoraggio dei lavoratori è alto rischio. Molte aziende ce l'hanno dentro gli strumenti HR e non lo sanno. - 3 · Trasparenza — l'unica con scadenza reale a tre settimane. Il chatbot si dichiara come IA? (È una riga di testo nel primo messaggio, non un progetto.) I contenuti generati sono marcati? I deepfake sono segnalati in modo visibile? - 4 · AI literacy. Piano di formazione documentato: obbligo già vigente, costo basso, prova di diligenza alta. - 5 · Non aspettare gli standard per partire sull'alto rischio. Un percorso completo di conformità richiede mediamente 8–14 mesi, con gli organismi di certificazione già in coda. Il rinvio ridistribuisce il lavoro nel tempo, non ne riduce il perimetro. Il primo e il secondo punto, si noti, non sono diritto: sono governo dell'IT — censire, classificare, assegnare responsabilità, misurare. Chi ha già una CMDB e processi ordinati parte con metà del lavoro fatto. Cinque cose che senti dire e sono sbagliate - «L'AI Act è stato rinviato.» No: è stato rinviato l'alto rischio. Il resto corre. - «Il rinvio è già legge.» Non ancora, alla data in cui scriviamo: manca la pubblicazione in Gazzetta. - «Riguarda chi sviluppa IA.» No: la gran parte degli obblighi colpisce chi usa modelli altrui. - «È roba da big tech.» L'articolo 50 riguarda chiunque abbia un chatbot o pubblichi output generato. - «Aspetto gli standard e poi mi muovo.» Inventario e classificazione non dipendono dagli standard. E il rinvio è condizionato: appena la Commissione conferma, parte un conto alla rovescia di sei mesi. Le domande che ci sentiamo fare Usiamo ChatGPT o Copilot in azienda: siamo «fornitori»?No, siete utilizzatori (deployer). Gli obblighi sono più leggeri, ma esistono: AI literacy, trasparenza verso gli interessati, uso conforme alle istruzioni del fornitore, divieto di impieghi vietati. Il nostro chatbot di supporto è «alto rischio»?In genere no: è rischio limitato, con obbligo di trasparenza (deve dichiararsi). Diventa alto rischio se decide l'accesso a servizi essenziali o valuta le persone. Se un articolo è scritto con l'aiuto dell'IA va dichiarato?La disclosure dell'articolo 50 colpisce l'uso professionale, per deepfake e contenuti di interesse pubblico; l'uso personale non professionale è generalmente escluso. Ma quando il contenuto viene monetizzato o serve a informare il pubblico, la soglia «personale» cade. È una zona grigia: qui serve un legale, non un blog. La marcatura dei contenuti (watermarking) funziona davvero?Onestamente: è un problema aperto. Un watermark che si rompe con un ritaglio o una ricompressione non protegge nessuno, e la robustezza delle tecniche attuali non è risolta. La norma impone la marcatura; la tecnologia per renderla affidabile è in corso d'opera. Meglio saperlo prima di vendere garanzie che non si possono mantenere. Avvertenza (e da dove cominciare) Questo è un pezzo divulgativo, non un parere legale: il quadro è in movimento e, alla data di scrittura, la pubblicazione in Gazzetta del regolamento modificativo non era ancora avvenuta. Per le decisioni di conformità fanno fede EUR-Lex e un professionista abilitato. Quello che possiamo dire dal nostro mestiere è che la parte urgente non richiede avvocati: richiede un inventario fatto bene e un chatbot che si presenta per quello che è. Sono i temi su cui lavoriamo ogni giorno — nel governo dell'IT, nella costruzione di assistenti IA con fonti verificabili nel perimetro del cliente, e nella verifica delle salvaguardie tecniche, penetration test degli agenti conversazionali compreso. Se vuoi capire da dove cominciare nelle tre settimane che restano, parliamone. Fonti. - Regolamento (UE) 2024/1689 (AI Act) — l'unica fonte che fa fede è EUR-Lex. - «Digital Omnibus» sull'IA — proposta COM/2025/836, procedura 2025/0359(COD); adozione formale del Consiglio UE, 29 giugno 2026. - Analisi consultate: Gibson Dunn, NicFab, Studio Legale Stefanelli & Stefanelli, Altalex, Agenda Digitale, Federprivacy (giugno–luglio 2026). - Sulla marcatura dei contenuti: Coalition for Content Provenance and Authenticity (C2PA); standard CEN-CENELEC JTC21 in corso di sviluppo. ### [Che cos'è e come funziona un server proxy](https://www.lymphatechnologies.com/it/server-proxy-panoramica) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Guide pratiche · Tag: reverse proxy, VPN, rete, proxy, sicurezza, privacy > Filtra, velocizza, protegge, maschera — ma vede tutto il tuo traffico. Come funziona un server proxy, a cosa serve davvero (dal transparent al reverse), e quando conviene affiancargli una VPN. In questo articolo - Come si svolge il lavoro del proxy - Le tre tipologie principali - Rischi o solo benefici? - Un sistema più sicuro ← Tutti gli articoli Un server proxy ha la funzione di gestire il traffico internet in ingresso o in uscita da una rete privata. Anche se apparentemente la funzione è unica, in realtà sottende moltissimi utilizzi: - filtra la navigazione: ad esempio può bloccare a un utente aziendale la possibilità di navigare su siti non pertinenti al proprio lavoro; - velocizza la navigazione: grazie a un sistema di cache può rendere molto più rapida la navigazione sulle pagine più frequentemente richiamate da un gruppo di utenti; - aumenta il livello di sicurezza del dispositivo con cui navighi: di fatto è il proxy a effettuare la connessione all'IP/porta che si desidera contattare (esempio www.sito.com sulla porta 80) — non sarà mai il tuo pc a stabilire la connessione, bensì il proxy, che poi si preoccupa di reindirizzare il risultato, in questo caso una pagina http; - si comporta come un firewall, con le sue regole specifiche di filtraggio contestuale; - aumenta la privacy di chi naviga; - permette la navigazione esclusivamente ai dispositivi autorizzati all'interno della rete locale di cui fanno parte: esempio una rete aziendale dove la navigazione dai server è inibita, salvo che verso i domini del produttore dei sistemi operativi e dell'hardware; - mascherando il tuo IP può mascherare anche la tua posizione, rendendo inutili i tentativi di geolocalizzazione dell'IP. Il suo lavoro è sostanzialmente intercettare e gestire il traffico tra dispositivi e i protocolli utilizzati. Esistono poi i reverse proxy: questi particolari server effettuano, appunto, il lavoro inverso, ovvero intercettano le richieste dei client per conto di uno o più server e, se necessario, le inoltrano ai server di destinazione (che offrono il servizio chiamato). Questo tipo di configurazione non solo impedisce a chiunque di comunicare direttamente con i server, ma migliora le prestazioni attraverso il bilanciamento di carico: è possibile infatti gestire il traffico in entrata distribuendolo tra più server che erogano lo stesso servizio, invece che concentrarlo su una sola macchina. Anche in questo caso il vantaggio è plurimo, compreso un aumentato livello di sicurezza per i server che, di fatto, non vengono esposti direttamente su internet. Come si svolge il lavoro del proxy - Step 1 — le richieste vengono inviate dal tuo indirizzo IP al server proxy; - Step 2 — il server proxy inoltra la richiesta all'esterno utilizzando il suo indirizzo IP; - Step 3 — le risposte vengono indirizzate al server proxy; - Step 4a — il server proxy inoltra i dati richiesti al tuo browser; - Step 4b — oppure il tuo browser riceve una pagina di avviso che il traffico richiesto non è permesso. Non ci sono solo vantaggi, però. Visto che il proxy è a conoscenza di tutte le tue richieste e di tutto il traffico a te destinato, automaticamente ti espone a un rischio di sicurezza e privacy. In sostanza: se non ti «fidi» del server proxy che stai utilizzando, potresti incorrere in rischi identici, se non maggiori, del non utilizzarlo affatto. Le tre tipologie principali - Transparent proxy — sostanzialmente utilizzato per fare cache di pagine ad alta frequenza di accesso, oltre che per il filtraggio di siti non graditi all'organizzazione. Questo tipo di proxy non effettua alcun mascheramento dell'IP che, di fatto, resta quello del dispositivo da cui si naviga. - Distorting proxy — fornisce un indirizzo IP falso al server web chiamato, anche se si identifica comunque come proxy. L'indirizzo IP falso garantisce l'anonimato, ma il vero vantaggio è che puoi indurre il server remoto a geolocalizzarti in una posizione fittizia. Spesso questa tipologia di proxy viene utilizzata per aggirare le restrizioni tipiche dei siti che offrono contenuti in base all'area geografica. - Anonymous proxy — mantiene l'indirizzo IP del tuo dispositivo nascosto per i siti web che visiti. Questo può aiutare a evitare i furti di identità, oltre a consentire l'esplorazione anonima; tuttavia i proxy anonimi si presentano comunque come server proxy, e alcuni siti web potrebbero non concederti l'accesso. Esiste una versione dell'anonymous proxy ad alto livello di anonimato: questa modalità aggiunge la rotazione dell'IP di uscita, così il tuo dispositivo si presenterà verso l'esterno con indirizzi IP che cambiano nel tempo. Questa seconda tipologia di proxy anonimo non si presenta all'esterno come proxy, il che garantisce la «copertura» delle tue tracce digitali, rendendola tra i tipi di server proxy più sicuri. Rischi o solo benefici? Ovviamente non esiste alcun sistema che non comporti anche dei rischi. Può capitare, ad esempio, che il server proxy non cripti il traffico web: questo punto è sicuramente fondamentale e impattante per la tua privacy, e può esporti al furto di password e altri dati sensibili. Non che sia pratica comune, ma può anche capitare che alcuni servizi open proxy gratuiti traccino e vendano le informazioni degli utenti (email, nome, cronologia della navigazione, ecc.): è quindi bene informarsi prima di utilizzare un proxy, e in generale vale sempre la prima regola della sicurezza informatica: «Non fidarsi!». Storia del tutto differente è chiaramente utilizzare un server proxy aziendale — anche se in questo caso l'azienda potrebbe tracciare le attività dell'utente per giuste ragioni di sicurezza; l'utente, tuttavia, dovrebbe essere informato di tale attività. Un sistema più sicuro Una VPN (Virtual Private Network) offre una protezione decisamente migliore. Che tu stia navigando da casa, dalla pizzeria o dall'azienda, far transitare il tuo traffico attraverso una VPN è certamente una scelta più sicura. Dal punto di vista della privacy la differenza non è poi così percettibile: se è vero che il «canale» di transito è più sicuro (traffico sempre crittografato in entrambe le direzioni), è pur vero che il gestore del server VPN deve godere della nostra fiducia — motivo per cui le VPN sono spesso utilizzate in realtà aziendali, dove è importante tenere alla larga utenti indesiderati e indesiderabili. Nulla ci impedisce di ragionare in termini di «doppia» protezione, ovvero un server proxy raggiungibile esclusivamente attraverso una VPN. Chiaramente sarebbe una configurazione non adatta a un utente casalingo; per l'azienda che vuole proteggere i propri utenti anche quando utilizzano computer portatili o altri dispositivi mobili, invece, può offrire la sicurezza del transito criptato dal dispositivo dell'utente al server VPN e, da lì, una navigazione protetta e regolata dal proxy. Progettare questo tipo di perimetri — e verificarne davvero la tenuta — è uno dei mestieri della sicurezza. Articolo pubblicato originariamente sul blog di VPS GREEN, il servizio VPS sul nostro cloud privato green. ### [Come mettere in sicurezza un VPS con Rocky Linux](https://www.lymphatechnologies.com/it/vps-sicurezza-rocky-linux) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Guide pratiche · Tag: VPS, Rocky Linux, hardening, firewalld, sicurezza, SSH, dnf > Rocky Linux è enterprise e 100% compatibile con Red Hat — ma i comandi non sono quelli di Ubuntu: dnf al posto di apt, firewalld al posto di ufw, il gruppo wheel per il sudo. La messa in sicurezza di base, passo per passo. In questo articolo - Prerequisiti - Verifichiamo quale sistema operativo è installato - Aggiorna il tuo sistema operativo - Creazione di un utente con privilegi limitati - Gestione del firewall - Modificare la porta del servizio SSH - Disabilitare l'accesso root via SSH ← Tutti gli articoli Rocky Linux è un sistema operativo open source di livello enterprise. La sua principale peculiarità è l'essere progettato e mantenuto di pari passo a Red Hat Enterprise Linux, ovvero essere 100% bug-per-bug compatibile. In questa guida andremo a eseguire una prima, basilare messa in sicurezza di un VPS Rocky Linux appena installato. Questi primi semplici step andranno poi integrati con eventuali altri meccanismi di sicurezza, a seconda dei servizi che vorrai installare. Vista l'origine comune (Red Hat), questa guida vale anche per i sistemi operativi CentOS 7 e 8. Prerequisiti - Un VPS Rocky Linux - Un utente con privilegi adeguati, ovvero root - Un editor di testo, nel nostro esempio useremo nano - Il gestore di pacchetti dnf, normalmente incluso nel sistema operativo - [Consigliato] Un firewall, nel nostro esempio useremo firewalld Verifichiamo quale sistema operativo è installato Essendo una distribuzione Linux che segue Red Hat EL, in caso di problemi è bene essere certi della versione su cui si lavora. Per farlo possiamo lanciare il comando: # cat /etc/os-release NAME="Rocky Linux" VERSION="9.0 (Blue Onyx)" ID="rocky" ID_LIKE="rhel centos fedora" VERSION_ID="9.0" PLATFORM_ID="platform:el9" PRETTY_NAME="Rocky Linux 9.0 (Blue Onyx)" ANSI_COLOR="0;32" LOGO="fedora-logo-icon" CPE_NAME="cpe:/o:rocky:rocky:9::baseos" HOME_URL="https://rockylinux.org/" BUG_REPORT_URL="https://bugs.rockylinux.org/" ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9" ROCKY_SUPPORT_PRODUCT_VERSION="9.0" REDHAT_SUPPORT_PRODUCT="Rocky Linux" REDHAT_SUPPORT_PRODUCT_VERSION="9.0"Nel nostro esempio la versione è la 9.0, denominata Blue Onyx. Aggiorna il tuo sistema operativo Per verificare la presenza di aggiornamenti usiamo il comando dnf con il parametro check-update: # dnf check-updateQuesto comando mostrerà la lista di tutti i pacchetti da aggiornare. A questo punto è possibile scegliere se aggiornare tutto quanto suggerito oppure, selettivamente, solo alcuni pacchetti. Nel primo caso basterà lanciare il comando: # dnf -y updateIl parametro -y serve soltanto a preconfermare la volontà di aggiornare tutti i pacchetti, senza chiedere alcuna conferma. Se invece vogliamo procedere con un aggiornamento selettivo, aggiornando quindi un determinato pacchetto, basterà lanciare il comando: # dnf update cockpit.x86_64Nel nostro esempio aggiorniamo il pacchetto cockpit, tralasciando gli altri. Creazione di un utente con privilegi limitati Come regola generale per la sicurezza, è bene non utilizzare l'utente root per le attività giornaliere sul VPS. A tale scopo andremo a creare un utente con privilegi limitati, ma che in caso di necessità possa impersonare temporaneamente l'utente root. Per creare un nuovo utente si utilizza il comando useradd: # useradd mio_utenteUna volta creato l'utente, assegniamo una password utilizzando il comando passwd: # passwd mio_utente Changing password for user mio_utente New password: Retype new password: passwd: all authentication tokens updated successfully.Anche se l'utente appena creato non avrà particolari chance di far danni sul sistema, evitiamo di utilizzare password deboli (almeno 8 caratteri alfanumerici, caratteri speciali compresi). A questo punto possiamo utilizzare l'utente appena creato per collegarci al VPS, ma per ora non saremo in grado di eseguire comandi che richiedono i privilegi dell'utente root. Per eseguire comandi che richiedono i privilegi di root è possibile procedere in due modi: - utilizzare il comando $ su root, per impersonare l'utente root; - aggiungere l'utente appena creato al gruppo dei sudoer (gli utenti che possono eseguire comandi con privilegi di root): quando servirà, basterà scrivere $ sudo comando_con_privilegi (esempio $ sudo dnf update). Se nel primo caso l'utente non privilegiato dovrà conoscere la password di root per poter operare, nel secondo sarà invece preautorizzato — a maggior ragione, non bisognerà sottovalutare la qualità della password scelta. Meglio sarebbe evitare di esporre SSH sulla porta standard e, ancor meglio, utilizzare chiavi cifrate per connettersi piuttosto che il mero sistema utente/password. Per aggiungere l'utente creato al gruppo dei sudoer, accediamo al VPS come utente root e usiamo il comando: # usermod -aG wheel mio_utenteIl gruppo «wheel» è un gruppo speciale, usato in alcuni sistemi Linux per controllare quali utenti possono utilizzare il comando sudo. Ora, se accediamo al VPS in SSH con l'utente senza privilegi, utilizzando sudo seguito dal comando che richiede privilegi potremo eseguire attività che richiedono normalmente i permessi di root, ad esempio: $ sudo dnf check-update We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for mio_utente:Ovviamente la password richiesta è quella dell'utente creato in precedenza, non quella di root. In questo modo potremo creare utenti per collaboratori esterni senza diffondere la password di root. Gestione del firewall Un aspetto importante per la sicurezza del VPS è la gestione del firewall. In Rocky Linux il firewall è attivo per default e ha una configurazione base che permette di collegarsi in SSH (porta standard TCP 22) e alla console web Cockpit (porta TCP 9090); quest'ultimo servizio non è attivo, quindi se proverai a collegarti all'indirizzo https://ip_vps:9090 non riceverai alcuna risposta. Diversamente dai sistemi operativi derivati da Debian (esempio Ubuntu Server), Rocky Linux utilizza firewalld: di conseguenza i comandi per la sua configurazione sono differenti da ufw (chi usa normalmente Ubuntu sa di cosa stiamo parlando). Come primo step, assicuriamoci che il firewall sia in esecuzione: $ sudo firewall-cmd --stateVisto che stai utilizzando un utente non root, ti sarà richiesta la password. Se tutto procede come sperato, l'output sarà un semplice «running». Per verificare l'attuale configurazione del firewall usiamo il comando: $ sudo firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: cockpit dhcpv6-client ssh ports: protocols: forward: yes masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:Da qui possiamo vedere che la zona attiva si chiama public (active), che a tale zona è assegnata l'interfaccia di rete eth0, che sono permesse le comunicazioni in ingresso per i servizi cockpit, dhcpv6-client e ssh e che sono permesse le risposte ICMP — icmp-block-inversion: no (esempio: le risposte al comando ping). La zona public blocca per default qualunque comunicazione in ingresso, se non specificato diversamente. Un concetto fondamentale di firewalld è che tutte le modifiche fatte alla configurazione sono temporanee, a meno che non venga utilizzato il parametro --permanent prima del comando. Questo significa che se, ad esempio, volessimo aprire la porta 443 per permettere l'accesso in HTTPS con il seguente comando: $ sudo firewall-cmd --zone=public --add-service=httpsal primo riavvio del VPS questa regola non sarebbe più presente. Se invece volessimo renderla permanente, basterà — come detto: $ sudo firewall-cmd --permanent --zone=public --add-service=httpsModificare la porta del servizio SSH Come direbbe il geniale scrittore contemporaneo Ken Follett sulla fiducia: «Fidarsi di qualcuno è come tenere dell'acqua nelle mani chiuse a coppa…»; se parliamo di sicurezza informatica, immaginate di tenere l'acqua nelle mani con le dita completamente aperte. Visto che non possiamo conoscere il «qualcuno» che tenterà di collegarsi al vostro VPS, non diamogli alcuna fiducia. Un suggerimento già dato in altri articoli è modificare la porta standard del servizio SSH: questa semplice operazione diminuisce i tentativi di accesso non autorizzati da parte di script che, in automatico, provano a collegarsi sulla porta 22. Prima di iniziare la configurazione decidiamo quale porta utilizzare: in questo esempio abbiamo scelto la porta 4322/TCP. Step 1 — Configuriamo il firewall. Aggiungiamo alla configurazione del firewall la porta 4322/TCP: $ sudo firewall-cmd --permanent --zone=public --add-port=4322/tcpCome puoi notare, abbiamo usato il parametro per rendere permanente la configurazione. A questo punto ricarichiamo tutti i parametri e accertiamoci che non vi siano errori: $ sudo firewall-cmd --reload $ sudo firewall-cmd --list-portsNell'output comparirà la nostra 4322/tcp. Step 2 — Configuriamo il servizio SSH. La procedura per modificare la porta di default è abbastanza semplice: basta modificare il file /etc/ssh/sshd_config cambiando il numero della porta e successivamente riavviare il servizio. Per modificare il file useremo l'editor nano: $ sudo nano /etc/ssh/sshd_configIn questo file tutto ciò che inizia con «#» indica un commento e non viene considerato dal sistema; allo stesso tempo, però, ci dice qual è il valore di default. Cerchiamo la riga che inizia per #Port 22, eliminiamo il simbolo «#» e modifichiamo il valore della porta — oppure aggiungiamo una riga appena sotto al commento con la nostra nuova porta SSH: Port 4322. Non resta che salvare la modifica con CTRL+X e Y di conferma. Affinché le modifiche diventino effettive bisogna riavviare il servizio: $ sudo systemctl restart sshd.serviceDa questo momento, se provi a collegarti in SSH al tuo VPS riceverai il messaggio ssh: connect to host IP_VPS port 22: Connection refused. Per potersi collegare è necessario aggiungere al comando l'opzione -p seguita dalla nuova porta: ssh mio_utente@IP_VPS -p 4322Disabilitare l'accesso root via SSH Per una maggiore sicurezza del tuo VPS è fortemente consigliato non permettere all'utente root l'accesso via SSH: a tale scopo in precedenza abbiamo creato un utente con privilegi limitati, ma che all'occorrenza possa diventare root. Ora andremo a impedire l'accesso in SSH a root. Anche in questo caso dovremo modificare il file di configurazione del servizio SSH, come fatto per il cambio della porta standard. Apriamo il file /etc/ssh/sshd_config con l'editor nano ($ sudo nano /etc/ssh/sshd_config), cerchiamo la stringa «PermitRootLogin yes» e la impostiamo a «no»: # Authentication: #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yesSalviamo la modifica con CTRL+X e Y di conferma. Riavviamo il servizio per rendere effettive le modifiche: $ sudo systemctl restart sshd.serviceAnche se può apparire scomodo impedire a root di connettersi via SSH, è un passaggio importante per aumentare il livello di sicurezza del VPS. Se avrai la necessità di collegarti direttamente alla macchina con l'utente root, potrai sempre utilizzare la console web dalla dashboard del tuo account VPS GREEN. Guida pubblicata originariamente sul blog di VPS GREEN, il servizio VPS sul nostro cloud privato green. ### [Disabilitare l'accesso con password per il protocollo SSH](https://www.lymphatechnologies.com/it/vps-ssh-senza-password) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Guide pratiche · Tag: VPS, SSH, hardening, sicurezza, sshd_config, chiavi SSH > Con le chiavi SSH configurate, la password è solo una porta in più lasciata socchiusa. Cinque passaggi su sshd_config per chiuderla del tutto — con la sessione d'emergenza aperta, per non tagliarsi fuori. In questo articolo - Prerequisiti - Modifica la configurazione del servizio SSH - Mai più password ← Tutti gli articoli Seguendo il percorso intrapreso con i precedenti articoli sulla messa in sicurezza di un VPS con sistema operativo Linux (la guida base e l'accesso con chiavi SSH), andremo ora a modificare il servizio SSH in modo da non accettare richieste di accesso con l'inserimento di password. In questo modo si potrà accedere esclusivamente con l'utilizzo di chiavi SSH, aumentando intrinsecamente il livello di sicurezza del VPS. Nel caso dovessi perdere la tua chiave privata, potrai comunque accedere al tuo VPS con utente e password tramite la console web di VPS GREEN, raggiungibile dalla dashboard. Effettuato l'accesso dalla console potrai riconfigurare l'SSH con una nuova chiave privata oppure ripristinare l'accesso con nome utente e password. Prerequisiti - Un VPS con sistema operativo Linux - Un utente con privilegi adeguati, ovvero sudo o direttamente root - Un editor di testo, nel nostro esempio useremo nano - Aver abilitato l'SSH all'utilizzo di chiavi cifrate Modifica la configurazione del servizio SSH Prima di iniziare con le modifiche, apri due sessioni SSH: in una eseguirai tutte le operazioni indicate, mentre l'altra resterà aperta in caso d'emergenza (può essere utile per evitare di restare tagliati fuori se le modifiche fatte al file di configurazione risultassero errate). Il file di configurazione del servizio SSH si trova in /etc/ssh/sshd_config; solo l'utente root può modificarlo. - Spostiamoci nella directory in cui si trova il file sshd_config: $ cd /etc/ssh - Facciamo una copia del file sshd_config, in modo da poter ripristinare rapidamente tutte le impostazioni modificate: $ sudo cp sshd_config sshd_config.orig - A questo punto possiamo iniziare con la modifica della configurazione: $ sudo nano sshd_config All'interno del file tutto ciò che inizia con # (cancelletto) rappresenta un commento e viene ignorato all'avvio del servizio; allo stesso tempo, però, ci indica qual è il valore di default per quella determinata opzione. Ad esempio: #Port 22 <- questa è la porta di default del servizio, ignorata Port 4422 <- questa è la nuova porta, scelta da noi, utilizzataPer impedire l'accesso con la password dobbiamo trovare l'opzione PasswordAuthentication, eliminare il simbolo # e modificare il suo valore di default a no — oppure, se si preferisce, scrivere una nuova riga conservando intatto il valore precedente. Usando l'editor nano abbiamo a disposizione una comoda funzionalità di ricerca: basta premere i tasti CTRL+W per attivare, nella parte bassa della finestra, un campo in cui inserire il testo da cercare; premendo INVIO inizierà la ricerca sul file. Trovato il parametro PasswordAuthentication, puoi modificarlo: # PasswordAuthentication yes PasswordAuthentication noSalva le modifiche premendo i tasti CTRL+X, poi Y e infine INVIO per accettare il nome del file proposto. - A questo punto bisogna rendere effettive le modifiche appena fatte: è quindi necessario riavviare il servizio SSH lanciando il comando $ sudo systemctl restart sshd - Visto che non riceverai alcun output particolare a conferma dell'avvenuto riavvio, controlla che il servizio si sia avviato correttamente (se il file sshd_config contiene errori, il servizio non si riavvierà): $ sudo systemctl status sshd Mai più password Se la procedura è stata eseguita bene, potrai vedere alla voce «Active:» che il servizio è attivo e in esecuzione, con un rassicurante active (running). Ora puoi provare a connetterti, magari senza la chiave privata, in modo da sperimentare il fatto che il servizio SSH sul tuo VPS negherà fermamente l'accesso, senza nemmeno chiedere nome utente o password: utente_vps@ip_vps: Permission denied (publickey)Guida pubblicata originariamente sul blog di VPS GREEN, il servizio VPS sul nostro cloud privato green. ### [Il backup non basta: perché c'è chi riparte in ore e chi resta fermo giorni](https://www.lymphatechnologies.com/it/il-backup-non-basta-perche-c-e-chi-riparte-in-ore-e-chi-resta-fermo-giorni) Pubblicato: 2026-07-16 · Autore: paolo.pierno · Categorie: Continuità & Sicurezza · Tag: backup, disaster recovery, business continuity, RTO, RPO, ransomware > Avere le copie non significa saper ripartire. La differenza la fanno quattro cose: obiettivi chiari (RTO e RPO), un'analisi d'impatto, prove di restore vere e qualcuno che guardi i job ogni giorno. In questo articolo - Una copia non è una ripartenza - RTO e RPO: le due domande da fare prima - Non tutti i servizi valgono uguale - Un backup non provato è una speranza - Quando l'attaccante cerca proprio i backup - Il valore di qualcuno che guarda ← Tutti gli articoli «Il backup ce l'abbiamo.» È la frase che sentiamo più spesso — ed è quasi sempre vera. Il problema è che risponde alla domanda sbagliata. La domanda giusta è un'altra: se domattina i sistemi non partono, tra quanto tempo l'azienda torna a lavorare? E su questa, chi ha «il backup» spesso scopre di non avere una risposta. Una copia non è una ripartenza Il backup è un oggetto: una copia dei dati, da qualche parte. La ripartenza è un processo: su quale hardware ripristini, in che ordine rimetti in piedi i servizi, chi lo fa, con quali credenziali, seguendo quale documento. Tra l'oggetto e il processo c'è la differenza tra chi riparte in ore e chi resta fermo giorni — con i reparti che chiamano, i clienti che aspettano e ogni decisione presa d'impulso. Questa distinzione ha due nomi precisi: data protection è proteggere il dato; business continuity e disaster recovery è garantire che l'azienda continui a funzionare. Sono due discipline diverse, e la seconda non si compra: si progetta. RTO e RPO: le due domande da fare prima Ogni piano serio parte da due parametri, che sono in fondo due domande semplici: - RTO (Recovery Time Objective): quanto tempo puoi restare fermo? Da qui discende tutto: un RTO di 4 ore e uno di 2 giorni portano ad architetture — e costi — completamente diversi; - RPO (Recovery Point Objective): quanti dati puoi permetterti di perdere? Le ore di lavoro tra l'ultima copia utile e il momento del guasto non tornano indietro. Il punto che cambia la prospettiva: RTO e RPO non si definiscono «per l'azienda», si definiscono per servizio. La posta elettronica, il gestionale e l'archivio storico non valgono uguale — e trattarli uguale significa spendere troppo dove non serve e troppo poco dove fa male. Non tutti i servizi valgono uguale Lo strumento per deciderlo si chiama Business Impact Analysis (BIA): l'analisi che mette in fila i processi aziendali, misura cosa succede se ciascuno si ferma — mancato fatturato, obblighi verso terzi, danno reputazionale — e da lì ricava priorità e obiettivi di ripartenza. È il momento in cui il piano smette di essere un documento IT e diventa una decisione di business: quali servizi rientrano per primi, in quale ordine, e quanto vale la pena investire su ciascuno. Un backup non provato è una speranza Il giorno del disastro non è il momento giusto per scoprire se il restore funziona. Le copie possono essere corrotte, incomplete, o semplicemente più lente da ripristinare di quanto chiunque immaginasse. L'unico modo per saperlo è provare: verifiche di ripristino periodiche — a campione sui singoli sistemi e, con la giusta cadenza, complete sui servizi critici — cronometrando i tempi reali e confrontandoli con l'RTO dichiarato. Se il ripristino misurato del gestionale richiede 11 ore e l'obiettivo era 4, meglio saperlo in un martedì tranquillo che durante l'incidente. Quando l'attaccante cerca proprio i backup C'è una ragione in più, oggi, per prendere sul serio tutto questo: nei moderni attacchi ransomware le copie di sicurezza non sono un danno collaterale — sono un obiettivo primario. Chi cifra i dati sa che un'azienda con backup integri non paga: per questo cerca di raggiungere e distruggere prima le copie. Le contromisure sono note e vanno applicate insieme: la regola 3-2-1 (tre copie, su due supporti diversi, di cui una fuori sede), almeno una copia immutabile o disconnessa che nessuna credenziale compromessa possa cancellare, e la separazione tra le utenze che amministrano i sistemi e quelle che amministrano i backup. A questo si affianca il lavoro di prevenzione e risposta: il backup è l'ultima linea di difesa, non l'unica. Il valore di qualcuno che guarda Ultima lezione dal campo: i backup falliscono in silenzio. Un job che si interrompe, uno storage che si riempie, un sistema nuovo mai aggiunto alle policy — e la scoperta arriva sempre nel momento peggiore. La differenza la fa un presidio quotidiano: qualcuno che controlla gli esiti, corregge le derive e tiene le policy allineate a com'è fatta l'azienda oggi. È il motivo per cui eroghiamo la protezione del dato come servizio gestito — con verifiche di ripristino incluse e il NOC che sorveglia i job insieme al resto dell'infrastruttura. Se invece vuoi partire dalla domanda giusta — «tra quanto ripartiamo?» — facciamola insieme, con una Business Impact Analysis. ### [Oltre il PUE: misurare il lavoro, non solo l'energia](https://www.lymphatechnologies.com/it/oltre-il-pue) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Data Center & Green IT · Tag: work capacity, PUE, EED, efficenza energetica, Green IT, ISO 50001 > Nei data center più nuovi il 70–90% dell'energia la consumano i sistemi IT — proprio la parte che il PUE non misura. Le metriche di capacità di lavoro, la produttività per megawattora e l'obbligo europeo che scatta dai 500 kW. In questo articolo - Dal consumo al lavoro utile - E i server per l'IA? E lo storage? - In Europa non è più (solo) una buona idea - Lavoro per energia: la metrica che chiude il cerchio - Da dove partire, in pratica ← Tutti gli articoli Nel nostro articolo sul PUE lo avevamo chiamato «il termometro, non la diagnosi». Oggi facciamo il passo successivo, perché c'è un paradosso che merita di essere guardato in faccia: più il tuo PUE è buono, meno il PUE ti dice. In un data center di nuova costruzione, con PUE tra 1,1 e 1,3, il 70–90% dell'energia viene assorbito dai sistemi IT — server, storage, rete. Ed è esattamente la parte che il PUE non misura: puoi avere la struttura più efficiente del mondo piena di server che lavorano al 10%. Dal consumo al lavoro utile La domanda giusta non è solo «quanta energia entra?», ma «quanto lavoro utile ne esce?». Per rispondere serve dare un numero alla work capacity, la capacità di lavoro dell'IT installato — e per anni il settore non ha avuto un metodo condiviso per calcolarla. Per i server tradizionali il metodo oggi c'è: The Green Grid — lo stesso consorzio del PUE e del DCMM — ha pubblicato una metodologia basata su PerfCPU, un valore rappresentativo di capacità ricavato dai test standard SERT e definito in una norma ETSI. La cosa interessante è la praticità: il valore si ricava dal codice del processore (o, in mancanza, dal numero di core fisici) tramite tabelle pubbliche. Niente benchmark da eseguire in sala: basta sapere cosa c'è installato, moltiplicare e sommare. E i server per l'IA? E lo storage? Per i server accelerati — GPU e altri acceleratori per addestramento e inferenza — Uptime Intelligence propone di usare i TFLOPS a 32 bit (la somma dei valori vettoriali e matriciali dichiarati per ciascun acceleratore). Non è una misura perfetta, e i puristi obiettano che le prestazioni reali dipendono da memoria, interconnessioni e software: vero. Ma è un valore standardizzato, reperibile e confrontabile anno su anno — e in un settore rimasto a lungo senza alcuna metrica, «rappresentativo» batte «perfetto». Per lo storage la scelta è ancora più pragmatica: i terabyte installati nei sistemi dedicati. E qui il report regala il dato che fa riflettere: un sistema storage assorbe l'80–90% della sua potenza massima anche quando non sta gestendo dati, perché nel frattempo esegue verifiche di integrità. Capacità inutilizzata significa energia sprecata: portare l'utilizzo dei sistemi sopra l'80% — invece di aggiungere scaffali — è una delle leve di efficienza più concrete che esistano. In Europa non è più (solo) una buona idea Queste metriche stanno entrando nella regolamentazione: la direttiva europea sull'efficienza energetica (EED), con il regolamento delegato 2024/1364, richiede ai data center con una potenza IT installata dai 500 kW in su di riportare gli indicatori di capacità ICT — capacità di lavoro dei server e capacità di storage — nel database europeo dei data center. Il problema? I dati. Per calcolare la capacità serve un inventario a livello di componente: quanti processori, di quale modello, in quale data center. Secondo le rilevazioni Uptime Institute, oggi meno di un operatore su due ha censito i codici dei propri CPU, e solo un terzo quelli degli acceleratori. Chi gestisce infrastrutture in Europa ha una ragione normativa per rimediare in fretta; tutti gli altri ne hanno una economica. Lavoro per energia: la metrica che chiude il cerchio Messi insieme, i tre ingredienti — capacità installata, utilizzo medio e energia consumata — permettono di calcolare il work-per-energy: quanto lavoro produce ogni megawattora. È la metrica di produttività che la ISO 50001 richiede per la gestione dell'energia, ed è anche il modo più onesto di misurare un progetto di consolidamento: prima e dopo, con un numero — da cui discendono risparmio energetico e ritorno dell'investimento. Il settore è stato troppo lento a dotarsi di una metrica di lavoro, lasciando che la perfezione ostacolasse il buono. È l'osservazione con cui si chiude il report, e la condividiamo: le metriche proposte non sono perfette, ma sono calcolabili oggi, con dati che un'organizzazione ben gestita ha già — o dovrebbe avere. Da dove partire, in pratica - Inventario a livello di componente: codici di CPU e acceleratori, capacità raw dello storage, associati alla sede — è il lavoro della CMDB fatta bene; - Misura dell'utilizzo e dei consumi: dati di utilizzo di CPU e storage e potenza a livello di rack o PDU, raccolti con continuità dal monitoraggio; - Prima fotografia del lavoro per energia: anche approssimata, dà la baseline su cui misurare consolidamenti e refresh — e si integra nella griglia di valutazione del DCMM, dove il PUE resta il termometro e queste metriche iniziano a fare la diagnosi. Il principio è lo stesso che applichiamo al nostro data center green: misurare, progettare sul dato, migliorare per passi. Se vuoi capire quanto lavoro produce davvero ogni megawattora della tua infrastruttura, parliamone. Fonti e riferimenti: Uptime Institute Intelligence, Calculating work capacity for server and storage products (Briefing Report 174, maggio 2025); The Green Grid, IT work capacity metric V1 — a methodology (white paper #94) e TGG's position on the metric to calculate ICT server capacity (#92); ETSI EN 303 740; Regolamento delegato (UE) 2024/1364 (indicatori ICT della direttiva EED). ### [PUE: il numero che dice quanto consuma davvero il tuo data center](https://www.lymphatechnologies.com/it/pue-data-center) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Data Center & Green IT · Tag: PUE, efficenza energetica, Green IT, data center, DCMM > Un indicatore nato nel 2007 separa ancora oggi i data center gestiti da quelli subiti. Cos'è il PUE, come si misura senza strumenti costosi, dove inganna — e cosa dice l'esperienza di un data center green vero. In questo articolo - Cos'è il PUE, in una riga - Quanto consuma il mondo - Misurarlo senza spendere (quasi) nulla - I primi interventi sono i più redditizi - Dove il PUE inganna - La prova su una scala non-hyperscaler ← Tutti gli articoli C'è un numero che racconta di un data center più di qualunque brochure: quanta dell'energia che entra nell'edificio arriva davvero ai sistemi IT, e quanta invece si perde per strada — raffrescamento, conversioni elettriche, illuminazione. Quel numero si chiama PUE, e vale la pena capirlo bene anche se il tuo «data center» è una sala CED con tre rack. Cos'è il PUE, in una riga Il PUE (Power Usage Effectiveness) è la metrica proposta nel 2007 da The Green Grid, il consorzio internazionale per l'efficienza delle infrastrutture IT. La definizione sta in una divisione: PUE = energia totale assorbita dalla struttura / energia assorbita dai sistemi ITIl valore ideale è 1,0: tutta l'energia va all'IT, zero perdite. Un PUE di 2,0 significa che per ogni watt consumato da server, storage e rete, un altro watt intero se ne va in «contorno» — soprattutto raffrescamento. Più il numero si avvicina a 1, più la struttura è efficiente. Quanto consuma il mondo Le rilevazioni annuali dell'Uptime Institute — il riferimento di settore per queste indagini — raccontano una storia in due tempi: un grande miglioramento nei primi anni della metrica, quando le pratiche di base si sono diffuse, e poi una media mondiale ferma intorno a 1,5–1,6 ormai da parecchi anni. Tradotto: il data center «medio» spreca ancora circa un terzo dell'energia che consuma. E questa è la media dei data center che si misurano. Le sale server piccole e non presidiate — condizionatore domestico, nessun contenimento dei flussi d'aria, nessun contatore dedicato — stanno tipicamente sopra il 2: per ogni euro di elettricità che lavora, un altro euro evapora. Misurarlo senza spendere (quasi) nulla La buona notizia: per iniziare non serve un sistema DCIM. Servono due numeri, presi nello stesso periodo: - l'energia totale della sala o dell'edificio — dal contatore o dalla bolletta, se la sala ha una fornitura distinguibile; - l'energia dei sistemi IT — la lettura in uscita dell'UPS è spesso il punto più comodo, oppure una pinza amperometrica sui quadri che alimentano i rack. Un campionamento mensile è già sufficiente per vedere la stagionalità (il raffrescamento d'estate si sente) e per dare un numero alla direzione. La versione «adulta» — misura continua, allarmi, trend — arriva dopo, con la strumentazione integrata nel monitoraggio: prima viene l'abitudine di misurare, poi lo strumento. I primi interventi sono i più redditizi È la stessa logica che il Data Center Maturity Model mette nero su bianco: i salti dai livelli bassi si fanno in gran parte con interventi a basso costo, e sono quelli che rendono di più. - Gestione dei flussi d'aria: separare aria calda e fredda (corridoi, pannelli ciechi nei rack, sigillatura dei passaggi cavi) — spesso il singolo intervento con il miglior rapporto costo/beneficio; - Set-point più onesti: molte sale sono tenute più fredde del necessario; alzare la temperatura di esercizio entro i range previsti dai costruttori riduce il lavoro del raffrescamento; - Free cooling: usare l'aria esterna quando le condizioni lo permettono, invece di produrre freddo meccanicamente; - Consolidare e spegnere: virtualizzazione, deduplica, dismissione dei sistemi «zombie» — ogni watt IT eliminato ne risparmia altri a cascata sul contorno. Dove il PUE inganna Il PUE misura l'efficienza della struttura, non dell'IT. Qui nasce il suo paradosso: se consolidi i server e dimezzi il consumo IT, il denominatore scende e il PUE… peggiora, anche se stai consumando meno in assoluto. Un PUE eccellente può convivere con centinaia di server che lavorano al 10%. Per questo il PUE va letto insieme alle metriche sorelle — CUE per l'impronta carbonica, WUE per quella idrica, ERF per il riuso del calore — e dentro una griglia più ampia che guardi anche l'utilizzo reale di compute, storage e rete. È esattamente ciò che fa il DCMM: il PUE è il termometro, non la diagnosi. La prova su una scala non-hyperscaler Che questi principi funzionino anche fuori dai giganti lo abbiamo verificato su noi stessi. Il data center green da cui eroghiamo i servizi è progettato attorno all'efficienza fin dall'involucro: struttura in legno a bassa trasmittanza, bassa densità, esercizio ad alta temperatura (~28 °C), free cooling con soli moti convettivi in inverno — e un'alimentazione 100% da fonti rinnovabili, documentata con Garanzie di Origine ed emissioni Scope 2 pari a zero (i certificati sono pubblici e scaricabili). Il punto non è il primato: è che misurare, progettare sul dato e migliorare per passi funziona a qualunque scala — dalla sala con tre rack in su. Il racconto completo del nostro approccio è nella pagina impegno per l'ambiente; se vuoi dare un numero alla tua infrastruttura, partiamo da lì. Fonti e riferimenti: The Green Grid (definizione del PUE, 2007; Data Center Maturity Model, 2011); Uptime Institute, Global Data Center Survey (rilevazioni annuali sul PUE medio di settore). ### [Perché il tuo RAG non funziona: è il retrieval, non il modello](https://www.lymphatechnologies.com/it/perche-il-tuo-rag-non-funziona-e-il-retrieval-non-il-modello) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: IA & Dati · Tag: RAG, retrieval, hybrid search, ricerca ibrida, assistenti IA, GenAI > Quando un assistente documentale risponde male, l'istinto è cambiare modello o riscrivere il prompt. Quasi sempre è la mossa sbagliata: il problema è a monte, nella ricerca che decide quali documenti il modello legge. In questo articolo - Il numero che gira nelle presentazioni - Il tetto che nessun modello può sfondare - Perché la ricerca sbaglia - La soluzione: far lavorare due ricerche insieme - Come si capisce se funziona (prima di fidarsi) - Le cinque domande da fare a chi ve lo costruisce - La sintesi ← Tutti gli articoli Quando un assistente basato su RAG — quelli che rispondono usando i documenti dell'azienda — dà risposte sbagliate, la reazione istintiva è sempre la stessa: «serve un modello più potente», oppure «riscriviamo il prompt». Quasi sempre è la mossa sbagliata, e anche la più costosa. Il collo di bottiglia è a monte, in un componente di cui si parla poco: il retrieval, cioè la ricerca che decide quali documenti finiscono sotto gli occhi del modello. Se il documento con la risposta non arriva sul suo tavolo, nessun modello — per quanto grande — può inventarselo. È il seguito naturale delle cinque lezioni dalla nostra piattaforma RAG, dove scrivevamo che «la qualità si decide nel retrieval». Qui spieghiamo perché — e soprattutto come accorgersene prima di spendere. Il numero che gira nelle presentazioni Circola ovunque la cifra «il 95% dei progetti di IA generativa fallisce». Viene da un report del MIT (The GenAI Divide, 2025), secondo cui il 95% dei progetti pilota non produce un impatto misurabile sul conto economico, a fronte di 30–40 miliardi di dollari investiti. Tre onestà necessarie prima di usare quel numero: non è un dato specifico sul RAG ma sui pilot GenAI in generale; «nessun impatto misurabile sui conti» non significa «il sistema non funziona»; e la metodologia del report è stata contestata per la fragilità del campione rispetto al titolo. Detto questo, il report indica una causa che coincide con la nostra esperienza sul campo: il problema non sta nella qualità dei modelli, ma nell'integrazione — nel contesto che gli si dà. La tesi di questo articolo è quindi più circoscritta e più difendibile: nella maggioranza dei progetti RAG che abbiamo visto arenarsi, la causa prima è la ricerca, non il modello. Ed è una tesi che si può misurare, non solo raccontare. Il tetto che nessun modello può sfondare Un sistema RAG è una catena di due anelli: c'è un componente che cerca i passaggi rilevanti nei vostri documenti, e un modello che scrive la risposta leggendo quei passaggi. Tutta l'attenzione (e il budget) va di solito al secondo anello. Ma vale una regola tanto banale quanto ignorata: La qualità massima delle risposte è limitata dalla qualità della ricerca: se il passaggio giusto non viene trovato, il modello può solo dire «non lo so» — oppure inventare. Non esiste una terza opzione. Cambiare modello sposta la scelta tra queste due, non risolve il problema. Ecco perché il primo investimento sensato non è un modello più grande: è misurare quanto spesso la ricerca porta il documento giusto. Se lo fa 6 volte su 10, il tetto di accuratezza dell'intero sistema è il 60% — e nessuna sistemazione del prompt lo alzerà. Perché la ricerca sbaglia Le cause ricorrenti sono poche e concrete: - Documenti spezzati male. Per essere cercati, i documenti vengono divisi in frammenti. Se il taglio è meccanico, una tabella finisce a metà, una regola si separa dalla sua eccezione, e il frammento «in tal caso il termine è ridotto a 15 giorni» non dice più di quale caso parla. - Parole diverse per la stessa cosa. L'utente chiede «posso pagare a rate una bolletta scaduta?», il documento parla di «piano di rientro per posizioni insolute». Zero parole in comune: la ricerca per parole chiave non lo troverà mai. - La correzione che crea il problema opposto. La risposta tipica è passare alla ricerca «semantica», che capisce il significato al di là delle parole. Vero — ma è debole proprio dove l'altra è forte: codici prodotto, sigle, numeri di articolo, nomi propri. Il codice errore ERR_5012 la ricerca per parole lo trova al primo colpo; quella semantica lo «annega» tra concetti simili. - Nessun collaudo. Il peccato originale: senza un insieme di domande vere con la risposta attesa, ogni modifica è una scommessa e ogni riunione un confronto di opinioni. La soluzione: far lavorare due ricerche insieme Il punto chiave: la ricerca per parole e la ricerca per significato sbagliano su domande diverse e complementari. Non è una scelta tra le due — servono entrambe. La ricerca ibrida fa esattamente questo: esegue le due ricerche in parallelo e ne fonde le classifiche con un criterio che premia il consenso — un documento trovato da entrambe, anche se non in cima, batte un documento primo per una sola. Che è il comportamento giusto: un passaggio trovato sia dalle parole sia dal significato è quasi certamente quello che serve. Un esempio reale, che abbiamo verificato con i numeri alla mano. Domanda: «posso rateizzare una fattura già scaduta?». Il documento giusto — quello sul «piano di rientro per crediti insoluti» — era quinto nella classifica della ricerca per parole e quarto in quella per significato: con una sola delle due tecniche non sarebbe mai entrato tra i primi tre passaggi letti dal modello, e la risposta sarebbe stata sbagliata. Con la fusione delle due classifiche è salito al primo posto — perché era l'unico presente in tutte e due. Strategia di ricerca · Posizione del documento giusto · Il modello lo legge? Solo per parole chiave · 5ª · ✗ Solo per significato · 4ª · ✗ Ibrida (fusione delle due) · 1ª · ✓ Due cose importanti per chi decide. Primo: non è tecnologia esotica — la ricerca ibrida è integrata di serie nei principali motori di ricerca enterprise (Elasticsearch, OpenSearch, Azure AI Search) e si abilita, non si inventa. Secondo: dopo la ricerca serve un passaggio di riordino dei risultati, perché i modelli leggono meglio ciò che sta in cima al contesto — un dettaglio documentato in letteratura che da solo cambia sensibilmente la qualità percepita. È la stessa filosofia della nostra piattaforma ACME ECMS IA & RAG Integration: più assi di ricerca sulla base di conoscenza e riordino dei passaggi prima della generazione. Non è teoria: è lo schema pubblicato in quella pagina. Come si capisce se funziona (prima di fidarsi) Il collaudo è sorprendentemente semplice, e quasi nessuno lo fa. Si costruisce un set di prova: 50–100 domande reali — raccolte da chi userà il sistema, non inventate a tavolino — ciascuna con l'indicazione del documento che contiene la risposta. Poi si misura una cosa sola, sulla ricerca isolata, prima ancora di coinvolgere il modello: quante volte il documento giusto compare tra i primi risultati? Quel numero è il tetto dell'intero progetto. Misurato prima e dopo ogni intervento — attivazione della ricerca ibrida, riordino, taglio migliore dei documenti — trasforma le discussioni in decisioni: si vede in una tabella che cosa ha migliorato le cose e di quanto, e si smette di attribuire al «modello scarso» colpe che stanno altrove. Le cinque domande da fare a chi ve lo costruisce - Esiste un set di prova con domande nostre e risposte attese? Possiamo vederlo? - Qual è la percentuale di volte in cui la ricerca porta il documento giusto tra i primi risultati, misurata sul nostro archivio? - La ricerca usa entrambi gli assi — parole chiave e significato — o uno solo? - C'è un passaggio di riordino dei risultati prima che il modello li legga? - Quando una risposta è sbagliata, sapete dirci se il documento giusto era stato trovato? (Se sì, il problema è la generazione; se no, è la ricerca. Nella nostra esperienza è quasi sempre la seconda.) Se a queste domande arrivano risposte vaghe, il progetto sta navigando a vista — qualunque modello ci sia sotto. La sintesi Il RAG non fallisce perché il modello è stupido. Fallisce perché gli si dà da leggere il documento sbagliato — e poi lo si accusa di aver risposto male. Prima di investire in un modello più grande: misurare la ricerca, attivare l'asse che manca, aggiungere il riordino. Nella nostra esperienza è l'ordine di interventi con il miglior rapporto tra risultato e costo — ma è un'esperienza, non un teorema: il set di prova costruito sulle vostre domande è l'unico arbitro che conta. Se il vostro assistente documentale si è arenato in fase pilota, possiamo guardarci dentro insieme — partendo, ovviamente, dalla misura. Fonti. - MIT Media Lab, Project NANDA — The GenAI Divide: State of AI in Business 2025 (luglio 2025); sintesi su Fortune, 18 agosto 2025. La metodologia è stata oggetto di critiche indipendenti per la fragilità del campione. - Sulla fusione delle classifiche (Reciprocal Rank Fusion): Cormack, Clarke, Büttcher, SIGIR 2009; documentazione di Azure AI Search, Elastic e OpenSearch. L'esempio numerico citato è stato ricalcolato e verificato dalla redazione. - Sul degrado di lettura nei contesti lunghi: Liu et al., Lost in the Middle, TACL 2024. ### [RAG on-premise: cinque lezioni da una piattaforma costruita davvero](https://www.lymphatechnologies.com/it/rag-on-premise-lezioni) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: IA & Dati · Tag: RAG, IA generativa, LLM, on-premise, knowledge graph, RAGAS > Abbiamo costruito e messo in esercizio una piattaforma RAG interamente on-premise — oggi si chiama ACME ECMS IA & RAG Integration. Queste sono le cinque cose che avremmo voluto sapere prima di iniziare. In questo articolo - 1 · La qualità si decide nel retrieval, non nel modello - 2 · Recupero ibrido più re-ranking: due passaggi, non uno - 3 · Non tutte le domande meritano il RAG - 4 · Senza metriche stai solo indovinando - 5 · On-premise è fattibile — e a volte è l'unica strada - Da dove partire ← Tutti gli articoli Di Retrieval-Augmented Generation si parla ovunque, quasi sempre allo stesso modo: si prende un modello linguistico, gli si «collegano» i documenti aziendali, e da quel momento risponde citando le fonti. La realtà, come spesso accade, è più interessante della brochure. Noi lo sappiamo perché una piattaforma RAG l'abbiamo costruita e messa in esercizio davvero — interamente on-premise, su hardware nel nostro perimetro, con modelli aperti. Oggi è la base di ACME ECMS IA & RAG Integration, e nella pagina dedicata trovi gli schemi dell'infrastruttura e una demo del suo funzionamento. Qui invece raccontiamo quello che gli schemi non dicono: le cinque lezioni che hanno cambiato il nostro modo di progettare questi sistemi. 1 · La qualità si decide nel retrieval, non nel modello La tentazione di chi inizia è concentrarsi sul modello: quale LLM, quanti parametri, quale versione. È la parte sbagliata del problema. Se i passaggi che recuperano i documenti portano al modello il contenuto sbagliato, il modello più potente del mondo farà una cosa sola: riassumere bene la cosa sbagliata. Il lavoro vero sta a monte: come si spezzano i documenti (il chunking), con quali rappresentazioni si indicizzano (gli embeddings), e soprattutto quanta struttura si dà alla base di conoscenza. Nella nostra piattaforma, accanto all'indice vettoriale vive un knowledge graph: entità e relazioni estratte dai documenti, che permettono di rispondere anche a domande che attraversano più documenti — dove la sola somiglianza semantica non basta. 2 · Recupero ibrido più re-ranking: due passaggi, non uno Un solo passaggio di ricerca deve scegliere tra due obiettivi in conflitto: non perdere nulla di rilevante e non far passare rumore. La soluzione che ha funzionato per noi è separarli. Il primo passaggio è largo e ibrido — vettori, parole chiave e grafo insieme — e ottimizzato per il richiamo: meglio un candidato in più che uno in meno. Il secondo passaggio è un re-ranker, un modello dedicato che riordina i candidati per pertinenza reale rispetto alla domanda, e taglia ciò che somiglia ma non risponde. È uno dei componenti che più ha alzato la qualità percepita delle risposte: le fonti citate smettono di essere «vicine al tema» e iniziano a essere quelle giuste. 3 · Non tutte le domande meritano il RAG Un errore comune è trattare ogni richiesta allo stesso modo: qualunque cosa chieda l'utente, si lancia l'intera pipeline — ricerca, re-ranking, generazione con contesto. Il risultato sono risposte lente e costose anche quando non serviva nulla di tutto ciò. Nella nostra architettura la prima decisione la prende un planner: un componente che classifica la richiesta e sceglie la strada. Un saluto o una domanda di cultura generale prendono la via diretta, senza toccare la base documentale; una domanda sui contratti, sulle procedure o sui progetti attiva la pipeline completa. Sembra un dettaglio: in esercizio è la differenza tra un sistema che «risponde quando può» e un servizio con latenze e consumi prevedibili. 4 · Senza metriche stai solo indovinando Cambi il modello di embedding e le risposte «sembrano» migliori. Rivedi il chunking e «sembrano» peggiori. Sembrano a chi? Su quali domande? La sensazione di chi sviluppa non è una metrica, e su un sistema che risponde in linguaggio naturale l'occhio si abitua in fretta. Per questo la piattaforma include una valutazione sistematica della qualità (usiamo il framework RAGAS, con un set di prova costruito in italiano sui nostri casi d'uso): a ogni modifica misuriamo quanto le risposte restano fedeli alle fonti, quanto sono pertinenti alla domanda e quanto è buono il contesto recuperato. È lo stesso principio del nostro metodo — misura, analizza, migliora, verifica — applicato all'IA: ogni intervento parte da un numero e torna a un numero. La domanda giusta non è «l'IA risponde bene?», ma «rispetto a cosa, misurato come, e meglio o peggio di ieri?». 5 · On-premise è fattibile — e a volte è l'unica strada La lezione forse più controintuitiva: per un RAG aziendale non serve un hyperscaler. Modelli aperti su GPU dimensionate al caso d'uso, dentro un'infrastruttura governata, coprono la stragrande maggioranza delle esigenze reali — e portano un vantaggio che nessuna API remota può offrire: i dati non escono mai dal perimetro. Per interi settori questo non è un vezzo, è un requisito. In Sanità i dati relativi alla salute godono della protezione rafforzata dell'art. 9 del GDPR; nella Pubblica Amministrazione pesano sovranità del dato e indicazioni sul cloud. Un'architettura on-premise (o su private cloud in Italia) risolve il problema alla radice — e, con modelli aperti, elimina anche il vendor lock-in. L'altra metà della lezione: un sistema del genere va gestito come un servizio, non come un esperimento. Monitoraggio dei componenti, backup della base di conoscenza, aggiornamenti controllati dei modelli: la parte «di esercizio» conta quanto quella di progettazione. Da dove partire Se dovessimo condensare le cinque lezioni in un consiglio solo: parti piccolo, ma parti misurando. Un caso d'uso concreto, un corpus documentale definito, metriche di qualità dal primo giorno — e un'architettura che non ti costringa a scegliere tra innovare e tenere i dati al loro posto. Come è fatta la nostra piattaforma — schemi d'infrastruttura, flusso logico e una demo animata del ciclo di vita — è raccontato nella pagina IA, Agenti e RAG. Se invece vuoi capire cosa potrebbe fare sul tuo patrimonio documentale, parliamone. ### [Un data center in Europa non basta: cosa significa davvero sovranità digitale](https://www.lymphatechnologies.com/it/sovranita-digitale-eurostack) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Governance · Tag: sovranità digitale, EuroStack, Cloud europeo, vendor lock-in, dati in Italia, private cloud, PA > Un data center costruito su suolo europeo ma di proprietà altrui non rende «sovrani» i tuoi dati: contano proprietà, controllo e possibilità di uscita. Cosa propone l'iniziativa EuroStack — e le domande giuste da fare oggi al proprio provider. In questo articolo - I numeri della dipendenza - Cosa propone EuroStack - La federazione dei piccoli - Cosa puoi fare oggi, senza aspettare Bruxelles ← Tutti gli articoli C'è una parola che negli ultimi anni compare in quasi ogni annuncio di nuovi data center in Europa: «sovrano». L'infrastruttura sta su suolo europeo, quindi i dati sarebbero al sicuro. Ma la collocazione geografica è solo una parte della storia: se la proprietà, la gestione e le condizioni d'uso di quell'infrastruttura rispondono ad altri ordinamenti, la sovranità resta sulla carta. È il paradosso da cui parte EuroStack, la proposta per un'infrastruttura digitale strategica europea presentata a inizio 2025 da un gruppo di studiosi e imprenditori del settore. I numeri della dipendenza Il documento fotografa una dipendenza ormai strutturale lungo tutta la catena del valore digitale — chip, dati, capacità di calcolo, connettività. Il dato più eloquente riguarda il cloud: la quota dei provider europei sul mercato europeo è passata da circa il 26% del 2017 al 10% attuale. Nel frattempo, secondo gli autori, la strategia europea si è concentrata quasi solo sulla regolamentazione — un ruolo da «arbitro digitale» che ha prodotto molte regole ma poca capacità industriale: le alternative non nascono per decreto, e diverse realtà europee promettenti sono finite acquisite proprio dai grandi operatori extraeuropei. Cosa propone EuroStack La tesi centrale è che l'alternativa vada costruita e governata, non solo auspicata. Il documento descrive tre livelli su cui investire in modo coordinato: - Infrastruttura fisica — chip, connettività, calcolo ad alte prestazioni (l'Europa ha tre dei primi dieci supercalcolatori al mondo, e uno, Leonardo, è qui a Bologna) e data center: non solo grandi impianti, ma anche soluzioni decentralizzate, edge e data center di piccola scala; - Infrastruttura logica — identità digitale (eIDAS), cloud interoperabile e federabile, motori IA europei addestrati su lingue e dati locali; - Intermediazione — reti di transazione aperte e governate dagli operatori, in alternativa alle piattaforme proprietarie. Insieme ai livelli tecnici, due leve di politica industriale: requisiti di «buy European» negli acquisti pubblici e privati, e investimenti misurati sui risultati di mercato — adozione reale, non proof-of-concept. La federazione dei piccoli Il passaggio che ci riguarda da vicino: per il documento non c'è né il tempo né il capitale per costruire da zero un «hyperscaler europeo». La strada indicata è federare gli asset che già esistono — la rete dei provider piccoli e medi — rendendoli interoperabili: API comuni, standard aperti per virtualizzazione e containerizzazione, condizioni contrattuali armonizzate, fino a un cloud iper-distribuito che converge naturalmente verso l'edge. E i punti di forza distintivi che il documento riconosce a questi operatori sono esattamente quelli su cui lavoriamo ogni giorno: controllabilità, conformità, prossimità al cliente e integrazione su standard aperti. Non è un caso che il nostro VDC GREEN nasca su radici OpenStack dal 2010, con i dati esclusivamente in Italia. Cosa puoi fare oggi, senza aspettare Bruxelles EuroStack è una proposta di politica industriale, e il suo destino si deciderà tra istituzioni e industria. Ma la logica che la sostiene si applica già oggi a ogni scelta di infrastruttura: - Chiedi chi controlla, non solo dove sta. La domanda giusta al provider non è «in che Paese sono i miei dati?», ma «chi è proprietario dell'infrastruttura, con quale ordinamento, e chi può decidere di spegnerla o cambiarne le condizioni?»; - Esigi una via d'uscita. Assenza di lock-in, costi di uscita chiari, formati e standard aperti: la portabilità si negozia all'ingresso, non all'uscita; - Valuta un provider europeo per almeno una parte del fabbisogno. È la versione dal basso del «buy European»: redundanza, resilienza e potere negoziale verso il fornitore principale; - Per i carichi davvero sensibili, perimetro proprio. Vale per i dati e vale per l'IA: un RAG on-premise tiene i documenti aziendali dove devono stare; - Se sei una PA, la sovranità è già un requisito — non un'opzione: qualificazioni, normativa e sovranità del dato vanno messe a capitolato. La sovranità digitale, insomma, non si compra con un indirizzo europeo: si costruisce con scelte di architettura, contratti e fornitori. Nel nostro piccolo è la strada che percorriamo da quindici anni — e se vuoi capire cosa significherebbe per la tua infrastruttura, parliamone. Fonti e riferimenti: #EuroStack: European Strategic Sovereign Digital Infrastructures — A Pitch Document (10 gennaio 2025; contributi di R. Berjon, C. Caffarra, F. Bonfiglio, V. Bertola, S. Toffaletti, K. Zenner e altri); iniziativa EuroStack presentata al Parlamento Europeo (settembre 2024); Rapporto Draghi sulla competitività europea (settembre 2024). ### [Accedere in modo sicuro a un VPS via SSH da Linux o macOS](https://www.lymphatechnologies.com/it/vps-ssh-chiavi-linux-macos) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Guide pratiche · Tag: VPS, SSH, ssh-keygen, Linux, macOS, chiavi SSH, sicurezza > Su Linux e macOS servono due comandi: ssh-keygen per creare la coppia di chiavi, ssh-copy-id per portare quella pubblica sul VPS. Da lì in poi, niente più password da digitare — né da farsi indovinare. In questo articolo - Prerequisiti - Come funziona l'accesso tramite chiavi SSH - Step 1 — Creazione delle chiavi con ssh-keygen - Step 2 — Copiamo la chiave sul VPS - Conclusioni ← Tutti gli articoli Come parte del processo di messa in sicurezza del tuo VPS (vedi l'articolo «Come mettere in sicurezza un VPS con sistema operativo Ubuntu Linux»), l'accesso SSH tramite nome utente e password potrebbe essere un elemento critico per la sicurezza. Tendenzialmente si cerca di utilizzare password facili da memorizzare (anche se contengono caratteri speciali, esempio Ci@oM0nd0): questo può esporti a tentativi d'accesso da parte di utenti malintenzionati — utilizzando la tecnica del brute force, infatti, è possibile trovare la tua password. Questa tecnica d'attacco si basa sostanzialmente sul provare ad accedere al server utilizzando un database di password conosciute, finché non si riesce a trovare quella corretta. Se hai seguito la guida indicata all'inizio di questo articolo, hai già configurato un utente senza privilegi che può utilizzare sudo e hai installato Fail2ban per tenere alla larga i tentativi di accesso non desiderati. Con i prossimi step andremo ad aumentare ulteriormente la sicurezza del VPS. Prerequisiti - Un VPS con sistema operativo Linux - Un utente con privilegi adeguati, ovvero sudo (in questo esempio si chiama utente_vps) - Il proprio computer deve utilizzare macOS o una qualsiasi distribuzione basata su Linux - L'applicazione ssh-keygen, normalmente presente su Linux e macOS - L'applicazione ssh-copy-id, normalmente presente su Linux e macOS In questa guida vedremo come creare la coppia di chiavi SSH utilizzando ssh-keygen, che è parte di OpenSSH. Come funziona l'accesso tramite chiavi SSH Prima di partire, facciamo un piccolo accenno al funzionamento. Una coppia di chiavi SSH è costituita, per l'appunto, da due chiavi crittografiche, una pubblica e una privata, utilizzate per autenticare un client su un server SSH. La chiave privata viene conservata dal client e deve essere tenuta al sicuro e non divulgata: se viene compromessa, persa o rubata consentirà a chi ne è in possesso di accedere al server. La corrispondente chiave pubblica può essere condivisa senza alcuna conseguenza, oltre che essere normalmente caricata sul server a cui si vuole accedere. Quest'ultima, infatti, viene utilizzata per criptare i «messaggi» che solo la chiave privata può decriptare. In una configurazione standard, la chiave pubblica viene inserita all'interno del file authorized_keys presente nella cartella ~/.ssh/ di ogni utente abilitato. Quando un client prova a collegarsi in SSH sul server, il servizio verifica se l'utente è in possesso della chiave privata: in caso di esito positivo sarà garantito l'accesso. Step 1 — Creazione delle chiavi con ssh-keygen - Apri l'applicazione Terminale - Digita il comando: $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/tuo_utente_macos/.ssh/id_rsa): oppure, se sei su Linux: Enter file in which to save the key (/home/tuo_utente_linux/.ssh/id_rsa): Ti chiederà dove salvare la coppia di chiavi: puoi lasciare il percorso che ti propone o sceglierne uno che preferisci. Nel caso in cui dovesse esistere già una coppia di chiavi, comparirà il messaggio: /Users/tuo_utente_macos/.ssh/id_rsa already exists. Overwrite (y/n)? In questo caso sta a te decidere se sovrascriverle o se interrompere la procedura e ripeterla cambiando il percorso di salvataggio delle nuove chiavi. - Per una maggiore sicurezza puoi specificare anche una passphrase, che dovrai inserire ogni volta che userai le chiavi. Sta a te decidere: se premi INVIO senza scrivere nulla, non ti servirà alcuna password. A questo punto abbiamo creato la coppia di chiavi, salvata nel percorso indicato all'inizio della procedura (normalmente la directory nascosta .ssh all'interno del tuo profilo utente): nell'esempio le puoi trovare in /Users/tuo_utente_macos/.ssh/ oppure /home/tuo_utente_linux/.ssh/. All'interno della cartella troverai due file, id_rsa e id_rsa.pub: come suggerisce il nome, id_rsa.pub è la chiave pubblica, che dovrà essere caricata sul tuo VPS, mentre id_rsa è la chiave privata e non dovrà assolutamente essere condivisa. Step 2 — Copiamo la chiave sul VPS Procediamo alla copia della chiave pubblica sul VPS. In questo caso ci viene in aiuto il comando ssh-copy-id: dall'applicazione Terminale sul tuo macOS o Linux, digita: $ ssh-copy-id Nome_Utente@IPv4_del_VPS /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/tuo_utente_macos/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys Nome_Utente@IPv4_del_VPS's password:In ogni caso devi inserire la password del tuo utente sul VPS per confermare la copia. Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'Nome_Utente@IPv4_del_VPS'" and check to make sure that only the key(s) you wanted were added.Se è stato fatto tutto correttamente, collegandoti ora in SSH sul VPS con l'utente senza privilegi accederai direttamente alla console remota senza che venga richiesta la password — salvo che tu non abbia impostato la passphrase al momento della creazione delle chiavi: in quel caso non userai la password del tuo utente sul VPS, bensì la passphrase che hai deciso di impostare. Conclusioni A questo punto potrai fare accesso al tuo VPS con un pizzico di sicurezza in più. C'è un ulteriore accorgimento che puoi mettere in campo: ora che le chiavi funzionano, puoi disabilitare del tutto l'accesso con password al servizio SSH. Guida pubblicata originariamente sul blog di VPS GREEN, il servizio VPS sul nostro cloud privato green. ### [Accedere in modo sicuro a un VPS via SSH da Windows](https://www.lymphatechnologies.com/it/vps-ssh-chiavi-windows) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Guide pratiche · Tag: VPS, SSH, chiavi SSH, sicurezza, PuTTY, Windows > Le password si indovinano, le chiavi crittografiche no. Come generare una coppia di chiavi SSH con PuTTY su Windows, caricare la chiave pubblica sul VPS e collegarsi senza più digitare password. In questo articolo - Prerequisiti - Step 1 — Installiamo PuTTY - Step 2 — Creazione delle chiavi con PuTTYgen - Step 3 — Copiamo la chiave pubblica sul VPS - Step 4 — Colleghiamoci in SSH usando la chiave privata ← Tutti gli articoli Come parte del processo di messa in sicurezza del tuo VPS (vedi l'articolo «Come mettere in sicurezza un VPS con sistema operativo Ubuntu Linux»), l'accesso SSH tramite nome utente e password potrebbe essere un elemento critico per la sicurezza. Tendenzialmente si cerca di utilizzare password facili da memorizzare (anche se contengono caratteri speciali, esempio Ci@oM0nd0): questo può esporti a tentativi d'accesso da parte di utenti malintenzionati — utilizzando la tecnica del brute force, infatti, è possibile trovare la tua password. Questa tecnica d'attacco si basa sostanzialmente sul provare ad accedere al server utilizzando un database di password conosciute, finché non si riesce a trovare quella corretta. Se hai seguito la guida indicata all'inizio di questo articolo, hai già configurato un utente senza privilegi che può utilizzare sudo e hai installato Fail2ban per tenere alla larga i tentativi di accesso non desiderati. Con i prossimi step andremo ad aumentare ulteriormente la sicurezza del VPS. Prerequisiti - Un VPS con sistema operativo Linux - Un utente con privilegi adeguati, ovvero sudo (in questo esempio si chiama utente_vps) - Il proprio computer deve utilizzare come sistema operativo Microsoft Windows In questa guida vedremo come creare la coppia di chiavi SSH utilizzando PuTTY. Step 1 — Installiamo PuTTY - Dalla pagina ufficiale dello sviluppatore di PuTTY, scarichiamo l'installer per Windows - Una volta scaricato il pacchetto facciamo doppio clic per far partire l'installazione; di default PuTTY sarà installato nella directory C:\Program Files\PuTTY\ - Una volta terminato il processo di installazione, clicca su Finish per chiudere il wizard Step 2 — Creazione delle chiavi con PuTTYgen - Per lanciare PuTTYgen usa il metodo che preferisci; nell'esempio useremo la barra di ricerca di Windows, quindi digitiamo PuTTYgen - Clicchiamo con il tasto destro su PuTTYgen e selezioniamo «Esegui come amministratore» - Nella finestra di PuTTY Key Generator, clicca sul pulsante «Generate» e muovi il cursore del mouse all'interno della finestra, finché la barra verde non arriva alla fine. Il movimento del mouse serve a generare numeri casuali che PuTTYgen utilizzerà per la creazione del certificato. - Salva le chiavi pubblica e privata (tasti «Save public key» e «Save private key») nel percorso che desideri, avendo cura di specificare che la chiave privata sarà senza passphrase (per ora). A questo punto avrai ottenuto i tuoi certificati, esempio: mypub_key.pub e mypriv_key.ppk. Fai attenzione a non modificare le estensioni dei file: il certificato pubblico avrà estensione .pub, quello privato .ppk. Lascia aperto PuTTYgen per ora. Step 3 — Copiamo la chiave pubblica sul VPS Ora che abbiamo la nostra coppia di chiavi, è giunto il momento di copiare la chiave pubblica sul tuo VPS. Lancia putty.exe (o dal prompt dei comandi puoi utilizzare direttamente ssh) e collegati al tuo VPS tramite indirizzo IPv4, utilizzando l'utente con privilegi sudo (nel nostro esempio si chiama utente_vps). Dalla finestra di PuTTY Key Generator, seleziona e copia tutto il contenuto del campo «Public key for pasting into OpenSSH authorized_keys file:» (assicurati di aver selezionato tutto: il campo ha una barra di scorrimento). Torna sulla sessione SSH aperta prima e, dalla home di utente_vps, posizionati dentro la cartella .ssh: utente_vps@mio_vps:~$ cd .ssh/Se per caso la cartella non esiste non preoccuparti, basta crearla con: utente_vps@mio_vps:~$ mkdir .ssh utente_vps@mio_vps:~$ cd .ssh/A questo punto, usando l'editor di testi nano, puoi creare o modificare il file authorized_keys dentro la cartella .ssh: incolla il testo copiato in precedenza (la chiave pubblica) senza introdurre nient'altro (spazi o invii). Per salvare il file usa la combinazione di tasti CTRL+X ed eventualmente conferma con Y qualora ti chiedesse se vuoi sovrascrivere il file. Step 4 — Colleghiamoci in SSH usando la chiave privata A questo punto ritorna sul programma PuTTY avendo cura di reinserire l'IP del tuo VPS e l'eventuale porta SSH (per modificare la porta 22 standard leggi l'articolo «Come mettere in sicurezza un VPS con sistema operativo Ubuntu Linux») e nella colonna di sinistra cerca l'opzione «Connection > SSH > Credentials». Nella sezione di destra, alla voce «Private key file for authentication», clicca sul pulsante «Browse» e indica come file la tua chiave privata (estensione .ppk) generata prima. Ritorna nella «Session»; se preferisci, puoi inserire un nome nel campo «Saved Sessions» e cliccare sul tasto «Save» per evitare di dover rifare ogni volta la procedura. A questo punto non ti resta che cliccare su «Open». Inserito il nome utente e premuto INVIO, ti apparirà la console del tuo VPS senza bisogno di inserire la password, in modo sicuro. Il passo successivo, per chiudere il cerchio, è disabilitare del tutto l'accesso con password. Guida pubblicata originariamente sul blog di VPS GREEN, il servizio VPS sul nostro cloud privato green. ### [Come installare la GUI sul tuo VPS Ubuntu Server](https://www.lymphatechnologies.com/it/vps-ubuntu-desktop-gui) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Guide pratiche · Tag: VPS, Ubuntu, GUI, desktop, GNOME, sysadmin > Ubuntu Server nasce senza interfaccia grafica, e di solito è la scelta giusta. Ma quando uno strumento rende meglio con una GUI, installare un ambiente desktop è questione di tre comandi — e di sapere quale scegliere. In questo articolo - Prerequisiti - Aggiornamento della libreria di pacchetti - Installazione del display manager - Installa la GUI su Ubuntu Server - Altre possibilità - Rimuovere una GUI o un display manager - Conclusione ← Tutti gli articoli Ubuntu Server è una variante del sistema operativo Ubuntu che non include un'interfaccia utente grafica (GUI) per impostazione predefinita. Le applicazioni GUI consumano le risorse di sistema necessarie per le attività orientate al server, quindi le distribuzioni server Linux di solito evitano una GUI a favore del terminale a riga di comando. Alcuni strumenti, tuttavia, funzionano meglio e sono più facili da gestire con una GUI. Se utilizzi uno strumento con una GUI, l'installazione di un ambiente desktop può migliorare l'esperienza di lavoro con il server. Prerequisiti - Un VPS con sistema operativo Ubuntu Linux Server - Un utente con privilegi adeguati, ovvero sudo o direttamente root - Il gestore di pacchetti apt, normalmente incluso nel sistema operativo Aggiornamento della libreria di pacchetti Per prima cosa assicuriamoci che la libreria dei pacchetti sia aggiornata. Per fare questo basta connettersi al VPS via SSH o via console e lanciare il comando: $ sudo apt update && sudo apt upgradeApt risponderà con una serie di informazioni, tra cui il numero di pacchetti che si vogliono aggiornare. È bene ricordare (salvo esigenze diverse) di mantenere sempre aggiornato il proprio VPS: si procederà quindi a confermare tutti i pacchetti proposti, come nell'esempio: 6 upgraded, 8 newly installed, 0 to remove and 0 not upgraded. 6 standard LTS security updates Need to get 54.5 MB of archives. After this operation, 242 MB of additional disk space will be used. Do you want to continue? [Y/n] YInstallazione del display manager Un display manager è un'applicazione che avvia il display server, avvia il desktop e gestisce l'autenticazione dell'utente. GDM3, quello predefinito, è un display manager ad alta intensità di risorse: se vuoi conservare le risorse di sistema, prendi in considerazione uno strumento più leggero, come SLiM o LightDM. In questo caso utilizzeremo GDM3. $ sudo apt install gdm3Installa la GUI su Ubuntu Server Con un display manager installato, procedi con l'installazione di una GUI. Il desktop Ubuntu predefinito è una versione modificata dell'ambiente desktop GNOME. $ sudo apt install ubuntu-desktopUltimata l'installazione di tutti i pacchetti, effettua il riavvio del VPS: $ sudo rebootAltre possibilità Esistono tanti altri desktop compatibili con Ubuntu, tra i quali: - GNOME è uno dei più solidi e completi desktop per Linux: un modo semplice ed elegante per utilizzare il tuo VPS, progettato per offrire la migliore esperienza possibile. Per installare la versione «vanilla» di GNOME: $ sudo apt install vanilla-gnome-desktop - KDE Plasma è un ambiente desktop flessibile e personalizzabile, che offre coerenza visiva e stile pur rimanendo veloce e reattivo. Per installare KDE Plasma: $ sudo apt install kde-plasma-desktop - XFCE è progettato per essere leggero e intuitivo. Il pacchetto principale, xfce4-session, fornisce un ambiente essenziale; se vuoi l'esperienza completa installa anche il pacchetto xfce4-goodies: $ sudo apt-get install xfce4-session xfce4-goodies - MATE è un fork di GNOME 2 e una popolare interfaccia grafica progettata per ridurre il consumo di risorse: $ sudo apt install ubuntu-mate-desktop - LXDE è un ambiente desktop con una GUI molto leggera. Usa LXDE se hai bisogno di un'interfaccia grafica ma vuoi minimizzare l'impatto sulla memoria di sistema e sulla CPU: $ sudo apt install lxde Rimuovere una GUI o un display manager Per rimuovere una o più componenti è necessario, da console e sempre con diritti di sudo o root, lanciare i comandi: $ sudo apt remove [display-manager] [desktop-environment]Ad esempio, se volessimo eliminare il desktop predefinito basterebbe scrivere sudo apt remove ubuntu-desktop. Anche se non strettamente necessario, è consigliato effettuare il riavvio del VPS oltre alla cancellazione dei pacchetti non più necessari: $ sudo apt autoremoveConclusione Se hai lavorato a lungo con i sistemi operativi Microsoft, può essere difficile dover lavorare in un'interfaccia a riga di comando. Fortunatamente Ubuntu, come molti sistemi Linux, è dotato di eccezionali ambienti desktop grafici, ricchissimi di applicazioni, tutti da provare. Guida pubblicata originariamente sul blog di VPS GREEN, il servizio VPS sul nostro cloud privato green. ### [Come mettere in sicurezza un VPS con sistema operativo Ubuntu Linux](https://www.lymphatechnologies.com/it/vps-sicurezza-ubuntu) Pubblicato: 2026-07-16 · Autore: Redazione Lympha · Categorie: Guide pratiche · Tag: VPS, Ubuntu, hardening, SSH, firewall, Fail2ban, sicurezza > Un VPS appena consegnato è come il produttore l'ha fatto: funzionante, non blindato. Sei accorgimenti di base — aggiornamenti, porta SSH, utenti senza privilegi, root disattivato, Fail2ban e password — comando per comando. In questo articolo - Prerequisiti - Aggiorna il tuo sistema operativo - Modifica la porta di default della Secure Shell - Non usare root per tutto: crea un account con diritti limitati - Disattiva l'accesso dell'utente root al server - Qualche protezione in più… Fail2ban - Cambia spesso le password - Conclusione ← Tutti gli articoli Appena prese in mano le redini del comando è necessario assicurarsi che il tuo VPS abbia almeno un minimo di difese contro gli attacchi esterni. Nessun sistema è perfetto, così come nessun sistema è veramente impenetrabile; ciò però non esula dal mettere in atto una serie di accorgimenti tecnici quantomeno mirati a evitare che anche gli attacchi più semplici vadano a segno. Per politica di VPS GREEN, i VPS vengono rilasciati con il sistema operativo prescelto così come lo rilascia il produttore. Questo chiaramente comporta un minimo di operazioni, rivolte alla sicurezza, prima di poter installare i propri programmi. Come nella famosa frase del fumetto di Spider-Man: l'amministratore di sistema ha grandi poteri, ma anche grandi responsabilità. Lo staff tecnico di VPS GREEN non è autorizzato ad accedere ai tuoi VPS; d'altro canto, è sempre disponibile per darti supporto sul sistema operativo. Prerequisiti - Un VPS con sistema operativo Linux - Un utente con privilegi adeguati, ovvero sudo o direttamente root - Un editor di testo, nel nostro esempio useremo nano - Il gestore di pacchetti apt, normalmente incluso nel sistema operativo - [Consigliato] Un firewall, nel nostro esempio useremo ufw Aggiorna il tuo sistema operativo La prima delle responsabilità come sysadmin è garantire quotidianamente sicurezza e funzionalità del sistema operativo e delle applicazioni. Gli sviluppatori di distribuzioni e di sistemi operativi propongono frequenti aggiornamenti di pacchetti, molto spesso per ragioni di sicurezza: garantire l'aggiornamento della distribuzione o del sistema operativo è un elemento essenziale per proteggere il VPS. Può capitare che i produttori delle applicazioni pubblichino un elenco di pacchetti di sistema o librerie compatibili o non compatibili: prima di aggiornare componenti specifiche assicurati che non vi siano incompatibilità con le applicazioni che hai installato o dovrai installare sul VPS. Per prima cosa assicuriamoci che la libreria dei pacchetti sia aggiornata. Basta connettersi al VPS via SSH o via console e lanciare il comando: $ sudo apt update && sudo apt upgradeApt risponderà con una serie di informazioni, tra cui il numero di pacchetti da aggiornare. È bene ricordare (salvo esigenze diverse) di mantenere sempre aggiornato il proprio VPS, confermando i pacchetti proposti, come nell'esempio: 6 upgraded, 8 newly installed, 0 to remove and 0 not upgraded. 6 standard LTS security updates Need to get 54.5 MB of archives. After this operation, 242 MB of additional disk space will be used. Do you want to continue? [Y/n] YModifica la porta di default della Secure Shell Anche se non obbligatorio, potrebbe essere una buona cosa modificare la porta standard dell'SSH, normalmente impostata sulla 22. Questa operazione, tutto sommato banale, evita gli attacchi da parte di robot che normalmente punterebbero alla porta standard. La procedura è piuttosto semplice: basta modificare il file di configurazione del servizio con l'editor di testo scelto. $ sudo nano /etc/ssh/sshd_configCerca la stringa «Port 22» e modifica il numero con la porta che preferisci, avendo cura però di non utilizzare una porta usata da un altro protocollo di sistema. Per convenzione le porte tra la 49152 e la 65535 sono considerate libere, non assegnate ad alcun protocollo o applicazione specifica. # This is the sshd server system-wide configuration file. # Port 22 Port 4422Salva le modifiche e riavvia il servizio SSH: $ sudo systemctl restart sshdAppena riavviato il servizio non dovresti notare differenze, ma è chiaro che la prossima volta che ti connetterai dovrai usare la stringa: ssh Nome_Utente@IPv4_del_VPS -p Numero_della_portaSe stai utilizzando un firewall, ricordati di aggiungere la nuova porta e permettere il traffico in ingresso. Ad esempio, se decidessi di utilizzare ufw esegui il comando: $ sudo ufw allow 4422 $ sudo ufw show added Added user rules (see 'ufw status' for running firewall): ufw allow 25565 ufw allow 22 ufw allow 4422In questo modo aggiungerai la nuova porta scelta per SSH e verificherai quali porte sono configurate sul firewall. Se desideri, oltre a non utilizzare la porta 22, anche bloccare il traffico su di essa, puoi impostare il deny: $ sudo ufw deny 22 $ sudo ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 25565 ALLOW IN Anywhere 22 DENY IN Anywhere 4422 ALLOW IN Anywhere 25565 (v6) ALLOW IN Anywhere (v6) 22 (v6) DENY IN Anywhere (v6) 4422 (v6) ALLOW IN Anywhere (v6)Il parametro status verbose ti permette di avere una panoramica della configurazione del firewall. Se tutto rispetta ciò che vuoi ottenere, assicurati che il servizio firewall sia attivo: $ sudo ufw enableNon usare root per tutto: crea un account con diritti limitati È buona regola generale non utilizzare sempre l'utente root, specialmente per operazioni che non richiedono privilegi così elevati. Per creare un nuovo utente, utilizza questo comando: $ sudo adduser Nome_del_Nuovo_UtenteIl sistema richiederà di specificare la password (si consiglia sempre di non utilizzare password deboli) e altre informazioni (nome, ecc.). Una volta creato, potrà essere da subito utilizzato per accedere al VPS. Se l'utente creato dovrà eseguire operazioni che richiedono privilegi, si potrà procedere in due modi distinti: - utilizzare il comando $ su root per spostarsi momentaneamente sull'utente root; - aggiungere l'utente all'elenco dei «sudoers», una speciale lista di utenti che possono elevare i propri privilegi attraverso il comando sudo. Mentre il primo metodo non necessita di ulteriori approfondimenti, il secondo prevede l'aggiunta del nuovo utente alla lista. Per autorizzarlo è necessario lanciare da root: $ echo "Nome_del_Nuovo_Utente ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/Nome_del_Nuovo_UtenteIn questo modo utilizzeremo l'utente root per creare un file dedicato al nuovo utente in sudoers.d/, che sarà letto da sudo e autorizzerà il nostro nuovo utente. A questo punto possiamo connetterci via SSH al VPS usando il nuovo utente anche per operazioni che richiedono privilegi particolari, come ad esempio: $ sudo apt updateDisattiva l'accesso dell'utente root al server L'utente root viene creato di default sui sistemi GNU/Linux e di solito rappresenta l'utente con il livello di accesso più elevato nel sistema. È fortemente sconsigliato, oltre che pericoloso, lasciare che il tuo VPS sia accessibile esclusivamente come utente root, perché questo account può effettuare operazioni senza alcun freno, quindi anche dannose e irreversibili. È quindi fortemente consigliato disattivare l'accesso diretto degli utenti root tramite i protocolli di accesso remoto (RDP, VNC, ecc.) in generale, e non solo per il protocollo SSH. La procedura è piuttosto semplice: basta modificare il file di configurazione del servizio con l'editor di testo scelto. $ sudo nano /etc/ssh/sshd_configCerca la stringa «PermitRootLogin yes» e imposta «no»: # Authentication: # PermitRootLogin yes PermitRootLogin noSalva le modifiche e riavvia il servizio SSH: $ sudo systemctl restart sshdDa questo momento qualsiasi tentativo di connessione via SSH con root@IPv4_del_VPS fallirà. Ricordati di creare un utente da utilizzare per l'accesso remoto. In ogni caso root potrà sempre essere utilizzato per l'accesso via console web di VPS GREEN. Qualche protezione in più… Fail2ban Fail2ban è estremamente utile a prevenire tentativi di intrusione e può rappresentare quindi un piccolo accorgimento in più per la sicurezza del tuo VPS. Lo scopo di Fail2ban è bloccare gli indirizzi IP da cui i robot o gli aggressori cercano di accedere al tuo sistema, in particolare se ad attaccarti è un robot che tenta un brute force (ovvero tenta di connettersi a un servizio provando password casuali o prese da un vocabolario). L'installazione è semplicissima: $ sudo apt install fail2banL'applicazione è già perfettamente funzionante così com'è appena installata. Se preferisci personalizzare qualche parametro, puoi modificare la configurazione nel file /etc/fail2ban/jail.conf; per approfondire ti consigliamo la documentazione ufficiale sul sito del progetto Fail2ban. Come suggerito nella documentazione, andiamo a creare un nostro file di configurazione: $ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local $ sudo nano /etc/fail2ban/jail.localRicordati che i parametri contrassegnati come [DEFAULT] agiscono a livello globale, su tutti i servizi; questi valori vengono però «sovrascritti» se si inseriscono nelle sezioni dedicate ai singoli servizi. Esempio: # [DEFAULT] bantime = 1h ... [sshd] # To use more aggressive sshd modes set filter parameter "mode" in jail.local: # normal (default), ddos, extra or aggressive (combines all). # See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details. #mode = normal port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s bantime = 3hNel nostro esempio abbiamo definito a livello globale il tempo di ban a 1 ora (bantime = 1h), mentre per il servizio SSH abbiamo impostato un bantime di 3 ore. Per attivare subito le personalizzazioni è necessario riavviare il servizio: $ sudo systemctl restart fail2ban.serviceAttenzione a non scrivere parametri doppi a parità di sezione [DEFAULT] o in qualsiasi [nome_servizio]: altrimenti Fail2ban non partirà, restituendo un errore. Cambia spesso le password È buona norma definire una politica per il cambio password, specialmente per gli utenti che hanno privilegi elevati. Non c'è una regola definita ma, in linea generale, più spesso si cambia la password (più complessa che si può) e meglio è. Per modificare la password del proprio utente: $ passwdSe la password da cambiare è di un altro utente, bisognerà specificarne il nome: $ sudo passwd rootConclusione Anche se Linux (in generale) è famoso per essere tra i sistemi operativi più sicuri, presenta alcune vulnerabilità. Molte minacce alla sicurezza possono sfociare in perdita o danneggiamento dei dati, ovvero costi e tempo per ripristinare. Ad esempio: - Malware — un software intrusivo progettato intenzionalmente per danneggiare i sistemi operativi. - Sniffing — una pratica volta a intercettare pacchetti in transito da e verso applicazioni non protette. - Brute force — un attacco volto a indovinare password tramite generazione automatica o vocabolari. - SQL injection — una pratica che sfrutta debolezze nel codice di un'applicazione web per ottenere l'accesso al database del server. - Cross-site scripting (XSS) — un attacco lato client durante il quale viene inserito codice dannoso in un sito web. - No function-level control — un software può causarlo non verificando correttamente i diritti di accesso, fornendo privilegi di root a utenti generici. - Broken authentication — furto di identità che di solito si verifica a causa di dati non crittografati, password deboli o timeout di sessione impostati in modo errato. Prima di implementare qualsiasi misura di sicurezza, renditi consapevole degli elementi che dovresti monitorare. Eccone alcuni: - Sicurezza dell'hosting VPS - Software installato sul server - Connessioni via SSH e altri protocolli abilitati sul server - Accesso root e login - Password, diritti e privilegi dell'utente - Firewall - Connessioni via FTP e altri protocolli di scambio file abilitati sul server - File di log Non è impossibile proteggere un server: se hai seguito questa guida, un primo passo lo hai già fatto. I prossimi: l'accesso con chiavi SSH e la disattivazione dell'accesso con password. E se la sicurezza vuoi verificarla, non solo dichiararla: è il nostro mestiere. Guida pubblicata originariamente sul blog di VPS GREEN, il servizio VPS sul nostro cloud privato green.