init.d - consulenza IT, DevOps e sviluppo software

INP sostituisce FID tra i Core Web Vitals: cosa misura e cosa monitorare

Alessandro Corbelli — Tue, 12 Mar 2024 00:00:00 GMT

Dal 12 marzo 2024 cambia una delle metriche con cui Google valuta la qualità di una pagina web. Una metrica chiamata FID viene ritirata e sostituita da un'altra, INP. Il cambiamento riguarda i Core Web Vitals, cioè l'insieme di indicatori che misurano l'esperienza di caricamento e uso di un sito. Non è una piccola modifica tecnica di nicchia: tocca sia la sensazione che prova chi usa il sito, sia il modo in cui Google tiene conto delle prestazioni nel posizionamento. Vale quindi la pena capire cosa cambia davvero, in parole semplici.

Cosa sono i Core Web Vitals

I Core Web Vitals sono un piccolo gruppo di metriche con cui Google prova a misurare, con numeri concreti, quanto è piacevole usare una pagina. Non giudicano il contenuto né la grafica: guardano il comportamento tecnico. Storicamente sono tre, ognuna con una domanda semplice dietro.

LCP (Largest Contentful Paint): quanto tempo passa prima che compaia il contenuto principale, che dipende anche da quanto è rapida la prima risposta del server? Considerata buona sotto i 2,5 secondi.
CLS (Cumulative Layout Shift): quanto gli elementi "saltano" mentre la pagina si carica? Considerata buona sotto 0,1.
La terza riguarda la reattività, cioè quanto la pagina risponde in fretta quando si tocca o si clicca qualcosa. È proprio questa a cambiare.

Fino a marzo 2024 la reattività veniva misurata con FID (First Input Delay). Da quella data viene misurata con INP (Interaction to Next Paint).

Cos'è INP e cosa misura

INP sta per Interaction to Next Paint, che si può tradurre come "dall'interazione al prossimo disegno sullo schermo". Misura una cosa che chiunque ha provato senza saperle dare un nome: quel piccolo ritardo tra il momento in cui si clicca un pulsante, si apre un menù o si spunta una casella, e il momento in cui lo schermo mostra che qualcosa è successo.

Quando quel ritardo è breve, il sito sembra pronto e vivo. Quando è lungo, resta la sensazione di aver premuto a vuoto: si è tentati di cliccare di nuovo, e la pagina dà l'impressione di essere bloccata o rotta, anche quando non lo è.

Secondo la documentazione di web.dev, il tempo di un'interazione si scompone in tre parti:

il ritardo di input, cioè il tempo prima che il browser inizi a eseguire il codice legato all'interazione (spesso perché è occupato con altro);
il tempo di elaborazione, cioè quanto ci mette il codice a fare il proprio lavoro in risposta al clic;
il ritardo di presentazione, cioè il tempo che serve poi per disegnare il risultato aggiornato sullo schermo.

INP tiene conto di tutte e tre le parti. Contano come interazioni i clic con il mouse, i tocchi su schermo e la pressione dei tasti; non contano invece lo scorrimento della pagina né il semplice passaggio del puntatore sopra un elemento.

::cta{variant="inline" title="Il tuo sito risponde subito o l'utente sente quel piccolo ritardo dopo ogni clic?" text="Misuriamo l'INP reale del tuo sito con dati di campo e individuiamo dove il browser perde tempo." button="Chiedi una misurazione →"}

Cosa cambia rispetto a FID

Il vecchio FID misurava solo il ritardo di input della prima interazione della visita. Aveva due limiti importanti. Il primo: guardava soltanto il primo tocco, quindi se il primo clic era rapido ma tutti i successivi erano lenti, il punteggio restava buono pur non riflettendo l'esperienza reale. Il secondo: misurava solo l'attesa iniziale, ignorando quanto tempo il codice impiegava poi a rispondere e a mostrare il risultato.

INP corregge entrambi i punti. Osserva tutte le interazioni durante l'intera visita, non solo la prima, e considera l'intero percorso, dal clic fino a quando lo schermo si aggiorna. Il valore riportato è vicino all'interazione più lenta osservata (escludendo i casi rari e isolati), così da rappresentare l'esperienza peggiore che l'utente ha davvero incontrato, non quella migliore. In pratica è una misura più onesta e più difficile da "far sembrare buona" per caso.

La soglia: buona sotto i 200 ms

Il riferimento pratico è semplice. La documentazione di web.dev indica tre fasce:

buona: INP pari o inferiore a 200 millisecondi;
da migliorare: tra 200 e 500 millisecondi;
scarsa: oltre 500 millisecondi.

Un millisecondo è un millesimo di secondo, quindi 200 ms sono un quinto di secondo: la soglia che separa una pagina che sembra reattiva da una che inizia a dare la sensazione di lentezza.

Un dettaglio importante su come si legge il valore: non si guarda l'utente più fortunato, ma il 75° percentile delle visite reali, misurato separatamente per dispositivi mobili e desktop. In parole povere, per essere considerato buono un sito deve rispondere sotto i 200 ms per almeno il 75% delle visite. È un modo per non nascondere i problemi dietro la media: conta che l'esperienza sia buona per la grande maggioranza, non solo in condizioni ideali.

Perché conta per la SEO e il calendario del cambiamento

I Core Web Vitals non servono solo a fare ordine: sono uno dei fattori che Google considera per l'esperienza di pagina, e quindi possono influire sul posizionamento nei risultati di ricerca. Non sono l'unico né il più importante criterio, ma a parità di contenuto un sito reattivo parte avvantaggiato rispetto a uno che risponde in ritardo. Il legame con la SEO è quindi indiretto ma reale, e passa soprattutto dall'esperienza offerta a chi visita davvero il sito.

Sul fronte pratico, il passaggio è già avvenuto: dal 12 marzo 2024 INP è a tutti gli effetti un Core Web Vital e FID non lo è più. Google ha annunciato il cambiamento con largo anticipo, a maggio 2023, e la metrica era disponibile in forma sperimentale già da prima. Il ritiro di FID è graduale sul piano degli strumenti: è stato rimosso subito dal report principale di Search Console, mentre altri strumenti hanno previsto un periodo di transizione per dare tempo a chi sviluppa di adeguarsi. Chi teneva d'occhio FID, insomma, deve semplicemente spostare l'attenzione su INP.

Come si tiene sotto controllo e si migliora

La prima cosa utile è misurare con dati reali. INP si valuta al meglio sul campo, cioè sulle visite effettive, non solo in laboratorio: strumenti come Search Console (nel report Core Web Vitals), PageSpeed Insights e i dati CrUX di Chrome mostrano il valore raccolto dagli utenti veri, sui loro dispositivi e sulle loro connessioni.

Sul piano delle cause, un INP alto in genere significa che il dispositivo dell'utente è troppo occupato a eseguire codice per rispondere in fretta alle interazioni. Le leve generali seguono di conseguenza, e agiscono soprattutto sul lato del browser.

Alleggerire il lavoro del browser. Meno codice viene eseguito in risposta a un clic, prima lo schermo può aggiornarsi. Ridurre il lavoro superfluo che si attiva a ogni interazione, per esempio affidando ad ancoraggi CSS nativi posizionamenti oggi gestiti con script su misura, è spesso l'intervento più efficace.
Spezzare le operazioni lunghe. Un compito pesante e ininterrotto tiene occupato il browser e blocca le risposte. Suddividerlo in parti più piccole lascia spazio per gestire le interazioni tra un pezzo e l'altro.
Contenere script e componenti di terze parti. Widget, tracker e strumenti esterni aggiungono lavoro che non sempre è visibile ma che pesa sulla reattività. Vale la pena verificarne il costo reale: su un e-commerce pieno di moduli è spesso il primo posto dove guardare.
Dare priorità a ciò che l'utente vede e tocca. Rimandare le attività non urgenti, così che le interazioni immediate abbiano la precedenza, aiuta a tenere basso il ritardo percepito.

Come sempre in questi casi, conviene misurare prima e dopo ogni modifica: la reattività dipende da tanti fattori e la strada giusta è capire dove il browser perde tempo, invece di cambiare tutto a caso.

In sintesi

Dal 12 marzo 2024 la reattività di una pagina si misura con INP al posto di FID. INP guarda tutte le interazioni della visita e considera l'intero percorso dal clic al risultato visibile, offrendo una fotografia più realistica di come il sito risponde. La soglia da tenere a mente è 200 millisecondi per almeno il 75% delle visite. Conta per due motivi che si tengono: un sito più reattivo è più piacevole da usare e, di riflesso, parte con qualche vantaggio anche lato SEO. Il punto di partenza resta lo stesso: misurare con dati reali, capire dove nasce il ritardo e intervenire sul livello giusto.

::cta{title="Vuoi portare l'INP sotto i 200 millisecondi?" text="Interveniamo su script di terze parti, codice lato client e configurazione del server per rendere il sito reattivo, dal primo byte alla singola interazione." button="Parliamone →"}

Fonti

Chrome attiva di default la crittografia post-quantum in TLS: cosa cambia e cosa può rompersi

Alessandro Corbelli — Thu, 16 May 2024 00:00:00 GMT

Da qualche versione, il browser Chrome protegge le connessioni sicure con un pezzo di crittografia nuovo, pensato per resistere ai futuri computer quantistici. È attivo per impostazione predefinita, quindi la maggior parte delle persone non deve fare nulla e non si accorge di niente. Per chi gestisce server e reti, però, c'è un dettaglio importante: questo cambiamento ha fatto emergere problemi latenti in alcuni apparati di rete mal implementati, con la conseguenza che qualche connessione smette di funzionare dopo l'aggiornamento del browser. Vale la pena capire cosa è cambiato, perché, e cosa conviene verificare.

La notizia in breve

Chrome ha abilitato di default, sui computer desktop, uno scambio di chiavi "ibrido" resistente ai computer quantistici a partire dalla versione 124, uscita nella primavera del 2024. Lo scambio di chiavi è il primo passo di ogni connessione sicura: il momento in cui il browser e il sito si mettono d'accordo su una chiave segreta condivisa, che poi serve a cifrare tutto il resto della conversazione. Tutto questo avviene dentro TLS, il protocollo che sta dietro all'https e al lucchetto che compare nella barra degli indirizzi.

La novità non richiede alcun intervento da parte dell'utente: se il sito la supporta, la connessione parte già protetta; se non la supporta, si usa il metodo di prima. Nessuno deve installare o configurare niente.

Contro quale minaccia: "raccogli ora, decifra dopo"

Per capire perché tutto questo serva bisogna partire da una minaccia dal nome poco rassicurante: harvest now, decrypt later, cioè "raccogli ora, decifra dopo". L'idea è semplice e sgradevole. Oggi il traffico su Internet è cifrato: i dati che viaggiano tra il dispositivo e il sito sono resi illeggibili a chi li intercetta, e la protezione regge perché i computer attuali non hanno la potenza per forzarla in tempi ragionevoli.

I computer quantistici - una tecnologia ancora in sviluppo, basata su principi diversi da quelli dei computer tradizionali - potrebbero un giorno rompere buona parte della crittografia che usiamo adesso. Nessuno sa con certezza se e quando accadrà. Il problema, però, è già attuale: chi intercetta traffico cifrato oggi può registrarlo e archiviarlo, aspettando di poterlo decifrare in futuro. Dati che restano sensibili per molti anni - cartelle cliniche, segreti industriali, comunicazioni riservate - sono quindi a rischio già ora, anche se la macchina capace di aprirli non esiste ancora. Mettere in sicurezza lo scambio di chiavi serve proprio a togliere valore a questa raccolta preventiva.

::cta{variant="inline" title="La tua rete regge un ClientHello più pesante?" text="Verifichiamo firewall, proxy e bilanciatori per capire se sono pronti allo scambio di chiavi post-quantum prima che si rompano da soli." button="Verifica la tua rete →"}

Come funziona: uno scambio di chiavi ibrido

Nella pratica non si è buttata via la crittografia di prima per sostituirla con quella nuova. Si usa un approccio ibrido: si combinano un algoritmo classico, collaudato da anni, e uno post-quantum. La connessione resta protetta finché almeno uno dei due regge. Così, se in futuro si scoprisse una debolezza nell'algoritmo nuovo - cosa non impossibile, visto che è recente - resterebbe la protezione di quello tradizionale; e all'inverso, contro un attacco quantistico, protegge la parte nuova. In pratica, cintura e bretelle insieme.

Lo schema attivato da Chrome si chiama X25519Kyber768. Il nome è ostico, ma dice cosa contiene: X25519 è l'algoritmo classico usato da anni per lo scambio di chiavi, mentre Kyber768 è la parte post-quantum. Kyber, al momento dell'annuncio, era ancora una bozza dello standard poi pubblicato dall'ente statunitense NIST con il nome di ML-KEM, lo stesso ente che in seguito ha scelto HQC come algoritmo di riserva per non dipendere da un solo approccio matematico. Non è quindi l'esperimento di un singolo fornitore, ma un algoritmo su cui l'industria si sta allineando. Nelle versioni successive di Chrome lo schema è stato aggiornato alla versione definitiva dello standard.

L'effetto collaterale: il ClientHello diventa più grande

Ecco la parte che interessa direttamente i sistemisti. La chiave post-quantum occupa molto più spazio di quella classica. Questo gonfia il ClientHello, cioè il primo messaggio con cui il browser si presenta al server all'inizio della connessione. Nel messaggio il browser elenca cosa sa fare, comprese le chiavi che propone per lo scambio, la stessa busta che un'altra estensione recente, l'Encrypted Client Hello, prova a cifrare per nasconderne il contenuto a chi intercetta il traffico.

Con la parte post-quantum, questo primo messaggio diventa abbastanza grande da non entrare più in un singolo pacchetto di rete: viene quindi spezzato in due. Non è gratis: secondo l'annuncio di Google, la maggiore dimensione comporta un aumento di circa il 4% della latenza mediana su tutti gli handshake TLS di Chrome sul desktop. È un costo contenuto, ma reale, ed è una delle ragioni per cui il cambiamento è arrivato prima sul desktop, dove le connessioni sono in genere più veloci.

Perché alcuni apparati si rompono

Il costo in latenza è la parte prevista. Quella imprevista è che, con l'attivazione di default, sono venuti a galla difetti già presenti in diversi prodotti che stanno "in mezzo" alle connessioni. Nel gergo si chiamano middlebox: firewall, proxy, bilanciatori di carico e soprattutto i sistemi di ispezione TLS, cioè apparati che sbirciano o filtrano il traffico cifrato in transito, molto diffusi nelle reti aziendali.

In teoria un cambiamento del genere non dovrebbe rompere nulla. TLS è progettato per essere estensibile: se un apparato incontra un'opzione che non conosce, la regola è ignorarla e proseguire con quelle che conosce. Offrire lo scambio di chiavi post-quantum è quindi retrocompatibile, e i sistemi scritti a norma continuano a funzionare senza modifiche. Il problema è che non tutti sono scritti a norma. Alcuni apparati davano per scontato che il ClientHello fosse piccolo e arrivasse in un solo pacchetto, oppure gestivano male i messaggi di dimensioni inattese. Finché tutti i ClientHello erano piccoli, il difetto non si vedeva. Appena il messaggio è cresciuto e si è spezzato in due pacchetti, quegli apparati hanno iniziato a rifiutare o troncare la connessione.

Il punto da tenere a mente è questo: non è un difetto di Chrome, né della crittografia post-quantum. È un baco preesistente in un apparato di rete, che il cambiamento ha semplicemente reso visibile. Google ha confermato che il rilascio ha portato a galla diversi bug di questo tipo in prodotti di terze parti.

Cosa deve verificare chi gestisce i server

Il sintomo tipico è chiaro: dopo un aggiornamento di Chrome, alcuni utenti non riescono più a raggiungere un sito o un servizio, mentre con browser o versioni diverse tutto va. Se capita, conviene procedere così.

Sospettare il percorso, non il browser. Il problema quasi sempre non è né il client né il server finale, ma qualcosa in mezzo: un proxy, un firewall con ispezione TLS, un bilanciatore, un apparato di sicurezza perimetrale.
Isolare la causa. Chrome mette a disposizione una policy aziendale, PostQuantumKeyAgreementEnabled, che permette di disattivare temporaneamente lo scambio di chiavi post-quantum. Se disattivandola il problema sparisce, la diagnosi è confermata: c'è un apparato che non regge i ClientHello più grandi.
Aggiornare l'apparato colpevole. La soluzione corretta è chiedere al fornitore una versione aggiornata che gestisca correttamente i messaggi grandi. La disattivazione via policy è pensata come rimedio temporaneo, per dare tempo di sistemare, non come stato definitivo.
Non rimandare. Lo scambio di chiavi post-quantum non tornerà indietro, anzi diventerà la norma, tanto che oltre metà del traffico web globale è già cifrata in modo post-quantum. Un apparato che si rompe oggi con Chrome si romperà domani con gli altri browser e con i client aggiornati. Meglio sistemarlo adesso.

In sintesi

Per la maggior parte delle persone non c'è nulla da fare: basta tenere aggiornati browser e sistema operativo, e la protezione arriva da sola. Per chi gestisce infrastrutture il messaggio è duplice. Da un lato è una buona notizia, perché il traffico inizia a essere protetto contro una minaccia concreta anche se ancora futura. Dall'altro è un promemoria: gli apparati di rete che ispezionano o filtrano TLS vanno mantenuti aggiornati e conformi agli standard, perché ogni evoluzione del protocollo, dalla vita sempre più breve dei certificati alla crittografia dello scambio di chiavi, può far emergere scorciatoie prese in passato. Questa è la prima onda, non l'ultima.

::cta{title="Sistemi in mezzo alla connessione da aggiornare?" text="Gestiamo server, firewall e reti aziendali: individuiamo gli apparati che non reggono TLS moderno e li mettiamo a norma prima che smettano di funzionare." button="Mettiamo in sicurezza la rete →"}

Fonti

CSS Anchor Positioning: posizionare tooltip e menu senza JavaScript

Alessandro Corbelli — Tue, 28 May 2024 00:00:00 GMT

Un piccolo riquadro che compare accanto al pulsante giusto per spiegare a cosa serve (un "tooltip", cioè un suggerimento a comparsa). Un menu che si apre proprio sotto la voce che l'ha richiamato. Una scheda informativa agganciata a un'icona. Sono dettagli banali da immaginare, ma sorprendentemente scomodi da realizzare bene su una pagina web. Il motivo è che per anni il browser non ha avuto un modo diretto per dire "colloca questo elemento accanto a quest'altro". A maggio 2024 è arrivata una novità che affronta proprio questo problema: il CSS Anchor Positioning, una funzione che permette di ancorare un elemento a un altro usando solo il CSS, il linguaggio con cui si definisce l'aspetto delle pagine, senza ricorrere a JavaScript.

La notizia in breve

La funzione è arrivata in forma stabile con Google Chrome 125, uscito il 14 maggio 2024, e con Microsoft Edge, che condivide lo stesso motore di rendering (Chromium). Al momento dell'annuncio Firefox e Safari non la supportano ancora: i rispettivi team la stanno implementando. La specifica, inoltre, è ancora una bozza (draft) del CSS Working Group del W3C, l'organismo che definisce gli standard del web: alcuni dettagli potrebbero quindi cambiare. In pratica è una funzione nuova, disponibile per ora in un solo motore di browser. È un dato importante da tenere presente prima di adottarla su un sito in produzione.

Il problema: mettere un elemento accanto a un altro

Per capire perché la notizia conta, serve un passo indietro. Un elemento come un tooltip di solito viene "estratto" dal flusso normale della pagina (con la proprietà CSS position: absolute) e piazzato tramite coordinate. Il guaio è che quell'elemento non sa dove si trova il pulsante a cui dovrebbe stare vicino. E la posizione del pulsante cambia in continuazione: quando la pagina scorre, quando la finestra viene ridimensionata, quando il testo attorno si allunga.

La soluzione, finora, era il JavaScript, il linguaggio di programmazione che gira nel browser. Serviva codice che misurasse la posizione del pulsante, calcolasse le coordinate del tooltip e ripetesse il calcolo a ogni scorrimento o ridimensionamento. Per non riscrivere ogni volta questa logica, si ricorre a librerie specializzate come Floating UI (l'erede di Popper), pensate proprio per gestire questi calcoli e i casi limite, ad esempio far comparire il tooltip sopra il pulsante quando sotto non c'è spazio. Sono strumenti validi, ma hanno un costo: codice in più da caricare e mantenere, e calcoli che, girando a ogni scorrimento, possono appesantire la pagina e peggiorare la reattività misurata da metriche come l'INP.

::cta{variant="inline" title="Il tuo frontend porta ancora librerie JS solo per posizionare tooltip e menu?" text="Valutiamo se puoi già sostituirle con CSS nativo o se serve un ripiego per i browser non ancora supportati." button="Valuta la tua interfaccia →"}

Cosa fa l'anchor positioning

L'anchor positioning ("posizionamento tramite ancora") sposta questo lavoro dentro il browser, sulla stessa scia di altre funzioni che portano nel motore capacità prima affidate a codice esterno, come la Prompt API per l'AI. L'idea è dichiarare la relazione direttamente nel CSS: un elemento viene indicato come "ancora", un altro viene posizionato rispetto a lei. Da quel momento è il browser a tenerli legati e a ricalcolare la posizione da solo quando qualcosa si muove o la pagina scorre. Poiché la funzione è integrata nel motore, questo ricalcolo avviene in modo efficiente, senza il codice aggiuntivo che prima girava a ogni evento.

Come funziona, in pratica

Il meccanismo si regge su pochi ingredienti. Prima si dà un nome all'ancora con la proprietà anchor-name. Poi, sull'elemento da posizionare, si usa position-anchor per puntare a quel nome e la funzione anchor() per allineare i suoi bordi ai bordi dell'ancora.

/* il pulsante diventa un'ancora, con un nome scelto da noi */
.pulsante {
  anchor-name: --info;
}

/* il tooltip viene agganciato a quell'ancora e messo appena sopra */
.tooltip {
  position: absolute;
  position-anchor: --info;
  bottom: anchor(top);          /* il bordo inferiore del tooltip tocca il bordo superiore del pulsante */
  justify-self: anchor-center;  /* centrato in orizzontale rispetto al pulsante */
}

La riga bottom: anchor(top) si legge così: "posiziona il bordo inferiore del tooltip all'altezza del bordo superiore dell'ancora", cioè mettilo sopra il pulsante. Cambiando questi riferimenti si sposta l'elemento sopra, sotto o di fianco, senza mai indicare coordinate assolute e senza una riga di JavaScript.

Quando non c'è spazio

Il caso più interessante è proprio quello che rende faticoso il lavoro a mano: cosa succede se il tooltip, messo sopra il pulsante, finisce fuori dallo schermo perché il pulsante è vicino al bordo superiore? Qui l'anchor positioning offre un meccanismo di ripiego integrato. Attraverso una regola dedicata (@position-try) si possono elencare posizioni alternative, e il browser sceglie la prima che ci sta senza essere tagliata. È lo stesso comportamento "intelligente" che finora richiedeva le librerie, ma ottenuto con il solo CSS. C'è anche un modo per nascondere l'elemento quando l'ancora esce dalla vista scorrendo, così un tooltip non resta appeso nel vuoto.

Cosa cambia rispetto alle librerie JavaScript

Per chi costruisce interfacce, il vantaggio principale è meno codice da scrivere e mantenere. Per i casi comuni - tooltip, menu, piccoli pannelli a comparsa - non serve più aggiungere una libreria dedicata solo per posizionare un elemento accanto a un altro. Il browser conosce la posizione degli elementi e aggiorna tutto da sé, in modo più coerente da un sito all'altro.

Questo non manda in pensione le librerie. Restano utili per scenari complessi, per animazioni e comportamenti particolari, e soprattutto per garantire lo stesso risultato oggi, su tutti i browser, anche quelli che non supportano ancora la funzione nativa. La scelta, insomma, dipende dal progetto.

Disponibilità e cautele

Trattandosi di una funzione nuova e per ora presente in un solo motore, conviene adottarla con l'approccio del miglioramento progressivo (progressive enhancement): costruire l'interfaccia in modo che resti utilizzabile anche dove la funzione manca, trattando l'ancoraggio nativo come un extra dove è disponibile. In alternativa si può continuare a usare una libreria come ripiego, attivando il metodo nativo solo sui browser che lo conoscono. L'anchor positioning si sposa bene con la Popover API, un'altra funzione recente pensata per mostrare pannelli sovrapposti come menu e finestrelle, e con le View Transitions per animare i cambi di stato: insieme coprono buona parte di ciò che serve per queste interfacce a livelli.

In sintesi

Il CSS Anchor Positioning permette di ancorare un elemento a un altro direttamente nel CSS, delegando al browser il calcolo della posizione. È arrivato in forma stabile con Chrome 125 a maggio 2024, mentre gli altri browser lo stanno ancora implementando, e la specifica è tuttora una bozza. Per chi fa frontend significa meno JavaScript e meno dipendenze per un compito molto comune, tenendo però conto che oggi il supporto non è ancora universale. È uno di quei tasselli che, col tempo, spostano nel browser lavori che prima ricadevano su chi scrive il codice.

::cta{title="Vuoi alleggerire il frontend della tua applicazione?" text="Sviluppiamo interfacce Vue e Laravel puntando su funzioni native del browser dove possibile, riducendo dipendenze JavaScript e tempi di caricamento." button="Parliamo del frontend →"}

Fonti

Cos'è il Model Context Protocol (MCP) e perché se ne parla

Alessandro Corbelli — Mon, 25 Nov 2024 00:00:00 GMT

Gli assistenti basati sull'intelligenza artificiale sanno scrivere testi e rispondere a domande, ma da soli non "vedono" i dati di chi li usa: i file su un disco, i messaggi in una chat di lavoro, le righe di un database. Per fargli usare quelle informazioni serve un collegamento. E finora ogni collegamento era un lavoro a sé, costruito su misura. Il 25 novembre 2024 Anthropic, l'azienda che sviluppa l'assistente Claude, ha presentato il Model Context Protocol (MCP): uno standard aperto pensato proprio per rendere quei collegamenti uniformi.

Vale la pena capire cosa significa, perché dietro un nome tecnico c'è un'idea semplice che riguarda chiunque usi o costruisca strumenti con l'AI.

Il problema: troppe integrazioni fatte a mano

Un assistente AI diventa davvero utile quando può attingere a dati e strumenti reali, non solo alla conoscenza con cui è stato addestrato. Il punto è che quei dati vivono in tanti posti diversi: un archivio di documenti, una casella di posta, un sistema aziendale, un database. Ognuno di questi posti parla un suo linguaggio e ha un suo modo di essere interrogato.

Fino a poco fa, per ogni sorgente bisognava scrivere un pezzo di codice apposta, cioè un'integrazione: un ponte su misura tra l'assistente e quel singolo servizio. Funziona, ma non regge la crescita. Con molti assistenti da un lato e molti servizi dall'altro, il numero di ponti da costruire e mantenere esplode. In termini spiccioli: se ci sono cinque applicazioni AI e dieci strumenti, senza un linguaggio comune servono potenzialmente cinquanta collegamenti diversi, tutti da scrivere, testare e aggiornare quando qualcosa cambia.

È il classico problema delle integrazioni frammentate: molte, tutte diverse, tutte fragili. Ed è esattamente il problema che MCP prova a togliere di mezzo.

Un'analogia: la presa universale

Un modo semplice per capirlo è pensare ai cavi. Prima che si diffondesse lo standard USB, ogni dispositivo aveva il suo connettore: un cavo per la stampante, uno per la macchina fotografica, uno per il telefono, ciascuno incompatibile con gli altri. Poi è arrivata una presa comune e quel groviglio si è ridotto a un solo tipo di collegamento.

MCP punta a fare la stessa cosa per gli assistenti AI. La documentazione ufficiale lo descrive proprio come "una porta USB-C per le applicazioni AI": un modo standardizzato per collegare un assistente a sorgenti di dati e strumenti esterni, al posto di tanti collegamenti su misura. Un protocollo, in questo contesto, è semplicemente un insieme di regole condivise su come due programmi si scambiano messaggi. Se entrambi i lati rispettano le stesse regole, si capiscono senza bisogno di un adattatore costruito ad hoc.

::cta{variant="inline" title="Vuoi collegare l'AI ai dati della tua azienda senza integrazioni fatte a mano ogni volta?" text="Valutiamo se un server MCP su misura ha senso per il tuo caso, e con quali permessi va esposto." button="Valuta il tuo progetto MCP →"}

Come funziona: client e server

MCP separa due ruoli, e capirli aiuta a vedere perché lo schema è pulito.

Da una parte c'è il server MCP: un piccolo programma che "espone" una sorgente di dati o uno strumento parlando il linguaggio dello standard. Per esempio, un server può dare accesso a una cartella di documenti, a un database o alle funzioni di un servizio. Il server dice, in modo uniforme, cosa mette a disposizione e come lo si usa.

Dall'altra parte c'è il client, cioè l'applicazione AI che vuole usare quei dati o quegli strumenti, come l'assistente stesso. Il client si collega al server e, seguendo le stesse regole, può leggere informazioni o richiedere azioni. Il collegamento è bidirezionale: l'assistente non solo riceve dati, ma può anche chiedere al server di fare qualcosa.

Il vantaggio dello schema è che i due lati non hanno bisogno di conoscersi in anticipo. Un assistente che "parla MCP" può collegarsi a qualunque server MCP, e un server MCP può essere usato da qualunque assistente compatibile. È lo stesso principio della presa universale: conta che entrambi rispettino lo standard, non chi li ha costruiti.

Cosa è stato rilasciato

All'annuncio, MCP non è arrivato come una semplice idea sulla carta, ma con materiale concreto e aperto:

La specifica dello standard e alcuni SDK (i kit di sviluppo, cioè gli strumenti per costruire client e server), pubblicati su GitHub e a disposizione di tutti.
Il supporto ai server MCP in locale dentro l'app Claude per computer desktop, così da poter provare i collegamenti sul proprio dispositivo.
Una raccolta open source di server già pronti per strumenti di uso comune, tra cui Google Drive, Slack, GitHub, Git e Postgres. Servono da esempio e da punto di partenza, invece di far ricominciare tutti da zero.

Anthropic ha inoltre indicato alcuni primi utilizzatori, come le aziende Block e Apollo, e strumenti per sviluppatori - tra gli altri Zed, Replit, Codeium e Sourcegraph - impegnati a integrare lo standard nei loro prodotti; da allora il supporto si è allargato anche a strumenti più recenti come Gemini CLI. Un dettaglio non secondario: MCP è stato presentato come progetto aperto e collaborativo, non come una tecnologia chiusa e controllata da un solo fornitore.

Perché uno standard conta

Il valore di MCP non sta in una singola funzione, ma nello spostamento di lavoro che rende possibile. Senza uno standard, chi costruisce un assistente deve creare un collegamento diverso per ogni strumento; e chi costruisce uno strumento deve rifare il lavoro per ogni assistente. Con uno standard, ognuno lo implementa una volta sola: chi crea uno strumento scrive un solo server MCP e lo rende utilizzabile da qualsiasi assistente compatibile; chi crea un assistente aggiunge il supporto a MCP e guadagna l'accesso a tutti i server esistenti. Costruisci una volta, colleghi ovunque.

Ci sono altri due motivi per cui questo conta, anche per chi non scrive codice. Il primo è la riduzione del vincolo a un solo fornitore: se il modo di collegare dati e strumenti è comune, è più facile cambiare assistente o farne convivere diversi, senza rifare tutte le integrazioni. Il secondo è la trasparenza: essendo uno standard aperto, chiunque può leggere la specifica, capire come funziona e contribuire, invece di doversi fidare di un meccanismo chiuso.

Cautele e stato al lancio

Onestà prima di tutto: al momento dell'annuncio si trattava di una prima release. Il supporto ai server in locale c'era da subito, mentre per l'uso remoto e in produzione - cioè collegamenti che non girano solo sul computer di una persona, ma dentro sistemi aziendali - Anthropic indicava strumenti ancora "in arrivo". Come per ogni standard, poi, il valore reale dipende dall'adozione: uno standard serve se in molti lo usano, e questo si vede col tempo, non il primo giorno, un percorso che è proseguito quando MCP è passato sotto il cappello della Linux Foundation per rafforzarne la governance neutrale.

C'è anche un aspetto di sicurezza da tenere presente. Un server MCP dà a un assistente accesso a dati e, spesso, la possibilità di compiere azioni. Va quindi trattato con le stesse cautele di qualsiasi integrazione che tocca informazioni reali: è bene sapere cosa espone, con quali permessi e verso chi, magari delegando l'accesso con un modello a permessi granulari come l'OAuth self-managed invece di un token che apre tutto. La comodità di un collegamento uniforme non toglie la responsabilità di controllarlo, per esempio eseguendo i server meno fidati in ambienti isolati come i container.

In sintesi

Il Model Context Protocol è uno standard aperto, presentato da Anthropic il 25 novembre 2024, per collegare gli assistenti AI a dati e strumenti in modo uniforme. Risolve un problema concreto: la selva di integrazioni fatte a mano, una per ogni combinazione di assistente e servizio. L'idea, come per lo standard USB, è avere un'unica "presa" comune al posto di tanti collegamenti diversi. È partito con specifica, SDK ed esempi aperti, e con qualche primo utilizzatore. Se e quanto diventerà davvero uno standard di riferimento lo diranno l'adozione e i mesi a venire; l'obiettivo, però, è chiaro e sensato: meno lavoro ripetuto, più libertà di scelta.

::cta{title="Vuoi portare MCP nei flussi di lavoro della tua azienda?" text="Sviluppiamo server e integrazioni MCP su misura per collegare l'AI ai vostri sistemi Laravel e ai dati aziendali, con permessi definiti e controllati." button="Costruiamo il tuo server MCP →"}

Fonti

OAuth 2.0: le nuove best practice di sicurezza (RFC 9700)

Alessandro Corbelli — Tue, 14 Jan 2025 00:00:00 GMT

A gennaio 2025 l'IETF - l'organismo che cura gli standard tecnici di Internet - ha pubblicato la RFC 9700, intitolata "Best Current Practice for OAuth 2.0 Security". Il documento raccoglie in forma ufficiale e aggiornata le regole di sicurezza consigliate per chi usa OAuth 2.0, il meccanismo dietro al classico "Accedi con Google" e a gran parte delle API protette del web. Non introduce un protocollo nuovo: mette ordine, aggiorna i consigli esistenti e segna come da evitare alcune pratiche ormai considerate rischiose.

Cos'è OAuth 2.0, in breve

OAuth 2.0 è uno standard per l'autorizzazione delegata. Detto in modo semplice: permette a un'applicazione di ottenere un accesso limitato a un servizio per conto di una persona, senza che quella persona debba consegnare la propria password all'applicazione. È quello che succede quando un sito chiede "Accedi con Google" oppure "Collega il tuo account". Il servizio di origine verifica l'identità e rilascia all'applicazione un token, cioè un gettone temporaneo che vale come permesso d'accesso, con limiti precisi su cosa può fare e per quanto tempo.

Il vantaggio è evidente. La password resta al servizio di origine, l'applicazione riceve solo il minimo necessario, e quel permesso si può revocare in qualsiasi momento. Proprio per questo OAuth 2.0 è diventato lo scheletro di login e API su gran parte del web: dai social alle piattaforme cloud, fino alle integrazioni tra software aziendali.

Conviene chiarire subito tre termini che torneranno utili. Un access token è il gettone che dà accesso a una risorsa. Un authorization code (codice di autorizzazione) è un passaggio intermedio: un codice breve che l'applicazione scambia poi con il token vero. Un redirect URI è l'indirizzo a cui il servizio rimanda l'utente dopo il consenso, e su cui recapita quel codice.

Perché un riferimento aggiornato conta

OAuth 2.0 è stato pubblicato nel 2012 (RFC 6749). Da allora è stato adottato quasi ovunque, e con l'adozione su larga scala sono emersi attacchi e insidie che all'inizio non erano chiari. Le regole di sicurezza originali si sono rivelate in alcuni punti troppo generiche, in altri superate.

La RFC 9700 nasce per questo. È una Best Current Practice - in sigla BCP, con numero 240 - cioè un documento che non descrive un nuovo standard tecnico, ma raccoglie la pratica migliore consigliata dalla comunità in un dato momento. In concreto aggiorna ed estende tre documenti precedenti: la specifica base di OAuth 2.0 (RFC 6749), le regole sull'uso dei token "bearer" (RFC 6750) e il vecchio modello delle minacce (RFC 6819). L'obiettivo dichiarato è incorporare l'esperienza raccolta sul campo e coprire minacce nuove, nate dall'uso sempre più esteso del protocollo.

Un punto importante: non è una bozza né una proposta. È un documento pubblicato a gennaio 2025, al livello di "pratica corrente" ufficiale. Gli autori sono Torsten Lodderstedt (SPRIND), John Bradley (Yubico), Andrey Labunets e Daniel Fett (Authlete), nomi noti nell'ambito dell'identità digitale.

::cta{variant="inline" title="La tua applicazione usa ancora l'implicit grant o password dirette?" text="Verifichiamo la configurazione OAuth delle tue API: PKCE, redirect URI e rotazione dei token." button="Chiedi una verifica →"}

Le raccomandazioni principali

Il testo è lungo e dettagliato, ma alcune indicazioni riassumono bene la direzione.

PKCE per le applicazioni pubbliche. PKCE è un meccanismo che lega la richiesta iniziale allo scambio finale del codice, così che un codice intercettato non basti da solo a ottenere il token. La RFC lo rende obbligatorio per i client "pubblici" - app mobili e applicazioni che girano nel browser, che non possono custodire un segreto - e lo consiglia anche per gli altri. I server di autorizzazione devono supportarlo e verificarlo, in modo che un attaccante non possa aggirarlo.

Corrispondenza esatta dei redirect URI. Il server deve confrontare l'indirizzo di ritorno con quelli registrati in anticipo carattere per carattere, senza scorciatoie. È una difesa contro il dirottamento del codice di autorizzazione verso un sito controllato dall'attaccante. L'unica eccezione pratica riguarda le app native su "localhost", dove il numero di porta può variare.

Token legati a chi li usa. Un rischio classico è il furto del token: chi lo ruba lo può riutilizzare. La RFC raccomanda i sender-constrained token, cioè token vincolati al client legittimo, tramite mutual TLS (RFC 8705) o DPoP (RFC 9449). In pratica il token da solo non basta: serve anche la prova di essere il titolare originale.

Protezione dei refresh token. Il refresh token è un gettone a vita più lunga che serve a ottenere nuovi access token senza rifare il login. Per le applicazioni pubbliche la RFC chiede che sia anch'esso vincolato al client, oppure che venga ruotato, cioè sostituito a ogni uso, così che un token rubato smetta presto di funzionare.

Difesa dagli attacchi "mix-up". Quando un'applicazione dialoga con più server di autorizzazione, un attaccante può cercare di confondere le risposte tra l'uno e l'altro. La contromisura richiesta è identificare con chiarezza chi ha emesso la risposta (tramite il parametro iss) oppure usare indirizzi di ritorno distinti per ciascun server.

A queste si aggiungono due regole di base: le risposte di autorizzazione non devono mai viaggiare su connessioni non cifrate, e conviene affidarsi ai metadati del server di autorizzazione per attivare in automatico le opzioni di sicurezza, riducendo gli errori di configurazione.

Cosa viene sconsigliato o eliminato

Parte del valore della RFC 9700 sta in ciò che toglie.

Viene abbandonato l'implicit grant, un vecchio flusso che consegnava l'access token direttamente nella risposta del browser: comodo un tempo, ma esposto a fughe e riuso del token. Al suo posto va usato il flusso con codice di autorizzazione e PKCE.

Viene escluso del tutto il resource owner password credentials, il flusso in cui l'utente digita la propria password direttamente nell'applicazione, che poi la gira al servizio. Vanifica il senso stesso di OAuth - non far passare la password dalle mani dell'applicazione - ed è incompatibile con l'autenticazione a più fattori. La RFC dice chiaramente che non deve essere usato.

Perché conta per chi espone login e API

Per chi gestisce un servizio con login sociale o API protette, la RFC 9700 è il riferimento a cui allinearsi. Non impone di riscrivere tutto domani, ma indica con chiarezza cosa è considerato sicuro oggi e cosa no.

Vale come lista di controllo pratica: verificare che sia attivo PKCE, che i redirect URI siano confrontati in modo esatto, che i flussi implicit e password siano stati dismessi, che i refresh token vengano ruotati o vincolati. Chi sviluppa integrazioni ha ora un documento unico e citabile a cui riferirsi nelle scelte tecniche e nelle verifiche di sicurezza. E chi usa librerie o provider di identità di terze parti può adottarlo come metro per capire se seguono la pratica aggiornata.

Il messaggio di fondo è semplice: OAuth 2.0 resta valido, ma il modo sicuro di usarlo si è affinato con l'esperienza. Avere quel modo scritto nero su bianco, in un documento ufficiale, aiuta a ridurre gli errori più comuni.

::cta{title="Devi mettere in sicurezza login e API secondo RFC 9700?" text="Progettiamo e gestiamo l'autenticazione delle applicazioni Laravel e delle integrazioni API: PKCE, token vincolati, monitoraggio degli accessi." button="Parliamone →"}

Fonti

Le passkey diventano davvero multipiattaforma

Alessandro Corbelli — Thu, 23 Jan 2025 00:00:00 GMT

Per entrare in un sito serve quasi sempre una password: una stringa da ricordare, che si può dimenticare, riusare per pigrizia o consegnare per sbaglio a una pagina truffa. Le passkey nascono per sostituire quel meccanismo. Esistono da qualche anno, ma finora avevano un limite pratico che ne frenava la diffusione: una passkey creata dentro un ecosistema tendeva a restare lì. A gennaio 2025 Google ha annunciato un passo che riduce quel limite. Le passkey salvate nel suo gestore, Google Password Manager, sono ora disponibili anche su iPhone e iPad, oltre che su Android, Windows, macOS, Linux e ChromeOS. Vale la pena capire cos'è una passkey e perché poterla usare su dispositivi di marche diverse cambia le cose.

Cos'è una passkey

Una passkey è un modo per accedere a un sito o a un'app senza digitare una password. Al posto della parola segreta condivisa con il servizio, usa una coppia di chiavi crittografiche: due valori matematici legati fra loro. Una è la chiave privata e resta sul dispositivo dell'utente, protetta e mai comunicata a nessuno. L'altra è la chiave pubblica e viene consegnata al sito al momento della registrazione.

Quando si accede, il sito invia una piccola sfida da firmare. Il dispositivo firma quella sfida con la chiave privata, ma solo dopo che l'utente si è sbloccato come fa di solito: impronta, riconoscimento del volto, PIN o segno. Il sito verifica la firma con la chiave pubblica che aveva in archivio e lascia entrare. Il gesto per l'utente è lo stesso che usa già per sbloccare il telefono.

Questo disegno ha due conseguenze pratiche. La prima: non c'è più una password da rubare. Sul server del sito resta solo la chiave pubblica, che di per sé non permette di accedere; una fuga di dati non consegna più le credenziali di accesso. La seconda: la passkey è legata all'indirizzo reale del sito. Una pagina che imita la banca non riceverà mai la firma giusta, perché l'indirizzo non corrisponde. In pratica il phishing, cioè l'inganno che spinge a digitare le credenziali su un sito falso, smette di funzionare. Le passkey si basano su standard aperti, WebAuthn e FIDO2, curati dalla FIDO Alliance insieme al consorzio del web.

Perché la sincronizzazione era il vero ostacolo

Sulla carta il meccanismo è più semplice e più sicuro di una password. Il problema, finora, non era la crittografia: era la portabilità. Se la chiave privata resta sul dispositivo, cosa succede quando i dispositivi sono più di uno, magari di marche diverse?

La risposta dei grandi fornitori è stata sincronizzare le passkey in modo cifrato tra i propri apparecchi. Ma ciascuno lo faceva dentro il proprio recinto. Una passkey creata su iPhone finiva in Apple Passwords, l'ex Portachiavi iCloud, e restava utilizzabile sui dispositivi Apple. Una passkey creata su Android o su un computer, tramite Google Password Manager, viveva nel mondo Google e non arrivava su iPhone e iPad. Chi aveva un telefono di una marca e un computer di un'altra, o cambiava marca di telefono, poteva ritrovarsi senza la propria passkey proprio dove serviva.

È un ostacolo concreto. Se l'utente teme di rimanere chiuso fuori, tende a tenersi la vecchia password come rete di sicurezza, e il sito deve continuare a supportarla. Finché la password resta come alternativa, i vantaggi della passkey restano a metà. La sincronizzazione tra piattaforme diverse è quindi il tassello che decide se le passkey diventano un metodo di accesso quotidiano o restano una comodità per chi vive dentro un solo ecosistema.

::cta{variant="inline" title="Il login della tua piattaforma si basa ancora solo su password?" text="Valutiamo se e come introdurre le passkey nel sistema di autenticazione dei tuoi utenti." button="Chiedi una valutazione →"}

Cosa ha annunciato Google

Il 16 gennaio 2025, sul blog per sviluppatori di Chrome, Google ha annunciato che le passkey di Google Password Manager sono disponibili su iOS e iPadOS, a partire dalla versione 17. Da quel momento Chrome, con lo stesso profilo connesso, sincronizza le passkey di Google Password Manager su tutte le piattaforme e i dispositivi: Android, iPhone e iPad, Windows, macOS, Linux e ChromeOS.

È il pezzo che mancava. La sincronizzazione tra computer e Android era già arrivata qualche mese prima, a settembre 2024, per Windows, macOS, Linux e ChromeOS. iPhone e iPad erano rimasti fuori: le passkey di Google Password Manager non erano disponibili lì, e quelle create su iOS finivano in Apple Passwords senza raggiungere le altre piattaforme. Con questo aggiornamento un singolo gestore, quello di Google, copre tutti i principali sistemi operativi da tavolo e da telefono.

Un dettaglio importante sul tono: non è una beta né una prova per pochi. È una funzione disponibile in modo stabile. Il requisito è iOS o iPadOS 17 o successivi; su iOS 16 le passkey continuano a essere salvate nel Portachiavi iCloud.

Come si usa, in pratica

Su un iPhone o iPad aggiornato ad almeno iOS 17, la passkey di Google Password Manager si usa impostando Chrome come fornitore di riempimento automatico nelle impostazioni del sistema. Da quel momento le passkey salvate nel gestore di Google diventano disponibili nelle app e nei browser del dispositivo, non solo dentro Chrome.

L'accesso a queste passkey è protetto da un PIN di Google Password Manager. Su un dispositivo nuovo serve quel PIN, oppure il metodo di sblocco di un dispositivo Android già collegato, per ripristinare le passkey. Conviene configurare per tempo questi elementi di recupero, perché sono l'unico modo per riottenere le proprie passkey.

Cosa tenere a mente

Qualche precisazione, per non leggere l'annuncio come più ampio di quello che è.

La sincronizzazione tra piattaforme di cui si parla qui riguarda un fornitore preciso, Google Password Manager, e passa da Chrome. Su iPhone occorre impostare Chrome come fornitore di riempimento automatico; le passkey di Google non si fondono con quelle di Apple Passwords. Chi preferisce restare nell'ecosistema Apple continua a usare Apple Passwords, che a sua volta sincronizza tra i dispositivi Apple. Il cambiamento è che oggi esiste almeno un gestore che attraversa tutti i sistemi principali, iOS compreso.

Le passkey di Google Password Manager sono cifrate end-to-end: sono leggibili solo sul dispositivo dell'utente e nemmeno Google può accedervi. È una garanzia sulla riservatezza, ma ha un rovescio: se si perdono sia il PIN sia i dispositivi collegati, il recupero diventa difficile. Per questo i metodi di ripristino vanno impostati quando tutto funziona, non quando serve.

Vale infine ricordare che una passkey non cancella le altre. Un sito può permettere di registrare più passkey, una per gestore o per dispositivo, e spesso conviene averne più di una come alternativa. E la password, dove è ancora offerta, resta lo strato da abbandonare per ultimo, non da buttare via il primo giorno.

In sintesi, la novità non è la passkey in sé, che c'era già, ma il fatto che ora un gestore la porti in modo uniforme su tutti i sistemi operativi diffusi. È il tipo di dettaglio poco appariscente che decide se una tecnologia di sicurezza resta di nicchia o diventa qualcosa che si usa senza pensarci.

::cta{title="Vuoi portare le passkey nella tua applicazione?" text="Sviluppiamo e integriamo l'autenticazione WebAuthn/FIDO2 nelle applicazioni Laravel e Vue che realizziamo, dal login alla gestione degli account." button="Parliamone →"}

Fonti

HTTP Concealed (RFC 9729): l'autenticazione che nasconde persino l'esistenza di una risorsa

Alessandro Corbelli — Tue, 11 Feb 2025 00:00:00 GMT

La maggior parte dei sistemi di accesso a un sito ha un difetto poco discusso: si vedono. Anche quando non si conosce la password, spesso è facile capire che dietro un certo indirizzo c'è qualcosa da proteggere. A febbraio 2025 l'IETF, l'organismo che cura gli standard tecnici di Internet, ha pubblicato la RFC 9729 e ha definito un nuovo schema di autenticazione HTTP pensato proprio per evitare questo: si chiama "Concealed", cioè nascosto.

Il problema: le porte chiuse che si notano lo stesso

Quando un browser chiede una pagina e il server richiede un accesso, di solito lo dice apertamente. Il caso classico è la risposta con codice 401 Unauthorized e l'intestazione WWW-Authenticate, con cui il server annuncia: "qui serve autenticarsi". È un comportamento utile e corretto nella stragrande maggioranza dei siti, ma ha una conseguenza: chiunque provi quell'indirizzo capisce che lì c'è una risorsa protetta.

Gli autori della RFC usano un termine preciso per questo: gli schemi di autenticazione tradizionali sono probeable, cioè "sondabili". Un client non autorizzato può mandare richieste a caso e osservare le risposte per dedurre dove il server tiene qualcosa sotto chiave. Per un sito pubblico non è un problema. Lo diventa quando l'obiettivo è che certi servizi restino invisibili a chi non ne conosce già l'esistenza: un pannello riservato, un endpoint di gestione, una risorsa destinata a un gruppo ristretto.

Il punto delicato è che, per un attaccante, sapere che una cosa esiste è già metà del lavoro. Uno scanner automatico che passa in rassegna migliaia di indirizzi si nutre esattamente di queste differenze nelle risposte, lo stesso tipo di traffico di fondo descritto a proposito degli attacchi brute force. Se il server tratta la porta chiusa in modo diverso da una porta che non c'è, quella differenza è un indizio.

Cos'è lo schema "Concealed"

La RFC 9729 definisce un nuovo schema crittografico di autenticazione per HTTP che ha una proprietà in più: è non-probeable, non sondabile. In pratica, un osservatore esterno non riesce a distinguere un server che richiede questo tipo di autenticazione da uno che non ne fa nulla.

Il meccanismo si basa sulla crittografia asimmetrica. Vale la pena spiegare il termine: ogni utente autorizzato possiede una coppia di chiavi, una privata (tenuta segreta) e una pubblica (condivisa in anticipo con il server). Il server conserva un elenco che associa a ogni identificativo di chiave la relativa chiave pubblica. Chi vuole autenticarsi dimostra di possedere la chiave privata firmando un dato concordato; il server verifica quella firma con la chiave pubblica che ha in archivio. Non viaggia mai nessuna password.

Un aspetto pratico da tenere presente: le chiavi vanno distribuite prima, per un'altra via. Lo schema dà per scontato che il server sappia già quali chiavi accettare. Non è pensato per iscriversi a un sito qualsiasi, ma per far entrare chi è stato messo nella lista in anticipo.

::cta{variant="inline" title="I tuoi endpoint riservati si vedono anche da chi non ha le chiavi giuste?" text="Controlliamo come risponde la tua infrastruttura a chi prova ad accedere senza autorizzazione." button="Chiedi una verifica →"}

Come fa a nascondere l'esistenza della risorsa

Il trucco sta in come viene generato il dato da firmare. Negli schemi crittografici classici, per evitare che una firma vecchia venga riutilizzata, è il server a mandare al client un numero usa-e-getta (un nonce) da inserire nella firma. Ma proprio quel messaggio del server è il segnale che tradisce: annunciando il nonce, il server sta dicendo "qui c'è un'autenticazione".

La RFC 9729 elimina quel passaggio. Il dato fresco da firmare non arriva dal server: il client lo ricava dalla connessione TLS già in corso, quella cifratura che protegge il traffico dei siti in https, la stessa base su cui poggia anche la riservatezza aggiuntiva dell'Encrypted Client Hello. TLS mette a disposizione una funzione, il keying material exporter, che permette a client e server di derivare in modo indipendente un valore segreto legato a quella specifica connessione. Con un'etichetta dedicata - EXPORTER-HTTP-Concealed-Authentication - il client ottiene questo valore, lo firma con la propria chiave privata e lo invia. Il server, dalla sua parte, può ricalcolare lo stesso valore e verificare.

Il risultato è che il client parla per primo, senza bisogno di alcun invito. E qui sta la parte importante per la riservatezza: un server che vuole restare davvero invisibile deve rispondere in modo identico sia quando la risorsa non esiste, sia quando esiste ma l'autenticazione fallisce. In pratica risponde 404 Not Found in entrambi i casi. Chi non ha la chiave giusta non riesce a distinguere "non c'è nulla" da "c'è qualcosa che non ti riguarda".

Come funziona, in concreto

L'autenticazione viaggia nell'intestazione Authorization (o Proxy-Authorization verso un proxy), con lo schema Concealed e alcuni parametri. Senza scendere nel dettaglio crittografico, i cinque campi previsti dalla specifica sono:

k - l'identificativo della chiave che il client vuole usare;
a - la chiave pubblica con cui il server verifica la firma;
s - lo schema di firma impiegato, scelto dal registro standard di TLS;
p - la prova (la firma vera e propria) che attesta il possesso della chiave privata;
v - un valore di verifica legato all'output esportato da TLS.

Una condizione tecnica è necessaria: serve TLS nella versione 1.3, oppure la 1.2 con l'estensione extended master secret. Il motivo è che la firma deve restare ancorata a quella singola connessione. Lo schema è compatibile con HTTP/2, HTTP/3 e con il trasporto QUIC.

A cosa serve davvero

Il caso d'uso principale è tenere fuori radar i servizi che non devono essere scoperti per caso. Un endpoint di amministrazione, un'interfaccia di gestione, un'API interna: con lo schema Concealed, chi non possiede una chiave valida non ha modo di capire nemmeno che quell'indirizzo faccia qualcosa. È una forma di difesa in profondità: non sostituisce le altre protezioni, ma riduce la superficie che uno scanner automatico riesce a mappare.

C'è anche un beneficio sul fronte del tracciamento. La specifica nota che le chiavi legano l'utente a una singola origine (un singolo sito), ma sono costruite per non permettere di correlare le richieste tra siti diversi. In altre parole, la stessa persona non diventa riconoscibile spostandosi da un dominio all'altro.

Cosa tenere d'occhio

Come ogni strumento, ha i suoi limiti dichiarati apertamente nella RFC.

La firma è legata alla connessione, non alla singola richiesta. Questo apre a un rischio di riuso: se l'intestazione con la prova trapelasse - per esempio a causa di codice che gira nella stessa sessione del browser - potrebbe essere sfruttata su altre richieste della stessa connessione. Per questo la RFC è netta su un punto: le chiavi usate qui non devono essere riutilizzate in altri protocolli.

C'è poi la freschezza. Il valore firmato dipende dall'età della connessione TLS; un server che vuole imporre una prova più recente può forzare l'apertura di una nuova connessione. E c'è l'attenzione ai canali laterali temporali: se il server impiegasse tempi diversi a rispondere nei due casi - risorsa assente contro autenticazione fallita - quella differenza di millisecondi rischierebbe di svelare ciò che si voleva nascondere. Ottenere risposte davvero indistinguibili richiede cura anche su questo.

A che punto è

RFC 9729 non è una bozza: è un documento pubblicato, sulla via degli standard IETF con il livello di Proposed Standard (Standard Proposto). È il primo gradino stabile del percorso: una specifica matura e rivista pubblicamente, non ancora al livello finale di "Internet Standard", lo stesso stadio raggiunto di recente anche dall'header HTTP che segnala le API deprecate. Prima di arrivarci si chiamava draft-ietf-httpbis-unprompted-auth ed è stata elaborata nel gruppo di lavoro httpbis dell'IETF.

Gli autori sono David Schinazi (Google), David M. Oliver (Guardian Project) e Jonathan Hoyland (Cloudflare). In concreto, il supporto lato browser e lato server è ancora agli inizi e va verificato caso per caso: la specifica è solida, la diffusione negli strumenti reali è ciò che nei prossimi tempi dirà quanto lo schema entrerà nell'uso comune. Resta comunque un'idea interessante, perché sposta l'obiettivo dell'autenticazione da "impedire l'accesso" a "non far sapere nemmeno che c'è una porta".

::cta{title="Vuoi nascondere davvero i servizi riservati della tua infrastruttura?" text="Configuriamo autenticazione, TLS e regole del reverse proxy per far sì che pannelli ed endpoint interni restino invisibili a chi non è autorizzato." button="Parliamone →"}

Fonti

SPF, DKIM e DMARC: cosa sono e perché contano per le email

Alessandro Corbelli — Tue, 18 Feb 2025 00:00:00 GMT

C'è un dettaglio poco noto della posta elettronica: il mittente di un'email si può falsificare con estrema facilità. Il nome e l'indirizzo che compaiono nel campo "Da" (in inglese From) sono un po' come il mittente scritto a mano sul retro di una busta: di per sé, nessuno garantisce che siano veri. Su questa debolezza si reggono buona parte dello spam, del phishing e dello spoofing, cioè le email che si spacciano per qualcun altro. SPF, DKIM e DMARC sono i tre strumenti nati per rimettere ordine. Servono a una cosa sola: dimostrare che un messaggio arriva davvero da chi dice di arrivare.

Il problema: la posta nasce senza controlli

Quando la posta elettronica è stata progettata, la rete era piccola e fatta di macchine che si fidavano l'una dell'altra. Scrivere il proprio nome nel campo mittente bastava, perché non c'era motivo di mentire. Quel modello non prevedeva alcuna verifica dell'identità, ed è rimasto tale: ancora oggi, tecnicamente, chiunque può inviare un'email indicando come mittente un indirizzo che non gli appartiene.

Le conseguenze sono due, ed è utile tenerle distinte perché i tre strumenti nascono proprio per affrontarle. La prima è la sicurezza: un truffatore può scrivere "da parte" della tua banca o della tua azienda e ingannare chi riceve. La seconda è la deliverability, cioè la capacità di un'email legittima di arrivare davvero nella casella giusta invece di finire nello spam. I grandi provider filtrano enormi volumi di posta, e un mittente che non riescono a verificare è, per definizione, sospetto.

SPF, DKIM e DMARC non si escludono a vicenda: lavorano insieme, ciascuno su un pezzo del problema. Vediamoli uno alla volta.

SPF: chi può spedire per un dominio

SPF sta per Sender Policy Framework ed è descritto nella RFC 7208. Risponde a una domanda precisa: quali server sono autorizzati a spedire posta per un certo dominio?

L'idea è semplice. Il proprietario di un dominio pubblica, tra le impostazioni pubbliche del dominio stesso (i cosiddetti record DNS, la "rubrica" che traduce i nomi di Internet), un elenco degli indirizzi dei server autorizzati. Quando arriva un messaggio, il server ricevente legge quell'elenco e controlla se il server che glielo sta consegnando è nella lista. Se c'è, il controllo passa; se non c'è, qualcosa non torna.

Il paragone è quello di un elenco al banco della posta: "per questa azienda possono spedire solo questi uffici". Una lettera che parte da un ufficio non autorizzato viene guardata con sospetto.

In pratica è una singola riga di testo, e un dominio deve averne una sola. Assomiglia a questa:

example.com.  IN  TXT  "v=spf1 include:_spf.provider.tld -all"

La parte finale, -all, dice al ricevente come trattare chi non è in lista: rifiutalo. Un'alternativa più morbida, ~all, significa "trattalo come sospetto ma non rifiutarlo del tutto", ed è comoda nella fase iniziale, quando non si è ancora sicuri di aver elencato tutti i propri mittenti.

SPF ha un limite importante da conoscere: controlla il "percorso" del messaggio, cioè il server che lo spedisce, non il suo contenuto. È il motivo per cui, da solo, non basta.

::cta{variant="inline" title="Le tue email finiscono nello spam più spesso di quanto dovrebbero?" text="Controlliamo la configurazione SPF, DKIM e DMARC del tuo dominio e la deliverability della posta aziendale." button="Chiedi un controllo →"}

DKIM: la firma che prova l'integrità

DKIM sta per DomainKeys Identified Mail ed è descritto nella RFC 6376. Se SPF verifica da dove parte il messaggio, DKIM verifica il messaggio stesso.

Funziona con la crittografia a chiavi, lo stesso principio delle firme digitali. Il server che spedisce applica al messaggio una firma calcolata con una chiave privata, che tiene segreta. Chi riceve recupera la corrispondente chiave pubblica (di nuovo dai record DNS del dominio) e la usa per verificare la firma. Se il conto torna, due cose sono dimostrate: il messaggio proviene davvero da quel dominio, e non è stato alterato durante il viaggio. Se anche solo una virgola fosse cambiata in transito, la firma non tornerebbe più.

Il paragone qui è il sigillo di ceralacca su una lettera. Non ti dice solo chi l'ha spedita: se il sigillo è intatto, ti garantisce anche che nessuno ha aperto e modificato la busta lungo la strada.

La firma viaggia dentro un'intestazione tecnica del messaggio, invisibile all'utente comune, chiamata DKIM-Signature. Al suo interno due indicazioni contano più delle altre: il dominio che firma (il tag d=) e il selettore (il tag s=), un'etichetta che permette a uno stesso dominio di avere più chiavi attive e di sostituirle senza interruzioni.

DMARC: la regola su cosa fare quando i controlli falliscono

Restano due lacune. Primo: né SPF né DKIM dicono al ricevente cosa fare quando un controllo fallisce. Secondo, e più sottile: entrambi verificano un dominio "tecnico", che l'utente non vede, e non garantiscono che coincida con l'indirizzo mostrato nel campo "Da". Un messaggio potrebbe superare i controlli su un dominio qualsiasi e mostrarne un altro all'utente.

DMARC colma entrambe le lacune. Sta per Domain-based Message Authentication, Reporting, and Conformance; dal 2026 il riferimento aggiornato è la RFC 9989, che ha sostituito la storica RFC 7489 e ha reso DMARC uno standard vero e proprio.

Il suo primo compito si chiama allineamento (in inglese alignment). DMARC pretende che il dominio verificato da SPF o da DKIM corrisponda a quello che l'utente legge nel campo "Da". Se un messaggio supera SPF o DKIM ma su un dominio diverso da quello visibile, per DMARC non è allineato. Basta che uno dei due controlli passi e sia allineato perché DMARC sia soddisfatto.

Il secondo compito è dare l'istruzione. Il proprietario del dominio pubblica una regola, di nuovo come record DNS, che indica cosa fare con i messaggi che non superano l'allineamento. Le tre opzioni previste sono:

p=none: non fare nulla di speciale, limitati a osservare. È la fase di monitoraggio.
p=quarantine: tratta il messaggio come sospetto, di solito recapitandolo nella cartella spam.
p=reject: rifiuta il messaggio, che non viene proprio consegnato.

Il record vive a un indirizzo dedicato e assomiglia a questo:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:report@example.com"

Quella parte rua introduce la terza funzione, spesso la più utile: i report. I provider riceventi inviano periodicamente al proprietario del dominio dei resoconti (documenti in formato XML) che elencano chi ha spedito a suo nome e con quale esito. È così che si scopre sia chi abusa del proprio dominio, sia i propri servizi legittimi dimenticati, per esempio un gestionale o una piattaforma di newsletter. Senza questi report si procede alla cieca.

Come si incastrano i tre

Messi in fila, i tre strumenti coprono aspetti diversi e complementari:

SPF verifica il percorso: da quale server parte il messaggio.
DKIM verifica l'integrità: il contenuto è autentico e non è stato manomesso.
DMARC lega i primi due all'indirizzo che l'utente vede davvero e decide cosa fare quando qualcosa non torna, oltre a fornire i report.

Nessuno dei tre da solo è sufficiente. SPF senza DMARC non protegge l'indirizzo visibile; DKIM senza DMARC non dice cosa fare in caso di fallimento; DMARC senza SPF né DKIM non ha nulla da controllare. È l'insieme a funzionare.

Perché contano oggi

Fino a qualche anno fa configurarli era considerato una buona pratica facoltativa. Non lo è più. Dal 2024 Google e Yahoo li richiedono esplicitamente a chi invia grandi volumi di posta: secondo le linee guida ufficiali di Google, chi supera i 5.000 messaggi al giorno verso caselle Gmail deve avere SPF e DKIM configurati e una regola DMARC attiva, anche solo minima (p=none), con l'indirizzo visibile allineato al dominio di SPF o di DKIM. Senza questi controlli, le email rischiano semplicemente di non arrivare.

Vale anche per chi invia poca posta. Un dominio senza autenticazione è un dominio che chiunque può usare per truffe a nome di chi lo possiede, ed è anche un dominio che i filtri antispam trattano con più diffidenza. Se il sintomo che vedi è concreto, per esempio i preventivi che finiscono in spam, molto spesso la causa è esattamente qui.

Come si imposta, a grandi linee

Tutti e tre si configurano nello stesso posto, i record DNS del dominio, e non richiedono di toccare i server di posta se ci si appoggia a un provider che li supporta. Lo schema generale è questo: si pubblica il record SPF con l'elenco dei mittenti autorizzati, si attiva la firma DKIM e si pubblica la relativa chiave pubblica, infine si pubblica il record DMARC.

Il passaggio più delicato è proprio DMARC, e l'ordine consigliato è graduale: si parte da p=none, si leggono i report per capire chi spedisce davvero a proprio nome, si sistemano gli eventuali mittenti legittimi rimasti fuori e solo allora si irrigidisce la regola verso quarantine e poi reject. Farlo di colpo rischia di bloccare email legittime che non si sapeva di avere. La logica è semplice: prima si guarda, poi si decide.

In sintesi

SPF, DKIM e DMARC sono tre risposte a un difetto di nascita della posta elettronica: chiunque può fingersi un altro. SPF dice chi è autorizzato a spedire, DKIM firma il messaggio per dimostrarne l'integrità, DMARC lega i due controlli all'indirizzo visibile e decide cosa fare quando falliscono. Insieme riducono spoofing e phishing e aiutano i messaggi legittimi ad arrivare a destinazione. Non sono più un extra: sono il minimo perché la posta di un dominio sia presa sul serio.

::cta{title="Vuoi mettere in sicurezza la posta del tuo dominio?" text="Configuriamo e monitoriamo SPF, DKIM e DMARC sui domini che gestiamo, dalla prima pubblicazione fino alla policy reject." button="Parliamone →"}

Fonti

Il NIST sceglie HQC: un secondo algoritmo di cifratura post-quantum di riserva

Alessandro Corbelli — Thu, 13 Mar 2025 00:00:00 GMT

L'11 marzo 2025 il NIST, l'ente statunitense che definisce molti standard di sicurezza usati in tutto il mondo, ha annunciato la scelta di un nuovo algoritmo di crittografia chiamato HQC. La sigla è ostica, ma la sostanza è semplice: HQC servirà da riserva per proteggere i dati contro una minaccia futura, affiancando un algoritmo già scelto in precedenza. Vale la pena capire cosa vuol dire, contro cosa protegge e perché avere un secondo algoritmo, invece di uno solo, è una decisione sensata.

La notizia in breve

Da alcuni anni il NIST porta avanti un lavoro pubblico per selezionare algoritmi di crittografia post-quantum, cioè metodi di cifratura pensati per resistere anche a un tipo di computer che oggi non esiste ancora in forma utilizzabile. Nel 2024 sono stati pubblicati i primi standard di questa nuova famiglia. Ora se ne aggiunge un altro: HQC, scelto come algoritmo di riserva per la cifratura.

Il punto chiave è proprio la parola "riserva". HQC non sostituisce nulla. L'algoritmo principale per la cifratura resta ML-KEM, già standardizzato. HQC gli si affianca come seconda opzione, da tenere pronta nel caso in cui il primo dovesse mostrare debolezze in futuro. È il quinto algoritmo che il NIST seleziona in questo percorso, e il secondo dedicato specificamente alla protezione dei dati in transito.

Il problema: la minaccia dei computer quantistici

Per capire perché serva tutto questo bisogna partire dalla minaccia. Oggi buona parte di ciò che facciamo online è protetto da crittografia: quando nel browser compare il lucchetto, i dati scambiati tra il dispositivo e il sito sono resi illeggibili a chi tentasse di intercettarli. Questa protezione regge perché i computer attuali non hanno la potenza per forzarla in tempi ragionevoli.

I computer quantistici sono una tecnologia in sviluppo, basata su principi fisici diversi da quelli dei computer tradizionali. In teoria, una macchina di questo tipo abbastanza potente potrebbe un giorno rompere buona parte della crittografia che usiamo adesso. Nessuno sa con certezza se e quando arriverà quel momento: le stime degli esperti vanno da oltre un decennio a diversi decenni.

C'è però un motivo per non aspettare. Chi intercetta traffico cifrato oggi può archiviarlo e conservarlo, in attesa di poterlo decifrare quando la tecnologia lo permetterà. Questa strategia ha un nome, "raccogli ora, decifra dopo". Significa che dati destinati a restare sensibili per anni sono già a rischio adesso, anche se la macchina capace di aprirli non esiste ancora. Da qui l'urgenza di adottare per tempo algoritmi resistenti, lo stesso motivo per cui Chrome ha iniziato ad abilitare di default lo scambio di chiavi post-quantum nelle connessioni TLS.

::cta{variant="inline" title="Sai già cosa succede ai tuoi dati cifrati oggi se un giorno arriverà un computer quantistico?" text="Verifichiamo la crittografia in uso sulla tua infrastruttura e il margine per adottare algoritmi post-quantum quando saranno pronti." button="Chiedi una verifica →"}

Cos'è HQC e su cosa si basa

HQC sta per Hamming Quasi-Cyclic. È un meccanismo di incapsulamento delle chiavi (in inglese key encapsulation mechanism, abbreviato KEM): in parole povere, si occupa del momento iniziale di una connessione sicura, quando due parti devono mettersi d'accordo su una chiave segreta condivisa senza che nessun altro possa scoprirla. Quella chiave serve poi a cifrare tutto il resto della conversazione. È proprio questo passaggio a essere il più esposto alla strategia "raccogli ora, decifra dopo", ed è quindi il primo da mettere in sicurezza.

La particolarità di HQC sta nella matematica su cui si fonda. Ogni algoritmo di crittografia moderna si appoggia a un problema matematico che si ritiene molto difficile da risolvere. HQC si basa sui codici correttori d'errore: tecniche nate per individuare e correggere gli errori nei dati quando vengono trasmessi o archiviati, usate da decenni in ambiti come le comunicazioni satellitari, i vecchi CD o i codici QR. Da quel principio si ricava un problema matematico difficile su cui costruire la protezione.

Qui sta la differenza importante rispetto a ML-KEM, l'algoritmo principale. ML-KEM si basa su un'altra area della matematica, chiamata reticoli strutturati (in inglese structured lattices). Due algoritmi, due fondamenta matematiche diverse. Non è un dettaglio da poco, come si vede tra poco.

Perché avere un'alternativa: la crypto-agility

La ragione per cui il NIST ha scelto un secondo algoritmo, e per giunta basato su matematica diversa, è una forma di prudenza. Questi algoritmi sono relativamente recenti. Sono stati studiati a fondo da esperti di tutto il mondo, ma nessuno può escludere del tutto che in futuro venga scoperta una debolezza. La storia della crittografia è piena di metodi ritenuti solidi e poi superati.

Il rischio più insidioso è quello sistemico. Se tutti gli algoritmi disponibili si basassero sullo stesso principio matematico, una singola scoperta capace di incrinare quel principio metterebbe in crisi l'intero sistema in un colpo solo. Avere un'alternativa costruita su fondamenta indipendenti riduce questo pericolo: se un giorno emergesse un problema con i reticoli su cui poggia ML-KEM, resterebbe pronto HQC, che dei reticoli non fa uso. E viceversa. Il responsabile del progetto post-quantum del NIST ha spiegato la scelta proprio così: serve uno standard di riserva basato su un approccio matematico diverso, nel caso in cui il primo dovesse un giorno rivelarsi vulnerabile.

Questo modo di ragionare ha un nome: crypto-agility, cioè la capacità di cambiare algoritmo senza dover ricostruire tutto da zero. Un sistema progettato in modo agile può passare da un metodo di cifratura a un altro con relativa facilità, man mano che le circostanze cambiano. Non è una qualità appariscente, ma è ciò che permette di reagire in fretta se qualcosa va storto, invece di restare bloccati con un'unica soluzione.

A che punto è: tempi e stato

Conviene essere precisi su un punto: la scelta di HQC è l'inizio di un percorso, non la fine. Al momento dell'annuncio non esisteva ancora uno standard pronto all'uso.

Il NIST ha indicato una tabella di marcia. Una bozza di standard è attesa entro circa un anno dall'annuncio, quindi indicativamente nel 2026. Alla pubblicazione della bozza segue un periodo di commenti pubblici di circa 90 giorni, durante il quale chiunque può segnalare problemi o proporre modifiche. Solo dopo si arriva alla versione definitiva, prevista intorno al 2027. Fino a quel momento HQC non è un algoritmo da mettere in produzione, ma una scelta consolidata di cui è stato annunciato il percorso di standardizzazione.

Vale la pena aggiungere un dettaglio tecnico onesto: HQC, a parità di sicurezza, tende a richiedere più risorse di calcolo rispetto a ML-KEM. È uno dei motivi per cui resta la seconda opzione e non la prima. Non è pensato per sostituire l'algoritmo principale nell'uso quotidiano, ma per esistere come alternativa affidabile su basi diverse.

Cosa cambia in pratica

Per la maggior parte delle persone, oggi, non cambia nulla di immediato. Non c'è alcuna azione da compiere e nessun software da aggiornare a mano per via di HQC. La transizione alla crittografia post-quantum è un processo lungo, che avviene soprattutto dietro le quinte, negli aggiornamenti di browser, sistemi operativi e librerie, un processo già misurabile: una parte crescente del traffico web passa già da crittografia post-quantum.

Per chi progetta o gestisce sistemi, invece, c'è un principio da tenere a mente: non concentrare tutto su un solo algoritmo. La lezione di questa notizia è proprio la crypto-agility. Un'infrastruttura pensata per poter cambiare metodo di cifratura in futuro, senza riscrivere mezzo sistema, sarà molto più semplice da adeguare quando gli standard evolveranno, lo stesso principio dietro la scelta di accorciare la vita dei certificati TLS per limitare i danni quando qualcosa va storto. Non serve correre ad adottare HQC oggi, ma conviene costruire in modo da poterlo fare domani senza traumi.

In sintesi

Il NIST ha scelto HQC come algoritmo di cifratura post-quantum di riserva, da affiancare a ML-KEM. La sua caratteristica principale è la matematica su cui si fonda, i codici correttori d'errore, diversa da quella dell'algoritmo principale. Questa diversità è il punto: avere due fondamenta indipendenti rende il sistema più resistente nel tempo, perché una singola scoperta non potrebbe abbatterle entrambe insieme. Lo standard vero e proprio arriverà nei prossimi anni, con una bozza attesa nel 2026 e la versione definitiva verso il 2027. Nel frattempo, la lezione utile a tutti è semplice: nella sicurezza, avere un piano B costruito su basi diverse non è un lusso, è prudenza.

::cta{title="Vuoi un'infrastruttura pronta a cambiare algoritmo di cifratura senza traumi?" text="Progettiamo e gestiamo l'infrastruttura server dei nostri clienti pensando alla crypto-agility: TLS, certificati e librerie aggiornabili senza riscrivere tutto da capo." button="Parliamone →"}

Fonti

Cos'è un reverse proxy (e perché quasi ogni sito ne usa uno)

Alessandro Corbelli — Thu, 20 Mar 2025 00:00:00 GMT

Dietro quasi ogni sito che si visita c'è un componente di cui non ci si accorge mai, perché fa bene il suo lavoro proprio restando invisibile: il reverse proxy. Non è il programma che genera le pagine, né il database che conserva i dati. È l'intermediario che sta davanti a tutto il resto e decide chi entra, come e verso quale servizio. Capire cos'è aiuta a leggere l'architettura di un sito senza doverla immaginare come una scatola nera.

Cos'è un reverse proxy in parole semplici

Un proxy è, letteralmente, un intermediario: un componente che sta in mezzo a due parti e gira i messaggi dall'una all'altra. Un reverse proxy è un intermediario che sta davanti a uno o più server applicativi. Il visitatore parla con il reverse proxy; il reverse proxy inoltra la richiesta all'applicazione giusta, ne raccoglie la risposta e la restituisce al visitatore. Il client, cioè il browser, non parla mai direttamente con il server che genera davvero la pagina.

Un'immagine utile è quella del centralino, o della reception di un ufficio. Chi arriva non gira per i corridoi cercando la persona giusta: si rivolge al banco all'ingresso, che smista la richiesta a chi di dovere e riporta indietro la risposta. Il banco è un solo punto di contatto per molti uffici diversi. Il reverse proxy fa la stessa cosa per i servizi web.

La differenza con un forward proxy

La parola "proxy" da sola crea confusione, perché esistono due tipi opposti. La differenza sta da che lato si trova l'intermediario.

Un forward proxy sta davanti ai client. È l'intermediario che una rete aziendale o una VPN mette davanti ai computer degli utenti: quando qualcuno naviga, la richiesta passa prima dal forward proxy, che poi parla con i siti esterni al posto suo. Serve a controllare e filtrare il traffico in uscita e, spesso, a nascondere l'identità di chi naviga.

Un reverse proxy sta davanti ai server. È l'intermediario che il gestore di un sito mette davanti alle proprie applicazioni. La documentazione di MDN riassume bene il contrasto: un forward proxy agisce per conto dei client e può nasconderne l'identità, mentre un reverse proxy può nascondere l'identità dei server. Stessa idea di base, lato opposto: uno protegge chi chiede, l'altro protegge chi risponde.

::cta{variant="inline" title="La tua applicazione è ancora esposta direttamente su internet?" text="Mettiamo noi un reverse proxy davanti al tuo servizio: configurazione Nginx, certificati TLS e hardening, senza interruzioni." button="Chiedi una valutazione gratuita →"}

Un solo ingresso per più servizi

Il motivo più concreto per cui il reverse proxy è così diffuso è che offre un solo punto d'ingresso per molti servizi. Su internet un sito è raggiungibile su due porte standard: la 80 per HTTP e la 443 per HTTPS. Ma dietro un singolo dominio possono vivere applicazioni diverse: il sito vetrina, l'area clienti, un'API per le app mobili, un pannello di amministrazione.

Il reverse proxy ascolta su quell'unica porta pubblica e, guardando il nome del dominio o il percorso richiesto, decide a quale applicazione interna girare ogni richiesta. Le applicazioni, dal canto loro, restano in ascolto solo sulla rete locale della macchina, senza essere esposte direttamente a internet. Un esempio essenziale con Nginx, uno dei reverse proxy più usati, rende l'idea:

server {
    listen 443 ssl;
    server_name sito.example.com;
    # ...certificati TLS...

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Qui il proxy riceve le connessioni cifrate dall'esterno e le inoltra a un'applicazione che gira in locale sulla porta 3000. Il visitatore vede un solo indirizzo; dietro le quinte può esserci un intero insieme di servizi.

TLS: la cifratura gestita in un posto solo

Oggi il traffico web viaggia cifrato con TLS, il protocollo che sta dietro il lucchetto di HTTPS. Gestire la cifratura richiede certificati, chiavi e configurazione, e non è un lavoro che conviene duplicare in ogni singola applicazione.

Il reverse proxy risolve il problema con la terminazione TLS: è lui a occuparsi dell'"handshake" cifrato con il browser, a decifrare le richieste in arrivo e a cifrare le risposte in uscita, così che i server dietro di lui non debbano farlo. I certificati stanno in un posto solo, la configurazione della sicurezza si aggiorna in un punto solo, e le applicazioni interne possono parlare in chiaro sulla rete locale, concentrandosi sul loro compito.

Cache e compressione: meno lavoro ripetuto

Un reverse proxy può anche conservare una copia delle risposte già calcolate. È la cache: se molti utenti chiedono la stessa immagine o la stessa pagina, non serve rigenerarla ogni volta. La prima richiesta paga il costo pieno verso l'applicazione; le successive ricevono la copia già pronta, molto più in fretta e senza affaticare il server d'origine.

Allo stesso livello agisce la compressione: il proxy può comprimere testi, HTML e dati prima di spedirli, riducendo i byte che viaggiano in rete e quindi i tempi di caricamento. Sono ottimizzazioni che è comodo mettere una volta sola, davanti a tutto, invece di reimplementarle in ogni applicazione.

Bilanciamento del carico

Quando un solo server non basta a reggere il traffico, si mettono più copie della stessa applicazione e si distribuiscono le richieste fra loro. Questo compito, il bilanciamento del carico (load balancing), è uno degli usi classici del reverse proxy.

Il proxy decide a quale server inoltrare ogni richiesta secondo una regola. Nginx, per esempio, di default usa il round robin, cioè distribuisce le richieste a turno fra i server disponibili tenendo conto di eventuali pesi; in alternativa può mandare ogni richiesta al server con meno connessioni attive (least connections) o legare un cliente sempre allo stesso server in base al suo indirizzo (ip hash). Il vantaggio è doppio: si regge più traffico e, se un server si guasta, gli altri continuano a rispondere.

Sicurezza: un filtro davanti all'applicazione

Mettere un intermediario davanti ai server ha anche un valore difensivo. Il primo è la riduzione della superficie esposta: le applicazioni non sono raggiungibili direttamente da internet, ma solo attraverso il proxy. Chi vuole attaccarle non ne conosce nemmeno l'indirizzo reale, perché a rispondere è sempre e solo l'intermediario.

Il secondo è che il reverse proxy diventa il punto naturale dove concentrare i controlli: limitare il numero di richieste per bloccare gli abusi (rate limiting), filtrare traffico sospetto, applicare regole di accesso. Farlo in un solo punto, davanti a tutto, è più semplice e più robusto che spargere le stesse difese in ogni applicazione.

Nginx e gli altri

Nginx è forse l'esempio più citato, ma il reverse proxy è un ruolo, non un prodotto. Lo stesso compito lo svolgono software come HAProxy, Apache, Caddy, Traefik o Envoy, i bilanciatori offerti dai fornitori cloud e, su scala globale, le CDN come quelle di Cloudflare, che sono anch'esse reverse proxy davanti a milioni di siti.

Vale la pena notare che il pattern non è legato al solo HTTP: un reverse proxy può inoltrare le richieste alle applicazioni anche con altri protocolli, e infatti Nginx supporta, oltre a HTTP, meccanismi come FastCGI, uwsgi, SCGI, memcached e gRPC. Il concetto resta lo stesso a prescindere dallo strumento scelto.

In sintesi

Un reverse proxy è l'intermediario che sta davanti alle applicazioni web e fa da unico punto di contatto verso l'esterno. Da lì gestisce la cifratura TLS, la cache e la compressione, distribuisce il carico fra più server e concentra i controlli di sicurezza, tenendo le applicazioni al riparo dall'esposizione diretta. Non è un componente vistoso e quasi nessun utente sa che c'è, ma è proprio per questo che quasi ogni sito ne usa uno: risolve in un posto solo una serie di problemi che, altrimenti, ogni applicazione dovrebbe affrontare da sé.

::cta{title="Vuoi mettere Nginx davanti alla tua infrastruttura?" text="Progettiamo e gestiamo reverse proxy in produzione da vent'anni: terminazione TLS, cache, bilanciamento del carico e regole di sicurezza tarate sul tuo servizio." button="Parliamone →"}

Fonti

Un header HTTP standard per dire che un'API è deprecata (RFC 9745)

Alessandro Corbelli — Tue, 25 Mar 2025 00:00:00 GMT

Chi mantiene un'API si trova prima o poi a dover ritirare qualcosa: un indirizzo che risponde da anni, un formato di risposta, un'intera versione del servizio. Il problema non è tecnico, è di comunicazione. Come si avvisa chi usa quell'API che sta per sparire, senza sperare che qualcuno legga la mail giusta o la nota giusta nel changelog? A marzo 2025 l'IETF, l'organismo che cura gli standard tecnici di Internet, ha pubblicato la RFC 9745 e ha reso standard un modo semplice per dirlo dentro le risposte stesse: l'intestazione HTTP Deprecation, uno dei tanti aggiornamenti con cui l'IETF sta ampliando il protocollo, insieme per esempio al nuovo metodo HTTP QUERY.

Il problema: avvisare le macchine, non solo le persone

Prima un po' di vocabolario, perché serve. Un'API è l'interfaccia con cui due programmi si parlano via rete. Un endpoint è uno degli indirizzi che quell'API espone. Un'intestazione (in inglese header) è una riga di informazioni di servizio che accompagna ogni richiesta e ogni risposta HTTP, separata dal contenuto vero e proprio. E deprecare una risorsa significa dichiararla ancora funzionante ma in via di dismissione: si può usare, ma conviene smettere e passare ad altro.

Fin qui la deprecazione si annuncia quasi sempre a parole: un post sul blog, una voce nella documentazione, un'email agli sviluppatori. Va bene per le persone, ma non per il software. Un programma che chiama un'API mille volte al giorno non legge il blog. Continua a chiamare quell'endpoint finché un giorno smette di rispondere, e a quel punto è un guasto in produzione. Manca un modo perché sia la risposta stessa a dire, in forma leggibile da un computer: "attenzione, questa risorsa è in via di dismissione".

È esattamente il vuoto che la RFC 9745 vuole colmare.

Cos'è la RFC 9745

La RFC 9745 si intitola The Deprecation HTTP Response Header Field ed è stata pubblicata nel marzo 2025 dall'IETF, con Sanjay Dalal ed Erik Wilde come autori. Definisce una nuova intestazione di risposta, Deprecation, con cui un server segnala a chi usa una risorsa che quella risorsa sarà o è già stata deprecata.

Il meccanismo è volutamente minimale. Il server aggiunge una riga alle proprie risposte HTTP e chi le riceve - un client, uno strumento di monitoraggio, una libreria - può leggerla in automatico. Nessun cambiamento al contenuto, nessuna rottura: solo un segnale in più.

::cta{variant="inline" title="Le tue API comunicano già quando un endpoint sta per sparire?" text="Controlliamo il ciclo di vita delle API che mantieni e cosa succede quando serve ritirare un endpoint." button="Chiedi una verifica →"}

Come si scrive: una data, e basta

Il valore dell'intestazione è una data, espressa nel formato dei Structured Fields di HTTP (RFC 9651), lo standard che definisce come scrivere valori strutturati dentro le intestazioni in modo che tutti li interpretino allo stesso modo. In pratica la data si scrive come un timestamp Unix - cioè il numero di secondi trascorsi dal 1° gennaio 1970 - preceduto da una chiocciola. Un esempio dalla specifica:

Deprecation: @1688169599

Quel numero corrisponde al 30 giugno 2023 alle 23:59:59 UTC. La cosa interessante è che la data può stare nel futuro o nel passato. Nel futuro significa "questa risorsa verrà deprecata a partire da quel momento": un preavviso. Nel passato significa "è già deprecata da allora". Con una sola riga il server comunica sia l'intenzione sia il fatto compiuto.

Deprecato non vuol dire spento

Qui va chiarito un equivoco frequente, e la RFC è esplicita. Deprecare non cambia il comportamento della risorsa. Un endpoint deprecato continua a funzionare come prima: risponde, restituisce gli stessi dati, non cambia significato. La presenza dell'intestazione non è un errore e non impone di smettere di usarlo da subito. È un avviso, non una porta chiusa.

Deprecazione e dismissione sono due momenti distinti. La deprecazione dice "inizia a spostarti"; la dismissione (in inglese sunset) è il giorno in cui la risorsa smetterà davvero di rispondere. Tra i due c'è, o dovrebbe esserci, il tempo per migrare.

Il compagno naturale: l'intestazione Sunset

Proprio per indicare quel giorno esiste un'altra intestazione standard, Sunset, definita dalla RFC 8594. Mentre Deprecation dice "da quando è deprecata", Sunset dice "da quando smetterà di funzionare". Le due si usano bene insieme, e la RFC 9745 mette un vincolo di buon senso: la data di Sunset non può essere precedente a quella di Deprecation. Non avrebbe senso spegnere una risorsa prima ancora di averla dichiarata in dismissione.

Dire cosa usare al posto suo: la relazione "deprecation"

Una data, da sola, non dice tutto. Non spiega perché la risorsa viene ritirata, cosa usare in alternativa, entro quando completare il passaggio. Per questo la RFC 9745 definisce anche una link relation chiamata deprecation: un modo standard per collegare, sempre via intestazione, una pagina di documentazione dove sta il resto della storia. L'esempio della specifica è questo:

Deprecation: @1688169599
Link: <https://developer.example.com/deprecation>;
      rel="deprecation"; type="text/html"

L'intestazione Link punta a un indirizzo, e rel="deprecation" dichiara che quel collegamento parla proprio della dismissione. Lì il fornitore dell'API può descrivere la politica di deprecazione, la tempistica e - quando esiste - la risorsa che prende il posto di quella vecchia, con una guida alla migrazione. La documentazione può anche fissare una regola chiara, per esempio che ogni deprecazione verrà annunciata con un certo numero di giorni di anticipo rispetto alla data di spegnimento.

Perché conta nel ciclo di vita di un'API

Il valore di tutto questo non è l'intestazione in sé, ma il fatto che finalmente un avviso di dismissione sia leggibile dalle macchine, lo stesso principio dietro ad altri segnali HTTP pensati per i client automatici, come quello che permette di far pagare i crawler AI. Cambia diverse cose pratiche.

Un client può accorgersi da solo di star chiamando un endpoint deprecato e scriverlo nei propri log, invece di scoprirlo il giorno in cui l'endpoint muore.
Uno strumento di monitoraggio può controllare le risposte e far scattare un avviso quando compare l'intestazione, dando al team il tempo di reagire.
Chi consuma decine di API diverse può misurare quanto "debito" ha accumulato, cioè quante dipendenze stanno per sparire, senza inseguire changelog scritti in modi diversi da ogni fornitore.

In una parola, la gestione del ciclo di vita di un'API smette di dipendere dal fatto che una persona abbia letto la comunicazione giusta al momento giusto. Il segnale viaggia insieme ai dati.

A che punto è

Un chiarimento sullo stato, perché è facile fraintenderlo. La RFC 9745 è uno Standard Proposto (Proposed Standard): non è una bozza né un documento sperimentale, ma il primo gradino stabile della via degli standard IETF, lo stesso livello raggiunto anche dallo schema di autenticazione HTTP Concealed. Significa che il testo è maturo, rivisto pubblicamente e citabile, e che l'intestazione Deprecation è stata registrata in modo permanente nel registro ufficiale dei nomi di campo HTTP. Da qui in avanti chi progetta API può adottarla sapendo che il significato è fissato una volta per tutte.

Resta il lavoro di adozione, che dipende dai singoli fornitori: il valore dell'intestazione si vede solo quando i server la inviano e i client la leggono. Ma la parte difficile - mettersi d'accordo su un formato unico e sensato - è fatta. Per chi mantiene API, aggiungere un'intestazione Deprecation (e possibilmente una Sunset e un link alla documentazione) è un gesto piccolo che rende una dismissione molto meno traumatica per chi sta dall'altra parte.

::cta{title="Vuoi gestire la dismissione delle tue API senza sorprese per chi le usa?" text="Progettiamo e manuteniamo API Laravel con header di deprecazione, documentazione di migrazione e piani di dismissione concordati con chi le consuma." button="Parliamone →"}

Fonti

Attacchi brute force: cosa sono e come ci si difende

Alessandro Corbelli — Thu, 10 Apr 2025 00:00:00 GMT

Ogni servizio raggiungibile da internet - la casella di posta, il pannello di amministrazione di un sito, l'accesso remoto a un server - prima o poi riceve tentativi di indovinare le sue credenziali. Spesso non c'è nulla di personale: gran parte di quel traffico è automatico e indiscriminato. Capire cos'è un attacco brute force, perché è così comune e con quali difese di fondo si affronta aiuta a proteggere qualsiasi sistema esposto senza affidarsi a soluzioni magiche.

Cos'è un attacco brute force

Un attacco brute force (in italiano "forza bruta") è il tentativo di indovinare una credenziale - una password, un codice, una chiave - provando molte combinazioni una dopo l'altra finché una funziona. Non c'è astuzia: c'è volume. La documentazione di OWASP, l'organizzazione no profit che si occupa di sicurezza delle applicazioni web, lo descrive come il configurare valori predefiniti, inviarli al server e analizzare la risposta per capire se hanno funzionato. Il nome dice tutto: si tira a indovinare, ma tante volte e in fretta.

Il motore di questi attacchi è l'automazione. Un essere umano che prova password a mano è lentissimo; un programma ne prova migliaia al secondo. Da qui la distinzione classica tra due approcci. Nel brute force "puro" si generano le combinazioni una a una (tutte le sequenze di lettere, numeri e simboli): esaustivo ma lento, tanto più lento quanto più la password è lunga. Nell'attacco a dizionario si parte invece da liste di parole e password comuni, spesso raccolte da vecchie violazioni di dati: meno esaustivo, ma molto più veloce a colpire chi usa credenziali deboli o già note.

Perché ogni servizio esposto ne riceve

La domanda più naturale è: perché proprio il mio server? Nella maggior parte dei casi la risposta è che non è "il tuo". Le reti di computer compromessi (le cosiddette botnet) scandagliano interi intervalli di indirizzi IP alla ricerca di porte aperte e pagine di login. Trovato un bersaglio, provano credenziali predefinite, password comuni e coppie utente/password trapelate da altri servizi. È traffico di fondo, come il rumore in una città: chiunque abbia una porta SSH, un server di posta o un modulo di accesso ne riceve, spesso migliaia di tentativi al giorno. E quando la porta esposta ha una falla nota, come è successo con SSH sui router MikroTik, non serve nemmeno indovinare.

Questo cambia il modo di ragionare. Non serve aspettarsi di essere un bersaglio "interessante": basta essere raggiungibili. E poiché gli attacchi sono automatici ed economici, non si fermano da soli. La difesa non consiste nel diventare invisibili, ma nel rendere ogni tentativo abbastanza costoso e poco redditizio da non portare a nulla.

::cta{variant="inline" title="Il tuo server riceve già questi tentativi, senza che tu lo sappia?" text="Controlliamo i log di accesso e verifichiamo se le difese di base, come fail2ban e MFA, sono già attive." button="Chiedi una verifica →"}

Non un solo attacco, ma una famiglia

Sotto l'etichetta "brute force" rientrano varianti che conviene distinguere, perché richiedono difese leggermente diverse.

Attacco a dizionario. Come detto, usa liste di parole e password frequenti invece di provare ogni combinazione. È efficace contro password prevedibili come password123 o il nome dell'azienda.
Credential stuffing. OWASP lo classifica come un sottoinsieme del brute force. Qui l'attaccante non indovina: riusa coppie utente/password rubate da una violazione per provarle su altri servizi. Funziona per un motivo semplice e diffuso: molte persone riutilizzano la stessa password ovunque. Se è trapelata da un sito, viene provata su tutti gli altri.
Password spraying. L'attaccante prova poche password molto comuni contro moltissimi account diversi, invece di accanirsi su uno solo. Serve a evitare i blocchi che scattano dopo troppi tentativi falliti sullo stesso utente.

Le difese di fondo

Nessuna singola misura basta. La protezione efficace è fatta di più livelli che si sommano, in modo che il fallimento di uno non lasci la porta spalancata.

Password e chiavi robuste

La prima barriera è rendere la credenziale difficile da indovinare. Una password lunga aumenta enormemente il numero di combinazioni possibili, e quindi il tempo necessario a provarle tutte. Le linee guida di OWASP indicano una lunghezza minima di 15 caratteri quando non c'è un secondo fattore, e suggeriscono di consentire password fino ad almeno 64 caratteri per non penalizzare le passphrase, cioè frasi facili da ricordare e difficili da indovinare. Altrettanto importante è non riutilizzare la stessa password su più servizi: un gestore di password aiuta a tenerne una diversa e casuale per ciascuno, anche se dove il servizio lo consente il modo più efficace resta sostituirla del tutto con una passkey.

Sui server c'è un'opzione ancora migliore delle password: le chiavi crittografiche. Una chiave SSH è enormemente più lunga e casuale di qualsiasi password memorizzabile, al punto da rendere il brute force praticamente inutile. Sostituire l'accesso con password con l'accesso a chiave elimina alla radice gran parte del problema, una misura che si può rafforzare ulteriormente restringendo l'ingresso dietro una VPN come WireGuard.

Autenticazione a più fattori (MFA)

L'autenticazione a più fattori (in inglese multi-factor authentication, MFA) richiede, oltre alla password, un secondo elemento indipendente: un codice temporaneo da un'app, una chiave fisica, un'impronta. L'idea è che indovinare o rubare la sola password non basti più. Secondo OWASP, la MFA è di gran lunga la migliore difesa contro la maggior parte degli attacchi legati alle password, brute force compreso; la stessa fonte riporta una stima di Microsoft secondo cui avrebbe fermato il 99,9% delle compromissioni di account. È la misura che, da sola, sposta di più l'ago della bilancia: anche se un attaccante azzecca la password, senza il secondo fattore non entra.

Rallentare e limitare i tentativi

Se un attacco vive di volume e velocità, una difesa naturale è togliergli entrambi. Il rate limiting (limitazione della frequenza) mette un tetto al numero di tentativi accettati in un dato intervallo di tempo. Piccole pause dopo ogni errore, un blocco temporaneo dopo N fallimenti (account lockout), o un CAPTCHA - quei test facili per un umano e fastidiosi per un programma - rendono l'attacco lento e poco pratico.

Qui però serve onestà: OWASP avverte che il blocco puro dell'account può ritorcersi contro di noi. Un attaccante può inondare di tentativi sbagliati l'account di un utente legittimo apposta per bloccarlo fuori, trasformando la difesa in un piccolo attacco di negazione del servizio. Per questo si preferiscono spesso approcci più mirati, legati al dispositivo o all'indirizzo di provenienza, che colpiscono l'origine dell'abuso invece dell'utente.

Bloccare gli IP che insistono

L'ultimo livello è reagire a chi continua a provare. Esistono strumenti che osservano i log del sistema, da conservare nel rispetto dei principi di minimizzazione previsti dal GDPR, e bloccano automaticamente gli indirizzi troppo insistenti. L'esempio più noto sul mondo Linux è fail2ban, software libero che, come recita la sua descrizione ufficiale, analizza i file di log (per esempio /var/log/auth.log), individua gli indirizzi IP responsabili di troppi tentativi di accesso falliti e li banna aggiornando le regole del firewall di sistema per rifiutarne le nuove connessioni per un tempo configurabile.

In pratica: se un indirizzo sbaglia le credenziali troppe volte in poco tempo, gli viene chiusa la porta per minuti o ore. Non impedisce il primo tentativo, ma spegne il rumore di fondo e alza il costo dell'insistenza. È un buon esempio di difesa reattiva, complementare - non alternativa - alle precedenti.

I limiti da tenere presenti

Bloccare gli IP non è una soluzione definitiva, ed è giusto saperlo. Un attacco distribuito su migliaia di indirizzi diversi, ciascuno con pochi tentativi, può restare sotto le soglie e non far scattare alcun blocco; lo stesso vale per gli attacchi "lenti", spalmati nel tempo. E soprattutto, nessun blocco basato sui tentativi falliti aiuta contro il credential stuffing che indovina la password giusta al primo colpo: lì l'unica vera rete di sicurezza è il secondo fattore.

Questo è il punto centrale: non esiste un singolo strumento che risolva il problema. È la somma dei livelli - credenziali robuste, MFA, limiti sui tentativi e blocco degli abusi - a rendere un attacco brute force poco più che rumore.

In sintesi

Un attacco brute force è il tentativo automatico di indovinare le credenziali provandone molte in fretta. Ogni servizio esposto ne riceve, perché gli attacchi sono automatici, economici e indiscriminati. Le difese di fondo sono poche e si rafforzano a vicenda: password lunghe e non riutilizzate (meglio ancora chiavi crittografiche sui server), autenticazione a più fattori, limiti alla frequenza dei tentativi e strumenti come fail2ban che bloccano gli indirizzi insistenti. Nessuna di queste, da sola, è sufficiente. Messe insieme, trasformano un problema serio in un fastidio gestibile.

::cta{title="Vuoi mettere in sicurezza gli accessi ai tuoi server?" text="Configuriamo fail2ban, autenticazione a più fattori e accesso a chiave sui server Linux che gestiamo, con il monitoraggio degli accessi sospetti incluso nella reperibilità." button="Parliamone →"}

Fonti

Certificati TLS verso i 47 giorni: l'automazione diventa obbligatoria

Alessandro Corbelli — Tue, 15 Apr 2025 00:00:00 GMT

Ogni sito raggiungibile via https usa un certificato: un piccolo documento digitale che dimostra che quel sito è davvero chi dice di essere, e che permette al browser di cifrare la connessione dopo un breve scambio iniziale, l'handshake TLS. Fin qui niente di nuovo. La novità è che questi certificati dureranno molto meno di adesso. Un gruppo che decide le regole per l'intero settore ha approvato un calendario che porterà la durata massima da poco più di un anno a soli 47 giorni entro il 2029. Per chi visita i siti non cambia nulla. Per chi li gestisce cambia parecchio, perché rinnovare un certificato a mano ogni mese e mezzo non è sostenibile: l'automazione smette di essere un lusso e diventa un requisito.

La notizia in breve

L'organismo che stabilisce queste regole si chiama CA/Browser Forum. È l'insieme in cui si incontrano due categorie: le Autorità di Certificazione (in inglese Certificate Authority, o CA), cioè le aziende che emettono i certificati, e i produttori di browser come Apple, Google, Microsoft e Mozilla, che decidono quali certificati considerare validi. Quando questi soggetti si accordano su una regola, quella regola vale nella pratica per tutto il web pubblico.

L'11 aprile 2025 il Forum ha approvato una proposta identificata dalla sigla SC-081v3. La proposta era stata presentata da un rappresentante di Apple e sostenuta da Sectigo, Google e Mozilla. Non si tratta quindi di una bozza o di un'idea in discussione: è una decisione presa, con un calendario preciso e vincolante. Il voto è stato favorevole senza contrari: nessuna delle Autorità di Certificazione e nessun produttore di browser si è opposto.

Il calendario dei tagli

La riduzione non avviene di colpo. È spalmata su tre tappe, con date precise. Oggi un certificato TLS può durare al massimo 398 giorni, cioè poco più di un anno. Da qui si scende così:

Dal 15 marzo 2026: durata massima 200 giorni
Dal 15 marzo 2027: durata massima 100 giorni
Dal 15 marzo 2029: durata massima 47 giorni

Le date indicano quando entra in vigore ciascun limite per i certificati emessi da quel giorno in poi. Un certificato ottenuto prima di una scadenza resta valido per il periodo con cui è stato emesso; il nuovo limite si applica alle emissioni successive. In pratica la stretta si sente in modo graduale, ma la direzione è una sola e non torna indietro.

::cta{variant="inline" title="Sai già quanti certificati TLS gestisci e quando scadono?" text="Facciamo un inventario rapido e verifichiamo cosa succederebbe con un rinnovo ogni 47 giorni." button="Chiedi un inventario →"}

Perché accorciare la validità

La domanda naturale è: perché complicarsi la vita? Il motivo principale è la sicurezza, e ruota attorno a un concetto semplice, la finestra di compromissione.

Un certificato è legato a una chiave privata, un file segreto che deve restare sul server e non uscire mai. Se quella chiave viene rubata - per un attacco, una configurazione sbagliata, un backup finito nel posto sbagliato - chi la possiede può impersonare il sito fino a quando il certificato resta valido. Più lungo è il certificato, più lunga è la finestra in cui un furto passa inosservato e fa danni.

In teoria esiste un rimedio: la revoca, cioè la possibilità di dichiarare un certificato non più valido prima della sua scadenza. Nella pratica la revoca funziona male. I browser non sempre controllano se un certificato è stato revocato, e i meccanismi pensati per avvisarli sono lenti o poco affidabili. Accorciare la durata è un modo più solido di ottenere lo stesso effetto: un certificato che dura poco limita da solo i danni, perché scade prima che il problema possa protrarsi. È meno elegante della revoca, ma funziona davvero.

C'è anche una ragione più ampia. Certificati che durano un anno tendono a essere trattati come oggetti da configurare una volta e dimenticare. Ridurne la vita costringe tutti ad automatizzare la gestione, e un processo automatico e frequente è più sicuro di uno manuale e raro: sbaglia meno, non dipende dalla memoria di una persona, non lascia certificati scaduti per dimenticanza.

Non cambia solo la scadenza

La stessa decisione tocca un secondo aspetto meno visibile ma altrettanto importante: la riconvalida del dominio. Prima di emettere un certificato per un sito, l'Autorità di Certificazione deve verificare che chi lo chiede controlli davvero quel dominio. Questo controllo si chiama Domain Control Validation (DCV). Una volta fatto, oggi il risultato può essere riutilizzato per un lungo periodo: si dimostra il controllo del dominio una volta e lo si dà per buono per mesi.

Anche questo periodo di riutilizzo viene accorciato con lo stesso calendario, fino ad arrivare a soli 10 giorni dal 15 marzo 2029. Significa che non basterà rinnovare spesso il certificato: bisognerà anche riprovare spesso di controllare il dominio. I metodi lenti e manuali - come la verifica via e-mail o il caricamento a mano di un file su un server - diventano impraticabili a questa frequenza. Serve un sistema che dimostri il controllo del dominio da solo, in automatico, tutte le volte che serve.

Il rinnovo manuale non regge più

Mettiamo insieme i pezzi. Con la durata massima a 47 giorni, ogni certificato va sostituito prima che scada, quindi in pratica ogni mese circa. Per chi gestisce un sito solo è un fastidio; per chi ne gestisce decine o centinaia diventa impossibile da seguire a mano. Basta un rinnovo dimenticato perché un sito mostri ai visitatori l'avviso di certificato scaduto - quello schermo rosso che spinge la gente a scappare - con danni immediati a immagine e vendite.

La conclusione a cui punta esplicitamente questa decisione è che la gestione dei certificati va automatizzata. Non come miglioria opzionale, ma come unico modo per stare dietro alla frequenza richiesta.

L'automazione si chiama ACME

Lo strumento per farlo esiste già ed è diffuso. Si chiama ACME (Automatic Certificate Management Environment), ed è un protocollo standard - cioè un linguaggio comune - con cui un server può chiedere, ottenere e rinnovare certificati da solo, dialogando con l'Autorità di Certificazione senza intervento umano. È lo stesso meccanismo reso popolare da Let's Encrypt, l'autorità gratuita che da anni emette certificati validi 90 giorni proprio perché progettati per essere rinnovati in automatico.

Il funzionamento, in parole semplici, è questo: un programma installato sul server dimostra all'Autorità di controllare il dominio, riceve il certificato, lo installa e programma da sé il rinnovo prima della scadenza. Tutto senza che nessuno debba ricordarsi nulla. Il client più noto si chiama certbot, ma quasi tutti i pannelli di controllo, i bilanciatori di carico e i servizi cloud moderni integrano già il supporto ad ACME. Chi lo usa già non deve fare quasi nulla: la riduzione della durata è, per lui, un dettaglio che il sistema gestisce da solo.

Un esempio della logica, con certbot, per ottenere e configurare un certificato su un server web:

certbot --nginx -d esempio.it -d www.esempio.it

Da quel momento il rinnovo avviene in automatico, di solito tramite un'attività pianificata che gira più volte al giorno e rinnova i certificati quando si avvicinano alla scadenza.

Cosa conviene fare adesso

Non c'è nessuna urgenza per la giornata di oggi, ma la direzione è chiara e vale la pena portarsi avanti con calma invece di rincorrere le scadenze.

Fare un inventario. Sapere quanti certificati si gestiscono, dove sono e quando scadono. Spesso ce ne sono più di quanti si ricordi.
Verificare cosa è già automatico e cosa no. I certificati ancora rinnovati a mano sono quelli che daranno problemi per primi.
Adottare ACME dove manca. Passare i rinnovi manuali a un client automatico è l'investimento che ripaga di più, perché elimina la parte fragile del processo.
Non aspettare il 2029. Chi si automatizza ora attraversa le tre tappe senza accorgersene. Chi rimanda si troverà a gestire a mano una frequenza che a mano non si gestisce.

In sintesi

La validità dei certificati TLS scende per gradi fino a 47 giorni entro il 2029, insieme al periodo di riutilizzo delle verifiche del dominio, che arriva a 10 giorni. È una decisione presa, non una proposta. Il motivo è ridurre il tempo in cui un certificato compromesso può fare danni, in un mondo in cui la revoca funziona male. Per chi naviga non cambia nulla. Per chi gestisce siti il messaggio è netto: il rinnovo manuale ha una data di scadenza, e l'automazione tramite ACME è la strada già pronta per non pensarci più.

::cta{title="Pronto a togliere il rinnovo dei certificati dalla lista delle cose da ricordare?" text="Configuriamo ACME e il rinnovo automatico su server, reverse proxy e bilanciatori di carico, così i certificati si rinnovano da soli anche con scadenze di poche settimane." button="Automatizziamo →"}

Fonti

Chrome non eliminerà i cookie di terze parti: cosa cambia

Alessandro Corbelli — Thu, 24 Apr 2025 00:00:00 GMT

Per anni una scadenza ha guidato i piani di mezzo web: Chrome, il browser più usato al mondo, avrebbe smesso di accettare i cookie di terze parti, quelli che permettono di seguire una persona da un sito all'altro. Interi settori - pubblicità online, misurazione del traffico, sistemi di login condivisi - si erano messi a riprogettare i propri strumenti per un mondo "senza cookie". Il 22 aprile 2025 Google ha annunciato che quel mondo non arriverà: Chrome manterrà l'approccio attuale ai cookie di terze parti e non introdurrà nemmeno la nuova richiesta di scelta che aveva promesso l'anno prima. Per chi naviga non cambia quasi nulla. Per chi lavora con analytics, pubblicità e autenticazione tra siti diversi, cambia il quadro su cui aveva lavorato a lungo.

La notizia in breve

L'annuncio è arrivato sul blog della Privacy Sandbox, il progetto con cui Google stava provando a sostituire i cookie di terze parti. In sintesi: Google mantiene l'attuale sistema di scelta sui cookie di terze parti in Chrome e non introdurrà una nuova richiesta dedicata che chieda all'utente se accettarli o rifiutarli. Le persone continuano a gestire questa preferenza dove già possono farlo oggi, cioè nelle impostazioni di privacy e sicurezza del browser.

Nello stesso testo Google aggiunge due cose. La prima: le tecnologie della Privacy Sandbox "potrebbero avere un ruolo diverso" da quello previsto, e nei mesi successivi verrà condivisa una road map aggiornata. La seconda: le protezioni contro il tracciamento nella navigazione in incognito proseguono, con l'arrivo previsto nel terzo trimestre del 2025 della cosiddetta IP Protection, una funzione che nasconde l'indirizzo di rete in quella modalità. È un annuncio di direzione, non una specifica tecnica: i dettagli del nuovo piano erano, al momento, ancora da definire.

Cosa sono i cookie di terze parti

Un cookie è un piccolo file che un sito chiede al browser di salvare, per ricordarsi qualcosa tra una visita e l'altra: che hai fatto il login, cosa hai messo nel carrello, la lingua che preferisci. Fin qui è comodo e innocuo.

La differenza sta in chi imposta il cookie. Un cookie di prima parte appartiene al sito che stai visitando, quello scritto nella barra degli indirizzi. Un cookie di terze parti, invece, viene impostato da un dominio diverso: tipicamente una rete pubblicitaria, uno strumento di statistiche, un pulsante social o un contenuto incorporato (per esempio un video). Siccome lo stesso fornitore è presente su tanti siti diversi, quel cookie gli permette di riconoscere la stessa persona mentre si sposta da un sito all'altro. È questo il meccanismo che rende possibile il tracciamento tra siti: costruire un profilo di ciò che uno guarda in giro per il web, soprattutto a fini pubblicitari.

Vale la pena essere onesti: i cookie di terze parti non servono solo alla pubblicità invadente. Sostengono anche usi legittimi, come misurare se una campagna ha portato una vendita, evitare di mostrare lo stesso annuncio cento volte, e far funzionare alcuni sistemi di login unico tra siti diversi (in inglese single sign-on, o SSO), spesso costruiti sopra protocolli come OAuth, dove ci si autentica una volta e si resta riconosciuti su più domini collegati. Per questo la loro rimozione toccava tanti equilibri insieme.

::cta{variant="inline" title="Il tuo sito dipende ancora da cookie di terze parti per login o misurazioni?" text="Mappiamo le dipendenze reali (SSO, pixel pubblicitari, analytics) e verifichiamo cosa succede se un browser li blocca." button="Chiedi una mappatura →"}

Come ci siamo arrivati

La storia parte nel 2019, quando Google presenta la Privacy Sandbox con un obiettivo dichiarato: togliere da Chrome i cookie di terze parti e rimpiazzarli con nuove tecnologie pensate per fare le stesse cose (pubblicità mirata, misurazione) senza seguire il singolo utente. L'idea era buona sulla carta, ma il traguardo è stato rinviato più volte, perché costruire alternative accettabili per tutti - inserzionisti, editori, autorità - si è rivelato difficile.

C'è anche un fronte regolatorio. Nel 2022 Google ha avviato un impegno formale con le autorità britanniche per la concorrenza (la CMA) e per la protezione dei dati (l'ICO). Il timore era che, rimuovendo i cookie di terze parti, Google finisse per favorire il proprio sistema pubblicitario a scapito dei concorrenti più piccoli, che di quei cookie vivono. Un cambiamento venduto come tutela della privacy rischiava così di diventare anche una questione di concorrenza.

La svolta vera arriva il 22 luglio 2024: invece di eliminare i cookie di terze parti, Google annuncia che introdurrà "una nuova esperienza in Chrome" con cui l'utente sceglie una volta come comportarsi, potendo poi cambiare idea quando vuole. Nove mesi dopo, il 22 aprile 2025, anche quella nuova richiesta viene accantonata: si tiene ciò che c'è già nelle impostazioni, senza aggiungere prompt. In pratica, in poco più di un anno il piano è passato da "rimuoviamo i cookie" a "lasciamo scegliere l'utente" a "non cambiamo l'esperienza attuale".

Perché la giravolta conta

Per chi visita i siti, ripetiamolo, l'effetto pratico è minimo. Il peso ricade su chi costruisce e gestisce servizi.

Pubblicità online. Molti operatori avevano investito tempo e denaro per testare le nuove interfacce della Privacy Sandbox - con nomi come Topics, Protected Audience e Attribution Reporting - pensate per rimpiazzare i cookie. Ora che la scadenza che spingeva quella migrazione non c'è più, e che Google stesso dice che quelle tecnologie "potrebbero avere un ruolo diverso", quegli investimenti restano in un limbo. Non sono buttati, ma non hanno più una data che li rende obbligatori.

Misurazione e analytics. Attribuire una conversione seguendo l'utente tra domini diversi, per ora, resta possibile con i cookie di terze parti dove il browser li accetta. Chi aveva già iniziato a spostarsi verso metodi che non dipendono da quei cookie non ha lavorato invano, ma la pressione a completare in fretta il passaggio si allenta.

Login tra siti diversi. Alcuni flussi di autenticazione condivisa tra domini si appoggiano ai cookie di terze parti. La loro rimozione li avrebbe rotti, costringendo a riscriverli. La decisione di Chrome toglie, almeno per ora, questa urgenza.

Non vuol dire "tutto come prima"

Sarebbe un errore leggere l'annuncio come un ritorno al passato senza pensieri. Alcuni fatti restano.

Chrome è il browser più diffuso, ma non è l'unico. Safari di Apple e Firefox di Mozilla bloccano già da tempo i cookie di terze parti in modo predefinito. Significa che una fetta importante del traffico gira comunque senza di essi: appoggiare tutto sui cookie di terze parti resta una scelta fragile, indipendentemente da cosa fa Chrome.

Restano anche le protezioni di Chrome nella navigazione in incognito, con la IP Protection attesa per il terzo trimestre 2025, dopo che il browser aveva già esteso ad altri ambiti, come la cifratura post-quantum delle connessioni, il proprio lavoro sulla sicurezza. E resta l'incertezza sul futuro della Privacy Sandbox stessa, il cui ruolo verrà ridefinito.

Infine, un punto che i browser non toccano: le regole sulla privacy. In Europa il GDPR e la normativa ePrivacy richiedono comunque il consenso dell'utente per i cookie di tracciamento. Che Chrome li accetti o no, chi gestisce un sito deve chiedere il consenso quando previsto. La decisione tecnica di Google non cancella gli obblighi di legge.

Cosa conviene fare adesso

Non smontare quello che si è già fatto. La direzione generale del web resta verso meno cookie di terze parti, non di più. Il lavoro fatto per ridurne la dipendenza mantiene valore.
Puntare sui dati di prima parte. Le informazioni raccolte direttamente dal proprio sito, con il consenso dell'utente, sono più solide e meno esposte alle scelte dei browser.
Mappare le dipendenze. Sapere quali funzioni - SSO, contenuti incorporati, misurazione - dipendono davvero dai cookie di terze parti, e avere un piano B per ciascuna.
Seguire la nuova road map. Google ha promesso un aggiornamento nei mesi successivi: vale la pena leggerlo prima di prendere decisioni definitive.

In sintesi

Google ha deciso di non rimuovere i cookie di terze parti da Chrome e di non introdurre nemmeno la richiesta di scelta annunciata nel 2024: resta ciò che c'è già nelle impostazioni. È un cambio di rotta rispetto ad anni di piani "senza cookie", e ridimensiona il ruolo della Privacy Sandbox, il cui futuro sarà chiarito da una road map successiva. Per chi naviga non cambia quasi nulla. Per chi lavora con pubblicità, analytics e login tra siti, il messaggio è di non correre, ma nemmeno di illudersi: altri browser bloccano già quei cookie e le regole sul consenso restano in piedi. La strada verso meno tracciamento è solo diventata meno ripida, non è sparita.

::cta{title="Vuoi mettere il sito al riparo dalle prossime mosse dei browser?" text="Configuriamo consenso cookie conforme al GDPR, dati di prima parte e alternative alle integrazioni che dipendono da cookie di terze parti, per sistemi Laravel e e-commerce." button="Parliamo del tuo sito →"}

Fonti

Cos'è l'Infrastructure as Code e perché conviene

Alessandro Corbelli — Thu, 15 May 2025 00:00:00 GMT

Chi gestisce anche solo un paio di server conosce bene la scena. Si entra nel pannello di controllo di un provider cloud, si clicca per creare una macchina virtuale, si aprono a mano le porte del firewall, si collega un dominio. Funziona. Poi, sei mesi dopo, serve rifare tutto uguale in un secondo ambiente, oppure ricostruire in fretta qualcosa che si è rotto, e nessuno ricorda più l'esatta sequenza di clic. È esattamente il problema che l'Infrastructure as Code prova a risolvere.

Cos'è l'Infrastructure as Code

L'Infrastructure as Code - spesso abbreviato in IaC, letteralmente "infrastruttura come codice" - è l'idea di descrivere l'infrastruttura in file di testo, invece di configurarla a mano cliccando in un pannello. Al posto di ricordare quali pulsanti premere, si scrive un documento che dice come deve essere fatto tutto: quante macchine devono esistere, che dimensione hanno, quali reti le collegano, quali regole di firewall si applicano, quali record DNS puntano dove.

Un programma legge quei file e si occupa di rendere l'infrastruttura reale identica a quanto descritto. Se nel testo c'è scritto che devono esistere due server e ce n'è solo uno, il programma crea il secondo. Se qualcosa non corrisponde più, lo riporta com'è scritto.

Il punto chiave è che questi file sono testo normale, come il codice di un programma. E come il codice, possono essere conservati in un sistema di versionamento come Git - uno strumento che tiene traccia di ogni modifica, di chi l'ha fatta e quando. L'infrastruttura smette di vivere solo dentro la console del provider e nella testa di chi l'ha creata, e diventa qualcosa che si può leggere, condividere e ricostruire.

Perché conviene

I vantaggi non sono astratti. Riguardano problemi che si presentano ogni volta che un'infrastruttura cresce o cambia mani.

Ripetibilità. Lo stesso file produce sempre lo stesso risultato. Serve un ambiente di collaudo identico a quello di produzione? Si riusa la stessa descrizione. Un'intera configurazione va ricreata dopo un guasto? Si riparte dal testo, non dalla memoria. Ciò che era una procedura manuale lunga e soggetta a dimenticanze diventa un'operazione ripetibile.

Revisione. Quando l'infrastruttura è testo, ogni modifica si può leggere e discutere prima di applicarla, ed eventualmente far verificare a una macchina come avviene in una pipeline CI/CD, esattamente come si fa con il codice di un'applicazione. Si vede in anticipo cosa cambierà, un collega può controllare, e resta uno storico di chi ha cambiato cosa. Un'apertura di porta sul firewall smette di essere un clic invisibile e diventa una riga che qualcuno ha scritto, con una data e un motivo.

Meno errori umani. Configurare tante cose a mano, magari in fretta, è il terreno ideale per le sviste: una regola dimenticata su un server, un parametro diverso tra due ambienti che dovrebbero essere identici. Descrivere tutto in un file e lasciare che sia una macchina ad applicarlo elimina buona parte di questi scarti. La stessa descrizione produce la stessa infrastruttura, senza variazioni introdotte dalla stanchezza o dalla fretta.

Documentazione implicita. Nella maggior parte dei progetti la documentazione dell'infrastruttura o non esiste, o è vecchia. Con l'IaC il problema si attenua alla radice: i file sono la descrizione aggiornata di ciò che gira davvero, perché sono la stessa cosa che l'ha creato. Non c'è un documento separato che rischia di divergere dalla realtà: la realtà è il documento.

::cta{variant="inline" title="La tua infrastruttura esiste solo nei clic di qualcuno?" text="Verifichiamo insieme cosa succede se quella persona è in ferie o cambia lavoro." button="Chiedi una verifica →"}

Stato desiderato e idempotenza

Due concetti aiutano a capire come funziona un sistema IaC, e ricorrono in quasi tutti gli strumenti.

Il primo è lo stato desiderato. Con l'approccio manuale si danno comandi imperativi, uno dopo l'altro: "crea questa macchina", "poi apri questa porta", "poi installa questo". Con l'IaC si fa il contrario: si descrive il risultato finale che si vuole ottenere - lo stato desiderato - e si lascia allo strumento il compito di capire quali passi servono per arrivarci. Non si dice come fare, si dice cosa deve esistere. Questo modo di ragionare si chiama dichiarativo, e ha un vantaggio pratico: la descrizione resta valida sia che si parta da zero, sia che quasi tutto esista già.

Il secondo è l'idempotenza. È un termine tecnico per un'idea semplice: applicare la stessa descrizione una volta o dieci volte porta allo stesso risultato. Se l'infrastruttura corrisponde già a quanto scritto, applicare di nuovo non crea doppioni e non cambia nulla. Questa proprietà è ciò che rende gli strumenti IaC sicuri da rieseguire: non c'è il rischio che lanciare due volte lo stesso file raddoppi i server. Lo strumento confronta ciò che c'è con ciò che è descritto, e agisce solo sulla differenza.

Come si presenta in pratica

Un file IaC assomiglia a una serie di descrizioni ordinate. Ecco, a titolo di esempio, come si potrebbe descrivere una singola macchina virtuale con Terraform, uno degli strumenti più diffusi:

resource "aws_instance" "web" {
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

Non serve conoscere la sintassi per cogliere il senso: il blocco dice "deve esistere una macchina virtuale di questo tipo, chiamata web-server". Non spiega come crearla, dice solo che deve esistere. È testo, quindi si può leggere, commentare, versionare.

Il ciclo di lavoro tipico è composto da pochi passi ricorrenti. Prima si scrive la descrizione. Poi si chiede allo strumento un'anteprima - spesso chiamata plan - che confronta il testo con la realtà e mostra esattamente cosa creerebbe, modificherebbe o eliminerebbe, senza toccare ancora niente. Solo dopo aver letto e approvato quell'anteprima si passa ad applicarla, e a quel punto lo strumento esegue le modifiche nell'ordine giusto. Questo passaggio di anteprima è una delle differenze più importanti rispetto al lavoro manuale: si vede cosa succederà prima che succeda.

Terraform e l'ecosistema

Quando si parla di IaC per infrastrutture cloud, lo strumento più citato è Terraform, sviluppato dall'azienda HashiCorp. La documentazione ufficiale lo descrive come uno strumento che permette di "costruire, cambiare e versionare risorse cloud e on-prem in modo sicuro ed efficiente", definendole in file di configurazione leggibili.

Terraform usa un proprio linguaggio, l'HCL (HashiCorp Configuration Language), pensato per essere leggibile anche da chi non lo conosce a fondo. Non parla direttamente con ogni piattaforma: usa dei provider, cioè componenti che traducono la descrizione nelle chiamate specifiche di un servizio - Amazon Web Services, Google Cloud, Azure, e molti altri. HashiCorp e la comunità hanno scritto migliaia di provider, disponibili in un registro pubblico, il che spiega perché lo stesso approccio funzioni su piattaforme molto diverse. Terraform tiene inoltre un file di stato che gli serve da riferimento su ciò che ha già creato.

Vale la pena sapere una cosa sul contesto. Nel 2023 HashiCorp ha cambiato la licenza di Terraform, passando da una licenza open source alla Business Source License, più restrittiva. In risposta, parte della comunità ha creato una versione derivata e indipendente chiamata OpenTofu, oggi ospitata dalla Linux Foundation e mantenuta open source. Per la maggior parte di chi usa questi strumenti per gestire la propria infrastruttura la differenza pratica quotidiana è minima, ma è utile saperlo per orientarsi: Terraform resta lo strumento più diffuso, e non è più l'unico.

In sintesi

L'Infrastructure as Code sposta l'infrastruttura da una serie di clic difficili da ricordare a una descrizione in file di testo, leggibile e versionata. I vantaggi sono concreti: si ricrea tutto allo stesso modo, si rivede ogni modifica prima di applicarla, si riducono gli errori manuali e la descrizione diventa essa stessa la documentazione. Alla base ci sono due idee: dichiarare lo stato desiderato invece di dare comandi passo passo, e l'idempotenza, che rende sicuro riapplicare la stessa descrizione. Terraform è oggi lo strumento più diffuso per farlo, ma il valore vero non è lo strumento: è smettere di affidare l'infrastruttura alla memoria e iniziare a scriverla.

::cta{title="Vuoi smettere di configurare server a mano?" text="Scriviamo e gestiamo infrastruttura come codice con Terraform, su AWS, Google Cloud e altri provider, dalla prima configurazione alla migrazione di ambienti esistenti." button="Parliamone →"}

Fonti

L'AI dentro il browser: la Prompt API con Gemini Nano

Alessandro Corbelli — Tue, 20 May 2025 00:00:00 GMT

Quasi ogni funzione "intelligente" che usiamo online - un riassunto automatico, un suggerimento di scrittura, la risposta a una domanda - funziona nello stesso modo. Il testo parte dal dispositivo, viaggia fino a un server, viene elaborato da un modello di intelligenza artificiale e torna indietro. È comodo, ma ha tre prezzi: i dati escono dal dispositivo, c'è un'attesa per il viaggio di andata e ritorno, e ogni richiesta ha un costo per chi offre il servizio. La Prompt API di Chrome prova a cambiare questo schema. Porta il modello dentro il browser, sul computer di chi naviga, così l'elaborazione avviene in locale, senza chiamare il cloud.

Cos'è la Prompt API

Un'API (in inglese application programming interface) è un insieme di istruzioni concordate con cui un programma chiede un servizio a un altro. La Prompt API è quindi il modo con cui il codice di una pagina web o di un'estensione può inviare una richiesta a un modello AI già presente in Chrome.

In parole semplici: si scrive la richiesta come la si scriverebbe a un assistente ("riassumi questo testo", "estrai nome ed email da questo messaggio", "questa recensione è positiva o negativa?") e il modello risponde. La parola prompt indica proprio quella richiesta in linguaggio naturale.

Il modello che risponde si chiama Gemini Nano. È una versione compatta dei modelli Gemini di Google, pensata per girare su un dispositivo normale invece che in un centro dati. Un dettaglio importante: il modello non è incluso dentro il browser. Viene scaricato a parte la prima volta che un sito o un'estensione lo usa, poi resta sul dispositivo e le richieste successive non ripetono il download.

Cosa permette di fare

La Prompt API è generica: non è legata a un solo compito. Secondo la documentazione di Chrome, il modello può gestire ragionamento e generazione di testo, classificazione, estrazione e analisi di contenuti. In pratica coincide con i lavori che ricorrono di più su una pagina:

Riassumere un articolo lungo o un thread di messaggi in poche righe.
Classificare un testo, per esempio dividere le richieste in "urgente" e "non urgente" o capire il tono di un commento.
Estrarre informazioni strutturate da testo libero: una data e un luogo da un invito, un contatto da una firma email.
Riscrivere o generare brevi testi a partire da istruzioni.

Un aspetto meno ovvio: la Prompt API non accetta solo testo. La documentazione indica che può ricevere anche immagini e audio come input. Questo apre casi come descrivere il contenuto di un'immagine o trascrivere una nota vocale, sempre in locale.

Per i compiti più comuni esistono inoltre API dedicate, più semplici da usare perché già specializzate: tra queste ci sono il Summarizer (riassunti), il Translator (traduzione), il Language Detector (riconoscimento della lingua), oltre a Writer, Rewriter e Proofreader per scrivere, riscrivere e correggere. Fanno parte della stessa famiglia di funzioni AI integrate nel browser, un approccio simile, in fondo, al modo in cui le Agent Skills incapsulano procedure specifiche per gli assistenti AI.

::cta{variant="inline" title="I tuoi dati devono davvero uscire verso un servizio AI esterno?" text="Valutiamo se le funzioni AI del tuo sito o della tua applicazione possono girare in locale nel browser, senza inviare dati a terzi." button="Chiedi una valutazione →"}

Perché conta: privacy, latenza, costi

Il motivo per cui questa novità merita attenzione non è "c'è l'AI nel browser", ma dove avviene il calcolo.

Privacy. Se il modello gira sul dispositivo, il testo (o l'immagine) da elaborare non deve essere spedito a un server esterno. Per contenuti delicati - appunti personali, bozze non ancora pubbliche, messaggi privati - è una differenza sostanziale: il dato non lascia il computer, un aspetto che pesa anche sul fronte della conformità GDPR.

Latenza. Senza il viaggio verso il cloud e ritorno, la risposta può arrivare prima. E, una volta scaricato il modello, molte richieste possono funzionare anche offline, cosa impossibile quando ogni operazione dipende da un server remoto.

Costi. Ogni chiamata a un modello nel cloud ha un prezzo per chi sviluppa il servizio. Con l'elaborazione in locale quel costo per singola richiesta non c'è: il lavoro sfrutta il dispositivo di chi naviga. Per funzioni usate spesso, la differenza sul conto finale è concreta.

Nessuno di questi vantaggi cancella il cloud. I modelli grandi che girano nei data center restano più capaci. Il punto è avere una scelta: per i compiti semplici e frequenti, l'opzione locale spesso basta.

Lo stato: cosa è pronto e cosa no

Qui serve onestà, perché lo stato non è uniforme.

Per le estensioni di Chrome la Prompt API è arrivata alla versione stabile: gli sviluppatori di estensioni possono usarla in produzione. Il percorso è iniziato con un origin trial (una fase di prova pubblica riservata a chi si iscrive) partito con Chrome 131 ed è poi diventato disponibile in modo stabile.

Sulle pagine web normali, invece, la situazione è più acerba: l'accesso passa da origin trial o da un flag da attivare a mano. In sostanza, sul web aperto è ancora una tecnologia in evoluzione, non qualcosa su cui costruire senza un piano B.

Ci sono poi requisiti concreti che limitano la disponibilità. La documentazione parla di dispositivi desktop (Windows 10 o 11, macOS 13 e successivi, Linux; su ChromeOS solo i Chromebook Plus) e non di Chrome per Android o iOS. Servono spazio libero su disco (la documentazione indica circa 22 GB) e una scheda grafica con più di 4 GB di memoria dedicata, oppure abbastanza RAM e core della CPU. Tradotto: non ogni visitatore ha un dispositivo idoneo, e questo va messo in conto.

Un esempio minimo

Il codice qui sotto mostra lo schema di base: prima si verifica se il modello è disponibile, poi si crea una sessione e si invia la richiesta.

// 1. Verifica se il modello è utilizzabile su questo dispositivo
const stato = await LanguageModel.availability();

if (stato !== "unavailable") {
  // 2. Crea una sessione (può scaricare il modello al primo uso)
  const sessione = await LanguageModel.create();

  // 3. Invia una richiesta e attende la risposta completa
  const risposta = await sessione.prompt(
    "Riassumi in una frase: " + testo
  );

  // 4. Libera le risorse quando hai finito
  sessione.destroy();
}

Esiste anche promptStreaming(), che restituisce la risposta poco alla volta man mano che viene generata, utile per mostrare subito qualcosa all'utente su testi lunghi.

I limiti da tenere presenti

È un modello piccolo. Gemini Nano è meno capace dei grandi modelli nel cloud. Rende bene su compiti ben definiti (riassunto, classificazione, estrazione), meno su ragionamenti complessi o conoscenza molto specifica.
Può sbagliare. Come ogni modello di questo tipo, a volte produce risposte errate o inventate. L'output va trattato come una bozza, non come una verità da usare tale e quale per decisioni importanti.
La disponibilità varia. Serve sempre controllare con availability() prima di usare l'API e prevedere un'alternativa (per esempio un servizio nel cloud, o un flusso manuale) per chi non ha un dispositivo idoneo.
Sul web è ancora in movimento. L'interfaccia può cambiare durante la fase di prova. Sulle pagine web aperte conviene sperimentare, non ancora dipenderne per funzioni critiche.

In sintesi

La Prompt API permette al codice di una pagina o di un'estensione di parlare con Gemini Nano, un modello AI che gira dentro Chrome, sul dispositivo. Serve per riassumere, classificare, estrarre e generare testo - e anche per immagini e audio - senza mandare i dati al cloud. I vantaggi sono chiari: più privacy, meno attesa, nessun costo per singola richiesta. Lo stato, però, va letto con precisione: stabile per le estensioni, ancora sperimentale sulle pagine web, con requisiti di dispositivo che escludono una parte degli utenti. Non è la fine del cloud, ma un'opzione in più: portare l'AI dove sta il dato, invece di spedire il dato dove sta l'AI.

::cta{title="Vuoi integrare funzioni AI nel tuo sito con giudizio?" text="Sviluppiamo funzionalità AI su misura per applicazioni web, valutando caso per caso se convenga l'elaborazione locale nel browser o un servizio cloud, con attenzione a privacy e costi." button="Parliamone →"}

Fonti

Web Bot Auth: identificare i bot con firme crittografiche

Alessandro Corbelli — Thu, 22 May 2025 00:00:00 GMT

Chi gestisce un sito riceve ogni giorno molte visite che non arrivano da persone, ma da programmi automatici. Alcuni sono utili - il crawler di un motore di ricerca, un aggregatore di feed, un monitoraggio dell'uptime - altri no, come chi copia i contenuti o cerca falle. A questi si aggiungono ora gli agenti AI, cioè assistenti che navigano il web al posto dell'utente per rispondere a una domanda o svolgere un compito. Il problema è vecchio ma sempre più pressante: come si distingue un bot legittimo da uno che finge di esserlo?

A metà maggio 2025 Cloudflare, uno dei maggiori operatori di rete e CDN al mondo, ha presentato una proposta per rispondere a questa domanda: si chiama Web Bot Auth. L'idea di fondo è semplice. Invece di indovinare chi c'è dietro una richiesta guardando indizi facili da falsificare, si chiede al bot di firmare le proprie richieste con una firma crittografica verificabile.

Il problema: riconoscere i bot oggi è fragile

Un "bot" è semplicemente un programma che invia richieste web senza una persona che clicca in tempo reale. Oggi chi vuole capire se un bot è affidabile ha a disposizione strumenti poco solidi.

Lo User-Agent. È una riga di testo che ogni richiesta porta con sé per dichiarare "chi sono" (per esempio il nome del browser o del crawler). Il problema è che è testo libero: chiunque può scriverci quello che vuole. Fingersi il crawler di un motore di ricerca è banale.
Gli intervalli di indirizzi IP. L'indirizzo IP è il "numero di telefono" da cui parte una richiesta. Alcuni operatori pubblicano gli intervalli di IP usati dai loro bot, così i siti possono creare delle allowlist (elenchi di indirizzi ammessi). Ma è un meccanismo fragile: gli IP cambiano, sono spesso condivisi tra servizi diversi, e molti strumenti passano da proxy o VPN che ne nascondono l'origine. Mantenere questi elenchi aggiornati è un lavoro continuo e imperfetto.
I token segreti. Si potrebbe dare a ogni bot una password da presentare al sito. Non regge su larga scala: servirebbe una credenziale diversa per ogni sito da visitare, e un accordo preventivo con ognuno.

Il risultato è che oggi bloccare i bot cattivi senza colpire quelli buoni è un esercizio di approssimazione.

Cos'è Web Bot Auth

Web Bot Auth ribalta l'approccio: non si prova a indovinare l'identità del bot, gli si chiede di dimostrarla con la crittografia.

Serve un breve richiamo su cos'è una firma digitale. Chi firma possiede due chiavi legate tra loro: una privata, tenuta segreta, e una pubblica, condivisa con tutti. Con la chiave privata si "sigilla" un messaggio; con quella pubblica chiunque può verificare che il sigillo sia autentico e che il messaggio non sia stato alterato. La cosa importante è che solo chi possiede la chiave privata può produrre una firma valida: non si può contraffare guardando quella pubblica, lo stesso principio delle coppie di chiavi che regge l'autenticazione di WireGuard al posto delle password.

Web Bot Auth applica questo principio alle richieste HTTP. Un bot legittimo genera una coppia di chiavi, pubblica quella pubblica in un punto noto e firma ogni richiesta con quella privata. Il sito che riceve la richiesta recupera la chiave pubblica e verifica la firma. Se torna, sa con certezza da quale operatore arriva quella richiesta.

Alla base c'è uno standard già pubblicato dall'IETF (l'organismo che cura gli standard tecnici di Internet): la RFC 9421, HTTP Message Signatures, del febbraio 2024. Definisce in modo generale come firmare pezzi di un messaggio HTTP e come allegare la firma tramite due intestazioni, Signature-Input e Signature. Web Bot Auth non reinventa nulla: è un modo specifico di usare quello standard per il caso dei bot.

::cta{variant="inline" title="Sai davvero chi c'è dietro alle richieste che ricevi ogni giorno?" text="Analizziamo il traffico bot e AI sul tuo sito e verifichiamo cosa puoi già filtrare in modo affidabile." button="Analizza il tuo traffico →"}

Come funziona, in concreto

Prima di inviare una richiesta, il bot ne firma alcuni elementi con la propria chiave privata. In particolare firma l'autorità di destinazione, cioè il dominio del sito a cui sta scrivendo: così la firma vale solo per quel destinatario e non può essere riciclata altrove. La richiesta viaggia poi con tre intestazioni aggiuntive:

Signature-Input - descrive cosa è stato firmato e con quali parametri: una finestra di validità (i momenti di creazione e di scadenza), un identificativo della chiave usata e un'etichetta che segnala lo scopo, web-bot-auth.
Signature - contiene la firma vera e propria.
Signature-Agent - indica dove trovare le chiavi pubbliche del bot, in un formato standard, così il sito sa dove andare a verificare.

In forma semplificata, una richiesta firmata assomiglia a questa:

GET /articolo HTTP/1.1
Host: www.esempio.it
Signature-Agent: signer.esempio-bot.com
Signature-Input: sig=("@authority" "signature-agent");
  created=1700000000; expires=1700003600;
  keyid="ba3e64=="; tag="web-bot-auth"
Signature: sig=:abc...==:

La finestra di validità è importante: la firma scade in fretta, quindi anche se qualcuno la intercettasse non potrebbe riutilizzarla a lungo. E poiché è legata al dominio di destinazione, non funziona verso un sito diverso da quello previsto.

Per rendere la cosa adottabile, Cloudflare ha rilasciato esempi pratici già utilizzabili: un pacchetto npm (web-bot-auth) per generare le firme con chiavi Ed25519, un'estensione per il browser Chrome, un plugin per il web server Caddy che mostra la verifica lato server, e un server di prova pubblico per fare esperimenti.

Perché è più affidabile delle allowlist di IP

La differenza pratica è netta. Un elenco di IP dice al massimo "questa richiesta arriva da un indirizzo che di solito appartiene a un certo operatore" - un'informazione indiretta, che invecchia e che si può aggirare. Una firma crittografica dice invece "questa specifica richiesta, verso questo specifico dominio, in questa finestra di tempo, è stata prodotta da chi possiede quella chiave privata".

Non serve più inseguire indirizzi che cambiano, né fidarsi di uno User-Agent che chiunque può scrivere. La verifica non dipende dal percorso di rete: funziona anche se il bot passa da proxy o infrastrutture condivise. E l'identità non va concordata sito per sito: il bot pubblica la sua chiave una volta, e chiunque può verificarla.

Cosa cambia per chi gestisce un sito

Per chi amministra un sito, l'orizzonte è poter decidere in modo più fine chi far entrare. Invece di ragionare per liste di indirizzi, si può ragionare per identità verificate: dare accesso al crawler di un motore di ricerca o a un agente AI a cui si vuole concedere spazio, e trattare diversamente il resto. Cloudflare ha dichiarato l'intenzione di integrare questo meccanismo nei propri strumenti di gestione dei bot e di analisi del traffico AI, sulla stessa linea di altre aperture recenti come l'OAuth self-managed.

Va detto con chiarezza che questa firma dimostra chi ha mandato la richiesta, non cosa poi ne farà. Un bot firmato resta soggetto alle regole del sito: l'autenticazione è la premessa per applicare permessi sensati, non un lasciapassare automatico.

A che punto è

Qui serve prudenza, perché non è ancora tutto stabile. Alla presentazione, Web Bot Auth è partito come beta chiusa, cioè una fase di prova ad accesso limitato.

Le specifiche che lo descrivono sono Internet-Draft dell'IETF (per esempio la bozza sull'architettura e quella sul formato della directory delle chiavi): documenti di lavoro, ancora in evoluzione e non approvati come standard. Vale la pena ricordare che un Internet-Draft, di per sé, non ha valore ufficiale nel processo IETF finché non completa l'iter. Lo standard che sta sotto, la RFC 9421, è invece già pubblicato e stabile.

Cloudflare ha anche descritto un'alternativa più sperimentale basata su mTLS (l'autenticazione reciproca a livello di TLS, con certificati sia lato client che server), ma indica le firme dei messaggi HTTP come via principale, perché più semplice da adottare senza toccare lo strato TLS.

In sintesi: è una proposta concreta e già sperimentabile, non un prodotto finito. L'idea di identificare i bot con una prova crittografica invece che con indizi falsificabili è solida, e arriva nel momento giusto, con gli agenti AI che moltiplicano il traffico automatico. Ma il suo valore reale dipenderà da quanti operatori di bot inizieranno a firmare e da quanti siti impareranno a verificare. Per ora conviene seguirla, capirne il funzionamento e considerarla un complemento alle difese esistenti, non ancora un loro sostituto.

::cta{title="Vuoi gestire bot e agenti AI senza bloccare i visitatori giusti?" text="Configuriamo regole di accesso, allowlist e strumenti di bot management su misura per il tuo sito o la tua infrastruttura." button="Parliamone →"}

Fonti

Amazon Aurora DSQL: un database SQL distribuito e sempre disponibile

Alessandro Corbelli — Wed, 28 May 2025 00:00:00 GMT

Tenere un database sempre raggiungibile è uno dei problemi più difficili di chi manda avanti servizi online. Un database è il registro dove un'applicazione conserva i suoi dati: ordini, utenti, pagamenti, catalogo. Se si ferma, si ferma tutto. E se quegli stessi dati vanno letti e aggiornati da più parti del mondo nello stesso momento, tenerli coerenti diventa un rompicapo. Il 27 maggio 2025 AWS ha reso disponibile a tutti - in "disponibilità generale", cioè fuori dalla fase di anteprima riservata - Amazon Aurora DSQL, un database pensato proprio per questo scenario.

Cos'è Aurora DSQL

Aurora DSQL è un database relazionale: organizza i dati in tabelle con righe e colonne, che si interrogano con il linguaggio SQL, lo stesso usato da decenni per questo tipo di archivi. Ha però due caratteristiche che lo distinguono da un database installato su un server tradizionale.

È serverless. "Senza server" non significa che i server non esistano, ma che non è chi usa il servizio a doverli scegliere, dimensionare, avviare o aggiornare: se ne occupa AWS dietro le quinte. Chi sviluppa vede solo un indirizzo a cui connettersi e paga per quanto lavoro effettivamente fa il database.

È distribuito. I dati non stanno su una sola macchina, ma sono replicati in automatico su più zone di disponibilità (data center vicini ma indipendenti all'interno di una regione) e, se si vuole, su più regioni geografiche diverse.

Un terzo dettaglio conta per chi già lavora con questi strumenti: Aurora DSQL è compatibile con PostgreSQL, uno dei database open source più diffusi. Nella documentazione AWS indica la compatibilità con la versione 16 di PostgreSQL. In pratica ci si collega con i driver, le librerie e gli strumenti che si usano già con PostgreSQL, come il client psql.

Il problema che prova a risolvere

Chi gestisce un database tradizionale conosce a memoria una lista di grattacapi.

Il primo è la manutenzione. Applicare gli aggiornamenti di sicurezza (le cosiddette patch) o passare a una versione nuova spesso richiede una finestra in cui il database è rallentato o fermo. Va pianificata, comunicata, sorvegliata.

Il secondo è il failover, cioè cosa succede quando la macchina principale si guasta. In un'architettura classica esiste una copia pronta a subentrare, ma il passaggio va gestito e non è mai del tutto indolore: c'è un intervallo in cui il servizio arranca, un tempo di fermo che va tenuto sotto la soglia di quanto ci si può permettere di restare fermi, e nei casi peggiori si rischia di perdere gli ultimi dati scritti.

Il terzo è la crescita. Quando i dati o il traffico diventano troppi per una macchina sola, la via classica è lo sharding: spezzare i dati in tanti pezzi (frammenti) distribuiti su più macchine. Funziona, ma complica tutto. L'applicazione deve sapere su quale frammento sta ogni dato, e le operazioni che ne coinvolgono più di uno diventano lente e fragili.

Aurora DSQL nasce per togliere questi tre compiti dalle spalle di chi sviluppa: niente patching manuale, niente failover da orchestrare, niente sharding da progettare a mano.

::cta{variant="inline" title="La tua applicazione gestisce ancora failover e sharding a mano?" text="Analizziamo l'architettura dati esistente e valutiamo se un database gestito e distribuito riduce davvero il carico operativo." button="Chiedi una verifica →"}

Alta disponibilità e consistenza forte

Sono due promesse diverse, e vale la pena tenerle separate.

La disponibilità misura per quanto tempo il servizio resta raggiungibile. Di solito si esprime con una percentuale. AWS dichiara per Aurora DSQL una disponibilità del 99,99% in una singola regione e del 99,999% tra più regioni. Tradotto in tempo concreto: 99,99% significa lasciar fuori al massimo circa 52 minuti di disservizio in un anno; 99,999% scende a poco più di 5 minuti l'anno. Sono obiettivi dichiarati dal fornitore, non garanzie che nulla possa mai andare storto, ma danno la misura dell'ordine di grandezza.

Come ci arriva? Con un'architettura che AWS descrive come attiva-attiva. Invece di avere una copia principale che lavora e una di scorta che aspetta, più copie lavorano contemporaneamente e possono accettare sia letture sia scritture. Se un componente si guasta, il traffico viene dirottato in automatico verso quelli sani, senza il failover tradizionale da coordinare. Ogni componente è ridondato su tre zone di disponibilità.

Nella configurazione multi-regione, due cluster in due regioni diverse si presentano all'applicazione come un unico database logico: entrambi gli indirizzi accettano letture e scritture, un assetto che tocca da vicino anche la conformità GDPR quando i dati attraversano più aree geografiche. A fare da arbitro c'è una terza regione con un ruolo ridotto, definita log-only witness (testimone di solo registro), che non serve le richieste ma aiuta a decidere quale sia la versione corretta dei dati in caso di problemi.

La consistenza forte è la seconda promessa, ed è la più delicata. In un sistema distribuito, dopo una scrittura, le varie copie del dato possono impiegare un attimo ad allinearsi. Molti sistemi accettano questo ritardo: si parla di consistenza eventuale, cioè "prima o poi tutte le copie saranno uguali". Nel frattempo, però, due utenti potrebbero leggere valori diversi. La consistenza forte promette invece che ogni lettura veda sempre l'ultimo dato scritto, anche da un'altra regione. Per un carrello, un saldo o una prenotazione, questa differenza non è un dettaglio: è la differenza tra vendere due volte l'ultimo pezzo di magazzino oppure no. Aurora DSQL offre transazioni ACID (le proprietà che rendono affidabili le operazioni sui database) con consistenza forte anche tra regioni.

Serverless: scala senza sharding e senza patch

Il lato "serverless" si traduce in due comodità pratiche.

La prima è la scalabilità automatica. Aurora DSQL adatta da solo capacità di calcolo, lettura/scrittura e spazio di archiviazione in base al carico. Se il traffico raddoppia non c'è un server da ingrandire a mano né uno sharding da riprogettare: è il compito che di solito ruba più tempo e che qui, sulla carta, sparisce.

La seconda è l'assenza di manutenzione a carico dell'utente. Non ci sono server da aggiornare, quindi non ci sono finestre di patching o di upgrade da pianificare, e non c'è il fermo tecnico che di solito le accompagna.

Compatibile con PostgreSQL, ma con dei limiti

Qui serve onestà, perché "compatibile" non vuol dire "identico". Aurora DSQL parla il protocollo di PostgreSQL e ne supporta un'ampia parte delle funzionalità, ma non tutte: AWS mantiene una pagina di documentazione dedicata a cosa è supportato e cosa no. Prima di dare per scontato che un'applicazione PostgreSQL esistente giri senza modifiche, conviene controllare quell'elenco.

Ci sono poi vincoli sull'uso multi-regione. Al momento del lancio i cluster multi-regione si potevano creare solo tra regioni dello stesso raggruppamento geografico, e non erano supportate combinazioni tra continenti diversi. È un limite da mettere in conto se l'obiettivo è servire utenti sparsi su più continenti con un unico cluster.

Per quali casi ha senso

Aurora DSQL è ottimizzato per i carichi transazionali: tante operazioni piccole e frequenti - inserire un ordine, aggiornare un saldo, registrare un pagamento - dove contano affidabilità e coerenza. AWS lo indica come adatto ad architetture a microservizi, serverless ed event-driven, e cita ambiti come banche, e-commerce, viaggi, retail, piattaforme SaaS multi-tenant, pagamenti e gaming.

Vale anche il ragionamento opposto, per non usarlo dove non serve. Non è pensato come strumento di analisi su grandi moli di dati storici (i cosiddetti carichi analitici o OLAP), che seguono logiche diverse. E se un'applicazione ha bisogno di una funzione specifica di PostgreSQL non ancora supportata, o se un semplice database gestito su una sola regione copre già il fabbisogno, la complessità di un database distribuito può essere di troppo. La scelta giusta dipende dai requisiti concreti di disponibilità e di distribuzione geografica, non dalla novità in sé.

Il prezzo, in breve

Il modello di costo è a consumo. Si paga il lavoro svolto tramite delle unità chiamate DPU (Distributed Processing Units), che misurano letture e scritture, più lo spazio di archiviazione a GB-mese. AWS include una fascia gratuita mensile: le prime 100.000 DPU e 1 GB-mese di archiviazione ogni mese non si pagano. Per i conti veri conviene comunque partire dalla pagina prezzi ufficiale, perché il totale dipende molto da come si usa il database, proprio come succede quando si confrontano le offerte di più fornitori cloud.

::cta{title="Vuoi valutare un database distribuito per la tua applicazione?" text="Progettiamo e gestiamo infrastrutture cloud su AWS e Google Cloud, dalla scelta del database alla migrazione, con attenzione a costi e continuità del servizio." button="Parliamone →"}

Fonti

Cos'è una VPN e come funziona WireGuard

Alessandro Corbelli — Thu, 12 Jun 2025 00:00:00 GMT

Capita di sentire la parola VPN in contesti molto diversi. Chi lavora da casa la usa per collegarsi ai sistemi dell'ufficio, chi gestisce dei server la usa per farli parlare tra loro in modo protetto, e c'è chi la installa sul telefono per stare più tranquillo su una rete Wi-Fi pubblica. Dietro usi così diversi c'è sempre la stessa idea di base. E negli ultimi anni, tra i tanti modi di costruire una VPN, uno in particolare si è fatto notare per la sua semplicità: WireGuard. Vale la pena capire cos'è una VPN e perché WireGuard è diventato un riferimento.

Cos'è una VPN, in parole semplici

VPN è la sigla di Virtual Private Network, "rete privata virtuale". Detta senza tecnicismi, è un tunnel cifrato tra due punti che passa sopra una rete pubblica come Internet. La documentazione di Wikipedia la descrive come una rete che "estende una rete privata attraverso una rete pubblica" usando cifratura e protocolli di tunnel.

Un paragone aiuta. Internet è come una stanza affollata in cui tanti messaggi viaggiano da un capo all'altro, e in linea di principio chi sta nel mezzo può vederli passare. Una VPN è come far correre quei messaggi dentro un tubo sigillato: chi guarda dall'esterno vede che qualcosa transita, ma non riesce a leggerne il contenuto. Le due parole chiave sono proprio queste. Cifratura: i dati vengono trasformati in modo che solo i due capi del tunnel possano decifrarli. Tunnel: il traffico viene incapsulato, cioè avvolto in un involucro che lo trasporta da un punto all'altro come se i due estremi fossero sulla stessa rete locale, anche se in realtà sono lontani.

A cosa serve

Gli usi concreti di una VPN si possono raggruppare in tre famiglie, che Wikipedia elenca come casi tipici.

Accesso remoto. Permette a una persona fuori sede di raggiungere in modo sicuro la rete dell'ufficio attraverso Internet. È il caso del lavoro da casa: si accede a file, applicazioni interne e strumenti aziendali come se si fosse fisicamente in sede. È anche il modo giusto di amministrare gli apparati di rete da remoto, invece di lasciare aperta su Internet l'interfaccia di gestione: le falle SSH di MikroTik RouterOS hanno mostrato cosa succede altrimenti.
Collegamento tra reti (site-to-site). Unisce due reti distinte, per esempio quella di un ufficio e quella di un datacenter, oppure due server in luoghi diversi che devono scambiarsi dati senza esporsi su Internet. È lo scenario più comune quando si parla di infrastruttura.
Privacy sulla connessione. Molti servizi commerciali usano una VPN per cifrare il traffico di chi naviga e ridurre il rischio che venga intercettato, tipicamente su reti non fidate. Va detto con onestà che qui la fiducia si sposta sul fornitore della VPN, che vede comunque passare il traffico.

Il filo comune è sempre lo stesso: mettere in comunicazione due punti in modo sicuro, senza dover fidarsi della rete che c'è in mezzo.

::cta{variant="inline" title="I tuoi server si parlano ancora esposti direttamente su Internet?" text="Verifichiamo come sono collegate le tue macchine e se un tunnel VPN ridurrebbe la superficie esposta." button="Verifica la tua rete →"}

Cos'è WireGuard

Costruire una VPN richiede un protocollo, cioè un insieme di regole che stabiliscono come i due capi si riconoscono, come cifrano i dati e come li instradano. Per anni gli strumenti più diffusi sono stati OpenVPN e IPsec, entrambi solidi ma anche pesanti da configurare. WireGuard è un progetto più recente, creato da Jason A. Donenfeld, che si presenta con un obiettivo dichiarato: fare le stesse cose in modo molto più semplice.

La sua stessa pagina ufficiale lo descrive come "una VPN estremamente semplice, ma veloce e moderna, che utilizza crittografia allo stato dell'arte". Sotto il cofano, WireGuard incapsula i pacchetti IP dentro UDP, uno dei protocolli di trasporto di base di Internet. Dal punto di vista pratico, è diventato parte del kernel Linux con la versione 5.6, rilasciata il 29 marzo 2020, ed è disponibile anche su Windows, macOS, Android, iOS e i sistemi BSD. Un dettaglio che spiega bene la sua filosofia: la documentazione dichiara di voler essere "facile da configurare e mettere in opera quanto SSH".

Perché è diventato popolare

Il successo di WireGuard non è dovuto a una singola funzione appariscente, ma a tre scelte di fondo che, messe insieme, cambiano l'esperienza d'uso.

La semplicità. OpenVPN e IPsec sono progetti enormi, con basi di codice difficili da verificare a fondo persino per gruppi di esperti. WireGuard nasce con l'idea opposta: poche righe di codice, pensate per essere "revisionabili in modo esaustivo da singoli individui". Meno codice significa meno superficie in cui possono nascondersi errori e meno cose da configurare a mano.

Le prestazioni. Sui sistemi Linux WireGuard vive dentro il kernel, il cuore del sistema operativo, invece di girare come programma separato. Questo evita continui passaggi tra i due mondi e si traduce in maggiore velocità, minore latenza e meno lavoro per il processore. La pagina ufficiale lo definisce "notevolmente più performante di OpenVPN".

La crittografia moderna. WireGuard non lascia scegliere tra decine di algoritmi, come fanno i protocolli più vecchi. Ne usa un insieme fisso e aggiornato, basato sul Noise protocol framework e su primitive come Curve25519, ChaCha20, Poly1305 e BLAKE2. Il vantaggio è sottile ma importante: dove non c'è una negoziazione su quale algoritmo usare, non c'è nemmeno il rischio che un attaccante la forzi verso una scelta debole.

Il cuore di WireGuard: chiavi e cryptokey routing

Qui sta la differenza più interessante rispetto a tanti sistemi tradizionali. WireGuard non usa username e password, un approccio a coppie di chiavi che si ritrova anche nelle firme crittografiche di Web Bot Auth. Ogni nodo della rete ha una coppia di chiavi: una privata, che resta sulla macchina e non la lascia mai, e una pubblica, che viene condivisa con gli altri. Il meccanismo è lo stesso delle chiavi SSH: chi possiede la mia chiave pubblica può cifrare traffico verso di me e verificare che sia davvero io a rispondere, ma non può fingersi me.

Ogni interlocutore, nel gergo di WireGuard, si chiama peer, cioè "pari": non esiste una gerarchia rigida tra client e server, ci sono solo nodi che si parlano. Il collante che tiene insieme il tutto è quello che la documentazione ufficiale chiama cryptokey routing: ogni chiave pubblica viene associata a una lista di indirizzi IP ammessi dentro il tunnel. Questa lista fa due lavori in uno. In uscita si comporta come una tabella di instradamento: decide verso quale peer, e con quale chiave, va cifrato un pacchetto. In ingresso si comporta come una lista di controllo accessi: accetta un pacchetto solo se arriva dal peer giusto e da un indirizzo che gli compete.

[Peer]
PublicKey = <chiave-pubblica-dell-altro-nodo>
AllowedIPs = 10.0.0.2/32
Endpoint = altro-nodo.esempio.net:51820

In poche righe c'è tutto: chi è l'altro nodo (la sua chiave), quali indirizzi gli spettano e dove raggiungerlo. Da questo legame tra chiave e indirizzo nasce un'altra comodità, il roaming: siccome un peer è identificato dalla sua chiave e non dal suo indirizzo di rete, se cambia connessione - per esempio un portatile che passa dal Wi-Fi alla rete mobile - il tunnel non si rompe. WireGuard scopre il nuovo indirizzo semplicemente dal punto da cui arrivano i dati correttamente cifrati.

WireGuard rispetto a OpenVPN e IPsec

La pagina ufficiale non gira intorno alla questione: WireGuard punta a essere "più veloce, più semplice, più snello e più utile di IPsec". La stessa idea vale nel confronto con OpenVPN, con il vantaggio aggiuntivo di una base di codice molto più piccola e quindi più facile da controllare.

Questo non vuol dire che le soluzioni più vecchie siano da buttare. IPsec resta lo standard più diffuso per far dialogare apparati di rete di produttori diversi, e OpenVPN sa attraversare firewall ostili facendosi passare per normale traffico web. Sono strumenti maturi, con anni di esperienza alle spalle. Il punto di WireGuard è un altro: per il caso comune di collegare in modo sicuro dei sistemi che si controllano, offre lo stesso risultato con meno codice, meno configurazione e meno modi di sbagliare.

In sintesi

Una VPN è un tunnel cifrato tra due punti che passa sopra Internet, e serve a metterli in comunicazione in modo sicuro: accesso remoto, collegamento tra reti o protezione della connessione. WireGuard è un modo recente di realizzarla, diventato popolare perché mette insieme tre cose difficili da avere tutte insieme: semplicità, prestazioni e crittografia moderna. Al posto di password usa coppie di chiavi come SSH, e lega ogni chiave agli indirizzi ammessi nel tunnel. Non rende obsoleti IPsec e OpenVPN, ma per molti scenari è oggi la strada più diretta.

::cta{title="Vuoi collegare uffici, server e sedi remote in modo sicuro?" text="Progettiamo e gestiamo VPN WireGuard per accesso remoto e collegamenti site-to-site, dalla generazione delle chiavi alla configurazione dei peer." button="Parliamone →"}

Fonti

Cloudflare porta i container accanto ai Workers (beta pubblica)

Alessandro Corbelli — Wed, 25 Jun 2025 00:00:00 GMT

Chi sviluppa applicazioni web conosce due mondi che finora è stato scomodo tenere insieme. Da un lato le funzioni "serverless", programmi piccoli e leggeri che partono all'istante e reggono bene tanto traffico, ma con poca memoria e tempi di esecuzione stretti. Dall'altro le applicazioni "vere", quelle che hanno bisogno di un ambiente completo - un sistema operativo, librerie di sistema, un runtime specifico - e che di solito si impacchettano in un container. Il 24 giugno 2025 Cloudflare, uno dei maggiori operatori di rete e CDN al mondo, ha aperto la beta pubblica di un servizio che prova ad avvicinare questi due mondi: i Container, eseguibili accanto ai Workers e comandati dallo stesso codice.

Prima un ripasso: Worker e container

Vale la pena chiarire i due termini, perché è lì che sta la notizia.

Un Worker è un programmino che gira sui server di Cloudflare distribuiti nel mondo. È "serverless": non c'è un server da amministrare, il codice viene eseguito vicino a chi fa la richiesta, parte in una frazione di secondo e scala senza sforzo. In cambio è volutamente limitato: poca memoria, poco tempo di CPU, un ambiente ristretto pensato per JavaScript o WebAssembly. Perfetto per smistare richieste, applicare regole, comporre risposte; poco adatto a un lavoro pesante e prolungato.

Un container è invece un modo di impacchettare un'applicazione insieme a tutto ciò che le serve per funzionare: il suo runtime, le librerie, i file di sistema. Il vantaggio è che gira uguale ovunque, indipendentemente dalla macchina sottostante. È il formato con cui oggi si distribuisce gran parte del software, dai backend agli strumenti a riga di comando.

Il limite storico è che i Worker, da soli, non potevano ospitare un container: per quello serviva un'infrastruttura separata, con le sue complessità. La novità è proprio questa: ora le due cose stanno sulla stessa piattaforma.

Cosa ha annunciato Cloudflare

In sintesi: si possono ora eseguire container accanto ai Workers, sulla rete globale di Cloudflare, senza doversi occupare di orchestratori, cluster o regioni. Il servizio è disponibile in beta pubblica per chi ha un piano a pagamento.

L'idea di fondo la descrive bene la stessa Cloudflare: si usa un Worker quando serve essere leggeri e scalabili; si usa un container quando serve più potenza e libertà. I due non sono in concorrenza, lavorano insieme. Il Worker resta la porta d'ingresso - riceve la richiesta, decide cosa farne - e quando c'è da svolgere un compito impegnativo la passa a un container.

::cta{variant="inline" title="Hai un carico troppo pesante per il serverless ma non vuoi un intero cluster?" text="Valutiamo se Worker, container o una VM dedicata sono la soluzione più adatta al tuo caso, senza sovradimensionare l'infrastruttura." button="Valuta il tuo caso →"}

Come si incastrano Worker e container

La parte interessante è che il container non si gestisce da un pannello a parte: lo si comanda dal codice del Worker. Un container viene descritto nel file di configurazione del progetto (wrangler.jsonc) indicando l'immagine da usare, e da lì il Worker lo può avviare, raggiungere e spegnere.

Sotto il cofano l'architettura si appoggia ai Durable Object, un altro mattone di Cloudflare che serve a coordinare stato e istanze in modo ordinato. Il meccanismo è semplice da capire: a ogni identificativo diverso passato al container corrisponde un'istanza isolata e dedicata. Serve un container per ogni utente, o per ogni lavoro? Basta usare un identificativo diverso e la piattaforma ne crea uno separato. È Cloudflare a scegliere in quali punti della rete far partire le istanze, con avvii nell'ordine di pochi secondi.

Anche il flusso di lavoro è pensato per essere corto. In locale si sviluppa con wrangler dev, che costruisce l'immagine del container automaticamente; per pubblicare si usa wrangler deploy, senza dover gestire a mano un registro di immagini separato.

// wrangler.jsonc, in forma semplificata
{
  "containers": [
    {
      "class_name": "MioContainer",
      "image": "./Dockerfile",
      "instance_type": "basic"
    }
  ]
}

A cosa serve

Gli usi tipici sono quelli in cui un Worker da solo non basta e finora si sarebbe dovuto tirare su un server dedicato:

Strumenti a riga di comando e lavori "batch". Programmi già esistenti, magari scritti in un linguaggio qualsiasi, che elaborano qualcosa e restituiscono un risultato.
Elaborazione di media e dati. Convertire un video o un'immagine, trasformare file, eseguire pipeline che richiedono CPU, memoria e un disco vero: compiti che sforerebbero i limiti di un Worker, un po' come succede quando un'applicazione ha bisogno di una GPU per l'inferenza AI e non basta più una funzione leggera.
Backend in qualunque linguaggio. Un'applicazione già impacchettata come container può girare così com'è, con un Worker davanti che fa da instradatore.
Ambienti isolati per codice non fidato. Dare a ogni utente un container separato, ad esempio per eseguire codice generato o inviato da terzi senza che si influenzino a vicenda. È uno scenario citato anche per gli agenti AI e i server MCP a cui si collegano, che spesso hanno bisogno di uno spazio isolato in cui operare.

Perché abbassa la barriera

Il punto pratico è qui. Far girare container in tante parti del mondo, oggi, significa in genere occuparsi di parecchia infrastruttura, la stessa che di solito si descrive e si versiona con strumenti di Infrastructure as Code: scegliere le regioni, mettere in piedi un orchestratore (spesso Kubernetes), configurare il bilanciamento, gestire la scalabilità e gli aggiornamenti. È un lavoro che richiede competenze specifiche e tempo continuo di manutenzione.

L'approccio proposto sposta questo peso sulla piattaforma. Non si scelgono le regioni: è la rete a decidere dove eseguire. Non si configura un cluster: si dichiara un container e lo si comanda da codice. Per chi ha un carico che oggi non entra in una funzione serverless ma non giustifica la gestione di un intero cluster, è un modo per stare nel mezzo con meno attrito.

Va detto con onestà che "meno infrastruttura da gestire" significa anche meno controllo fine e un legame più stretto con una singola piattaforma, lo stesso compromesso da mettere sul piatto quando si sceglie un provider cloud. È un compromesso, non un pasto gratis: conviene valutarlo caso per caso.

Come si paga e quali limiti ci sono

Il modello di costo è a consumo e a grana fine: si paga solo mentre il container è effettivamente in esecuzione, misurato a intervalli molto brevi (nell'ordine dei 10 millisecondi), con CPU, memoria e disco conteggiati separatamente. Dopo un periodo di inattività il container va in pausa da solo, così non si paga per tempo morto. Il piano a pagamento include una quota mensile; i numeri esatti sono sulla pagina dei prezzi.

Alla partenza sono previste tre taglie di istanza - indicativamente da 256 MiB fino a qualche GiB di memoria, con quote di CPU e disco crescenti - e, trattandosi di una beta, ci sono tetti complessivi per account. Sono limiti pensati per la fase di prova e destinati a crescere: Cloudflare ha indicato tra i lavori futuri istanze più grandi, numeri più alti e uno scaling automatico con instradamento sensibile alla latenza, oltre a un'integrazione più stretta con gli altri servizi della piattaforma (archiviazione, database, chiavi-valore).

A che punto è

Serve la solita prudenza. Si tratta di una beta pubblica: aperta a chiunque abbia un piano a pagamento, ma pur sempre una fase di prova, con limiti stretti e funzionalità ancora in evoluzione. Alcune cose che ci si aspetta da una piattaforma matura - lo scaling automatico, le istanze più capienti, alcune integrazioni - sono dichiarate come in arrivo, non come già presenti.

L'idea di fondo, però, è concreta e già sperimentabile: portare i container dove già girano i Workers, e comandarli con lo stesso codice, invece di tenere due infrastrutture separate. Per chi oggi fatica a incastrare carichi pesanti in un ambiente serverless, vale la pena provarla su un progetto piccolo, tenendo conto che è ancora una beta e che il conto va guardato con attenzione mentre si sperimenta.

::cta{title="Vuoi portare in produzione un carico containerizzato senza gestire un cluster?" text="Progettiamo e gestiamo infrastrutture cloud su misura, dai Worker ai container fino ai server tradizionali, scegliendo lo strumento giusto per ogni componente." button="Parliamo del progetto →"}

Fonti

Gemini CLI: un assistente AI open source nel terminale

Alessandro Corbelli — Wed, 25 Jun 2025 00:00:00 GMT

Chi amministra server o scrive codice passa gran parte della giornata nel terminale: la finestra a testo dove si digitano comandi per far lavorare il computer. Molti assistenti basati sull'intelligenza artificiale, invece, vivono nel browser o dentro l'editor. C'è quindi un salto continuo tra il posto dove si fa il lavoro e il posto dove si chiede aiuto. Gemini CLI, annunciato da Google il 25 giugno 2025, prova a togliere quel salto: porta un assistente AI dentro il terminale, dove il lavoro succede davvero.

Cos'è Gemini CLI

Partiamo dai termini. CLI sta per command-line interface, cioè interfaccia a riga di comando: il modo di usare un programma scrivendo comandi testuali invece di cliccare su pulsanti. Un agente AI è un programma che, oltre a rispondere a domande, può compiere azioni concrete per conto di chi lo usa: leggere file, eseguire comandi, cercare informazioni.

Gemini CLI mette insieme le due cose. Si installa sul proprio computer, si avvia dal terminale e si dialoga con esso in linguaggio naturale, come si scriverebbe a un collega. Dietro le quinte usa Gemini, la famiglia di modelli AI di Google. Al momento del lancio l'assistente si appoggia a Gemini 2.5 Pro, un modello con una finestra di contesto da un milione di token, poi affiancato dalla generazione successiva descritta in Gemini 3.

Vale la pena spiegare quest'ultimo punto. Un token è un pezzetto di testo, più o meno una sillaba o una parola breve; la finestra di contesto è la quantità di testo che il modello riesce a tenere presente in una sola conversazione. Un milione di token è molto: significa poter passare al modello interi progetti, file di log lunghi o documentazione estesa senza doverli spezzare a mano.

Cosa sa fare

L'annuncio e la documentazione descrivono un assistente generico, non legato a un solo compito. Le cose principali che sa fare:

Leggere e capire il codice di un progetto, spiegarlo, proporre modifiche.
Eseguire comandi nel terminale e modificare file, sempre nella cartella su cui si sta lavorando.
Cercare sul web tramite Google Search per basare le risposte su informazioni aggiornate, invece che solo sulla conoscenza con cui il modello è stato addestrato.
Farsi guidare da istruzioni scritte: si può creare un file chiamato GEMINI.md con regole e contesto specifici del progetto, così l'assistente le tiene sempre presenti, un'idea vicina a quella degli Agent Skills.

Due caratteristiche meritano attenzione perché contano soprattutto per chi lavora con i server.

La prima è il supporto a MCP, sigla di Model Context Protocol. È uno standard aperto, nato per collegare gli assistenti AI a strumenti e sorgenti di dati esterni in modo uniforme. In pratica MCP fa da spina universale: permette di aggiungere a Gemini CLI la capacità di parlare con altri sistemi (un database, un servizio interno, un'API aziendale) senza reinventare ogni volta il collegamento.

La seconda è l'uso non interattivo. Oltre alla modalità a dialogo, l'assistente si può richiamare dentro uno script passandogli la richiesta direttamente. Questo lo rende un pezzo utilizzabile dentro l'automazione, non solo uno strumento da usare a mano.

# Avviarlo senza installare nulla in modo permanente
npx @google/gemini-cli

# Richiesta singola, senza interfaccia, adatta agli script
gemini -p "Spiega l'architettura di questo progetto"

# Output in formato JSON, più facile da elaborare in automatico
gemini -p "Elenca i servizi definiti" --output-format json

::cta{variant="inline" title="Vuoi capire se un agente da riga di comando ha senso nel tuo flusso di lavoro?" text="Valutiamo dove inserirlo, quali dati può vedere e con quali limiti d'uso." button="Chiedi una valutazione →"}

Open source, con una precisazione

Il codice di Gemini CLI è pubblicato su GitHub con licenza Apache 2.0. È una licenza open source permissiva molto diffusa: consente di usare, modificare e ridistribuire il programma, anche in contesti commerciali, con obblighi minimi. Concretamente vuol dire che chiunque può leggere il codice per capire cosa fa, segnalare problemi, proporre correzioni o adattarlo alle proprie esigenze. Per uno strumento che esegue comandi sul proprio computer, poter ispezionare il codice non è un dettaglio.

Serve però una precisazione onesta, perché la parola "open source" qui riguarda una parte sola. Ad essere aperto è il programma che si installa in locale, cioè l'agente. Il modello Gemini, invece, resta un servizio di Google che gira sui suoi data center: non è open source e non è scaricabile. Detto altrimenti, le richieste e il contesto (il testo, il codice, i file che si condividono) vengono inviati ai server di Google per essere elaborati. Il calcolo avviene nel cloud, non sul proprio computer.

Quanto costa e i limiti d'uso

Al lancio Google offre un accesso gratuito legato al proprio account Google personale. I limiti dichiarati sono 60 richieste al minuto e 1.000 richieste al giorno, senza costi. Nel pacchetto gratuito è inclusa anche una licenza base di Gemini Code Assist, il servizio di assistenza al codice della stessa famiglia.

Per chi ha bisogno di più - per esempio un'azienda o un uso intensivo - ci sono le alternative a pagamento: si possono usare le chiavi di Google AI Studio o di Vertex AI, con fatturazione a consumo, oppure le licenze Gemini Code Assist Standard ed Enterprise. La versione gratuita basta per provarlo e per un uso personale; oltre una certa soglia si passa a un piano a pagamento.

Perché interessa a sistemisti e sviluppatori

Il valore non sta nella novità in sé, ma in dove si colloca lo strumento. Chi gestisce sistemi ha già il terminale aperto: avere lì un assistente evita di cambiare contesto. Alcuni usi pratici che ricorrono nel lavoro quotidiano:

Farsi spiegare un messaggio di errore o un pezzo di file di log senza incollarlo altrove.
Ottenere una bozza di comando o di configurazione da rivedere, invece di scriverla da zero.
Capire in fretta un progetto ereditato da altri, chiedendo una descrizione della sua struttura.
Inserire una richiesta all'assistente dentro uno script, sfruttando la modalità non interattiva.

Il fatto di essere open source e basato su uno standard aperto come MCP riduce inoltre il rischio di restare legati a un solo fornitore per la parte client: il programma si può leggere, adattare e, in teoria, collegare ad altri strumenti.

I limiti e le cautele

Prima di adottarlo conviene tenere presenti alcuni punti, senza entusiasmi.

È in preview. Google lo descrive come versione in anteprima: può contenere errori, comportamenti che cambiano e funzioni ancora instabili. Non è il caso di costruirci sopra processi critici senza un'alternativa.

I dati escono dal computer. Poiché il modello gira nel cloud, ciò che si condivide con l'assistente viene inviato a Google. Per contenuti riservati - codice proprietario, credenziali, dati di clienti - è un aspetto da valutare con attenzione e da regolare secondo le proprie politiche, anche alla luce dei requisiti del GDPR lato infrastruttura.

Esegue comandi e modifica file. È la sua forza, ma anche il suo rischio. Un agente che può lanciare comandi va supervisionato: conviene rivedere ciò che propone prima di autorizzarlo, soprattutto su sistemi in produzione.

Può sbagliare. Come ogni modello di questo tipo, a volte produce risposte errate o inventate. L'output va trattato come una bozza da verificare, non come una verità da applicare così com'è.

In sintesi

Gemini CLI è un agente AI che vive nel terminale: legge codice, esegue comandi, cerca sul web e si può richiamare dentro gli script. Il programma è open source con licenza Apache 2.0, mentre il modello Gemini che lo alimenta resta un servizio nel cloud di Google. C'è un piano gratuito con limiti generosi e opzioni a pagamento per usi più intensi. È utile perché mette l'assistente dove sistemisti e sviluppatori già lavorano, ma va usato con giudizio: è in anteprima, invia i dati al cloud e può eseguire azioni sul sistema. Uno strumento in più, da tenere sotto controllo, non un pilota automatico.

::cta{title="Vuoi automatizzare compiti sistemistici con un agente AI, in sicurezza?" text="Integriamo strumenti come Gemini CLI nei flussi di lavoro dei server che gestiamo, definendo cosa può eseguire e quali dati non deve mai vedere." button="Parliamone →"}

Fonti

GPU serverless su Cloud Run: pagare l'inferenza solo quando serve

Alessandro Corbelli — Mon, 30 Jun 2025 00:00:00 GMT

A giugno 2025 Google ha portato alla disponibilità generale il supporto alle GPU su Cloud Run, il suo servizio "serverless". In pratica: si può servire un modello di intelligenza artificiale su una scheda grafica che si accende solo quando arriva una richiesta e si spegne quando non c'è nulla da fare, pagando solo i secondi effettivamente usati. Sembra un dettaglio tecnico, ma tocca una voce di spesa che oggi pesa parecchio. Vale la pena spiegare, senza tecnicismi inutili, cosa cambia e quando conviene davvero.

Due parole sui termini: "GPU", "inferenza", "serverless"

Una GPU è una scheda grafica: un tipo di processore nato per i videogiochi, capace di fare tantissimi calcoli in parallelo. Proprio per questo è diventata lo strumento standard per l'intelligenza artificiale, che è fatta in gran parte di calcoli ripetuti su grandi quantità di numeri.

Con inferenza si intende l'uso di un modello già addestrato: non lo si sta insegnando, gli si fa solo una domanda e si aspetta la risposta. Quando si scrive a un assistente e questo risponde, quello è un lavoro di inferenza. Serve una GPU perché avvenga in fretta.

Serverless è il modello di noleggio dietro tutto questo. Non significa "senza server": i server ci sono, ma non li si affitta a tempo fisso. Si consegna il proprio programma al fornitore, che lo avvia quando arriva una richiesta e lo spegne quando il traffico cala, addebitando solo il tempo di calcolo consumato. Cloud Run è il servizio serverless di Google: finora lavorava con i normali processori, ora sa usare anche le GPU, un'evoluzione non lontana da quella che ha portato i container accanto ai Worker di Cloudflare sul fronte dei carichi più pesanti.

Perché conta: il costo di una GPU sempre accesa

Il problema che questo annuncio affronta è concreto e riguarda chiunque voglia offrire una funzione basata sull'AI: una chat, un generatore di immagini, un sistema che analizza testi o foto, magari collegato a strumenti esterni tramite standard come MCP.

Nel modo tradizionale si affitta una macchina con GPU e la si tiene accesa. Il punto è che si paga anche mentre non arriva nessuna richiesta. Una scheda grafica da data center costa parecchio all'ora, e il traffico di quasi ogni servizio non è costante: ci sono i picchi e ci sono le ore morte, la notte, i giorni festivi. Tenere il "motore" acceso h24 per servire richieste concentrate in poche ore vuol dire pagare soprattutto il tempo in cui la GPU sta ferma ad aspettare.

L'alternativa era spegnere e riaccendere a mano, oppure gestire da soli un sistema che aggiunge e toglie macchine a seconda del carico: fattibile, ma è lavoro da mantenere. L'idea del serverless con GPU è togliere di mezzo tutto questo: se non ci sono richieste, non c'è nulla acceso e non si paga nulla.

::cta{variant="inline" title="Stai pagando una GPU accesa anche quando nessuno la usa?" text="Verifichiamo il traffico reale del tuo servizio AI e valutiamo se il serverless con GPU riduce davvero il conto nel tuo caso." button="Verifica il tuo caso →"}

Cosa ha annunciato Google

Il supporto GPU su Cloud Run è passato dalla fase di anteprima alla disponibilità generale, cioè è considerato pronto per l'uso in produzione ed è coperto dagli impegni di servizio del prodotto. I punti principali:

La GPU offerta è la NVIDIA L4, con 24 GB di memoria dedicata alla scheda. È un modello pensato proprio per l'inferenza, non per l'addestramento dei modelli più grandi.
Vale il principio del serverless: scale-to-zero, cioè quando non arrivano richieste il numero di istanze scende a zero e i costi della GPU si azzerano; e pagamento al secondo, si paga solo la GPU effettivamente consumata.
Non serve più fare una richiesta di quota: la GPU L4 è disponibile a tutti gli account, basta attivarla.
Google dichiara che un'istanza con GPU e driver già installati si avvia in circa 5 secondi. È il tempo per rendere la scheda pronta; a questo va poi aggiunto il caricamento del modello.

Per dare un'idea del tempo complessivo, Google riporta un esempio con un modello linguistico di piccole dimensioni in cui la prima risposta arriva in circa 19 secondi partendo da zero istanze: dentro quei secondi ci sono l'avvio, il caricamento del modello e la generazione. È un numero d'esempio del fornitore, legato a quel modello specifico, non una garanzia valida per ogni caso.

Come si usa, in breve

Chi ha già dimestichezza con Cloud Run trova la GPU come un'opzione in più. Attivarla via console è una casella da spuntare; da riga di comando è un parametro. Un esempio di distribuzione di un modello con lo strumento Ollama:

gcloud run deploy mio-servizio \
  --image ollama/ollama --port 11434 \
  --gpu 1 --cpu 4 --memory 16Gi

Per la GPU L4 è richiesto un minimo di 4 CPU e 16 GiB di memoria per istanza. Il servizio supporta lo streaming della risposta sia su HTTP sia su WebSocket: significa che il testo può arrivare all'utente man mano che viene generato, come nelle chat, invece di comparire tutto insieme alla fine.

Dove è disponibile e con quali condizioni

Al momento del lancio le GPU su Cloud Run sono attive in cinque regioni: Iowa (Stati Uniti), Belgio e Paesi Bassi (Europa), Singapore e Mumbai (Asia). La copertura è quindi ancora parziale, come è normale per una funzione appena arrivata alla disponibilità generale; Google indica altre regioni in arrivo.

Di base le istanze con GPU sono distribuite su più zone della stessa regione, per resistere al guasto di una singola zona. Si può rinunciare a questa ridondanza per spendere meno, accettando un ripristino "best effort", cioè non garantito, in caso di problema di zona.

Oltre ai servizi che rispondono a richieste in tempo reale, Google sta estendendo le GPU anche ai job di Cloud Run, cioè le elaborazioni a lotti che partono, fanno un lavoro e finiscono: ritocco di un modello su dati propri, inferenza su grandi quantità di immagini o testi, conversione di video. Al momento dell'annuncio questa parte è in anteprima privata, quindi non ancora aperta a tutti.

Cosa valutare prima di adottarlo

Il serverless con GPU risolve un problema preciso, ma non è la risposta a tutto. Alcuni punti da tenere presenti.

L'avvio a freddo ha un costo di tempo. Se il servizio è sceso a zero, la prima richiesta dopo una pausa deve aspettare l'accensione dell'istanza e il caricamento del modello. Per un uso interattivo qualche secondo di attesa iniziale può dare fastidio. Chi ha bisogno di risposte sempre immediate può tenere una istanza minima sempre attiva, ma così rinuncia in parte al risparmio dello scale-to-zero. È un compromesso da tarare sul proprio traffico.

La L4 è una scheda da inferenza. Ha 24 GB di memoria: va bene per modelli di dimensioni piccole e medie e per servire richieste. Non è pensata per addestrare da zero i modelli più grandi, che richiedono schede diverse e ben più memoria.

Il conto va fatto sul proprio caso. Il serverless conviene quando il traffico è discontinuo, con picchi e lunghe pause. Se invece la GPU è usata quasi in continuazione, una macchina affittata a tempo fisso può costare meno. La domanda giusta non è "quanto costa un secondo di GPU", ma "quante ore reali al giorno la userei davvero".

Attenzione al legame con il fornitore. Impacchettare il proprio servizio per Cloud Run è semplice, ma il modo in cui si scala, si fattura e si configura è specifico di Google. Spostare tutto altrove in futuro richiede lavoro. Non è un difetto, è un dato da mettere in conto, lo stesso genere di valutazione utile quando si confrontano i provider cloud in generale.

In sintesi, l'idea di fondo è ragionevole e affronta una spesa reale: pagare una GPU solo mentre lavora, invece di tenerla accesa a vuoto. Per servizi AI con traffico irregolare può ridurre il costo in modo sensibile e togliere la fatica di gestire l'accensione delle macchine. Per carichi costanti o modelli molto grandi, invece, restano più adatte le soluzioni tradizionali. Come sempre, la scelta giusta è quella misurata sul proprio caso, non sul numero d'esempio del comunicato.

::cta{title="Vuoi mettere in produzione un servizio AI senza sovrapagare l'infrastruttura?" text="Progettiamo e gestiamo backend AI su Google Cloud, dal deploy su Cloud Run al monitoraggio dei costi, misurando la scelta sul tuo traffico reale." button="Ottimizza i costi →"}

Fonti

Cos'è un bastion host e perché rende l'accesso SSH più sicuro

Alessandro Corbelli — Tue, 08 Jul 2025 00:00:00 GMT

Per amministrare un server a distanza si usa quasi sempre SSH (Secure Shell), un protocollo che permette di collegarsi a una macchina e impartire comandi da un altro computer, in modo cifrato. Finché i server sono uno o due, gestire questi accessi è semplice. Il problema nasce quando diventano dieci, cinquanta o cento. Aprire l'accesso SSH di ognuno verso Internet significa lasciare tante porte, e ogni porta è qualcosa da sorvegliare. Il bastion host è la risposta più diffusa a questo problema: invece di esporre tutti i server, se ne espone uno solo, controllato, e si passa da lì.

Cos'è un bastion host

Un bastion host (in italiano "host bastione", spesso chiamato anche jump host o jump box, cioè "host di salto") è una macchina che fa da unico punto d'ingresso verso una rete privata. Il glossario del NIST, l'ente statunitense che pubblica standard di sicurezza informatica, lo definisce come un computer con uno scopo specifico su una rete, progettato e configurato appositamente per resistere agli attacchi.

L'idea di fondo è semplice. Nessuno si collega direttamente ai server interni. Ci si collega prima al bastion e, da lì, si raggiunge la destinazione. I server interni, dal canto loro, accettano connessioni SSH soltanto dal bastion e da nessun altro. È la macchina in prima linea: l'unica raggiungibile dall'esterno e, proprio per questo, quella tenuta con più cura.

Il problema: esporre tutti i server

Per capire perché serve, aiuta il concetto di superficie d'attacco: l'insieme di tutti i punti da cui qualcuno potrebbe tentare di entrare. Ogni server con la porta SSH aperta verso Internet è uno di questi punti. E non è un rischio teorico: qualsiasi indirizzo pubblico riceve di continuo tentativi automatici di accesso, condotti da programmi che provano credenziali in sequenza sperando di indovinarne una.

Con un solo server è un problema gestibile. Con venti diventa ingovernabile, per tre motivi che si sommano:

Manutenzione. Ogni macchina esposta va aggiornata, sorvegliata e mantenuta allineata alle stesse regole. Tenere venti server perfettamente in pari è molto più difficile che tenerne uno.
Tracciabilità. Se l'accesso è possibile ovunque, la traccia di chi è entrato è sparsa su venti sistemi diversi. Rispondere alla domanda "chi si è collegato a quel server ieri sera?" diventa una piccola indagine.
Autenticazione. Alzare le difese, per esempio aggiungendo un secondo fattore di verifica, va fatto su ogni macchina. Venti volte lo stesso lavoro, con venti occasioni di sbagliare.

La superficie d'attacco, insomma, cresce con il numero di porte aperte. Ridurne il numero è già di per sé una difesa.

::cta{variant="inline" title="Quanti server della tua azienda hanno ancora la porta SSH aperta su internet?" text="Verifichiamo quali macchine sono esposte direttamente e valutiamo se un bastion host ridurrebbe davvero il rischio." button="Chiedi una verifica →"}

Un solo punto d'ingresso: come funziona

Un paragone utile è la reception di un edificio con molti uffici. I visitatori non entrano da qualsiasi porta: passano dalla reception, si identificano, firmano il registro. Solo dopo raggiungono l'ufficio giusto. Se qualcuno vuole controllare chi è entrato e quando, guarda un registro solo, non venti.

Il bastion host è quella reception. Concentra in un unico punto le operazioni che altrimenti andrebbero replicate ovunque: verificare l'identità di chi si collega, decidere chi può entrare e da dove, registrare ogni accesso. I server interni non hanno bisogno di occuparsene, perché si fidano del fatto che chiunque arrivi da loro è già passato dal controllo alla frontiera.

Perché riduce la superficie d'attacco

Il vantaggio principale è proprio questo: da tante porte esposte si passa a una sola. Invece di difendere venti macchine allo stesso livello, se ne difende bene una, e le altre restano irraggiungibili dall'esterno.

Su quella macchina, poi, conviene tenere il minimo indispensabile. Un bastion ben fatto non ospita siti, database o altri servizi: il suo unico compito è far passare le connessioni. Meno software gira su una macchina, meno sono i possibili punti deboli. Lo nota anche il NIST: i bastion host, dovendo stare in prima linea, sono di norma configurati con il minor numero possibile di servizi attivi, lo stesso principio che porta a disattivare per difetto le funzioni usate raramente, proprio per ridurre la superficie d'attacco.

Accessi tracciati e verificati in un punto solo

Concentrare l'ingresso porta due benefici che valgono da soli lo sforzo.

Il primo è la tracciabilità. Se ogni accesso passa da un unico host, i registri (i log) di chi entra, quando e con quale identità sono tutti in un posto, un requisito che si allinea bene ai principi di accountability richiesti anche dal GDPR. Spedendoli in tempo reale verso un sistema di raccolta separato, la traccia resta al sicuro anche se il bastion venisse compromesso. La domanda "chi si è collegato ieri sera?" diventa una ricerca nei log, non un'indagine.

Il secondo è l'autenticazione forte. Un metodo molto usato per rendere più sicuro un accesso è l'MFA (Multi-Factor Authentication, autenticazione a più fattori): oltre alla credenziale abituale, si richiede un secondo elemento, per esempio un codice temporaneo generato da un'app sul telefono. Anche se qualcuno rubasse la password, senza il secondo fattore non entrerebbe. Con un bastion, questa protezione si imposta una volta sola, nel punto d'ingresso, invece di configurarla su ogni server. Discorso a parte meritano gli accessi automatici, quelli di uno script o di una procedura di rilascio, che un secondo fattore non possono digitarlo: lì la strada è un'altra, e la trovi in come si conservano le credenziali di una pipeline.

ProxyJump: attraversare il bastion nel modo giusto

Per anni il "salto" attraverso il bastion si faceva a mano: ci si collegava al bastion e da lì si lanciava un secondo comando SSH verso il server interno. Funziona, ma è scomodo e non è la scelta migliore dal punto di vista della sicurezza, perché la connessione verso la destinazione finale nasce e vive sulla macchina più esposta.

Dalla versione 7.3, OpenSSH (l'implementazione di SSH più diffusa) offre un'opzione dedicata, ProxyJump, con il relativo flag -J. Le note di rilascio la descrivono in modo diretto: aggiunge l'opzione ProxyJump e il comando -J per semplificare l'accesso indiretto attraverso uno o più bastion, o "jump host". Dal lato di chi si collega, il salto diventa un dettaglio invisibile:

# Un solo comando: il passaggio dal bastion è automatico
ssh -J bastion.example.com server-interno.lan

Meglio ancora, si può salvare la configurazione nel file ~/.ssh/config del proprio computer e dimenticarsene:

Host server-interno
    HostName 10.0.5.20
    ProxyJump bastion.example.com

La differenza non è solo di comodità. Con ProxyJump il bastion si limita a inoltrare i dati verso la destinazione, mentre la connessione SSH resta cifrata da un capo all'altro tra il proprio computer e il server interno. In pratica il bastion fa passare dati che non è in grado di leggere. Da evitare, invece, la scorciatoia dell'agent forwarding, che renderebbe la propria chiave di accesso utilizzabile dal bastion stesso: la documentazione ufficiale invita a usarla con cautela, ed è per questo che di default è disattivata.

Dove si colloca in un'architettura

Il bastion funziona solo se la rete è organizzata di conseguenza. L'assetto tipico prevede la segmentazione: il bastion vive in una zona esposta e controllata (spesso chiamata DMZ o sottorete pubblica), mentre i server veri e propri stanno in una zona privata, non raggiungibile direttamente da Internet. Un firewall applica la regola che rende vero tutto il resto: verso quei server, le connessioni SSH sono accettate solo se provengono dal bastion.

Senza questa separazione, il bastion sarebbe una porta blindata accanto a una finestra aperta: chiunque potrebbe aggirarlo collegandosi direttamente. Con la segmentazione, invece, l'unica strada verso l'interno passa dalla frontiera controllata.

C'è un rovescio della medaglia da tenere presente: concentrando tutto in un punto, quel punto diventa critico. Se il bastion è mal configurato o smette di funzionare, si blocca l'accesso a tutto. Per questo va tenuto minimale, aggiornato e sorvegliato con attenzione particolare: vale anche per i router, come mostra il caso delle falle SSH di MikroTik RouterOS sfruttate su apparati con la gestione esposta. Il bastion non è l'unico modo di risolvere il problema - una VPN, per esempio, affronta la stessa esigenza da un'altra angolazione - ma resta uno dei più semplici e diffusi.

In sintesi

Un bastion host è un imbuto: costringe ogni accesso a passare da un punto solo, dove si concentrano le difese che sarebbe assurdo replicare ovunque. Riduce la superficie d'attacco perché al posto di tante porte esposte ne lascia una sola, ben protetta; rende gli accessi tracciabili perché li raccoglie in un unico registro; e permette di alzare l'autenticazione una volta per tutte invece che macchina per macchina. Attraversarlo con ProxyJump lo rende anche comodo e sicuro da usare. Non è una soluzione magica, e va inserito in una rete segmentata per funzionare davvero, ma è uno dei modi più solidi per mettere ordine in un accesso cresciuto senza controllo.

::cta{title="Vuoi mettere in sicurezza l'accesso SSH alla tua infrastruttura?" text="Progettiamo e gestiamo architetture di accesso con bastion host, segmentazione di rete e autenticazione a più fattori per i server Linux dei nostri clienti." button="Parliamone →"}

Fonti

Pay per crawl: far pagare i crawler AI con l'HTTP 402

Alessandro Corbelli — Tue, 08 Jul 2025 00:00:00 GMT

Chi pubblica contenuti online si trova da tempo davanti a una scelta secca quando arrivano i "crawler" delle intelligenze artificiali. Un crawler è un programma automatico che scarica pagine web: quelli delle aziende di IA lo fanno per addestrare i modelli o per raccogliere materiale con cui rispondere alle domande degli utenti. Fino a poco fa le opzioni per chi gestisce un sito erano solo due: lasciarli passare gratis, oppure sbarrargli la strada. A inizio luglio 2025 Cloudflare - una grande azienda di infrastruttura di rete, che fa da intermediario per una fetta enorme del traffico web - ha proposto una terza via: far pagare l'accesso. Il meccanismo si chiama "pay per crawl" e riporta in vita un codice HTTP quasi mai usato, il 402 "Payment Required" ("pagamento richiesto").

Il problema: o si blocca tutto, o si regala tutto

Per capire perché la cosa interessa chi produce contenuti, conviene partire dal contesto. Un sito che ospita articoli, foto o dati ha un costo per prodursi e per stare online. Quando un crawler di un'azienda di IA scarica quel materiale, di fatto lo preleva senza lasciare nulla in cambio: nessuna visita di un lettore, nessuna pubblicità vista, nessun abbonamento.

Lo strumento storico per gestire i crawler è il file robots.txt, un semplice elenco di regole con cui un sito dichiara "questo puoi scaricarlo, questo no". Ha però due limiti. Il primo è che è solo una richiesta di cortesia: non impedisce nulla a chi decide di ignorarla. Il secondo è che parla una lingua binaria: sì o no. Non esiste una casella "sì, ma pagando".

Il risultato è che chi pubblica si trova con un aut-aut poco comodo. Bloccare del tutto i crawler significa rinunciare a qualsiasi ritorno e, a volte, sparire dalle risposte generate dall'IA. Lasciarli liberi significa regalare il proprio lavoro. Cloudflare racconta di aver raccolto questa insoddisfazione parlando con testate giornalistiche, editori e grandi piattaforme: molti vorrebbero una terza opzione, cioè permettere l'accesso ma essere ricompensati.

Cos'è pay per crawl

Pay per crawl è esattamente quella terza opzione. Per ogni crawler, chi gestisce il sito può scegliere tra tre comportamenti:

Consenti - accesso libero e gratuito, come sempre.
Fai pagare - l'accesso è permesso, ma a un prezzo fissato.
Blocca - accesso negato, senza possibilità di pagare.

L'idea di fondo è semplice: trasformare l'accesso da parte dei crawler in una piccola transazione economica, senza dover trattare caso per caso con ogni azienda di IA. Il prezzo, al momento, è unico e vale per l'intero dominio: si stabilisce una cifra per ogni richiesta andata a buon fine e quella si applica a tutte le pagine.

::cta{variant="inline" title="Sai davvero quali crawler AI stanno scaricando i contenuti del tuo sito?" text="Verifichiamo la configurazione di robots.txt, WAF e regole Cloudflare per capire chi accede ai tuoi contenuti." button="Chiedi una verifica →"}

Come funziona: il ritorno dell'HTTP 402

Qui entra in gioco la parte tecnica, spiegata in modo semplice. Ogni volta che un browser o un programma chiede una pagina a un server, il server risponde con un "codice di stato": un numero che riassume com'è andata. Il 200 vuol dire "tutto bene, ecco il contenuto"; il 404 "non trovato"; il 403 "vietato". Tra questi ne esiste uno, il 402 "Payment Required", previsto fin dalle prime versioni dello standard HTTP ma di fatto tenuto in disparte per anni, in attesa di un uso concreto. Pay per crawl è proprio uno di questi usi.

Lo scambio, semplificando, funziona così. Un crawler chiede una pagina a pagamento senza offrire nulla: il server risponde con un 402 e aggiunge un'intestazione (una riga di metadati che accompagna la risposta) chiamata crawler-price, cioè il prezzo richiesto. A questo punto il crawler, se accetta, ripete la richiesta dichiarando quanto è disposto a pagare tramite l'intestazione crawler-exact-price. Se tutto è in ordine, il server risponde con un 200 e il contenuto, aggiungendo crawler-charged per confermare la cifra addebitata.

Esiste anche una via più diretta: il crawler può indicare fin dalla prima richiesta un tetto di spesa con l'intestazione crawler-max-price. Se il prezzo del sito rientra in quel tetto, il contenuto arriva subito, con l'addebito confermato. In pratica il 402 non è un errore da evitare, ma un modo per dire "questo si può avere, ma costa X": una specie di listino restituito al volo dal server.

Come si distingue un crawler che paga

Un meccanismo del genere regge solo se il server sa con certezza chi ha di fronte: altrimenti chiunque potrebbe spacciarsi per un crawler autorizzato. Per questo pay per crawl si appoggia a firme crittografiche. Ogni crawler aderente possiede una coppia di chiavi (una privata, segreta, e una pubblica, nota) e firma le proprie richieste con quella privata; il server verifica la firma con la chiave pubblica. È lo stesso principio che rende affidabili molte comunicazioni sicure in rete: la firma dimostra l'identità e garantisce che la richiesta non sia stata alterata lungo il percorso. Questo lega l'addebito a un mittente riconosciuto, non a un anonimo.

Chi incassa e chi paga: Cloudflare come intermediario

Restava un problema pratico: nessun editore vuole gestire micro-pagamenti verso decine di aziende di IA, e nessuna azienda di IA vuole aprire un conto con ogni singolo sito. Cloudflare si mette in mezzo con il ruolo di "merchant of record", cioè il soggetto che compare come venditore ufficiale nella transazione. In concreto raccoglie gli addebiti maturati, li fattura alle aziende dei crawler e gira il ricavato a chi pubblica. Per il sito significa non dover costruire da zero un sistema di pagamenti; per il crawler significa un solo interlocutore invece di mille.

Va detto con chiarezza: per usare pay per crawl bisogna essere clienti di Cloudflare e far transitare il proprio sito dalla sua rete. È una scelta di campo, non uno standard aperto a cui chiunque possa aderire da solo.

Cosa cambia per chi produce contenuti

Il valore della proposta non è il singolo pagamento, che preso da solo sarà spesso minuscolo, ma il fatto di dare finalmente un prezzo a qualcosa che prima si poteva solo regalare o negare. Per una testata o per chi gestisce un archivio ricco e aggiornato, poter dire "sei il benvenuto, ma questo lavoro ha un costo" è un cambio di prospettiva, anche solo come leva negoziale.

Conviene però mantenere le aspettative sobrie. Il meccanismo funziona solo se le aziende di IA decidono di partecipare e di pagare, invece di limitarsi a non scaricare il sito. Il prezzo unico per l'intero dominio è ancora poco flessibile. E l'intera impalcatura vive dentro l'infrastruttura di un singolo fornitore. Sono elementi che ne fanno un esperimento interessante più che una soluzione già matura.

È una beta, e guarda agli "agenti"

Su questo punto serve precisione: al momento dell'annuncio pay per crawl è in beta privata. Non è un servizio aperto a tutti né uno standard consolidato: per provarlo occorre iscriversi e passare da un accesso riservato. Le intestazioni, i prezzi e le regole descritte qui sono quelle della fase iniziale e possono cambiare man mano che la sperimentazione va avanti.

C'è però una direzione di fondo che spiega perché la notizia ha fatto discutere. Cloudflare la inquadra in uno scenario più ampio, quello degli "agenti" - programmi di IA che agiscono per conto di una persona. L'idea, dichiaratamente prospettica, è che un giorno si possa dare a un assistente un budget e lasciargli acquistare in autonomia i contenuti migliori per svolgere un compito. Che quel futuro arrivi o meno, il segnale concreto di oggi è più modesto ma non banale: prendere un pezzo dimenticato dello standard HTTP, il codice 402, e provare a usarlo per rimettere un prezzo sull'accesso automatico ai contenuti.

::cta{title="Vuoi gestire l'accesso dei crawler AI al tuo sito?" text="Configuriamo Cloudflare, regole di accesso e monitoraggio del traffico per i siti e gli e-commerce che gestiamo." button="Parliamone →"}

Fonti

Cos'è LVM e perché semplifica la gestione dei dischi su Linux

Alessandro Corbelli — Thu, 14 Aug 2025 00:00:00 GMT

Chi installa un server o un computer Linux, prima o poi, si trova davanti a una domanda solo in apparenza banale: come dividere lo spazio del disco. Con il metodo tradizionale quella decisione va presa quasi subito ed è scomoda da correggere dopo. Basta che una parte del disco si riempia mentre un'altra resta mezza vuota per capirne il limite. LVM nasce proprio per rendere quella scelta reversibile. Capire cos'è aiuta a ragionare sullo spazio disco senza trattarlo come una gabbia decisa una volta per tutte.

Prima di LVM: il problema delle partizioni fisse

Un disco, di solito, non si usa tutto intero: si divide in partizioni, cioè fette di spazio con un confine ben preciso. Una fetta per il sistema, una per i dati, una per l'area di scambio, e così via. Il problema è che quel confine, con le partizioni classiche, è scolpito nel disco: dice "questa fetta arriva fino a qui e non oltre". Finché le previsioni fatte all'inizio reggono, va tutto bene. Quando non reggono più, spostare un confine su un sistema in funzione è un'operazione delicata, spesso da fare a computer spento, con il rischio concreto di perdere dati.

Il risultato tipico è uno spreco che chiunque abbia gestito un disco conosce: una partizione piena al 100% che blocca un servizio, mentre accanto ce n'è un'altra usata a metà. Lo spazio libero c'è, ma è dalla parte sbagliata del muro.

Cos'è LVM in parole semplici

LVM sta per Logical Volume Manager, cioè "gestore di volumi logici". È un componente incluso di serie nelle distribuzioni Linux più diffuse, e la sua idea è semplice: mettere uno strato intermedio tra i dischi fisici e i filesystem (il modo in cui i dati vengono organizzati, scritti e letti). Invece di far parlare i dati direttamente con il disco, ci si rivolge a LVM, che tiene la contabilità dello spazio e decide come distribuirlo.

Questo strato in più è tutto il punto. Aggiungendo un livello di astrazione, i confini dello spazio smettono di essere fissi: diventano numeri gestiti via software, che si possono spostare mentre il sistema continua a lavorare. La documentazione di Oracle Linux lo riassume bene quando descrive LVM come una tecnologia "non disruptive and transparent to users", per cui operazioni come ingrandire un volume o riorganizzare i dischi "don't require any system down time" (non richiedono alcun fermo del sistema).

::cta{variant="inline" title="Rischi di ritrovarti con un disco pieno mentre un altro resta a metà?" text="Controlliamo lo storage dei tuoi server e valutiamo se passare a LVM senza fermare i servizi." button="Chiedi una valutazione →"}

I tre concetti base: volume fisico, gruppo, volume logico

LVM si regge su tre concetti impilati uno sopra l'altro. Chiarirli subito toglie gran parte della confusione. Un'analogia utile è quella di un magazzino.

Il volume fisico (in inglese physical volume, PV) è il livello più basso: un disco o una partizione che si dichiara "utilizzabile da LVM". È come portare in magazzino delle scatole di merce grezza. LVM ne suddivide lo spazio in tanti blocchetti tutti uguali, i cosiddetti extent (la documentazione Oracle indica una dimensione predefinita di 4 MB), che sono l'unità con cui poi conta ogni cosa.

Il gruppo di volumi (volume group, VG) è il magazzino vero e proprio: mette insieme uno o più volumi fisici in un unico grande serbatoio di spazio. Qui sta il cuore della flessibilità. Al serbatoio non importa se lo spazio arriva da un disco solo o da cinque dischi diversi: li vede come un'unica riserva.

Il volume logico (logical volume, LV) è ciò che si usa davvero: dal serbatoio si ritaglia un volume della dimensione voluta, ci si mette sopra un filesystem e lo si monta come una normale unità. Per il sistema è indistinguibile da una partizione, con la differenza sostanziale che i suoi confini non sono fissi. Restando all'analogia: le pareti tra le stanze del magazzino non sono muri di mattoni, ma pannelli mobili che si spostano quando serve, senza svuotare tutto.

Il percorso completo, dai dischi allo spazio pronto all'uso, è una sequenza di tre passi:

pvcreate /dev/sdb /dev/sdc      # marca due dischi come volumi fisici
vgcreate dati /dev/sdb /dev/sdc # li unisce in un gruppo chiamato "dati"
lvcreate -L 50G -n web dati     # ritaglia un volume logico da 50 GB

Da qui in poi si crea un filesystem sul volume e lo si monta, esattamente come si farebbe con una partizione.

Cosa cambia rispetto alle partizioni classiche

I vantaggi pratici di questo modello sono pochi e concreti.

Ridimensionare a caldo. Se un volume logico si riempie e nel gruppo c'è ancora spazio libero, lo si può allargare mentre il sistema è in funzione, senza smontare nulla e senza fermare i servizi. In molti casi, con una sola opzione, anche il filesystem sopra viene ingrandito nello stesso momento. Un dettaglio da conoscere: allargare un filesystem si può fare quasi sempre a caldo, ma rimpicciolirlo è più delicato e spesso richiede di smontarlo prima. Alcuni filesystem, come XFS, si possono solo far crescere e non ridurre.
Unire più dischi in un unico spazio. Poiché il gruppo somma la capacità di tutti i volumi fisici che contiene, un filesystem può estendersi su più dischi come se fossero uno solo. Quando lo spazio scarseggia, basta aggiungere un disco al gruppo per aumentarne la capacità, senza rifare la struttura esistente.
Snapshot. Uno snapshot è un'istantanea congelata di un volume in un preciso momento. La pagina di manuale di LVM lo descrive come una "frozen image of an origin LV" (immagine congelata di un volume di origine) utilizzabile, per esempio, per i backup mentre il volume originale continua a essere usato, secondo la stessa logica di ridondanza descritta nella regola del backup 3-2-1. È utile per copiare un database o un sistema senza fermarlo, evitando di salvare file che cambiano mentre la copia è ancora in corso, un'operazione che in produzione conviene pianificare con un timer schedulato invece che avviarla a mano. In LVM uno snapshot si può anche "riassorbire" nell'origine, riportando il volume allo stato di quando era stato creato: una rete di sicurezza comoda prima di un aggiornamento a rischio. Nel mondo della virtualizzazione gli snapshot sui volumi LVM condivisi sono stati a lungo un limite, superato solo di recente: è una delle novità di cui parliamo a proposito del passaggio da Proxmox VE 8 alla 9.
Spostare i dati tra dischi senza fermare nulla. Se un disco inizia a dare segni di cedimento, o se si passa da un disco meccanico a uno a stato solido, LVM permette di trasferire i dati da un volume fisico a un altro mentre i volumi restano montati e in uso. A trasferimento concluso, il vecchio disco si toglie dal gruppo ed è fisicamente estraibile.

Quando conviene usarlo (e quando no)

LVM non è gratis: aggiunge uno strato in più da capire e, all'occorrenza, da saper recuperare se qualcosa va storto. Su una chiavetta USB o su un disco monouso a dimensione fissa è complessità inutile, che non ripaga. Va anche ricordato che la piccola partizione di avvio del sistema (boot ed EFI) resta comunque una partizione classica: LVM non la sostituisce.

Sui server, però, la bilancia pende quasi sempre dall'altra parte. Ogni volta che si prevede di dover far crescere lo spazio nel tempo, spostare dati tra dischi o fare backup coerenti senza fermare i servizi, la flessibilità di LVM ripaga il piccolo costo iniziale, lo stesso ragionamento che porta a preferire un'infrastruttura descritta in file versionati invece che configurata a mano una volta per tutte. La regola pratica più diffusa è semplice: partizione classica solo dove è obbligatoria, tutto il resto sotto LVM. Meglio avere la flessibilità e non usarla che scoprirne il bisogno a disco pieno.

In sintesi

LVM è un livello di astrazione che si mette tra i dischi fisici e i dati. Trasforma i confini rigidi delle partizioni in numeri gestiti via software: i dischi diventano volumi fisici, si uniscono in un gruppo che fa da serbatoio, e da lì si ritagliano volumi logici con pareti mobili. Il guadagno concreto è poter ridimensionare a caldo, unire più dischi, congelare istantanee per i backup e spostare dati senza downtime. Non serve ovunque, ma dove lo spazio deve poter cambiare nel tempo, evita di trattare una decisione presa il primo giorno come se fosse definitiva.

::cta{title="Vuoi gestire lo storage dei tuoi server senza il rischio di restare senza spazio?" text="Gestiamo dischi e volumi Linux su server e cloud: migrazione a LVM, snapshot per i backup e ridimensionamento a caldo, senza downtime." button="Parliamone →"}

Fonti

Passkey portabili: uno standard per spostarle tra gestori diversi

Alessandro Corbelli — Tue, 19 Aug 2025 00:00:00 GMT

Chi ha iniziato a usare le passkey al posto delle password si è trovato presto davanti a una domanda pratica: se decido di cambiare gestore, le mie credenziali vengono con me? Fino a poco tempo fa la risposta era scomoda. Le passkey tendevano a restare intrappolate nel servizio dove erano nate, e non esisteva un modo sicuro e condiviso per spostarle altrove. La FIDO Alliance, l'organizzazione che cura gli standard alla base delle passkey, ha pubblicato le specifiche che affrontano proprio questo punto.

Perché conta

Il timore di restare legati a un fornitore ha un nome ricorrente: "lock-in". Se cambiare strumento significa perdere le proprie credenziali, oppure esportarle in modo insicuro, molti preferiscono non muoversi affatto. Oppure tengono la vecchia password come rete di sicurezza. E finché la password resta come riserva, gran parte dei benefici delle passkey resta sulla carta. Rendere il trasferimento delle credenziali un'operazione prevista e sicura non è un dettaglio tecnico: è uno dei nodi che decidono se le passkey diventano un metodo di accesso diffuso o restano una comodità per pochi.

Cos'è una passkey, in breve

Una passkey è un modo per accedere a un sito o a un'app senza digitare una password. Al posto di una parola segreta usa una coppia di chiavi crittografiche: due valori matematici legati tra loro. Uno, la chiave privata, resta sul dispositivo dell'utente e non viene mai condiviso. L'altro, la chiave pubblica, viene consegnato al sito in fase di registrazione. Al momento dell'accesso il dispositivo firma una piccola "sfida" inviata dal sito, ma solo dopo che l'utente si è sbloccato come al solito: impronta, riconoscimento del volto o PIN.

Il vantaggio è doppio. Non c'è più una password da rubare, perché il sito conserva solo la chiave pubblica, che da sola non fa entrare nessuno né si presta a un attacco a forza bruta. E i tentativi di phishing, cioè le pagine finte che imitano un servizio per farsi digitare le credenziali, smettono di funzionare, perché la passkey è legata all'indirizzo reale del sito. Le passkey vengono in genere salvate e sincronizzate da un "gestore di credenziali": può essere quello del sistema operativo, come Apple Passwords o Google Password Manager, oppure un'applicazione dedicata come 1Password o Bitwarden.

::cta{variant="inline" title="La tua applicazione supporta già le passkey per l'accesso?" text="Valutiamo l'autenticazione attuale e cosa serve per affiancare o sostituire le password." button="Chiedi una valutazione →"}

Il problema: nessun modo sicuro di spostarle

Fin qui la parte solida. Il punto debole era la portabilità. Ogni gestore custodiva le passkey dentro il proprio recinto, e passare da uno all'altro era complicato. Con le vecchie password esisteva almeno una via, ma pessima: esportarle in un file di testo, spesso in chiaro, cioè leggibile da chiunque aprisse quel file. Per le passkey non c'era nemmeno quello. Mancava del tutto uno standard, cioè un formato e una procedura condivisi che tutti i gestori potessero adottare.

Il risultato è proprio il lock-in di cui sopra. Senza una via d'uscita sicura, l'utente si sente in trappola, e la fiducia verso una tecnologia nuova ne risente.

Cosa ha pubblicato la FIDO Alliance

Per rispondere a questo problema la FIDO Alliance ha definito due specifiche complementari, riunite sotto il nome di Credential Exchange (scambio di credenziali).

Credential Exchange Format (CXF): è il formato. Stabilisce come devono essere descritti i dati da trasferire, con una struttura comune basata su JSON (un modo diffuso e leggibile di organizzare dati). Non riguarda solo le passkey: copre anche password, chiavi SSH, credenziali Wi-Fi e altri tipi di segreto. L'idea è che un dato esportato risulti uguale a prescindere dal gestore che lo ha prodotto.
Credential Exchange Protocol (CXP): è il protocollo, cioè il "come". Definisce il modo in cui il trasferimento avviene tra due gestori, in forma cifrata e sicura per impostazione predefinita, lo stesso principio della cifratura dei dati in transito richiesto ai sistemi che trattano dati personali. L'obiettivo dichiarato è che le credenziali non viaggino più in chiaro.

In sintesi: CXF dice cosa si trasferisce, CXP dice come lo si trasferisce.

Un punto importante da capire: queste specifiche non spostano le passkey al posto dell'utente. Sono un linguaggio comune. Servono perché due gestori diversi, di aziende diverse, possano parlarsi e passarsi le credenziali senza inventare ogni volta un metodo proprio.

A che punto sono le specifiche

Qui serve onestà sui tempi, perché le due specifiche non sono allo stesso stadio.

Le prime bozze di CXF e CXP sono state pubblicate il 14 ottobre 2024, aperte ai commenti della comunità e non ancora pronte per l'uso reale. Da lì il lavoro è proseguito. Il 14 agosto 2025 il formato CXF è stato pubblicato come Proposed Standard, cioè una prima versione stabile (la 1.0) che i gestori possono iniziare a implementare. È un passaggio diverso da una semplice bozza: segna un punto fermo su cui costruire.

Il protocollo CXP, invece, al momento in cui si scrive è ancora in fase di bozza. In pratica il formato con cui descrivere le credenziali c'è ed è consolidato; la procedura sicura di trasferimento diretto tra gestori è ancora in via di definizione. È una distinzione utile per non leggere l'annuncio come "da domani sposto tutto con un clic".

Vale la pena notare chi c'è dietro. Le specifiche nascono da un gruppo di lavoro della FIDO Alliance dedicato ai fornitori di credenziali, a cui hanno contribuito nomi molto diffusi: tra gli altri 1Password, Apple, Bitwarden, Dashlane, Enpass, Google, Microsoft, NordPass, Okta, Samsung e SK Telecom. È un dettaglio che conta: uno standard di portabilità ha senso solo se lo adottano proprio i gestori tra cui gli utenti vogliono spostarsi.

Cosa aspettarsi, con realismo

Uno standard pubblicato non è ancora una funzione pronta nel proprio gestore. Perché diventi qualcosa che si usa davvero, ogni fornitore deve implementarlo nei propri prodotti, e i tempi variano da uno all'altro. Detto questo, la direzione è chiara: rendere l'esportazione e l'importazione delle credenziali un'operazione sicura e prevista, invece di un percorso a ostacoli o di un file leggibile in chiaro.

Per l'utente comune il beneficio, quando arriverà a regime, è concreto: poter cambiare gestore di credenziali con la stessa libertà con cui oggi si cambia operatore telefonico mantenendo il numero. È proprio la mancanza di questa libertà che teneva molti fermi.

In sintesi

La FIDO Alliance ha definito uno standard per spostare le credenziali tra gestori diversi in modo sicuro: CXF per il formato dei dati e CXP per il protocollo di trasferimento. Il formato è arrivato a una prima versione stabile nell'agosto 2025; il protocollo è ancora in lavorazione. Non è una funzione già disponibile ovunque, ma è il tassello che mancava per togliere di mezzo il timore del lock-in, uno dei freni principali alla diffusione delle passkey.

::cta{title="Vuoi portare le passkey nella tua applicazione?" text="Progettiamo e integriamo l'autenticazione senza password nelle applicazioni Laravel e Vue che sviluppiamo, valutando sicurezza e compatibilità con i gestori più diffusi." button="Parliamone →"}

Fonti

Cos'è systemd e cosa sono i timer (l'alternativa moderna a cron)

Alessandro Corbelli — Wed, 10 Sep 2025 00:00:00 GMT

Un server Linux non è mai davvero fermo: dietro le quinte decine di programmi partono all'avvio, restano in ascolto e vengono riavviati se qualcosa va storto. Qualcuno deve coordinare tutto questo, decidere cosa avviare e in che ordine, e cosa fare quando un programma smette di funzionare. Su gran parte dei sistemi Linux moderni quel "qualcuno" si chiama systemd. Capire cos'è, e cosa sono i suoi timer, aiuta a ragionare su come una macchina Linux fa girare i propri servizi e pianifica le attività ricorrenti.

Cos'è systemd

La documentazione ufficiale lo definisce in modo asciutto: systemd è "un gestore di sistema e di servizi per sistemi operativi Linux". In pratica è il primo programma che parte all'accensione, tecnicamente il processo numero 1 (o PID 1), e da lì avvia e mantiene in vita tutti gli altri. È quello che in gergo si chiama init system: il capostipite da cui discende ogni altro processo del sistema.

Serve una parola su cosa si intende per "servizio". Un servizio (o daemon) è un programma che gira in sottofondo senza un'interfaccia con cui interagire direttamente: il web server che risponde alle pagine, il database, il sistema che invia le email. Non lo si "apre" come un'app: parte da solo e resta attivo. Il compito di systemd è avviare questi programmi nell'ordine giusto, tenerli d'occhio e, quando serve, riavviarli.

systemd è adottato dalla maggior parte delle distribuzioni Linux più diffuse, ed è per questo che conoscerlo anche solo a grandi linee è utile: è il punto di partenza per capire come una macchina Linux si comporta all'avvio e durante il funzionamento.

Le unit: i mattoncini di systemd

Tutto ciò che systemd gestisce è descritto da un'unit. Un'unit è semplicemente un file di testo che descrive un oggetto del sistema e come trattarlo. La documentazione ne elenca undici tipi diversi; per farsi un'idea bastano i più comuni:

le unit .service avviano e controllano i servizi (i daemon di cui sopra);
le unit .socket gestiscono le connessioni di rete o locali;
le unit .mount si occupano dei punti di montaggio dei dischi;
le unit .target raggruppano altre unit o segnano tappe note dell'avvio (per esempio "il sistema è pronto per la rete");
le unit .timer, tema di questo articolo, fanno scattare l'attivazione di altre unit in base al tempo.

Il vantaggio di questo schema è l'uniformità. Che si tratti di un disco, di un servizio o di un'attività pianificata, la logica è sempre la stessa: un file che descrive l'oggetto e un unico insieme di comandi per gestirlo.

::cta{variant="inline" title="I tuoi job pianificati su cron falliscono in silenzio, senza che nessuno se ne accorga?" text="Verifichiamo come sono pianificati i task ricorrenti sui tuoi server e se i fallimenti vengono davvero notificati." button="Chiedi una verifica →"}

Cosa sono i timer

Ecco il punto chiave, spiegato con calma. Un timer di systemd non esegue un comando: fa partire un'altra unit a un certo momento. Per convenzione un timer attiva il servizio con lo stesso nome (backup.timer fa partire backup.service), e il lavoro vero, cioè il comando da eseguire, sta in quel servizio. Il timer dice soltanto quando.

I timer si dividono in due famiglie.

I timer di calendario scattano a un orario dell'orologio, come "ogni giorno alle 3:30". Si configurano con l'opzione OnCalendar=, la cui sintassi ricalca l'idea dei campi di cron ma in forma più esplicita: giorno della settimana, anno-mese-giorno, ora:minuto:secondo. Un asterisco significa "qualsiasi valore".

OnCalendar=*-*-* 03:30:00    # ogni giorno alle 3:30
OnCalendar=Mon..Fri 09:00    # dal lunedì al venerdì alle 9:00

Esistono anche scorciatoie comode come hourly, daily, weekly, monthly: per esempio daily corrisponde a *-*-* 00:00:00.

I timer monotonici, invece, non guardano l'orologio ma il tempo trascorso da un evento: OnBootSec= misura da quando la macchina è accesa, OnUnitActiveSec= da quando l'unit collegata è stata avviata l'ultima volta. Servono per esprimere cose come "15 minuti dopo l'avvio, poi ogni ora".

Cos'è cron e perché si parla di alternativa

Per capire perché i timer piacciono, serve ricordare cosa fa cron. cron è il programma storico di Linux (e Unix) per pianificare attività ricorrenti: un daemon che, con le parole del suo manuale, "esegue questo comando a quest'ora in questa data". La pianificazione si scrive in un file, la crontab, con cinque campi che indicano minuto, ora, giorno del mese, mese e giorno della settimana.

cron fa una cosa sola, e la fa da decenni con affidabilità: esegue un comando a un orario. Il punto è tutto il resto, cioè dove finisce l'output, cosa succede se la macchina era spenta all'orario previsto, come sapere quando ripartirà. Sono aspetti che a cron non competono. I timer di systemd nascono proprio per coprire quel "resto".

I vantaggi dei timer

I log finiscono nel journal

systemd tiene un registro centralizzato degli eventi, il journal, gestito da un servizio chiamato journald. Per impostazione predefinita l'output di ogni servizio, sia quello normale sia i messaggi di errore, viene raccolto lì e ordinato per unit. Con cron, tradizionalmente, l'output di un'attività veniva spedito per email (tramite l'opzione MAILTO) o rischiava di perdersi. Con un timer basta un comando per rileggere l'intera storia di un'attività:

journalctl -u backup.service     # storico completo del job
systemctl list-timers            # tutti i timer e la prossima esecuzione

Recuperare le esecuzioni perse

Con cron, se la macchina era spenta all'orario previsto, quel giro salta e nessuno lo registra. I timer offrono l'opzione Persistent=true: systemd salva su disco quando l'attività è stata eseguita l'ultima volta e, alla riaccensione, se nel frattempo sarebbe dovuta partire almeno una volta, la avvia subito. È un comportamento pensato per recuperare le esecuzioni perse dopo un periodo di spegnimento, e vale per i timer di calendario.

Dipendenze e ordine

Un timer avvia un'unit, e un'unit vive nel grafo delle dipendenze di systemd. Si può quindi chiedere di eseguire un'attività "solo dopo che la rete è pronta" oppure "solo dopo che un disco è montato". cron, invece, scatta all'orario e basta, che le condizioni siano soddisfatte o no.

Verificabilità

C'è un ultimo vantaggio pratico: si può controllare tutto senza aspettare l'orario. systemctl list-timers mostra ogni timer con la sua prossima esecuzione, e il servizio collegato si può avviare a mano per provarlo, indipendentemente dalla pianificazione.

Quando cron va ancora bene

Non è una gara. Per un'attività semplice, senza bisogno di log strutturati, dipendenze o recupero, cron resta più breve da scrivere ed è disponibile anche su sistemi che non usano systemd. Ma quando conta sapere cosa è successo, cioè l'output, l'esito e la prossima esecuzione, oppure servono ordine e recupero dopo un'interruzione, i timer offrono molto di più a fronte di un file in più da scrivere.

In sintesi

systemd è il gestore di sistema e servizi che, su gran parte dei Linux moderni, avvia e sorveglia i programmi della macchina. Descrive ogni cosa come un'unit, e tra queste ci sono i timer: un modo per pianificare attività ricorrenti che, rispetto a cron, aggiunge log integrati nel journal, recupero delle esecuzioni perse e dipendenze. cron non è obsoleto, ma per chi ha bisogno di sapere davvero cosa fanno i propri job pianificati, i timer sono l'alternativa moderna.

::cta{title="Vuoi backup e task pianificati che si possono davvero monitorare?" text="Configuriamo systemd timer, log centralizzati e allarmi sui server Linux che gestiamo, backup compresi." button="Parliamone →"}

Fonti

GDPR lato infrastruttura: cosa significa in pratica

Alessandro Corbelli — Tue, 07 Oct 2025 00:00:00 GMT

Il GDPR viene spesso vissuto come una questione di moduli da firmare e informative da pubblicare. È una parte della storia, ma non tutta. Molte delle regole del regolamento si giocano sui server, nei database e nei backup: cioè sull'infrastruttura. Chi gestisce sistemi non deve dare pareri legali, ma è utile che capisca quali scelte tecniche il regolamento chiede di prendere. Questo articolo prova a spiegarlo in modo semplice.

Una precisazione doverosa prima di iniziare: questo non è un parere legale. È una spiegazione generale del lato tecnico. Per gli obblighi specifici del proprio caso servono un consulente o il proprio responsabile della protezione dei dati.

Di cosa parliamo

GDPR sta per General Data Protection Regulation, in italiano Regolamento generale sulla protezione dei dati. È il Regolamento (UE) 2016/679, approvato il 27 aprile 2016 e applicabile dal 25 maggio 2018. Riguarda il trattamento dei dati personali, cioè qualsiasi informazione che si riferisce a una persona identificata o identificabile: un nome, un'email, un indirizzo IP, i dati di un ordine.

Il punto di partenza è semplice. Se un sistema conserva o muove dati di persone, il modo in cui lo fa non è indifferente. Il regolamento chiede che sia fatto con criterio e, in caso di problemi, chiede di poterlo dimostrare.

I principi che riguardano chi gestisce i sistemi

L'articolo 5 elenca i principi di fondo del trattamento. Tre di questi toccano da vicino l'infrastruttura.

Minimizzazione dei dati. I dati raccolti devono essere «adeguati, pertinenti e limitati a quanto necessario» rispetto allo scopo. Tradotto: non si raccoglie tutto per ogni evenienza, ma solo ciò che serve davvero.
Limitazione della conservazione. I dati vanno tenuti «per un arco di tempo non superiore» a quello necessario. Cioè: hanno una scadenza, non si accumulano all'infinito.
Integrità e riservatezza. I dati vanno trattati in modo da garantire un'adeguata sicurezza, compresa la protezione da accessi non autorizzati e da perdite o distruzioni accidentali.

C'è poi un quarto principio che fa da cornice, la responsabilizzazione (in inglese accountability): chi tratta i dati deve non solo rispettare le regole, ma essere «in grado di comprovarlo». È il motivo per cui tante scelte tecniche vanno documentate.

::cta{variant="inline" title="La tua infrastruttura rispetta questi principi tecnici del GDPR?" text="Verifichiamo cifratura, log, backup e controllo degli accessi sui sistemi che gestisci." button="Chiedi un audit →"}

Cifratura: dati a riposo e in transito

L'articolo 32 riguarda la sicurezza del trattamento. Tra le misure che cita per nome ci sono «la pseudonimizzazione e la cifratura dei dati personali».

Cifrare vuol dire trasformare i dati in modo che siano leggibili solo con la chiave giusta. Nella pratica si distinguono due momenti.

In transito, cioè mentre i dati viaggiano in rete. È il caso di un sito che usa HTTPS invece di HTTP, o di un collegamento tra due server dentro un tunnel cifrato. Chi intercetta il traffico vede passare qualcosa, ma non riesce a leggerlo.
A riposo, cioè mentre i dati stanno fermi su un disco. Se il supporto viene rubato o una copia finisce nelle mani sbagliate, senza la chiave resta illeggibile, un principio che vale anche sullo storage cloud, dove per esempio S3 ha cambiato le impostazioni predefinite di cifratura.

Lo stesso articolo considera i rischi legati alla distruzione, perdita, modifica, divulgazione o accesso non autorizzato a dati «trasmessi, conservati o comunque trattati». Da qui la distinzione pratica tra dati in movimento e dati fermi.

Log: utili, ma non per sempre

I log - i registri di ciò che accade su un sistema - sono preziosi per capire i problemi e ricostruire un incidente. Ma spesso contengono dati personali: un indirizzo IP, un nome utente, l'orario di un accesso.

Questo significa che anche ai log si applicano gli stessi principi. Minimizzazione: registrare ciò che serve, non tutto per abitudine. Limitazione della conservazione: definire per quanto tempo tenerli e poi cancellarli o anonimizzarli. Tenere i log all'infinito «per sicurezza» va nella direzione opposta a quella che il regolamento indica.

Controllo e tracciamento degli accessi

Un'idea ricorrente è che a un dato debba poter accedere solo chi ne ha davvero bisogno, e per il tempo in cui ne ha bisogno. Sul piano tecnico questo si traduce in cose concrete: account personali invece di credenziali condivise, permessi assegnati per ruolo, revoca degli accessi quando una persona cambia mansione o lascia l'organizzazione, magari partendo da un unico punto di ingresso sorvegliato come un bastion host.

Accanto al controllo c'è il tracciamento: sapere chi ha fatto cosa e quando. Serve sia a scoraggiare gli abusi sia, in caso di incidente, a capire cosa è successo. È anche uno degli strumenti con cui si dimostra di aver agito con criterio.

Backup sicuri

L'articolo 32 cita anche la capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati dopo un incidente fisico o tecnico. In altre parole: i backup non sono solo una buona pratica, sono parte della sicurezza richiesta.

Ma un backup è a tutti gli effetti una copia dei dati, e va protetto come l'originale, idealmente seguendo una strategia strutturata come la regola del 3-2-1. Se i dati in produzione sono cifrati e le copie no, la protezione ha un buco. Per questo un backup andrebbe cifrato, conservato in un luogo sicuro e testato: una copia che non si riesce a ripristinare non protegge nessuno. Lo stesso criterio, con copie anche offline, ritorna nei requisiti NIS2 che le aziende obbligate chiedono ai propri fornitori: ne parliamo in NIS2 e fornitori.

Dove risiedono i dati

Un'altra domanda che il regolamento rende rilevante è semplice: dove si trovano fisicamente i dati? Il GDPR pone condizioni specifiche per il trasferimento di dati personali fuori dall'Unione europea. Non è un divieto, ma richiede garanzie.

Per chi gestisce infrastruttura questo si traduce in scelte concrete su come scegliere il fornitore cloud e sulla regione in cui girano i server e vengono conservati i backup. Sapere in quale Paese risiedono i dati non è un dettaglio burocratico: è un'informazione tecnica che conviene conoscere.

Un approccio, non una lista di regole

Verrebbe voglia di avere una checklist fissa di «misure minime». Il regolamento non funziona così. Come ricorda anche il Garante per la protezione dei dati personali, l'elenco dell'articolo 32 è aperto e non esaustivo, e dopo il 25 maggio 2018 non esistono obblighi generalizzati di misure minime: la scelta è rimessa caso per caso al titolare, in rapporto ai rischi concreti. Un punto fermo però c'è: difendere come adeguato un software abbandonato dal produttore è quasi impossibile.

Questo è il concetto di protezione «fin dalla progettazione», previsto dall'articolo 25: la tutela dei dati va pensata all'inizio, quando si progetta un sistema, non aggiunta alla fine. E va proporzionata al rischio: i dati di un forum di quartiere e quelli sanitari di una clinica non richiedono le stesse cautele.

Un ultimo punto pratico. Se avviene una violazione dei dati che comporta un rischio per le persone, il titolare deve notificarla all'autorità di controllo «senza ingiustificato ritardo e, ove possibile, entro 72 ore». Avere in anticipo log, backup e un minimo di procedura rende questa scadenza gestibile invece che un'emergenza.

In sintesi

Sul piano infrastrutturale il GDPR chiede cose ragionevoli: cifrare i dati fermi e in movimento, raccogliere e conservare solo il necessario, controllare e tracciare gli accessi, proteggere i backup, sapere dove risiedono i dati. Non è una lista da spuntare una volta sola, ma un modo di progettare i sistemi proporzionato al rischio e capace di rendere conto delle proprie scelte. Il lato legale resta un altro mestiere: per gli obblighi del proprio caso serve un consulente.

::cta{title="Vuoi adeguare l'infrastruttura ai requisiti tecnici del GDPR?" text="Interveniamo su cifratura dei dati, gestione dei log, backup e controllo degli accessi dei server che amministriamo, in coordinamento con il tuo responsabile della protezione dei dati." button="Parliamone →"}

Fonti

Oltre metà del traffico web è ormai post-quantum: cosa significa

Alessandro Corbelli — Tue, 14 Oct 2025 00:00:00 GMT

A fine ottobre 2025 Cloudflare, una delle grandi reti che smistano una fetta importante del traffico di Internet, ha annunciato un traguardo: oltre la metà del traffico web avviato da persone che passa dai suoi server è ormai protetto con crittografia post-quantum. È un termine che sa di laboratorio, ma la questione riguarda chiunque usi un sito, faccia acquisti online o mandi un messaggio. Vale la pena capire cosa vuol dire, contro quale minaccia protegge e cosa resta ancora da fare.

La notizia in breve

L'annuncio segna un punto di svolta silenzioso. Fino a pochi anni fa la crittografia post-quantum era confinata agli esperimenti; oggi è attiva per impostazione predefinita in buona parte dei browser più diffusi. Chrome l'ha abilitata sui computer da marzo 2024 e su Android da novembre 2024; nel corso del 2025 si sono aggiunti Firefox e i sistemi di Apple, su iPhone, iPad e Mac. Il risultato è che, senza che l'utente debba fare nulla, più di una connessione su due parte già protetta contro un attacco che oggi non è ancora possibile, ma che potrebbe diventarlo.

Il problema: "raccogli ora, decifra dopo"

Per capire perché tutto questo conta bisogna partire da una minaccia dal nome poco rassicurante: harvest now, decrypt later, cioè "raccogli ora, decifra dopo". L'idea è semplice e sgradevole. Oggi il traffico su Internet è cifrato: quando nel browser compare il lucchetto, i dati che viaggiano tra il dispositivo e il sito sono resi illeggibili a chi li intercetta. Questa protezione regge perché i computer attuali non hanno la potenza di calcolo per forzarla in tempi ragionevoli.

Il punto è che i computer quantistici - una tecnologia ancora in sviluppo, basata su principi diversi da quelli dei computer tradizionali - potrebbero un giorno rompere buona parte della crittografia che usiamo adesso. Quel momento ipotetico viene chiamato "Q-day". Nessuno sa con certezza se e quando arriverà: le stime degli esperti vanno da poco più di dieci anni a diversi decenni. C'è però un dettaglio che rende il problema attuale e non futuro: chi intercetta traffico cifrato oggi può conservarlo e archiviarlo, in attesa di poterlo decifrare quando la tecnologia lo permetterà. Dati che restano sensibili per anni - cartelle cliniche, segreti industriali, comunicazioni riservate - sono quindi a rischio già ora, anche se il computer capace di aprirli non esiste ancora.

::cta{variant="inline" title="Sai se i tuoi server supportano già lo scambio di chiavi post-quantum?" text="Verifichiamo la configurazione TLS dei tuoi server e la compatibilità con gli algoritmi post-quantum." button="Chiedi una verifica →"}

La risposta: crittografia post-quantum

La contromisura si chiama crittografia post-quantum: nuovi algoritmi progettati per resistere anche a un computer quantistico. Non richiedono hardware speciale, sono normale software e possono girare sui dispositivi di tutti i giorni. La parte arrivata per prima riguarda lo scambio di chiavi (in inglese key exchange o key agreement): il momento iniziale di una connessione sicura in cui il browser e il sito si mettono d'accordo su una chiave segreta condivisa, che poi serve a cifrare tutto il resto della conversazione. È proprio questo passaggio a essere esposto all'attacco "raccogli ora, decifra dopo", ed è quindi il primo da mettere in sicurezza.

Lo scambio di chiavi ibrido

Nella pratica non si è buttata via la crittografia di prima per sostituirla con quella nuova. Si usa un approccio ibrido: si combinano un algoritmo classico, collaudato da anni, e uno post-quantum. La connessione resta protetta se almeno uno dei due regge. Così, se in futuro si scoprisse una debolezza nel nuovo algoritmo - cosa non impossibile, visto che è recente - resterebbe comunque la protezione di quello tradizionale; e all'inverso, contro un attacco quantistico, protegge la parte nuova. In pratica, cintura e bretelle insieme.

Lo schema più diffuso in questo momento si chiama X25519MLKEM768. Il nome è ostico, ma dice esattamente cosa contiene: X25519 è l'algoritmo classico usato da anni per lo scambio di chiavi, ML-KEM-768 è la parte post-quantum. ML-KEM (sigla di Module-Lattice-Based Key-Encapsulation Mechanism, in precedenza noto come Kyber) è stato standardizzato ufficialmente dall'ente statunitense NIST il 13 agosto 2024, con il nome di FIPS 203. Non è quindi la sperimentazione di un singolo fornitore, ma uno standard pubblico su cui l'industria si sta allineando. Il tutto viaggia dentro TLS 1.3, il protocollo che sta dietro all'https e al lucchetto del browser.

Perché "oltre il 50%" è una tappa concreta

Che una fetta così ampia del traffico usi già questi algoritmi non è un dettaglio da addetti ai lavori. Superare la metà significa che la protezione non è più un'eccezione, ma sta diventando la norma, in modo trasparente per chi naviga. Il merito è soprattutto dei browser, che l'hanno attivata di default: l'utente non ha dovuto installare o configurare niente. Sul lato dei siti la diffusione è più indietro - scansioni di settembre 2025 indicavano circa il 39% dei server web pubblici pronti a usarla - ma la direzione è chiara. Va anche ricordato che il dato di Cloudflare riguarda il traffico "avviato da persone", cioè le connessioni di browser reali, tenute distinte da quelle automatiche dei bot.

Cosa manca ancora: firme e certificati

Il quadro, però, è a metà. La crittografia serve a due cose diverse, ed entrambe vanno rese post-quantum. La prima è tenere segreti i dati: è lo scambio di chiavi di cui si è parlato, ed è la parte già in produzione. La seconda è l'autenticazione: assicurarsi di parlare davvero con il sito giusto e non con un impostore. Questo si basa sui certificati e sulle firme digitali, ed è la parte ancora indietro.

Il motivo è tecnico ma comprensibile: le firme post-quantum occupano molto più spazio di quelle attuali, e questo crea problemi di prestazioni e di compatibilità con sistemi pensati per dimensioni più piccole. Al momento della notizia, a ottobre 2025, gli standard per i certificati post-quantum non erano ancora definitivi; il lavoro sui certificati "ibridi" era in corso, con la speranza di chiuderlo all'inizio del 2026. Difficilmente si vedranno certificati simili in uso diffuso prima del 2027. Restano intanto pronti altri standard NIST per le firme - ML-DSA (FIPS 204) e SLH-DSA (FIPS 205), pubblicati anch'essi nel 2024 - e un algoritmo di riserva per lo scambio di chiavi, HQC, scelto a marzo 2025 come alternativa basata su principi matematici diversi.

In sintesi

Per la maggior parte delle persone non c'è nulla da fare: basta tenere aggiornati browser e sistema operativo, e la protezione arriva da sola. Per chi gestisce siti e server il messaggio è di prepararsi senza fretta ma senza rimandare: verificare che il proprio stack supporti lo scambio di chiavi post-quantum, tenere aggiornato il software e, guardando più avanti, abituarsi all'idea che i certificati andranno rinnovati con nuovi formati. Diverse autorità - statunitensi, europee, britanniche, australiane - indicano scadenze di migrazione tra il 2030 e il 2035: c'è tempo, ma non è una buona ragione per aspettare in modo passivo.

Il superamento del 50% non risolve il problema, ma segna che la transizione è iniziata sul serio e sta procedendo in silenzio, un aggiornamento del browser alla volta.

::cta{title="Vuoi adeguare la tua infrastruttura alla crittografia post-quantum?" text="Aggiorniamo e gestiamo la configurazione TLS dei server che seguiamo, con attenzione a certificati e algoritmi supportati." button="Parliamone →"}

Fonti

Agent Skills: impacchettare il know-how per gli assistenti AI

Alessandro Corbelli — Thu, 16 Oct 2025 00:00:00 GMT

Gli assistenti basati sull'intelligenza artificiale sono bravi a rispondere a domande e a scrivere testi. Quando però devono seguire una procedura precisa - il modo in cui una certa azienda prepara un report, applica una convenzione sui nomi dei file o compila un modulo - vanno guidati ogni volta. Di solito si finisce per reincollare le stesse istruzioni in ogni conversazione, oppure per costruire un assistente su misura per ciascun compito. Il 16 ottobre 2025 Anthropic, l'azienda che sviluppa l'assistente Claude, ha presentato le Agent Skills: un modo per impacchettare quelle istruzioni, e gli eventuali script, in cartelle riutilizzabili che l'assistente carica solo quando servono.

Dietro il nome tecnico c'è un'idea semplice, che riguarda chiunque usi l'AI per compiti che si ripetono. Vale la pena capirla.

Prima, un chiarimento sui termini

Qui per agente si intende un assistente AI che non si limita a rispondere, ma può usare strumenti e compiere più passi per portare a termine un'attività: leggere un file, eseguire un piccolo programma, produrre un documento. Un altro termine utile è contesto: è tutto ciò che l'assistente "ha davanti" mentre lavora, cioè la richiesta dell'utente più le istruzioni e le informazioni caricate in quel momento. Il contesto ha uno spazio limitato: più roba ci si mette, più diventa dispersivo e costoso. Tenere a mente questo limite aiuta a capire perché le Skills sono fatte come sono.

Il problema: ogni procedura riscritta da capo

Un'azienda accumula col tempo un patrimonio di "come si fa qui": il formato standard di una fattura, i passaggi per generare un bilancio mensile, le regole di stile per un testo, la sequenza esatta per preparare un pacchetto software. Sono conoscenze procedurali, spesso non scritte da nessuna parte in modo ordinato.

Per far seguire una di queste procedure a un assistente AI ci sono due strade, entrambe scomode. La prima è incollare le istruzioni nella conversazione ogni volta: funziona, ma è ripetitivo e facile da sbagliare, e occupa spazio prezioso nel contesto. La seconda è costruire un assistente dedicato per ogni singolo compito: preciso, ma richiede lavoro tecnico e va rifatto per ognuna delle tante procedure. In entrambi i casi il know-how resta difficile da riutilizzare e da condividere.

Le Agent Skills nascono per togliere di mezzo proprio questa frizione: scrivere una procedura una volta, in un formato ordinato, e poterla poi richiamare quando serve senza reincollarla.

::cta{variant="inline" title="Le procedure della tua azienda vivono solo nella testa di qualcuno?" text="Valutiamo con te quali processi ripetitivi convertire in automazioni o Skill riutilizzabili, con giudizio su sicurezza e costi." button="Chiedi una valutazione →"}

Cos'è una Skill: una cartella con dentro le istruzioni

Nella pratica una Skill è semplicemente una cartella. Dentro c'è un file obbligatorio chiamato SKILL.md e, se servono, altri file: documenti di approfondimento, esempi, oppure piccoli script pronti all'uso.

Il file SKILL.md è scritto in un formato leggibile anche da una persona. In cima ha poche righe di metadati in YAML - un modo essenziale per annotare coppie "etichetta: valore" - con almeno un nome e una descrizione di cosa fa la Skill. Sotto, in Markdown (lo stesso testo semplice di tanti file di appunti), ci sono le istruzioni vere e proprie: i passaggi da seguire, le convenzioni da rispettare, gli esempi. In sostanza è un foglio di istruzioni ordinato. Anthropic usa un'analogia efficace: costruire una Skill è come preparare la guida di benvenuto per una persona appena assunta.

Una struttura minima somiglia a questa:

report-mensile/
  SKILL.md        # cosa fa e come si fa, passo per passo
  esempio.md      # un caso già svolto, come riferimento
  genera.py       # uno script opzionale per i passaggi ripetitivi

Il fatto che sia una cartella con file di testo ha un vantaggio pratico non piccolo: una Skill si può salvare, versionare come si fa con il codice, e passare a un collega semplicemente condividendo la cartella.

Il trucco: caricare le informazioni a strati

Se ogni Skill venisse caricata per intero e sempre, si tornerebbe al problema del contesto ingombro. Le Agent Skills evitano questo con un caricamento progressivo, cioè a strati, per mettere davanti all'assistente solo ciò che serve al momento.

Funziona così, in tre livelli:

All'avvio l'assistente conosce soltanto nome e descrizione di ogni Skill disponibile. Poche righe a testa: giusto abbastanza per sapere che quella Skill esiste e a cosa serve.
Quando la richiesta dell'utente combacia con una Skill, l'assistente apre e legge il contenuto completo del relativo SKILL.md, con tutte le istruzioni.
Se il SKILL.md rimanda ad altri file - un documento di dettaglio, un esempio lungo - quelli vengono aperti solo se davvero necessari.

Il risultato è che si possono tenere a disposizione molte Skills, anche corpose, senza appesantire ogni conversazione. L'assistente "sfoglia l'indice" e va a leggere il capitolo giusto solo quando gli serve, invece di tenere tutti i manuali aperti sulla scrivania.

C'è un secondo elemento utile: una Skill può includere script già scritti, per esempio in Python. Per i passaggi ripetitivi e meccanici, l'assistente può eseguire quel codice invece di improvvisare la procedura ogni volta, un po' come si affida a un timer automatico un compito che altrimenti andrebbe rilanciato a mano. Per certi compiti è più affidabile e più economico far girare uno script collaudato che chiedere al modello di rifare tutto a mano.

Dove si possono usare

Le Agent Skills funzionano nello stesso formato in più contesti: l'app di Claude (per i piani Pro, Max, Team ed Enterprise), lo strumento per sviluppatori Claude Code, l'API rivolta agli sviluppatori e l'Agent SDK, cioè il kit per costruire i propri agenti. Lo stesso pacchetto, quindi, si sposta da un ambiente all'altro senza doverlo riscrivere.

Al lancio Anthropic ha messo a disposizione alcune Skills pronte per compiti d'ufficio molto comuni: creare fogli di calcolo Excel con le formule, presentazioni PowerPoint, documenti Word e moduli PDF compilabili. C'è poi una Skill particolare, la skill-creator, che aiuta a costruirne di nuove in modo guidato: fa domande sul flusso di lavoro, prepara la struttura di cartelle e imposta il file SKILL.md. Un modo per iniziare senza partire dal foglio bianco.

Sul piano della disponibilità, va detto per correttezza che non tutto è identico ovunque: l'uso via API, per esempio, si appoggia alla funzione di esecuzione del codice, ancora in fase beta, e negli account aziendali un amministratore deve abilitare la funzione per l'organizzazione. Dettagli, ma utili per non farsi trovare impreparati.

Perché è utile a chi ha procedure ricorrenti

Il valore vero non sta in una singola funzione, ma nello spostamento di lavoro che rende possibile. Una procedura scritta bene una volta smette di essere un'istruzione da ripetere a voce e diventa un pezzo riutilizzabile: si richiama quando serve, si può migliorare nel tempo modificando un file, si passa a un collega condividendo una cartella. In pratica è un modo per capitalizzare il know-how che oggi vive nella testa delle persone o sparso in appunti diversi.

Per chi gestisce sistemi e infrastrutture il paragone è immediato: è la stessa logica per cui una procedura ripetitiva conviene metterla in uno script o in un playbook, invece di eseguirla a memoria ogni volta. Qui il "playbook" è scritto in modo che possa seguirlo un assistente AI, con la possibilità di includere anche il codice per i passaggi meccanici.

Attenzione alla provenienza

Una nota di prudenza, che Anthropic stessa mette in evidenza. Una Skill può contenere istruzioni e codice che vengono eseguiti, e può indicare all'assistente di accedere a risorse esterne. Vanno quindi installate solo da fonti di cui ci si fida, e quelle di provenienza incerta è bene esaminarle prima: cosa contengono i file, se il codice si collega a servizi esterni, se ci sono istruzioni che potrebbero portare dati fuori dove non dovrebbero. È la stessa cautela che si userebbe prima di far girare uno script scaricato da internet. La comodità non toglie la responsabilità di controllare.

In sintesi

Le Agent Skills, presentate da Anthropic il 16 ottobre 2025, sono cartelle che raccolgono istruzioni e script riutilizzabili per gli assistenti AI, con al centro un file SKILL.md in testo semplice. Risolvono un problema concreto e quotidiano: non dover riscrivere ogni volta le stesse procedure. Il caricamento a strati permette di tenerne a disposizione molte senza ingombrare il contesto, e la possibilità di includere script rende più affidabili i passaggi ripetitivi. Funzionano nell'app, in Claude Code, via API e con l'Agent SDK. Quanto diventerà uno strumento diffuso lo diranno i mesi a venire; l'idea di fondo, però, è chiara e sensata: mettere il know-how in un formato ordinato e riutilizzabile, invece di ripeterlo a voce ogni volta.

::cta{title="Vuoi portare l'AI dentro i flussi di lavoro della tua azienda?" text="Progettiamo integrazioni AI su misura nei vostri applicativi Laravel e Vue, valutando sicurezza dei dati e costi prima di andare in produzione." button="Parliamone →"}

Fonti

Transizioni animate native nel browser: le View Transitions diventano Baseline

Alessandro Corbelli — Tue, 21 Oct 2025 00:00:00 GMT

Cambiare schermata su un sito è quasi sempre uno scatto secco: un contenuto sparisce, un altro appare, senza alcun passaggio morbido. Per ottenere quelle animazioni fluide che si vedono nelle app - un'immagine che si ingrandisce, un elenco che scorre in modo ordinato - di solito servono librerie JavaScript dedicate, con codice da scrivere e mantenere. A metà ottobre 2025 è arrivata una novità che riguarda chi costruisce siti: le View Transitions same-document, cioè le transizioni animate all'interno della stessa pagina, sono diventate Baseline. In parole semplici, ora funzionano in modo affidabile su tutti i principali browser, e il grosso del lavoro lo fa il browser stesso.

La notizia in breve

Il 14 ottobre 2025 le View Transitions same-document hanno raggiunto lo stato "Baseline Newly available". Il passaggio è avvenuto con l'uscita di Firefox 144, l'ultimo dei tre principali motori di browser a supportare la funzione. Google Chrome la offre dal 2023 (dalla versione 111) e Safari di Apple dalla versione 18, uscita a settembre 2024. Con Firefox il cerchio si chiude: la stessa funzione, scritta una volta, si comporta allo stesso modo ovunque. Il traguardo rientra in Interop 2025, l'iniziativa con cui i produttori di browser concordano un elenco di funzioni web da rendere compatibili tra loro nell'arco dell'anno.

Cosa vuol dire "Baseline"

Baseline è un'etichetta pensata per rispondere a una domanda pratica: posso usare questa funzione senza il timore di lasciare fuori una fetta di visitatori? Una funzione è Baseline quando è supportata dalle versioni recenti dei browser costruiti sui tre motori più diffusi: Chromium (Chrome, Edge e altri), WebKit (Safari) e Gecko (Firefox).

Lo stato "Newly available" indica che il traguardo è stato appena raggiunto: la funzione è pronta all'uso, ma i dispositivi più datati potrebbero avere versioni di browser ancora prive del supporto. Con il tempo, quando gli aggiornamenti si diffondono, lo stato passa a "Widely available". Sapere che una funzione è Baseline aiuta a decidere con serenità se adottarla in un progetto reale.

::cta{variant="inline" title="Il tuo sito cambia schermata con uno scatto secco invece che con una transizione morbida?" text="Verifichiamo se puoi già sfruttare le View Transitions native senza aggiungere librerie." button="Verifica il tuo sito →"}

Che cos'è una view transition

Una view transition è un'animazione che collega due stati di una pagina. Immagina una galleria di foto: si tocca una miniatura e la si vede crescere fino a diventare l'immagine grande, invece di comparire di colpo. Prima, un effetto del genere andava costruito a mano.

Il meccanismo, dal punto di vista del browser, è semplice da raccontare. Quando si avvia una transizione, il browser scatta una "fotografia" della pagina com'è adesso, lascia che il contenuto cambi, scatta una seconda fotografia del nuovo stato e anima il passaggio dalla prima alla seconda. L'effetto predefinito è una dissolvenza incrociata: il vecchio aspetto sfuma mentre il nuovo compare. Con poche righe di stile CSS si possono poi ottenere movimenti più elaborati, come uno scorrimento o un ingrandimento.

La novità di ottobre riguarda le transizioni same-document, cioè quelle che avvengono senza cambiare pagina, mentre il contenuto viene aggiornato via JavaScript. È lo scenario tipico delle applicazioni a pagina singola (in inglese single-page application), dove il sito riscrive parti della schermata senza ricaricare tutto. Esiste anche una variante cross-document, pensata per le transizioni tra pagine diverse durante la normale navigazione: è una funzione collegata ma distinta, che segue un percorso a sé e non è l'oggetto di questo annuncio.

Il problema che risolve

Fino a ieri, per animare in modo curato il passaggio tra due stati servivano quasi sempre librerie JavaScript specializzate, un po' come succedeva per posizionare tooltip e menu prima del CSS Anchor Positioning. Sono strumenti validi, ma hanno un costo: codice in più da caricare e mantenere, animazioni da sincronizzare a mano, e il rischio di appesantire la pagina. C'è anche un tema di coerenza, perché ogni libreria fa le cose a modo suo.

Spostando questo lavoro dentro il browser, gran parte di quel codice non serve più. Il browser conosce la posizione e l'aspetto degli elementi prima e dopo il cambiamento, quindi può calcolare l'animazione in modo efficiente. Per molti casi comuni si ottiene così una transizione gradevole senza aggiungere alcuna libreria, con un beneficio indiretto anche sulla reattività della pagina alle interazioni, la stessa che misura l'INP.

Come funziona, in pratica

Il cuore della funzione è un solo metodo, document.startViewTransition(). Gli si passa la funzione che modifica il contenuto della pagina, e il browser si occupa dell'animazione.

// Aggiornamento senza animazione
function aggiornaPagina() {
  // ... qui si modifica il contenuto della pagina ...
}

// Con una transizione animata, quando il browser la supporta
function aggiornaConTransizione() {
  if (!document.startViewTransition) {
    aggiornaPagina(); // ripiego: aggiorna e basta
    return;
  }
  document.startViewTransition(() => aggiornaPagina());
}

Il punto chiave è il controllo if (!document.startViewTransition): se il browser non conosce la funzione, il contenuto viene aggiornato lo stesso, solo senza animazione. Questo approccio, chiamato miglioramento progressivo, fa sì che il sito resti pienamente funzionante ovunque, con l'animazione come extra dove è disponibile.

Per animare un singolo elemento in modo indipendente dal resto - per esempio far "viaggiare" un'immagine dalla miniatura alla sua versione grande - si assegna un nome tramite la proprietà CSS view-transition-name. Il browser riconosce che quell'elemento è lo stesso prima e dopo il cambiamento, e lo anima di conseguenza invece di limitarsi alla dissolvenza generale.

Cosa cambia per chi fa frontend, e qualche avvertenza

Per chi sviluppa interfacce, il vantaggio principale è meno codice da scrivere per un risultato più fluido. Restano però un paio di dettagli da tenere presenti.

Il primo riguarda Firefox: la sua prima versione con questa funzione non include ancora le cosiddette tipologie di transizione (view transition types), uno strumento più avanzato per applicare animazioni diverse a seconda del contesto. Chi ne ha bisogno può prevedere un comportamento di ripiego, esattamente come nel controllo mostrato sopra.

Il secondo è l'accessibilità. Non tutti gradiscono le animazioni, e alcune persone le trovano fastidiose o fonte di disagio. I sistemi operativi offrono un'impostazione per ridurre il movimento, che sul web si legge con la regola CSS prefers-reduced-motion. È buona norma rispettarla, riducendo o togliendo l'animazione a chi l'ha richiesta.

In sintesi

Le View Transitions same-document sono diventate Baseline il 14 ottobre 2025, con l'arrivo del supporto in Firefox 144 accanto a Chrome e Safari. In pratica, il browser può ora animare da solo il passaggio tra due stati di una pagina, un compito che prima richiedeva quasi sempre librerie JavaScript, proprio come sta succedendo con altre funzioni portate nativamente nel browser, ad esempio l'intelligenza artificiale eseguita direttamente lì dentro. Per chi costruisce siti significa meno codice, animazioni più coerenti e pagine potenzialmente più leggere, a patto di gestire con cura i browser più datati e le preferenze di chi non vuole movimento. È una di quelle novità silenziose che, nel tempo, rendono il web un po' più piacevole da usare.

::cta{title="Vuoi animazioni più fluide senza appesantire il frontend?" text="Integriamo le View Transitions e le altre funzioni native del browser nei siti e nelle applicazioni Vue che sviluppiamo, mantenendo il codice leggero." button="Parliamone →"}

Fonti

Come scegliere un provider cloud: i criteri che contano davvero

Alessandro Corbelli — Thu, 13 Nov 2025 00:00:00 GMT

Scegliere dove ospitare un sito, un'applicazione o un intero sistema aziendale è una di quelle decisioni che sembrano solo tecniche e invece pesano sul portafoglio per anni. Il mercato del cloud offre decine di fornitori, ognuno con la sua tabella dei prezzi, e il rischio è confrontarli guardando la voce sbagliata. Questa guida mette in fila i criteri che contano davvero, senza spingere un provider in particolare: l'obiettivo è aiutare a ragionare, non vendere.

Con "cloud provider" si intende un'azienda che affitta risorse informatiche via Internet: potenza di calcolo, spazio di archiviazione, rete. Invece di comprare un server e tenerlo in ufficio, si paga un canone per usarne uno (o mille) da remoto. Fin qui è semplice. La complessità arriva quando si prova a capire quanto costa davvero.

Il modello di prezzo: hyperscaler contro VPS

Semplificando, i fornitori si dividono in due grandi famiglie. Da una parte gli hyperscaler - i colossi globali come Amazon Web Services (AWS), Microsoft Azure e Google Cloud - che vendono un catalogo di centinaia di servizi separati, dalle istanze di calcolo tradizionali fino ai nuovi chip ARM pensati per abbattere i costi. Dall'altra i provider di VPS (Virtual Private Server, cioè "server privati virtuali"): una macchina virtuale a canone fisso, con un prezzo quasi tutto compreso.

La differenza non è solo di scala, è di filosofia. L'hyperscaler non ti vende "una macchina": ti vende l'istanza di calcolo, e poi - a voci separate - l'indirizzo IP pubblico, lo spazio disco, le copie di sicurezza, il bilanciatore di carico, il traffico di rete e il piano di supporto. Il prezzo dell'istanza è la punta dell'iceberg. Un VPS parte invece dall'idea opposta: un canone che include già disco, traffico e indirizzo IP. È meno flessibile, ma molto più facile da preventivare.

Nessuno dei due modelli è "giusto" in assoluto. Il punto è che confrontarli solo sul prezzo orario dell'istanza è fuorviante, perché in quel prezzo i due casi comprendono cose diverse.

I costi nascosti: la banda in uscita

Se c'è una voce che fa saltare i preventivi, è la banda in uscita (in inglese egress): il traffico di dati che esce dal cloud verso Internet, cioè verso gli utenti. Ogni immagine, video, download o risposta di un'API che raggiunge un visitatore è traffico in uscita.

Sugli hyperscaler questo traffico si paga a consumo, al gigabyte. AWS, per esempio, include 100 GB al mese gratuiti aggregati su tutti i servizi, e poi fattura ogni gigabyte successivo. Sembra poco, ma un sito con molte immagini o un servizio che distribuisce file può muovere terabyte al mese: a quel punto la banda diventa una delle voci più pesanti della fattura, a volte più dell'istanza stessa.

I provider di VPS di solito ribaltano la logica: includono nel canone una quota di traffico molto generosa e fanno pagare pochissimo l'eventuale eccedenza. La conseguenza pratica è semplice: se l'applicazione muove molti dati verso l'esterno, il modello a consumo può costare ordini di grandezza in più. Se invece consuma soprattutto CPU e database con poco traffico, la differenza si assottiglia. La regola è stimare la banda in uscita prima di scegliere, non dopo la prima bolletta.

::cta{variant="inline" title="Sai davvero quanto ti costerebbe la banda in uscita del tuo carico?" text="Analizziamo il traffico reale della tua applicazione e confrontiamo hyperscaler e VPS sul costo effettivo, non sul prezzo dell'istanza." button="Chiedi una stima →"}

Servizi gestiti o self-managed?

Qui il confronto si ribalta. Un servizio gestito (managed) è una risorsa che il provider mantiene per conto tuo: un database gestito, per esempio, viene aggiornato, salvato e replicato in automatico, con sostituzione del nodo in caso di guasto. L'alternativa è il self-managed: il provider ti dà la macchina "nuda" e database, aggiornamenti, backup e monitoraggio li configuri e li tieni in piedi tu.

Gli hyperscaler eccellono nei servizi gestiti, dal database completamente amministrato alle GPU serverless per l'inferenza AI: hanno cataloghi enormi che tolgono lavoro operativo. I VPS offrono soprattutto materia prima, ottima e a buon prezzo, ma da amministrare. La domanda giusta non è "chi ne ha di più", ma "quanto vale il mio tempo". Un database gestito costa più di uno installato a mano, però quel sovrapprezzo è il lavoro (e la reperibilità notturna) che non devi fare tu. Se in casa ci sono le competenze per gestire l'infrastruttura, il self-managed fa risparmiare; se non ci sono, il servizio gestito spesso costa meno del personale che servirebbe. Il self-managed non è gratis: è un costo che si sposta dalla fattura del cloud alle ore di chi amministra.

Dove stanno i dati: data center, UE e GDPR

Un provider ha data center - i capannoni pieni di server - in zone geografiche chiamate region. La scelta della region conta per due motivi. Il primo è la latenza: più il server è vicino agli utenti, più le risposte arrivano in fretta. Il secondo, spesso più importante, è legale.

Il GDPR, il regolamento europeo sulla protezione dei dati, pone regole precise su dove possono finire i dati personali. Il suo Capo V (articoli 44 e seguenti) stabilisce che il trasferimento di dati personali fuori dall'Unione Europea è vietato salvo condizioni specifiche. Tradotto: se tratti dati di cittadini europei, il luogo fisico in cui risiedono quei dati non è un dettaglio.

C'è però una sottigliezza che sfugge a molti. Scegliere una region europea non basta a mettere i dati al riparo da ogni richiesta esterna. Per via del CLOUD Act statunitense, la giurisdizione americana segue l'azienda, non il server: un fornitore soggetto al diritto USA può essere obbligato a consegnare i dati che controlla anche se sono archiviati in un data center europeo. Non significa che gli hyperscaler americani siano "fuori legge" - hanno costruito offerte apposite per rispondere al tema - ma che la sovranità dei dati va valutata sul prodotto e sull'entità legale che lo gestisce, non sulla bandiera nel logo.

Il rischio di lock-in

Lock-in significa dipendenza tecnica: quanto è costoso e complicato cambiare fornitore una volta entrati. Su un VPS è basso, perché di solito è una macchina Linux standard che si migra altrove in un pomeriggio. Su un hyperscaler può essere alto, perché i servizi proprietari - database su misura, funzioni serverless, code di messaggi - non esistono uguali altrove, e riscriverli costa.

C'è anche una forma più subdola di lock-in: la gravità dei dati. Più dati accumuli in un servizio, più costa portarli via, perché l'uscita di quei terabyte passa proprio dalla banda in uscita a pagamento. Il costo dell'egress diventa così anche un pedaggio che scoraggia la migrazione. La difesa è progettuale: preferire, dove possibile, componenti standard e aperti, descrivere l'infrastruttura con strumenti di Infrastructure as Code invece che a mano, e sapere fin dall'inizio quanto costerebbe traslocare. Il lock-in non è un difetto morale, è una scelta da fare con gli occhi aperti.

Il supporto

Ultimo criterio, spesso sottovalutato: cosa succede quando qualcosa si rompe alle tre di notte. I livelli di supporto variano moltissimo. Alcuni provider includono un'assistenza di base nel canone; gli hyperscaler vendono i piani di supporto a parte, spesso come percentuale della spesa mensile. Vale la pena leggere lo SLA (Service Level Agreement, l'accordo sul livello di servizio): promette una certa disponibilità e certi tempi di risposta, ma spesso il "rimborso" per un disservizio è solo un credito sulla fattura, non un risarcimento del danno reale. Il supporto non si valuta dal numero verde in homepage, ma da cosa c'è scritto nel contratto.

In sintesi

Non esiste "il cloud migliore": esiste il modello giusto per un carico specifico. Conviene procedere per ordine. Prima stimare la banda in uscita, che è la variabile che più spesso ribalta i conti. Poi decidere quanto lavoro operativo delegare, scegliendo tra servizi gestiti e self-managed in base alle competenze disponibili. Quindi verificare dove devono stare i dati e chi può essere obbligato a consegnarli. Infine mettere in conto il rischio di lock-in e leggere per davvero le condizioni di supporto. Il prezzo orario dell'istanza, quello che tutti confrontano per primo, è quasi sempre la voce meno importante.

::cta{title="Devi scegliere o cambiare provider cloud per la tua infrastruttura?" text="Progettiamo e gestiamo infrastrutture su misura su AWS, Google Cloud e VPS, valutando insieme costi, GDPR e rischio di lock-in prima di firmare." button="Parliamo della tua infrastruttura →"}

Fonti

Google presenta Gemini 3: cosa cambia per chi sviluppa

Alessandro Corbelli — Tue, 18 Nov 2025 00:00:00 GMT

Chi sviluppa software o costruisce automazioni si ritrova, ogni pochi mesi, davanti a un nuovo modello di intelligenza artificiale presentato come il più capace mai visto. Il 18 novembre 2025 Google ha annunciato Gemini 3, la nuova generazione della sua famiglia di modelli. Conviene guardare oltre il titolo: cosa migliora davvero, per quali usi, e con quali riserve. Questo articolo prova a riassumere l'annuncio in modo sobrio, distinguendo i fatti dichiarati dalle promesse di marketing.

Cos'è Gemini 3

Partiamo dai termini. Gemini è la famiglia di modelli di intelligenza artificiale di Google, quella che alimenta l'app Gemini, alcune funzioni della Ricerca e vari strumenti per chi programma. Gemini 3 è la nuova generazione, che prende il posto della precedente (Gemini 2.5) come modello di punta.

Al centro del lancio c'è Gemini 3 Pro, disponibile da subito in anteprima. È un modello multimodale: vuol dire che nella stessa richiesta capisce testo, immagini, video, audio e codice, senza doverli trattare separatamente. Ha una finestra di contesto da circa un milione di token. Un token è un pezzetto di testo, più o meno una sillaba o una parola breve; la finestra di contesto è quanto materiale il modello riesce a tenere presente in una sola conversazione. Un milione di token è molto: consente di passargli interi progetti o documenti lunghi senza spezzarli a mano. La risposta, invece, può arrivare fino a circa 65.000 token.

Accanto al modello principale, Google ha annunciato Gemini 3 Deep Think, una modalità pensata per i problemi di ragionamento più difficili. Al momento dell'annuncio non era ancora disponibile in modo ampio: è destinata inizialmente agli abbonati al piano Ultra. È bene tenerne conto, perché una funzione annunciata non è una funzione che si può già usare.

I miglioramenti dichiarati

Google afferma che Gemini 3 Pro supera il modello precedente sui principali benchmark, cioè le prove standardizzate con cui si misurano i modelli. Vale la pena riportare qualche numero, ma con la giusta cautela: sono cifre dichiarate da chi vende il prodotto, ognuna misura solo una fetta del lavoro reale, e nessuna racconta tutto.

Sul fronte del ragionamento, Google cita un 91,9% su GPQA Diamond, un test di domande scientifiche di livello universitario avanzato, e un 37,5% su "Humanity's Last Exam", un esame difficile che spazia su molte materie.

Sul fronte del codice, i numeri riguardano compiti concreti. Su SWE-bench Verified, che misura la capacità di correggere bug reali presi da progetti su GitHub, il modello dichiara un 76,2%. Su Terminal-Bench 2.0, che valuta il portare a termine compiti dentro un terminale, un 54,2%.

Ci sono poi le classifiche a voto umano, dove le persone confrontano le risposte di modelli diversi senza sapere quale sia quale. Google riferisce di essere in cima a LMArena (1501 punti Elo) e a WebDev Arena (1487), quest'ultima dedicata alla costruzione di piccole applicazioni web. Sono indicatori utili per farsi un'idea, non prove definitive.

::cta{variant="inline" title="Ti stai chiedendo se vale la pena integrare Gemini 3 nei tuoi sistemi?" text="Valutiamo benchmark, costi e rischi rispetto al caso d'uso reale, prima di scegliere un modello." button="Chiedi una valutazione →"}

Perché conta per agenti e automazione

Un agente è un programma che, oltre a rispondere, compie azioni concrete per conto di chi lo usa: legge file, esegue comandi, usa strumenti esterni spesso collegati tramite standard aperti come MCP. Chi valuta un modello per costruire automazioni guarda proprio a questo, non solo alla qualità del testo prodotto.

È il motivo per cui benchmark come Terminal-Bench o SWE-bench pesano più di altri: raccontano quanto il modello se la cava quando deve muoversi tra file, comandi e strumenti, invece di limitarsi a chiacchierare. Insieme al modello, Google ha presentato Antigravity, una piattaforma di sviluppo pensata per far lavorare gli agenti con accesso diretto all'editor, al terminale e al browser. Gemini 3 arriva anche dentro Gemini CLI, l'assistente da riga di comando già esistente.

Per chi progetta sistemi conta anche un dettaglio più tecnico: l'API introduce un parametro chiamato thinking level, con cui si decide quanto a fondo il modello debba "ragionare" prima di rispondere. È una leva pratica: ragionare di più può migliorare la qualità su problemi complessi, ma costa di più e richiede più tempo. Poterlo regolare aiuta a bilanciare spesa, velocità e accuratezza a seconda del compito.

Come provarlo e quanto costa

Per chi sviluppa, Gemini 3 Pro è raggiungibile tramite l'API di Gemini in due ambienti: Google AI Studio, con un accesso gratuito soggetto a limiti d'uso, e Vertex AI, la piattaforma cloud rivolta alle aziende. Il modello è anche integrato in strumenti di terze parti già diffusi tra chi programma, come Cursor, GitHub, JetBrains e Replit. Per il pubblico generico, invece, è arrivato nell'app Gemini e in alcune funzioni della Ricerca.

Sui costi, Google ha indicato un prezzo di 2 dollari per milione di token in ingresso e 12 dollari per milione di token in uscita, per le richieste fino a 200.000 token; oltre quella soglia la tariffa cambia. Sono valori utili per stimare la spesa di un uso intensivo, ma vanno verificati sulla documentazione al momento dell'adozione, perché i listini dei modelli cambiano spesso.

Le cautele

Prima di spostarci sul nuovo modello conviene tenere presenti alcuni punti, senza entusiasmi.

È un'anteprima. Google lo descrive come versione in preview: comportamenti, funzioni e prezzi possono cambiare. Non è il caso di appoggiarci processi critici senza un'alternativa pronta.

I numeri sono di parte. I benchmark sono dichiarati da chi vende il prodotto e misurano scenari standardizzati. L'unico giudice affidabile resta la prova sui propri casi d'uso reali.

I dati vanno nel cloud. Come per i modelli precedenti, il calcolo avviene sui server di Google: ciò che si invia al modello esce dal proprio computer. Per contenuti riservati è un aspetto da valutare con attenzione, anche alla luce di quanto richiesto dal GDPR sul lato infrastruttura quando si trattano dati personali.

Non tutto è disponibile subito. Deep Think e alcune funzioni non erano accessibili a tutti al momento del lancio. Meglio verificare cosa si può usare davvero, e con quale piano, prima di fare affidamento su una capacità specifica.

In sintesi

Gemini 3 è la nuova generazione dei modelli di Google, con Gemini 3 Pro disponibile in anteprima e una modalità Deep Think annunciata per i compiti di ragionamento più difficili. Google dichiara miglioramenti su ragionamento, codice e comprensione multimodale, con numeri interessanti ma di parte. Per chi costruisce agenti e automazioni le novità più concrete sono le migliori prestazioni sui compiti pratici, la piattaforma Antigravity e il controllo sul livello di ragionamento tramite API. Resta uno strumento in anteprima, che gira nel cloud e va misurato sui propri casi: vale la pena provarlo, senza prenderne per buoni i comunicati.

::cta{title="Vuoi integrare l'AI nei tuoi flussi di lavoro con criterio?" text="Progettiamo automazioni e agenti che usano modelli come Gemini 3 dentro il software che sviluppiamo, con attenzione a sicurezza dei dati e costi per richiesta." button="Parliamone →"}

Fonti

MCP passa alla Linux Foundation: uno standard aperto e neutrale

Alessandro Corbelli — Mon, 08 Dec 2025 00:00:00 GMT

Sempre più programmi di intelligenza artificiale non si limitano a rispondere a domande: leggono file, interrogano database, usano strumenti esterni per conto di chi li adopera, come fa ormai anche un assistente che lavora da riga di comando. Perché tutto questo funzioni serve un modo comune per collegare quei programmi ai sistemi con cui devono parlare. Uno degli standard più diffusi per farlo si chiama MCP. All'inizio di dicembre 2025 è stato annunciato un cambiamento che lo riguarda: MCP non è più governato da una sola azienda, ma è passato sotto una fondazione indipendente. La notizia interessa soprattutto chi costruisce software su questo standard, ma vale la pena capirla anche da fuori, perché tocca un punto semplice: di chi ci si fida quando si sceglie una tecnologia su cui appoggiare il proprio lavoro.

Cos'è MCP

Partiamo dai termini. MCP sta per Model Context Protocol, che si può tradurre come «protocollo di contesto per i modelli». Un protocollo è un insieme di regole condivise che permette a due programmi di parlarsi, un po' come una lingua comune. MCP definisce un modo standard per collegare le applicazioni di intelligenza artificiale - per esempio un assistente come ChatGPT o Claude - ai sistemi esterni: documenti, database, strumenti di lavoro, servizi online.

Il problema che affronta è concreto. Senza uno standard condiviso, ogni volta che si vuole far dialogare un modello con un nuovo strumento bisogna scrivere un collegamento su misura. Con tanti modelli da un lato e tanti strumenti dall'altro, il numero di integrazioni da costruire e mantenere cresce in fretta. Un protocollo comune riduce quel lavoro: chi realizza uno strumento lo espone una volta sola seguendo le regole di MCP, e qualsiasi applicazione che «parla» MCP può usarlo senza integrazioni dedicate. L'idea ricorda quella di una presa standard come l'USB: un solo tipo di connettore al posto di tanti cavi incompatibili.

MCP è nato circa un anno fa e si è diffuso rapidamente. Secondo i dati riportati nell'annuncio, i pacchetti per sviluppatori (le librerie con cui si integra il protocollo) superano i 97 milioni di scaricamenti al mese, e si contano oltre 10.000 server MCP pubblici attivi - cioè strumenti già pronti da collegare. Il supporto è presente in diversi prodotti diffusi, tra cui ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e Visual Studio Code. Sono cifre dichiarate da chi promuove lo standard, quindi da prendere come ordine di grandezza più che come misura esatta; restano comunque il segnale di un'adozione ampia.

Cosa è successo

Il cambiamento riguarda la governance, cioè chi decide come lo standard evolve. Fino a oggi MCP era guidato da Anthropic, l'azienda che lo ha creato. Con l'annuncio di dicembre, il protocollo è stato donato all'Agentic AI Foundation (AAIF), una nuova iniziativa ospitata dalla Linux Foundation.

La Linux Foundation è un'organizzazione senza scopo di lucro che fa da custode a molti progetti tecnologici aperti e molto usati; ne fanno parte, per esempio, il kernel Linux, Kubernetes e PyTorch. «Ospitare» un progetto significa mettergli intorno una struttura neutrale, con regole condivise, che non appartiene a un singolo fornitore.

L'Agentic AI Foundation nasce con l'obiettivo dichiarato di far crescere in modo aperto e collaborativo le tecnologie legate agli agenti, cioè i programmi di intelligenza artificiale che, oltre a rispondere, compiono azioni concrete usando strumenti esterni. È co-fondata da Anthropic, Block e OpenAI, con il sostegno di Google, Microsoft, AWS, Cloudflare e Bloomberg. Nasce con tre progetti fondanti: MCP, donato da Anthropic; goose, un progetto di Block; e AGENTS.md, una convenzione proposta da OpenAI. Il fatto che aziende spesso concorrenti tra loro contribuiscano insieme alla stessa fondazione è, di per sé, parte della notizia, sulla stessa scia di altri tentativi di dare regole condivise al modo in cui gli agenti AI vengono istruiti, come le Agent Skills di Anthropic.

::cta{variant="inline" title="Stai valutando di collegare i tuoi sistemi a un assistente AI tramite MCP?" text="Verifichiamo quali dati e strumenti esporre in sicurezza, e quali tenere fuori dalla portata di un agente." button="Chiedi una valutazione →"}

Perché una fondazione neutrale conta

Qui sta il senso pratico dell'annuncio. Quando uno standard è controllato da una sola azienda, chi ci costruisce sopra dipende dalle scelte di quell'azienda: le sue priorità, il suo modello di business, la sua strategia. Se un giorno cambiassero, lo standard potrebbe seguirle. È il timore che frena molte adozioni, soprattutto quando si tratta di infrastruttura destinata a durare.

Affidare lo standard a una fondazione neutrale sposta il baricentro. Le decisioni non fanno più capo a un unico proprietario, ma a una struttura condivisa in cui più soggetti hanno voce. Non è una garanzia assoluta, ma riduce il rischio che lo standard venga piegato agli interessi di uno solo. È lo stesso percorso già seguito da progetti come Kubernetes e PyTorch, che sotto la Linux Foundation sono diventati riferimenti comuni proprio perché nessun fornitore ne detiene il controllo esclusivo.

Per chi valuta se investire tempo e codice su MCP, questo passaggio è rilevante. Una tecnologia di base - quella su cui si appoggiano altri strumenti - vale soprattutto per la sua stabilità e per la fiducia che ispira nel lungo periodo. Una governance non legata a un singolo vendor rende più credibile la promessa che lo standard resterà aperto e sostenuto anche in futuro.

Cosa cambia (e cosa no) nell'immediato

Per chi già usa MCP, nel breve periodo cambia poco sul piano tecnico. Secondo l'annuncio, il modello di governance introdotto in precedenza continua com'era: le decisioni sul protocollo restano in capo alle stesse persone che lo curano, i maintainer - cioè chi mantiene e fa evolvere il progetto - guidati dai contributi della comunità attraverso il processo con cui si propongono e discutono le modifiche. Lo sviluppo quotidiano prosegue senza interruzioni. Anthropic, dal canto suo, dichiara di voler continuare a investire nello sviluppo, a mantenere l'infrastruttura di base e a partecipare alla comunità.

In pratica, il cambiamento è più di forma che di sostanza tecnica: lo standard resta lo stesso, cambia la casa che lo ospita e le regole di chi ne decide il futuro. È proprio questo il punto della notizia. Non c'è una nuova versione del protocollo da adottare né un'API da riscrivere; c'è una diversa cornice di governo, pensata per dare più garanzie di neutralità.

Cosa resta da vedere

Qualche cautela è d'obbligo, senza sminuire l'annuncio. Il passaggio a una fondazione è un impegno di indirizzo, non un risultato già acquisito: la neutralità dichiarata andrà misurata nel tempo, guardando a come vengono prese le decisioni concrete e a quanto la comunità riesce davvero a influire. La presenza di molte aziende attorno allo stesso tavolo è un segnale positivo, ma governare uno standard condiviso richiede equilibrio costante.

C'è poi un aspetto più generale. MCP è uno standard giovane e in evoluzione: chi lo adotta fa bene a seguirne gli aggiornamenti e a non dare per definitivo tutto ciò che oggi è disponibile. Il passaggio sotto la Linux Foundation non congela il protocollo, lo affida a una struttura pensata per farlo maturare in modo aperto.

In sintesi

MCP è lo standard che permette alle applicazioni di intelligenza artificiale di collegarsi in modo uniforme a strumenti e sistemi esterni. Con l'annuncio di inizio dicembre 2025 è stato donato all'Agentic AI Foundation, una nuova fondazione sotto la Linux Foundation, insieme ad altri due progetti fondanti e con il sostegno di diverse aziende del settore. Sul piano tecnico cambia poco: gli stessi maintainer continuano a curarlo e lo sviluppo prosegue. Cambia la governance, che passa da una singola azienda a una struttura neutrale. Per chi costruisce sopra MCP è la differenza che conta di più: uno standard aperto e non legato a un solo fornitore è più facile da adottare con fiducia. Un impegno nella giusta direzione, di cui resterà da verificare la tenuta nel tempo.

::cta{title="Vuoi integrare l'AI nei tuoi flussi aziendali con giudizio?" text="Progettiamo integrazioni MCP su misura per il tuo software Laravel, valutando sicurezza degli accessi e costi prima di metterle in produzione." button="Parliamone →"}

Fonti

Amazon S3 Vectors: cercare per similarità senza un database dedicato

Alessandro Corbelli — Tue, 09 Dec 2025 00:00:00 GMT

Quando si cerca qualcosa in un archivio, di solito si cercano parole esatte: chi scrive "fattura" trova i documenti che contengono la parola "fattura", non quelli che parlano di "ricevuta" o "nota di pagamento". Le applicazioni basate sull'intelligenza artificiale hanno bisogno di un altro tipo di ricerca: trovare i contenuti simili per significato, anche quando le parole sono diverse. Per farlo serve un modo di conservare e confrontare i dati chiamato database vettoriale. Il 2 dicembre 2025, durante la conferenza re:Invent, AWS ha reso disponibile a tutti - in "disponibilità generale", cioè fuori dalla fase di anteprima riservata - Amazon S3 Vectors, che porta questa capacità dentro S3, il suo servizio di archiviazione più diffuso.

Cosa sono i vettori e perché servono

Per capire l'annuncio conviene partire dai vettori, o embedding. Un embedding è un elenco di numeri che rappresenta il significato di un contenuto: una frase, un documento, un'immagine. A produrlo è un modello di intelligenza artificiale, che trasforma il testo o l'immagine in una lunga sequenza di cifre. L'idea di fondo è semplice: due contenuti simili per significato producono vettori "vicini", due contenuti che parlano di cose diverse producono vettori "lontani". La vicinanza si misura con un calcolo geometrico, come la distanza tra due punti.

Con questo trucco, cercare diventa un'operazione diversa. Invece di confrontare parole, si confrontano numeri: si prende la domanda dell'utente, la si trasforma nel suo vettore e si cercano i vettori più vicini nell'archivio. Il risultato è la ricerca semantica, cioè per significato. Chi cerca "come proteggo il server dagli accessi non autorizzati" può ottenere un documento intitolato "hardening SSH", anche se non contiene nessuna delle parole digitate.

Il collegamento con l'AI: il RAG

Questo meccanismo è il cuore di una tecnica molto usata con i modelli linguistici, il RAG (dall'inglese Retrieval Augmented Generation, "generazione con recupero di informazioni"). Un modello come quelli che alimentano gli assistenti conversazionali sa molte cose in generale, ma non conosce i documenti interni di un'azienda né le informazioni aggiornate a ieri. Il RAG colma questa lacuna: prima di rispondere, il sistema cerca nei propri archivi i passaggi più pertinenti alla domanda - usando proprio la ricerca per similarità tra vettori - e li passa al modello come contesto. Così la risposta si basa su documenti reali e verificabili, non solo su ciò che il modello ha imparato durante l'addestramento.

Per fare tutto questo servono due cose: un posto dove salvare i vettori e un modo veloce per trovare i più vicini a un vettore di riferimento. È il compito di un database vettoriale. Fino a poco tempo fa significava adottare un software specializzato, da installare e mantenere, oppure un servizio dedicato a parte, con un costo che cresce insieme al numero di vettori.

::cta{variant="inline" title="La tua azienda vorrebbe un assistente che risponde sui documenti interni?" text="Valutiamo se un sistema RAG con ricerca semantica ha senso per il tuo caso d'uso, e con quale costo reale." button="Chiedi una valutazione →"}

Cosa cambia mettendo i vettori dentro S3

Amazon S3 è lo storage a oggetti di AWS: un posto dove depositare file di ogni tipo - immagini, backup, log, documenti - pagando poco per grandi quantità di spazio. È uno dei mattoni più comuni delle infrastrutture su cloud, lo stesso servizio che gestisce anche le impostazioni di cifratura lato server. L'idea di S3 Vectors è aggiungere a questo storage la capacità di conservare vettori e di cercarli per similarità, senza affiancargli un database separato.

In pratica si crea un vector bucket, un contenitore simile ai normali bucket S3 ma pensato per i vettori, e al suo interno uno o più vector index (indici vettoriali). Quando si crea un indice si dichiarano poche cose: la dimensione dei vettori, cioè quanti numeri contiene ciascuno, e la metrica di distanza con cui misurare la vicinanza, che può essere il coseno o la distanza euclidea. A ogni vettore si possono associare dei metadati, cioè informazioni aggiuntive come la data o la fonte del documento, utili per filtrare i risultati: fino a 50 chiavi di metadati per vettore.

Il servizio è serverless, proprio come già succede con altri database serverless di AWS. "Senza server" non vuol dire che i server non esistano, ma che non è chi usa il servizio a doverli scegliere, dimensionare o aggiornare: se ne occupa AWS. Non c'è un cluster da tenere acceso e da pagare a ore: si paga per lo spazio occupato dai vettori e per le operazioni di scrittura e di interrogazione effettivamente fatte.

Il vantaggio che AWS mette in primo piano è il costo. La stima ufficiale parla di una riduzione fino al 90% del costo totale per caricare, conservare e interrogare i vettori rispetto a soluzioni di database vettoriale dedicate. È un dato dichiarato dal fornitore e, come sempre, il risparmio reale dipende da come si usa il servizio; ma indica la direzione: rendere la ricerca per similarità un'opzione economica anche per archivi molto grandi.

Quanto scala e con quali limiti

La disponibilità generale arriva con numeri più alti rispetto all'anteprima. Ogni indice può contenere fino a 2 miliardi di vettori, quaranta volte il limite di 50 milioni della fase di prova, e ogni vector bucket può ospitare fino a 10.000 indici. Sono cifre che spostano il servizio dalla dimostrazione all'uso in produzione su grandi collezioni di documenti.

Sul fronte dei tempi di risposta, AWS indica che le interrogazioni poco frequenti tornano un risultato in meno di un secondo, mentre quelle frequenti scendono intorno ai 100 millisecondi o meno. Ogni interrogazione può restituire fino a 100 risultati (erano 30 in anteprima), e in scrittura si arriva fino a 1.000 vettori al secondo quando si aggiornano gli indici un vettore alla volta.

Vale la pena essere onesti sul rovescio della medaglia. S3 Vectors è pensato per costare poco e reggere volumi enormi, non per essere lo strumento più rapido in assoluto: un centinaio di millisecondi va benissimo per un archivio di documenti, meno per scenari che richiedono risposte in pochi millisecondi su traffico molto intenso. Non a caso AWS lo presenta anche in coppia con OpenSearch, il suo motore di ricerca: si possono tenere i vettori usati di rado, e più economici, dentro S3 Vectors, spostando su OpenSearch solo quelli che richiedono le prestazioni più alte.

Le integrazioni

Con la disponibilità generale diventano stabili anche alcune integrazioni utili. S3 Vectors si collega alle Amazon Bedrock Knowledge Bases, il servizio con cui AWS costruisce applicazioni RAG: si può usare S3 Vectors come archivio dei vettori per abbassare il costo di un assistente che risponde attingendo a una base documentale. È disponibile l'integrazione con Amazon OpenSearch, per l'architettura a due livelli descritta sopra. Ci sono poi il supporto a CloudFormation per creare le risorse in modo automatico e ripetibile, PrivateLink per la connessione su rete privata, l'assegnazione di una chiave di cifratura dedicata per singolo indice e i tag per il controllo degli accessi e la ripartizione dei costi.

Alla data dell'annuncio il servizio è attivo in 14 regioni AWS, contro le 5 dell'anteprima, comprese Irlanda, Londra, Parigi, Francoforte e Stoccolma in Europa.

Quando ha senso

S3 Vectors è una buona opzione quando i vettori sono tanti, le interrogazioni non sono continue e il costo conta più della latenza minima: archivi di documentazione, basi di conoscenza per assistenti interni, ricerca semantica su cataloghi. In questi casi evita di dover installare, aggiornare e pagare un database vettoriale a parte, e tiene i vettori vicino ai dati che spesso sono già su S3.

Il ragionamento opposto vale altrettanto. Se un'applicazione ha bisogno di risposte nell'ordine dei pochi millisecondi su un flusso costante di richieste, o di funzioni avanzate offerte da un motore specializzato, un database vettoriale dedicato - o l'accoppiata con OpenSearch - resta più adatto. Come sempre, la scelta dipende dai requisiti concreti di volume, frequenza e velocità, non dalla novità in sé.

::cta{title="Vuoi costruire un assistente AI che conosce i documenti della tua azienda?" text="Progettiamo pipeline RAG su misura, dalla scelta dell'archivio vettoriale all'integrazione nei tuoi applicativi Laravel e Vue, con attenzione a costi e sicurezza dei dati." button="Parliamone →"}

Fonti

La regola del backup 3-2-1 spiegata (e perché funziona)

Alessandro Corbelli — Thu, 11 Dec 2025 00:00:00 GMT

Prima o poi capita a tutti: un disco che smette di girare, un file cancellato per sbaglio, un telefono caduto in acqua, un'azienda bloccata da un attacco informatico. In quei momenti la domanda è sempre la stessa: «C'è una copia da qualche parte?». La regola 3-2-1 è la risposta più semplice e collaudata a questa domanda. Non è un prodotto né una tecnologia: è un modo di ragionare sui backup che vale per un fotografo con le sue foto quanto per un'azienda con i suoi gestionali.

Il punto di partenza è un'idea scomoda ma sana: prima o poi qualcosa andrà perso. Non è pessimismo, è statistica. I dischi si guastano, le persone sbagliano, i programmi hanno difetti, i ladri esistono. Un backup non serve a evitare che succeda: serve a fare in modo che, quando succede, non sia un disastro.

Cosa dice la regola 3-2-1

La regola si riassume in tre numeri.

3 copie dei dati. L'originale più altre due copie. Non basta «avere un backup»: ne servono almeno due, oltre ai dati che si usano ogni giorno.
2 supporti diversi. Le copie non vanno tenute tutte sullo stesso tipo di dispositivo. Per esempio: il disco del computer e un disco esterno, oppure un disco locale e un servizio in cloud.
1 copia fuori sede. Almeno una copia deve stare in un luogo fisicamente diverso: un altro edificio, un data center, il cloud. Lontano dai rischi che minacciano l'originale.

Detta così sembra ovvia. Il valore sta nel perché ognuno di quei numeri è lì.

Perché tre copie e non una

Un backup solo, tenuto accanto all'originale, protegge da pochissime cose. Se cancello un file per errore e me ne accorgo subito, va bene. Ma se il backup è sullo stesso disco dell'originale, un guasto del disco porta via entrambi in una volta sola. Se è nella stessa stanza, un furto o un allagamento fanno lo stesso.

Tre copie servono a rendere improbabile che un singolo evento le colpisca tutte. È lo stesso principio per cui non si tengono tutti i contanti nello stesso posto. Più le copie sono indipendenti tra loro - è quella che i tecnici chiamano ridondanza - meno probabile è perderle insieme.

::cta{variant="inline" title="Sai davvero se i tuoi backup si ripristinano, o lo speri soltanto?" text="Verifichiamo la tua strategia di backup attuale: quante copie, su quali supporti, e se i ripristini sono mai stati testati davvero." button="Chiedi una verifica →"}

Perché due supporti diversi

Ogni tipo di supporto ha i suoi punti deboli. Un disco meccanico si può rompere per usura. Una chiavetta USB si può smarrire. Un servizio online può avere un disservizio o un problema con l'account. Usare due tipi diversi di supporto evita che lo stesso difetto colpisca tutte le copie.

Un esempio classico: una copia su un disco esterno in ufficio e una copia in un servizio cloud. I due supporti non condividono quasi nessun rischio. Il fulmine che frigge l'elettronica in ufficio non tocca il cloud; il problema di connessione che blocca il cloud non impedisce di leggere il disco esterno.

Perché una copia fuori sede

Le prime due regole proteggono dai guasti. La terza protegge dai disastri che colpiscono un intero luogo: un incendio, un allagamento, un furto, ma anche un attacco informatico che cifra o cancella tutto quello che riesce a raggiungere in rete.

Il «fuori sede» (in inglese offsite) significa proprio questo: una copia che non si trova nello stesso posto degli altri dati e, idealmente, non è raggiungibile con le stesse credenziali, un requisito che rientra a pieno titolo tra le misure di sicurezza richieste anche dal GDPR sul lato infrastrutturale. Se un incendio distrugge l'ufficio, la copia nel data center dall'altra parte del Paese è ancora lì. Se un attacco riesce a entrare nei sistemi, una copia isolata e non modificabile resta l'ultima difesa, sullo stesso principio delle chiavi di cifratura che nemmeno il fornitore cloud può leggere senza il consenso del cliente.

Il backup che nessuno testa

C'è un errore che si ripete spesso: fare backup per anni e non provare mai a rimetterli in funzione. Un backup che non è mai stato ripristinato non è un backup: è una speranza.

I motivi per cui un ripristino può fallire sono tanti e banali. Il file di backup è corrotto. La procedura, magari pianificata con un timer, salvava la cartella sbagliata. La password per aprire l'archivio cifrato è andata persa. Il formato non è più leggibile. Tutte cose che si scoprono solo provando - e il momento peggiore per scoprirle è durante un'emergenza vera.

Per questo il test del ripristino (in inglese restore) è parte della regola, non un extra. Ripristinare ogni tanto una copia in un ambiente separato e controllare che i dati ci siano davvero è l'unico modo per sapere che il backup funziona. Se non è stato testato, non si sa se funziona: si spera. Ed è il primo requisito di ogni intervento grosso sull'infrastruttura, come l'aggiornamento di un hypervisor Proxmox a fine supporto: prima di toccare il server si verifica che il rientro esista davvero. Vale anche per le aziende soggette alla NIS2: le misure di base dell'ACN chiedono backup verificati di dati e configurazioni e, per i sistemi rilevanti, anche copie offline, come spieghiamo in NIS2 e fornitori.

RPO e RTO spiegati facile

Quando si parla di backup seri compaiono due sigle: RPO e RTO. Sembrano complicate, ma dietro ci sono due domande molto concrete.

RPO sta per Recovery Point Objective. Risponde alla domanda: «Quanti dati posso permettermi di perdere?». In termini pratici è ogni quanto si fa un backup. Se salvo una volta al giorno, nel peggiore dei casi posso perdere fino a un giorno di lavoro: tutto ciò che è cambiato dall'ultimo backup. Se è troppo, la risposta è fare backup più spesso. Il NIST, l'ente statunitense che pubblica standard tecnici, lo definisce come il punto nel tempo a cui i dati devono essere riportati dopo un'interruzione.

RTO sta per Recovery Time Objective. Risponde all'altra domanda: «Quanto tempo posso restare fermo?». È quanto può passare tra il guasto e il ritorno alla normalità. Un sito personale può stare fermo qualche ora senza grossi danni; un e-commerce nel fine settimana degli sconti no, un ragionamento non troppo diverso da quello che porta a scegliere un database ad alta disponibilità per i servizi più critici. Il NIST lo descrive come la durata complessiva entro cui i sistemi devono tornare operativi prima che l'impatto sull'attività diventi inaccettabile.

Le due sigle misurano due perdite diverse: RPO misura i dati persi, RTO il tempo perso. Definirle in anticipo aiuta a scegliere: ogni quanto fare i backup e quanto in fretta serve poterli ripristinare. Da lì discende il resto.

Da dove viene la regola

La formula «3-2-1» è stata resa popolare dal fotografo Peter Krogh a metà degli anni 2000, nel libro The DAM Book dedicato alla gestione degli archivi digitali. Krogh non ha inventato l'idea delle copie multiple e della copia fuori sede - esisteva già - ma l'ha condensata in tre numeri facili da ricordare. Da allora è diventata un riferimento comune, ripresa anche da enti pubblici che si occupano di sicurezza informatica.

Non è un dogma

La 3-2-1 è un buon punto di partenza, non un traguardo. Negli ultimi anni, con la diffusione degli attacchi ransomware - i programmi che cifrano i dati e chiedono un riscatto - si sono aggiunte varianti che insistono su due punti: avere almeno una copia immutabile o isolata dalla rete, che un attaccante non possa cancellare, e verificare che i ripristini funzionino senza errori. Sono raffinamenti, non stravolgimenti: il cuore resta quello di sempre.

Vale anche il contrario. Per i dati di casa non serve un piano aziendale: due copie su supporti diversi e una nel cloud coprono già gran parte dei rischi. La regola scala verso l'alto e verso il basso.

In sintesi

La regola 3-2-1 funziona perché attacca il problema giusto: non «come evitare i guasti», ma «come sopravvivere quando succedono». Tre copie rendono improbabile perderle tutte insieme; due supporti diversi evitano che lo stesso difetto le colpisca tutte; una copia fuori sede resiste ai disastri che cancellano un intero luogo. E niente di tutto questo vale se non si prova ogni tanto a ripristinare. Definire quanto si può perdere (RPO) e quanto si può stare fermi (RTO) trasforma una buona abitudine in un piano. Non serve essere esperti: serve solo prendere sul serio l'idea che, prima o poi, una copia servirà davvero.

::cta{title="Vuoi una strategia di backup 3-2-1 che funziona davvero?" text="Progettiamo e gestiamo backup automatici, copie fuori sede e test di ripristino periodici per i sistemi Linux e le applicazioni dei nostri clienti." button="Parliamone →"}

Fonti

Let's Encrypt: certificati validi 6 giorni e per indirizzi IP

Alessandro Corbelli — Tue, 20 Jan 2026 00:00:00 GMT

Chi gestisce un sito conosce i certificati TLS: il piccolo documento digitale che dimostra l'identità di un server e permette al browser di cifrare la connessione, quello che accende il lucchetto accanto all'indirizzo. Fino a poco tempo fa un certificato di Let's Encrypt durava 90 giorni. Dal 15 gennaio 2026 l'autorità mette a disposizione di tutti due novità: certificati che scadono dopo poco più di sei giorni, e certificati che coprono un indirizzo IP invece di un nome a dominio. Per chi naviga non cambia nulla. Per chi amministra server è un segnale chiaro sulla direzione presa dal web: la vita dei certificati si accorcia, proprio mentre cresce la quota di traffico già protetta da crittografia post-quantum, e l'automazione diventa l'unico modo sensato di gestirli.

La notizia in breve

Let's Encrypt è un'Autorità di Certificazione (in inglese Certificate Authority, o CA): l'ente che emette i certificati, cioè che garantisce l'identità di un sito. È gratuita e da anni è la più usata al mondo, perché ha reso l'emissione dei certificati un'operazione automatica invece di un acquisto manuale.

Le due funzioni annunciate erano in prova da mesi con accesso limitato. Dal 15 gennaio 2026 sono passate a disponibilità generale, cioè sono aperte a chiunque:

Certificati a vita breve, validi 160 ore, poco più di sei giorni.
Certificati per indirizzi IP, sia IPv4 sia IPv6.

Restano due opzioni facoltative. Il certificato standard di Let's Encrypt continua a durare 90 giorni: chi non fa nulla non nota alcuna differenza. Chi vuole i certificati brevi o quelli per IP deve richiederli in modo esplicito.

Sei giorni invece di novanta

Per ottenere un certificato a vita breve non basta chiederlo e basta: il programma che dialoga con l'autorità deve saper indicare un profilo, una sorta di modello di certificato. Il profilo si chiama shortlived. È identico a quello usato normalmente per i siti web, con un'unica differenza: il certificato dura circa sei giorni invece di tre mesi.

Quella durata così corta non è casuale. Esiste una regola di settore, le Baseline Requirements, che definisce una categoria a parte, i certificati a vita breve. Un certificato che rientra in questa categoria ha un privilegio: non deve contenere alcuna informazione sulla revoca. Per capire perché è un vantaggio serve fare un passo indietro e spiegare cos'è la revoca.

::cta{variant="inline" title="I certificati del tuo server si rinnovano ancora a mano?" text="Verifichiamo il client ACME in uso e la sua compatibilità con i profili a vita breve, prima che diventino lo standard." button="Chiedi una verifica →"}

Perché così brevi: il problema della revoca

Ogni certificato è legato a una chiave privata, un file segreto che deve restare sul server e non uscire mai. Se quella chiave viene rubata - per un attacco, una configurazione sbagliata, un backup finito nel posto sbagliato - chi la possiede può fingersi il sito legittimo fino a quando il certificato resta valido. Questo intervallo si chiama finestra di compromissione: più lungo è il certificato, più a lungo un furto può fare danni senza che nessuno se ne accorga.

In teoria esiste un rimedio: la revoca, cioè dichiarare un certificato non più valido prima della sua scadenza naturale. Nella pratica la revoca funziona male. I browser non sempre controllano se un certificato è stato revocato, e i meccanismi pensati per avvisarli sono lenti o poco affidabili. Il risultato è che, anche dopo una revoca, molti visitatori continuano a fidarsi di un certificato che non dovrebbero più accettare.

I certificati a vita breve aggirano il problema alla radice. Se un certificato dura sei giorni, la finestra di compromissione è di sei giorni al massimo: dopo, scade da solo. Non serve revocarlo, perché sparisce comunque in fretta. È un modo meno elegante ma più solido di ottenere lo stesso risultato. È anche la ragione per cui Let's Encrypt ha detto di voler portare la durata standard dagli attuali 90 giorni a 45 nei prossimi anni, lo stesso percorso di riduzione fissato a livello di settore con il traguardo dei 47 giorni approvato dal CA/Browser Forum: la direzione è ridurre il tempo in cui un errore può fare danni.

La fine di OCSP

Questa scelta si lega a un cambiamento avvenuto pochi mesi prima. Per anni il modo principale di controllare se un certificato era stato revocato si chiamava OCSP (Online Certificate Status Protocol): a ogni visita, il software poteva chiedere in tempo reale all'autorità "questo certificato è ancora valido?".

Il 6 agosto 2025 Let's Encrypt ha spento il suo servizio OCSP. Le ragioni sono due. La prima è la privacy: ogni interrogazione OCSP rivelava all'autorità quale sito una persona stava visitando, e da quale indirizzo. La seconda è la scala: al suo apice il servizio gestiva circa 340 miliardi di richieste al mese, un'infrastruttura enorme da mantenere. Al posto di OCSP resta un solo meccanismo, le CRL (Certificate Revocation List), cioè elenchi di certificati revocati pubblicati periodicamente.

In un mondo in cui il controllo in tempo reale non esiste più, i certificati a vita breve hanno ancora più senso: non hanno bisogno di essere revocati, quindi non dipendono da un sistema di revoca che ormai è volutamente più leggero.

Certificati per un indirizzo IP

La seconda novità risolve un problema diverso. Di solito un certificato copre un nome a dominio, per esempio esempio.it. Ma non tutto ha un dominio: ci sono servizi raggiungibili solo tramite il loro indirizzo numerico, come 203.0.113.10 o un indirizzo IPv6. Fino a ieri, per quei casi, un certificato pubblicamente riconosciuto non era ottenibile e restava solo la strada dei certificati "fatti in casa", che i browser segnalano come non attendibili.

Ora Let's Encrypt può emettere certificati che coprono direttamente un indirizzo IP, sia IPv4 sia IPv6. Serve a proteggere connessioni verso servizi che non hanno un nome a dominio: endpoint di infrastruttura, apparati di rete, ambienti tecnici in cui l'indirizzo numerico è tutto ciò che c'è.

Ci sono due vincoli, entrambi legati alla natura degli indirizzi IP. Il primo: un certificato per un indirizzo IP deve essere a vita breve, quindi passa per il profilo shortlived. Il motivo è che un indirizzo IP cambia proprietario molto più spesso di un dominio, e verificarlo di continuo è importante per evitare che finisca a chi non dovrebbe. Il secondo: per dimostrare di controllare l'indirizzo si possono usare solo due metodi di verifica, quello basato su una risposta HTTP e quello basato sulla connessione TLS. Il metodo via DNS, comodo per i domini, qui non è utilizzabile, perché un indirizzo IP non ha voci DNS da modificare.

Cosa serve per usarli

Il requisito pratico è uno solo: il programma che gestisce i certificati - il client ACME, dove ACME è il protocollo standard con cui un server ottiene e rinnova i certificati da solo - deve saper richiedere un profilo. È una funzione recente, quindi conviene usare una versione aggiornata del proprio client. I client più diffusi, tra cui certbot, hanno già istruzioni dedicate per selezionare il profilo shortlived.

Il resto è automazione, ed è la parte importante. Un certificato che dura sei giorni va rinnovato ogni pochi giorni: a mano è impensabile. Ma per un sistema automatico rinnovare ogni giorno o ogni tre giorni non è più faticoso che rinnovare ogni due mesi. Chi già affida i rinnovi a un client ACME che gira da solo non deve cambiare quasi nulla; chi rinnova ancora a mano, con questi certificati, semplicemente non può farlo.

In sintesi

Let's Encrypt ha aperto a tutti due opzioni facoltative: certificati validi poco più di sei giorni e certificati per indirizzi IP. I primi accorciano al minimo il tempo in cui un certificato compromesso può fare danni, in un mondo in cui la revoca - e il vecchio servizio OCSP, ormai spento - non offrivano garanzie affidabili. I secondi portano i certificati pubblici anche dove non c'è un dominio. Il filo comune è sempre lo stesso: certificati più brevi, controlli più frequenti, e un'automazione solida come unica condizione per starci dietro, mentre nello stesso periodo anche lo scambio di chiavi post-quantum abilitato di default in Chrome sposta più in generale l'asticella della sicurezza in TLS.

::cta{title="Vuoi automatizzare davvero il rinnovo dei tuoi certificati TLS?" text="Configuriamo client ACME, rinnovo automatico e monitoraggio delle scadenze sui tuoi server, dai domini classici agli indirizzi IP esposti senza nome a dominio." button="Parliamone →"}

Fonti

L'Encrypted Client Hello di TLS diventa standard (RFC 9849)

Alessandro Corbelli — Tue, 10 Mar 2026 00:00:00 GMT

Per anni chi osserva il traffico di rete ha potuto leggere un dettaglio che molti credevano già protetto: il nome del sito verso cui ci si sta collegando. La connessione era cifrata, il lucchetto nel browser chiuso, eppure quell'informazione viaggiava in chiaro. A marzo 2026 la IETF, l'organismo che scrive gli standard di Internet, ha pubblicato la RFC 9849, intitolata "TLS Encrypted Client Hello". Il documento chiude proprio quella falla. Vale la pena capire cosa nasconde davvero e perché riguarda chi progetta reverse proxy, CDN e sistemi di filtraggio.

Il dettaglio che restava scoperto

Quando un browser apre una connessione sicura verso un sito, i due lati si scambiano prima alcuni messaggi per accordarsi su chiavi e parametri. Questa fase si chiama handshake. Con la versione più recente del protocollo, TLS 1.3, quasi tutto l'handshake è cifrato: un osservatore esterno vede passare byte incomprensibili.

Resta però un'eccezione importante. Nel primissimo messaggio, il ClientHello, il browser deve dire a quale sito vuole collegarsi. Serve perché su un singolo indirizzo IP possono vivere centinaia di siti diversi, e il server deve sapere quale certificato presentare. Questa indicazione si chiama SNI, cioè Server Name Indication, e finora viaggiava in chiaro. In pratica, chiunque si trovi lungo il percorso della connessione (il gestore della rete, un provider, un firewall aziendale) poteva leggere esempio.it anche senza vedere nulla del contenuto. Come spiega la stessa RFC, l'SNI in chiaro è forse l'informazione più sensibile rimasta scoperta in TLS 1.3.

Cos'è l'Encrypted Client Hello

L'Encrypted Client Hello, abbreviato in ECH, è un'estensione di TLS 1.3 che cifra il ClientHello, e con esso l'SNI. Non solo il nome del sito: protegge anche altri campi che potrebbero far intuire la destinazione, come l'elenco dei protocolli applicativi che il client è disposto a usare (l'estensione ALPN).

L'idea non è nuova. Nasce da anni di lavoro su una proposta chiamata ESNI, che cifrava soltanto il nome del sito. Con il tempo ci si è accorti che nascondere un solo campo non bastava: altri dettagli del ClientHello potevano tradire la destinazione. La proposta è stata quindi riprogettata per cifrare l'intero messaggio, ed è questa la versione arrivata a standard con la RFC 9849. Il documento ha lo stato di Proposed Standard, il primo gradino della via ufficiale agli standard IETF: è stabile e pubblicato, non è più una bozza.

::cta{variant="inline" title="Il tuo reverse proxy smista il traffico guardando solo l'SNI?" text="Controlliamo se la tua configurazione regge quando quel nome smette di essere leggibile." button="Chiedi una verifica →"}

Come funziona, senza tecnicismi

Il meccanismo si basa su due ClientHello annidati. Ce n'è uno "interno", quello vero, che contiene l'SNI reale e viene cifrato. E ce n'è uno "esterno", visibile, che contiene un nome pubblico e innocuo, condiviso da molti siti ospitati dallo stesso operatore.

Chi guarda dall'esterno vede solo il nome pubblico. Il server che riceve la connessione, chiamato client-facing server, decifra il ClientHello interno e capisce quale sito è stato davvero richiesto, poi instrada la connessione di conseguenza. Se molti siti condividono lo stesso nome pubblico, per un osservatore diventano indistinguibili: è quello che la specifica chiama insieme di anonimato.

Per cifrare il ClientHello interno serve la chiave pubblica del server. Il client la ottiene tramite il DNS, il sistema che traduce i nomi in indirizzi. Un secondo documento pubblicato insieme al primo, la RFC 9848, definisce come pubblicare questa configurazione (l'ECHConfig) nei record DNS di tipo SVCB e HTTPS, tramite un parametro dedicato chiamato ech. La cifratura vera e propria usa HPKE, uno schema crittografico standard pensato proprio per cifrare dati verso una chiave pubblica.

Sono previsti anche i casi in cui qualcosa non torna. Se il server non riesce a decifrare, ad esempio perché il client ha usato una configurazione ormai vecchia, può rispondere con quella aggiornata e la connessione viene ritentata. E c'è un accorgimento chiamato GREASE: i client possono inviare dati ECH finti anche quando non li usano davvero, così chi adotta ECH non si distingue dagli altri e gli apparati di rete non si "abituano" ad aspettarsi un formato fisso.

Cosa cambia per reverse proxy, CDN e filtri

Qui sta la parte pratica, quella che tocca chi gestisce infrastrutture.

Molti reverse proxy instradano le connessioni leggendo l'SNI senza nemmeno decifrare il traffico: guardano il nome, scelgono il backend giusto e passano oltre. Con ECH questo non funziona più, perché l'SNI visibile è il nome pubblico condiviso. Per smistare in base al sito reale, il server esposto deve diventare a tutti gli effetti il client-facing server: decifrare l'ECH e leggere l'SNI interno. Chi ha costruito lo smistamento sul solo SNI in chiaro dovrà rivedere l'architettura.

Per le CDN il modello calza bene. Una CDN ospita già molti clienti dietro gli stessi indirizzi: può presentare un nome pubblico comune, fare da client-facing server e instradare verso il sito corretto dopo aver decifrato l'ECH. È anche il contesto in cui l'insieme di anonimato è più ampio, e quindi la protezione più efficace.

Discorso diverso per i filtri basati su SNI. Firewall, sistemi di controllo parentale, filtri aziendali e strumenti di blocco a livello di rete spesso decidono cosa passare leggendo proprio il nome del sito nell'SNI. Con ECH quel nome non è più visibile: un filtro che si basa solo sull'SNI perde il suo appiglio. È il rovescio della medaglia della privacy, ed è bene saperlo per tempo, senza illudersi che nulla cambi.

A che punto siamo

ECH è uno standard pubblicato, ma il suo effetto dipende da quanto viene adottato dalle due parti. Sul fronte client, alcuni browser hanno già sperimentato ECH da tempo. Sul fronte server, diverse CDN lo offrono e le librerie crittografiche stanno aggiungendo il supporto: pochi giorni dopo la pubblicazione, il progetto OpenSSL ha annunciato il supporto a ECH così come descritto dalla RFC 9849.

Restano alcuni prerequisiti da tenere a mente. ECH richiede TLS 1.3, quindi le connessioni che si fermano a versioni precedenti restano scoperte. E dipende dal DNS per recuperare la configurazione: se le richieste DNS viaggiano in chiaro, un osservatore può comunque intuire la destinazione o manomettere la configurazione. Per questo ECH ha senso soprattutto insieme a un DNS cifrato, come DNS over HTTPS o DNS over TLS.

In sintesi, la RFC 9849 mette al riparo l'ultimo pezzo di handshake che restava leggibile. Non è una rivoluzione improvvisa: è un tassello che diventa ufficiale dopo anni di prove sul campo, e che nei prossimi mesi cambierà silenziosamente il modo in cui reverse proxy, CDN e filtri di rete vedono, o non vedono più, il nome dei siti.

::cta{title="Vuoi preparare la tua infrastruttura a ECH?" text="Revisioniamo reverse proxy, CDN e regole di filtraggio per continuare a instradare il traffico correttamente anche quando l'SNI è cifrato." button="Parliamone →"}

Fonti

S3 disabilita SSE-C di default sui nuovi bucket: cosa cambia e cosa controllare

Alessandro Corbelli — Thu, 16 Apr 2026 00:00:00 GMT

Un valore predefinito, quando cambia, può passare inosservato finché qualcosa smette di funzionare. È il caso di un aggiornamento che Amazon Web Services (AWS) ha iniziato a distribuire ad aprile 2026 sul suo servizio di archiviazione S3: la cifratura con chiave fornita dal cliente, nota come SSE-C, non è più attiva per impostazione predefinita sui nuovi bucket. Un bucket è il contenitore di base in cui S3 conserva i file, che nel gergo del servizio si chiamano oggetti, lo stesso concetto ripreso anche dai più recenti vector bucket per la ricerca semantica. Per la maggior parte di chi usa S3 non cambia nulla. Ma chi ha automazioni o applicazioni che si appoggiano a SSE-C ha un buon motivo per controllare le proprie configurazioni prima che il cambiamento arrivi ovunque.

Cos'è SSE-C, e dove si colloca

S3 offre la cifratura lato server (server-side encryption): i dati vengono cifrati automaticamente quando vengono scritti su disco e decifrati alla lettura, senza che l'applicazione debba occuparsene. La differenza tra le varianti sta in una domanda sola: chi possiede e gestisce la chiave.

SSE-S3 - la chiave la genera e la gestisce AWS. È l'opzione più semplice e quella predefinita.
SSE-KMS - la chiave vive in AWS Key Management Service (KMS), il servizio dedicato alla gestione delle chiavi. In cambio si ottengono controlli d'accesso fini tramite le policy IAM (il sistema dei permessi di AWS) e una traccia di ogni uso della chiave in CloudTrail, il registro delle attività dell'account, un livello di tracciabilità che si allinea bene ai principi di accountability richiesti anche dal GDPR.
SSE-C - la chiave la fornisce il cliente, e la invia a S3 a ogni richiesta di scrittura e di lettura. S3 la usa per cifrare o decifrare al volo, ma non la conserva da nessuna parte. Il controllo della chiave resta interamente in mano a chi la produce.

Proprio quest'ultimo punto è il tratto distintivo di SSE-C: siccome S3 non memorizza la chiave, senza quella chiave i dati non si leggono, nemmeno lato AWS. È una garanzia forte, ma anche un vincolo operativo pesante.

Cosa cambia, in concreto

L'aggiornamento riguarda i bucket "general purpose", cioè quelli standard usati nella stragrande maggioranza dei casi.

Nuovi bucket: SSE-C è disabilitato di default. Ogni bucket creato dopo il rollout parte con SSE-C bloccato.
Bucket esistenti: dipende dall'account. Se l'account non contiene alcun oggetto cifrato con SSE-C, S3 ha disattivato SSE-C anche sui bucket già presenti. Se invece anche un solo bucket dell'account contiene oggetti SSE-C, S3 non ha toccato nessuna configurazione di quell'account, per non rompere ciò che è in uso.
Tempi e regioni: la distribuzione è partita ad aprile 2026 e ha raggiunto 37 regioni AWS, comprese le regioni AWS China e AWS GovCloud (US). Fanno eccezione, almeno per ora, le regioni Middle East (Bahrain) e Middle East (UAE), dove il nuovo default non si applica. Il cambiamento non è arrivato a sorpresa: AWS aveva pubblicato un preavviso a novembre 2025.

Vale la pena sottolineare che si tratta di un cambiamento reale e già in corso, non di una beta né di una proposta: il default è cambiato davvero.

::cta{variant="inline" title="Sai quali dei tuoi bucket S3 dipendono ancora da SSE-C?" text="Controlliamo la configurazione di cifratura dei tuoi bucket e verifichiamo se il nuovo default AWS può bloccare scritture in produzione." button="Chiedi una verifica →"}

Perché AWS lo fa

La motivazione dichiarata è che SSE-C, oggi, offre pochi vantaggi rispetto alle alternative. Poiché S3 non conserva la chiave, questa va rispedita a ogni singola richiesta: condividere l'accesso ai dati con altri utenti o servizi diventa scomodo, e manca la tracciabilità che KMS offre in modo naturale con IAM e CloudTrail. Da quando esiste KMS - che permette di creare, possedere e gestire chiavi con controlli d'accesso e registrazione degli usi - il beneficio pratico di SSE-C si è di fatto assottigliato, e la maggior parte dei carichi di lavoro moderni ha smesso di usarlo.

Il cambio di default va quindi letto come una scelta di sicurezza per impostazione predefinita: disattivare una funzione poco usata riduce la superficie su cui possono nascere errori di configurazione, lasciando comunque a chi ne ha davvero bisogno la possibilità di riattivarla.

Cosa succede a chi usa ancora SSE-C

Su un bucket dove SSE-C è bloccato, ogni richiesta che chiede esplicitamente SSE-C viene rifiutata con un errore HTTP 403 AccessDenied, cioè un "accesso negato". Riguarda i caricamenti (PutObject), le copie (CopyObject), le PostObject, i caricamenti multiparte e le repliche tra bucket.

Per un'applicazione che si aspetta di scrivere con SSE-C, questo si traduce in un errore improvviso e potenzialmente diffuso. Da qui l'importanza di accorgersene in anticipo, quando è una verifica pianificata e non un incidente in produzione.

Cosa conviene verificare prima

Conviene procedere per due domande, in ordine.

Prima domanda: si usa SSE-C da qualche parte? Non sempre è ovvio, soprattutto in automazioni scritte tempo fa. Per scoprirlo si può esaminare in CloudTrail quali metodi di cifratura compaiono nelle richieste verso S3, e usare i report di S3 Inventory per elencare gli oggetti già cifrati con SSE-C. Per controllare la configurazione di cifratura di un singolo bucket si può interrogare l'API con un comando di sola lettura:

aws s3api get-bucket-encryption --bucket nome-del-bucket

Seconda domanda: se SSE-C serve davvero, come si riattiva? Su un bucket nuovo va abilitato in modo esplicito chiamando l'API PutBucketEncryption (serve il permesso s3:PutEncryptionConfiguration), dopodiché le applicazioni continuano a includere le consuete intestazioni SSE-C nelle loro richieste. La stessa API gestisce anche l'impostazione a livello di bucket introdotta per l'occasione, che consente di bloccare o sbloccare SSE-C in modo controllato, bucket per bucket.

Per chi scopre di dipendere ancora da SSE-C, il momento è buono anche per una domanda più a monte: quel dato ha davvero bisogno di una chiave gestita fuori da AWS, o SSE-KMS coprirebbe l'esigenza offrendo in più tracciabilità e controlli d'accesso? La risposta cambia da caso a caso, ma vale la pena porsela ora, con calma, invece che davanti a un caricamento fallito.

In sintesi

Il messaggio operativo è semplice. Il cambiamento è già in distribuzione, era stato annunciato con mesi di anticipo e per la maggior parte degli utenti è trasparente, oltre a spingere verso un default più prudente. Per chi ha investito su SSE-C - spesso in pipeline o script che nessuno guarda da tempo - il compito è chiaro: individuare dove SSE-C è in uso, decidere se ha ancora senso o se conviene passare a SSE-KMS, e nel caso riabilitarlo esplicitamente sui bucket giusti prima che il default aggiornato faccia fallire una scrittura, esattamente come si testa un ripristino prima che serva davvero.

::cta{title="Vuoi mettere in sicurezza l'infrastruttura AWS della tua azienda?" text="Gestiamo configurazioni cloud su AWS: cifratura, permessi IAM e monitoraggio, con un audit prima di ogni cambio di default che potrebbe rompere qualcosa." button="Parliamone →"}

Fonti

AWS Graviton5 e le nuove istanze EC2: perché i chip ARM nel cloud contano

Alessandro Corbelli — Wed, 10 Jun 2026 00:00:00 GMT

Il 10 giugno 2026 AWS ha reso disponibili a tutti due nuovi tipi di server virtuali nel suo cloud: le istanze EC2 chiamate M9g e M9gd. La novità sotto il cofano è il processore che le muove, Graviton5, presentato in anteprima a fine 2025 e ora arrivato alla disponibilità generale. È l'occasione per spiegare, senza tecnicismi inutili, una cosa che ormai riguarda chiunque affitti server nel cloud: perché i processori ARM stanno prendendo piede e cosa conviene controllare prima di spostarci sopra i propri programmi.

Cosa significano "ARM" e "istanza", in breve

Un'istanza EC2 è semplicemente un server virtuale che si affitta a ore: gli si dà una potenza di calcolo e della memoria, ci si installa sopra Linux e ci girano i propri servizi. Il "motore" di quel server è il processore, cioè il chip che esegue i calcoli.

Per anni i processori dei server hanno seguito quasi tutti la stessa impostazione di fondo, quella dei chip Intel e AMD, nota come x86. ARM è un modo diverso di costruire i processori: è la stessa famiglia di architettura che si trova negli smartphone e nei computer portatili moderni, nata con un'attenzione forte al consumo di energia. La differenza tecnica non interessa all'utente finale; interessa la conseguenza pratica: a parità di lavoro svolto, un chip ARM tende a consumare meno corrente e a costare meno da far girare.

Graviton è la linea di processori ARM che AWS progetta per conto proprio, invece di comprarli da altri. Non è una novità assoluta: esiste da alcuni anni ed è arrivata alla quinta generazione. Graviton5 è appunto l'ultimo passo.

Perché contano i chip ARM nel cloud

Il punto non è il tifo per una tecnologia o l'altra. Il punto è il conto della spesa e il conto dei consumi.

Nel cloud si paga il tempo di calcolo. Se lo stesso servizio gira su un chip che rende di più a parità di corrente assorbita, il fornitore può proporre quel calcolo a un prezzo inferiore. Storicamente le istanze ARM di AWS sono state offerte a listino più basso rispetto alle equivalenti x86, ed è questa combinazione - prestazioni per euro speso e consumi contenuti - la ragione per cui tante aziende hanno cominciato a guardarle.

C'è poi il lato ambientale ed economico dei data center. Un processore che fa lo stesso lavoro con meno energia significa meno calore da smaltire e meno corrente in bolletta: due voci pesanti per chi gestisce migliaia di server.

::cta{variant="inline" title="Il tuo attuale piano AWS pesa più del dovuto sul budget?" text="Verifichiamo se i tuoi carichi Linux sono compatibili con le istanze ARM e quanto risparmieresti passando a Graviton." button="Chiedi una verifica →"}

Cosa cambia con Graviton5

AWS descrive Graviton5 come il processore più potente ed efficiente che abbia mai costruito. I numeri dichiarati, da leggere sempre con il "fino a" davanti perché sono valori di punta e non medie garantite, sono questi:

fino al 25% di prestazioni di calcolo in più rispetto alla generazione precedente, Graviton4;
guardando a carichi specifici, fino al 35% più veloce per le applicazioni web, fino al 35% per l'inferenza dei modelli di intelligenza artificiale (cioè l'uso di un modello già addestrato) e fino al 30% per i database;
192 core per processore (i core sono le unità di calcolo indipendenti: più core significano più cose in parallelo);
cinque volte più cache L3 rispetto alla generazione precedente. La cache è una piccola memoria molto veloce accanto al processore: più è ampia, meno il chip deve fermarsi ad aspettare i dati;
fino al 33% di latenza in meno tra i core, cioè i core si scambiano informazioni più in fretta;
memoria DDR5-8800, tra le più rapide disponibili oggi nel cloud.

Sono cifre fornite dal produttore. Restano un'indicazione utile della direzione, ma il valore reale dipende sempre dal carico specifico.

Le due istanze: M9g e M9gd

Le nuove istanze arrivano in due varianti che condividono lo stesso processore.

M9g è la versione generica, adatta alla maggior parte dei servizi: siti, applicazioni web, backend, database di dimensioni normali. Le taglie vanno da 1 vCPU con 4 GiB di memoria fino a 192 vCPU con 768 GiB. Un vCPU è la fetta di processore assegnata all'istanza; qui il rapporto è di un vCPU ogni quattro GiB di memoria.

M9gd aggiunge dello spazio su disco NVMe locale, cioè memoria a stato solido molto veloce fisicamente collegata al server, fino a 11,4 TB. Serve a chi ha bisogno di leggere e scrivere dati in locale a grande velocità - per esempio certe basi di dati o sistemi di cache - senza passare da un disco di rete. AWS indica per questa variante anche un aumento delle operazioni di lettura e scrittura al secondo rispetto al passato.

Le istanze sono acquistabili nei modi consueti di AWS (a consumo, con i piani di risparmio, in modalità Spot per i carichi interrompibili, e nelle forme dedicate) e, al lancio, sono disponibili in alcune regioni: Stati Uniti (Virginia del Nord, Ohio, Oregon) ed Europa (Francoforte). La copertura è quindi ancora parziale, come normale per una novità appena uscita.

Sul fronte sicurezza, AWS le costruisce sulla sesta generazione del suo sistema Nitro e introduce un componente chiamato Nitro Isolation Engine, che rafforza l'isolamento tra le macchine virtuali che condividono lo stesso hardware fisico.

Cosa valutare prima di migrarci i propri carichi Linux

Passare da x86 ad ARM non è un semplice cambio di taglia. È un cambio di architettura del processore, e questo ha conseguenze concrete. Ecco i punti da controllare, in ordine di importanza.

Il software deve esistere in versione ARM. Un programma compilato per x86 non gira su ARM così com'è. La buona notizia è che le distribuzioni Linux più diffuse (Debian, Ubuntu, Amazon Linux, RHEL e derivate) offrono da tempo versioni per ARM a 64 bit, indicata come arm64 o aarch64. La maggior parte dei linguaggi interpretati - PHP, Python, Node.js, Java - funziona senza riscrivere nulla.

Attenzione alle dipendenze compilate. Il problema si nasconde nei componenti "nativi": estensioni di un linguaggio, librerie di sistema, software proprietario fornito come binario già pronto. Se un pezzo esiste solo per x86, va sostituito, ricompilato o accantonato. Vale la pena censire in anticipo cosa usa il proprio stack, un lavoro più veloce se l'infrastruttura è già descritta come codice.

Le immagini dei container vanno controllate. Chi usa Docker deve verificare che le immagini siano "multi-architettura", cioè disponibili anche per linux/arm64. Molte immagini ufficiali lo sono già; quelle costruite in casa vanno ricostruite per ARM.

Provare con i propri dati, non con i numeri del listino. Le percentuali dichiarate sono valori di punta. L'unico test che conta è misurare il proprio carico reale su una piccola istanza ARM e confrontarlo con quella x86 che si usa oggi, guardando sia le prestazioni sia il costo effettivo nella propria regione.

Verificare il prezzo caso per caso. Il vantaggio economico di ARM è storicamente reale, ma non è una legge fissa: dipende dalla regione, dalla taglia e dalla forma d'acquisto. Va confermato sul preventivo, non dato per scontato.

In pratica, per molti servizi Linux moderni la migrazione ad ARM è oggi meno faticosa di quanto si tema, e il risparmio può essere concreto. Per stack più vecchi o pieni di componenti proprietari, invece, conviene procedere con calma: prima l'inventario del software, poi una prova affiancata, e solo dopo la decisione. Graviton5 rende l'opzione ARM più interessante, ma la scelta giusta resta quella misurata sul proprio caso.

::cta{title="Vuoi valutare la migrazione dei tuoi server ad ARM?" text="Ci occupiamo di gestione sistemistica su AWS e Google Cloud: censiamo lo stack, testiamo le prestazioni su Graviton e gestiamo la migrazione senza fermare il servizio." button="Parliamone →"}

Fonti

Cloudflare apre l'OAuth self-managed a tutti gli sviluppatori

Alessandro Corbelli — Thu, 18 Jun 2026 00:00:00 GMT

Chi costruisce un programma che deve "parlare" con un servizio online - per esempio un'applicazione che gestisce siti, DNS o firewall per conto di un cliente - prima o poi si scontra con una domanda pratica: come faccio a far accedere il mio software all'account di qualcun altro, in modo sicuro e senza chiedergli la password? Il 3 giugno 2026 Cloudflare, uno dei maggiori operatori di rete e CDN al mondo, ha reso disponibile a tutti i propri clienti uno strumento pensato proprio per questo: l'OAuth "self-managed", cioè la possibilità di creare da sé le proprie applicazioni OAuth. Fino a poco prima era una funzione riservata a un ristretto gruppo di partner approvati a mano; ora può usarla chiunque abbia un account.

Il punto di partenza: i token API

Per capire la notizia conviene partire da come si accede oggi alle API di Cloudflare. Un'API è l'interfaccia con cui un programma comanda un servizio senza passare dal sito: creare un record DNS, aggiungere una regola, leggere delle statistiche. Per autorizzare queste operazioni si usa in genere un token API: una lunga stringa segreta che funziona come una chiave. Chi ce l'ha può compiere le azioni che quel token permette.

I token risolvono il problema, ma hanno alcuni limiti fastidiosi quando si costruiscono integrazioni per altri. Sono spesso a lunga durata e con permessi ampi, perché è comodo generarne uno che "faccia tutto". Vanno consegnati al programma che li userà, e questo significa condividere un segreto: se finisce nel posto sbagliato, magari attraverso una dipendenza software compromessa come è successo di recente ai pacchetti npm messi in quarantena, chi lo ha in mano può agire sull'account finché il token non viene cancellato. E se un cliente vuole revocare l'accesso a una singola applicazione, districare quale token appartiene a chi non è sempre immediato. In breve: comodi per l'uso personale, poco adatti a delegare un accesso limitato a software di terzi.

Cos'è OAuth e cosa cambia

OAuth è uno standard di autorizzazione diffuso in tutto il web. È lo stesso meccanismo che c'è dietro i pulsanti "Accedi con Google" o "Collega il tuo account": invece di consegnare una password o una chiave, l'utente viene mandato sul sito del servizio, gli conferma quali permessi concedere all'applicazione e torna indietro con un'autorizzazione limitata. L'applicazione non vede mai le credenziali dell'utente; riceve solo il permesso di fare quel poco che le è stato concesso.

Rispetto a un token consegnato a mano, il modello OAuth porta tre vantaggi concreti. Il primo è il consenso esplicito: è l'utente a decidere, davanti a una schermata chiara, cosa autorizzare. Il secondo è il minimo privilegio: l'applicazione chiede solo i permessi che le servono, non le chiavi di tutto. Il terzo è la revoca pulita: l'utente può togliere l'accesso a quella singola applicazione dal proprio pannello, senza toccare il resto.

::cta{variant="inline" title="I tuoi token API circolano ancora con permessi troppo ampi?" text="Verifichiamo come le tue integrazioni accedono ai servizi esterni e dove serve un modello di autorizzazione più granulare." button="Chiedi una verifica →"}

Cosa ha annunciato Cloudflare

La novità è che ora qualsiasi cliente Cloudflare può creare e gestire in autonomia le proprie applicazioni OAuth, senza dover essere un partner selezionato. Si fa dal pannello, alla voce Manage account > OAuth clients, oppure via API per chi preferisce automatizzare. Da lì si definisce l'applicazione, si scelgono i permessi e si ottengono le credenziali necessarie a far partire il flusso di autorizzazione.

È una funzione disponibile a tutti (general availability), non una beta. Cloudflare la descrive come un'alternativa ai token API più sicura, più comoda da usare e più facile da gestire, soprattutto per gli scenari in cui un'applicazione agisce per conto di un utente.

Permessi su misura

Il cuore della cosa sono gli scope, cioè i permessi che un'applicazione può richiedere. Su Cloudflare i nomi degli scope corrispondono ai permessi che si troverebbero anche creando un token API: si può quindi scegliere in modo granulare a cosa dare accesso - per esempio la sola lettura del DNS di una zona, o la sola gestione di una certa funzione - invece di concedere tutto in blocco. L'elenco degli scope disponibili si può consultare dal pannello durante la creazione del client, oppure recuperare via API.

L'effetto pratico è che un'integrazione ben fatta chiede solo ciò che le serve. Se domani quell'applicazione viene compromessa, il danno resta confinato ai permessi concessi, non all'intero account.

Client privati e pubblici, e la schermata di consenso

Cloudflare distingue due tipi di applicazione. Un client privato può essere autorizzato solo dai membri dell'account che lo ha creato: è pensato per gli strumenti interni di un'organizzazione. Un client pubblico può invece essere autorizzato da qualsiasi utente Cloudflare: è il caso di un prodotto SaaS che offre un pulsante "collega il tuo account Cloudflare" ai propri clienti.

Per i client pubblici c'è un passaggio in più a tutela degli utenti: la verifica del dominio. Chi pubblica l'applicazione deve dimostrare di controllare il proprio dominio inserendo un record DNS di tipo TXT con un codice fornito da Cloudflare. Superata la verifica, l'applicazione ottiene un badge sulla schermata di consenso, così chi sta per autorizzarla sa con chi ha a che fare. La stessa schermata è stata rivista per mostrare in modo chiaro quale applicazione chiede l'accesso e quali permessi riceve.

Client secret e PKCE

Un dettaglio tecnico utile per chi svilupperà queste integrazioni: Cloudflare supporta il flusso OAuth 2.0 chiamato authorization code, in linea con le più recenti raccomandazioni di sicurezza per OAuth, ed esclude altri tipi meno adatti a un accesso delegato sicuro. In questo flusso, un'applicazione che gira su un server proprio può custodire un client secret, cioè una password dell'applicazione tenuta al riparo. Le applicazioni che invece girano interamente sul dispositivo dell'utente - un'app mobile, un programma desktop, una pagina web - non possono nascondere un segreto e devono usare un meccanismo chiamato PKCE, che protegge lo scambio senza bisogno di custodire una chiave. È una distinzione importante: il consiglio esplicito è di non incorporare mai il client secret nel codice che finisce sul dispositivo dell'utente.

A cosa serve

Gli scenari che si aprono sono soprattutto tre. Il primo sono i prodotti SaaS che gestiscono infrastruttura Cloudflare per conto dei clienti: ora possono offrire un vero flusso "collega il tuo account", con permessi mirati, al posto di chiedere all'utente di generare e incollare un token. Il secondo sono le piattaforme interne di sviluppo: un'azienda può costruire strumenti che agiscono sulle proprie risorse Cloudflare con autorizzazioni per singolo utente. Il terzo, più recente, riguarda gli agenti AI e i server MCP - programmi che agiscono per conto di una persona: anche loro hanno finalmente un modello di accesso delegato pensato per lo scopo, invece di doversi far consegnare un token a permessi ampi.

Perché conta

Il valore non sta in una singola funzione appariscente, ma nel togliere frizione a un problema ricorrente. Chi costruisce integrazioni può chiedere solo i permessi necessari, gli utenti vedono con chiarezza cosa stanno autorizzando e possono revocare l'accesso a una specifica applicazione con un clic. È il modello a cui gran parte del web è già abituata, esteso ora anche alle API di Cloudflare e aperto a chiunque, non più ai soli partner.

Va detto con onestà che questo non manda in pensione i token API: per gli usi personali o per gli script rapidi restano più semplici e diretti. L'OAuth self-managed brilla quando c'è di mezzo una terza parte e serve delegare un accesso limitato in modo controllato. Sotto il cofano, per rendere il servizio disponibile a tutti, Cloudflare ha aggiornato il motore OAuth su cui si appoggia (il progetto open source Ory Hydra) con una migrazione senza interruzioni: un lavoro invisibile all'utente, ma che spiega perché la funzione arriva solo ora. Per chi costruisce integrazioni con Cloudflare, è un tassello che finora mancava e che vale la pena provare su un progetto reale.

::cta{title="Devi costruire un'integrazione che acceda in modo sicuro ai dati di un cliente?" text="Sviluppiamo integrazioni Laravel con OAuth, gestione degli scope e revoca degli accessi, al posto di token generici passati a mano." button="Progettiamo l'integrazione →"}

Fonti

TTFB: cos'è il Time To First Byte e perché conta per le prestazioni di un sito

Alessandro Corbelli — Sun, 28 Jun 2026 00:00:00 GMT

Quando si apre una pagina web, c'è un momento di attesa prima che compaia qualsiasi cosa: la barra di caricamento gira, lo schermo resta bianco, e solo dopo iniziano ad apparire testi e immagini. Buona parte di quell'attesa iniziale ha un nome preciso: TTFB, cioè Time To First Byte, il "tempo fino al primo byte". Capire cos'è aiuta a ragionare sulle prestazioni di un sito senza affidarsi a sensazioni vaghe.

Cos'è il TTFB in parole semplici

Il TTFB misura il tempo che passa da quando il browser inizia a richiedere una pagina a quando riceve il primo byte della risposta dal server. In pratica è quanto ci mette il server a "iniziare a rispondere", non a finire.

Un paragone utile: è come ordinare al ristorante. Il TTFB non è il tempo per finire di mangiare, e nemmeno quello per avere il piatto completo davanti. È il tempo che passa dall'ordine al momento in cui il cameriere torna con la prima portata. Se quel primo segnale arriva tardi, tutto il resto slitta di conseguenza.

Vale la pena chiarire subito un punto: il TTFB non è una singola cosa, ma la somma di più passaggi. Secondo la documentazione di web.dev, comprende il tempo per eventuali redirect (rimbalzi da un indirizzo a un altro), l'avvio di un eventuale service worker, la risoluzione DNS (tradurre il nome del sito nell'indirizzo numerico del server), la negoziazione della connessione e del TLS (l'"handshake" cifrato che protegge i dati) e infine l'elaborazione della richiesta fino al primo byte restituito.

Perché conta per chi usa il sito

Il primo byte non è ancora contenuto visibile: è solo il segnale che la risposta è iniziata. Ma finché non arriva, il browser non può fare nulla. Non può leggere l'HTML, non può scaricare immagini o fogli di stile, non può disegnare niente sullo schermo. Un TTFB alto sposta in avanti tutto ciò che viene dopo.

Per l'utente questo si traduce in una sensazione concreta: il sito sembra "lento a partire". Anche se il resto è ottimizzato, un server che ci mette troppo a rispondere lascia lo schermo vuoto più a lungo, e la pagina dà l'impressione di non funzionare. Su questo tema le linee guida offrono un riferimento pratico: un TTFB è considerato buono a 0,8 secondi o meno ed è considerato scarso oltre 1,8 secondi. Non è una soglia assoluta, ma un ordine di grandezza utile per capire se c'è margine di miglioramento.

::cta{variant="inline" title="Sai quanto tempo passa prima che il tuo sito inizi a rispondere?" text="Misuriamo il TTFB del tuo sito e ti diciamo se il problema è il server, l'applicazione o il database." button="Misura il tuo TTFB →"}

TTFB, SEO e Core Web Vitals

Qui serve un po' di contesto. Google usa un insieme di metriche chiamate Core Web Vitals per misurare la qualità dell'esperienza di caricamento di una pagina, e queste metriche sono un fattore che influisce sul posizionamento nei risultati di ricerca. Sono tre: LCP (Largest Contentful Paint, quanto tempo passa prima che compaia il contenuto principale, buona sotto i 2,5 secondi), INP (Interaction to Next Paint, quanto è reattiva la pagina ai clic, buona sotto i 200 millisecondi) e CLS (Cumulative Layout Shift, quanto gli elementi "saltano" mentre la pagina si carica, buona sotto 0,1). Da notare che nel 2024 INP ha sostituito la vecchia metrica FID.

Il TTFB, di per sé, non è una delle Core Web Vitals. Però le precede tutte. È il primo mattoncino su cui si costruisce l'LCP in particolare: la documentazione di web.dev lo descrive come la prima parte dell'LCP e stima che possa pesarne circa il 40%. Il principio è semplice: nulla può accadere nella pagina finché il server non consegna quel primo byte, quindi qualsiasi cosa riduca il TTFB tende a migliorare anche le altre metriche di caricamento. Ridurre il TTFB non garantisce da solo un buon punteggio, ma un TTFB alto lo rende molto più difficile da ottenere.

Da cosa dipende il TTFB

Il TTFB non dipende da un unico fattore, ed è per questo che a volte è difficile diagnosticarlo. In generale entrano in gioco più livelli.

La rete e la distanza geografica. Ogni richiesta viaggia fisicamente tra l'utente e il server. Più sono lontani, più tempo serve solo per il viaggio dei dati, a cui si aggiungono la risoluzione DNS e l'handshake TLS iniziali.
Il server e l'hosting. Un server sovraccarico, sottodimensionato o con software datato risponde più lentamente. La qualità dell'hosting è spesso il primo punto da valutare.
L'applicazione. Il codice che genera la pagina può fare lavoro pesante a ogni richiesta: calcoli, chiamate a servizi esterni, elaborazioni non ottimizzate. Tutto questo si accumula prima del primo byte.
Il database. Se generare la pagina richiede interrogazioni lente o troppo numerose, il server resta in attesa del database prima di poter rispondere.
La cache (o la sua assenza). Se ogni richiesta viene ricalcolata da zero, si paga ogni volta l'intero costo. La cache serve proprio a evitarlo.

Un TTFB alto, quindi, è un sintomo: il valore va poi scomposto per capire dove si perde tempo.

Le leve generali per migliorarlo

Non esiste un'unica soluzione valida per tutti, e conviene sempre misurare prima e dopo. Detto questo, gli approcci più diffusi sono pochi e agiscono sui livelli descritti sopra.

Caching. È spesso la leva con il miglior rapporto tra sforzo e risultato. L'idea è servire un risultato già pronto invece di ricalcolarlo. Può avvenire a più livelli: una page cache che conserva l'HTML già generato, una cache dei dati o delle query e le intestazioni Cache-Control, che indicano a browser e intermediari quando riusare una risposta. Con una cache efficace, solo la prima richiesta paga il costo pieno verso il server d'origine.
CDN (Content Delivery Network). Una CDN è una rete di server distribuiti geograficamente che avvicinano i contenuti all'utente. Serve la risposta da un nodo vicino invece che dal server d'origine lontano, riducendo il tempo di viaggio dei dati; in più le CDN in genere offrono DNS veloce, protocolli moderni come HTTP/2 e HTTP/3 e una gestione ottimizzata del TLS.
Ottimizzazione del backend. Qui rientra tutto ciò che rende più rapida la generazione della risposta: query di database più efficienti, riduzione del lavoro svolto a ogni richiesta, aggiornamento dell'infrastruttura. È la parte meno "magica" e più artigianale, ma spesso la più risolutiva quando il collo di bottiglia è l'applicazione, come succede di frequente con un e-commerce cresciuto negli anni.
Ridurre i redirect. Ogni rimbalzo da un indirizzo all'altro aggiunge un giro completo di rete prima ancora di iniziare a rispondere. Eliminare i redirect superflui, quando sono sotto il proprio controllo, aiuta.

In sintesi

Il TTFB è il tempo prima del primo byte di risposta: un valore piccolo ma fondamentale, perché tutto il resto del caricamento parte da lì. Non è una metrica ufficiale delle Core Web Vitals, ma le condiziona, e per questo incide sia sull'esperienza percepita sia, indirettamente, sulla SEO. Dipende da rete, server, applicazione, database e cache, e si affronta soprattutto con caching, CDN e ottimizzazione del backend. La regola pratica resta la stessa: misurare, capire dove si perde tempo e intervenire sul livello giusto invece di cambiare tutto a caso.

::cta{title="Vuoi un sito che risponde subito, non solo che si carica in fretta?" text="Interveniamo su hosting, cache e backend per abbattere il TTFB, dall'ottimizzazione del server alla messa a punto delle query più lente." button="Parliamone →"}

Fonti

HTTP QUERY (RFC 10008): un metodo sicuro con un corpo per le ricerche complesse

Alessandro Corbelli — Mon, 06 Jul 2026 00:00:00 GMT

Chi lavora con le API web conosce un fastidio ricorrente. Quando una ricerca diventa complessa - molti filtri, elenchi di valori, condizioni annidate - non c'è un modo davvero pulito per esprimerla usando i metodi HTTP di sempre. A giugno 2026 l'IETF, l'organismo che cura gli standard tecnici di Internet, ha pubblicato la RFC 10008 e introdotto un nuovo metodo HTTP pensato proprio per questo caso: si chiama QUERY.

Il problema che QUERY vuole risolvere

Ogni richiesta HTTP ha un "metodo", cioè un verbo che dice al server cosa si vuole fare. I più noti sono GET (leggere qualcosa) e POST (inviare dati, di solito per creare o modificare).

Chi progetta un'API di ricerca si trova davanti a un bivio poco comodo:

GET è il metodo giusto per leggere, ma i parametri viaggiano nella querystring, cioè la coda dell'indirizzo dopo il punto interrogativo (?nome=valore&...). Gli indirizzi hanno però limiti di lunghezza pratici: server, proxy e browser possono troncare o rifiutare URL troppo lunghi. Inoltre l'indirizzo finisce quasi sempre nei log e nella cronologia. Esprimere un filtro articolato in una querystring diventa presto illeggibile e fragile.
POST permette di allegare un body, cioè un corpo del messaggio dove mettere i dati veri e propri, in JSON o in altri formati. Molte API usano POST per le ricerche solo per poter sfruttare questo corpo. Il problema è che POST nasce per operazioni che cambiano qualcosa, e questo confonde chi sta nel mezzo.

Qui servono due termini, spiegati in parole semplici. Una richiesta si dice sicura (safe) quando è di sola lettura: non ci si aspetta che modifichi nulla sul server. Si dice idempotente quando ripeterla identica non cambia il risultato: mandarla una o dieci volte porta allo stesso stato. GET ha entrambe le proprietà; POST no. Per questo cache e proxy non possono ripetere una POST in automatico dopo un errore di rete, né conservarne la risposta con tranquillità: non sanno se quella richiesta ha "toccato" qualcosa.

Il risultato è una scelta tra due compromessi: GET pulito ma con la querystring che scoppia, oppure POST comodo ma semanticamente sbagliato per una semplice ricerca.

Cos'è il metodo QUERY

QUERY colma esattamente questo vuoto. La RFC 10008 lo descrive come una richiesta sicura e idempotente che porta con sé un contenuto che indica come deve essere elaborata dalla risorsa di destinazione, la quale risponde con il risultato di quell'elaborazione.

In pratica: è una richiesta di sola lettura come GET, ma con un corpo come POST. Il testo dello standard è netto sulle due proprietà. Sul fronte della sicurezza: il client "non richiede né si aspetta alcun cambiamento allo stato della risorsa". Sull'idempotenza: le richieste QUERY "possono essere ritentate o ripetute quando serve, per esempio dopo un errore di connessione".

Detto altrimenti, QUERY dà a chi progetta API la cosa che né GET né POST offrono da soli: una ricerca complessa, con un corpo strutturato, che resta ripetibile e memorizzabile in cache senza rischi.

::cta{variant="inline" title="Le tue API di ricerca usano ancora POST per aggirare i limiti di GET?" text="Verifichiamo endpoint e client per capire se conviene già introdurre QUERY o tenere un fallback solido." button="Chiedi una verifica →"}

GET, POST e QUERY a confronto

Un modo semplice per fissare le idee:

GET - legge, senza corpo utile; i parametri stanno nell'URL, con i suoi limiti.
POST - ha un corpo, ma non è né sicuro né idempotente: pensato per modificare.
QUERY - ha un corpo ed è sicuro e idempotente: pensato per interrogare.

La differenza non è cosmetica. Rende esplicita al server, alle cache e ai proxy l'intenzione reale - "sto solo leggendo" - e sblocca comportamenti come la ripetizione automatica e la conservazione in cache che con POST sarebbero azzardati.

Come funziona, in concreto

Alcuni dettagli dello standard aiutano a capire come si userà.

Il tipo di contenuto è obbligatorio. Il corpo di una QUERY può essere in qualsiasi formato: JSON, un'espressione simile a SQL, un linguaggio di filtro proprietario. Proprio per questo il server deve sapere cosa sta ricevendo. La RFC prevede che il server rifiuti la richiesta se manca l'intestazione Content-Type o se non è coerente con il contenuto, e vieta di "indovinare" il formato dai dati (niente content sniffing). Una richiesta priva dell'indicazione del tipo va respinta con un codice 4xx, tipicamente 400.

C'è un modo per annunciare il supporto. Lo standard introduce una nuova intestazione di risposta, Accept-Query, con cui una risorsa può dichiarare che accetta QUERY e quali formati di query capisce. Un esempio dalla specifica: Accept-Query: "application/jsonpath", application/sql;charset="UTF-8". Serve a far scoprire ai client, in modo ordinato, che quella via è disponibile.

Le risposte possono andare in cache. È il vantaggio pratico più evidente, perché incide direttamente su il tempo di risposta percepito da chi naviga. La risposta a una QUERY è memorizzabile, ma con un'attenzione: la chiave di cache - l'identificativo con cui la risposta viene ritrovata - deve tenere conto del corpo della richiesta e dei suoi metadati, non solo dell'URL. Le cache possono normalizzare differenze irrilevanti del contenuto per riconoscere richieste equivalenti, ma solo ai fini della chiave, senza alterare la richiesta vera.

La risposta può indicare dove ritrovare il risultato. Il server può includere un'intestazione Content-Location che punta a una risorsa con il risultato dell'operazione (eventualmente temporanea), oppure Location per indicare una risorsa "equivalente": un indirizzo su cui un client potrà poi fare una normale GET per ripetere la stessa interrogazione senza rimandare tutto il corpo.

Sicurezza e compatibilità: cosa tenere d'occhio

Ci sono aspetti pratici che conviene valutare prima di adottarlo.

Sul piano della riservatezza c'è un beneficio: spostando i criteri di ricerca dall'URL al corpo, i dati sensibili finiscono meno spesso nei log, perché - come nota la RFC - l'indirizzo viene registrato e trattato dagli intermediari molto più del contenuto. Lo standard raccomanda anche che, se il server crea una risorsa temporanea per il risultato, l'indirizzo assegnato non contenga parti sensibili della query originale.

Restano però attriti di adozione. Nei browser una QUERY verso un'altra origine richiede una richiesta di preflight CORS - un controllo preliminare che il browser fa per verificare i permessi - perché QUERY non è tra i metodi considerati "sicuri per impostazione predefinita". Va inoltre ricordato che l'eccezione per cui un redirect trasforma una POST in GET (risposte 301 o 302) non si applica a QUERY. E, banalmente, ogni anello della catena - proxy, web server, framework, librerie client - deve imparare a riconoscere il nuovo metodo: finché non lo fa, una QUERY può essere bloccata o gestita male.

A che punto è la standardizzazione

Qui serve una precisazione, perché in giro si trova ancora la vecchia dizione. Per anni questa proposta è esistita come Internet-Draft con il nome draft-ietf-httpbis-safe-method-w-body, elaborata dal gruppo di lavoro httpbis dell'IETF, lo stesso che ha prodotto anche l'header per segnalare le API deprecate e lo schema di autenticazione concealed. Nel novembre 2025 il testo è stato approvato e a giugno 2026 è stato pubblicato come RFC 10008. Non è più quindi una semplice bozza: è un documento pubblicato.

Attenzione però al livello. RFC 10008 è uno Standard Proposto (Proposed Standard), cioè il primo gradino stabile della via degli standard IETF: un testo maturo, rivisto pubblicamente e citabile, ma non ancora il livello finale di "Internet Standard". In termini pratici significa che la specifica è solida, mentre il supporto reale in server, proxy e framework è ancora in corso di diffusione.

Gli autori sono Julian Reschke (greenbytes), James M. Snell (Cloudflare) e Mike Bishop (Akamai). La presenza di Cloudflare e Akamai, due grandi operatori di rete e CDN, è un segnale utile: sono proprio gli attori che devono supportare il metodo lungo il percorso perché diventi usabile su larga scala, la stessa spinta con cui Cloudflare sta sperimentando anche su altri fronti del protocollo, per esempio un nuovo uso dello status HTTP 402 per il traffico dei crawler AI.

Perché può tornare utile a chi sviluppa API

Il valore di QUERY non è l'ennesima sigla, ma il fatto di dare un nome corretto a una cosa che si faceva già forzando gli strumenti. Chi finora ha usato POST per le ricerche lo ha fatto per un motivo tecnico legittimo - serviva un corpo - ma pagando in chiarezza e perdendo cache e ripetizione automatica.

In prospettiva, per un'API con ricerche articolate conviene valutare QUERY come alternativa più onesta: mantiene la semantica di lettura, evita i limiti dell'URL, tiene i criteri fuori dai log e riapre la porta alla cache. Nel frattempo, dato che l'adozione lungo la catena non è ancora universale, un approccio prudente è tenere una via di fallback su POST e verificare il comportamento di proxy e client prima di affidarsi solo a QUERY in produzione. È una di quelle novità che non cambiano tutto domani, ma che nel giro di qualche anno è ragionevole aspettarsi come opzione standard nelle API di ricerca.

::cta{title="Stai progettando o revisionando un'API con ricerche complesse?" text="Sviluppiamo API su misura in Laravel e PHP: valutiamo insieme se e come introdurre QUERY, con attenzione a cache, proxy e compatibilità dei client." button="Parliamone →"}

Fonti

Pacchetti npm compromessi: cosa è successo e come difendersi con un periodo di quarantena

Alessandro Corbelli — Thu, 16 Jul 2026 00:00:00 GMT

Chi sviluppa in JavaScript installa librerie di terze parti decine di volte al giorno, quasi senza pensarci. Un comando, qualche secondo, e il progetto ha una nuova dipendenza - insieme a tutte le dipendenze di quella dipendenza. Negli ultimi mesi questo gesto quotidiano è diventato il canale di una serie di attacchi che hanno colpito librerie usate da milioni di progetti. La buona notizia è che una delle difese più efficaci è anche semplice da adottare: aspettare qualche giorno prima di installare le versioni appena pubblicate. Vediamo cosa è successo e come si configura questa protezione con pnpm.

Cos'è un attacco alla supply chain

Prima i termini. Il registro npm è l'archivio pubblico da cui si scaricano i pacchetti JavaScript: contiene milioni di librerie, pubblicate dai rispettivi manutentori. Un attacco alla supply chain ("catena di fornitura") non colpisce direttamente il tuo progetto: colpisce una delle librerie che il tuo progetto usa. Se un malintenzionato riesce a pubblicare una versione modificata di una libreria diffusa, chiunque la installi in quel periodo esegue anche il suo codice.

Il punto debole è quasi sempre l'account del manutentore. Ottenute le sue credenziali - di solito con il phishing, cioè con email e siti contraffatti che imitano quelli veri - l'attaccante pubblica una nuova versione del pacchetto con dentro il codice malevolo. Per chi installa, quella versione è indistinguibile da un aggiornamento legittimo.

Cosa è successo, in breve

Gli episodi recenti danno la misura del problema.

A settembre 2025 un manutentore molto attivo è stato ingannato da una email di phishing che imitava il supporto di npm (il dominio contraffatto era npmjs.help). Con le sue credenziali sono state pubblicate versioni malevole di 18 pacchetti, tra cui chalk e debug: librerie minuscole ma presenti, direttamente o indirettamente, in una fetta enorme dell'ecosistema - nell'insieme contano miliardi di scaricamenti a settimana. Il codice iniettato dirottava transazioni di criptovalute nel browser. Le versioni compromesse sono rimaste online circa due ore prima della rimozione.

Poche settimane dopo è arrivato Shai-Hulud, un attacco di tipo nuovo: un worm, cioè un programma che si replica da solo. Partito dal pacchetto @ctrl/tinycolor, una volta installato cercava sulla macchina della vittima credenziali e token di accesso (npm, GitHub, provider cloud), li usava per pubblicare versioni infette dei pacchetti gestiti dalla vittima stessa, e così si propagava di manutentore in manutentore. I pacchetti coinvolti sono arrivati nell'ordine delle centinaia, e i segreti rubati venivano pubblicati in repository GitHub creati automaticamente. A fine novembre 2025 una seconda ondata ("Shai-Hulud 2.0") ha prodotto decine di migliaia di repository malevoli.

Il fenomeno non si è fermato: nella primavera del 2026 i ricercatori hanno documentato nuove campagne che riprendono le stesse tecniche - tra cui una terza ondata del worm partita a fine aprile - e a giugno 2026 sono stati compromessi una trentina di pacchetti pubblicati sotto il namespace @redhat-cloud-services. Non è un elenco completo, e con ogni probabilità non sarà l'ultimo capitolo.

::cta{variant="inline" title="Il tuo progetto installa ancora le versioni npm appena pubblicate senza filtro?" text="Controlliamo la configurazione di pnpm o npm nei tuoi progetti e valutiamo se attivare una quarantena sulle nuove versioni." button="Chiedi un controllo →"}

Perché basta "aspettare" per difendersi

C'è un dettaglio che ricorre in quasi tutti questi episodi: le versioni malevole vengono individuate e rimosse in fretta. Le versioni compromesse di chalk e debug sono durate un paio d'ore; il worm Shai-Hulud è stato identificato nel giro di una dozzina di ore. La comunità della sicurezza monitora il registro npm costantemente, e un pacchetto popolare che inizia a fare cose strane viene segnalato quasi subito.

Il problema è che in quelle poche ore i danni li subisce chi installa proprio in quel momento. E gli intervalli di versione usati nei package.json (il classico ^1.2.3, che accetta qualsiasi versione compatibile più recente) fanno sì che una versione appena pubblicata venga adottata automaticamente da chiunque installi da zero o aggiorni.

Da qui l'idea della quarantena (o cooldown): non installare mai versioni pubblicate da meno di X giorni. Non protegge da tutto - un attacco che resta inosservato più a lungo la supera - ma avrebbe bloccato la quasi totalità degli episodi visti finora, al costo di adottare gli aggiornamenti con qualche giorno di ritardo.

Come si configura con pnpm

pnpm (un gestore di pacchetti alternativo a npm, compatibile con lo stesso registro, che sa anche bloccare la versione di Node.js usata dal progetto) implementa questa idea con l'impostazione minimumReleaseAge, espressa in minuti. Si imposta nel file pnpm-workspace.yaml alla radice del progetto:

# pnpm-workspace.yaml
# non installare versioni pubblicate da meno di 3 giorni
minimumReleaseAge: 4320

Da quel momento pnpm, per ogni dipendenza - incluse quelle transitive, cioè le dipendenze delle dipendenze - risolve la versione più recente che abbia almeno quell'età. L'impostazione esiste da pnpm 10.16. Un esempio provato mentre scrivevamo questo articolo: al 16 luglio 2026 l'ultima versione di @types/node è la 26.1.1, pubblicata l'8 luglio. Con una quarantena di 10 giorni (minimumReleaseAge: 14400), pnpm salta la 26.1.1 e installa la 26.1.0 del 1° luglio, dichiarandolo apertamente:

$ pnpm add @types/node
# ...
dependencies:
+ @types/node 26.1.0 (26.1.1 is available)

Nessun errore, nessun intervento manuale: la versione troppo recente non viene considerata, e pnpm segnala tra parentesi che esiste. Quando avrà superato la soglia, un normale aggiornamento la porterà nel progetto.

Il controllo non vale solo per le nuove installazioni: pnpm verifica anche il lockfile esistente, e se contiene una versione più giovane della soglia blocca l'installazione con un errore esplicito (ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION, provato anche questo). Se una dipendenza specifica deve poter arrivare subito - per esempio un pacchetto interno all'azienda, o una correzione di sicurezza attesa - si aggiunge un'eccezione:

minimumReleaseAge: 4320
minimumReleaseAgeExclude:
  - "@nostra-azienda/*"

Quanto dev'essere lunga la quarantena? Da pnpm 11 l'impostazione è attiva di default a 1440 minuti (un giorno), che è già sufficiente per gli episodi lampo come chalk/debug. Un valore tra i 3 e i 7 giorni dà più margine, in cambio di aggiornamenti un po' meno tempestivi: una scelta ragionevole per progetti che non inseguono l'ultima versione di tutto.

Le altre difese che pnpm attiva da solo

La quarantena funziona meglio insieme ad altre due protezioni, che nelle versioni recenti di pnpm sono già attive.

La prima riguarda gli script di installazione. Molti attacchi (Shai-Hulud incluso) si attivano tramite i lifecycle script, comandi che un pacchetto può eseguire automaticamente al momento dell'installazione. Da pnpm 10 questi script non vengono più eseguiti per le dipendenze, salvo quelle autorizzate esplicitamente (la chiave attuale è allowBuilds; nelle versioni precedenti si chiamava onlyBuiltDependencies):

# pnpm-workspace.yaml
# solo questi pacchetti possono eseguire script di installazione
allowBuilds:
  - esbuild

La seconda è il lockfile (pnpm-lock.yaml), il file che registra le versioni esatte installate. In CI e in produzione conviene installare con pnpm install --frozen-lockfile: se il lockfile non corrisponde al package.json l'installazione fallisce invece di risolvere versioni nuove, quindi nessun aggiornamento entra senza passare da una modifica revisionabile, lo stesso spirito con cui conviene ritagliare i permessi dei token usati dalla pipeline sul minimo necessario invece di lasciarli ad ampio raggio.

Chi usa npm non resta senza opzioni: il flag --before permette di installare solo versioni pubblicate prima di una certa data (npm install --before="2026-07-09"), anche se va passato a ogni comando; al momento non esiste un equivalente stabile del cooldown automatico di pnpm.

In sintesi

Gli attacchi alla supply chain di npm non sono più episodi isolati: tra la fine del 2025 e il 2026 hanno colpito librerie di uso comune, con un worm capace di propagarsi da solo tra i manutentori. Quasi tutte le versioni malevole, però, vengono rimosse entro poche ore o pochi giorni dalla pubblicazione. Imporre una quarantena alle versioni troppo recenti - con minimumReleaseAge di pnpm, un valore tra 1 e 7 giorni - elimina la finestra in cui si è più esposti, senza cambiare il modo di lavorare. Insieme al blocco degli script di installazione e al lockfile congelato nella pipeline che compila il progetto, è oggi una delle difese con il miglior rapporto tra costo e beneficio per chi sviluppa in JavaScript.

::cta{title="Vuoi mettere in sicurezza la catena di dipendenze dei tuoi progetti JavaScript?" text="Configuriamo minimumReleaseAge, blocco degli script di installazione e lockfile congelato in CI per i progetti Laravel e Vue che sviluppiamo e manteniamo." button="Parliamone →"}

Fonti

Fissare la versione di Node.js con pnpm, senza nvm

Alessandro Corbelli — Thu, 16 Jul 2026 00:00:00 GMT

"Sulla mia macchina funziona." Una buona parte delle volte, dietro questa frase c'è una versione diversa di Node.js: il progetto è nato sulla 20, il collega ha la 24, la CI usa un'altra ancora. Lo strumento classico per conviverci è nvm, che permette di installare più versioni e passare dall'una all'altra. Funziona, ma va installato e configurato da ogni persona del team, e ricordarsi di digitare nvm use al momento giusto resta un onere. Chi usa pnpm come gestore di pacchetti ha un'alternativa spesso trascurata: pnpm sa gestire anche la versione di Node.js, e sa farlo per progetto, senza strumenti aggiuntivi.

Il problema, in due parole

Node.js è l'ambiente che esegue il JavaScript fuori dal browser; ogni progetto è di fatto testato e garantito solo su certe versioni. nvm (Node Version Manager) affronta il problema installando più versioni fianco a fianco: nvm install 20, nvm use 20 e la shell corrente passa alla 20.

I limiti sono noti a chi lo usa ogni giorno. nvm è uno script di shell che va installato per utente e agganciato al profilo della shell; il cambio di versione vale per la sessione corrente, quindi va ripetuto (o automatizzato con hook) a ogni cartella; nelle pipeline di integrazione continua e nei container si usa tipicamente tutt'altro meccanismo, con il rischio di divergenze. Non è un difetto di nvm: è il prezzo di uno strumento separato dal progetto.

L'alternativa: il runtime dichiarato nel progetto

pnpm ribalta l'approccio: la versione di Node.js diventa una dichiarazione del progetto, scritta nel package.json e versionata insieme al codice. Il campo si chiama devEngines:

{
  "devEngines": {
    "runtime": {
      "name": "node",
      "version": "20.19.0",
      "onFail": "download"
    }
  }
}

La chiave è onFail: "download": se il Node in uso non corrisponde a quello dichiarato, pnpm scarica da solo la versione richiesta (una volta sola, poi resta in cache) e la usa per il progetto, senza toccare il Node di sistema. Il runtime compare nell'output di pnpm install come una dipendenza qualsiasi:

$ pnpm install
# ...
+ node 20.19.0

E da quel momento tutto ciò che passa da pnpm usa quella versione. Un esempio provato mentre scrivevamo l'articolo, su una macchina con Node 22 di sistema:

$ node -v               # il Node di sistema
v22.22.2

$ pnpm run check-node   # uno script che esegue "node -v"
> node -v
v20.19.0                # la versione dichiarata nel progetto

$ pnpm node -v
v20.19.0

Nessun nvm use, nessun hook di shell: chiunque cloni il repository - collega nuovo, CI, container - ottiene la stessa versione di Node semplicemente usando pnpm.

::cta{variant="inline" title="Il tuo team perde tempo a inseguire versioni diverse di Node tra sviluppatori e CI?" text="Verifichiamo la configurazione degli ambienti di sviluppo e della pipeline CI/CD dei tuoi progetti JavaScript." button="Chiedi una verifica →"}

Anche a intervalli, e bloccato nel lockfile

version accetta sia una versione esatta sia un intervallo semver. Con "version": "^20.11.0", nel nostro test pnpm ha risolto e scaricato l'ultima 20.x disponibile:

$ pnpm install
# ...
+ node 20.20.2

Il dettaglio più interessante è che la versione risolta finisce nel lockfile (pnpm-lock.yaml), come una normale dipendenza:

node:
  specifier: runtime:^20.11.0
  version: runtime:20.20.2

Questo significa che tutto il team e la CI usano esattamente la stessa versione di Node, non solo "una versione compatibile": la riproducibilità è la stessa che il lockfile garantisce alle librerie. Il classico campo engines, per confronto, si limita ad avvisare quando la versione non corrisponde; devEngines con onFail: "download" risolve il problema da solo.

I limiti da conoscere

Il meccanismo vale per ciò che passa da pnpm: pnpm run, pnpm exec, pnpm node, gli script del package.json. Se si digita node server.js direttamente nel terminale, si usa ancora il Node di sistema. Nella pratica è un limite più piccolo di quanto sembri - nei progetti JavaScript quasi tutto passa dagli script - ma è bene saperlo: devEngines non "cambia il Node del computer", garantisce che il progetto giri sulla versione giusta.

Una nota per chi arriva da versioni precedenti: fino a pnpm 10 esisteva l'impostazione use-node-version (o useNodeVersion nel pnpm-workspace.yaml), che faceva una cosa simile. pnpm 11 l'ha rimossa insieme a executionEnv.nodeVersion: la strada supportata oggi è devEngines. Se un progetto usa ancora quelle chiavi, con pnpm 11 vengono semplicemente ignorate - un aggiornamento facile da dimenticare.

E al posto di nvm per tutto il sistema?

pnpm può sostituire nvm anche come gestore globale delle versioni, con il comando pnpm env:

pnpm env list 20            # quali versioni 20.x esistono
pnpm env use --global 20    # installa e attiva l'ultima 20.x
pnpm env use --global lts   # oppure l'ultima LTS

Qui serve una precisazione onesta: pnpm env gestisce il collegamento globale a Node, quindi richiede che pnpm sia installato in modo autonomo (con lo script di installazione ufficiale o con Corepack), non tramite npm install -g pnpm - in quel caso pnpm girerebbe dentro il Node che sta cercando di sostituire. Per l'uso per-progetto visto sopra, invece, questa distinzione non conta.

In sintesi

Se un progetto usa già pnpm, fissare la versione di Node.js non richiede nvm: un blocco devEngines nel package.json, con onFail: "download", fa scaricare e usare a pnpm il runtime dichiarato - versione esatta o intervallo - e blocca nel lockfile quella effettivamente risolta, uguale per tutto il team e per la CI. Il limite è chiaro (vale per i comandi che passano da pnpm), e chi arriva da pnpm 10 deve migrare da use-node-version a devEngines. nvm resta utile come gestore generale sulla propria macchina; per la riproducibilità di un progetto, la versione dichiarata nel repository è la strada più solida.

::cta{title="Vuoi rendere riproducibili gli ambienti dei tuoi progetti Node.js?" text="Configuriamo pnpm, pipeline CI/CD e ambienti di sviluppo per i progetti Laravel e Vue che realizziamo e gestiamo." button="Parliamone →"}

Fonti

PHP a fine vita: cosa rischia davvero chi resta su una versione vecchia

Alessandro Corbelli — Sun, 09 Aug 2026 00:00:00 GMT

"Funziona, perché toccarlo?" è la frase che tiene in vita migliaia di siti e gestionali su versioni di PHP ormai abbandonate. Ed è una frase comprensibile: l'aggiornamento costa tempo, il sito risponde, i clienti non si lamentano. Il problema è che il rischio di un PHP a fine vita non si vede: non rallenta la pagina, non mostra errori, non manda avvisi. Semplicemente, da un certo giorno in poi, nessuno chiude più le falle che vengono scoperte.

E le falle vengono scoperte comunque. La ricerca di vulnerabilità non si ferma quando finisce il supporto: si ferma solo la distribuzione delle correzioni. Tutto ciò che emerge dopo quella data resta aperto per sempre, su ogni server che esegue quella versione.

Fine del supporto: cosa significa davvero

Ogni versione di PHP attraversa due fasi. Nella prima, il supporto attivo, riceve correzioni di ogni tipo: bug, prestazioni, sicurezza. Nella seconda, il supporto di sicurezza, riceve solo le patch per le vulnerabilità. Finita anche questa, la versione è a fine vita (end of life): il codice continua a girare, ma è ufficialmente abbandonato.

Le date sono pubbliche e non negoziabili: l'intera famiglia PHP 7 è a fine vita dalla fine del 2022, PHP 8.0 dalla fine del 2023 e PHP 8.1 dalla fine del 2025. Nell'estate del 2026 ricevono correzioni solo PHP 8.2 (che chiude a fine anno), 8.3, 8.4 e 8.5. Chi oggi è su PHP 7.4 esegue un software che non vede una patch di sicurezza da quasi quattro anni. Lo stesso meccanismo vale un piano più in basso, per il server che ospita tutto: ne parliamo a proposito di Proxmox VE 8 a fine vita.

I rischi concreti, oltre la teoria

Il primo rischio è ovvio: vulnerabilità senza rimedio. Un sito esposto su internet viene sondato in continuazione da scanner automatici che cercano proprio le installazioni vecchie, perché sono le più facili da bucare. Non serve essere un bersaglio interessante: basta essere raggiungibili.

Il secondo è più sottile: l'ecosistema si sposta. Librerie, framework e piattaforme abbandonano le versioni vecchie di PHP molto prima dei loro utenti: le nuove release di WordPress, PrestaShop, Laravel e delle dipendenze Composer richiedono versioni recenti. Restare fermi su un PHP vecchio significa restare fermi su tutto, moduli di pagamento e plugin di sicurezza inclusi.

Il terzo riguarda chi tratta dati personali: per il GDPR le misure di sicurezza devono essere "adeguate allo stato dell'arte", e un componente abbandonato dal produttore è difficile da difendere come adeguato, come abbiamo visto parlando di GDPR lato infrastruttura. In caso di violazione, la versione di PHP finisce nel verbale. Per le aziende soggette alla NIS2 c'è anche un risvolto contrattuale: le misure dell'ACN ammettono solo software con aggiornamenti di sicurezza garantiti e i requisiti passano ai fornitori, come spieghiamo in NIS2 e fornitori.

::cta{variant="inline" title="Non sai su quale versione di PHP girano i tuoi siti?" text="Lo verifichiamo noi: censiamo versioni, estensioni e dipendenze dei tuoi progetti e ti diciamo cosa è a rischio e cosa conviene aggiornare per primo." button="Chiedi un censimento gratuito →"}

L'aggiornamento conviene anche quando non è obbligato

Aggiornare PHP non è solo togliersi un rischio: è uno dei pochi interventi che migliora le prestazioni senza toccare una riga di codice. Ogni release recente esegue lo stesso programma più in fretta della precedente, e su un sito dinamico la differenza si misura, come racconta la nostra guida su come velocizzare un PrestaShop. Meno tempo di CPU per richiesta significa anche server più piccoli a parità di traffico: l'aggiornamento spesso si ripaga in bolletta.

Come si migra senza drammi

La migrazione temuta "perché poi si rompe tutto" si affronta come ogni intervento serio: con un metodo, non con il coraggio.

Inventario: quali applicazioni girano, su quale versione, con quali estensioni e dipendenze. Senza questa mappa ogni stima è una scommessa.
Prova in un ambiente separato: si replica il sito su un ambiente di test con la versione di destinazione e si guardano log e deprecation warning. Gli strumenti di analisi statica segnalano in anticipo il codice incompatibile.
Aggiornamenti graduali: meglio salire una versione alla volta che saltare dal 7.4 all'8.5 in un colpo solo, correggendo le incompatibilità a piccoli passi.
Rete di sicurezza: prima di toccare la produzione, un backup verificato e un piano di rientro. Se qualcosa va storto, si torna indietro in minuti, non in nottate.

Per un e-commerce o un gestionale su misura il grosso del lavoro non è quasi mai PHP in sé, ma i moduli e il codice custom scritti anni fa: è lì che serve la mano di chi queste migrazioni le fa di mestiere.

In sintesi

Una versione di PHP a fine vita non smette di funzionare: smette di essere difesa. Le falle nuove restano aperte per sempre, l'ecosistema di librerie e piattaforme si allontana, e la conformità GDPR diventa difficile da sostenere. La migrazione, affrontata con inventario, ambiente di prova, passi graduali e backup, è un progetto ordinario e non un salto nel vuoto; in cambio si ottiene un sito più sicuro, più veloce e di nuovo libero di aggiornare tutto il resto.

::cta{title="Vuoi portare i tuoi progetti su un PHP supportato senza fermare nulla?" text="Migriamo siti, e-commerce e gestionali da versioni PHP a fine vita: inventario, ambiente di prova, correzione delle incompatibilità e rientro garantito dal backup." button="Parliamone →"}

Fonti

PrestaShop lento: da dove nasce il problema e come si risolve

Alessandro Corbelli — Sun, 09 Aug 2026 00:00:00 GMT

Un e-commerce lento perde vendite, ed è una perdita silenziosa: nessun cliente scrive per avvisare che la pagina ci metteva troppo, semplicemente chiude la scheda e compra altrove. Ogni secondo di attesa in più si paga in carrelli abbandonati, e il conto arriva proprio nei momenti peggiori, quando una promozione o una campagna porta più traffico del solito.

PrestaShop, di suo, non è una piattaforma lenta: lo diventa. Anni di moduli installati e mai rimossi, un tema comprato per l'estetica, un hosting scelto quando il negozio era piccolo, un database cresciuto senza manutenzione. La buona notizia è che la lentezza non è una condanna né un mistero: si diagnostica e si cura, a patto di procedere con metodo invece che a tentativi.

La lentezza ha sempre un indirizzo

"Il sito è lento" è un sintomo unico, ma le cause abitano in posti diversi: la rete e l'hosting, la versione di PHP e la sua configurazione, il database MySQL, il tema e i moduli, il front-end con i suoi script. Ogni livello ha rimedi propri, e un intervento sul livello sbagliato non produce nulla.

L'errore più comune è proprio questo: passare a un hosting più costoso senza sapere dove si perde tempo. Se il collo di bottiglia è un modulo che esegue centinaia di query per comporre la home, raddoppiare la RAM del server sposta poco: la spesa aumenta, l'attesa resta.

Misurare prima di toccare

La diagnosi separa due famiglie di tempo. C'è il tempo che il server impiega a generare la pagina, che si legge nel TTFB, il Time To First Byte, e c'è il tempo che il browser impiega a renderla usabile, misurato dai Core Web Vitals. Un TTFB alto punta a server, PHP, database o cache; un TTFB buono con una pagina comunque pigra punta a tema, immagini e script.

Gli strumenti ci sono già. PageSpeed Insights inquadra il front-end. Per il lato server, PrestaShop include un profiler integrato: attivandolo si vede, pagina per pagina, quanto tempo va in PHP, quante query vengono eseguite e quali sono le più costose. Sul database, lo slow query log di MySQL registra le interrogazioni oltre soglia. Un esempio concreto: se la home risponde in 1,8 secondi e il profiler mostra 900 query, il problema non è lo slider delle immagini, è chi compone quella pagina.

::cta{variant="inline" title="Il tuo PrestaShop rallenta proprio quando vende di più?" text="Facciamo noi la diagnosi: misuriamo TTFB, query e moduli, troviamo il collo di bottiglia e ti diciamo cosa conviene sistemare, prima di toccare qualsiasi cosa." button="Chiedi una diagnosi gratuita →"}

Lato server: PHP, OPcache e MySQL

PrestaShop è un'applicazione PHP, e la versione di PHP conta: ogni release recente esegue lo stesso codice più in fretta della precedente, e le versioni vecchie oltre a essere lente non ricevono più correzioni di sicurezza. Accanto alla versione serve OPcache, l'estensione che tiene in memoria il codice già compilato invece di ricompilarlo a ogni richiesta:

; /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=40000
; in produzione: niente ricontrolli dei file a ogni richiesta,
; la cache si svuota al deploy
opcache.validate_timestamps=0

Sul fronte database, la regola d'oro di MySQL è un InnoDB buffer pool dimensionato in modo che i dati caldi del negozio stiano in memoria: se il buffer è troppo piccolo, ogni pagina prodotto paga letture su disco che potrebbero essere evitate. Completano il quadro un pool PHP-FPM proporzionato a CPU e RAM disponibili e lo slow query log attivo, così le query problematiche si vedono invece di sospettarle.

Moduli e tema: i soliti sospetti

Ogni modulo installato aggiunge hook che scattano a ogni pagina, query in più, a volte chiamate a servizi esterni che tengono in ostaggio la risposta. Il marketplace è pieno di moduli scritti bene e di moduli scritti male, e uno solo di questi ultimi basta: il classico difetto è la query ripetuta per ogni prodotto in elenco invece di una sola per tutto l'elenco.

La cura è poco glamour ma efficace: inventario dei moduli, disattivazione di quelli inutilizzati o doppioni, e per i sospetti la prova del nove, disattivare e rimisurare. Lo stesso vale per il tema, dove gli override accumulati negli anni possono riscrivere pezzi di piattaforma in modo meno efficiente dell'originale.

La cache giusta al posto giusto

La cache in un PrestaShop lavora a strati: la cache dei template Smarty, la cache interna della piattaforma, una full page cache davanti a tutto per le pagine uguali per tutti i visitatori, servita idealmente da un reverse proxy, e una CDN per immagini e asset statici.

Due avvertenze. La prima: la cache nasconde il codice lento, non lo ripara, e carrello, checkout e aree utente restano dinamici per natura, quindi un backend sano serve comunque. La seconda: una cache configurata male fa danni peggiori della lentezza, dal prezzo vecchio mostrato al cliente al carrello di un altro utente. Va progettata, non semplicemente accesa.

L'hosting conta, ma non è sempre colpa sua

Sull'hosting condiviso le risorse si dividono con i vicini: CPU, disco e database possono rallentare per colpe altrui, e i limiti si sentono appena il negozio cresce. Il passaggio a un VPS o al cloud dimensionato sul traffico reale è spesso il momento di svolta, e la scelta del provider merita gli stessi criteri di qualunque infrastruttura seria.

Resta però l'ordine giusto delle cose: l'hardware più potente applicato a un negozio con 900 query in home è un modo elegante di pagare di più lo stesso problema. Prima la diagnosi, poi il dimensionamento.

In sintesi

Un PrestaShop lento si affronta in sequenza: misurare TTFB e front-end per capire il lato del problema, leggere profiler e slow query log, sistemare le fondamenta del server (PHP recente, OPcache, MySQL con memoria adeguata), fare pulizia di moduli e override, stratificare la cache dove serve e, solo a quel punto, dimensionare l'hosting sul traffico vero. Ogni passo si verifica rimisurando: se un intervento non cambia i numeri, non era il collo di bottiglia.

::cta{title="Vuoi un PrestaShop veloce anche sotto carico?" text="Ottimizziamo e-commerce PrestaShop su tutta la filiera: hosting, PHP, MySQL, moduli e cache, con misure prima e dopo per vedere il risultato nero su bianco." button="Parliamone →"}

Fonti

OpenTofu: l'alternativa a Terraform dopo il cambio di licenza

Alessandro Corbelli — Thu, 13 Aug 2026 00:00:00 GMT

Immagina di aver costruito la tua casa seguendo le regole di un certo comune. Un giorno il comune cambia il regolamento edilizio, e alcune cose che facevi liberamente ora richiedono un permesso, o non sono più concesse. La casa è già in piedi, ma le regole del gioco sono cambiate a lavori fatti. È più o meno quello che è successo nel 2023 a chi usa Terraform, lo strumento più diffuso per descrivere l'infrastruttura come codice, cioè per gestire server, reti e firewall scrivendoli in file di testo invece di configurarli a mano.

L'azienda che sviluppa Terraform, HashiCorp, ha cambiato la licenza del prodotto, rendendola più restrittiva. In risposta, parte della comunità che usava e contribuiva a Terraform ha creato una versione derivata e indipendente, chiamata OpenTofu, oggi mantenuta come progetto open source neutrale. Per chi gestisce infrastruttura, o si affida a qualcuno che lo fa, capire questa vicenda serve a una cosa concreta: sapere su cosa si sta appoggiando il proprio lavoro, e quali alternative esistono.

Cosa è successo alla licenza di Terraform

Fino all'agosto 2023 Terraform era distribuito con una licenza open source vera e propria, la MPL 2.0: chiunque poteva usarlo, modificarlo e ridistribuirlo senza vincoli particolari. Poi HashiCorp è passata alla Business Source License (BSL), una licenza che si definisce source-available: il codice resta visibile e usabile da quasi tutti, ma con un limite. Non si può più usare Terraform per costruire un prodotto che compete con HashiCorp stessa.

La differenza sembra tecnica, ma il punto pratico è semplice. Una licenza open source riconosciuta garantisce che nessuno, in futuro, possa cambiare le regole e limitare l'uso di ciò che hai adottato. Una licenza source-available come la BSL toglie questa garanzia: il proprietario decide cosa è concesso e cosa no, e può rivederlo. Per la stragrande maggioranza di chi usa Terraform per gestire i propri server non cambia nulla nell'immediato, ma per l'ecosistema, cioè le aziende e i progetti costruiti attorno allo strumento, il segnale è stato pesante. Chi aveva investito anni su una tecnologia libera si è ritrovato con regole diverse decise da una sola azienda. Poco dopo, tra l'altro, HashiCorp è stata acquisita da IBM, il che ha reso ancora più concreta la domanda: di chi ti fidi quando scegli lo strumento che regge la tua infrastruttura?

Cos'è OpenTofu e chi lo governa

Nel giro di poche settimane dal cambio di licenza, un gruppo di aziende e sviluppatori ha annunciato un fork di Terraform. Un fork è una copia del codice che prosegue per una strada propria, indipendente dall'originale. Il progetto ha preso il nome di OpenTofu ed è stato affidato non a una singola azienda, ma alla Linux Foundation, la stessa fondazione indipendente che ospita Linux e, più di recente, lo standard MCP per collegare le AI agli strumenti esterni.

Questo passaggio è il cuore della vicenda. OpenTofu è tornato a una licenza open source riconosciuta (la stessa MPL 2.0 che Terraform aveva prima), e la sua governance, cioè chi decide come evolve, non è più in mano a una sola azienda ma a una comunità sotto una fondazione neutrale. Il vantaggio non è ideologico: è una garanzia contrattuale che la storia del cambio di licenza non si ripeta. Nessuno può un domani rendere OpenTofu source-available a lavori fatti, perché non c'è un unico proprietario che possa deciderlo. Per chi costruisce sopra uno strumento, sapere che le regole non cambieranno sotto i piedi vale quanto le funzionalità.

::cta{variant="inline" title="La tua infrastruttura dipende da uno strumento di terze parti?" text="Valutiamo insieme quanto sei legato a una singola tecnologia e quali alternative aperte riducono il rischio." button="Chiedi una valutazione →"}

Terraform o OpenTofu: cosa cambia in pratica

La notizia migliore per chi usa Terraform è che OpenTofu è nato come sostituto compatibile. Nei primi tempi si comportava come una copia fedele: gli stessi file di configurazione, lo stesso linguaggio HCL, gli stessi provider (i componenti che traducono la descrizione nelle chiamate ai vari provider cloud). Il comando da riga di comando cambia solo nel nome: si scrive tofu al posto di terraform, e nella maggior parte dei casi tutto il resto resta identico.

# Prima
terraform init
terraform plan
terraform apply

# Con OpenTofu, stessi file e stesso flusso
tofu init
tofu plan
tofu apply

Col tempo i due progetti hanno iniziato a divergere, ognuno aggiungendo funzioni proprie. OpenTofu, per esempio, ha introdotto la cifratura dello stato: il file di stato è il registro che lo strumento tiene di ciò che ha già creato, e spesso contiene informazioni sensibili, quindi poterlo cifrare è utile per la sicurezza. Terraform, dal canto suo, prosegue con la propria roadmap. Questo significa che la compatibilità perfetta vale soprattutto per chi migra da versioni non recentissime, mentre chi usa le ultime funzioni di uno dei due deve verificare caso per caso. Per un progetto tipico, però, la migrazione resta indolore: si punta OpenTofu ai file esistenti e allo stato attuale, si lancia un'anteprima delle modifiche, e se non risultano cambiamenti indesiderati si continua a lavorare come prima.

Quando conviene passare? Non c'è un obbligo, e Terraform resta perfettamente funzionante. La scelta di OpenTofu ha senso soprattutto quando conta avere una tecnologia realmente open source e a governance neutrale: per evitare il lock-in, cioè la dipendenza da un fornitore che può cambiare le condizioni, per ragioni di policy aziendale, o semplicemente per stare su un progetto guidato dalla comunità. È la stessa logica di prudenza che vale per ogni pezzo di software di terzi da cui si dipende, dai pacchetti che finiscono nelle applicazioni allo strumento che governa i server.

In sintesi

Nel 2023 Terraform è passato da una licenza open source a una più restrittiva, e la comunità ha risposto creando OpenTofu, un fork tornato open source e affidato alla Linux Foundation. La differenza pratica quotidiana per chi gestisce infrastruttura è minima, perché OpenTofu è nato compatibile e la migrazione è quasi sempre un cambio di comando. La differenza vera è di garanzie: con OpenTofu le regole d'uso non dipendono da una singola azienda e non possono cambiare a lavori fatti. Terraform resta lo strumento più diffuso e una scelta valida, ma non è più l'unico, e conoscere l'alternativa è il primo passo per non restare legati a una tecnologia che non controlli.

::cta{title="Vuoi un'infrastruttura che non dipenda da un solo fornitore?" text="Progettiamo e gestiamo infrastruttura come codice con Terraform e OpenTofu, su AWS, Google Cloud e altri provider, con attenzione a lock-in e continuità nel tempo." button="Parliamone →"}

Fonti

Cos'è una pipeline CI/CD (e perché il deploy manuale costa più di quanto sembra)

Alessandro Corbelli — Thu, 20 Aug 2026 00:00:00 GMT

In molte aziende il rilascio di un sito o di un'applicazione è ancora un gesto manuale. Una persona apre il terminale, lancia una sequenza di comandi che ha imparato a memoria, aspetta, ricarica la pagina e incrocia le dita. Se il sito si vede, si passa ad altro. Se non si vede, comincia la caccia: cosa è cambiato, chi ha toccato cosa, com'era prima.

Il problema non è la competenza di chi lancia i comandi. Il problema è che un rilascio fatto a mano è una procedura non scritta: leggermente diversa ogni volta, impossibile da controllare prima, e legata a una persona sola. Quando quella persona è in ferie, ha fretta o cambia lavoro, il rilascio diventa un rischio.

Una pipeline CI/CD è la risposta a questo problema. È l'idea di scrivere una volta per tutte cosa deve succedere quando il codice cambia, e lasciare che sia una macchina a eseguirlo, sempre allo stesso modo, verificando prima di pubblicare.

Integrazione continua: il codice viene controllato da qualcun altro

La prima metà della sigla è CI, continuous integration, integrazione continua. L'idea è semplice: ogni volta che qualcuno salva il proprio lavoro nel repository condiviso, una macchina neutra scarica il progetto da zero, installa tutto quello che serve e esegue i controlli.

Quel "da zero" è la parte che conta. Sul computer di chi sviluppa il progetto funziona anche grazie a cose installate mesi prima e dimenticate: una libreria di sistema, una variabile d'ambiente, un file di configurazione mai versionato. La macchina della CI non ha quella memoria. Se il progetto funziona lì, funziona davvero, e la frase più cara al settore, "sul mio computer funziona", smette di essere un'opinione.

Il vantaggio pratico è il momento in cui scopri il problema. Un test che fallisce due minuti dopo il salvataggio costa cinque minuti di lavoro, perché hai ancora in testa cosa stavi facendo. Lo stesso problema scoperto in produzione tre settimane dopo costa una giornata, più la telefonata del cliente.

Consegna continua: dal codice verificato al sito online

La seconda metà è CD, e vale la pena distinguere due significati che spesso si confondono.

La continuous delivery, consegna continua, significa che il codice verificato è sempre pronto per andare in produzione, e la pubblicazione avviene quando qualcuno preme un pulsante. Il continuous deployment, distribuzione continua, va oltre: se tutti i controlli passano, la pubblicazione avviene da sola, senza intervento umano.

Non sono livelli di bravura, sono scelte diverse: un e-commerce che rilascia venti volte al giorno guadagna dalla distribuzione automatica, uno studio che aggiorna il gestionale di un cliente una volta al mese vive benissimo con il pulsante. Quando si parte conviene il pulsante: si ottiene quasi tutto il valore, e si mantiene il controllo su quando le cose cambiano.

::cta{variant="inline" title="Il rilascio in produzione dipende da chi si ricorda i comandi?" text="Mettiamo per iscritto la procedura, la facciamo eseguire a una macchina e aggiungiamo un controllo prima di ogni pubblicazione." button="Chiedi una verifica →"}

Com'è fatta una pipeline, in concreto

Una pipeline è un file di testo, versionato insieme al codice, che descrive i passi da eseguire. Ecco la versione minima con GitHub Actions, uno dei sistemi più diffusi:

name: CI
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

Letto in italiano: a ogni salvataggio (on: push), accendi una macchina Linux pulita, scarica il codice, installa Node nella versione 22, installa le dipendenze esattamente come sono scritte nel file di blocco (npm ci, non npm install) ed esegui i test. Se un comando fallisce, la pipeline diventa rossa e chi ha fatto la modifica riceve una notifica.

Fissare la versione di Node non è pignoleria: è la stessa ragione per cui conviene dichiarare la versione del runtime nel progetto. Una pipeline che usa "l'ultima versione disponibile" un giorno si rompe da sola, senza che nessuno abbia toccato niente.

Da qui si cresce aggiungendo la pubblicazione, che avviene solo se i test sono passati e solo dal ramo principale:

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - run: ./deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Le due righe importanti sono needs: test, che impedisce di pubblicare codice non verificato, e if:, che limita la pubblicazione al ramo principale: il lavoro su un ramo secondario viene controllato ma non va online.

Lo stesso concetto, sistemi diversi

Il modo di scrivere cambia, l'idea no. La stessa pipeline su GitLab CI si scrive così:

stages:
  - test
  - deploy

test:
  image: node:22
  script:
    - npm ci
    - npm test

deploy:
  stage: deploy
  only:
    - main
  when: manual
  script:
    - ./deploy.sh

Qui when: manual è la consegna con pulsante di cui sopra: il lavoro viene preparato in automatico, la pubblicazione la decide una persona. Esistono anche Forgejo e Gitea, che ospitano il codice in casa con una sintassi quasi identica a quella di GitHub Actions, e sistemi storici come Jenkins che fanno la stessa cosa da vent'anni. La scelta dello strumento conta molto meno della decisione di avere una procedura scritta.

Un termine da conoscere: la macchina che esegue i passi si chiama runner. Può essere fornita dal servizio, e paghi al minuto, oppure essere una tua macchina se il codice non deve uscire dalla rete aziendale. Nel secondo caso va installata, aggiornata e isolata, perché esegue codice a ogni modifica del progetto.

Cosa conviene metterci dentro

L'ordine giusto dei passi va dal più veloce al più lento, così un errore banale non ti fa aspettare dieci minuti prima di saperlo:

Controlli di forma: formattazione e analisi statica, pochi secondi.
Test automatici: il cuore della verifica.
Compilazione: se il progetto non si compila, è inutile andare oltre.
Controlli specifici del progetto: qui sta la parte che quasi nessuno sfrutta.
Pubblicazione.

Il punto 4 merita un esempio, perché è dove una pipeline smette di essere generica e diventa tua. Un controllo è semplicemente un comando che esce con codice zero se va tutto bene e con un codice diverso se qualcosa non va:

#!/usr/bin/env bash
set -euo pipefail

if grep -rn "console.log" src/; then
  echo "Trovate chiamate di debug dimenticate in src/"
  exit 1
fi

Con la stessa logica si verificano cose che non sono codice: immagini troppo pesanti caricate per sbaglio, link interni che puntano a pagine inesistenti, file di traduzione disallineati tra due lingue, regole editoriali di un blog. Sono tutti errori che nessuno trova rileggendo, e che una macchina trova sempre.

I segreti, cioè la parte che si sbaglia più spesso

Per pubblicare servono credenziali: un token del provider, una chiave SSH, una password di database. Tre regole, in ordine di importanza.

Mai nel repository. Un token scritto in un file versionato resta nella cronologia anche dopo averlo cancellato: rimuoverlo dal file non lo rimuove dai salvataggi precedenti. Se succede, l'unica risposta seria è cambiare quel token. È un tema abbastanza denso da meritare un articolo a parte, dove entriamo nel dettaglio di dove mettere davvero i segreti di una pipeline.

Nel sistema CI, con le protezioni attive. Le due impostazioni da cercare sono il mascheramento, che impedisce alla credenziale di comparire nei registri di esecuzione, e la limitazione ai rami protetti. Senza quelle, il token è leggibile da chiunque possa modificare il file della pipeline.

Con il minimo dei privilegi. Il token che pubblica il sito deve poter pubblicare il sito, non amministrare l'intero account.

C'è un ultimo aspetto che si tende a ignorare: la pipeline installa dipendenze, e installare dipendenze significa eseguire codice scritto da altri su una macchina che ha in mano le credenziali di produzione. È il motivo per cui vale la pena sapere cosa succede quando un pacchetto viene compromesso e perché il runner andrebbe isolato dal resto dell'infrastruttura.

Cosa costa, detto onestamente

Una pipeline non è gratis: va scritta, va mantenuta, e ogni tanto si rompe per conto suo perché scade un token o cambia una versione. Su progetti minuscoli, con un solo sviluppatore e un rilascio ogni sei mesi, può non valerne la pena.

C'è poi un rischio culturale, ed è il più serio: una pipeline rossa da settimane non è una pipeline, è un semaforo guasto. Se il rosso diventa normale, le persone imparano a ignorarlo e i controlli non servono più a niente. Il verde deve essere lo stato ordinario: quando un controllo produce troppi falsi allarmi, o lo si sistema o lo si toglie, ma non lo si lascia lampeggiare.

Infine, la pipeline verifica solo ciò che le hai chiesto di verificare. Non sostituisce il ripristino di un backup, che va comunque provato davvero, né la possibilità di tornare indietro in fretta quando qualcosa passa lo stesso.

In sintesi

Una pipeline CI/CD trasforma il rilascio da procedura ricordata a memoria in un documento eseguibile: l'integrazione continua verifica ogni modifica su una macchina pulita, la consegna continua porta in produzione ciò che ha superato i controlli, con o senza un pulsante di mezzo. Si scrive in un file di testo versionato insieme al codice e funziona allo stesso modo su GitHub Actions, GitLab CI o un sistema ospitato in casa. Come per l'infrastruttura descritta in file di testo, il guadagno vero non è la velocità: è smettere di affidare a una persona sola qualcosa che l'azienda fa ogni settimana.

::cta{title="Vuoi che il tuo software vada online solo quando i controlli passano?" text="Progettiamo e manteniamo pipeline su GitHub Actions, GitLab CI e runner ospitati in casa, per applicazioni su misura, siti e servizi in cloud. Ci occupiamo anche della gestione delle credenziali e della procedura per tornare indietro in fretta." button="Parliamone →"}

Fonti

Proxmox VE 8 a fine vita: perché aggiornare ora e cosa cambia con la 9

Alessandro Corbelli — Sun, 23 Aug 2026 00:00:00 GMT

Se nella tua azienda c'è un server che fa girare macchine virtuali, c'è una buona probabilità che sopra ci sia Proxmox VE 8: è uscito a giugno 2023 ed è stato per tre anni la versione che tutti installavano. Il 31 agosto 2026 esce dal supporto. Da quel giorno Proxmox non pubblica più correzioni per la versione 8, né per i bug né per le falle di sicurezza. L'interfaccia web della 8 lo segnala già da tempo con un avviso nella barra in alto, con la data precisa.

Non succede niente di visibile. I server restano accesi, le macchine virtuali continuano a funzionare, nessun contatore scade. È esattamente questo il problema: un hypervisor (il software che fa girare le macchine virtuali su un server fisico) sta sotto a tutto il resto, e quando smette di ricevere patch il rischio si sposta in silenzio su ogni servizio che ospita.

Qui sotto: cosa significa in pratica la fine del supporto, cosa si rischia restando sulla 8, cosa si rompe nel passaggio alla 9 e come si affronta l'aggiornamento senza fermare l'azienda. Tutte le informazioni vengono dalle fonti ufficiali Proxmox, linkate in fondo.

Fine del supporto: cosa significa per un hypervisor

La regola di Proxmox è pubblica: ogni versione di Proxmox VE è supportata almeno finché la versione di Debian su cui si appoggia è supportata dal team di sicurezza di Debian, cioè circa tre anni dalla prima uscita. Proxmox VE 8 è costruito su Debian 12 "Bookworm", il cui supporto di sicurezza ordinario si è chiuso a metà 2026, e la tabella ufficiale del ciclo di vita fissa la fine del supporto di Proxmox VE 8 ad agosto 2026. L'ultimo aggiornamento del ramo 8, la versione 8.4.21, è del 14 agosto.

Un dettaglio che genera confusione: Debian 12 passa ora al supporto LTS, gestito da un gruppo separato di volontari e aziende, fino a metà 2028. Quel supporto riguarda i pacchetti Debian, non Proxmox. Il kernel, QEMU (il motore delle macchine virtuali), LXC (i container), ZFS e tutto lo strato di gestione del cluster sono pacchetti che mantiene Proxmox, e nella versione 8 non li mantiene più. Contare sulla LTS di Debian per un hypervisor a fine vita è un equivoco.

È lo stesso meccanismo che abbiamo descritto per PHP a fine vita: il software non smette di funzionare, smette di essere difeso. Solo che qui la superficie esposta non è un sito, è il server intero.

Cosa rischia chi resta sulla 8

Vulnerabilità senza rimedio. Le falle si scoprono comunque, anche dopo la fine del supporto: si ferma solo la distribuzione delle correzioni. Anche nel 2026 il ramo 8.4 ha continuato a ricevere aggiornamenti con impatto sulla sicurezza: ad aprile l'autenticazione delle console VNC e SPICE è stata irrobustita, ad agosto sono stati rafforzati i permessi richiesti per interrompere i backup e la protezione di alcuni campi dell'interfaccia da contenuti non filtrati. Da settembre, correzioni di questo tipo per la 8 non arrivano più. E una falla nell'hypervisor vale quanto una falla in ciascuna delle macchine che ospita.

L'ecosistema si sposta. Proxmox Backup Server è già alla versione 4, la release più recente di Ceph (lo storage distribuito integrato) è disponibile solo dalla 9.2, i plugin di storage di terze parti vengono adattati alla 9. Il supporto all'hardware nuovo arriva con i kernel recenti: Proxmox VE 9.2 monta il kernel 7.0, la 8 resta al 6.8 (6.14 come opzione). Chi compra un server oggi e lo installa con la 8 rischia di scoprire che schede di rete o controller non sono riconosciuti.

Nessuna scorciatoia in futuro. Proxmox documenta e supporta solo il passaggio da una versione maggiore alla successiva: dalla 7 si passa per la 8, dalla 8 si arriva alla 9, e il salto si allunga a ogni anno di attesa.

La conformità. Per chi tratta dati personali il GDPR chiede misure "adeguate allo stato dell'arte": come abbiamo visto parlando di GDPR lato infrastruttura, un componente abbandonato dal produttore è difficile da difendere come adeguato, e in caso di incidente la versione dell'hypervisor finisce nel verbale.

::cta{variant="inline" title="Non sai quanti host Proxmox 8 hai in produzione, o se sono pronti per la 9?" text="Facciamo noi il censimento: versione, storage, container vecchi, hardware, backup. Ti diciamo cosa si può aggiornare subito e cosa va preparato prima." button="Chiedi una verifica →"}

Cosa porta in più Proxmox VE 9

L'aggiornamento non è solo togliersi un rischio. Proxmox VE 9 è uscito ad agosto 2025 su Debian 13 "Trixie" ed è già alla terza release (9.2, maggio 2026): una piattaforma rodata da un anno, non una novità da aspettare.

Snapshot anche sullo storage condiviso in LVM "thick", quello tipico delle SAN in iSCSI o Fibre Channel: prima non si potevano fare, ora sì, grazie alle catene di volumi (funzione in anteprima tecnologica, ma copre un caso molto comune nelle PMI con uno storage di rete). Se questi volumi ti suonano nuovi, abbiamo spiegato cos'è LVM e come gestisce i dischi.
Regole di affinità per l'alta disponibilità: si dichiara che certe VM devono stare su certi nodi, o che due VM non devono mai finire sullo stesso nodo. Con la 9.2 arriva anche il bilanciamento dinamico del carico, che sposta da solo le VM dal nodo più carico a quello più scarico.
ZFS 2.3 (2.4 nella 9.2), che permette di aggiungere un disco a un RAID-Z esistente senza ricostruirlo da zero.
Fabric SDN (OpenFabric e OSPF, dalla 9.2 anche WireGuard e BGP) per collegare i nodi con reti instradate invece che con cavi incrociati configurati a mano: utile per i cluster Ceph a maglia completa.
Container da immagini OCI (dalla 9.1): gli stessi formati usati per Docker diventano template per container LXC.
Kernel, QEMU e LXC aggiornati (kernel 6.14 nella 9.0 e 7.0 nella 9.2, QEMU 10 e poi 11) e una nuova interfaccia per smartphone.

Cosa si rompe: le incompatibilità verso il basso

È la parte che la guida ufficiale chiama breaking changes, e va letta prima, non dopo. Tradotta in situazioni concrete:

Container vecchi. La 9 elimina il supporto a cgroup v1, il vecchio sistema con cui il kernel assegna risorse ai container. Conseguenza: i container con un sistema operativo basato su systemd versione 230 o precedente (del 2016) non partono più. Gli esempi citati da Proxmox sono CentOS 7 e Ubuntu 16.04. Se ne hai, il sistema operativo dentro il container va migrato prima di aggiornare l'host, non dopo.
I nomi delle schede di rete possono cambiare con il nuovo kernel, e se la configurazione punta al nome vecchio il server riparte senza rete. Proxmox fornisce uno strumento per fissare i nomi prima di aggiornare (pve-network-interface-pinning) e raccomanda un accesso indipendente dalla rete (IPMI, iKVM o console fisica) per non dover correre in sala server.
Storage. GlusterFS non è più supportato: i dati vanno spostati altrove. I plugin di storage di terze parti funzionano solo se l'autore li ha adattati alla 9. Sui volumi LVM condivisi va eseguito lo script ufficiale che disattiva l'autoattivazione dei volumi, per evitare che più nodi attivino gli stessi dischi.
Hardware datato. Proxmox dichiara che l'hardware con più di dieci anni non è testato a fondo con il nuovo kernel, cita CPU AMD Opteron e Turion del 2009-2010 su cui Ceph si ferma con un errore di istruzione illegale, e segnala che in alcuni casi il passthrough di schede PCI (per esempio una GPU assegnata a una VM) non parte con il kernel 6.14. Per le schede NVIDIA vGPU serve almeno il driver GRID 18.3.
Backup di terze parti. Veeam non funziona con le VM che usano la versione macchina QEMU 10 o successiva; il rimedio è fissare la versione macchina alla 9.2 finché Veeam non si adegua. Chi ha Proxmox Backup Server installato sulla stessa macchina deve aggiornare anche quello, alla versione 4, seguendo la guida dedicata.
Dettagli di sistema che non perdonano. Il file /etc/sysctl.conf non viene più letto (le impostazioni vanno in /etc/sysctl.d/), /tmp diventa una cartella in memoria ripulita periodicamente, alcuni permessi cambiano (il privilegio VM.Monitor sparisce, nasce VM.Replicate, creare container privilegiati richiede Sys.Modify), l'opzione maxfiles dei backup viene rimossa, le schede di rete VirtIO senza MTU esplicita ereditano quello del bridge invece di 1500. Niente di drammatico, ma tutto da sapere prima.

Il punto non è spaventare: ognuna di queste voci o non ti riguarda o si risolve prima di partire, e la differenza la fa averle controllate.

Come si aggiorna senza fermare l'azienda

Proxmox fornisce una guida ufficiale passo passo e uno strumento, pve8to9, che controlla l'host e segnala in anticipo tutto ciò che è elencato sopra. Il metodo che seguiamo noi:

Inventario. Quanti host, che versione (serve almeno la 8.4.1), che storage, che Ceph (deve essere già Squid 19.2), quali container e con quale sistema operativo, che hardware e di che anno.
Checklist pve8to9 --full su ogni nodo, risolvendo ogni avviso prima di procedere. Lo strumento controlla e basta, non corregge nulla da solo.
Rete di sicurezza. Backup verificati di tutte le VM e i container secondo la regola del 3-2-1, copia della configurazione di /etc, accesso fuori banda al server e almeno 5 GB liberi sulla partizione di sistema.
Un nodo alla volta. In un cluster si spostano le VM sugli altri nodi con la migrazione a caldo, si aggiorna il nodo vuoto, si riavvia, si verifica, si passa al successivo: i servizi non si fermano mai. Su un host singolo serve una finestra di manutenzione: il solo apt dist-upgrade va da meno di cinque minuti su SSD a oltre un'ora su dischi meccanici, più il riavvio.
Verifica finale. Riavvio nel nuovo kernel, controllo di rete e storage, migrazione automatica dei gruppi HA in regole, pulizia della cache del browser per la nuova interfaccia, passaggio dei repository al nuovo formato.

Per un'installazione pulita (per esempio su hardware nuovo) c'è anche la reinstallazione da ISO con ripristino delle VM dai backup: spesso è la strada più rapida quando si cambia server insieme alla versione.

In sintesi

Proxmox VE 8 non si spegne il 31 agosto 2026, ma da quel giorno ogni falla nuova resta aperta sul server che regge tutte le tue macchine virtuali, e la LTS di Debian non copre i componenti Proxmox. La versione 9 è matura da un anno, porta snapshot sullo storage condiviso, alta disponibilità più intelligente e supporto all'hardware recente, e l'aggiornamento è un percorso documentato: la parte delicata sono le incompatibilità (container vecchi, nomi di rete, storage, hardware datato, backup di terze parti), che si trovano tutte prima di partire con un inventario e la checklist ufficiale.

::cta{title="Hai host Proxmox 8 in produzione e vuoi passare alla 9 senza sorprese?" text="Pianifichiamo e facciamo noi l'aggiornamento: censimento degli host, checklist pve8to9, backup verificato, migrazione delle VM a caldo nei cluster, finestra concordata sugli host singoli e rientro garantito. Gestiamo server Linux e Proxmox per PMI e agenzie." button="Parliamone →"}

Fonti

Secrets nelle pipeline: come non finire con le chiavi su GitHub

Alessandro Corbelli — Thu, 27 Aug 2026 00:00:00 GMT

Una pipeline che pubblica in produzione ha bisogno di credenziali: un token del provider cloud, una chiave SSH, la password di un database. Sono le chiavi di casa, consegnate a una macchina che lavora da sola a ogni modifica del codice.

Il modo in cui quelle chiavi vengono conservate è il punto più delicato di tutta l'automazione, e anche quello che si sbaglia più spesso. Non per ignoranza: si sbaglia di fretta, il venerdì, quando il rilascio deve partire e la strada breve funziona subito. Un token incollato dentro un file di configurazione fa esattamente il suo lavoro, e nessuno se ne accorge finché non è troppo tardi.

Vediamo dove vanno messe davvero, cosa fare quando ne è già uscita una, e qual è oggi la soluzione migliore: smettere del tutto di avere chiavi da conservare.

Un segreto nel repository non si cancella

La prima regola è che una credenziale non va mai scritta in un file versionato. Il motivo non è ovvio: il problema non è il file, è la cronologia.

Git conserva ogni versione precedente di ogni file. Se scrivi un token in un file e domani lo cancelli, il file di oggi è pulito, ma il salvataggio di ieri contiene ancora la credenziale, e resta consultabile da chiunque abbia accesso al repository, per sempre. Chi arriva sei mesi dopo non deve nemmeno cercare: basta scorrere le modifiche.

Da qui discende una conseguenza che sorprende sempre: cancellare il segreto non risolve niente. Se una credenziale è finita in un repository, quella credenziale va considerata compromessa e va sostituita, cioè revocata sul servizio che l'ha emessa e rigenerata. Riscrivere la cronologia è possibile, con strumenti pensati apposta, ma è un'operazione invasiva che rompe le copie di tutti e non ti dà comunque nessuna garanzia su chi ha già letto.

Se il repository è pubblico, il tempo a disposizione è ancora minore: esistono programmi che sorvegliano le pubblicazioni su GitHub in tempo reale cercando credenziali, e i minuti tra la pubblicazione e l'uso sono davvero pochi. GitHub stesso analizza il codice pubblico alla ricerca di chiavi note e avvisa il fornitore che le ha emesse, che spesso le revoca d'ufficio. È una rete di sicurezza, non una soluzione.

Il posto giusto: il magazzino del sistema CI

Ogni sistema di pipeline CI/CD ha un posto dove conservare le credenziali fuori dal codice: si chiamano secrets su GitHub Actions, variabili CI/CD su GitLab. Il valore si inserisce una volta dall'interfaccia, e nella pipeline si usa solo il nome:

- run: ./deploy.sh
  env:
    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Chi legge il file vede DEPLOY_TOKEN, non il suo valore. Ma metterli lì non basta: contano due impostazioni che quasi nessuno cerca.

Il mascheramento impedisce che il valore compaia nei registri di esecuzione. Senza, basta un comando che stampa l'ambiente, o un errore un po' loquace di un programma, perché la credenziale finisca in chiaro in un registro che di solito è leggibile da molte più persone di quante possano vedere le impostazioni.

La limitazione ai rami protetti decide quali esecuzioni ricevono il segreto. È la protezione più importante e la meno usata: senza, chiunque possa creare un ramo nel progetto può scrivere una pipeline di tre righe che stampa il token e leggerselo con calma. Se il segreto è riservato al ramo principale, e il ramo principale accetta modifiche solo dopo revisione, quella strada si chiude.

::cta{variant="inline" title="Sai dire quali credenziali stanno oggi nei tuoi repository?" text="Facciamo una ricognizione su repository e pipeline: cosa è esposto, cosa va sostituito subito, cosa va spostato altrove." button="Chiedi una ricognizione →"}

Il salto di qualità: nessuna chiave da conservare

La protezione migliore per una chiave è non averla. Da qualche anno i sistemi CI più diffusi permettono di autenticarsi al provider senza credenziali permanenti, con un meccanismo che si chiama OIDC (OpenID Connect).

Funziona così. Al momento dell'esecuzione, il sistema CI genera un documento firmato che attesta chi sta chiedendo: questo repository, questo ramo, questa esecuzione. La pipeline lo presenta al provider cloud, che lo verifica e, se corrisponde a una regola configurata in precedenza, restituisce credenziali temporanee, valide per pochi minuti.

Su GitHub Actions sono due blocchi:

permissions:
  id-token: write     # la pipeline può chiedere il documento di identità
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/deploy-sito
      aws-region: eu-south-1

Non c'è nessuna chiave da nessuna parte. Il ruolo deploy-sito, lato provider, è configurato per fidarsi solo di quel repository e solo di quel ramo: un altro progetto che provasse la stessa richiesta verrebbe rifiutato.

Il guadagno è grosso. Non c'è niente da rubare, perché le credenziali durano quanto l'esecuzione. Non c'è niente da ruotare ogni sei mesi, e quindi niente che scada di venerdì pomeriggio. E la fiducia è legata a un'identità verificabile invece che al possesso di una stringa, che è la stessa differenza che passa tra un documento e una chiave trovata per terra. Vale la pena adottarlo appena il provider lo supporta, e oggi lo supportano i principali.

Privilegi minimi, che vale anche per le identità

Chiave o identità temporanea che sia, resta la domanda: quanto può fare quella credenziale? La risposta corretta è: il minimo indispensabile.

Un token che pubblica un sito deve poter pubblicare quel sito. Non amministrare l'account, non leggere le altre applicazioni, non toccare i DNS. È una differenza che si sente solo il giorno dell'incidente, ed è quel giorno che decide se il danno è "hanno ripubblicato il sito" oppure "hanno in mano tutto".

Lo stesso ragionamento vale dentro la pipeline. Su GitHub Actions il blocco permissions limita cosa può fare l'esecuzione sul repository stesso: dichiararlo esplicitamente, invece di lasciare i valori predefiniti, evita che uno script eseguito nella pipeline possa scrivere dove non deve. Il principio è lo stesso che si applica a un accesso amministrativo ai server o a un'autorizzazione OAuth: un permesso concesso "per comodità" è un permesso che prima o poi verrà usato da qualcun altro.

Le tre trappole che vediamo più spesso

Le proposte di modifica da estranei. Se il progetto accetta contributi esterni, una pipeline che parte in risposta a una proposta di modifica esegue codice scritto da chi l'ha inviata. Su GitHub esiste un tipo di innesco, pull_request_target, che gira con i permessi del repository di destinazione: usarlo insieme al prelievo del codice proposto significa consegnare i propri segreti a uno sconosciuto. È una delle configurazioni sbagliate più sfruttate in assoluto.

Le dipendenze. La pipeline installa librerie, e installarle vuol dire eseguire codice altrui su una macchina che ha in mano le credenziali di produzione. Un pacchetto compromesso, come in tutti gli episodi visti su npm, legge le variabili d'ambiente e le spedisce fuori. Difese pratiche: bloccare gli script di installazione, congelare le versioni, e non passare i segreti agli stadi che non devono pubblicare. Chi esegue i test non ha bisogno del token di produzione.

I registri. Un comando lanciato con la variabile in linea, un curl -v che stampa le intestazioni, un errore che riporta l'URL completo con il token dentro: i registri di esecuzione sono spesso il punto da cui il segreto esce, e sono anche il posto dove nessuno pensa di guardare.

Se un segreto è già uscito

Nell'ordine, senza saltare passaggi. Revocare subito la credenziale sul servizio che l'ha emessa: è l'unica azione che ferma davvero l'emorragia, e va fatta prima di ogni altra cosa. Rigenerarne una nuova, con i permessi minimi che servono davvero, e metterla nel magazzino del sistema CI. Controllare cosa è stato fatto con quella vecchia, guardando i registri di accesso del provider nelle ore precedenti. Solo alla fine, se ha senso, ripulire il file.

E una volta sistemato, vale la pena aggiungere una rete: esistono programmi che analizzano il codice cercando credenziali e che si possono far girare automaticamente prima di ogni salvataggio, così la prossima chiave incollata di fretta viene fermata sul posto invece che scoperta sei mesi dopo.

In sintesi

I segreti di una pipeline non vanno nel repository, perché la cronologia di Git non dimentica e una credenziale finita lì va considerata bruciata: si revoca e si rigenera, non si cancella. Vanno nel magazzino del sistema CI, con il mascheramento nei registri e la limitazione ai rami protetti, che è quella che impedisce a un ramo qualsiasi di leggerseli. Meglio ancora, non vanno conservati affatto: con OIDC la pipeline dimostra chi è e riceve credenziali che durano minuti, quindi non c'è niente da rubare e niente da ruotare. Su tutto vale il principio dei privilegi minimi, che è ciò che decide se un incidente sarà una seccatura o un disastro.

::cta{title="Vuoi che a pubblicare in produzione sia un'identità temporanea, non una chiave eterna?" text="Rivediamo le pipeline che avete già: spostiamo le credenziali fuori dal codice, riduciamo i permessi al minimo e, dove il provider lo consente, passiamo a OIDC senza chiavi da conservare." button="Parliamone →"}

Fonti

MikroTik RouterOS sotto attacco: le falle SSH sfruttate e cosa fare subito

Alessandro Corbelli — Mon, 07 Sep 2026 00:00:00 GMT

Il 3 settembre 2026 MikroTik ha pubblicato un aggiornamento di sicurezza per RouterOS, il sistema operativo dei suoi router, definendolo "importante" e senza spiegare cosa correggesse. Due giorni dopo CERT Polska, il centro di risposta agli incidenti informatici polacco che aveva scoperto e segnalato i problemi, ha rotto il silenzio: sei vulnerabilità, due delle quali combinate permettono a chiunque di prendere il controllo completo del router senza conoscere alcuna password, a patto che il servizio SSH sia raggiungibile da internet. La catena di attacco ha un nome, MikroTrick, ed è già in uso: le intrusioni ricostruite risalgono almeno al 2 settembre, il giorno prima delle patch.

I router MikroTik sono ovunque dove serve un apparato di rete solido a un prezzo contenuto: uffici, studi professionali, piccoli provider, sedi collegate in VPN, rack di colocation. Spesso li ha installati un tecnico anni fa, funzionano, e nessuno li ha più aperti. È esattamente il profilo del dispositivo che questa vicenda mette a rischio.

Qui sotto: cosa è stato scoperto, chi è esposto davvero e chi no, come capire se un router è già stato violato, come si aggiorna e cosa cambiare in configurazione perché non capiti di nuovo. Le informazioni vengono dal bollettino MikroTik, dall'avviso di CERT Polska e dalla documentazione ufficiale, linkati in fondo.

Cosa è stato scoperto: sei falle, due bastano per entrare senza password

Le due vulnerabilità che formano la catena MikroTrick riguardano entrambe il server SSH di RouterOS, il servizio che permette di amministrare il router da riga di comando a distanza. Sono classificate con gravità 9,2 su 10.

CVE-2026-67276: quando un utente si autentica con una chiave crittografica invece che con una password, RouterOS non verificava la chiave per intero, ma solo una sua parte. Chi conosce la parte pubblica della chiave di un utente autorizzato può costruirne una diversa che il router accetta lo stesso, ed entrare come quell'utente senza possederne la chiave privata. È come una serratura che controlla la forma della chiave ma non i denti.
CVE-2026-86060: la procedura di accesso via SSH gestiva male i nomi utente che iniziano con un carattere non ammesso. Con un nome costruito ad arte, una sessione che dovrebbe avere permessi limitati ottiene i privilegi di amministratore completo.

Prese una alla volta hanno dei prerequisiti. Combinate, secondo CERT Polska, consentono "il controllo completo del dispositivo senza autenticazione". Le altre quattro falle sono meno gravi ma non trascurabili: una nel servizio bandwidth-test (lo strumento di misura della banda, porta 2000) permette senza autenticazione di leggere frammenti di memoria del sistema o di far riavviare il router; una nell'interfaccia web WebFig permette di leggere file riservati, compresi archivi di configurazione con credenziali; le ultime due toccano il client SSH integrato e la gestione dei certificati X.509.

Un dettaglio che spiega la corsa contro il tempo: MikroTik ha rilasciato la correzione senza dettagli, ma le patch di RouterOS sono pubbliche e confrontabili. Il 4 settembre era già online un'analisi indipendente che, mettendo a confronto la versione 7.23.3 con la 7.23.4, aveva ricostruito il meccanismo delle falle. A quel punto tacere non serviva più a nessuno, e CERT Polska ha pubblicato l'avviso il 5.

Chi è a rischio davvero (e chi no)

MikroTik scrive che "la maggior parte delle configurazioni non è a rischio". È vero, con una precisazione importante. La configurazione predefinita di un router MikroTik blocca l'accesso ai servizi di gestione dalla porta WAN, quindi un apparato installato con le impostazioni di fabbrica non espone SSH a internet e non è attaccabile da fuori.

Il problema sono tutti gli altri: i router configurati da zero da un tecnico, quelli in cui le regole del firewall sono state rimosse "per far funzionare una cosa", quelli in cui SSH è stato aperto per comodità di gestione remota, quelli dei provider e dei datacenter. La Shadowserver Foundation, una fondazione che scandaglia internet per conto dei CERT nazionali, il 5 settembre contava circa 122.500 router MikroTik con SSH raggiungibile da chiunque. Ognuno di quelli, se non aggiornato, si prende con uno script.

Le versioni coinvolte sono tante. Alla domanda di un utente sul forum ufficiale se anche le 7.20 e 7.21 fossero vulnerabili, lo staff MikroTik ha risposto che sono coinvolte "molte annate di versioni": la correzione esiste solo dalle release del 3 settembre. Non conta quanto è recente il router, conta quanto è recente il sistema operativo.

::cta{variant="inline" title="Non sai se il router MikroTik del tuo ufficio o del tuo rack ha SSH aperto su internet?" text="Lo verifichiamo da fuori e da dentro: versione di RouterOS, servizi esposti, tracce di accessi anomali. Ti diciamo se è pulito e cosa chiudere." button="Chiedi una verifica →"}

Come capire se il router è già stato violato

Prima di aggiornare vale la pena guardare, perché l'aggiornamento chiude la porta ma non caccia chi è già entrato. CERT Polska descrive cosa lasciano dietro di sé gli attacchi osservati:

nel registro eventi compaiono righe come login failure for user -2 from <ip> via ssh e subito dopo user <nome> added by ssh:-2@<ip>: quel -2 al posto del nome utente è la firma della falla sfruttata;
viene creato un utente amministratore sconosciuto, nei casi osservati chiamato ops;
compaiono script, attività pianificate, proxy o tunnel che nessuno ha configurato.

Dalla console del router i controlli sono questi:

/log/print where message~"-2"
/system/history/print
/user/print
/system/script/print
/system/scheduler/print
/ip/proxy/print
/ip/socks/print

Se il registro è già stato sovrascritto, e su un router lo è in fretta, l'assenza di righe sospette non prova nulla: contano gli utenti, gli script e le regole che non riconosci.

MikroTik ha aggiunto una rete di sicurezza in più. Le versioni corrette, al primo avvio, esaminano la configurazione alla ricerca di tracce note di compromissione: se le trovano, disattivano le voci sospette, scrivono un messaggio critico nel registro e impostano il router in stato Flagged. Si controlla con /system/device-mode/print. In quello stato il router continua a funzionare, ma non permette di creare nuove attività pianificate, proxy, tunnel VPN o condivisioni finché non si interviene di persona: per togliere il marcatore serve un comando confermato premendo il tasto fisico di reset o spegnendo l'apparato. La documentazione è chiara su due punti: lo stato Flagged non cancella la configurazione, che va comunque ispezionata riga per riga, e il meccanismo riconosce solo tracce note, quindi un router non marcato non è per forza pulito.

Cosa fare adesso: aggiornare, poi verificare

Le versioni corrette sono 7.24.2 (canale stable), 7.23.4 (long-term), 6.49.21 per chi è ancora sulla vecchia serie 6 e la 7.25beta3 per chi usa il canale di sviluppo. Dalla console:

/system/package/update/check-for-updates
/system/package/update/install

Il router si riavvia da solo al termine: su un apparato in produzione serve una finestra di pochi minuti. Prima dell'aggiornamento conviene esportare la configurazione con /export file=prima-aggiornamento e scaricare il file, per la stessa ragione per cui si fanno i backup prima di ogni intervento: se qualcosa va storto, si torna indietro.

Dopo l'aggiornamento, non prima:

controllare /system/device-mode/print e il registro eventi per il messaggio Flagged;
ripetere i controlli della sezione precedente su utenti, script, attività pianificate, proxy e tunnel;
cambiare tutte le password del router e rigenerare le chiavi SSH degli utenti, perché un attaccante che ha avuto accesso amministrativo può aver letto la configurazione completa, credenziali comprese;
se il router faceva da concentratore VPN, considerare compromesse anche le chiavi dei tunnel e rigenerarle.

Se un router mostra segni di compromissione e non si è in grado di ricostruire cosa è stato toccato, la strada più sicura è un ripristino alle impostazioni di fabbrica con la versione corretta e una riconfigurazione da un export verificato di prima dell'incidente.

Chi non può aggiornare subito ha una sola alternativa temporanea, indicata sia da MikroTik sia da CERT Polska: rendere irraggiungibili dall'esterno SSH, l'interfaccia web (WWW e WWW-SSL) e il servizio bandwidth-test. Riduce la superficie, non risolve.

Non basta aggiornare: l'accesso di gestione non va esposto

La lezione più utile di questa storia non riguarda MikroTik. Le interfacce di amministrazione di un router (SSH, WebFig, Winbox, l'API) non dovrebbero mai essere raggiungibili da internet, a prescindere dalle falle del momento. È lo stesso principio per cui la porta SSH dei server non si espone e per cui i tentativi automatici di indovinare le password, migliaia al giorno su qualunque cosa risponda, colpiscono anche i router: già a luglio la CISA, l'agenzia statunitense per la sicurezza informatica, aveva pubblicato due avvisi sull'API di RouterOS, uno dei quali segnala che non limita i tentativi di accesso falliti.

Nella pratica, la configurazione che consigliamo e applichiamo:

/ip/firewall/address-list/add list=gestione address=192.168.10.0/24
/ip/firewall/filter/add chain=input protocol=tcp dst-port=22,80,443,2000,8291,8728,8729 src-address-list=!gestione action=drop place-before=0
/ip/service/disable telnet,ftp,www,api,api-ssl
/tool/bandwidth-server/set enabled=no
/ip/ssh/set strong-crypto=yes

La prima regola scarta qualunque connessione ai servizi di gestione che non provenga dalla rete interna di amministrazione. Le altre spengono ciò che non serve. Lo staff MikroTik, sempre sul forum, ha precisato che limitare l'indirizzo sorgente nel servizio (/ip/service/set ssh address=...) è meno efficace di una regola firewall, perché il firewall scarta il pacchetto prima che il servizio lo riceva.

Per gestire il router da remoto la risposta giusta è una VPN come WireGuard, che RouterOS integra da anni: si entra nel tunnel con una chiave, e solo da dentro il tunnel si raggiunge SSH. È anche la raccomandazione esplicita del bollettino MikroTik. Il resto è disciplina: un inventario degli apparati con versione e data dell'ultimo aggiornamento, e una regola per cui gli aggiornamenti di sicurezza di un router si applicano entro pochi giorni, come per qualsiasi altro software che regge la produzione.

In sintesi

Sei falle in RouterOS, due delle quali insieme permettono di prendere un router MikroTik con SSH esposto senza alcuna credenziale, sono sfruttate in rete dal 2 settembre 2026. Le versioni 7.24.2, 7.23.4 e 6.49.21 le correggono e aggiungono un controllo automatico che marca come Flagged i router con tracce note di compromissione. La configurazione di fabbrica non è esposta, ma decine di migliaia di router configurati a mano lo sono. Si verifica il registro e gli utenti, si aggiorna, si cambiano le password, e si chiude per sempre l'accesso di gestione da internet, spostandolo dentro una VPN.

::cta{title="Hai router MikroTik in ufficio, in un rack o presso i clienti e vuoi metterli in sicurezza una volta per tutte?" text="Facciamo l'inventario, aggiorniamo in una finestra concordata, verifichiamo le tracce di compromissione, chiudiamo i servizi di gestione dietro WireGuard e ti lasciamo la configurazione documentata. Gestiamo reti e server Linux per PMI, studi e agenzie." button="Parliamone →"}

Fonti

Le email dei tuoi preventivi finiscono in spam? Ecco perché (e come si risolve)

Alessandro Corbelli — Sun, 20 Sep 2026 00:00:00 GMT

Mandi un preventivo, aspetti, e non risponde nessuno. La conclusione più naturale è che al cliente non interessasse. Spesso, però, la verità è un'altra: quell'email non è mai arrivata. È finita nella cartella spam, o è stata scartata prima ancora di entrare nella casella. Un affare perso senza nemmeno sapere di averlo perso.

Non è sfortuna, e quasi mai è colpa di quello che hai scritto. Nella grande maggioranza dei casi è un problema tecnico preciso, e risolvibile, nel modo in cui il tuo dominio dimostra la propria identità. Gmail, Outlook e gli altri grandi provider decidono in una frazione di secondo se fidarsi di un'email, e se il tuo dominio non prova di essere davvero chi dice, la risposta di default è: nella spam.

La buona notizia è che questo problema si diagnostica in mezz'ora e si sistema in un pomeriggio, e non richiede di cambiare provider di posta. Vediamo perché succede e come capire se riguarda anche te.

Perché un'email legittima finisce nello spam

C'è un difetto di nascita nella posta elettronica: il mittente si può falsificare con facilità. L'indirizzo che compare nel campo "Da" è come il nome scritto a penna sul retro di una busta, di per sé non lo garantisce nessuno. Per questo i provider filtrano in modo aggressivo, e un mittente che non riescono a verificare è, per definizione, sospetto.

Per decidere, controllano tre "documenti" pubblici del tuo dominio: SPF, DKIM e DMARC. Se mancano, sono rotti o non sono allineati, la tua email parte già in svantaggio. A questo si aggiunge la reputazione: l'indirizzo IP da cui spedisci ha una storia, e se in passato da lì è partito spam, o se il tuo dominio non è mai stato autenticato, i filtri ti trattano con diffidenza.

Il paragone è quello della dogana. Un pacco con documenti in ordine passa; uno senza mittente verificabile viene aperto, messo da parte o rispedito. La tua email è quel pacco, e i tre controlli sono i suoi documenti.

I tre controlli che decidono se ti leggono

Senza entrare nel tecnico, ecco cosa fa ciascuno:

SPF dichiara quali server sono autorizzati a spedire per il tuo dominio. Se l'email arriva da un server non in elenco, è sospetta.
DKIM aggiunge una firma che prova che il messaggio arriva davvero da te e non è stato alterato lungo la strada.
DMARC lega i primi due all'indirizzo che il cliente vede, dice al provider cosa fare quando qualcosa non torna e ti manda dei report su chi spedisce a tuo nome.

Chi vuole i dettagli li trova nella guida completa su cosa sono SPF, DKIM e DMARC. Il punto per te è un altro: dal 2024 Gmail e Yahoo li richiedono esplicitamente a chi invia volumi consistenti, e li usano come segnale per tutti. Non averli configurati oggi significa spedire in salita.

::cta{variant="inline" title="I tuoi preventivi arrivano davvero ai clienti?" text="Controlliamo SPF, DKIM, DMARC e la reputazione del tuo dominio, e testiamo la consegna reale verso Gmail e Outlook finché la posta entra in inbox." button="Chiedi un controllo →"}

Come capire se è il tuo caso, senza essere tecnico

Ci sono segnali che è ora di guardarci dentro:

I clienti ti dicono "non ho ricevuto niente", e tu l'email l'avevi mandata.
I preventivi verso indirizzi Gmail, Outlook o aziendali restano senza risposta più del normale.
Le email transazionali del gestionale o dell'e-commerce (conferme d'ordine, reset password) non arrivano.
Anni fa qualcuno ha collegato al tuo dominio una piattaforma di newsletter o un CRM, e nessuno ha più controllato la configurazione.

La verifica veloce la puoi fare anche da solo: manda una prova a un indirizzo Gmail e a uno Outlook, e guarda se finisce in spam. Poi apri l'email ricevuta e cerca, tra le opzioni "mostra originale" o "dettagli", le righe che dicono spf=pass o spf=fail, dkim=pass o dkim=fail. Un "fail" è il campanello. Esistono anche strumenti online gratuiti che, dato il tuo dominio, ti dicono se i tre record ci sono e sono coerenti.

Cosa NON risolve il problema

Vale la pena dirlo, perché sono le strade sbagliate che si tentano più spesso:

Comprare un hosting o un server più potente non c'entra nulla: la deliverability è una questione di DNS e reputazione, non di potenza.
Riscrivere il testo dell'email o togliere allegati aiuta poco se il dominio non è autenticato: il filtro decide prima di leggere il contenuto.
Aggiungere "questa non è spam" nel footer non ha alcun effetto sui filtri.

La reputazione di un dominio si costruisce in mesi e si brucia in un pomeriggio, per esempio con una casella compromessa che spedisce spam a tua insaputa. Per questo la cosa giusta è configurare bene i tre controlli, partire da DMARC in sola osservazione per capire chi spedisce davvero a tuo nome, e solo dopo irrigidire le regole. Prima si guarda, poi si decide.

In sintesi

I preventivi che finiscono in spam raramente sono sfortuna: sono il tuo dominio che non riesce a dimostrare di essere te. La combinazione di SPF, DKIM, DMARC e reputazione decide se un'email legittima entra in inbox o viene scartata. È un problema diagnosticabile e risolvibile in un pomeriggio, senza cambiare provider, e ogni email che torna a essere consegnata è un affare che stavi perdendo in silenzio. Se preferisci non metterci mano da solo, è esattamente il tipo di lavoro di cui ci occupiamo sui mail server che gestiamo.

::cta{title="Vuoi che i tuoi preventivi arrivino, e restino fuori dallo spam?" text="Analizziamo il DNS del tuo dominio, sistemiamo autenticazione e reputazione e verifichiamo la consegna sui provider reali, con tutto documentato riga per riga." button="Parliamone →"}

Fonti

Il sito è lento? Prima di comprare un server più potente, misura

Alessandro Corbelli — Sun, 20 Sep 2026 00:00:00 GMT

Un sito lento non è solo un fastidio: è un costo. Chi apre una pagina e la vede caricare a fatica se ne va, e con lui se ne vanno visite, vendite e fiducia. Google, poi, tiene conto della velocità quando decide chi mostrare per primo: un sito lento parte più indietro anche nei risultati di ricerca.

L'istinto, davanti a un sito lento, è quasi sempre lo stesso: "prendiamo un server più potente". È la reazione più naturale e, nove volte su dieci, è anche quella sbagliata. Un server più grande nasconde il problema per qualche mese, ti fa spendere di più ogni mese, e poi la lentezza torna, perché la causa non era la potenza. La regola è una: prima si misura, poi si spende.

Vediamo perché il "ferro" raramente è la risposta, quali due numeri puoi guardare da solo e gratis, e da dove nasce davvero la lentezza.

Perché un server più potente (di solito) non risolve

Il collo di bottiglia di un sito lento quasi mai è la pura potenza di calcolo. Nella grande maggioranza dei casi è qualcos'altro: immagini enormi mai ottimizzate, una cache assente o mal configurata, query al database scritte male, o troppi script di terze parti che rallentano il caricamento. Raddoppiare CPU e memoria non tocca nessuna di queste cause: le compensa un po', a caro prezzo, finché il traffico non cresce e il problema riemerge.

Il paragone è quello del traffico in città. Se le strade sono intasate perché ci sono troppi semafori mal regolati, comprare un'auto più veloce non ti fa arrivare prima: resti fermo nella coda, solo con una macchina più costosa. La velocità serve quando la strada è libera, non quando il problema è come è organizzato il percorso.

I due numeri da guardare, gratis

Prima di spendere un euro, guarda come sta il sito davvero. Ti bastano due indicatori, che trovi gratis in strumenti come PageSpeed Insights di Google, semplicemente incollando l'indirizzo del sito:

LCP (in italiano "il tempo per vedere il contenuto principale"): quanto ci mette a comparire l'elemento più grande della pagina, di solito l'immagine o il titolo in alto. Dipende molto da quanto è veloce a rispondere il server, un aspetto che ha un nome preciso: il tempo di risposta, o TTFB.
INP: quanto è reattiva la pagina quando ci clicchi o ci scrivi dentro. Un valore alto racconta una pagina appesantita da troppo codice che gira nel browser, spesso script di terze parti. È la metrica che ha sostituito il vecchio FID tra i Core Web Vitals di Google.

Questi due numeri ti dicono dove guardare. Un LCP alto punta verso il server e il caricamento; un INP alto punta verso gli script e il codice. È la differenza tra sapere e tirare a indovinare.

::cta{variant="inline" title="Il tuo sito è lento e non sai da dove nasce?" text="Misuriamo LCP, INP e TTFB, troviamo il collo di bottiglia reale e ti diciamo cosa conviene sistemare, prima di spendere in hardware." button="Chiedi un'analisi →"}

Le cause vere della lentezza, in ordine di frequenza

Nella pratica, la lentezza di un sito nasce quasi sempre da queste cause, ed è utile conoscerle perché ognuna ha un rimedio diverso e mirato:

Immagini enormi non ottimizzate. Una foto da 4 MB caricata così com'è pesa più di tutto il resto della pagina. Ridimensionarle e comprimerle bene è spesso il singolo intervento che rende di più.
Cache assente o mal configurata. Senza cache, il server ricalcola ogni pagina da zero a ogni visita. Una cache ben messa, lato server e lato browser, taglia i tempi in modo netto.
Query al database lente. Su CMS ed e-commerce è una causa classica: una singola query scritta male può bloccare intere schermate. È il cuore del problema quando, per esempio, un negozio PrestaShop diventa lento nei momenti di punta.
Troppi script di terze parti. Chat, pixel di tracciamento, tag di marketing, widget: ognuno aggiunge peso e ritardo. Spesso se ne accumulano a decine senza che nessuno li riveda.
Server sottodimensionato o mal configurato. Sì, a volte il server c'entra davvero, ma lo scopri da un TTFB alto misurato, non per sensazione.

Quando invece il server c'entra davvero

Va detto con onestà: capita che la causa sia proprio l'hardware, un hosting condiviso sovraccarico o una macchina sottodimensionata per il traffico reale. Ma anche in questi casi la risposta raramente è "comprare più potenza". Spesso basta introdurre uno strato di cache (Redis, Varnish), tarare bene il web server e il database, e lo stesso hardware regge il triplo del carico. Si passa a un server più grande solo dopo aver misurato che serve davvero, non come primo tentativo al buio.

In sintesi

Un sito lento raramente si risolve comprando ferro. Prima si misurano LCP, INP e il tempo di risposta del server; poi si interviene sulla causa reale, che nella grande maggioranza dei casi sono immagini pesanti, cache mancante, query lente o script di troppo. Spesso lo stesso hardware, tarato bene, va il triplo, a un costo molto inferiore rispetto a un server più grande che nasconde il problema per qualche mese. Se vuoi capire da dove nasce la lentezza del tuo sito prima di spendere, è il tipo di analisi con cui partiamo nel monitoraggio e ottimizzazione delle performance.

::cta{title="Vuoi un sito veloce senza buttare soldi in hardware?" text="Misuriamo, troviamo il collo di bottiglia reale e ottimizziamo cache, immagini, query e configurazione del server, con numeri prima e dopo." button="Parliamone →"}

Fonti

NIS2 e fornitori: cosa ti chiederanno i clienti obbligati (scadenza ottobre 2026)

Alessandro Corbelli — Wed, 14 Oct 2026 00:00:00 GMT

Se la tua azienda vende servizi a un'altra azienda, prima o poi quel cliente ti manderà un questionario di sicurezza o una clausola da firmare. Nel 2026 è più probabile che mai: la direttiva europea NIS2, recepita in Italia con il decreto legislativo 138/2024, sta arrivando alla sua prima grande scadenza operativa.

La NIS2 non riguarda solo i colossi. Per legge tocca le aziende medie e grandi di diciotto settori (non solo energia e sanità, anche servizi digitali, manifattura e altri) e, in alcuni casi, anche realtà più piccole. Chi rientra viene inserito in un elenco tenuto dall'ACN, l'Agenzia per la cybersicurezza nazionale, e deve adottare misure di sicurezza e segnalare gli incidenti. Se non sei in quell'elenco non hai quegli obblighi per legge. Ma se vendi qualcosa a chi ci è dentro, quegli obblighi ti arrivano lo stesso, per contratto.

Qui spieghiamo come funziona il passaggio dal cliente al fornitore, quali misure toccano server, backup e accessi, e da dove conviene cominciare. Una premessa onesta: non è consulenza legale. Sono i requisiti tecnici che ACN ha pubblicato, tradotti in cose da verificare.

Le scadenze: ottobre 2026 non vale per tutti

Il calendario dipende da quando il soggetto è stato inserito nell'elenco. Ogni anno, dal 1° gennaio al 28 febbraio, le aziende interessate si registrano sul portale ACN, e l'Agenzia comunica a ciascuna se è stata inserita. Da quella comunicazione decorrono due termini:

9 mesi per la notifica degli incidenti significativi (per il primo gruppo, inserito nel 2025, è scattata a gennaio 2026);
18 mesi per le misure di sicurezza di base (per lo stesso gruppo, ottobre 2026).

Chi è stato inserito per la prima volta nel 2026 ha più tempo: notifica degli incidenti dal 1° gennaio 2027 e misure di base entro il 31 luglio 2027. Quindi "ottobre 2026" non è una data universale: dipende dal cliente che hai davanti. Le misure sono quelle della Determinazione ACN 379907 del 19 dicembre 2025, in vigore dal 15 gennaio 2026: 37 misure per i soggetti importanti e 43 per quelli essenziali.

Come arriva a un fornitore: nei contratti

Le misure di base includono la gestione dei rischi della catena di fornitura. In pratica il cliente deve valutare i fornitori che possono avere un impatto sulla sua sicurezza e inserire requisiti di sicurezza nei contratti. Le FAQ di ACN chiariscono i punti che interessano a te:

i contratti già in essere non vanno modificati; i requisiti diventano obbligatori per i contratti firmati, rinnovati o prorogati dalla scadenza delle misure di base in poi, salvo motivate ragioni legali o tecniche documentate;
il cliente valuta il rischio di ogni fornitura: quanto accedi ai suoi sistemi e ai suoi dati, quanto pesa un tuo fermo prolungato, quanto costa e quanto tempo richiede il ripristino;
i requisiti riguardano le forniture con un potenziale impatto sulla sicurezza e devono recepire la sostanza delle misure, non copiarne il testo.

Cosa troverai scritto, quindi, lo decide il cliente. La linea comune è che chi gestisce i suoi server, il suo gestionale o il suo e-commerce dovrà dimostrare di avere in ordine le stesse cose che il cliente deve avere in ordine in casa.

::cta{variant="inline" title="Un cliente ti ha già mandato un questionario NIS2?" text="Lo leggiamo insieme e lo traduciamo in cose da verificare sui tuoi server: cosa c'è già, cosa manca e in che ordine sistemarlo." button="Fatti aiutare con il questionario →"}

Le misure che toccano server, backup e accessi

Le specifiche di base sono ampie e riguardano anche governo, formazione e documentazione. Quelle più legate all'infrastruttura, e quindi alle risposte che un fornitore IT dovrà dare, sono queste:

Inventario di sistemi e servizi (ID.AM, GV.OC): un elenco aggiornato di hardware, software, servizi e fornitori. Il primo passo è sapere cosa gira, dove e chi lo gestisce.
Solo software con aggiornamenti di sicurezza (PR.PS-02): va installato soltanto software, sistemi operativi compresi, per cui il produttore garantisce le patch di sicurezza, e le patch vanno applicate "senza ingiustificato ritardo", salvo ragioni tecniche documentate. È il caso di chi resta su una versione di PHP a fine vita.
Backup, anche offline (PR.DS-11): backup periodici di dati e configurazioni e, per i sistemi rilevanti, anche copie offline. La regola del backup 3-2-1 è un buon punto di partenza, a patto di provare il ripristino.
Autenticazione a più fattori e account separati (PR.AA-03, PR.AA-05): la verifica a più fattori per i sistemi rilevanti, in base al rischio, e account amministrativi distinti da quelli ordinari, con credenziali diverse.
Accessi da remoto elencati, protetti e registrati (PR.IR-01, PR.PS-04): un elenco dei sistemi raggiungibili da remoto e di come, firewall aggiornati, e registrazione di tutti gli accessi remoti e di quelli con privilegi amministrativi, con log conservati in modo sicuro e possibilmente centralizzato. Un bastion host per l'accesso SSH risolve gran parte della questione.
Gestione delle vulnerabilità (ID.RA-08): un piano scritto che dica come si scoprono, si seguono e si correggono, compreso il monitoraggio dei canali del CSIRT Italia, la squadra nazionale che gestisce gli incidenti informatici.
Fornitori e catena di fornitura (GV.SC, PR.PS-06): un inventario dei fornitori con referente e tipo di fornitura e, per chi sviluppa software, pratiche di sviluppo sicuro documentate. Il tema della catena di fornitura riguarda anche il codice: ne parla la storia dei pacchetti npm compromessi.

Un dettaglio rassicurante: molti requisiti valgono "per almeno i sistemi informativi e di rete rilevanti", cioè quelli la cui compromissione inciderebbe in modo significativo sui servizi. Il cliente può circoscrivere dove li applica, e di conseguenza dove ti chiederà conferme. I dati personali restano un capitolo a parte, quello del GDPR, che abbiamo raccontato in GDPR lato infrastruttura.

Incidenti: 24 ore, 72 ore, un mese, e chi avvisa chi

Per un soggetto NIS un incidente significativo si segnala al CSIRT Italia in tre tempi (articolo 25 del decreto 138/2024):

pre-notifica entro 24 ore da quando si viene a conoscenza dell'incidente;
notifica entro 72 ore, con una prima valutazione di gravità e impatto;
relazione finale entro un mese dalla notifica, con la causa e le misure adottate.

Il termine parte dal momento in cui il soggetto ha evidenza dell'incidente, che spesso è dopo che l'incidente è avvenuto. Per questo il tempo che passa tra "è successo qualcosa sul tuo server" e "il cliente lo sa" conta: ACN indica che i clienti dovrebbero chiedere ai fornitori, per contratto, di segnalare tempestivamente gli eventi di sicurezza. Se l'incidente di un fornitore colpisce i servizi del cliente, a notificare al CSIRT è il cliente, e anche il fornitore se l'incidente è significativo per lui; per i servizi cloud notificano entrambi, tranne che per l'infrastruttura (IaaS e hosting), dove notifica solo il cliente.

Tradotto: devi poter dire in poche ore cosa è successo, su quali sistemi e con quali conseguenze. Senza log, senza un contatto reperibile e senza una procedura scritta non è possibile.

Da dove cominciare, in un pomeriggio

Non serve un progetto da sei mesi per partire. Un ordine sensato:

Censisci server, applicazioni, servizi esterni e chi li gestisce. Una tabella basta.
Chiudi gli accessi: verifica a più fattori ovunque sia possibile, account amministrativi separati, elenco degli accessi da remoto.
Prova un ripristino da backup, incluso quello offline. Un backup mai ripristinato è una speranza.
Scrivi due pagine: il piano per le patch e la procedura per un incidente, con nome e telefono di chi risponde.
Prepara una scheda per i clienti che riassuma come gestisci server, backup, accessi e incidenti: la riuserai a ogni questionario.

Mettere in ordine la parte tecnica è il nostro lavoro quotidiano di messa in sicurezza dei server Linux. Una nota di onestà: siamo una consulenza tecnica, non facciamo audit di conformità né consulenza legale. Per quella serve un legale o un consulente specializzato.

In sintesi

La NIS2 arriva ai fornitori attraverso i contratti: dopo la scadenza delle misure di base, che per il primo gruppo di soggetti cade a ottobre 2026 e per i nuovi iscritti del 2026 a luglio 2027, i clienti obbligati dovranno chiedere requisiti di sicurezza a chi li serve. Le richieste ruoteranno attorno a cose concrete: inventario, patch sul software supportato, backup anche offline, accessi protetti e registrati, un piano per le vulnerabilità e una procedura per gli incidenti. Chi parte ora ha il vantaggio di rispondere in modo ordinato invece di improvvisare davanti a un questionario.

::cta{title="Vuoi arrivare pronto alla prossima richiesta di un cliente NIS2?" text="Facciamo l'inventario, mettiamo in ordine accessi, backup e aggiornamenti dei tuoi server Linux e documentiamo tutto in un report leggibile che puoi allegare alle risposte." button="Parliamone →"}